Shadow AI in the Enterprise: Finding the Tools Nobody Approved

Someone in finance pastes a supplier contract into a free chatbot to summarise the payment terms. A recruiter installs a browser extension that ranks CVs. A project manager switches on the AI notetaker in the video conferencing tool, and every internal meeting is now transcribed and retained by a processor nobody has assessed. None of this appears in the record of processing activities. None has been through a data protection impact assessment. None is covered by a processor contract or a transfer mechanism. This is shadow AI: not a rogue system built in secret, but competent people solving ordinary problems with tools the organisation never looked at.

It matters because accountability does not depend on awareness. UK and EU GDPR require the controller to be able to demonstrate compliance for all personal data processing, and you cannot demonstrate what you have never recorded. As the EU AI Act's obligations phase in, a second set of duties attaches to the deployer — the organisation putting an AI system to use — not only to the vendor that built it. The moment a subject access request, a supplier security questionnaire, a client audit or a breach notification lands, the gap between what you think you run and what your staff actually use becomes visible to someone other than you.

What shadow AI actually looks like

It is useful to separate three layers, because each is discovered differently.

Consumer tools on personal accounts. Staff signing up with a work email or a personal one, on a free tier, outside single sign-on. There is no contract, no configured retention, and often a default that permits the provider to use inputs for model training. Because there is no invoice, procurement never sees it.

AI features inside software you already licence. This is the larger and more overlooked layer. CRM, service desk, HR, productivity and conferencing suites have added generative features, and many are enabled by default or by a tenant administrator with no governance step. The vendor is contracted; the new processing purpose, the new sub-processors and the new data flows may not be.

Team-built automation. Scripts, low-code flows and agents wired to an API key on a departmental credit card, moving data between systems without any change control. These are the hardest to find and the most likely to act on production data.

The obligations that bite first

Most shadow AI does not create an exotic new legal problem. It breaks existing ones you already have controls for.

Under UK and EU GDPR: the Article 30 record of processing will be incomplete; Article 28 processor terms will be missing or accepted click-through by an individual with no authority; Chapter V transfer safeguards will be unexamined for tools hosted outside the UK or EEA; Article 32 security expectations will not have been tested; and where a tool systematically evaluates people — CV ranking, performance scoring, risk flags — Article 35 points towards a DPIA before use, not after. If output materially drives a decision about someone with legal or similarly significant effect, Article 22 is in scope. The higher GDPR penalty tier reaches 4% of global annual turnover, but in practice the more common consequences are a corrective order, a suspension of processing, and a remediation programme you did not budget for.

Under the EU AI Act, the questions are different. Is anything in use a prohibited practice — for example emotion inference in the workplace, or untargeted scraping to build facial recognition databases? That tier carries the highest exposure, up to 7% of global annual turnover. Is anything high-risk, which includes several employment and worker-management uses such as recruitment screening and task allocation? Deployers of high-risk systems have their own duties: use in line with the provider's instructions, meaningful human oversight by competent staff, input data that is relevant, monitoring, and retention of logs. Do any systems trigger transparency duties — telling people they are interacting with an AI, and marking synthetic or manipulated content? Most non-prohibited breaches sit under a 3% ceiling. Separately, the Act expects providers and deployers to ensure a sufficient level of AI literacy among staff operating these systems, which is difficult to evidence for tools you did not know existed.

Where to look

A discovery checklist you can run this quarter

• Agree a working definition of "AI system" for your organisation and write it down, so two teams do not return incomparable lists.
• Pull egress logs against a maintained list of AI vendor domains, and keep the list under review — new tools appear constantly.
• Export third-party application consents from your identity provider and review what data scopes were granted, by whom, and when.
• Ask each SaaS application owner one question in writing: which AI features are enabled in our tenant, and what is the default setting for training on our data?
• Search expense and card data for small recurring charges, which is where free-to-paid upgrades surface.
• Run a genuine amnesty: a short, no-blame survey with a named deadline, sponsored visibly by an executive. People disclose tools when disclosure is not punished.
• Cross-reference contracted AI vendors against your DPIA register to find the assessed-nowhere cases.
• Capture, for every item found: business purpose, data categories, personal data yes or no, decision impact on individuals, hosting location, contract status, and a named owner.

Turning a sweep into a standing control

A one-off audit ages badly, because vendors ship AI features into products you already own without asking. Two habits keep the picture current: treat sub-processor change notifications and vendor release notes as monitored inputs rather than noise, and re-run the log-based discovery on a fixed cycle with the results reported to the same forum that sees other risk metrics. Attestation from department heads at each cycle is weaker evidence than telemetry, but combining the two is what makes the register defensible.

The limits of this approach

Discovery and registration reduce the risk of unknown processing. They do not tell you whether a given system performs acceptably, whether its outputs are biased, or whether the human oversight you have designed is meaningful in practice — those require testing against your own data and population, and for high-risk uses that testing is the substantive work, not the paperwork.

This article is general guidance, not legal advice, and it does not address sector rules that may apply to you: financial services operational resilience requirements, medical device regulation where an AI tool supports clinical decisions, professional privilege and disclosure duties in legal contexts, or employment and works council consultation obligations that can apply before monitoring or assessment tools are deployed. Classification under the EU AI Act is fact-specific and the interaction between UK and EU regimes depends on where your systems, users and data subjects sit. Where a tool touches special category data, employment decisions, children, or safety-relevant functions, take specialist legal and technical advice before it goes any further.