Re-identifying redacted LLM logs when a regulator requests them

Why this is decided at redaction time

Teams redact prompts, responses and tool-call payloads to keep sensitive data out of models and general-purpose log stores. The problem appears later, when an authority or auditor needs to reconstruct what an AI system did in one specific interaction. If the original values were discarded, the evidence may be incomplete. If raw logs were kept everywhere, the privacy, retention and access exposure is the cost of that completeness.

NIST SP 800-188 describes de-identification as any process of removing the association between a set of identifying data and the data subject. For LLM logs, the design question is who can restore that association, under what conditions, and with what record. That question can only be answered by the architecture chosen when the redaction happens.

The EU AI Act points the same way. As of October 2026, high-risk AI systems must technically allow automatic recording of events over the system's lifetime (Article 12(1)). Providers must keep the automatically generated logs to the extent they are under their control, for a period appropriate to the intended purpose and at least six months, unless Union or national law provides otherwise, in particular on personal data protection. Deployers carry a similar retention duty for logs under their control. On a reasoned request, a provider must give a competent authority access to those logs. Logging is therefore a built-in capability, not something assembled after a request arrives, and retention yields to data protection law.

Comparing redaction methods for LLM logs

Each method trades recoverability against exposure. The right choice can differ by field. A national identifier in a prompt may warrant a different treatment from a name in a tool-call argument.

• Irreversible masking: The original value is removed or replaced with a fixed placeholder. Lowest exposure and simplest retention story, but nothing can be recovered. Suitable only where no later need to reconstruct the value is plausible.
• Deterministic tokenization: The same input always yields the same token, which preserves joins and pattern analysis across logs. The risk is that equal tokens reveal equal values, and a token derived from the value can be attacked by guessing inputs. Needs keyed derivation and tight key control.
• Vault-based tokenization: Tokens are random and unrelated to the value. The original is recoverable only by lookup in a mapping store. Re-identification is a single controlled operation, and the store can be retained, residency-bound and access-controlled separately from logs. The mapping store becomes a high-value target.
• Field-level encryption: The original value is stored encrypted inside the log record. No separate lookup is needed, but ciphertext travels with the log, so key management determines who can decrypt. Key rotation, key access and deletion semantics need careful design.

Where execution-path enforcement decides what evidence exists

Evidence can only describe decisions that were actually made and recorded. If redaction happens in a downstream batch job, or policy is reviewed after the fact, there may be no record of what was allowed at the moment of the interaction. Enforcement in the execution path means the decision, the redaction and the evidence record come from the same event.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit, or escalate for human approval, at the level of individual interactions and tool calls. That enforcement generates continuous audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed deploys self-managed in the customer cloud with configurable retention and data residency, so a regulated enterprise can keep evidence, and any mapping data it chooses to hold, under its own control.

The pattern in this guide does not depend on any product. Whatever you use, test it by picking a past interaction and asking three questions. Can you show what policy applied and what action was taken? Can you show who could reach the original value and who did? Can you show that the last re-identification was requested, approved and limited as intended?