A municipal broadband team operates an AI assistant that can retrieve resident account PII for authorized clerks. What control best supports auditability of that access?
Select an answer to reveal the explanation.
Short Explanation
If something goes sideways with resident account data, you want a paper trail—who asked, when, and what scope they touched. Shared mystery logins and silent systems make investigations guesswork.
Full Explanation
For a municipal broadband AI assistant that can retrieve resident account PII for authorized clerks, auditability is best supported by logging who accessed the AI system, when, and which sensitive data scopes were involved. Those logs tie a named identity to time and purpose, enabling privacy reviews, insider investigations, and regulator or auditor questions about why a particular account was surfaced. Scope-aware logging matters because “someone used the chatbot” is not enough when the assistant can pull billing, address, or identity attributes.
Disabling all access logs to improve assistant latency trades a measurable performance gain for an unacceptable loss of accountability on systems that touch resident PII; latency tuning belongs elsewhere. Sharing one generic service account among all broadband clerks destroys attribution: every retrieval looks like the same principal, so misuse and mistakes cannot be investigated. Storing PII only inside free-form prompt history with no retention rules creates an ungoverned secondary store of sensitive data that may persist longer than policy allows and may not meet records or privacy controls.
Exam caveat: logging supports auditability; it is not itself authorization—access must still be role-based and least privilege. Operational check: require individual SSO identities, log principal, timestamp, and data-scope or tool-call metadata, protect log integrity and retention, and test that a sample investigation can reconstruct who retrieved which resident scopes.