Almost every company that decides to take AI governance seriously makes the same first move, and it is almost always the wrong one: stand up a central committee and route every AI use case through it for review. The committee meets, the queue behind it grows faster than it can process, and within a few months either nobody waits for permission anymore or the committee rubber-stamps requests to keep the business moving. Either way, the program has failed at the one job it was supposed to do.

Call this what it is: a chokepoint, formalized into a process. The opening post of this series argued that a company moves at the speed of its chokepoints, not its people, and an AI review committee is the purest specimen, every use case in the company squeezed through a panel that meets on Thursdays. The point of AI governance was never to review every use case. It is to make most use cases never need a review in the first place.

Governance is a classification problem

The useful question is not whether this use case gets approved. It is which category the use case falls into, and whether that category needs a human at all. Most AI activity inside a company sorts cleanly into three bands. Internal drafting, summarizing, brainstorming, and work with non-sensitive information carries low enough risk that it needs no approval, just a default set of guardrails everyone operates inside. Customer-facing content, decision support in business-critical workflows, and anything touching company data at scale needs predefined controls and approved tools, but still no person in the loop for every instance. Only a narrow band, clinical or medical decisions, employment or financial decisions, sensitive personal data, and agents operating with real autonomy or privileged access, actually needs formal review and ongoing monitoring. Draw those lines once, well, and the review queue shrinks to the handful of cases that were always going to need a human anyway. The chokepoint dissolves. The judgment stays.

Cybersecurity solved this decades ago

No security team convenes a committee to approve every employee who opens a web browser. Identity controls, access policy, endpoint monitoring, and logging do that job automatically, and a human gets pulled in when something crosses a threshold worth their attention. AI governance is mostly still where cybersecurity was before that shift: a committee sitting between every request and every answer, instead of policy and classification embedded in the systems themselves. The end state looks the same in both cases. Policy decides the risk band, automated controls enforce it, exceptions escalate to a person, and nobody asks permission for activity that was never actually risky.

You can’t govern AI you don’t know exists

The opposite failure mode is worse than a slow committee: no governance at all, because nobody in security or IT knows what AI is actually running. An employee who downloads a specialized model and points it at company data has created exposure the company has no visibility into, no record of, and no way to monitor. IBM’s 2025 breach report priced that gap: breaches involving unsanctioned AI cost about $670,000 more than an ordinary incident. Before any classification scheme means anything, the first job is knowing what AI exists inside the company at all. Classification only works on activity you can see.

The CISO’s job got harder, not obsolete

There is a version of this story that recasts the CISO as a newly minted AI transformation officer. That framing undersells what actually happened. Every agent is a new identity to track, every integration a new data flow to monitor, every autonomous action a privilege grant that used to require a person and now doesn’t. The underlying mission, protecting the company’s assets, has not changed. AI made it more important and considerably harder to do well.

Then the software starts acting on its own

Everything above assumes the AI waits for a person to read its output and decide what happens next. Agents don’t wait. Three questions matter about any agent before it gets access to anything: what is it actually able to do on its own, who controls what it is allowed to reach, and can it cross from one system into another. The word “agent” has been stretched by nearly every vendor into meaning anything with a hint of autonomy, which makes the first question harder than it should be. What matters for governance is whether something can act without waiting for approval, hold state across a session, reach outside tools and APIs, and delegate part of its work, not whether it carries the label.

The boundary crossing is where the real problem lives. A human employee might hold access to five systems, but every permission ties back to one accountable identity, the person logging in. An agent built inside one vendor’s platform can authenticate as a service account, chain APIs across systems that were each governed separately by different teams with different rules, and pass what it finds from one system into the next without a person ever seeing the handoff. Who is accountable for what happens at the boundary between two systems that were never designed to be governed together?

What comes next

Not a faster committee, and not a longer policy document. The answer is the same architecture the rest of this series keeps building toward: an identity layer that gives every agent something to be held to, a broker that controls what it can actually reach, and judgment that sits in the path before an action lands rather than in a queue after. The classification problem this piece opened with and the boundary-crossing problem it closed with turn out to be the same problem, and the next posts in this series answer both.