How UK B2B firms find the AI tools staff already use, triage them by data, and keep one register that answers customers.
Shadow AI is staff use of AI tools the firm has not approved or cannot see, including AI features inside approved software. Bans hide it. Find it from SSO grants, expenses, extensions and an amnesty, triage each tool by the data it may receive, and keep one AI tool register that answers customer questionnaires.
An enterprise customer's security questionnaire asks which AI tools process its data, and nobody can answer with confidence. Or someone finds client data pasted into a personal chatbot account. Either way, shadow AI has stopped being a theory. This guide is for founders, COOs and security leads at UK B2B tech firms selling into regulated customers.
Shadow AI is staff use of AI tools the firm has not approved or cannot see: personal chatbot accounts, browser extensions and AI features switched on inside software you already approved. Bans push that use out of sight. The fix is discovery, a triage based on data, a paved road and one register.
By the end, you will know how to find the tools already in use, decide which to approve, restrict or block, and keep one record that answers your customers and supports ISO/IEC 42001 and the EU AI Act where they apply.
Shadow AI is any use of an AI tool for work that the organisation has not approved, or cannot see. It covers free chatbot accounts used with work data, AI browser extensions, meeting note-takers that join calls uninvited, and AI features a supplier switched on inside a tool you approved before those features existed.
Most shadow AI starts with good intentions. Someone wants to write a proposal faster, summarise a contract or clean up a spreadsheet, and the tool is one browser tab away. The risk is not the intent. The risk is that client data, personal data or your own confidential material leaves the firm with no record of where it went or what the vendor may do with it.
That is why shadow AI is a visibility and evidence problem before it is a discipline problem.
A policy nobody can follow does not reduce shadow AI. It hides it.
Shadow AI is a kind of shadow IT, but three things make it harder to manage. AI arrives inside tools you already approved, so your software list misses it. Every prompt can carry data out of the firm. And the vendor's terms decide whether your inputs are stored, reviewed or used to train its models.
Shadow IT usually meant a team buying its own file-sharing or project tool. You found it on an expense report and either approved it or moved the team onto the company standard. Shadow AI breaks that pattern in three ways:
The ways AI systems themselves are attacked, such as prompt injection, are a separate subject, and our AI security risks guide covers them.
Find shadow AI by reading sources you already hold before buying anything new. Single sign-on and OAuth app grants, expense and card data, the browser extension inventory, DNS or proxy logs where you have them, and a short staff survey with an amnesty will show much of the AI in use at a 25 to 100-person firm.
Work through the sources in this order, because each one is cheaper than the next:
Then check your approved software. Review each supplier's release notes and admin settings for AI features, and record which ones are on.
The amnesty is also the only source that tells you why people chose each tool. That reason becomes the requirement for the approved option.
Triage each AI tool by the most sensitive data it may receive, not by the tool's popularity or brand. Sort the firm's data into four classes (public, internal, confidential, and client or personal data), then decide which tool tier may receive each class. Every tool you find lands as approved, restricted or blocked.
| Data class | Example | Consumer or free tier | Business tier with agreed terms | Enterprise tier with SSO and retention controls |
|---|---|---|---|---|
| Public | Published marketing copy, public documentation | Approved | Approved | Approved |
| Internal | Internal process notes, non-sensitive planning | Restricted: no names or figures | Approved | Approved |
| Confidential | Pricing, roadmaps, unreleased financials, source code | Blocked | Restricted: named uses only | Approved |
| Client or personal data | Client contracts, customer records, employee data | Blocked | Blocked unless a data processing agreement is in place | Approved where the contract and a data protection check allow it |
The table is a starting point; adjust the tiers to the contracts you hold. A customer contract may forbid sending its data to any sub-processor it has not approved, whatever tier the tool sits on.
Approved means anyone may use the tool for that data class. Restricted means named uses or named teams only. Blocked means the tool is removed or access is cut, and the person is pointed to the approved alternative on the same day.
A paved road is a short list of approved AI tools, set up so the safe choice is also the easy one. Each tool sits on a business or enterprise tier, signs in through SSO, has its retention and training settings checked, and is listed in the AI tool register. A fast lane answers requests for new tools quickly.
Staff turn to shadow AI when the approved route is slower than the unapproved one. The paved road reverses that. For each approved tool, we recommend checking four things before anyone uses it:
The fast lane is the other half. When someone finds a new tool, they submit a one-page request: the tool, the use, and the most sensitive data class it will touch. A named reviewer answers within a short, published time; we recommend 5 working days. A tool approved through the fast lane goes straight onto the AI tool register.
Without a fast lane, the paved road decays. People stop asking, and the shadow returns.
An AI usage policy needs one page, and it belongs inside your acceptable use policy rather than standing alone. It names the approved tools, states which data classes each may receive, explains how to request a new tool, and says what to do if client or personal data goes into an unapproved one.
Keeping the rules inside the acceptable use policy means staff read one document, not two that drift apart. In ISO/IEC 27001:2022 terms, this is the acceptable use control in Annex A (A.5.10), so it is an extension of rules you may already keep.
The page should cover six points:
A named owner matters more than the wording. Our piece on AI accountability sets out why AI governance fails without one.
An AI tool register is the single record of every AI tool approved for work, with its owner, tier, permitted data classes, vendor terms and review date. One AI tool register answers customer questionnaires, supports the documentation of AI resources that ISO/IEC 42001 expects, and records the AI literacy measures you take for staff who use each tool.
Keep the AI tool register small enough that someone updates it. A spreadsheet is enough at 25 to 100 people. For each tool, record:
The same entries map to the frameworks your customers ask about:
| Framework | What the register supports |
|---|---|
| ISO/IEC 42001 | The AI policy, the documented resources for AI systems, third-party relationships and staff awareness |
| ISO/IEC 27001:2022 | Acceptable use (A.5.10), supplier relationships (A.5.19) and use of cloud services (A.5.23) |
| UK GDPR | Processor and sub-processor duties when client personal data goes into a tool |
| EU AI Act Article 4 | A record of the AI literacy measures taken, where the firm is in scope |
UK GDPR is the row with legal teeth. If you process client personal data as a processor and paste it into an AI tool, you have brought that tool's vendor into the processing. Article 28(2) of the UK GDPR says a processor "shall not engage another processor without prior specific or general written authorisation" from the controller. Your client may never have authorised that vendor.
For the standard itself, see our ISO 42001 overview. For UK guidance, the government's Code of Practice for the Cyber Security of AI, published in January 2025, asks the organisations it covers to keep a comprehensive inventory of their assets and to include AI security content in staff training.
Article 4 of the EU AI Act applies to providers and deployers, and a firm whose staff use AI tools at work will normally be a deployer. The duty applies only where the firm is in scope. Since 27 July 2026, it has been a duty to take measures that support AI literacy, not to guarantee a level.
Who is a deployer. Article 3(4) of the EU AI Act defines a deployer as a person or organisation "using an AI system under its authority", except for purely personal, non-professional use. In our reading, staff using a chatbot for their work are using it under the firm's authority, whether or not the firm approved the tool.
Whether you are in scope. Article 2(1) covers deployers established or located in the EU, and deployers in a third country "where the output produced by the AI system is used in the Union". A UK firm with no EU presence is not automatically in scope. A UK firm with an EU office, or whose AI-assisted work is used by EU clients, should take advice on its position under the EU AI Act. Our EU AI Act overview covers the wider Act.
What the duty now says. The Digital Omnibus on AI, Regulation (EU) 2026/1744, amended Article 4. The amended text says providers and deployers "shall take measures to support the development of AI literacy of their staff" and others using AI on their behalf, and that the obligation "does not require providers or deployers to guarantee any specific level of AI literacy of any individual". National market surveillance authorities have supervised and enforced the duty since 2 August 2026.
In practice, Article 4 measures are proportionate. The European Commission's AI literacy questions and answers says staff using a chatbot for tasks such as translation "should be informed about the specific risks, for example hallucination", that "there is no need for a certificate", and that organisations can keep an internal record of training. The AI tool register is that record. Role-based training is covered in our guide to compliance training.
The AI tool register answers a questionnaire's AI section by giving you facts to copy rather than assurances to invent. When a customer asks which AI tools touch its data, whether vendors train on it, and how staff are trained, each answer is a column in the register, with the date it was last reviewed.
Questions like these map straight to something the AI tool register already holds:
A firm with a dated register answers in an afternoon. A firm without one answers from memory, and has to hope the memory is right.
For a supplier selling into regulated customers, that answer is part of the deal, not paperwork after it.
The most common mistakes are banning AI outright, approving a tool without checking its terms, forgetting AI features inside approved software, and letting the AI tool register go stale. Each one recreates the visibility gap the programme was meant to close, usually without anyone noticing until a customer or an incident asks the question.
An unreviewed register is not evidence. It is a record of what used to be true.
The main risks of shadow AI are data leaving the firm without a record, client or personal data reaching a vendor that no contract covers, and output that nobody checked going to customers. For a B2B supplier, the commercial risk is an AI question in a security questionnaire that the firm cannot answer with evidence.
We recommend against a blanket ban. Bans push AI use onto personal devices and accounts, where it is invisible. Approve a business tier with SSO and checked terms, block the consumer tier for confidential and client data, and give staff a fast way to request other tools.
Yes, if nobody reviewed them. An assistant added to an approved CRM or document editor can send data to a new model provider under new terms. Check supplier release notes and admin settings, decide whether each feature stays on, and record it in the AI tool register.
Treat it as a possible personal data breach, not a policy slip. Record what went in and when, check the tool's retention terms and delete what you can. If you handle that data as your client's processor, Article 33(2) of the UK GDPR requires you to notify the client without undue delay.
Only if it falls within the EU AI Act's scope: an establishment in the EU, or AI output used in the EU. Where it applies, Article 4 asks the firm to take measures that support staff AI literacy, not to guarantee a level. Check your own position before assuming either way.