AIccountability: you can automate the work, you can't automate the blame

You can automate the work. You can’t automate the blame.

Read that again, because it’s the whole article and it’s the part everyone rushing to bolt AI onto their business is quietly pretending isn’t true.

I’ve written four pieces now on how AI works, where it fits, how to learn with it, and how to plot it against your business. Accountability has been standing in the corner of every single one of them, unaddressed. “The AI isn’t accountable, so the responsibility falls on you.” “No agent owns the outcome.” “Responsibility-heavy tasks — bad fit.” I kept pointing at it and walking past. This time we stop and take a deeper look at it directly.

So let me be blunt for the length of one article. If you’re deploying AI and you haven’t answered the question “when this is wrong, who answers for it?” you haven’t deployed a tool. You’ve deployed a liability. And you’ve probably handed it to someone who doesn’t know they’re holding it.

Why AI can never be accountable

Let’s kill the comfortable idea some people have first: that accountability is a feature the next model will ship.

It won’t. Ever. Not because the models aren’t good enough, but because accountability isn’t a capability. It’s not something you get better at by adding parameters. Ask yourself what being accountable actually means. It means there are consequences that land on you. You can be fired. Sued. Fined. Struck off. Made to pay something back. Made to explain yourself to someone who’s furious. Made to lie awake at night knowing you got it wrong.

Now point any of that at a model. Fire it? Sue it? Fine it? There’s nothing there to punish and nothing there that cares. It has no license to lose, no reputation to protect, no skin in the game, or just no game at all. It produces an output and moves on the same whether it just saved you an afternoon or torched a client relationship.

That’s not a bug in this generation of AI. It’s the definition of a tool. A hammer isn’t accountable for the wall. A spreadsheet isn’t accountable for the forecast. And an AI isn’t accountable for the decision no matter how much it sounds like it made one. Stop waiting for the version that can hold responsibility. There isn’t one coming.

The accountability gap

Here’s the part people don’t think thoroughly enough about. Accountability doesn’t vanish when you hand the work to something that can’t hold it. It’s afantasy that automating the task also automates away the responsibility for it. It doesn’t. The work moved, but the blame didn’t. It’s still sitting there, fully intact, looking for a human to land on.

And it always finds one. The developer who shipped the feature. The employee who copy-pasted the output into the email. The manager who signed off on the rollout. The founder who decided the whole thing should run on agents. Somebody in that chain is going to answer for it when it breaks. And the further from the keyboard you get and let the AI do the work on your behalf, the more likely it’s you, not the model, whose name is on it, while you didn’t even actually do it.

This is the accountability gap: the distance between the thing that did the work and the person who owns the outcome. AI doesn’t close that gap. It widens it and then quietly drops the whole weight of it onto whoever was standing closest.

“The AI did it”

Which brings us to the sentence I want you to ban from your vocabulary.

“The AI did it.”

It feels like an explanation, but it’s a reason and never an excuse. It functions like nothing. It is, precisely, a bad workman blaming his tools and you already know how that story ends. Nobody sympathizes with the workman. Nobody says “ah, well, the chisel slipped, not your fault.” They held him responsible, because he’s the one who picked up the chisel, and he’s the one who was supposed to know how to use it.

“The AI generated the wrong number” is not a defense. You chose to use AI for that task. You chose not to check it. You chose to put it in front of a customer. Every one of those was a human decision, and the model didn’t make a single one of them. Hiding behind “the AI did it” doesn’t transfer the blame, it just advertises that you didn’t understand where the blame was sitting the whole time.

No matter how the failure happens, no matter how many layers of automation it passes through, the blame lands on a person. Every time. The only real question — the one you should be asking before you deploy anything — is which person, and whether they signed up for it.

The disclaimer shield

Here’s a small five-word sentence that tells you the entire industry already knows this.

Look under the prompt box in Microsoft’s Copilot: AI-generated content may be incorrect.

Sit with that for a second, because it’s not a friendly heads-up. It’s a legal position. The company that built the tool, sold you the tool, and profits from the tool is telling you, in writing, that it will not stand behind what the tool produces. Read the terms of service on basically any of these products and you’ll find the same thing dressed up in more words: the provider disclaims responsibility, and the liability for what you do with the output is yours.

Think about what that means for the chain of blame. The AI can’t be accountable, we covered that, and now the vendor has explicitly, contractually stepped out of the way too. So when the output is wrong and something breaks, walk the line back: not the model, not the company that made the model. Who’s left standing?

You are. You were always the one left standing. The disclaimer isn’t a warning label, but a transfer of custody, and you accepted it the moment you hit enter or clicked ‘accept’ without reading page upon page of legalese writing just to use a simple tool.

When the chain erases accountability

Now make it worse, the way real businesses make it worse: chain the systems together.

I wrote about this in the first article — the multi-agent pipeline where one model’s output feeds the next, and a subtle error five handoffs upstream travels downstream, compounds, and lands in the final result with no stack trace to trace it back. Confident output at every step. No error thrown anywhere. Just a broken outcome and no obvious place to point.

Watch what that does to accountability. In a single system, at least you know where the failure happened. Distribute the work across a chain of agents and you distribute the failure and blame too, and although distributed failure doesn’t automatically becomes distributed blame, it does have a nasty habit of rounding down to nobody’s blame. “It wasn’t my agent, mine worked fine.” “The input it got was already wrong.” Everyone in the chain is technically correct and the outcome is still broken and somehow no single component owns it. You’ll end up with a situation I’d describe as: “The operation was a great success, but the patient died.”.

But the drumbeat holds: the blame didn’t disappear just because you can’t locate it. The customer who got burned holds your business responsible, not your fifth-agent-in-the-chain.

If you’ve done any ops work, this whole article is already familiar, because you’ve probably lived it.

Your service goes down at 3am. The root cause is a dependency you didn’t write — some library maintainer’s bug, some upstream provider’s outage. And you know exactly how much that matters when the pager goes off: not at all. You don’t get to reply to the incident with “not my code.” You own the service. You’re on-call for it. The fact that someone else’s component failed doesn’t move the responsibility one inch. It was your job to know your dependencies could fail and to build accordingly.

For some AI is becoming a dependency. The most confident, most convincing, least accountable dependency you’ve ever used. And it does not come with its own on-call rotation. When its output breaks something, the pager goes off on your phone.

That’s the reframe I want you to leave with. Accountability was never about who typed the line or generated the paragraph. It was always about who answers when it breaks. And a tool — any tool, including this one — cannot answer. It can’t hold the pager. Someone with a pulse has to, and that someone is you, whether you planned for it or not.

So how do you design it in?

Everything above is the diagnosis. Here’s the practical part, because “keep a human accountable” is easy to nod along to and easy to get wrong. If accountability has to be built in on purpose, this is what “on purpose” actually looks like:

Name the owner before you ship, not after it breaks: every AI-touched outcome has one human whose name is on it. If you’re assigning the owner during the post-mortem, you’ve already lost.
Give that owner real authority: the power to catch the error and overrule the output. Accountability without authority isn’t a safeguard; it’s a scapegoat with a job title.
Match the checker to the stakes: the more expensive being wrong is, the more the human in the loop has to actually verify the output, not rubber-stamp it. Low-stakes, let it ride. High-stakes, someone competent reads every word. Note: Watch out for the things that seem low-stake, and are (or become) high-stake 😉
No owner, no use case: if you can’t name the person who answers for a given use case, you haven’t found a use case an unassigned liability waiting for the worst possible moment to find an owner. Because when something has become a problem/liability, who actually wants to be its owner?

Conclusion — you don’t offload accountability, you design to keep it

So here’s the shift, and it’s the same shape as everything I’ve argued across this series. You don’t “adopt AI” and let responsibility sort itself out, because the one thing you cannot automate is the answering-for-it. You design it in, on purpose, or it lands on someone by accident.

Underneath the four rules above sits a single one: no outcome your business ships is allowed to be owned by “the AI.” Ever. That’s the truth the disclaimer told you and the pager taught you. Use AI for everything it’s brilliant at, being the structured, the repeatable, the verifiable, just never let it convince you it’s holding a responsibility it fundamentally can’t.

You can automate the work. You can’t automate the blame. A tool to enhance, not to replace and never a name to hide behind.

But here’s the catch, and it’s the one that’s been quietly undermining half of what I just told you. “Keep a human in the loop” (the answer I keep reaching for) only works if that human can actually catch the error. And thanks to everything I’ve written about the illusion of competence, that’s a much bigger if than it looks. Sometimes the human in the loop isn’t a safeguard at all. Sometimes they’re just there to absorb the blame for a system nobody could realistically supervise.

That’s the next edition. Safeguard, or blame sponge? We’ll find out.