Social-services staff notice that chatbot prompt logs contain resident case details. How should the city treat those logs?

Municipal social-services chatbot prompt and response logs frequently contain resident identifiers, case narratives, and benefits details equivalent in sensitivity to case notes. The city should therefore classify those logs at the same sensitivity level as case records and apply matching encryption, access control, retention, and audit requirements. Treating prompt logs as first-class protected data closes a common AI blind spot: teams harden the case management system while leaving conversational telemetry in debug buckets, shared drives, or chat channels. Encryption protects confidentiality if storage is compromised; classification drives who may read, how long logs are kept, and whether they may leave the agency boundary.

Classifying and encrypting prompt logs with the same controls used for case counts fails because case counts controls assume aggregated, low-sensitivity counts with broad access; resident identifiers and case narratives in those logs remain as sensitive as case notes and would be exposed to routine aggregation and overly broad readership.

Classifying and encrypting prompt logs with the same controls used for case summaries fails because case summary controls are designed for condensed, redacted overviews with broader internal sharing; applying them to prompt logs would expose resident case details to readers who must never see them and would lack the strict access control, retention, and audit trail required for case notes.

Classifying and encrypting prompt logs with the same controls used for case statistics fails because case statistics controls prioritize aggregate reporting and broad planning access to de-identified totals; resident identifiers and case narratives would remain as sensitive as case notes yet be exposed to reporting staff and analytics pipelines without case-level protections.

Exam caveat: Applying case statistics controls does not neutralize sensitivity; resident details in prompt logs remain as restricted as case notes and would still be exposed to broad reporting access and retention that violate privacy rules. A case statistics label that permits broad reporting access without case-level restriction reopens the gap the classification was meant to close.

Operational check: Inventory social-services AI log stores; map them to the same classification labels as case notes; enforce encryption at rest and strict RBAC; disable public or all-staff dump channels; never apply case-summary controls to prompt logs; never apply case-counts or case-statistics controls to prompt logs; and sample recent prompts to confirm PII handling matches the written records policy before any external SIEM ingestion.