Somewhere in your organisation right now, someone is pasting a customer contract into a chatbot to get a summary before a meeting. They are not malicious. They are not even careless by their own lights — they are trying to do their job faster, with a tool that is manifestly good at it. They did not ask permission because asking permission has never once resulted in a faster yes than the chatbot already gives them. This is Shadow AI, and if your first instinct is to block the domain, you have already lost the part of the fight that mattered.

We have been here before. Shadow IT — the SaaS tools, the personal Dropbox accounts, the spreadsheets doing the work of systems — taught enterprise architecture a lesson it keeps having to relearn: unsanctioned adoption is not a discipline problem, it is a signal. It tells you where the official channels are too slow, too locked down, or too absent to meet a real need. Shadow AI is the same signal, arriving an order of magnitude faster and carrying a good deal more risk.

Why this is worse than Shadow IT ever was

Classic Shadow IT mostly leaked money and coherence. A team bought a tool the CMDB never heard about; you overpaid, you duplicated a capability, you found out at renewal time. Bad, but slow and largely recoverable.

Shadow AI leaks data, and it does so instantly and irreversibly. The moment a paragraph of a contract, a slice of a customer table, or a snippet of unreleased source goes into a consumer chatbot, you have made an uncontrolled disclosure to a third party whose retention and training terms you never negotiated. There is no un-sending it. The exposure is not a line item you reconcile later; it is an event that has already happened by the time anyone with a governance hat notices.

And the surface is enormous. Shadow IT required someone to procure something. Shadow AI requires a browser tab. Every knowledge worker in the building is one paste away from being an integration point you never designed, between your most sensitive data and a model you do not control.

Why the block list fails

The reflex response is prohibition: firewall the consumer AI domains, add a policy line, run a training module. I understand the appeal. It is also, measured against how people actually behave, close to useless.

Prohibition does not reduce the demand that created the behaviour; it only removes your visibility into how the demand gets met. Block the sanctioned-looking tools and usage migrates to phones, personal laptops, and the long tail of AI features now quietly embedded in every SaaS product you already run. You have not stopped the data leaving. You have blinded yourself to it, and you have taught your most motivated, most productive people that the security function is an obstacle to be routed around rather than a partner to be consulted.

This is the same structural error I wrote about in architecture governance at agent speed: putting a human gate in front of demand that vastly outpaces the gate. The queue does not hold. It gets bypassed, and the bypass becomes the real system while your policy becomes fiction.

The EA move: build the sanctioned path

The enterprise architect’s contribution here is not a stricter policy. It is a reference architecture — a sanctioned AI landing zone that is genuinely easier to use than the shadow alternative, because if it is even slightly harder, people will keep pasting into the consumer tab.

The shape of it is not exotic:

  • An AI gateway as the single egress point for model calls. Every request to an LLM — from apps and from people — routes through a broker you operate. That is where you get logging, data-loss inspection, prompt and response retention on your terms, and the ability to swap providers without touching a hundred integrations.
  • An allow-list of models and providers with negotiated enterprise terms: no training on your data, defined retention, a real contract. The point is not to offer one blessed model; it is to make the good options the default ones.
  • Data classification wired into the path, so the gateway knows the difference between a public marketing draft and a customer record and can redact, block, or route accordingly — rather than trusting each employee to make that call under time pressure.
  • A sanctioned front door for humans: an internal chat experience, backed by the gateway, that is as fast and as pleasant as the consumer tool it replaces. This is the part architects under-invest in and it is the part that decides whether any of the rest gets used.

Notice what this does. It converts an uncontrolled, invisible integration between your data and arbitrary models into a governed seam you own and can observe. That is the same reframing at the heart of from system of record to system of context: the value, and the risk, has moved to the layer where your data meets the model, and that layer deserves to be architected on purpose rather than left to emerge one paste at a time.

Governance that enables rather than gates

A landing zone without governance is just a faster leak. But the governance that works here is guardrails, not gates — controls that run in the path automatically, not committees that changes wait behind.

This is where the discipline EA already has earns its keep. TOGAF’s risk management and its capability framing are not obsolete in the AI era; as I argued in TOGAF in the AI era, the parts that describe how you reason about risk and capability transfer almost untouched. Treat “enterprise AI usage” as a capability with an owner, a maturity target, and a defined set of controls. Express the non-negotiables — no unclassified data to unapproved models, full retention of prompts touching regulated data — as things the gateway enforces on every request, so compliance is the default state of the system rather than an audit you fail later.

The board still exists. It just points at the policy encoded in the gateway — which models, which data classes, which redaction rules — and argues about that, slowly and deliberately, because it changes far less often than the traffic flowing through it.

Measuring whether it is working

Shadow anything is, by definition, hard to measure — but the whole point of the landing zone is that it replaces the invisible with the observable, so give yourself a metric that reflects that.

The one I would watch is the ratio of sanctioned to estimated total AI usage. Sanctioned usage you can measure exactly, at the gateway. Total usage you triangulate — network telemetry to the known consumer endpoints, SaaS admin reports on embedded-AI features, honest survey data. The gap between them is your live Shadow AI exposure. If the sanctioned path is winning, that ratio climbs month over month, and it climbs because your front door is better, not because your firewall is angrier. A falling ratio is not a discipline failure to be met with more prohibition; it is a product failure telling you the sanctioned path has fallen behind, and it is the single most useful number this whole exercise produces.

The turn

Shadow AI is not a security incident to be suppressed. It is your workforce voting, thousands of times a day, that AI makes them better at their jobs. The enterprise architect who treats that vote as a threat will spend the next several years losing a game of whack-a-mole against their own most valuable people. The one who treats it as a requirement — and builds the sanctioned, observable, genuinely-better path that absorbs the demand — turns the same energy into the safest, most leveraged capability the organisation has. The tools were never the problem. The absence of a designed path was.