How to Detect Shadow AI in Your Organisation

Your employees are using AI tools you have never approved. That is not an accusation — it is a statistical near-certainty. A 2024 survey by Salesforce found that more than 55% of employees use AI tools that their employers have not officially sanctioned. "Shadow AI" — a term the EU AI Act does not use, but operations and compliance teams use constantly — refers to AI systems running inside an organisation without IT awareness, procurement approval, or governance coverage.

That gap matters under Regulation (EU) 2024/1689. An undiscovered AI system is still subject to the Act. If it turns out to be prohibited under Article 5, your organisation has been exposed since 2 February 2025 — the date those prohibitions became enforceable. If it is high-risk under Article 6 and Annex III, you have an unmet documentation, risk management, and human-oversight obligation that no one is working on. Detection is therefore not an IT hygiene task; it is the prerequisite for compliance.

This page covers how to find unsanctioned AI. For the governance and policy response — what to do once you have found it — see the shadow AI policy guide.

Why Discovery Is Harder Than It Looks

Most shadow AI does not arrive as a rogue server in the basement. It arrives as a browser extension a developer installed last Tuesday, a CRM module that quietly received an "AI-powered suggestions" update, or a subscription an account manager expenses to a company card. The problem has three distinct shapes:

Standalone SaaS tools. ChatGPT, Midjourney, Perplexity, or any of the dozens of AI-writing and -coding assistants employees access from a browser. No installation, no IT ticket, no visibility.

Embedded AI features in existing tools. Your HR suite, CRM, or document management product may have rolled out AI-assisted drafting, screening, or scoring as a default feature. These are easy to miss because the vendor is already in your approved stack — the AI addition comes silently through a product update.

Built-in-house experiments. A developer calling the OpenAI API or hooking into an open-source model to speed up a workflow. No deployment, no review, no registration.

Each route requires a different detection technique.

Detection Method 1 — Network and DNS Monitoring

The most reliable technical signal is egress traffic. AI SaaS platforms expose identifiable hostnames: api.openai.com, generativelanguage.googleapis.com, api.anthropic.com, api.mistral.ai, api.cohere.com and dozens of others. DNS query logs or firewall egress records will show whether your estate is calling them.

Build or update a blocklist/allowlist of known AI API endpoints and consumer-facing AI product domains. Any outbound connection to an unlisted AI endpoint is a candidate for investigation. Your SIEM or DNS security tool can alert on new entries. This catches direct API use and most browser-based SaaS access where the tool makes back-end calls. It does not catch local models running entirely on-device — those produce no egress.

The data-leakage angle here is significant independent of the EU AI Act. If employees are pasting customer records or contract text into a consumer AI service, that data is leaving your perimeter. GDPR Article 28 requires a data-processing agreement with every sub-processor; a consumer AI tool accessed ad hoc almost certainly lacks one.

Detection Method 2 — CASB and SaaS Management Tools

Cloud Access Security Broker (CASB) platforms and dedicated SaaS-management products (Torii, Zylo, BetterCloud, and similar) inspect OAuth grants, browser-extension permissions, and SSO activity logs to enumerate every third-party application a user has authorised. Run an export — it will typically reveal forty to a hundred applications no one formally approved, a significant fraction of which will be AI tools.

SSO logs are especially useful: if employees sign into AI services using "Sign in with Google" or "Sign in with Microsoft," those authorisation events appear in your identity provider's audit trail. Google Workspace and Azure AD both expose OAuth app inventories in their admin consoles. A monthly review of newly-authorised third-party apps should be a standing procedure.

Detection Method 3 — Expense and Procurement Signals

Consumer AI subscriptions cost £18–30 per month, which falls well below most procurement thresholds. Employees pay personally and expense through T&E, or charge to virtual company cards. A review of expense categories and card transactions for subscriptions to AI product domains will surface individual-use subscriptions that never touched a procurement workflow.

This works best run as a one-time targeted audit rather than a continuous process. Pull three to six months of T&E data, search for known AI vendor names (OpenAI, Anthropic, Midjourney, Runway, ElevenLabs, and others), and you have a list to investigate. Any recurring payment to an AI product is evidence of use.

Detection Method 4 — Endpoint and DLP Telemetry

Endpoint Detection and Response (EDR) tools log process activity, browser extension installs, and in some configurations clipboard or file-transfer events. A review of recently installed browser extensions across your estate will typically find AI assistant extensions that were not approved.

Data Loss Prevention tools configured to monitor outbound content (email, clipboard, uploads) can detect patterns consistent with AI prompting — large text pastes followed by smaller returns — or can be tuned to flag uploads to AI-associated domains. This gives you both a discovery signal and an early warning on data-exfiltration risk.

Detection Method 5 — Staff Surveys and Amnesty Programmes

Technical controls have gaps. A confidential survey asking employees what AI tools they use — with an explicit assurance that honest answers are not grounds for disciplinary action — reliably surfaces tools that do not appear in network logs. Employees using on-device models, AI built into approved tools they did not think to flag, or experimental code they are not proud of will often self-disclose if the process feels safe.

An amnesty programme is the stronger version: a time-limited window during which employees can register AI tool use without consequence, in exchange for the organisation capturing what they know. Frame it as "help us build the inventory so we can support you properly." The shadow-AI-policy page sets out the governance structure to back this up.

The "AI Inside" Problem — Embedded Features in Approved Tools

This category is frequently overlooked. Microsoft Copilot is now enabled by default in many M365 tenants. Salesforce Einstein is active in most Sales Cloud instances. Workday has rolled out AI-assisted candidate screening. LinkedIn Recruiter uses AI scoring. Your approved stack may already contain AI systems you have not reviewed.

Run a systematic audit of your ten to fifteen most-used business applications. For each, check the vendor's release notes or admin settings for AI features added in the past eighteen months. Ask: what does this feature do, what data does it process, and what decisions does it influence? A Workday AI feature that influences candidate screening is potentially high-risk under Annex III point 4(a) of the EU AI Act regardless of whether you sought it out — you are using it, which makes you a deployer under Article 26.

Turning Discovery into Compliance: The Required Steps

Finding an unsanctioned AI system is not the end of the process. Every discovered system must complete three steps.

Step 1 — Enter the AI inventory. Article 26 implies that deployers must be aware of the systems they use. An organisation-wide AI register is the foundation. Log the tool name, vendor, business unit, use case, and data processed.

Step 2 — Classify it. Apply Article 5 first: does this system do anything the Act prohibits? Emotion recognition used to monitor employees in the workplace is prohibited under Article 5(1)(f), in force since 2 February 2025 — regardless of whether you knew about it. Then apply Article 6 and Annex III: does the use case fall into one of the eight high-risk categories? Recruitment screening, creditworthiness assessment, biometric identification, and law-enforcement support are among the Annex III triggers. If the use does not reach high-risk, classify it as limited-risk (Article 50, if customer-facing generative AI is involved) or minimal.

Step 3 — Assign an owner and a deadline. A high-risk system with no named responsible person is still a compliance gap. Assign the tool to an owner who will follow up with the vendor's conformity documentation, assess whether a Fundamental Rights Impact Assessment is required under Article 27, and confirm that human oversight under Article 14 is in place.

The penalty exposure is real. An unassessed high-risk system carries up to €15 million or 3% of worldwide annual turnover (Article 99(4)). Shadow use of a prohibited practice — even inadvertent — sits in the top tier: €35 million or 7% (Article 99(3)). For companies with fewer than 250 employees, the SME proportionality cap in Article 99(6) applies the lower of the percentage or the fixed sum, which provides some relief — but not a free pass.

Article 4, on AI literacy, has been in force since 2 February 2025. It requires organisations to ensure that staff deploying or overseeing AI have sufficient understanding of the systems they use. A discovery exercise that reveals widespread unsanctioned use is also a signal that your Article 4 literacy programme needs to reach the people actually using these tools.

How Confir Helps

Once you have run a discovery exercise and have a list of systems to process, Confir's rule-based classification engine lets you register each one and work through Article 5 and Article 6 / Annex III in a plain-English intake. The same intake derives your role (provider or deployer), scopes the exact obligation set, and flags whether a FRIA under Article 27 is required. The output is an AI register entry with a classification rationale that is reproducible and audit-defensible — not a black-box score, but explicit logic tied to specific articles.

For companies working through a backlog of newly discovered tools, being able to classify ten systems in a single session, each with a documented finding, is the difference between a compliant inventory and a spreadsheet that no one trusts.

Frequently Asked Questions

Is "shadow AI" a legal term under the EU AI Act?

No. "Shadow AI" does not appear in Regulation (EU) 2024/1689 or in any official guidance. It is an operational risk management term describing AI use that falls outside organisational governance and IT oversight. The Act's obligations apply to the AI systems themselves — a system operating without your knowledge is still subject to the Act if you are using it.

Does the EU AI Act require organisations to find all AI they use?

Not in those explicit terms, but the obligations imply it. Article 26 requires deployers to use AI systems in accordance with the instructions of use, implement human oversight (Article 14), and monitor performance. You cannot meet those obligations for systems you do not know exist. Article 4 requires sufficient AI literacy among staff involved in AI use. An organisation that discovers a prohibited system operating in its environment and took no steps to find it faces the full penalty exposure from the date the prohibition came into force (2 February 2025).

Which discovery method finds the most shadow AI?

In practice, a combination of network/DNS monitoring and expense/procurement audit covers the majority of cases, because most shadow AI is SaaS-based and involves some form of payment. Staff surveys consistently surface tools that technical controls miss — particularly on-device models and AI embedded in approved tools that employees did not think to flag. Running at least two methods gives substantially better coverage than any single approach.

What if a discovered tool turns out to be prohibited under Article 5?

Stop using it and document when use began and what data it processed. Article 5 prohibitions have been in force since 2 February 2025. If the system processed employee data in a way that constitutes prohibited workplace emotion recognition (Article 5(1)(f)), you have a concurrent GDPR exposure to assess under GDPR Article 35 (DPIA). Seek legal advice before making any disclosure, but do not continue operating a prohibited system while you decide what to do.

What about AI features added by a software vendor without notice?

You are still a deployer under Article 26. The fact that the feature arrived in a product update does not transfer the deployer obligation to the vendor. Review your vendor contracts: Article 26 requires providers to give deployers instructions for use; a vendor that activates AI features silently may not be meeting that obligation. Flag it, classify the feature's use case, and — if it is high-risk — require the vendor to provide its conformity documentation under Article 13.

Does discovering a high-risk system automatically mean we are non-compliant?

Not automatically. Article 6(3) provides a filter: a system falling in an Annex III area is not high-risk if it does not pose a significant risk of harm — for example, if it performs a narrow procedural task without influencing human decisions. Assess the actual use, document your reasoning, and if the filter applies, register the assessment. If the system is genuinely high-risk and has been operating without the required oversight and documentation, that is a gap you need to close — the Digital Omnibus agreed in May 2026 pushes the high-risk compliance deadline for Annex III stand-alone systems to 2 December 2027, which gives you time to remediate properly rather than panic-patch.

Related guides

• Article 6 high-risk classification
• compliance checklist for Articles 6–29
• EU AI Act explained simply
• Article 6 risk classification tool
• risk classification levels guide
• Article 5 biometric prohibition requirements