Shadow AI Is an Operating Problem, Not a Ban

Forensics on thirty managed laptops, four months of browser history apiece, return the same artifact on most of them: customer records and source code pasted into a consumer chatbot. Nothing logged on your side. No retention you control. No list of which prompts left the building. A policy forbade exactly this. The policy is why the evidence surfaced in a forensic review instead of on a dashboard.

Pull the failure apart. The ban did not stop the work; it relocated the work to where you cannot see it. The first time you learn how AI is actually being used in your company is a data-leak incident, and by then you are reconstructing a workflow from a breach timeline instead of governing it. Data privacy is not a posture you announce; it is a boundary you can prove, and a boundary you never observed is one you cannot prove.

The reflex after a finding like this is a higher wall: block harder, ban louder. That rebuilds the exact condition that produced the leak, a barrier people route around. Traffic comes home only when the sanctioned tool is faster than the consumer one, and “faster and observable” is not a memo. It is infrastructure someone funds, builds, and holds under a latency budget.

That infrastructure has a name: an LLM gateway. Every model call routes through it, a reverse proxy between your people and every provider, the only way out. Four concrete layers turn it from a suggestion into enforcement. It authenticates against your IdP over OIDC or SAML, so every request carries a real user and group rather than a shared key, and access is revocable in one place the moment someone leaves. On managed devices and networks, the secure web gateway blocks consumer AI domains and allowlists only the proxy, so the direct chatbot stops resolving and the sanctioned endpoint wins by being the only one that answers. Before egress, requests hit a redaction stage (secret-scanning regex plus a PII classifier); matches are masked or blocked, and the decision is logged with the prompt that triggered it. Whatever does leave lands in a log you own: every prompt, response, user, and token count, with a retention window you set and can show an auditor.

None of this is exotic. A thin gateway is a few engineer-weeks on an existing API gateway, or a bought product at a per-token markup. The build is not the cost that matters.

Latency is, because latency is what sends people back to the consumer tool. A naive DLP stage that buffers the full response and round-trips it to a classifier adds hundreds of milliseconds to seconds, and you have rebuilt the wall, slower. The fix is architectural: scan on the request path, stream the response, redact inputs rather than outputs. Budget the proxy under ~100ms at p95 and treat any regression as a sev.

That budget is one number you can hold; governed share is the other. Of the AI egress your network can actually watch leave, it is the fraction routed through the gateway rather than out to a consumer chatbot. Below ~90% you have not funded a control plane, you have funded a dashboard that lies. Fund the gateway against that number and review it like a P&L line, not a compliance checkbox, and read it for what it covers: managed iron only.

Egress blocking reaches only the devices and networks you manage. A personal phone on home wifi routes around every wall you own and never enters the governed-share denominator, so a 95% governed share can sit on top of leakage you will never count. The block buys compliance on managed hardware; it cannot supply what wins the unmanaged majority, which is speed and capability. A governed path that is merely permitted gets bypassed. A governed path that is the fastest call, with the best models already wired in, gets adopted, which is governance without bureaucracy : the control and the convenience on a single endpoint. Make that endpoint the fastest one, and the traffic that no wall can reach comes back on its own.