One diagram for enterprise AI adoption: five stages from identity to governance

This is a reference architecture for bringing AI into a company. It has five layers: users and apps, identity and access, an AI gateway, models with data retrieval, and agents with tools, with a governance and observability row underneath. Each box is a functional component and maps onto whatever product a team already runs. The diagram carries two kinds of marks. Arrows show which component calls which. The numbered badges 1 through 5 give the recommended adoption order. This piece walks the diagram in badge order.

Stage one is identity and the gateway. It covers the full IDENTITY & ACCESS column, SSO / IdP, Roles & scopes, Secrets manager, and the full AI GATEWAY column, Routing, Rate limit & budget, Logging, PII / DLP filter, marked 1 on the diagram. Cloud LLM APIs sit right on the enterprise boundary line, and every arrow into or out of them passes through the gateway first; there is no second path straight to an external provider. This comes first because every later stage depends on two questions already being answered: who is asking, and how much did this call cost and was it logged. Without those two answered, nothing else can be managed. To walk through what each stage runs into, picture a company called Qingchuan, about 40 people, 8 engineers and 2 in marketing. Qingchuan is made up and only serves to walk through each stage. If Qingchuan lets everyone open accounts on their own credit card and use their own key, the company cannot say who is using which tool. You know you can move to stage two when a new hire logs in through SSO, gets the correct role scope, and anything over budget or containing PII that should be blocked is actually blocked, without anyone standing over it.

Stage two is data and retrieval. It covers the full DATA & RETRIEVAL column, Enterprise data sources, Ingestion & indexing, Retrieval index, marked 2. It comes after identity and the gateway because Retrieval index is labeled "scoped by role," and roles only exist once stage one's Roles & scopes is in place. If Qingchuan feeds the engineering wiki, support tickets, and customer records into the same index, one question from marketing could pull back information only support should see. The index was never split by role. This stage is still read-only, so the worst outcome is a wrong answer. You know you can move to stage three when the same question, asked by people in different roles, returns different data scoped correctly to each of them, and that scoping is enforced by the system itself; the model has no part in deciding what it can share.

Stage three is where agents start acting. It covers Agent runtime and Read connectors inside AGENTS & TOOLS, marked 3. Agent runtime is labeled "sandboxed execution," and at this stage it only connects to read-only connectors. This comes after data and retrieval because an agent needs something to read before it has anything to do, and what it can read is bounded by the scoping set up in stage two. If Qingchuan lets an agent read the repo and query the ticket system on its own, the sandbox keeps a crash or a bad run from reaching anything outside it. A connector that was never scoped tightly enough is a separate problem, and the agent can end up reading more than intended. You know you can move to stage four when what the agent read, and when, shows up in a log, and that log matches what the agent itself reports doing, giving you an independent record to check the agent's own account against.

Stage four is writing and sending. It covers Write connectors and Send connectors, plus the dashed Human approval box between them, marked 4. Write and Send connectors are drawn separately from Read connectors, and every arrow from them has to pass through Human approval first; the box is labeled "send & write need a person." Writing and sending differ from reading because a mistake here leaves an external trace: a record gets changed, or a message goes out and cannot be pulled back. If Qingchuan lets an agent answer support tickets or open pull requests on its own, whether the content is good is a separate question from whether it should go out unapproved, and that decision needs a person to actually approve it; a line in a prompt asserting that someone would falls short. You know you can move to stage five when both write and send actions leave an approval record inside the system, kept independently of whatever the AI itself reports having done.

Stage five is governance hardening. It covers the full bottom row, GOVERNANCE & OBSERVABILITY: Policy & gates, Audit ledger, Halt & budget caps, Cost & quality metrics, marked 5. It comes last because there has to be something to govern first, identity, the gateway, retrieval, agents, writing and sending, before governance has an object to act on. This is easy to misread as governance only starting at stage five. Logging and Rate limit & budget have been running inside the gateway since stage one; every call has been logged and charged against a budget from the start. What stage five adds is three specific things. Policy & gates checks declared rules against what actually happened. Halt & budget caps can stop an entire run in progress; a rate limit only refuses the next call. Cost & quality metrics track tail numbers like p95, where averages would hide the same anomaly. By this stage Qingchuan is usually running several agents or pipelines at once, and the new problem is whether a run that goes out of bounds can be stopped while it is still running, on top of the call already being logged back at stage one. There is no stage after this one. The way to check governance is actually working is to periodically compare what Policy & gates declares against what Audit ledger recorded; a mismatch means it isn't holding yet.

The SaaS and self-hosted diagrams differ only in the MODELS column. In the SaaS version, Cloud LLM APIs sit on the enterprise boundary line, and traffic in and out passes through the gateway with no second path straight to the external API. In the self-hosted version, that box is replaced by Model registry / weights and GPU / inference cluster, marked 1b, both sitting fully inside the enterprise boundary; weights load from the registry into the GPU cluster, and nothing connects out. The other four columns and the GOVERNANCE & OBSERVABILITY row at the bottom are identical between the two diagrams. The self-hosted swap only changes who holds the model. Identity, the gateway, data scoping, how agents act, and how governance gets layered on all stay the same.

This piece only walks the full diagram once. Each stage after it gets its own piece, starting with identity and the gateway at stage one and running through governance hardening at stage five.