Who Is Responsible When AI Gets It Wrong?
Somebody in your company is already accountable for an AI mistake that hasn't happened yet. They just don't know it, because nobody wrote the name down.
Picture an agent that auto-approves carrier rate confirmations under a set threshold. It runs quietly for four months. Then it starts approving them against the wrong tender, and a five-figure sum leaves the building before anyone notices.
The failure is not the interesting part. The meeting afterward is. Six people in a room and no honest answer to whose this was. The developer built what was asked for. Operations signed off on the threshold. The vendor supplied the model. Finance approved the budget. Every one of them did their job, and the loss belongs to nobody.
This is not an exotic scenario. It is the normal state of AI accountability in companies that deployed something without deciding, in advance, who owns it being wrong. Ask who is responsible for AI mistakes at most companies and you get a shrug, a job title, and no name.
The legal answer is simple and unhelpful
Legally, you are responsible. Your company made the decision to deploy the system, your company benefited from it, and your customer's contract is with you. "The model produced it" carries roughly the weight of "the spreadsheet had a bad formula." No regulator, no court and no customer has shown any appetite for treating a model as a party.
Vendor contracts rarely change this. Read your AI vendor's terms and you'll find liability capped at twelve months of fees, output disclaimed as-is, and an obligation on you to review before relying on it. That last clause is doing enormous work. It converts the vendor's product risk into your operational risk, and it's in nearly every agreement in this category.
Which means the useful question isn't legal responsibility. It's internal accountability: who inside your company is supposed to catch it, and who answers for it when they don't.
The four names
Every AI system in production should have four names attached to it. Not four committees. Four people, written down where anyone can find them.
The business owner
The person whose process the system runs. They own the outcome: whether the output is good enough, what the acceptance threshold is, and when the system should be switched off. This is not the person who built it. If your only named owner sits in engineering, then quality is being judged by someone with no exposure to what a bad output costs.
The technical owner
The person who can explain how it works, who monitors it, and who fixes it. They own uptime, cost, drift and the evaluation harness. When the model provider ships a change that alters behavior, this is the person who is supposed to notice before your customers do.
The approver
Whoever decided this system was allowed to operate at this level of autonomy. They own the boundary: what it may do alone, what needs a human, and what limits apply. In most mid-market companies this should be one executive rather than a committee, for the simple reason that committees do not get called at nine on a Friday night.
The accountable executive
One person for the whole AI portfolio, who answers to the CEO and the board. When someone asks who is ultimately responsible for AI governance in a company, this is the seat they mean, and it is the name most companies are missing. Its absence is why the meeting after an incident goes the way it does. If AI is currently owned by everyone at your company, then it's owned by nobody, and you'll discover that on the worst possible day.
What "responsible" actually requires
Naming someone is necessary and not sufficient. An owner who has no way to know the system is misbehaving is a name on a document, not an accountable person. Three things have to be in place for accountability to be real:
- A measurement. An evaluation set built from real historical cases, scored on a cadence, with a threshold that triggers action rather than discussion.
- A kill switch. The named owner can disable the system themselves, without a change request, without waiting for a deployment window.
- A log. Every decision the system made, with its inputs and its confidence, retained long enough to reconstruct what happened. Without one, the scenario above ends with a number nobody can explain and no way to find which approvals went wrong.
A company with those three things has genuine accountability even if its policy document is two pages. A company with a forty-page responsible-AI framework and none of the three has the paperwork of accountability and none of the substance.
Where this usually goes wrong
Two failure patterns account for most of what I see.
The first is accountability by seniority. Something goes wrong, and responsibility lands on whoever is most senior in the room, usually the CTO or the CIO. It feels decisive and it teaches the organization nothing, because the person now accountable had no visibility into the threshold that was set or the evaluation that wasn't running.
The second is accountability by vendor. "We bought it from a reputable provider" is offered as a substitute for review. It isn't one, and your own contracts with your customers say so. If you promised a client that their data stays in a region, or that a human reviews decisions affecting them, the vendor's compliance posture does not discharge your promise.
What I'd do this week
Take an hour. Write down every AI system currently running in your company, including the ones people set up themselves in a departmental tool. Beside each one, put four names. Where you can't fill in a name, you've found something.
Then check the three requirements for the systems that can act on their own, rather than merely recommend. Those are the ones where the gap between "someone is responsible" and "someone can actually tell" costs real money.
Most companies find that the exercise takes less than a morning and changes the next three quarters. If yours has more than a handful of systems and no single accountable executive, fix that before you fix anything else on the list. I've written more on who should own AI and on the seven decisions a governance framework has to make.
If you're staring at a list with a lot of blanks in it, tell me what's on it. That conversation is usually short and worth having before the incident rather than after.