How to govern 2,000+ AI systems without reviewing every case

More than 2,000 AI agents had been created by business teams within a few months. Reviewing every agent with Legal, Compliance, Security and IT would have turned successful adoption into an administrative queue. We chose a different control model: encode the shared doctrine once, apply it across the portfolio, review samples and send only exceptions to specialists.

I led the cross-functional program behind that change. My role covered the AI charter, the operating model, the first complete rule set and the working implementation used to test it. I brought Digital, IT, Compliance, Legal, Information Security and other policy owners onto the same decision model, then turned their reviews into changes that could be applied to the whole portfolio.

The 96–97% figure describes the routing result, not the accuracy of the classifier and not a benchmark for another company. It told us something useful about this portfolio: most business-built agents were low-impact uses that could proceed on a monitored path. The scarce expert time belonged on the remaining cases.

The bottleneck was the policy system

The bank already had policies. It had many of them, owned by different teams and written for human interpretation. A single AI use case could trigger overlapping questionnaires, each with its own vocabulary and decision path. Adding more reviewers would have preserved the same bottleneck.

We converted those sources into a versioned doctrine: common definitions, decision dimensions, rules, evidence requirements and escalation routes. Each rule points back to its source and records why it produced a result. Policy owners can change a rule, run it against the portfolio and see which decisions would move before publishing the new version.

A policy becomes operational when a change can be tested against the portfolio, traced to its source and reused by every control point.

This is the part worth carrying to another organization. AIR was the internal software vehicle that proved the approach. It produced the registry, system records, rationales and exports needed by the program. The reusable asset is the method for building and operating the doctrine, not AIR as a product.

Review the exceptions, sample the green path

Human oversight does not require a person to approve every result. That would make the automation pointless and encourage rubber-stamping. In this model, deterministic checks handle facts that can be settled directly. A language model interprets context that deterministic rules cannot resolve reliably. The doctrine then routes each case.

Sample review is the quality loop. It reveals missed context, unclear questions and rules that route too many or too few cases. Those findings update the doctrine and the next portfolio-wide run shows their effect. Exceptions get explicit human decisions. Routine cases remain auditable without being individually signed off.

The registry is an output, not the control model

A registry remains essential. It answers who owns a system, what it is for, which data it uses, how it was classified and which rule version produced that result. It also provides the working base for AI Act scoping, internal reporting and any registration or high-risk obligations that apply.

But a record describes a system at a point in time. An agent can later receive a new tool, act on different data or gain more autonomy. The control model therefore needs two layers: qualification of the system and controls applied when an action is attempted.

Controls belong where the action happens

A drafting assistant and an agent that can send a payment may use the same model. Their risk is defined by purpose, identity, data, tools, autonomy and the consequence of error. Controls should follow those variables.

A low-impact action can be logged and sampled. An external message may require confirmation. A decision affecting a person needs a defined review and recourse path. An action outside the user's permissions should never be offered to the agent.

This is why connectors and gateways are part of governance. They know the user identity, the requested capability and the target system. They can restrict scope, request confirmation, deny an action and preserve a useful trace. The MCP 2026-07-28 architecture makes the same allocation explicit: the host enforces security policies, consent and authorization decisions while servers expose bounded capabilities.

The OWASP Top 10 for Agentic Applications 2026 reinforces the point. Goal hijacking, tool misuse, identity abuse and unexpected multi-agent behavior cannot be managed by reviewing model output alone.

Current regulation changes the calendar, not the job

The EU AI Act still makes inventory, classification and lifecycle evidence necessary where its provider or deployer obligations apply. The AI Omnibus, in force since July 27, 2026, extends parts of the high-risk implementation timeline and reduces some administrative burden. It does not make an unknown AI portfolio governable.

Building the doctrine now avoids coupling the operating model to a moving deadline. The same evidence supports internal policy, security review and regulatory work. The NIST AI 600-1 GenAI Profile reaches a similar conclusion from a risk-management perspective: governance has to persist through design, deployment, use and evaluation.

The organizational change matters most

The software was the visible part. The harder result was moving several policy owners from separate approval chains to one maintained doctrine. I started with a complete working model because abstract alignment was too slow. Teams could inspect real rules, challenge them and see the impact of each change. That gave the program a shared object to work on.

The same doctrine now informs the registry, the AI gateway and the platforms that execute AI systems. I also designed agents, reusable skills and decision engines for investment-file analysis, legal review and contract analysis against an internal clause library.

The standard assistant on the first agent platform was replicated across environments and became its most-used agent. It helps employees produce an agent prompt and operating guide, checks whether the use is permitted and adds specialized guardrails from a shared skill library. That matters because the method is designed around governed decisions, not around one interface or one type of AI system.

Four questions expose a paper control

I now test any proposed control with four questions. Where is it applied so it cannot be bypassed? Which facts and rules determine the result? What evidence does it retain? What happens across the portfolio when the rule changes?

If those answers live in different teams, documents and tools, the control will slow adoption without giving management a reliable view of risk. A common executable doctrine fixes that. It lets most work move, makes exceptions visible and gives specialists something precise to improve.

Working sources, checked July 30, 2026: Regulation (EU) 2024/1689, the European Commission's AI Omnibus update, MCP 2026-07-28 architecture, NIST AI 600-1 and OWASP Top 10 for Agentic Applications 2026.