Why 'We Have a Zero-Retention Agreement' Doesn't Solve Your PII Problem

A team ships an agent that touches customer data. Someone on the security side asks about PII exposure. Someone else points to the enterprise agreement: zero data retention, signed and filed. Case closed, or so it seems.

It isn’t closed. Retention and transmission are two different legal questions, and a zero-retention clause only answers one of them. The PII still leaves your systems. It still crosses the wire to a third-party provider. It still gets processed by a model that reads it in full before generating a response. Some vendors reserve the right to hold it briefly anyway, for abuse monitoring or debugging, regardless of what the retention clause says. None of that is covered by “we don’t keep it.” What you signed up for is “we don’t keep it afterward.” What happens during the request is a separate matter, and it’s the part most teams haven’t actually looked at.

This is worth sorting out now specifically. The EU AI Act’s high-risk obligations, things like data governance requirements, logging, and human oversight for systems that fall into scope, become fully enforceable on August 2, 2026. If you’re reading this close to publication, that’s weeks away, not some distant future compliance item.

This stopped being a healthcare-and-finance problem

The regulatory surface around LLM data handling widened fast, and not just for the obviously regulated industries. GDPR already treats any personal data sent to an LLM provider as “processing,” full stop, regardless of sector. The EU AI Act adds its own data governance rules on top for high-risk systems, with penalties reported up to €15 million or 3% of global turnover (some sources cite higher figures for certain categories, but they don’t agree with each other cleanly enough to repeat as settled). HIPAA treats PHI sent to a provider without a signed business associate agreement as a reportable disclosure, and current guidance increasingly pushes toward doing redaction inside your own network perimeter so PHI never touches the public internet at all. California’s amended CCPA/CPRA rules, effective January 1, 2026, now classify neural data as sensitive and treat any data from users under 16 as automatically sensitive. Connecticut passed its own LLM-training-disclosure mandate that took effect in the last days of June 2026.

Enforcement, to be fair, is messier than the headlines suggest. In March 2026, Italy’s Court of Rome annulled the Garante’s €15 million fine against OpenAI, the one finalized GDPR enforcement action anywhere tied specifically to a generative AI launch. So the honest picture isn’t “regulators are coming for you tomorrow.” It’s tightening rules, patchy enforcement, and real incidents in the meantime, like the breach of OmniGPT’s infrastructure that reportedly exposed tens of thousands of user records and tens of millions of lines of raw chat logs. Enforcement lagging doesn’t mean the exposure isn’t real; it means the consequences are currently more reputational and contractual than regulatory. One frequently cited figure claims nearly 40% of AI prompts carry sensitive data. Treat that as a directional estimate from a vendor blog rather than a hard number, but even a much more conservative version of that claim means this isn’t an edge case.

What redaction actually needs to catch

Ask someone to picture “PII redaction” and they’ll usually picture a regex: match anything that looks like an email address or a Social Security number, swap it out. That part works fine, structured PII is exactly what pattern matching is good at.

It’s everything else that regex misses. Names. Home addresses. A medical condition mentioned in a sentence instead of a form field. Any of that in a language other than English. This is why serious redaction tools use named entity recognition (NER), which is a technique that lets software guess “this string is probably a person’s name” based on context and patterns, rather than matching a fixed template. NER is necessary, but it’s not a solved problem. Microsoft’s open-source Presidio project kept adding new country-specific recognizers through the first half of 2026, which tells you multilingual PII detection is still very much a work in progress, not a checked box.

NER also makes mistakes in both directions, and this is where it gets genuinely uncomfortable to design around. Tune a system to catch everything and it starts flagging normal text: “I met them at Quantum Bistro” gets redacted to “I met them at [ORGANIZATION]” because the capitalization and rarity of the phrase look like an entity to the model. Do enough of that and the agent stops being able to do useful work; one security researcher bluntly described over-aggressive redaction as a “utility tax” on the agent. Tune the other way for fewer false positives and real PII starts slipping through unredacted. There’s no setting that eliminates both failure modes at once. Anyone telling you their redaction is 100% accurate either hasn’t stress-tested it or is rounding up.

Masking and tokenization are not the same thing, legally

Here’s a distinction that sounds like implementation detail but actually determines which regulatory bucket your system lives in.

Masking replaces PII irreversibly. The SSN is gone, swapped for a placeholder, no way to recover it. Done well, this can put the data genuinely outside GDPR’s scope, as true anonymization. Tokenization replaces PII with a reference that can be reversed by whoever holds the mapping. Legally, that’s still “pseudonymization” under GDPR Article 4(5), which means the data is still personal data and still fully in scope of the regulation. Same-looking output, completely different compliance posture.

So why would anyone choose the option that stays in scope? Because agents often need the real value back. Picture a support agent that tokenizes a customer’s account number before it ever reaches the model. The LLM reasons over a placeholder the whole time, never sees the actual number, and the gateway swaps the real value back in right before the agent’s tool call actually hits the account system. The model produces genuinely useful output without ever touching the sensitive value directly. That reversibility isn’t a nice-to-have bolted on afterward. For an agent that has to act on a real account, a real ticket, a real record, it’s the entire point of the design.

Where agent workloads break the generic advice

Most redaction advice online is written for a single chat message: a user types something, you scrub it, you send it. Agents don’t work that way, and two mechanics specific to agent loops get missed constantly.

The first is tool output. When an agent reads a file, queries a database, or calls an API, whatever comes back gets appended to the model’s context in full. A redaction layer watching only the user’s typed message never sees the SSN sitting inside a customer record the agent just fetched, or the raw output of a support ticket the agent pulled to answer a question. If your redaction only inspects the first message in, you’ve covered a fraction of what actually reaches the model.

The second is how agents handle history. Every coding agent, every support bot, every multi-turn tool-calling loop resends its entire conversation on every single turn. That’s not a design choice anyone made poorly, it’s how the underlying model works: it’s not remembering the conversation, it’s re-reading the whole transcript fresh each time. Which means a single PII leak that slipped into turn 3 doesn’t get sent to the provider once. It gets re-sent on every subsequent turn for the rest of the session. One mistake becomes many exposures, and the count keeps climbing the longer the session runs.

This is the exact intersection AJNT sits at as a gateway between agents and the providers they call. Its job is already rewriting the resent conversation history before it crosses the wire, so sessions don’t hit a provider’s context ceiling, and already routing requests across tool-call boundaries between providers. A layer already positioned to inspect every point where new content enters an agent’s context, not just the first user message, but tool outputs and everything resent afterward, is structurally the right place to also carry PII inspection through the whole loop, not just the front door. That’s a description of where this problem and this kind of infrastructure naturally meet, not a claim about a specific feature shipped today.

It’s also worth being honest that whether this inspection should happen at the gateway layer or inside the application’s own pipeline is a genuinely open question right now, with real tradeoffs on latency and accuracy either way. Nobody has settled it.

What’s still unsettled

Nobody has set a numeric bar for “how much residual leakage is acceptable” in a regulated context. The one academic benchmark that measured this across different redaction methods (published in August 2025, so treat it as background rather than a current snapshot) found close to a hundred-fold difference in leakage rates between the best and worst approaches on the identical task. That’s a wide enough spread that “we use an LLM to redact PII” tells you almost nothing on its own. The specific method matters enormously, and most teams haven’t measured which one they’re actually running.

And the EU AI Act’s enforcement date arriving in weeks doesn’t mean anyone knows yet how enforcement will actually play out in practice. That’s genuinely untested.

The practical takeaway is to stop treating “PII redaction” as a vendor checkbox and start treating it as an architecture decision: where does inspection actually happen, is it reversible or not, and does it cover the tool outputs and resent history an agent generates, not just the first thing a user typed. A zero-retention agreement is a real and useful thing to have. It’s just answering a narrower question than the one most teams think they asked.