Shadow AI

What is shadow AI?

Shadow AI is the use of AI tools by employees without IT approval, security review, or governance: consumer chatbots, browser assistants, and personal model accounts adopted to get work done faster than the sanctioned stack allows. The tools are often genuinely useful. What is missing is the review that would have decided where the data goes.

Nothing about shadow AI requires technical skill or a budget line. A free tier, a browser tab, and a copy-paste are enough, which is why it spreads through support teams faster than unapproved SaaS ever did, and why procurement records show none of it.

How shadow AI works

Shadow AI forms in a repeatable four-stage loop. Stage one is the gap: a macro is missing, a knowledge article is stale, the queue is backed up, and the approved tooling has no answer. Stage two is the workaround, where an agent pastes a customer's message into a public model and gets a usable draft in seconds. Stage three is normalisation, when the trick is shared in a team channel and becomes how the shift runs. Stage four is dependency: answer quality now rests on a system nobody has tested, logged, or contracted for.

Each stage strips a control the sanctioned path would have applied. Pasted transcripts skip the PII redaction that masks identifiers before anything is stored. Drafted answers skip the AI compliance review that records which policy version produced them. Copilots granted account access skip the permission scoping that governs tool calling, so an unreviewed integration can read and change live records.

Types of shadow AI

Shadow AI arrives in five forms, and they carry very different blast radii.

• Consumer chatbot use: Staff paste tickets, transcripts, or exported spreadsheets into a public model to draft replies, summarise threads, or translate.

• Unapproved browser extensions: Assistants installed in one click read whatever is on screen, including the CRM record sitting behind the active tab.

• Dormant features switched on: AI summarisation or drafting inside already-approved SaaS, enabled by an admin without a fresh vendor security review.

• Personal API keys: An ops lead wires a model into a script or spreadsheet on a personal account, outside single sign-on and outside billing visibility.

• Unsanctioned agents: A team stands up an agent with credentials to read orders or issue refunds, which turns a drafting risk into an action risk.

Shadow AI vs shadow IT vs sanctioned AI vs BYOAI

Teams use these four labels interchangeably during incident reviews, and the confusion decides who owns the remediation. Shadow IT covers any unapproved software or service, from a file-sharing account to a scheduling tool. Sanctioned AI covers models and agents that passed security review and run inside a contracted boundary. BYOAI covers personal AI accounts brought into work by individuals, usually on personal devices and personal logins. Shadow AI is the subset where the unapproved system is a model, which adds data retention, training-set exposure, and output accuracy to a problem that was previously about access alone.

If you are deciding what to call an incident, apply one test: name it shadow IT when the unapproved tool holds no model, and shadow AI when a model processed the data, because the second case forces retention, training, and accuracy questions the first one never raised.

Why shadow AI matters for customer experience

Shadow AI shows up first as a quality problem. Two agents answer the same billing question differently because one drafted from a public model that guessed at a policy it had never read. Nothing in the ticket record shows where the wording came from, so the review after a complaint reconstructs the decision from memory.

The data problem follows. A transcript pasted into a consumer tool carries names, account numbers, and sometimes payment or health detail out of the systems where retention and deletion are actually enforced, and the company cannot honour a deletion request for a copy it does not know exists. The hidden cost of shadow AI in support sits mostly in that gap between what happened and what can be evidenced.

The tradeoff is real. A hard ban pushes the same usage onto personal phones, where visibility falls to zero and the productivity gain disappears with it.

How is shadow AI measured?

Shadow AI is counted before it is scored. Discovery answers the first question: how many distinct AI destinations appear in egress and DNS logs, how many AI accounts exist outside single sign-on, and how many of those accounts touch systems holding customer records. Expressed as a share of headcount, that figure is the adoption estimate most security teams start from.

Exposure is the second question, measured at the boundary: how often sensitive fields are flagged leaving approved systems, and how many of those events involve an AI destination. No published norm exists for either measure, so the useful comparison is your own trend line quarter over quarter. For context on what unreviewed third parties cost, the Verizon Data Breach Investigations Report put third-party involvement in breaches at 30% in its 2025 edition, roughly double the 15% recorded the year before.

How AI agents change shadow AI

Chatbot shadow AI produces text a person still reads before sending. Agentic shadow AI holds credentials and acts. Once a team connects a model to a helpdesk API or a billing endpoint, the unapproved system can refund an order, close a ticket, or email a customer with no human in the path, and the record of why it did so lives in a console security has never seen.

That shifts the control question from data exposure to authority. Sanctioned deployments constrain an agent through three mechanisms: scoped permissions, approval steps on high-impact actions, and AI agent testing against known cases before release. A weekend project skips all three, which is how an unreviewed agent ends up confidently quoting a policy that expired two quarters ago. The failure patterns match those catalogued in this guide to support agents that avoid wrong answers, applied to a system nobody signed off.

What to look for in shadow AI controls

Coverage is the first axis. Discovery that reads network egress and identity logs sees browser extensions and personal API keys; an expense-report review sees only what somebody paid for.

Integration surface decides enforcement. Controls that sit in the identity provider and the data-loss layer apply automatically to each new AI domain that appears, while controls that live in a policy document apply to whoever read it.

Governance is ownership made concrete: a named approver, a written review record, an inventory entry, and an expiry date on every approval.

Certification is where regulated buyers get specific, asking whether an AI vendor sits inside the same audited boundary as the rest of the stack. SOC 2 Type II is the report they request when the question is whether controls held over a period, and ISO 42001 is the one they raise when the question is how the AI system itself is managed.

The constraint most programmes underestimate is approval latency. A review queue that outlasts the problem an agent is trying to solve rebuilds shadow AI faster than any policy removes it.

Shadow AI and AI governance

Shadow AI is governance with the record missing. Pulling it back inside usually means offering a sanctioned equivalent fast enough that people prefer it, which for support teams often means SOC 2 AI support, where the agent, its data flows, and its subprocessors all sit inside one audited boundary. Discovery tells you which tools appeared; voice of the employee programmes tell you why, and the gap those tools filled is the specification for what to approve next.

What does shadow AI mean in plain terms?

Think of shadow AI as an unlogged shortcut through a locked corridor. The door exists because someone decided that what happens on the other side needs a record. The shortcut is quicker, the person taking it means well, and the record simply never gets written.

Concretely: an agent drafts a refund explanation in a personal AI account and pastes it into the ticket, and the customer sees an ordinary reply. Had the draft come from the approved system, there would be a log of the prompt, the source article, and the model version behind it. Both replies read the same. Only one can be explained six months later during an audit or a dispute.

The tradeoff people underestimate is that every approval step added makes the sanctioned path slower, and slowness is what created the shortcut in the first place.

Common shadow AI mistakes

Treating it as a discipline problem. Reminders and acceptable-use training address intent, while shadow AI is driven by throughput. As long as the approved path is slower than the queue, the shortcut regenerates after every reminder.

Banning the category outright. A blanket block moves usage onto personal devices and personal accounts, where no telemetry reaches and no data-loss rule applies, so the exposure survives while the evidence disappears.

Discovering once. A one-time SaaS audit produces a snapshot that decays within a quarter, because new AI features appear inside tools that were already approved and need no new signup to switch on.

Approving the tool and stopping there. An approval with no owner, no expiry, and no re-review becomes a permanent exception, and the next wave of shadow AI grows in the space between what was reviewed and what the tool can now do.