R
Raviteja Nekkalapu
Guest
The strange thing about AI-based redaction is that the redaction model still has to see the original data.
There is one job in an AI pipeline that I have become increasingly uncomfortable giving to another AI model.
Removing sensitive data.
Think about the usual setup.
A user pastes a support ticket, medical note, application log, resume, financial document, or customer conversation into your application.
Before sending it to the main LLM, you want to clean it.
So we add another model first.
The first model receives the original text and gets a prompt like:
Code:
Remove all personally identifiable information from this text.
Replace names, phone numbers, email addresses, account numbers,
credit card numbers and other sensitive information with placeholders.It returns a cleaned version.
Then we send that version to the model that actually performs the task.
At first, this looks like a privacy feature.
Then you draw the data flow.
Code:
User
|
v
Redaction AI
|
v
Main AIThe redaction model had to read the secret before it could remove the secret.
That bothered me.
Not because every AI provider is secretly training on every API request. That would be an inaccurate claim.
Several major providers now explicitly offer API and business terms under which customer inputs are not used for model training by default.
But training is only one question.
My question became much simpler:
Did this system actually need the original sensitive value in the first place?
If the answer is no, I do not want to transmit it.
The Privacy Problem Happens Before Training
Imagine this text arrives from a customer:
Code:
Hi, my email is [email protected].
My payment is failing on account 78329184.
The card I tried ends in 4242.
Can you check what happened?Suppose the model only needs to understand that a payment failed.
It does not need the person's email address.
It probably does not need the account identifier.
It definitely does not need a complete payment credential if somebody accidentally pasted one.
Whether the downstream provider trains on that information is almost beside the point.
The information has already left your application's privacy boundary.
There is now another system processing it.
That means another API request, another network path, another processor, another configuration surface, and potentially another retention policy that you need to understand.
This is why I started thinking about PII redaction as a data minimization problem rather than an AI problem.
The best sensitive value to protect downstream is often the one you never send downstream.
A Lot of PII Is Surprisingly Deterministic
There is a reason developers reach for AI here.
PII looks messy.
And some of it absolutely is.
Names are messy.
Addresses are messy.
A random identifier such as
AX92K1 could be a customer ID, a product number, or meaningless text depending on context.But a large amount of sensitive information is much more structured than that.
Credit card numbers have recognizable formats and can be checked with the Luhn algorithm.
Indian Aadhaar numbers can be validated using Verhoeff checksum logic.
IBANs have country-specific structure and MOD-97 validation.
Email addresses have syntax.
IPv4 and IPv6 addresses have defined structures.
Private keys and API credentials often contain recognizable prefixes and character distributions.
Government identifiers usually follow country-specific formats.
Phone numbers have country and length constraints.
That means detection does not have to begin with:
Code:
Hey model, does this look sensitive?It can begin with code.
Regex Alone is Not Enough
I should clarify something because "deterministic PII detection" often gets translated into "a giant file full of regex."
That is not how I think it should work.
Regex is useful for generating candidates.
Validation is what makes those candidates interesting.
Take a payment card number.
A loose regex can find sequences that look like card numbers, but a document may contain invoice numbers, timestamps, or random numeric identifiers with similar lengths.
Running Luhn validation immediately eliminates a large number of those false positives.
The same idea applies elsewhere.
For some identifiers you can validate a checksum.
For others you can validate prefixes.
For others you can validate length, surrounding words, country rules, or allowed character ranges.
The pipeline I eventually preferred looked more like this:
Code:
text
|
candidate detection
|
structural validation
|
checksum validation where available
|
context checks
|
redactionNothing in that sequence needs to predict the next token.
It just needs to be correct enough about the format it is looking for.
Determinism Has Another Advantage I Did Not Appreciate at First
The same input gives me the same decision.
That sounds obvious until you compare it with an LLM.
Suppose I send the same unusual identifier through a language model after changing the surrounding paragraph.
The model can interpret it differently.
Change the model version and the behavior can change again.
Change the system prompt, and you may get another result.
For many AI tasks, that flexibility is useful.
For a privacy boundary, I find it uncomfortable.
If I say an Aadhaar validator accepted a number because it matched the expected format and passed its checksum, I can reproduce that result.
If I say a card number was rejected because the Luhn checksum failed, I can reproduce that too.
I can write unit tests around both cases.
I can generate thousands of invalid values and make sure they stay invalid.
I can test every supported identifier independently.
That is a very different debugging experience from asking why a model classified one sentence differently on Tuesday.
The Hard Part Is Not Credit Cards
Structured PII is the easy half.
The difficult part begins when the sensitive information looks like normal language.
Consider this:
Code:
Please send the replacement laptop to
Rahul Sharma at Flat 204, Lake View Apartments."Rahul Sharma" has no checksum.
Neither does the address.
You can use dictionaries, gazetteers, contextual rules, and combinations of signals, but there is no magic validator that proves a string is a human name.
This is where deterministic systems have to be honest about their limitations.
You can make the rules broader and increase recall, but false positives go up.
You can make them stricter and reduce false positives, but you will miss unusual names and addresses.
There is no free lunch.
For my own implementation, I ended up separating strongly structured detection from deeper scanning intended for harder text patterns instead of pretending both problems were identical.
That distinction became important.
A 16-digit number that passes a card checksum is a very different signal from two capitalized words that might happen to be a person's name.
They should not receive the same confidence simply because both came from a "PII detector."
Blocking Can Be Better Than Redacting
I also changed my opinion about what should happen after something sensitive is found.
My first instinct was to redact everything automatically.
Now I think that is wrong for some categories.
If a user pastes an email address, replacing it with something like
[EMAIL] may be perfectly reasonable.If somebody pastes a private key, I would rather stop the request.
The same is true for certain credentials and financial identifiers.
Silently replacing an extremely sensitive credential can hide an important security event.
Sometimes, the correct response is:
Code:
Request blocked.
Sensitive credential detected.
Remove it before continuing.Redaction and blocking solve different problems.
A privacy filter needs both.
Then I Turned the Idea Into an API
After spending enough time on this problem, I packaged the approach into something I now call PII Firewall Edge.
It currently covers 152 categories of sensitive information.
The part that matters to me is not the number.
The important design rule is that the detection path does not ask a general-purpose AI model whether the text is sensitive.
The service uses deterministic detection and validation instead.
That means there is no prompt such as "please find the PII."
There is no model response to parse.
There is no token bill hiding inside the redaction operation.
There is no model upgrade that suddenly changes what my card validator thinks a card number looks like.
I checked the production dashboard before writing this article because I did not want to discuss the system only in benchmark terms.
During the last 30 days, the
redactDeep endpoint handled 4,840 API calls. RapidAPI reported a 0 percent average error rate and 101.43 ms average latency for that period.That latency is the API-level number shown by the platform, not a claim about the CPU time of the detector itself.
I think that distinction matters.
It is very easy to publish the smallest local benchmark you can produce and call your system "2 ms."
What users experience is the whole request.
An API Is Still Another Trust Boundary
There is an obvious criticism of everything I have written so far.
If I care about minimizing exposure, why send sensitive text to a redaction API at all?
That criticism is correct.
If your requirement is that raw customer data must never leave infrastructure you control, then use an in-process or locally hosted redactor.
A hosted API is not the right architecture for that threat model.
I would never tell a bank, hospital, or government system with a strict local-processing requirement to upload sensitive documents to my API simply because my detector does not use an LLM.
The network boundary still exists.
What a deterministic hosted redaction service changes is a narrower problem.
If your architecture already permits a dedicated external redaction processor, that processor does not also need to be a general-purpose generative model.
Those are two different privacy decisions.
I think developers should keep them separate.
The Question I Ask Before Every AI Call Now
Before sending data into an AI system, I try to ask one question:
What information does the model actually need to complete this task?
A resume summarizer probably needs employment history and skills.
It does not necessarily need the candidate's phone number.
A customer-support classifier needs the description of the problem.
It may not need the customer's email address or account number.
A coding assistant needs the stack trace.
It does not need the API key someone accidentally printed three lines above it.
A financial document analyzer may need transaction amounts and categories.
It may not need the full account identifier attached to every row.
Removing unnecessary information before the AI boundary feels less exciting than adding another AI model.
But I think it is better engineering.
AI Is Great. That Does Not Mean Every Step Needs AI.
I use AI every day.
I build with it.
I am not arguing that deterministic code is somehow superior to machine learning in general.
That would be ridiculous.
The reason language models are useful is that they can handle ambiguity that ordinary code struggles with.
But not every problem benefits from ambiguity.
Sometimes I want a system that follows a boring rule every single time.
A checksum should be boring.
A credential detector should be boring.
A firewall should be boring.
Privacy infrastructure probably should be boring too.
The more AI applications we build, the more sensitive information will eventually find its way into prompts. Some of it will be intentional. A lot of it will not.
We will need protection around those boundaries.
My preference is simple.
If a model does not need a sensitive value, remove that value before the model ever gets a chance to see it.
Not after.
Before.