Who actually owns an AI decision when it goes wrong?

Ask almost any mid-size company what happens when they have a security incident, and you’ll get a real answer: an incident commander, a defined severity scale, a postmortem template, a person whose job it is to own the response. That process didn’t appear overnight — it took years of real incidents to build the muscle.

Now ask the same company what happens when their AI system makes a bad call that affects a real person — denies someone a loan, flags the wrong employee, misroutes a customer complaint that should’ve escalated. In my experience coaching teams through this transition, the honest answer is usually a shrug, or a name that turns out to be wrong the moment you press on it.

The incident exists. The ownership doesn’t.

This isn’t a claim that AI failures don’t get noticed. They do — someone files a ticket, a customer complains, a manager gets an angry email. What’s missing is the layer underneath that: who actually owned the decision to deploy this system in this way, who’s accountable when it’s wrong, and what the actual remediation process is, beyond “we’ll look into it.”

Compare that to security. A breach has an owner from minute one, because the org decided in advance who that would be. An AI decision failure usually doesn’t, because most orgs never had that conversation — the system got deployed by an engineering team, approved by a product owner, and used by a business unit that had no say in how it was built, and none of the three would confidently claim ownership of a bad outcome after the fact.

Why this keeps happening

Part of it is timeline. Security governance had decades and a steady drumbeat of high-profile breaches to force the issue. AI governance is being built in real time, on a much faster deployment cycle, by teams that are still primarily optimizing for “does it work” rather than “who’s accountable when it doesn’t.”

Part of it is structural. A security incident is usually legible — something was accessed that shouldn’t have been. An AI decision failure is often ambiguous: was the model wrong, was the input data bad, was the person using it supposed to override a low-confidence output and didn’t? That ambiguity gives every party in the chain a plausible reason to point elsewhere, and organizations that haven’t pre-assigned ownership will let that ambiguity resolve into nobody being accountable at all.

What actual ownership looks like

It’s not complicated, but it requires deciding in advance, not after the fact:

A named owner per deployed system, not per project. Projects end. Deployed systems keep making decisions long after the team that built them has moved on to something else.

A defined threshold for human override, decided before deployment, not improvised in the moment a business user notices something looks wrong.

A real postmortem process for model decisions, not just model performance. “The model was 94% accurate” is a technical postmortem. “Here’s what we changed about who can deploy what, and how overrides get triggered” is a governance one, and it’s the one that actually prevents the next incident.

None of this is a new invention — it’s the same discipline security governance already has, applied to a category of risk that’s growing faster than the accountability structure around it.

If your organization can answer “who owns our security incidents” without hesitation, and can’t answer the same question about your AI systems, that gap is worth closing before something forces the issue — because eventually, something will.

This is the first entry in The Long View*‘s Corporate Governance section — ongoing essays on how organizations actually make decisions, and where accountability quietly goes missing.*