What an AI data leakage assessment actually is
An AI data leakage assessment answers one question that matters commercially. Where can your staff expose sensitive data through the AI tools they already use?
It sounds simple. The answer almost never is. People reach AI through several doors at once. Browser chatbots, assistants built into the software they open every morning, coding tools, document editors. Your security team sees some of that and misses the rest. Even the tools you have signed off often arrive with default settings that let far more data flow out than anyone pictured when they approved them.
A good assessment looks at two things side by side. The technical reality, meaning what data is actually leaving and through which services, and the governance wrapped around it, meaning your policies, your access controls, and your logging. What comes back is a picture of your real exposure today, on the systems your people use right now, rather than the exposure your policy imagines.
For a regulated UK firm that picture has stopped being optional. The FCA and the PRA have both made clear that any firm using AI near customer outcomes needs to show where those tools sit and how they behave. Having that evidence ready before a regulator asks is worth far more than producing it in a hurry afterwards.
Why regulated firms are booking these now
Two pressures have arrived at the same time.
The first is speed. AI tools landed in everyday work long before most firms had any policy for them. So the typical picture today is staff using tools nobody assessed, under rules written after the fact, with logging that does not cover the behaviour that matters. Governance is trailing the risk by a wide margin, and the gap is still widening.
The second is the regulator. The FCA's expectations on model risk, Consumer Duty, and operational resilience all carry implications for how AI use gets documented and controlled. The practical upshot is blunt. A firm that cannot show a regulator the shape of its AI use, which tools are running, which data can pass through them, and how AI influenced decisions are recorded, is in a weaker position than one that can.
An assessment hands you that documented baseline before the question is ever asked. It also packages the evidence for the other people who come knocking. An insurer pricing your cyber risk, an enterprise client running supplier due diligence, a board that wants assurance the risk is understood.
What an assessment covers
The work usually splits into four areas.
Outbound data flow. A technical look at your network and proxy logs to find connections to AI services. This tells you which tools are live, how much traffic is going where, and whether the patterns suggest sensitive data heading into services nobody reviewed. It catches the most common problem of all, staff quietly routing work through consumer AI products.
Productivity AI configuration. Microsoft Copilot, Gemini for Google Workspace, and similar embedded assistants are a different animal. Firms often wave them through because the underlying platform is already in use, but the AI layer changes the data access model completely. An assistant that inherits a user's permissions can read, summarise, and act across that user's whole footprint. Mailboxes, calendars, shared drives, CRM records, financial documents. Checking how those tools are set up, and what an ordinary user can actually reach, belongs in any serious assessment. We go deeper on this in the Microsoft 365 Copilot risk assessment and the Google Workspace Gemini risk assessment.
Policy and control gaps. Technical exposure only matters once you know whether your controls were built to catch it. The assessment reads your acceptable use policy, your data handling rules for anything processed by AI, and the controls, if any, that enforce them. A familiar finding is a well written policy with no teeth. It correctly forbids sending client data to unapproved services, yet nothing in the environment stops someone doing exactly that, and nothing would record it if they did.
Logging and audit. Every regulated firm needs to know whether it could reconstruct events after a leak, suspected or alleged. Most discover their logging for AI activity is far thinner than for other data processing. The assessment tests whether you hold any audit trail for AI use, whether it covers the tools genuinely in play, and whether it survives in a form a regulator or a court would accept. This feeds straight into the harder job of building an AI audit trail for compliance, where the distance between what the policy intends and what the systems actually capture tends to be wider than security teams expect.
What it usually turns up
No two assessments read the same, but a handful of findings show up often enough to call out.
Consumer AI with no governance around it is the one we see most, in regulated and unregulated firms alike. Staff feed sensitive data into public chatbots and document tools that have no data processing agreement behind them. This is rarely reckless. It is people being efficient when no sanctioned alternative exists. The risk is the same either way.
Productivity AI with broader reach than anyone expected is close behind. Where Copilot or Gemini is switched on, the assessment regularly finds the data model is wider than users or their managers thought. An assistant that can see a user's whole mailbox, every document in the drives they can open, and all their calendar entries creates an exposure surface that simply did not exist before the tool went live.
Then there is logging that is missing or half there. Being able to reconstruct what happened is the backbone of accountability, yet most firms find their AI logging is either absent or only covers some of the tools in use. Usually this is a setup gap rather than a deliberate call, but the effect is the same. A serious incident involving AI assisted exposure would be very hard to investigate after the event.
Last, policies held up by goodwill rather than controls. A policy that depends on every employee reading it, understanding it, and applying it correctly under pressure is a policy that will let you down at the worst moment. Mature programmes aim for technical enforcement instead. Allow lists, data loss prevention, gateway controls. Most assessments find a real distance between what the policy says and what the systems enforce.
None of this is evidence of negligence. It reflects how fast AI arrived at work compared with how slowly governance has caught up. An AI governance framework for the enterprise gives you the structure to close these gaps in order, but the assessment is what tells you which gaps you actually have and which to tackle first.
How it differs from a penetration test or a DPIA
People mix these up, and the difference matters when you scope the work.
A penetration test asks whether an attacker can get in. An AI data leakage assessment asks whether your data can get out, specifically through the AI tools your own staff use to do their jobs. Different question, different threat model.
A data protection impact assessment is a legal step under UK GDPR, required before you start high risk processing. It weighs one defined activity against set criteria. The AI assessment is a discovery exercise with a wider lens. It finds what is already happening before you have pinned it down clearly enough to run a DPIA at all. The two work well together. An assessment often uncovers processing that then needs a DPIA, and its output gives you much of the factual groundwork for writing one. Neither stands in for ongoing AI governance. The assessment sets your starting position. Governance keeps that position from slipping as your tools, people, and use cases change.
What to do with the report
A useful report is ranked, not exhaustive. The job is not to list every risk you could dream up. It is to tell you which exposures matter most, why, and what to do.
Top priority findings tend to involve live exposure of regulated data through unapproved services, or specific settings you can change with little effort and real impact. These earn action in the first week. The middle tier, usually policy gaps, logging shortfalls, and training needs, shapes the following quarter. They are real, but you have more time before they bite.
The report should be something you can put in front of the board as proof the risk has been found and is being handled. It needs to be clear enough that a non technical director grasps the nature of the exposure, how serious it is, and what the plan is. For a regulated firm, that is exactly the kind of documentation a regulator or insurer wants to see.
Where staff awareness comes up as a weak point, and it usually does, the next question is how to build knowledge that lasts rather than running a one off training event. Our guide to measuring training effectiveness covers the evidence behind structured learning, and why it matters most for AI risk, where the threats move faster than an annual training cycle can follow.
How to commission one
The IntelXview AI Data Leakage Risk Assessment is fixed scope. Two weeks, £1,500, with a written report covering all four areas above. Fixed scope means clean commercial terms, a short procurement cycle, and no doubt about what you are getting or when.
If you run on Microsoft 365 or Google Workspace, a platform specific assessment digs further into the AI layer inside that environment, on the same fixed scope basis.
The starting point never changes. Understand what is actually happening before you decide what to do about it. An assessment gives you that understanding in a form that is documented, defensible, and useful to everyone who needs it. Your security team, your board, your regulator, and your clients.
