Skip to content
InvariantRisk

Who owns it when an AI tool gets something wrong?

When an AI tool sends the wrong thing to a customer, the damage is rarely the first mistake — it's the two days spent figuring out who's allowed to fix it. Here's how to assign that ownership before you need it.

Updated June 9, 2026 · 9 min read

Picture the moment. Your AI support assistant has promised a customer a refund you never authorized. The customer is upset. Your support lead thinks IT owns the tool. IT thinks the vendor owns its behavior. The vendor points back at your configuration. Meanwhile the same wrong reply is still going out to other customers, because nobody is sure who is allowed to turn it off.

The first mistake — one bad AI reply — was small. The expensive part is the scramble. This guide is about removing that scramble: naming who owns an AI incident, and the path it follows, before one happens.

"Who's liable" and "who owns the response" are different questions

There is a lot of writing on AI liability, and it mostly lands in the same place: when a deployed AI tool causes harm, the organization that deployed it usually carries the primary responsibility — not the model vendor, who limits liability in their terms (BigID, MintMCP). Useful to know. But liability is the lawyer's question, answered after the fact.

The operational question is different and more urgent: when this goes wrong on a Tuesday, who picks it up, who can stop it, and who decides what we tell the customer? That is the question that determines whether an AI mistake is a ten-minute fix or a two-day fire. And it is one you answer with an org chart and a runbook, not a contract.

Name one owner per AI workflow

The single highest-leverage thing you can do: for each AI tool doing real work, name one internal person who owns it. Not a committee. One name. That person does not have to be technical. They have to have the authority to do three things:

  • Pause it. Switch the tool to draft-only or off, fast, without asking three other people.
  • Change the rule that caused it. Or know exactly who can, and reach them.
  • Decide the customer response. Own what you say and who says it.

The contractor who set the tool up and rolled off does not count. "The vendor" does not count. If you cannot name the person in under ten seconds, that is your finding.

Write escalation triggers as things people actually notice

Most "escalation procedures" are risk scores nobody references in the moment. Better: write triggers as observable events a normal team member would recognize and act on. For an AI workflow, a strong starter set:

A customer says the AI promised them something you didn't authorize (a refund, a price, an outcome) → pause the tool and notify the owner the same day.

The same wrong output goes out more than twice → it's a rule problem, not a one-off; the owner changes the rule before more go out.

A customer, partner, or prospect asks how their data is handled by the AI tool → route to the owner; do not improvise an answer.

The AI touches money, eligibility, or a regulated decision without a human in the path → treat as an incident regardless of outcome.

Notice these are sentences a support agent could read and act on at 2pm. That is the test. If your escalation rule needs interpretation, it will not fire when it matters.

The minimum incident runbook for AI

You do not need a 30-page IR plan. You need one page that answers, in order:

  1. What happened — a one-line description and which workflow.
  2. Stop the bleeding — how to pause the tool (the named owner can do this in under five minutes).
  3. Who's involved — owner, plus whoever needs to know (support lead, legal if customer-facing, the vendor contact).
  4. What we tell the customer — who drafts it, who approves it.
  5. Fix the cause — change the rule or config so it cannot recur.
  6. Write it down — a five-line post-incident note so the next person learns from it.

Shadow AI makes this harder, because you cannot write a runbook for a tool you do not know exists. Most teams have AI features running inside products they already pay for, deployed by whoever turned them on (UHY). Step zero is a quick inventory: which AI tools are doing real work, and who turned each on.

Do this before you need it

Every one of these steps is cheap when done in a quiet week and expensive when done mid-incident. Naming an owner takes a conversation. Writing four escalation triggers takes an hour. A one-page runbook takes an afternoon. The alternative is discovering, live, that nobody is sure who can turn the thing off.

If you want to see what this looks like end to end, our redacted example review walks through a real-shaped case where "nobody owns the assistant when it goes wrong" was the second-biggest finding — and what the fix was.

Want the runbook without building it from scratch?

Our AI Incident Response Pack gives you a list of incident types, a named-ownership map, an escalation path, a response runbook, a guide for vendor-caused failures, and a post-incident checklist — sized for a small team, not a SOC.