Glossary · 6 · Quality, risk and governance

Shadow AI

Also known as: Unsanctioned AI, Unapproved AI use, BYOAI (bring your own AI)

German: Schatten-KI

In AI governance, shadow AI is the work-related use of AI tools, models, accounts or AI-enabled features inside an organization without the approval, inventory or oversight of the responsible function — typically IT, security, data protection or a governance board. Vendor and security literature describes it as the AI-specific form of shadow IT: private ChatGPT or Claude accounts, free-tier assistants, AI note-takers, browser extensions and coding assistants used on company content. Because this work happens outside the governed tool chain, it leaves no record of which model saw which data, which weakens usage visibility, provenance records and data protection commitments. No standard or law defines the term; it is an industry label for a governance gap, not a legal category.

Intermediate
Technical writers
Technical marketers
Technical project managers
Developers

In one sentence

Shadow AI explained: unapproved AI tool use in organizations, why it breaks visibility and records, and how to govern it.

Example

A documentation team finds that three writers had been polishing release notes in private chatbot accounts, so the unreleased feature names never appeared in any approved-tool log — and the team adds an approved assistant plus a logged prompt library instead of a ban.

How it applies

Treat it as a visibility problem, not a discipline problem: IBM describes shadow AI as the unsanctioned use of AI tools or applications by employees or end users without the formal approval or oversight of the IT department. The usual driver is convenience — an approved path that is slower or weaker than the free one. Measuring and replacing that gap works better than announcing a prohibition nobody can enforce.
Know what it costs: IBM's Cost of a Data Breach Report 2025 reports that one in five studied organizations (20%) experienced breaches linked to shadow AI, with roughly USD 670,000 added to the average breach cost. Figures like these come from a vendor study with its own sample and method — useful for a business case, not a compliance statement.
Make the inventory the control: Governance frameworks assume you know which AI systems you run. The NIST AI Risk Management Framework's Govern function expects mechanisms for inventorying AI systems, and ISO/IEC 42001 sets requirements and guidance for an AI management system covering organizations that develop, provide or use AI systems. An inventory that lists only procured enterprise tools is incomplete by design.
Write a policy people can follow: An AI usage policy should name approved tools, the data classes that must never be pasted into any AI tool, and the request path for a new tool. Pair it with training: Article 4 of the EU AI Act (Regulation (EU) 2024/1689) obliges providers and deployers of AI systems to take measures for the AI literacy of their staff and others operating AI on their behalf. Naming the Act, a standard or this entry never establishes compliance by itself — only implemented and documented measures can.
Technical writers: Unapproved tools break traceability. If a draft passed through a private account, you cannot show which source version it was grounded in, whether hallucination was checked, or whether disclosure obligations under your AI content disclosure rules were met. Ask for an approved assistant with a shared prompt library rather than working around the gap.
Technical marketers: Free-tier image and copy generators often come with unclear training-data and rights terms, and customer lists or embargoed launch material pasted into them may leave the organization's control. Clear rights and terms before a campaign, not after.
Technical project managers: Add tool discovery to onboarding and to the risk register, run a light approval process with service-level expectations, and record who owns each AI-assisted deliverable — see Accountability (AI). Where personal data is involved, coordinate with your data protection function; see Data privacy in AI tools.
Developers: Shadow AI in engineering shows up as unmanaged API keys, personal accounts in an IDE, unreviewed AI coding assistant output and self-hosted models or MCP servers nobody registered. Route calls through a managed gateway, log model, version and prompt metadata, and keep secrets out of prompts.
Usage tracking as governance, not surveillance: Record tool, model and version at the artifact level rather than keystrokes at the person level. Aggregate, purposeful logging gives you provenance and an audit trail; monitoring individuals invites the workarounds that create shadow AI in the first place.

Shadow AI vs. shadow IT

Shadow IT is the older, broader concept: NIST's mobile device security guidance (SP 800-124 Rev. 2) describes shadow IT as staff members' work-related use of IT hardware, software or cloud services without the knowledge of the organization's IT department. Shadow AI is the subset in which the unsanctioned service is an AI system — and the risk profile shifts. A rogue file-sharing app mainly stores data; a chatbot may retain inputs, use them to improve a service, surface them in outputs, and act through tools and agents. Shadow IT questions are mostly about access and storage; shadow AI questions add provenance, disclosure, model behavior and the duty to explain an output.

In one sentence

Example

How it applies

Shadow AI vs. shadow IT

External references