Logging inherits the sensitivity of what it captures

An AI workflow that classifies tickets, drafts appeals, or recommends an action usually logs the full prompt, the retrieved context, and the model's response for debugging and audit purposes. If the underlying record contains a customer's account number, a patient's diagnosis, or a free-text note with a name and address, that content now also lives in the observability platform, the trace viewer, and often in a review queue UI built by a different team on a faster timeline.

OWASP's Top 10 for LLM Applications names this directly as Sensitive Information Disclosure: the risk that an LLM application leaks private data through its outputs, logs, or traces, not through a classic breach of the source database. The failure mode is rarely a hacked system. It is a well-intentioned logging pipeline that nobody scoped for the sensitivity of what passes through it.

Redaction is a design decision, not a cleanup step

The fix is not a quarterly log-scrubbing script. It is deciding, at the point where data enters the workflow, which fields are needed downstream and which are not, then masking, tokenizing, or dropping the rest before anything is written to a log, a trace, or a review packet.

This is the same data-minimization principle GDPR Article 5 sets out for personal data generally: information collected and retained should be "adequate, relevant and limited to what is necessary" for the purpose it serves. Applied to an AI workflow, that means the review packet a human sees should carry the evidence needed to approve or reject a case, not a full export of the source record.

  • Mask account and policy numbers to the last four digits in logs and review UIs.
  • Hash identifiers used only for deduplication or rate limiting; never store them in reversible form if the original isn't needed.
  • Strip free-text notes and attachments from the trace unless a specific field is flagged for the decision at hand.
  • Keep the decision record (what was decided and why) separate from the source document it was decided from.

Retention and redaction answer different questions

Retention policy answers how long a piece of evidence must be kept, usually driven by audit, legal, or contractual requirements. Redaction answers what belongs in that evidence in the first place. Teams often solve the first and assume it covers the second; it doesn't. A seven-year audit trail of unredacted customer data is a seven-year liability, not a compliance win.

The NIST Privacy Framework frames this as an ongoing risk-management function rather than a one-time control: organizations are expected to continually identify what data they are actually holding, map where it flows, and decide what level of protection each flow needs. For an AI workflow, that mapping has to include the logging and review layers, not just the primary data store.

Review queues are the leak point few teams audit

A human-in-the-loop review step is supposed to add a control, but the review UI itself is often the least-audited part of the system. More people typically have access to the review queue than to the source system, screenshots and exports proliferate outside both, and reviewers can usually see far more of the underlying record than their decision requires.

Treat the review packet as a product surface with its own data contract: list exactly which fields it shows, who can see it, and how long it persists after a decision is made. That contract is cheap to write before launch and expensive to reconstruct after a data-exposure incident.