BlogShadow AI: Governing the Tools Your Team Already Uses
AI Governance

Shadow AI: Governing the Tools Your Team Already Uses

How UK B2B firms find the AI tools staff already use, triage them by data, and keep one register that answers customers.

Harry WestFounder & CEO25 March 202613 min read
Inside This Article
What is shadow AI?How is shadow AI different from shadow IT?How do you find the AI tools your staff already use?How should you triage the AI tools you find?What does a paved road for AI tools look like?What belongs in an AI usage policy?What should an AI tool register record?Does EU AI Act Article 4 apply to shadow AI?How does the register answer customer questionnaire AI questions?What are the most common mistakes in governing shadow AI?Frequently asked questions
Book a discovery call

Key takeaways

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.

Deployer
Under Article 3(4) of the EU AI Act, a deployer is a person or organisation using an AI system under its authority, other than for personal non-professional use.
Article 4 AI literacy
Regulation (EU) 2026/1744 amended Article 4 from 27 July 2026: providers and deployers in scope must take measures to support staff AI literacy, without guaranteeing any individual's level.
Supervision date
The Commission says supervision and enforcement of the AI literacy duty apply from 2 August 2026, no certificate is needed, and organisations can keep an internal record of training.
Sub-processor authorisation
Article 28(2) of the UK GDPR says a processor must not engage another processor without the controller's prior specific or general written authorisation.

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.

What is shadow AI?

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.

How is shadow AI different from shadow 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:

  • AI features inside approved software. A supplier's update can add an assistant to your CRM, document editor or support desk. The tool on your approved list is the same; what it does with your data is not.
  • Prompts as data egress. Pasting a client contract into a chatbot is a data transfer. No file leaves your systems, so the controls built for files often miss it.
  • Training and retention terms. Free and consumer tiers can carry different terms from business tiers. Whether the vendor keeps your prompts, and for how long, is set in terms most staff never read.

The ways AI systems themselves are attacked, such as prompt injection, are a separate subject, and our AI security risks guide covers them.

How do you find the AI tools your staff already use?

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:

  1. SSO and OAuth app grants. Your identity provider lists every third-party app a user has authorised with a work account. AI note-takers, writing assistants and calendar tools show up here, along with the permissions each one holds.
  2. Expense and card data. Search for AI subscriptions claimed on expenses or company cards. A personal plan expensed by three people is a business need you have not met.
  3. Browser extension inventory. If you manage browsers centrally, export the extension list. Depending on their permissions, AI extensions can read every page a user opens, which can expose more than a chatbot tab.
  4. DNS or proxy logs, where they exist. Traffic to known AI services shows volume and which teams use them. Treat it as a pointer, not proof of what data was sent.
  5. Ask, with an amnesty. A short survey asking which AI tools people use for work, and what for, finds what the logs miss. Promise that disclosure this round carries no penalty, and keep that promise.

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.

How should you triage the AI tools you find?

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 classExampleConsumer or free tierBusiness tier with agreed termsEnterprise tier with SSO and retention controls
PublicPublished marketing copy, public documentationApprovedApprovedApproved
InternalInternal process notes, non-sensitive planningRestricted: no names or figuresApprovedApproved
ConfidentialPricing, roadmaps, unreleased financials, source codeBlockedRestricted: named uses onlyApproved
Client or personal dataClient contracts, customer records, employee dataBlockedBlocked unless a data processing agreement is in placeApproved 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.

TEMPLATE

Acceptable Use Policy

Staff rules for ISO 27001 A.5.10, covering hybrid working, personal devices, messaging and AI tools.

AvailableWORD12 pages
  • Acceptable use policy: devices, hybrid working, messaging, AI tools and monitoring
  • Appendices: approved tools register, acknowledgement form, one-page staff summary
  • Getting-started guide and next steps
  • Policy management checklist: approval, staff acceptance and reviews

POL-ISO27001-02 · v1.0

We'll use your details to give you access to the resource you requested, plus occasional related content. Opt out any time — see our Privacy Notice.

What does a paved road for AI tools look like?

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:

  • Contract tier. A business or enterprise tier whose terms say how your inputs are used, including whether they train the vendor's models.
  • Single sign-on. Accounts tied to your identity provider, so leavers lose access the day they go.
  • Retention settings. Prompt and output retention set to the shortest period your work allows, with the setting recorded.
  • Data processing terms. A data processing agreement where client or personal data may go in.

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.

What belongs in an AI usage policy?

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:

  1. The approved tools, by name and tier, with a pointer to the AI tool register.
  2. The data classes, with one example of each.
  3. What each tier may receive, taken from the triage table.
  4. How to request a new tool through the fast lane.
  5. What to do after a mistake: report it the same day, with no penalty for prompt reporting.
  6. Who owns the policy and when it is reviewed.

A named owner matters more than the wording. Our piece on AI accountability sets out why AI governance fails without one.

What should an AI tool register record?

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:

  • tool name, vendor and contract tier;
  • business owner and approved uses;
  • the highest data class permitted;
  • whether the vendor trains on your inputs, and the retention setting;
  • whether client or personal data goes in, and the data processing agreement that covers it;
  • the guidance or training staff received before using it;
  • the date approved and the next review date.

The same entries map to the frameworks your customers ask about:

FrameworkWhat the register supports
ISO/IEC 42001The AI policy, the documented resources for AI systems, third-party relationships and staff awareness
ISO/IEC 27001:2022Acceptable use (A.5.10), supplier relationships (A.5.19) and use of cloud services (A.5.23)
UK GDPRProcessor and sub-processor duties when client personal data goes into a tool
EU AI Act Article 4A 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.

Does EU AI Act Article 4 apply to shadow AI?

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.

How does the register answer customer questionnaire AI questions?

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:

  • "Which AI tools process our data?" Filter the AI tool register by the client or personal data class.
  • "Are any of them sub-processors?" The data processing agreement column shows which vendors are, and your sub-processor list should match.
  • "Do vendors train models on our data?" The training and retention column answers it, tool by tool.
  • "How do you control staff use of AI?" Point to the AI usage policy, the triage rules and the fast lane.
  • "How are staff trained?" The guidance and training column, plus the AI literacy record.

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.

What are the most common mistakes in governing shadow AI?

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.

  • Banning instead of channelling. A blanket ban without an approved alternative moves AI use onto personal phones and accounts, where you cannot see it at all.
  • Approving the brand, not the tier. The same product can carry different data terms on its free and business tiers. Approval belongs to the tier and its settings.
  • Missing embedded AI. The approved list stays the same while suppliers add assistants to it. Review release notes and admin settings at each AI tool register review.
  • A register with no review date. AI vendors update their terms and features. A register checked once a year describes last year's tools.
  • Treating training as a slide. Article 4 asks for measures suited to staff and context. One generic session does not tell a sales team what not to paste.

An unreviewed register is not evidence. It is a record of what used to be true.

Frequently asked questions

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.

Profile image for Harry West, Founder and CEO of GRCMANA
Author

Harry West

Harry is the founder of GRCMANA, he helps regulated service providers close the enterprise trust gap — turning GRC, cyber resilience and AI governance from paperwork exercises into shippable systems.

GRCMANA
  • About
  • Insights
  • Contact
Ask the Trust ArchitectBook a Call →
  • About
  • Insights
  • The Vault
    Compliance VaultCyber Essentials→ISO 27001→SOC 2→ISO 42001→
    Domain VaultGRC Fundamentals→Risk Management→AI Governance→GRC Engineering→
    Other ResourcesFree Tools→Templates→Newsletter→
  • Contact
Book a Call →Ask the Trust ArchitectFixed fee. ISO 27001 in as few as six weeks.
GRCMANA

Helping high-growth B2B tech startups close the Enterprise Trust Gap through security, governance, and AI resilience.

ISO 27001ISO 42001ISO 9001Cyber EssentialsEU AI Act ReadyNIST AI RMF

The Vault

GRC EngineeringAI GovernanceISO 27001ISO 42001All Vault Resources

Resources

BlogFree ToolsTemplatesNewsletter

Company

About GRCMANAContactPrivacy PolicyTerms & ConditionsCookie Policy
© 2025 GRCMANA · All rights reservedRegistered in England & Wales under company registration 16810805. VAT Registration 506308024