Sensitive Data Exposure Prevention

Blocking is the wrong goal!

The objective is not to stop your people from using AI on sensitive work. It is to let the work happen while the sensitive part never leaves the building. Those sound similar. Operationally they are opposites, and the difference decides whether your data protection programme survives contact with the business.

Here is what that looks like in practice.

Follow one prompt

An operations analyst is clearing a payments exception. She pastes this into an approved AI assistant:

Please draft a customer note explaining the delay. Credit A/C 4390 1111 2222 3333 for GBP 12,400, customer Sarah Whitfield, ref TXN-88213.

Reasonable request. Legitimate tool. Approved platform. And in that single line sits a card number, a customer name, a transaction reference and an amount, all heading to a third party model.

There are three ways this ends.

The block ends it badly. The prompt is refused, the analyst gets an error, and within a week she is drafting the note in a personal account on her phone. You have moved the exposure somewhere you cannot see it.

The pass through ends it worse. The prompt sails past, the note comes back, the customer is happy, and a card number now sits in a vendor's logs under retention terms nobody in your institution has read.

The third option is the one worth building. The prompt leaves as:

Please draft a customer note explaining the delay. Credit A/C ⟦SGE_DATA_1⟧ for GBP 12,400, customer ⟦SGE_DATA_2⟧, ref TXN-88213.

The model has everything it needs to write a good note. It has the context, the amount, the structure of the request and the word "A/C" telling it what kind of thing is missing. It does not have the card number or the customer's name. When the response comes back, the tokens are replaced with the real values inside your perimeter, where policy allows.

The analyst gets her draft in the same few seconds. The regulated data never crossed the boundary.

That is the whole idea. Everything else is engineering.

The engineering is the hard part

Finding sensitive data in a spreadsheet is a solved problem. Finding it in free text, written by a human in a hurry, in under 200 milliseconds, without flooding your risk team with false positives, is not.

Three things make it genuinely difficult.

Structure disappears. In a database, a card number lives in a column called card_number. In a prompt it is sixteen digits floating in a sentence, possibly with spaces, possibly with dashes, possibly split across a line break because someone copied it out of a PDF.

Context decides meaning. The number 4390111122223333 might be a card. It might also be an internal reference, a batch ID or a timestamp concatenation. A rule that flags every sixteen digit string will be technically thorough and practically useless.

Precision and recall pull against each other. Loosen the rules to catch more and you drown the team in noise, and noise gets controls switched off. Tighten them and you miss the thing that mattered.

Most data protection programmes fail on the third point rather than the first two. The control works. Nobody can live with it.

Detection as a ladder, not a switch

Sayaa layers detection deliberately, and only trades precision for recall where the trade is earned.

Level one is rules with validators. Card numbers are checked with Luhn. IBANs are checked with mod 97. These are deterministic. A sixteen digit string that fails Luhn is not a card number, and you have not just avoided a false positive, you have proven it. This layer is in production and handles structured identifiers reliably.

Level two is keyword anchored matching. This is where most of the practical value sits. Instead of trying to describe every possible format of every possible identifier, the system recognises a value by what sits next to it. The words "A/C", "account", "IBAN", "policy no", "customer ref" tell you what the adjacent value is.

Then it does something specific. It tokenises the value and keeps the keyword.

That detail matters more than it looks. If you redact the whole phrase, the model loses the context it needs to be useful and the output degrades. Keep "A/C" and replace only the number, and the model still understands the sentence. One well built keyword anchored rule replaces well over a hundred regexes, and it does not shatter the first time someone formats a number differently. This layer is in production.

Level three is transformer based detection, which understands meaning rather than pattern and catches what rules miss. Being straight with you: this is exploratory research at Sayaa, not a shipped capability. We would rather tell you which rung of the ladder you are actually standing on.

Every rule carries a confidence score, and every rule is tuned in a live test sandbox against real sample text before it touches production traffic. You see the false positives before your users do.

Redaction is not one thing

Once something is detected, "redact it" is not a single action. Different data types need different handling, and forcing one behaviour across all of them is how programmes become unusable.

Sayaa supports:

• Mask, showing partial values where the last four digits are genuinely useful

• Remove, where the value should not appear at all

• Hash, where you need consistency across occurrences but never the original

• Replace with a static token, for simple substitution

• Tokenise and restore, where the real value comes back in the response inside your perimeter

Policy binds to the specific AI system, not to a blanket rule. The same customer record can be tokenised on an approved enterprise platform, blocked outright on an unapproved consumer one, and passed untouched to an internal model running inside your own network. When several policies match, the most restrictive one applies.

That granularity is what makes the difference between a control the business routes around and one it barely notices.

Know where the data is before it moves

Runtime protection catches exposure in flight. It is better to know what you are carrying.

Discovery scans connect to enterprise data sources and identify where sensitive data actually sits, which categories are present and where classification gaps exist. That feeds an exposure view by category, source, system, owner, region and risk level, and it rolls into the risk score for each AI system rather than sitting in a separate report.

The practical effect is that when a team proposes connecting an AI system to a data source, you already know what is in there.

Who gets to change the rules

A detection and redaction engine is only as trustworthy as its change control. Anyone who can quietly weaken a rule can quietly create an exposure.

New classifications and detection rules require two eyes approval before they go live. The person who writes a rule cannot be the person who activates it. Enforcement decisions are recorded and linked with SHA-256 chaining, so altering a record breaks the visible integrity chain.

Segregation of duties is enforced by the platform, not assumed by process.

What this does not solve

Three honest limits.

Detection is not perfect and no vendor's is. Confidence scoring, validators and sandbox tuning reduce false negatives substantially. They do not eliminate them. Anyone promising otherwise is selling.

Level three semantic detection is research at Sayaa today, not production. Rules and keyword anchoring do the work now, and they do it well for structured and semi structured identifiers.

If the detection engine becomes unreachable, a circuit breaker lets traffic continue rather than halting customer facing operations, and the event is logged. That is a deliberate choice of availability over a hard stop in a banking environment, and it is a tradeoff you should understand rather than discover.

The test to run

Take a prompt one of your teams would realistically write. A collections note, a credit summary, an AML narrative. Put real structure in it, with an account number, a customer name and a reference.

Then ask two questions.

Would your current controls catch it, wherever the person happened to be working?

And if they caught it, would the analyst still have been able to finish the task?

If the answer to the first is no, you have an exposure. If the answer to the first is yes and the second is no, you have an exposure arriving shortly, because people find the path of least resistance and it will not run through your controls.

The goal was never to stop the work. It was to let the work happen without the data going with it.

Sayaa is a runtime assurance platform for regulated financial institutions, combining AI governance, real time data protection and audit ready evidence in one control layer.