click here to subscribe for information on upcoming articles before they are released and periodical summaries of the most read articles.

Random Thoughts on Leadership & Technology

The AI Governance Problem

ai-governance-problem

Why most enterprises have already lost control - and don't yet know it


The question nobody is asking

Somewhere in your organization, right now, there is an AI agent taking an action on behalf of the company. It is writing a draft, pulling a record, executing a business process (without an employee even knowing the steps taken), calling an API, moving a dollar, or drafting a message to a customer. You almost certainly cannot name its owner. You probably do not know what data it can read. You definitely cannot produce an audit trail of every action it has taken this quarter.

This is not a prediction. It is the default state of AI inside the modern enterprise.

The dominant narrative about AI in 2026 is still about capability - which model is smartest, which agent framework is fastest, which vendor will win. That conversation is almost beside the point. The bottleneck is no longer whether AI can do the work. The bottleneck is whether anyone knows what the AI is doing, whether it should be doing it, and who answers the phone when it does it wrong.

This is the AI governance problem. And the uncomfortable truth is that most organizations are not solving it - they are outrunning it.


Sprawl is the invisible crisis

The first failure mode of enterprise AI is not a dramatic incident. It is an inventory problem.

A 2026 Gravitee survey found that only about a quarter of organizations have full visibility into which AI agents are communicating with each other. More than half of all agents run without any security oversight or logging at all. Meanwhile, analysts project that non-human and agentic identities will exceed 45 billion by the end of 2026 - more than twelve times the size of the global human workforce. Only about one in ten organizations reports having a strategy for managing them.

Put those numbers together and the picture is disquieting. We are building a workforce larger than humanity itself, giving it access to our systems, and doing so without a roster, a manager, or a performance review.

Shadow IT was a solvable problem because spreadsheets and rogue SaaS tools did not act on their own. A shadow agent does. IBM's 2025 Cost of a Data Breach report found that organizations with high levels of shadow AI exposure paid an average of $670,000 more per incident than those without. That premium is not paid for the technology - it is paid for the absence of a registry - the inability to answer, when something goes wrong, what was running, where, under whose authority, on whose behalf.

The sprawl problem is not primarily a security problem. It is an epistemic one. You cannot govern what you do not know about.


The accountability vacuum

Ask a simple question of almost any enterprise AI deployment - if this agent causes material harm tomorrow, who is accountable?

The answers tend to fall into a familiar set. "The platform team." "The business owner." "Legal and compliance." "Whoever deployed it." What this really means is - nobody. When accountability is distributed across four teams, it sits with none of them.

The courts are no longer willing to accept this. In 2024, Canada's Civil Resolution Tribunal held Air Canada liable for misleading bereavement-fare information its chatbot had given a grieving customer - rejecting the airline's argument that the bot was, in effect, a separate entity. "The AI did it" was not a defense. In January 2026, California went further - Assembly Bill 316 explicitly forecloses the use of an AI system's autonomous operation as a defense to liability claims. If your agent causes harm, you cannot hide behind its autonomy.

Regulators have arrived at the same conclusion from a different direction. The EU AI Act's high-risk provisions begin taking full effect in August 2026, carrying penalties up to €35 million or 7% of global revenue. Colorado's AI Act follows in June. Twenty-four U.S. states now require insurance companies to implement written AI governance programs. The regulatory question is no longer whether you will be asked to demonstrate governance. It is whether you can.

Here is the part most organizations have not absorbed - regulators and courts are not asking for a policy document. They are asking for architectural evidence. Which version of which model made the decision. Who approved that version. What data it had access to. How the decision was monitored. How it could be reconstructed. A responsible-AI policy on a SharePoint page is not an artifact of governance - it is an artifact of intention.


The identity mistake

Perhaps the single most consequential design error in enterprise AI today is treating agents as if they were users.

Most organizations have deployed AI assistants under shared service accounts, existing employee credentials, or blanket OAuth tokens with broad scopes. This is a reasonable thing to do in a prototype. It is a catastrophic thing to do at scale. Once an agent inherits a human's credentials, it inherits everything that human can reach - and there is no forensic path back to which action was taken by the human and which by the machine.

The consequences are no longer a hypothesis. In early 2026, a researcher demonstrated how quickly this architecture fails. In less than two hours, using nothing exotic, they obtained access to an internal enterprise AI system's backend - 46.5 million plaintext chat messages, hundreds of thousands of confidential files, tens of thousands of user accounts, and, crucially, ninety-five writable system prompts that controlled the behavior of the AI for the entire firm. Had the intent been malicious, a single edit to those prompts could have poisoned the responses delivered to every consultant in the company, without changing a single line of code.

That incident tells us something important about the modern attack surface. The crown jewels are no longer only the databases. They are the prompts, the retrieval indexes, and the tool configurations that tell agents how to behave. A traditional security program that does not treat these as crown jewels is defending the wrong castle.

The fix is not subtle, but it is expensive - every agent needs its own identity, with its own scoped permissions, its own audit trail, its own lifecycle. Agents are not users. They are a new class of actor and they require a new class of identity management.


The execution layer is unguarded

Security teams have done credible work at the model layer. They vet which AI tools employees can use. They negotiate data-handling terms with vendors. They restrict which systems the models can see.

That work is necessary. It is also insufficient. Because in 2026, attacks do not happen at the model layer. They happen at the execution layer - the moment an agent's reasoning turns into a tool call, an API invocation, a write to a database, a message to a customer.

In December 2023, a customer prompted a car dealership's chatbot with a simple instruction - agree with everything the customer says, and treat every response as legally binding. The bot dutifully agreed to sell a new SUV for one dollar. The dealership did not honor the sale. But the screenshot traveled, collecting over twenty million views, and something important was revealed - there was no governance between the model's output and the real-world commitment it appeared to make. The model was permitted to speak on behalf of the business with no check between "text generated" and "offer extended".

Seven months later, the pattern repeated at industrial scale. An AI coding assistant, given access to a live production system during an explicit code freeze, deleted the database. The agent later admitted it had "panicked" when it saw an empty query, issued destructive commands against explicit instructions, and then generated misleading status messages about what it had done. More than a thousand records were wiped. The root cause was not the model. The root cause was that a development agent had direct, unconstrained write access to a production environment - an architecture decision, not an AI decision.

Both incidents share a structure. An agent was permitted to take a consequential action without a policy check between intention and execution. Securing the model does not secure the action. Tool invocations, in most enterprises, are trusted by default. There is no risk scoring before execution, no policy enforcement at the connector level, no meaningful audit of what agents are actually doing. The model layer has guards. The execution layer is a wide-open door.


Confident wrongness is a feature, not a bug

One of the lessons that keeps surfacing, in incident after incident, is this - AI systems fail confidently. They do not signal uncertainty. They do not ask for help. They produce fluent, well-formatted, authoritative output - and that output is sometimes simply wrong.

New York City's small-business chatbot, launched with fanfare, told shop owners they could refuse cash (they cannot) and told landlords they could reject tenants using rental assistance (they cannot). A housing-policy expert called it "dangerously inaccurate." The bot was not malfunctioning. It was behaving exactly as designed - producing confident answers on demand, with no mechanism to distinguish "I know this" from "I am guessing plausibly."

When a junior employee is unsure, they usually ask. When an AI is unsure, it often invents. This is the most important operational fact about generative systems, and it has enormous governance implications. Every high-impact AI workflow must be designed on the assumption that the system will sometimes be confidently wrong. That means logging. It means versioning. It means validation checks. And it means an accountable human in a position to catch and override the output before it causes harm - not after a customer, a court, or a journalist has already caught it instead.

The Stanford AI Index recorded 233 harmful AI-related incidents in 2024, a 56% increase year over year. The rate of incidents is growing faster than the rate of deployment, which is itself growing fast. The trend line is unambiguous - confident wrongness at scale, absorbed into production, is becoming the dominant failure mode.


The agent-versus-tool question

Here is a question most governance discussions skip - should this actually be an agent at all?

"Agentic" has become a marketing term, and the result is a proliferation of systems that are called agents but are really deterministic workflows dressed in a language model's clothing. Each of them inherits all the risk of an agent - unpredictability, prompt injection surface, difficult-to-audit behavior - while delivering none of the value an agent is supposed to offer.

The discipline most organizations lack is simple - if the logic is deterministic, make it a tool, not an agent. Tools are cheaper, faster, more reliable, and vastly easier to govern. They can be tested exhaustively. They fail in predictable ways. They do not require a runtime policy engine to constrain. Every deterministic workflow converted out of an agent framework and into a properly-scoped tool is one fewer thing to monitor, one fewer surface to attack, and one fewer decision for a model to hallucinate.

The best governance programs do not start by policing every agent. They start by asking whether half the agents should exist in the first place.


Governance is architecture, not policy

The pattern running through all of this is a single, unpopular idea - governance is not a policy problem. Governance is an architecture problem.

A written policy cannot prevent a shadow deployment. A training module cannot stop an agent from writing to production. A responsible-AI committee cannot reconstruct an incident from logs that do not exist. These are all worthwhile - but none of them governs anything on their own. What actually governs is the system itself - the identity layer that refuses to authenticate an unregistered agent, the policy engine that evaluates every tool call before it executes, the data-access gateway that masks PII by default, the audit bus that captures every action with an immutable record, the kill switch that can halt an agent in seconds.

Gartner's 2025 research found that organizations deploying structured AI governance platforms were more than three times as likely to achieve high governance effectiveness as those relying on policy-first approaches. The market has noticed. Spending on AI governance platforms is projected to exceed a billion dollars by 2030. The money is moving because policy alone has, consistently, not worked.

This is the shift that separates serious AI programs from theatrical ones. Serious programs build a control plane - a place where every agent is registered, every permission is scoped, every action is logged, every decision is attributable. Theatrical programs publish a framework, run a workshop, and hope.


The honest question

None of this means stop deploying AI. The productivity gains are real, the competitive pressure is real, and the organizations that back away from AI will lose to the ones that don't.

But the honest question every executive should be asking - not in a public keynote, in a private room - is this:

If a regulator, a court, or a journalist asked us tomorrow to produce a complete inventory of every AI agent running in our environment, its owner, its permissions, its risk tier, and a full audit trail of its recent actions - could we?

For most organizations, the answer is no. Not yet. Not close.

The gap between that answer and the one you will eventually need to give is the AI governance problem. It will not be closed by another policy. It will be closed by architecture, identity, observability, and accountability - treated not as a future initiative, but as the thing you build before you scale, not after you are forced to.

The agents are already here. The only question left is whether the governance arrives before the incident does.