# PII Redaction and Audit Logs for LLMs: A Practical Guide

PII redaction keeps personal data out of your LLM requests, and audit logs prove it happened. This guide shows how to set up both without letting the log itself become a store of the data you meant to protect.

_Source: https://saygm.com/blog/guide-on-pii-redaction-and-audit-logs-for-llm-traffic_
PII redaction and audit logs are the two controls a security review asks about first once LLM traffic reaches production. Redaction decides what personal data a model provider ever receives. Audit logs prove what happened afterwards. Getting one right while getting the other wrong is common, and the most frequent mistake is the quietest: the audit log ends up storing the exact data the redaction step was meant to remove.

The pressure to sort this out is real. Cyberhaven's 2026 research found that [39.7% of AI interactions involve sensitive data](https://www.cyberhaven.com/blog/sensitive-data-flowing-into-ai-tools), across prompt text, pasted content and file uploads. Once that traffic runs through a production API, every prompt becomes a potential copy of a customer record sitting on someone else's infrastructure.

This guide covers how PII detection and PII masking work on LLM requests, what an AI audit trail should actually contain, where redaction should run, and how to set it up step by step. If you're new to the hardware side of private inference, our explainer on [trusted execution environments for AI teams](https://saygm.com/blog/trusted-execution-environments-explained-for-ai-teams) is a good companion read.

## Table of Contents

- [What Is PII Redaction for LLM Traffic?](#what-is-pii-redaction-for-llm-traffic)
- [Why Does an AI Audit Trail Matter for LLM Compliance?](#why-does-an-ai-audit-trail-matter-for-llm-compliance)
- [The Logging Paradox: When the Audit Log Becomes the Leak](#the-logging-paradox-when-the-audit-log-becomes-the-leak)
- [Where Should PII Redaction Run?](#where-should-pii-redaction-run)
- [How to Set Up PII Redaction and Audit Logging](#how-to-set-up-pii-redaction-and-audit-logging)
- [How SayGm Handles Redaction and Request Records](#how-saygm-handles-redaction-and-request-records)
- [Common Questions About PII Redaction](#common-questions-about-pii-redaction)
- [Final Thoughts](#final-thoughts)

## What Is PII Redaction for LLM Traffic?

PII redaction is the process of finding personally identifiable information in a request and replacing it before the request is sent on. For LLM traffic, that means scanning the prompt, any retrieved context, and any tool arguments on the way out, then swapping names, email addresses, phone numbers, account numbers and similar values for placeholders. The model still gets enough to do its job. "Draft a reply to [NAME_1] about invoice [ACCOUNT_1]" is just as answerable as the original.

There are two parts to it, and they fail in different ways.

**PII detection** is the finding step. Structured data with a predictable shape, like email addresses, card numbers or API keys, is usually caught with pattern matching. Unstructured data, like a person's name or a street address in the middle of a sentence, needs context, which is where named entity recognition models come in. Most production setups combine the two. Neither is perfect: patterns miss anything unusual, and models produce both false positives and false negatives, especially on data that looks different from what they were trained on.

**PII masking** is the replacing step, and there are two broad approaches:

- **Irreversible masking** replaces the value with a generic label such as `[EMAIL]`. The original is gone, which is the safest option but means the model's reply will contain the label too.
- **Reversible substitution** (often called tokenization) replaces each value with a consistent placeholder and keeps a mapping, so the real values can be put back into the response before it reaches the user. This keeps replies readable, but the mapping itself is now sensitive and needs protecting.

The OWASP Top 10 for LLM Applications lists sensitive information disclosure as its second-ranked risk and recommends pattern-based detection and redaction as a mitigation. Redaction is a sensible layer of protection, not a fringe idea.

## Why Does an AI Audit Trail Matter for LLM Compliance?

Redaction reduces exposure. An AI audit trail is what lets you show that it happened, and answer the questions that come after an incident: which key made this request, which model answered it, when, and at what cost.

For LLM compliance, three pressures tend to drive the requirement:

- **Data protection law.** GDPR's data minimisation principle expects you to process only the personal data you need. Sending a full customer record to a model provider when the task needed none of it is hard to defend, and so is keeping that record in a log indefinitely.
- **Sector rules.** Healthcare teams working under HIPAA are expected to have audit controls that record activity in systems handling protected health information. An LLM integration that touches patient data falls inside that scope.
- **AI-specific regulation.** The EU AI Act requires high-risk AI systems to support automatic logging of events across their lifetime. The AI Omnibus, which entered into force on 27 July 2026, [moved the high-risk obligations to 2 December 2027](https://www.whitecase.com/insight-alert/eu-ai-omnibus-enters-force-amending-ai-act) for stand-alone systems. That delay is a window to design logging properly, not a reason to ignore it.

The common thread is that auditors want evidence. A policy document saying prompts are handled carefully is a weaker answer than a record of what was sent, to whom, and under which controls.

## The Logging Paradox: When the Audit Log Becomes the Leak

Here's the trap most teams walk into. The easiest way to build an audit trail is to log every request and response in full. It's great for debugging, and it answers any question an auditor might ask.

It also creates a second, permanent, searchable copy of every piece of personal data that passed through your system. If redaction runs after logging, or the logger captures the raw request before the redaction step, the audit log quietly undoes the redaction. Logs tend to be shipped to observability tools, kept for months, and readable by far more people than production databases are. A leaked log is often worse than a leaked prompt.

The fix is to separate *evidence* from *content*. A useful AI audit trail rarely needs the prompt itself. It needs:

- A request ID and timestamp
- The API key or service identity that made the call
- The model and provider that served it
- Token counts and cost
- Status, latency and error class
- Which guardrails ran and how many matches they made (counts, not the matched values)

That's enough to reconstruct who did what, when, and under which policy, without turning the log into a data store. Where you genuinely need content for debugging, keep it short-lived, redacted, and access-controlled, and treat it as a separate system from the audit trail.

## Where Should PII Redaction Run?

Where redaction happens matters as much as how well it detects. There are three common places to put it.

**In each application.** Every service redacts its own requests before calling a model. This gives fine control, but policies drift between teams, and every new integration has to remember to add it.

**At a central gateway or proxy.** All LLM traffic passes through one layer that applies policy consistently. This is where most teams end up, because it gives one place to configure rules and one place to record what happened. The catch is that a standard proxy sees every prompt in plaintext before it redacts anything. You've reduced what the model provider receives, but you've concentrated all of that raw data in the proxy, its host, and whoever operates it.

**Inside a trusted execution environment.** Redaction runs at a gateway, but the gateway itself runs inside hardware-isolated memory. The operator and the host can't read the prompt while it's being processed, so the original values and any placeholder mapping stay sealed for the life of the request. Remote attestation lets you check that the code doing the redaction is the code you expect.

One distinction matters here, and it's easy to blur. When a request goes to a closed frontier model, the model provider still receives it. Redaction reduces what that provider sees, and a TEE gateway cuts the gateway operator and host out of the picture, but the provider is still a party to the request. Open-weight models served inside a TEE go further: inference itself stays inside the confidential environment. Pick the tier based on how sensitive the content is, not just the identity behind it.

## How to Set Up PII Redaction and Audit Logging

Whatever tools you use, the setup follows roughly the same order.

1. **Map the data flows.** List every place LLM requests originate and what each one can contain: support tickets, uploaded documents, source code, retrieved records. You can't write a redaction policy for data you haven't found.
2. **Choose detectors per category.** Use pattern matching for structured values like emails, card numbers and credentials, and add entity detection where free text carries names and addresses. Add custom patterns for identifiers specific to your business, such as internal customer IDs.
3. **Separate keys by policy boundary.** Give each workload its own API key with its own guardrail settings. A support assistant and an internal code tool shouldn't share a policy, and separate keys also make the audit trail far easier to read.
4. **Decide between masking and round-trip.** If users need to see real values in the reply, use reversible substitution and make sure the mapping lives somewhere short-lived and protected. If not, irreversible masking is simpler and safer.
5. **Test with synthetic data.** Run the policy against realistic but fake examples before turning it on in production. Measure what gets missed, not just what gets caught, and bias toward over-redaction where a miss would be costly.
6. **Log metadata, not content.** Build the audit trail from the fields listed in the section above. Make sure no logger anywhere in the path captures the raw request.
7. **Set retention and review.** Decide how long each kind of record is kept, who can read it, and how often the guardrail match counts are reviewed for drift.

Treat redaction as one layer, not your entire data-loss prevention strategy. It sits alongside access controls, contracts with providers, and your own validation of what users are allowed to send.

## How SayGm Handles Redaction and Request Records

SayGm is an inference gateway that runs inside an Intel TDX trusted execution environment, and its guardrails are built around the placement described above: redaction happens inside the enclave, before the request leaves for a model provider.

![SayGm chat with PII redaction guardrails on, summarizing patient risk factors from a test prompt](https://assets.saygm.com/blog/2026/10/9e964f5a-3b10-4e5a-8c37-6346ccc905a5-patient-risk-factors-1684x1162.png)

[Guardrails on SayGm](https://docs.saygm.com/platform/guardrails/) are opt-in processors configured per API key and off by default. They cover personal data, secrets and credentials, your own regular expressions, and blocked words or topics. Matches are swapped for placeholders, the originals stay inside the enclave for the life of the request, and real values can be restored in the model's reply before it comes back to you. Because the gateway runs in a TEE, SayGm can't read the prompt during this process, so the redaction step doesn't create a new plaintext copy on SayGm's side.

![GPT-5.5 unable to count a redacted email's characters because SayGm replaced it before the request](https://assets.saygm.com/blog/2026/10/d895cfc8-733f-4596-ba4c-4c65ac71b456-patient-redacted-info-1160x742.png)

On the records side, SayGm keeps prompts and completions out of every record. According to its [privacy page](https://saygm.com/privacy), each request produces a settlement record covering the request ID, timestamp, gateway, provider and model, token usage, price and success status, with no prompts, completions, account details, API keys or IP addresses. Separate diagnostic records (latency, retry count, error class and guardrail counts) are kept for 30 days for support and debugging. Per-key usage and spend are visible in the dashboard. That's close to the metadata-only audit trail this guide recommends, without any extra work on your side.

The [privacy model documentation](https://docs.saygm.com/security/privacy/) spells out which tier your request falls into: frontier models are reached through an upstream provider that receives the request, while models with a `-TEE` suffix keep inference inside the confidential environment.

Next on the roadmap are attested logs, a signed and verifiable audit log of which model responded with what, and team-level controls with an audit log per user.

## Common Questions About PII Redaction

### What is the difference between data masking and redaction?

Redaction removes sensitive data so it can't be seen or used downstream. Data masking replaces it with a substitute, such as a label, a placeholder or a realistic fake value, so the surrounding text or record still works. In LLM traffic the two overlap: a redaction step usually masks each value with a placeholder like `[EMAIL_1]`. Masking can be irreversible, or reversible if a mapping is kept so original values can be restored in the model's reply.

### How do you mask PII data?

First detect it, using pattern matching for structured values like emails, card numbers and credentials, and entity recognition for names and addresses in free text. Then replace each match with a placeholder before the data leaves your control. For LLM requests, do this at a central gateway so every application gets the same policy, and decide up front whether you need the real values restored in responses.

### What is PII detection?

PII detection is the step that finds personally identifiable information in text or data before it's masked, redacted or blocked. It typically combines regular expressions for predictable formats with machine learning models that recognise names, locations and other entities from context. No detector is perfect, so test it against realistic synthetic data and review what it misses over time.

### Is pseudonymized data personal data?

Under GDPR, generally yes for whoever can reverse it. Pseudonymized data, such as text where names are swapped for tokens and a mapping is kept, can still be linked back to a person, so it stays within the scope of data protection law. In September 2025 the EU Court of Justice added nuance in [EDPS v SRB](https://www.jonesday.com/en/insights/2025/09/cjeu-clarifies-scope-of-personal-data-in-edps-v-srb-decision): pseudonymized data may not count as personal data for a recipient with no realistic way to re-identify it. That's a reason to keep placeholder mappings away from the model provider, and short-lived.

### What is the purpose of audit trails?

An audit trail is a chronological record of who did what, when, and with what result. For LLM traffic, its purpose is to show which key made a request, which model answered it, what it cost and which guardrails ran, so you can investigate incidents and evidence compliance. A good AI audit trail records that metadata and never the prompt content itself.

## Final Thoughts

PII redaction and audit logs solve two halves of the same problem. Redaction limits what leaves your perimeter, and the audit trail proves it, as long as the log itself never becomes a store of the data you were trying to protect.

- Detect with patterns for structured data and entity recognition for free text.
- Choose masking or round-trip substitution based on whether users need real values back.
- Run redaction at a central layer, ideally one that can't read the raw prompt itself.
- Build the AI audit trail from metadata, never from prompt content.
- Keep the frontier and confidential tiers distinct when deciding what's safe to send.

If you're routing production LLM traffic and want PII redaction that runs inside hardware-isolated memory, SayGm lets you turn it on per API key in minutes. Start with the [SayGm quickstart guide](https://docs.saygm.com/getting-started/quickstart/) and point your existing OpenAI, Anthropic or Gemini code at the gateway.

## About SayGm

SayGm is a drop-in inference gateway for teams who don't want to just take a company's word that their prompts are private. Every request runs inside a hardware-verified confidential environment - not even SayGm can see what's inside it. That's not a policy, it's provable. Swap in your existing OpenAI, Anthropic, or Gemini code and you're covered in minutes, at transparent, published rates with no hidden markup.

Say gm to AI at [saygm.com](https://saygm.com).

[Website](https://saygm.com) | [Twitter](https://x.com/say_gm_) | [Discord](https://discord.com/channels/799672011265015819/1343950080465698836) | [Blog](https://saygm.com/blog) | [Medium](https://medium.com/@say_gm_) | [Docs](https://docs.saygm.com/) | [LinkedIn](https://www.linkedin.com/company/saygm)