Shadow AI: governing the tools staff already use

Shadow AI is the set of AI tools your staff already use without approval, logging, or a contract governing what happens to the data they type in. You cannot ban your way out of it: the demand is real and the tools sit one browser tab away. The fix is a sanctioned path that beats the shadow one on convenience, backed by a written policy and logs that catch the violations.

Start from an honest premise. If your firm has knowledge workers and an internet connection, people are pasting company data into chatbots right now. An analyst summarizes an earnings call to hit a deadline. Someone in ops asks a model why two spreadsheets disagree. The productivity is genuine, which is exactly why prohibition fails. A rule that makes the sanctioned workflow slower than the unsanctioned one loses every time, and it loses quietly, on personal devices where you have no visibility.

Where the data actually leaks

The leak is almost never the model’s output. It is the input. When an employee pastes context into a prompt, that text can be retained, logged, or fed into a future model version depending on the vendor’s terms. The specific things that walk out the door in finance are predictable:

• Client identifiers and account numbers dropped into a prompt to “clean up this list”
• Unreleased financial figures pasted while drafting a memo before the numbers are public
• Reconciliation extracts and trial balances shared to ask why two sources disagree
• Source code containing connection strings, API keys, or internal schema names
• Draft filings, board materials, and deal documents used as writing context

Material non-public information is the sharpest edge. If an analyst pastes pre-release quarter-end figures into a consumer chatbot, you have a data-handling failure and potentially a securities-law problem in the same keystroke. The employee was not being malicious. They were being efficient with a tool that gave them no signal about where the text was going.

The second failure mode is quieter: decisions made on output nobody can trace. Someone asks a model to summarize a covenant package, pastes the summary into a credit note, and the model has silently dropped a carve-out. There is no lineage back to the source document and no record that a model touched the decision at all. When an examiner later asks how a figure was derived, the answer is a chat window that no longer exists.

Write a policy that names behaviors, not vibes

Most acceptable use policies are useless because they are abstract. “Use AI responsibly” tells no one what to do on a Tuesday afternoon. A policy that changes behavior sorts data and tasks into tiers and states the rule for each.

• Classify the data. Public marketing copy, internal-but-non-sensitive text, confidential client data, and regulated or material non-public information each get a different rule. The top tier goes only to sanctioned endpoints with a signed data processing agreement, or nowhere.
• Classify the task. Drafting and brainstorming carry low risk. Anything whose output feeds a customer decision, a filing, or a control gets a mandatory human review and a record of what the model produced.
• Name the approved tools by product and tier. “An enterprise AI assistant” is not actionable. “Tool X on the enterprise plan for tiers 1 through 3, never tier 4” is.
• State the retention terms in plain language so staff understand why the sanctioned tool is safer. Zero data retention and no training on your inputs are the two clauses that matter.
• Require attribution when model output lands in a deliverable that someone will rely on, so the audit trail links the output to the person who accepted it.

Keep it to two pages. A policy nobody reads governs nothing. Pair it with the AI-literacy training that Article 4 of the EU AI Act expects deployers to provide, and keep a record of who completed it.

Controls that catch what the policy misses

Policy sets expectations. Controls tell you when those expectations are being ignored, and they do the work the honor system cannot.

Give people a sanctioned endpoint first. An enterprise AI gateway with a zero-retention agreement, routed through your identity provider, is the single most effective control, because it removes the reason to reach for the shadow tool. Make it fast and make it the default inside the tools staff already open.

Then put a redaction layer in front of that gateway. A data-loss-prevention pass that detects account numbers, national IDs, and known client entity names before the prompt leaves your perimeter turns a potential breach into a blocked field. Tune it against a real eval set of prompts your staff actually write, and hold a false-positive budget. A redactor that mangles every legitimate prompt gets switched off by the people it was meant to protect. Entity resolution against your client master helps here, so the filter catches “Acme Holdings” and not only the raw account number.

Log the sanctioned path and monitor the rest. Egress logging on the sanctioned gateway gives you the audit trail. Network telemetry to known consumer-AI domains tells you where shadow usage is concentrated, which is a signal to improve the sanctioned workflow rather than a list of people to discipline. Watch that traffic for drift; a spike after a new consumer feature ships means your sanctioned tool just fell behind.

Review the high-risk tier by hand for a while. Before you trust any control on the material non-public or regulated data path, sample the actual prompts and outputs and read them. That is how you learn what your redaction is missing and where the policy tiers are drawn in the wrong place. The controls that survive contact with real usage are the ones you built against real logs, not the ones you drew on a whiteboard.

None of this ends shadow AI. It converts it from an invisible risk into a governed one, where the data staff handle has a rule attached, the sanctioned tool is the path of least resistance, and the exceptions show up in a log you can actually read.