Key takeaways
- Shadow AI is the use of any AI tool, feature, or agent inside your organization without governance oversight, and it now drives roughly one in five enterprise data breaches.
- Most coverage frames shadow AI as a cybersecurity story. It is at least as much a governance discovery story: you cannot register, risk-assess, or audit what you cannot see.
- Shadow AI, AI sprawl, and AI bill of materials are three distinct concepts that the security industry routinely conflates. Treat them separately or your governance program will not scale.
- The
EU AI Act,ISO/IEC 42001, and theNIST AI Risk Management Frameworkall share one unstated assumption: that you have a complete inventory of every AI system in scope. Shadow AI quietly invalidates that assumption. - The remedy is not a ban (those backfire) but a credible discovery program feeding a single AI registry that doubles as your
Annex VIIIregistration source and your ISO 42001 risk register.
What shadow AI actually means
Shadow AI is the use of any artificial intelligence tool, capability, or agent inside an organization without the formal awareness, approval, or oversight of the people accountable for governing AI: the CISO, the Data Protection Officer, the AI governance lead, the compliance function, or whoever holds that mandate in your operating model.
The phrase is often reduced to a narrower image: an employee pasting a confidential document into a free ChatGPT tab. That is one instance, but it is not the whole category. Shadow AI shows up in at least three flavors, and treating them as a single problem leads to incomplete controls.
Standalone consumer GenAI tools. Free or low-cost chatbots, image generators, code assistants, and meeting transcribers accessed directly through a browser or a personal account. The classic shadow AI surface, and the easiest one to detect through network telemetry.
AI features embedded inside approved SaaS. Your organization sanctioned the SaaS, but the vendor turned on a new AI feature mid-contract. Suddenly your CRM is summarizing customer notes with a foundation model, your collaboration suite is auto-drafting emails, and your project tool is suggesting risks. The procurement record says no AI was approved. Reality disagrees. As IBM observes in its shadow AI explainer, enterprise GenAI adoption climbed from 74 percent to 96 percent between 2023 and 2024, much of it through this embedded-feature path (IBM Think).
Internal models, scripts, and agents. A data analyst fine-tunes an open-source model on a laptop. A platform engineer wires an agent to a Model Context Protocol server with broad permissions. A marketing team trains a custom GPT on a sensitive corpus. None of these traverse the public internet to a third-party chatbot, so they evade traditional shadow-IT detection, yet they create the same governance gap.
The useful distinction with shadow IT is one of scope. Shadow IT covers any unsanctioned technology asset. Shadow AI is the AI-shaped subset, and it carries risks that traditional shadow IT does not: probabilistic outputs, hallucination, opaque training data, model drift, value-chain contamination, and a regulatory regime, the EU AI Act, that explicitly assigns responsibility for these characteristics.
That last point is what tips shadow AI from a security topic into a governance topic. Security teams have spent two decades catching unsanctioned SaaS. The novel work for the next two decades is governing AI you did not know you had.
Shadow AI vs AI sprawl vs AI bill of materials
Three adjacent concepts get used interchangeably in vendor blogs and analyst notes. They are not the same thing, and conflating them will produce a fuzzy governance program.
Shadow AI is unauthorized use. It is a property of governance posture: an AI system is in shadow when no one with accountability has logged its existence. A perfectly sanctioned tool used by an unapproved team is still shadow AI, because the governance trail is missing.
AI sprawl is uncontrolled multiplication, whether or not the systems are authorized. An organization with 80 sanctioned AI tools spread across 40 teams with no central catalog has sprawl, not shadow AI in the strict sense. Sprawl is what happens when discovery succeeds but consolidation does not.
AI bill of materials (sometimes shortened to AI BOM) is the documentation artifact, modeled loosely on software BOM. For a given AI system, the BOM lists components: the foundation model and version, the training and fine-tuning data sources, the retrieval databases, the third-party APIs invoked at inference time, and the human-in-the-loop checkpoints. AI BOM is not a problem; it is a deliverable, and it is the thing that makes shadow AI remediation auditable.
A mature program addresses all three: surface shadow AI through discovery, reduce sprawl through consolidation, and produce an AI BOM per system so the registry has substance instead of a name and an owner.
Why shadow AI is exploding now
The sociologist Marko Silic and colleagues frame shadow AI as a socio-technical governance failure rather than a security one, in a 2026 preprint that argues AI’s generative, opaque, and autonomous nature creates novel challenges that existing IT governance cannot absorb (Silic et al., Preprints.org). Their framing matches what enterprises see on the ground. Four forces compound.
Consumerization of GenAI. A free OpenAI account or a fifteen-dollar monthly subscription delivers capability that two years ago required a procurement cycle and a cloud bill. The friction that used to slow unsanctioned tooling has collapsed.
Embedded AI in approved SaaS. When a sanctioned vendor enables an AI feature by default, the legal contract has not changed but the data flow has. Most CISOs lack the contractual instrumentation to know when their fifth-largest SaaS provider quietly enabled retrieval-augmented generation against tenant data.
Agents and the MCP layer. Model Context Protocol servers and autonomous agents represent a new shadow surface that traditional secure-web-gateway products were not designed to inspect. An agent invoking an MCP server inherits that server’s permissions, which can exceed the invoking user’s direct access. Without dedicated visibility, the blast radius of an agent deployment is unknowable.
The IT-business velocity gap. Employees use shadow AI for the same reason they used shadow SaaS: because it works faster than the sanctioned path. As one Splunk explainer notes, banning consumer AI tools without offering an internal alternative simply pushes usage further underground (Splunk).
The quantitative picture is stark. Gartner predicts that by 2030, more than 40 percent of enterprises will have experienced a security or compliance incident tied to shadow AI (Gartner press release, Nov 2025). IBM’s 2025 Cost of a Data Breach report places the cost premium of shadow-AI-linked breaches at roughly USD 4.63 million versus USD 3.96 million for standard breaches, and finds that only 37 percent of organizations have any policy at all to manage or detect shadow AI (IBM Cost of a Data Breach 2025). One in five breaches now involves shadow AI as a contributing factor.
The direction is unambiguous. The strategic question is whether organizations treat the gap as a security problem to be plugged, or as a governance discipline to be built.
The governance risk: what shadow AI breaks
The security framing is intuitive: sensitive data leaves the perimeter, regulators fine you, customers churn. That story is real, and other articles tell it well. The governance framing is less told and more consequential. Three regulatory and standards regimes are converging, and all three rest on a single assumption that shadow AI invalidates.
EU AI Act registration mandate
Article 49 of the EU AI Act requires that providers of high-risk AI systems listed in Annex III register themselves and the system in the EU public database before the system is placed on the market or put into service. Public-authority deployers must register their use of those systems as well. The required content, set out in Annex VIII, includes provider identity, the AI system’s name and intended purpose, instructions for use, the conformity assessment certificate, status (on market, recalled, withdrawn), and impact assessment summaries (EU AI Act Article 49, Annex VIII).
The enforcement implication for shadow AI is direct. If a tool used inside the organization, sanctioned or not, falls within the Annex III high-risk categories (employment screening, credit scoring, biometric identification, critical infrastructure, education, law enforcement, migration, justice administration), then registration is a legal obligation, not a best practice. A shadow system that turns out to be Annex III is a missed registration, which is exactly the kind of factual nonconformity national market surveillance authorities will pursue.
Deployer obligations under Articles 26 and 27 compound the exposure. Deployers must follow vendor instructions for use, maintain logs, ensure human oversight, and, for public-sector or regulated-sector deployers in scope, perform a Fundamental Rights Impact Assessment. Shadow deployment silently breaks all four because the system was never on the inventory that would have triggered them.
This section is purely descriptive of the legal text. The point is not what readers should do about it. The point is that shadow AI converts a documentation obligation into a documentation failure without anyone noticing until an audit.
ISO/IEC 42001 Statement of Applicability
ISO/IEC 42001 Clause 6 requires the organization to identify AI-related risks and opportunities, treat them, and document the treatment in an AI risk register. Annex A defines a catalog of recommended controls, and the Statement of Applicability declares which controls are in or out, with justification for each exclusion.
Shadow AI breaks this structure twice. First, the risk register is incomplete by construction: a system you do not know about cannot have a documented risk treatment. Second, the Statement of Applicability claims that certain controls apply to certain systems. The moment a shadow system enters scope, those claims become inaccurate, and certified organizations face a nonconformity at re-audit.
The practical implication is that a 42001 certification is only as credible as the discovery program behind it. Organizations preparing for certification often discover, painfully, that the gap between their sanctioned AI list and the actual AI footprint is wider than the audit timeline can absorb.
NIST AI RMF MAP function
The NIST AI Risk Management Framework 1.0 organizes trustworthy AI activities into four functions: GOVERN, MAP, MEASURE, and MANAGE. GOVERN sets the policy and accountability baseline. MAP, the second function, requires what NIST calls contextual analysis: knowing each AI system’s purpose, owners, training data, deployment status, and integration points (NIST AI RMF).
Shadow AI defeats MAP at the foundation. You cannot characterize the context of a system you have not identified. The NIST AI 600-1 Generative AI Profile compounds this by listing twelve GenAI-specific risk categories (data privacy, information security, value chain, human-AI configuration, confabulation, harmful bias, and others) that all require system-level visibility to manage (NIST AI 600-1).
The OWASP AI Exchange, OWASP’s flagship AI security project since March 2025, makes the same point from a control catalog perspective: every AI threat and control assumes a known asset. Where the asset is shadow, the threat model defaults to silence (OWASP AI Exchange). CEN-CENELEC draft standards under development (prEN 18228 and prEN 18282) follow the same logic at the European harmonized-standards level.
Three frameworks, one unstated dependency: you have to know what AI you have.
How to actually discover shadow AI
Discovery has to be multi-layered because no single signal catches every flavor of shadow AI. The five layers below, run in combination, give a defensible coverage picture.
Layer 1: network and SaaS telemetry. DNS logs, secure web gateway data, cloud access security broker telemetry, and browser extensions reveal traffic to known consumer AI endpoints. This catches the classic ChatGPT-in-a-browser case. It misses everything that runs inside an approved SaaS or behind an enterprise IP.
Layer 2: identity layer audits. OAuth grant history, SSO logs, and consent-screen approvals show which third-party AI services have been granted access to corporate identity. This catches the AI services that piggyback on Google Workspace or Microsoft 365 identity. It misses fully air-gapped uses.
Layer 3: embedded AI feature audits inside approved SaaS. A direct conversation with each top-twenty SaaS vendor: which AI features are enabled by default, which are opt-in, what data flows where. This is unglamorous procurement work, but it surfaces the embedded-AI flavor that telemetry cannot.
Layer 4: amnesty and survey programs. A clearly communicated amnesty window where employees declare their AI usage without penalty. Combined with a short, honest survey, this produces qualitative discovery that no telemetry can match. The success condition is psychological safety, not tooling.
Layer 5: AI-aware data loss prevention. Prompt-level inspection inside approved channels, looking for sensitive data exfiltration patterns. This is the cybersecurity industry’s current investment focus and the layer most vendor blogs lead with. It is necessary but not sufficient on its own.
No organization gets to one hundred percent coverage. The realistic goal is a high enough sweep that the residual unknown is small, documented, and decreasing. The mistake is to over-invest in one layer and call it discovery.
From discovery to an AI registry
Discovery without a destination is a one-time spreadsheet that goes stale within a quarter. The destination is a central AI registry that holds every system the organization knows about, in a structure that satisfies regulators, standards bodies, and the internal risk function simultaneously.
What the registry has to capture per system:
- Identity: name, owner, business sponsor, technical sponsor
- Purpose: intended use, prohibited uses, in-scope user populations
- Data: classifications of inputs and outputs, training and fine-tuning data sources, retrieval databases
- Provider chain: foundation model and version, fine-tuning provider, hosting environment, third-party APIs invoked at inference
- Lifecycle status: pilot, production, retired; date placed in service
- Regulatory tier: EU AI Act risk classification, ISO 42001 Annex A applicability, NIST AI RMF profile match
- Residual risk: after controls, with the responsible accepter named
- Evidence: links to FRIA documents, conformity assessments, model cards, datasheets
The AI BOM section of each registry entry is what makes the system auditable. Model lineage, training data composition, retrieval indexes, and downstream API dependencies form a graph that an external auditor can verify against actual deployments.
Done right, the registry is the single source of truth that feeds three downstream artifacts: the Annex VIII submission packet when a system falls under EU AI Act registration, the ISO 42001 risk register and Statement of Applicability annexes, and the NIST AI RMF MAP outputs. Built in three separate spreadsheets, you get drift between them within weeks. Built once, with the right schema, you get governance leverage.
Bringing shadow AI into the light: a 60-day plan
The sequencing matters because discovery without enablement produces resentment and pushes shadow AI further underground.
Weeks 1 to 2. Announce an amnesty window. Communicate that the goal is to enable AI, not to ban it. Stand up the registry skeleton with a minimal schema. Capture baseline telemetry across all five discovery layers.
Weeks 3 to 4. Run the discovery sweep. Combine telemetry, identity audit, SaaS vendor outreach, and the amnesty survey. Expect surprises in the embedded-AI category.
Weeks 5 to 6. Triage each discovered system. Tier by regulatory exposure first, business criticality second. Identify any systems that map to Annex III of the EU AI Act, as those carry registration obligations regardless of the rest of the program’s maturity.
Weeks 7 to 8. Migrate the triage output into the registry. For each tier-one system, attach the AI BOM, the FRIA where applicable, the model card, the data classification. For lower tiers, capture identity and purpose and defer the deeper documentation to the next sprint.
Beyond day 60, the program becomes operational: new system intake replaces discovery, the registry feeds the regulatory and audit pipelines, and the next sprint focuses on the sprawl problem (consolidation, decommissioning, retirement).
The failure mode to watch is over-engineering. A perfect registry that no one updates is worth less than a rough registry that captures eighty percent of systems and gets refreshed quarterly. Start light, get inputs flowing, and let regulatory pressure shape the precision over time.
FAQ
What is shadow AI in simple terms? Shadow AI is the use of any AI tool, feature, or agent inside your organization that the people accountable for AI governance do not know about. It can be an employee using a free chatbot, an AI feature switched on inside an approved SaaS tool, or an internally built model running on a laptop. The common element is that the system is not on any inventory and is therefore unmanaged.
Is shadow AI the same as shadow IT? No. Shadow IT is the broader category of any unsanctioned technology asset. Shadow AI is the AI-shaped subset, and it carries distinct risks: probabilistic outputs, hallucination, opaque training data, model drift, and a dedicated regulatory regime in the EU. Shadow IT controls catch some shadow AI, but they miss the embedded-AI and internal-model flavors entirely.
How big is the shadow AI problem in 2026? Gartner forecasts that more than 40 percent of enterprises will face a shadow-AI-linked security or compliance incident by 2030. IBM’s 2025 breach report finds that shadow AI now contributes to about one in five enterprise breaches, and that those breaches cost on average USD 0.67 million more than standard breaches. Only 37 percent of organizations report having any policy in place to manage or detect shadow AI.
Does the EU AI Act force me to inventory shadow AI? The EU AI Act does not use the word “inventory” but its effect is the same. Article 49 requires registration of Annex III high-risk systems before they reach the market. Articles 26 and 27 impose deployer obligations (log retention, oversight, instructions for use, fundamental rights impact assessment for in-scope deployers) that cannot be satisfied without knowing which systems are in scope. A shadow system that turns out to be high-risk is, in practice, a compliance gap waiting to be enforced.
How does ISO 42001 treat shadow AI? Clause 6 of ISO/IEC 42001 requires an AI risk register. Annex A provides a catalog of controls, and the Statement of Applicability declares which controls apply to which systems. Shadow AI breaks both: the risk register is incomplete by construction, and the Statement of Applicability is inaccurate the moment a shadow system enters scope. This is why certification audits often start with a discovery exercise rather than a control review.
What is the difference between shadow AI and AI sprawl? Shadow AI is about authorization: a system is in shadow when governance does not know about it. AI sprawl is about multiplication: many AI systems, sanctioned or not, spreading across the organization with no central catalog. You can have sprawl without shadow (everything is logged, but there are eighty of them) and you can have shadow without sprawl (two unsanctioned tools, used widely). A mature program addresses both, and an AI bill of materials per system is the deliverable that ties them together.
What should an AI registry actually contain? At minimum: system identity and owner, purpose and in-scope users, data classifications, foundation model and version, third-party APIs at inference time, lifecycle status, regulatory tier, residual risk after controls, and links to supporting evidence (model card, datasheet, conformity assessment, fundamental rights impact assessment). Each entry doubles as the source for EU AI Act Annex VIII submission, the ISO 42001 risk register, and the NIST AI RMF MAP output.
Conclusion
Shadow AI will not yield to bans or to security tooling alone. It is a governance discovery problem disguised as a security one, and the organizations that treat it as such will spend the next two years building registries, AI bills of materials, and risk treatments that survive an audit. The ones that treat it as a perimeter problem will spend the same two years catching incidents. The deliverable is the same in both cases: a single, current, credible inventory of every AI system the organization runs. The question is whether you build it on your own schedule or under regulator pressure.