A county IT team downloads open-weight models for internal pilots without integrity verification of the files. What vulnerability should the auditor cite?
Select an answer to reveal the explanation.
Short Explanation
Downloading mystery weights without a checksum is like installing software from a sketchy USB stick. Verify integrity before county pilots trust the model. Incomplete license documentation isn't the control.
Full Explanation
Citing missing model integrity verification that leaves municipal AI ops open to tampered weights emphasizes checksums, signatures, and trusted sources when county teams download open-weight models. The correct vulnerability works because unverified files can be substituted with backdoored or corrupted weights that later run in internal pilots and potentially broader systems. Integrity verification is a foundational AI operations control for open-weight acquisition, analogous to verifying software package hashes.
Incomplete license documentation for open-weight models deployed in county pilot systems fails as the vulnerability because licensing paperwork does not detect or prevent tampered model weights. Unencrypted storage of pilot prompts and outputs on shared internal drives fails conceptually: encrypting stored prompts and outputs does not address whether the model files themselves were tampered with before loading. Limited logging of county pilot inference latency metrics for internal performance tuning review meetings fails because performance logging does not mitigate malicious or corrupted weight downloads.
Exam caveat: verifying a hash only helps if the expected hash itself comes from a trusted channel; phishing a false hash defeats naive checks. Operational check: obtain models from approved registries, verify signatures/checksums before load, quarantine unverified artifacts, and document integrity steps in county AI ops procedures for every open-weight pilot.