Transit security wants richer prompt logging for an AI assistant but worries the logs become a new exposure. What should management require?

Storing encrypted prompts but granting database read access fails because the decryption keys must still protect against internal access; the encryption provides no real protection if authorized insiders can read the data. That requirement works because prompt and output telemetry improve detection of injection, abuse, and policy violations, yet the same logs can concentrate rider identifiers, trip patterns, payment hints, and operational secrets. Management therefore retains necessary AI monitoring while applying access control, encryption, retention limits, redaction, and segregation so logging does not become an unmanaged vulnerability.

Logging every prompt in cleartext on a shared drive with no access controls fails conceptually because it maximizes confidentiality risk and treats highly sensitive AI artifacts as ordinary scratch files. Logging only errors and exceptions fails because it captures insufficient information for incident investigation; interactions where the model produces correct output contain context needed to understand system behavior and detect subtle attacks. Storing prompt logs only on public kiosks for rider convenience fails because public endpoints expand exposure and are inappropriate repositories for sensitive assistant content.

Exam caveat: “balance” is not license to log everything forever; privacy, retention, and purpose limitation still constrain what transit may keep. Operational check: classify prompt-log sensitivity, place logs in a restricted store with role-based access and short retention for routine content, redact known PII patterns at ingest, and require ticketed break-glass access for investigations.