Shadow AI Discovery & Control

Your bank already has an AI inventory. It is not the one in your spreadsheet.

The only reliable way to find the real one is to look at the network traffic. Surveys, attestations and browser plugins will all miss most of it. That is the short version, and the rest of this article explains why, and what to do about it.

The Problem

Right now, somewhere in your institution, a credit analyst is pasting borrower financials into a chatgpt to get a faster summary.

Right now, somewhere in your institution, a credit analyst is pasting borrower financials into a chatbot to get a faster summary. A collections agent is asking an AI to soften the tone of a letter that still contains an account number. A developer is dropping a stack trace with three live customer records into a coding assistant.

Nobody is acting maliciously. Everyone is trying to work faster. None of it appears in the inventory your model risk team took to the board last quarter.

This is shadow AI, and it is the widest gap between what banks believe about their AI exposure and what is actually happening on their networks.

Adoption is no longer the question. McKinsey found that 88% of organisations already use AI in at least one business function. Banks are often ahead of that curve, because the work is text heavy and repetitive in exactly the ways language models are good at. Credit memos. AML narratives. Customer correspondence. Policy interpretation. Code.

What has not kept pace is the control layer.

Most banks govern AI the way they govern models. A register, an owner, a risk rating, an annual review. That framework was built for models the bank builds itself, where someone knows they are deploying something.

Shadow AI does not work that way. There is no deployment. There is a browser tab. A plugin someone installed. An API key expensed on a corporate card. A vendor tool that quietly shipped an AI assistant in its last release without telling procurement.

You cannot put those in a register, because you do not know they exist.

The exposure

Shadow AI looks like a productivity issue. It is a data egress issue.

A single unregistered prompt can carry:

• Customer PII such as names, addresses, national ID numbers and dates of birth • Account and card data including IBANs, PANs and routing details • Credit and underwriting material, including financials and decision rationale • Investigation content such as AML case notes and fraud analysis • Internal confidential material like pricing models and board papers

Once that text reaches a third party model provider, your control over it ends. Retention terms vary by vendor and by plan. Enterprise agreements often exclude training use. Consumer accounts frequently do not. An employee using a personal account on a corporate device is exporting regulated data under terms you never negotiated and cannot audit.

The regulatory maths is unforgiving. EU AI Act penalties reach €35 million or 7% of global turnover, roughly double the GDPR ceiling. Gartner expects 75% of the world's economies to regulate AI by 2030, with half arriving by 2027. GLBA, PCI DSS and GDPR obligations already apply to the data itself, whatever the vector.

Then there is the question that ends careers rather than budgets. When an examiner asks which AI systems have touched customer data in the last twelve months, the damaging answer is not a large number. It is "we do not know."

Why the usual controls miss it

Four responses are common. Each solves part of the problem and leaves a gap.

Blocking at the firewall is blunt and fails quickly. Block the major AI domains and usage moves to personal devices, personal accounts and unmonitored networks. The exposure stays. Your visibility disappears. You also signal to a workforce that is trying to be productive that security is an obstacle, which makes everything after that harder.

Browser extensions only see the browser. They go blind the moment someone uses a desktop application, an IDE, an internal tool with an embedded assistant, or a script calling an API. In a bank, that is a large share of real traffic.

Acceptable use policy is necessary but it is a statement of intent, not a control. No examiner will accept it as one. Policy tells you what should happen. It produces no evidence about what did.

Traditional DLP was built for files, email and endpoints, where documents move between known locations. It was never designed to read the meaning of a conversational prompt in real time, decide whether the sensitive part can be safely substituted, and pass the rest through in under 200 milliseconds.

The shared weakness is the same in all four. They assume you already know which systems exist. Shadow AI is defined by the fact that you do not.

How Sayaa handles it

Sayaa starts from a different position. Discovery happens in the network path, from the traffic itself.

When a request from an employee, an application or an autonomous agent heads toward an AI platform, Sayaa sits in that path. It inspects the request, identifies the destination and checks it against your approved inventory.

If the platform is registered, governance proceeds as normal. Policy applies, the interaction is evidenced, and the system's risk score updates.

If it is not registered, that is shadow AI and it surfaces straight away. You see which platform, which user, which department, what data category was present and what enforcement decision was taken. It becomes a governance event with an owner attached, rather than a rumour.

Because this happens in the network path, it does not matter whether the prompt came from a browser tab, a desktop client, a coding assistant, an internal application or a script. Same path, same visibility.

Discovery alone changes nothing

Finding shadow AI and stopping there produces a report and an uncomfortable conversation. The risk position stays where it was. What matters is what happens in the same moment.

Sayaa applies policy at the point of interception, with graduated actions rather than a simple block:

• Allow. Low risk prompts on approved platforms pass through untouched. Governance should not tax work that carries no exposure.

• Warn. The user is told what was detected and why, and the event is logged. This is where most cultural change actually happens. People stop pasting account numbers once they see, in context, that they are doing it.

• Redact and tokenise. Sensitive values are swapped for secure tokens before the prompt reaches the model. The model reasons over the tokens and returns a useful answer. Real values are restored in the response only where policy allows. The analyst gets their summary. The account number never leaves the building.

• Block. For the highest sensitivity combinations, such as regulated data heading to an unapproved platform, the prompt does not leave and the attempt is logged in full.

• Escalate. Some cases need a person. The interaction routes to a risk owner with the detection detail attached.

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 on an unapproved consumer one, and allowed on an internal model running inside your own perimeter. That granularity is the difference between a governance control and a productivity tax.

Then you prove it

Discovery and enforcement handle the risk. Evidence handles the examiner.

Every enforcement decision is recorded with what was detected, which classification matched, which policy applied, what action was taken, who the user was and which platform was involved. Records are linked using SHA-256 chaining, so altering any single entry breaks the visible integrity chain.

Detection rules and enforcement policies follow two eyes approval. The person who writes a rule cannot be the person who activates it. Segregation of duties is how the platform operates, not an add on.

The practical result is that "which AI systems have touched customer data" stops being a project. It becomes a query with an exportable, timestamped, tamper evident answer behind it.

Where this goes next

Shadow AI is not a phase that ends when the novelty wears off. It is the predictable result of putting genuinely useful tools one click away from every employee. It will become more diffuse, not less, as AI capability arrives already embedded inside the vendor software your teams run today.

You have two realistic options.

Keep governing AI through registers and attestations, and discover your real inventory during an examination, an incident or a headline.

Or accept that visibility has to come from the traffic layer, that control has to be graduated rather than binary, and that evidence has to be produced continuously rather than assembled afterwards.

The banks that come out of this well will not be the ones that used AI least. They will be the ones that could always say, precisely and with proof, what their AI was doing.

One honest note on where we are. Sayaa is early stage and working with its first banking design partners. We are formalising independent security attestations alongside them, and we would rather say that plainly than imply certifications we do not yet hold.

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.