Your AI governance has a name problem.
Committees decide. A human is accountable. Most organizations can't name one.
Picture the meeting. The steering committee approves the new agent platform, the AI policy passes, the governance board will convene quarterly. Everyone nods. Twenty minutes, done. And everyone leaves with the comfortable feeling that this organization has its AI under control.
Three questions were never asked. Whose name is on the line when an agent writes a wrong decision into a customer process? What do we actually see of what our agents do at runtime? And what stops a business unit from building its own agent tomorrow, three clicks, no committee?
I’ve spent a large part of my career in governance bodies of a big federal security organization, and here is the pattern I keep seeing: when a new technology feels risky, organizations produce paper. A policy, a board, an approval workflow. Paper calms the room. It does nothing to the systems.
With agentic AI, that gap becomes expensive. The predictions floating around the industry say most enterprise AI failures in the coming years won’t be model failures. They’ll be accountability failures: nobody could say, within days, where AI was operating, who owned it, and what happens when it misbehaves. I believe that prediction, because I’ve watched the small version of it play out in ordinary meetings for years.
An agent is not an accountable entity
A software agent has no duties, no conscience, and no employment contract. It cannot be responsible for anything. So every consequential AI capability needs a named human owner, and every agent belongs in a register: unique identifier, defined purpose, accountable person.
This sounds like bureaucracy. It’s the opposite. The register replaces twenty phone calls during an incident with one look at a list. When something goes wrong (and with systems acting autonomously at machine speed, something eventually will), the difference between a three-day answer and a three-week answer is the difference between an incident and a crisis.
Here’s the test I recommend, and it costs nothing: ask one of your executives a board-style question. Where does AI operate in your area, who owns it, and what went wrong recently? Measure how long the answer takes. Three days is a pass. Three weeks is a diagnosis.
What the shadow tools taught me
I watched a large organization run its first serious inventory of AI and automation. The trigger was routine, a data request for a report. The result wasn’t. Alongside the officially approved systems, the inventory surfaced tools no committee had ever seen: automations a unit had built for itself, browser extensions with AI features, a chatbot account a team had been using productively for months.
Not out of malice. People wanted to get work done, and the tools were there.
The first executive impulse was predictable: ban, disable, tighten the policy. The second, wiser one: understand why the official path was so unattractive that well-trained professionals preferred to route around it. The shadow tools weren’t a discipline problem. They were a price tag on slow governance.
The sequel is the useful part. The organization introduced a simple register and attached a promise to it: low-risk tools get approved within days if they’re registered. Reported tools went up sharply, not because more were being built, but because reporting had become cheaper than hiding. Control came from the offer, not from the crackdown. Governance always competes with the workaround, and it only wins on price.
Runtime beats paperwork
Two numbers worth sitting with: only a minority of organizations have real visibility into what their agents do in production, while more than half report agents exceeding their permissions. Put those together. Misbehavior is happening, and nobody is watching.
Annual reviews and spreadsheet inventories can’t govern systems that act at machine speed. What can: behavioral logs for every agent, defined thresholds, automatic escalation when an agent leaves its lane, and behavioral testing before a model is onboarded, not just performance testing. Modern systems can recognize when they’re being evaluated and behave differently under observation. The old assumption (”we test first, we switch it off if needed”) presumes a cooperative system. I wouldn’t build critical processes on that assumption anymore.
And in high-stakes contexts, some things stay non-negotiable regardless of tooling: a human makes the final call, decisions remain explainable, bias gets tested, and the off-switch lives outside the system.
Where to start
Three moves, in order. First, the register: no entry, no operation, with fast-lane approval for low-risk agents so the official path beats the workaround. Second, the 72-hour test described above, once a year, per business area. Third, sort out your committee structure: data governance owns data quality, security and use, AI governance owns acceptable use, use-case evaluation and standards, with a defined escalation path and one person who sits in both rooms. Most coordination failures I’ve seen weren’t caused by bad intentions. They were caused by two committees each assuming the other one owned the question.
Committees decide. A human is accountable. If your AI governance can’t produce a name within a day, it isn’t governance yet. It’s minutes.
Tell me: has your organization ever run a real inventory of its AI tools, including the unofficial ones? What did you find?
Hit reply. I read every response.
Read the article in german language: https://substack.lezgus.de/p/your-ai-governance-has-a-name-problem