Right now, while you're reading this, somewhere in your fintech an analyst is pasting client data into ChatGPT.
There's no alert. No SIEM line. No DLP block. Nothing in your incident queue.
That's not because nothing happened. It's because nothing is watching.
How a silent leak actually looks
A traditional data breach has a moment. A laptop is stolen. A phishing email lands. A misconfigured S3 bucket gets indexed by Shodan. There's a discrete event your monitoring stack can latch onto.
AI data exposure has no moment. It's a stream of small pastes spread across departments and weeks. An ops analyst summarising a payment dispute. A compliance officer drafting a SAR response. A junior accountant reformatting a vendor contract. Each one looks, to your existing controls, like ordinary web traffic.
This is the failure pattern: the leak looks normal because the channel is new and the data is conversational.
Why your existing stack misses it
Three concrete reasons your detection stack has a hole here:
- DLP scans files and email. A typed prompt is neither. Most DLP platforms don't model browser-tab content as a regulated egress channel.
- **CASB sees the tool, not the content.** Your CASB report shows ChatGPT in use across 47 employees. It does not show what those 47 employees pasted in.
- Network DLP samples and stalls on noise. Where TLS decryption is in place, vendors typically inspect a sampled subset for performance, and free-form chat generates more false positives than signal — so even when prompts are seen, they're rarely actioned.
Which means: detection at the prompt layer is the only place where the question "what just left the org?" can actually be answered.
What GDPR Article 5 expects
Most teams reach for Article 28 (the processor DPA) when they think about AI data leakage. Article 5 is the more pointed one.
Article 5(1)(f) requires personal data to be processed "in a manner that ensures appropriate security... including protection against unauthorised or unlawful processing." Article 5(2) — the accountability principle — requires the controller to demonstrate compliance with that.
"We trust our employees" is not a demonstration. "We have a policy that says don't paste client data" is not a demonstration. "Here is the redacted log of every prompt classified as high-risk in the past 90 days" — that's a demonstration.
A fintech without prompt-level visibility cannot meet the demonstrability bar in Article 5(2). The controls are not the issue; the evidence of controls is.
A 5-item silent-leak diagnostic
Thirty-minute exercise. Ask your team to answer these four questions in plain English. If any answer is "I'd have to ask" or "I don't know," that's the gap.
- Inventory. Which AI tools have appeared in DNS or proxy logs in the past 30 days, including web Copilot, ChatGPT consumer, Gemini, Claude, and any vertical-specific tool?
- Volume. Roughly how many prompt submissions per day across the company? An order-of-magnitude estimate is fine.
- Content classification. What share of those submissions, by best estimate, contain personal data, financial data, or confidential client material?
- Detection. If a high-risk prompt was submitted at 14:32 yesterday, would your monitoring stack have noticed by now? Specifically — would anything have alerted, queued, or been logged in a way you could surface to an auditor?
- Evidence. If the ICO requested, today, a sample of AI-channel processing activity from the past quarter, what would you hand them?
Most fintechs have answers to questions 1 and 2 within an hour. Most stall on 3, 4, and 5.
!Prompt-level audit log showing high-risk submissions
What "detectable" actually means
Detectable doesn't mean surveilled. It doesn't mean reading the actual content of every prompt your employees type.
It means: the category of data being submitted is classified at the moment of submission. Sensitive types — IBAN, PAN, DOB, passport, internal project codename — are pattern-matched. The submission is logged with classification and outcome (allowed, warned, redacted), not raw content.
That is a defensible audit trail. It's also, incidentally, defensible against employee privacy concerns — because it doesn't hand a manager the actual text of what was typed, only the structural fact that something matched a sensitive pattern.
The 30-day path to closing the gap
Three practical moves, in order:
- Inventory AI tool usage from DNS or proxy logs. Output: a one-page list of tools and rough usage volume.
- Pilot prompt-level visibility on 5-10 employees most likely to handle sensitive data — a junior analyst pod, a compliance team, a customer ops team. Run it for 14 days. Look at what surfaces.
- Decide based on what the pilot shows. Often the surface area is bigger than expected, and the policy work that follows is a one-week effort once the data is in front of you.
None of this requires banning AI tools. None of it requires adopting a single specific product. What it requires is the underlying capability: a log of what categories of data your team submits to AI, on what cadence, with what outcome.
Without that, your defence is your trust in your colleagues. With it, your defence is evidence — which is what Article 5(2) is asking for.
Run a free AI prompt audit. Install Prytive on 3-5 analysts for 7 days and see real redacted prompts from your own team. No setup call required. → prytive.com/start