Shadow AI: Find It, Inventory It, Build a Risk Register

Key takeaways

• Shadow AI is any AI tool, model, or agent used without formal approval, inventory, or a named owner, and it lands in your risk register as an unassessed use case.
• Four discovery signals cover most shadow AI: SSO telemetry, CASB or firewall logs, procurement and expense review, and AI spend analysis.
• AI spend analysis is the fastest audit-ready starting point because every unmatched charge produces a named owner and a dollar figure.
• Every inventory entry needs a use case description, named owner, risk tier, review date, data classification, and control mapping.
• Discovery and inventory must come before policy, because you cannot classify or govern AI systems you have not found.

Shadow AI is any AI tool or use case adopted inside your organization without IT review, a named owner, or a place in your risk register, from an underwriter pasting policyholder data into a public chatbot to a department spinning up an unsanctioned AI agent. Left undiscovered, it creates unassessed risk that surfaces in audits, incidents, and regulator questions. This guide walks through a step-by-step discovery and inventory workflow, then gives you a reusable AI risk assessment template structure with named owners, risk tiers, and review dates.

What is shadow AI and what does it mean for your organization?

Shadow AI is any AI tool, model, or agent used inside your organization without formal approval, inventory, or a named owner: the marketing analyst pasting patient data into a public chatbot, or the vendor's "AI assistant" enabled inside a SaaS product nobody risk-reviewed. It is the AI equivalent of shadow IT, and it lands in your risk register as an unassessed use case. For a regulated organization, the problem is accountability. Under the EU AI Act's risk-based approach, high-risk systems carry documentation, monitoring, and human oversight obligations (European Commission, AI Act overview), and an auditor will ask which AI systems you operate, who owns each one, and when it was last reviewed. If your answer lives in someone's browser history rather than an inventory with risk tiers and review dates, you cannot evidence compliance. Shadow AI discovery turns that unknown into a manageable list.

What is an example of shadow AI in a real workplace?

Shadow AI rarely looks dramatic. It shows up as an employee pasting a donor list into a free chatbot, or a department adopting a SaaS tool whose "smart features" nobody evaluated.

The four common shadow AI patterns -Employee chatbot use - Drafting emails with a free LLM account, pasting in client or patient text - No procurement, no vendor file, no log -Browser AI extensions - A Chrome extension that summarizes pages or writes replies, with broad read permissions - Installed without IT approval -Unsanctioned AI agents - Someone builds an automation or agent that queries internal systems on a schedule - Looks like a script, not an AI system -Embedded AI in vendor SaaS - Your existing CRM or helpdesk ships a new AI summarization feature, on by default - The vendor was approved before the feature existed

The fourth pattern is the one most organizations miss. The vendor is in your risk register, but the AI feature is not, so it never gets an owner, a risk tier, or a review date. Each of these four patterns should become a line in your AI use case inventory, which is what the discovery and inventory steps in later sections cover.

How do you discover shadow AI tools employees are already using?

Discovery signals and where to find them

Four signal sources cover most shadow AI. SSO telemetry shows unsanctioned logins and browser extensions authenticated through your identity provider. CASB or firewall logs reveal traffic to AI endpoints, including tools employees access without SSO. Procurement and expense review catches subscriptions billed on corporate cards or submitted for reimbursement. AI spend analysis, the fourth signal, is the one most teams skip.

What AI spend analysis reveals

Expense data is the fastest audit-ready starting point because it produces a named owner for every finding: whoever's card or cost center paid the invoice. Pull twelve months of card transactions and expense reports, search for AI vendor names and categories like "software as a service" and "productivity tools," then reconcile the results against your approved vendor list. Every unmatched charge is a shadow AI use case with a dollar figure attached, which is exactly the evidence format auditors and boards respond to. Pair each finding with the network and SSO signals above to estimate how many employees actually use the tool, not just who paid for it.

That reconciliation step, spend data cross-checked against actual usage logs, is what turns a list of invoices into a defensible AI inventory with named owners, risk tiers, and review dates rather than a spreadsheet nobody trusts. NIST's AI Risk Management Framework calls this mapping: documenting the context, users, and deployment of AI systems before you can measure or manage risk.

How do you build an AI use case inventory from discovery findings?

Discovery gives you raw signals: browser extensions, SSO logs, expense line items, and the tools employees self-report. An inventory turns those signals into audit-ready records. The difference matters when your auditor asks who approved a use case, when it was last reviewed, and what risk tier it carries.

The minimum fields your inventory needs

Each entry should capture:

• Use case description: what the tool actually does, in the employee's words, not the vendor's
• Named owner: a person, not a department, accountable for the use case
• Risk tier: your own classification, applied consistently (a drafting assistant and a tool touching PHI should not land in the same tier)
• Review date: when the entry is next reassessed, so the inventory stays current instead of fossilizing
• Data classification: what information flows into the tool
• Control mapping: which ISO 27001, NIST CSF, or NCSC CAF controls cover this use case, so cross-framework reporting comes from one record

Deduplicate aggressively. Five teams using the same transcription tool is one use case with five stakeholders, not five rows.

Honest limitation: discovery tools surface tools, not intent. Expect a manual pass where you interview owners to confirm what each use case really does before you assign tiers. Budget for that; it is where most of the effort goes.

How should you run an AI risk assessment on discovered shadow AI use cases?

Treat each discovered use case as a risk register entry, not a ticket. Score it once, assign a named owner, and set a review date. The structure below is deliberately plain so it can live in a spreadsheet or a system of record without losing anything in translation.

AI risk assessment template: the fields that survive an audit

• Use case description: what the tool does, in the employee's own words.
• Named owner: a person, not a department.
• Data sensitivity: what inputs go in, and whether they include PHI, PII, or donor data.
• Likelihood and impact: scored on your existing risk scale, so AI entries sit beside every other register entry.
• Risk tier: high, medium, or low, with tier criteria written down before you score anything.
• Required controls and review date: what must change before wider use, and when the entry is re-scored.

The pattern here mirrors mainstream governance practice, where AI systems are treated as governed assets with owners, permissions, and lineage. The honest caveat: a template does not discover anything, and it does not enforce review dates. If nobody is accountable for re-scoring high-tier entries, your risk register decays into the spreadsheet problem you were trying to escape.

How does shadow AI discovery support EU AI Act compliance?

The EU AI Act sorts AI systems into risk tiers, and Articles 9 through 15 attach documentation, logging, and human-oversight duties to the high-risk ones. You cannot classify what you have not found: discovery gives you the inventory, and each inventoried use case gets a classification call, a named owner, and a review date. The Commission's AI Act explorer lays out the obligations per tier.

An inventory also feeds the technical documentation and record-keeping evidence auditors will ask for, replacing the spreadsheet sprawl that GRC teams say still underpins most programs. If your footprint is US-only, the same inventory supports NIST AI RMF mapping, so the discovery work is not EU-specific overhead.

Honest limitation: GOVERNBOX.ai structures risk tiers and review dates but does not ship a prebuilt EU AI Act classification engine. Larger platforms such as OneTrust and Holistic AI market AI Act modules; check their documentation before assuming coverage.

How do governance frameworks like Databricks' apply to controlling shadow AI?

Vendor frameworks such as Databricks' AI governance guidance and the NIST AI RMF converge on the same principle: every AI use case needs a named owner, a risk tier, and a documented review date. Unsanctioned tools fail all three by definition, which is why discovery and inventory come before policy. Frameworks tell you what "good" looks like; they do not find the unauthorized copilot your claims team adopted in March.

Choosing tooling: an honest criteria check

Evaluate any AI GRC tool against four criteria: shadow AI discovery, an audit-ready inventory with owners and review dates, control mapping across ISO 27001, NIST CSF and NCSC CAF, and board-level exports. OneTrust, Holistic AI, Credo AI and IBM watsonx.governance cover broad AI governance programs; Drata anchors compliance automation more broadly.

GovernBox runs the same check honestly: it covers inventory, risk tiers, named owners and flat org pricing ($3,500–$25,000/yr), but discovery depth and cross-framework mapping are narrower than enterprise suites, and there is no free tier, so a credit card is required to trial it.

FAQ

Is shadow AI illegal, or just against policy?

Usually neither is automatic. Using an unapproved AI tool is typically a policy violation, not a crime. It becomes a legal problem when the tool processes regulated data like PHI, PII, or donor records, or when a high-risk use case under the EU AI Act goes undocumented. Treat each case as a risk question, not a disciplinary reflex.

What's the difference between shadow AI and shadow IT?

Shadow IT is any technology adopted without IT approval: a random SaaS subscription, a personal laptop, an unsanctioned database. Shadow AI is the subset performing AI work, like a chatbot, an agent, or an embedded model. The distinction matters because AI carries extra obligations: risk classification, documentation, and human oversight under frameworks like the EU AI Act.

How often should we re-scan for shadow AI tools?

Quarterly is a defensible baseline for most organizations, since new tools, browser extensions, and vendor features appear continuously. Re-run the four discovery signals (SSO telemetry, network logs, expense review, AI spend analysis) on that cadence, and add a trigger-based scan when a vendor announces new AI features or after an incident. Every re-scan should update owners, tiers, and review dates.

Can employees use personal ChatGPT accounts for work if they don't paste sensitive data?

Low-sensitivity use can be acceptable, but it still belongs in your inventory with a named owner and a risk tier. "No sensitive data" is a claim you cannot verify without logging, and free accounts typically give you no data-handling guarantees or retention controls. Decide the policy deliberately and require an approved account for anything touching client, patient, or donor content.