Shadow AI: How to Find, Assess and Govern Unsanctioned AI Use in Your Organisation

Every organisation now has an AI policy, whether or not it has written one down. If the approved route to a useful tool is slow or missing, staff find their own: a personal chatbot account to tidy up a client email, a browser extension that summarises meetings, a free transcription service, a code assistant on a developer's laptop. None of this is malicious. Most of it is people trying to work faster. But each of those tools is a data flow you did not design, cannot see and may not be able to explain to a customer or the ICO.

That is shadow AI. This article explains how to find it, how to decide which uses matter, and how to bring the useful ones under control without driving the rest further underground.

Why shadow AI is different from ordinary shadow IT

Unsanctioned software has always existed. AI tools raise the stakes in three ways.

• The input is the risk. With most SaaS tools the danger is what you store in them. With generative AI the danger is often what one person pastes into a prompt in a single moment: a customer list, a contract, source code, a patient letter.
• Terms vary widely. Consumer tiers of AI services may retain prompts, use them to improve models or allow human review. Business tiers of the same product often do not. Staff rarely know which tier they are using.
• AI is embedded everywhere. AI features now arrive inside tools you already approved, through updates, plug-ins and browser extensions. Your approved software list can be accurate on Monday and out of date by Friday.

Step 1: Discover what is actually in use

Discovery should combine technical evidence with simply asking people. Neither is complete on its own.

Technical sources

• DNS, proxy and secure web gateway logs: look for traffic to known AI service domains and API endpoints. Volume and user counts matter more than single hits.
• Identity provider logs: OAuth consents and "sign in with Microsoft/Google" grants to AI applications show which tools have been connected to corporate accounts, and with what permissions.
• Endpoint and browser management: inventory browser extensions and desktop apps. Meeting assistants and writing tools often arrive this way.
• Expense and card data: small monthly subscriptions to AI services are a reliable indicator of a team that has found something useful.
• Code repositories and CI pipelines: API keys for AI providers in code or configuration indicate integrations that were never reviewed.

Asking people

Run a short, amnesty-style survey: which AI tools do you use, for what tasks, and with what kind of data? Make it clear that the aim is to provide safe tools, not to discipline anyone. You will learn which use cases are valuable, which is exactly what you need to design approved alternatives.

Step 2: Build an AI inventory that is useful, not exhaustive

Record each tool with enough detail to make a decision:

• Tool and vendor, and whether it is a consumer or business tier.
• Who uses it and for which tasks.
• What categories of data go in (public, internal, personal data, special category data, client confidential, source code).
• Whether the vendor retains prompts or uses them for training, where data is processed, and whether a contract or data processing agreement exists.
• Whether it can take actions (send email, edit files, call APIs) or only produces text.

The NCSC's guidelines for secure AI system development put inventory and asset tracking at the start of secure deployment, and the same thinking underpins the UK AI Cyber Security Code of Practice. If you are aiming for ISO/IEC 42001, this inventory becomes the foundation of your AI management system scope.

Step 3: Assess the data risk properly

For tools that handle personal data, UK GDPR applies in the ordinary way. You need a lawful basis, transparency, appropriate security and, where processing is likely to be high risk, a data protection impact assessment. The ICO's guidance on AI and data protection is clear that using AI does not change these obligations; it often makes them harder to meet.

The practical questions to answer for each significant use are:

• Is the vendor acting as your processor under a contract, or as an independent controller of the prompts?
• Where is the data processed and stored, and is any international transfer covered?
• Can you delete prompts and outputs, and can you respond to a subject access request that touches them?
• What would a breach look like, and would you even know it had happened?

Where the honest answer is "we cannot control what goes in", technical redaction is the usual fix. Stripping identifiers from prompts before they leave your boundary means a tool can still be used for drafting and analysis without the personal data. Our article on tokenisation, encryption and pseudonymisation under UK GDPR explains the options.

Step 4: Govern by offering a better path

Blanket bans are tempting and usually fail. They remove visibility while leaving the demand in place. A more durable approach has four parts.

1. Provide approved tools for the common tasks identified in your survey, on business terms, with single sign-on so access is tied to employment.
2. Publish a one-page AI acceptable use statement that tells people what data may and may not go into which tools, how to check AI output before relying on it, and how to request a new tool.
3. Block or restrict the highest-risk categories technically, for example consumer AI services for users who handle special category data, or unreviewed browser extensions.
4. Monitor and repeat. Re-run discovery quarterly. New tools and new AI features in existing tools appear constantly.

If your organisation trades with EU customers or deploys AI that affects EU residents, it is worth knowing that the EU AI Act has applied an AI literacy expectation since February 2025; the 2026 Omnibus softened the company duty, but customers still ask how staff are trained. Our EU AI Act guide for UK businesses covers when the Act reaches UK firms.

Where Microsoft 365 Copilot fits

For many organisations the approved alternative is an enterprise assistant such as Microsoft 365 Copilot. That is a sensible route, but it brings its own risk: Copilot makes your existing permissions far more discoverable. Before you present it as the safe option, read our Microsoft 365 Copilot security review checklist.

How Pyralink helps

For the cloud accounts those tools run in, PyraLink™ Prove collects read-only configuration evidence. To talk about shadow AI risk, contact Pyralink.

Frequently asked questions

What is shadow AI?

Shadow AI is the use of AI tools, features or integrations that the organisation has not approved or assessed, such as personal chatbot accounts, AI browser extensions, meeting assistants or AI API keys embedded in code.

Should we ban public AI tools?

Bans tend to reduce visibility rather than use. A more effective approach is to provide approved tools for common tasks, publish a short acceptable use statement, and technically restrict the highest-risk combinations of tool and data.

How do we find out which AI tools staff are using?

Combine DNS, proxy and identity provider logs, browser extension inventories, expense data and code repository scans with a short, no-blame staff survey. Each source catches tools the others miss.

Does UK GDPR apply to prompts sent to AI tools?

Yes. If a prompt contains personal data, sending it to an AI service is processing under UK GDPR. You need a lawful basis, appropriate security and suitable contractual terms with the provider, and may need a DPIA.

Sources: NCSC: Guidelines for secure AI system development; ICO: Guidance on AI and data protection; DSIT: AI Cyber Security Code of Practice; ISO/IEC 42001:2023 Artificial intelligence management system; European Commission: AI Act regulatory framework.