Why Your AI Feature Needs More Than a DLP Filter

TIL: Why Your AI Feature Needs More Than a DLP Filter

A quick breakdown of AI DLP vs. AI privacy firewalls, and why picking wrong costs you later

Last week a junior dev on our team opened a PR that, buried three files deep, sent the entire raw request body — including the user's email and a free-text "notes" field — straight to an LLM API. No filtering, no masking, nothing. It passed review. It almost merged.

That's not a callout post. It's basically me, six months ago, on a different project. Turns out this is one of those things almost every team building on top of LLMs learns the hard way, usually right before launch, sometimes right after. So here's the TIL version of what I wish someone had explained to me before I went down this rabbit hole.

The mistake everyone makes first

You wire up an LLM call. You test it with clean sample data. It works. You ship it. Then real users start typing real things into that free-text field — their name, their phone number, sometimes a full home address because they were mid-rant about a delivery — and suddenly every one of those details is sitting in a third-party API's request logs.

Nobody did anything wrong on purpose. The gap is just invisible until someone goes looking for it.

The two fixes people reach for (and why only one scales)

Once you notice the problem, there are two directions you can go, and they are not the same thing even though people talk about them like they are.

Option 1: Block it. This is basically AI DLP (data loss prevention) applied to LLM traffic. You scan the outgoing prompt, match it against patterns for emails, phone numbers, card numbers, etc., and reject or flag anything that matches before it goes out. It's the natural extension of tools your security team probably already runs.

Option 2: Transform it. This is what people are starting to call an AI privacy firewall. Instead of asking "should this be allowed through," it asks "how do I make this safe to send." Sensitive entities get swapped for placeholder tokens before the prompt leaves your infrastructure, the model responds using those placeholders, and your app swaps the real values back in once the response comes back.

Here's the part that took me too long to internalize: Option 1 breaks your feature when it fires. If your DLP layer blocks a prompt because it contains a phone number, what does your app actually do? Show an error? Silently drop the request? There's no good UX answer, because the feature just doesn't work in that case.

Option 2 doesn't have that failure mode. The feature works the same way every time, sensitive or not, because the data is disguised rather than rejected.

A resource that actually explains this well

I went looking for something that laid out this comparison properly instead of just repeating marketing copy, and found a solid one — deployment models, cost, compliance angle, the works:

AI DLP vs. AI Privacy Firewall: which one should you actually choose

If you're the one actually deciding this for your team, it's worth the read before you pick a direction.

What we actually built

We ended up going with the transform approach — a small proxy layer sitting between our backend and the model API. Every outbound prompt passes through entity detection first (names, emails, phone numbers, order IDs), gets the sensitive bits swapped for stable placeholders, then goes to the model. The response comes back with placeholders still in it, and our proxy swaps the real values back in before it ever reaches the frontend.

It's more upfront work than a regex. It's also the only version of this that doesn't randomly break the feature depending on what a user typed that day.

Questa AI is one of the vendors building exactly this kind of real-time anonymize-and-rehydrate layer, if you want a reference point for what "production-ready" looks like here instead of rolling your own from scratch.

The regex phase will burn you

Before we built the proxy, we tried the classic move: regex for emails, regex for phone numbers, regex for card numbers. It looked fine in our test suite. In production it missed international phone formats, typo'd emails, and basically anything that wasn't a US-shaped pattern. It also occasionally flagged our own support agents' names as "sensitive" and swapped them out when it shouldn't have.

None of that is a reason to give up on the idea — it's a reason to expect a real tuning period after you ship, the same way you'd expect to tune any other detection system. We review missed/false-positive cases monthly now like any other bug bucket.

Why this isn't just an engineering nice-to-have

If your product touches EU users, the EU AI Act's transparency rules are already live, and GDPR's data minimization principle has been around forever. "We have a regex" is a weak answer if anyone ever asks how you're minimizing exposure by design instead of catching problems after they've already happened. Building the anonymization layer before launch is a much smaller diff than retrofitting it into a feature customers already depend on.

More on this if you want the longer version

I've written a few different takes on this same underlying problem for different audiences — worth a look if this topic is relevant to what you're building:

Why "Just Block It" Doesn't Work for AI Data Leaks

The AI Privacy Trap Most Companies Don't See Coming

We Almost Shipped an AI Feature That Leaked Customer PII

TL;DR

• DLP blocks sensitive prompts. Privacy firewalls disguise them so the feature keeps working.
• Blocking creates a bad UX problem: what happens when the request gets rejected?
• Transforming has no equivalent failure mode — it just always works.
• Build this before launch. Retrofitting it later is a much bigger lift.

Would genuinely love to hear how other teams are handling this — drop your approach in the comments.