Accountability
Figuring out who has to answer for what an AI produces
- When an AI produces a bad result, the party who has to answer for it is usually split across several places. The builder, the service that packages the model, and the one who put it to use each carry a different share.
- Answering for something requires a record. Without a trace of what went in and what came out, there is nowhere to even point.
- "The AI said so" is not an excuse. Choosing that tool and putting it in that spot was a human decision.
- Having a review step and actually reviewing are not the same thing. A check that exists only on paper doesn't transfer accountability to anyone.
- Sorting this out before something goes wrong, by writing down what gets handed off and what a person still has to look at, works far better than arguing about it afterward.
Contents
1The analogy
Step into an elevator and there's a small inspection sticker on the wall. It names the company that inspected it, the date, and the date of the next check. That one slip of paper does something simple: it tells you where to ask when something goes wrong.
A single elevator has several hands on it. A company built the machine, a contractor installed it in the building, a management office looks after it day to day, and a separate inspector checks it on a schedule. If the doors suddenly won't open, it's hard to blame just one of them. That's why who did what, and when, ends up written on that sticker.
AI has several hands on it too. The party that built the model, the one who packaged it into a service, and the one who brought it into their own work are all different. Accountability is the work of sorting out which of these has to answer for what.
2In detail
Several hands touched it
A single AI result usually has three parties tangled up in it. The one who gathered data and trained the model, the one who wrapped that model in instructions and a screen and sold it as a service, and the one who pulled that service into their own work.
Each one controls a different slice. The builder knows what went into training and what the limits are. The seller decides what the tool is billed as being for, and whether anything filters out risky requests. The user decides where the tool got placed and whether a person actually looked at the result before it went out. Whatever slice a party could control becomes the slice it has to answer for.
So the same mistake can point to different places depending on where it actually broke. If the tool got dropped into a spot it was never fit for, that isn't a performance problem on the builder's end. If it was used exactly as advertised and still produced a bad answer, it's hard to pin that on the user alone.
No record, no way to ask
Sorting out accountability is mostly a matter of going back through records. What request went in, what material it was grounded in, what settings it ran with, who received the result and what they did with it — without these on file, there's nothing to trace a cause back to.
Without them, something strange happens. When a problem surfaces and nobody can show what happened at their own stage, everyone just points at everyone else, and nothing actually gets fixed. What's left is a dispute, and the same failure happens again.
With records, the story changes. You can see exactly where things went wrong and fix that one spot. A record isn't kept to punish someone — it's kept so the same thing doesn't happen twice.
A check that's only a formality
Plenty of places have a rule that says "a person reviews the output." But when hundreds of items come through a day and most of them are fine, review turns into habit. Once it becomes clicking a button while scrolling past screens, that step keeps its name and loses its substance.
The real danger here isn't that a result is wrong — it's that accountability looks like it moved when it didn't. A name is stamped on the review field, so on paper a person made the call. In practice, no one actually judged anything.
Making review real again means building conditions where reviewing is actually possible: cut the volume one person handles at a time, surface the supporting evidence alongside the result, or reserve human sign-off for the decisions that can't be undone. Ask someone to check everything, and they end up checking nothing.
Deciding ahead of time cuts down on fights
Splitting up accountability after something has already gone wrong is always too late. Places that run well decide beforehand: what this tool is for, what it's kept away from, which outputs a person must see before they go out, and who has the authority to shut things down if something breaks.
One more piece belongs here: telling the person on the receiving end that AI was involved. If they don't know that, even a result that feels off won't prompt them to ask questions. Tell them, and there's one more set of eyes catching mistakes from the outside.
3More precisely
Accountability isn't one single obligation. The duty to explain what happened and produce the reasoning, the duty to fix and reverse a mistake, and the duty to compensate for harm are three separate things. The first two are often shared between builder and user; the last one depends on contracts and on the rules of wherever it happened.
The analogy also breaks down in one place. An elevator's faulty part can eventually be found. AI often resists that. Opening up the model to ask why a particular answer came out frequently returns nothing a person can read as a reason, and the same question can produce a different answer next time, which makes the original moment hard to reconstruct.
That's why records on the AI side need to cover more ground than a part's service history. Which model, with what settings, grounded in what material, and what a human looked at before passing it along — all of that has to be kept together for anyone to trace it back later. Keeping the record is half of accountability by itself.
4Try it yourself
5Common misconceptions
It's easy to think a bad AI result is the maker's fault, but actually the larger share often belongs to whoever decided where to place the tool and how much to hand off to it.
It's easy to think clicking "reviewed" discharges the duty, but actually if the pace and volume made real judgment impossible, that click is a formality and nothing more.
It's easy to think sorting out accountability means finding someone to punish, but actually it's closer to finding which stage needs fixing so the same thing doesn't happen again.
7One-line summary
In shortAccountability is the work of figuring out who has to answer for what an AI produces, and that requires a record of what happened at every stage that touched it.
Spotted an error or have a better analogy? Suggest an edit · Last updated2026-09-02