The post-mortem is forty minutes in.

A script generated by an AI tool went to production after a single approval and no staging run, and it corrupted a batch of customer records. Support is flooded. Someone from the vendor side is on the call, and a team lead is sharing a screen full of logs.

Then comes the sentence.

“The model hallucinated.”

Nobody says anything. A few heads nod. The meeting starts to move toward fixes, patches, and a promise to “tune the prompts.”

And just like that, the question that matters has left the room.

Who decided this was ready to run?

Why the sentence is so tempting

In my last essay I wrote about the habit of saying “AI did it.” I argued that AI does not want, decide, or intend anything. It produces outputs. People build it, train it, sell it, deploy it, and trust it.

But knowing that in the abstract is easy.

Remembering it in a tense meeting, with a client waiting and a dashboard on fire, is much harder.

Because the hype has done its work. For years we have been told these systems think, decide, understand, and act. So when something goes wrong, “the model did something unexpected” feels like a natural explanation. It sounds technical.

It sounds honest. It sounds like nobody’s fault.

Most of the time, I don’t think people say it to deceive. They say it because the language they have absorbed gives the tool a mind.

The sentence is not always a lie. It is often a habit.

But habit or not, it does the same thing. It moves responsibility from people to a thing that cannot be held responsible.

So here is something practical. Four phrases I hear again and again when responsibility starts to slip, and calm questions that bring it back.

Phrase one: “The model decided.”

A system does not decide in the human sense. It produces an output based on how it was built, what it was trained on, and what it was asked to do.

So the useful question is not “why did the model do that?” It is:

“Who set the objective, and who set the threshold for good enough?”

Somewhere, a person or a team chose what the system was optimising for. Somewhere, a person decided the test results were acceptable. Those are the decisions worth looking at.

Share

Phrase two: “No model is 100% accurate.”

This one is true. And it is almost always used to change the subject.

Of course no model is perfect. That is exactly why humans are supposed to design checks around it.

The accuracy of the technology in general is not the issue in your post-mortem. What was promised, in your contract, your process, or your own team agreement, is.

The question:

“What did we agree this system would do, and what checks were supposed to catch it when it didn’t?”

If you buy from a vendor, this is where the contract matters. We do not sign service agreements with software. We sign them with companies.

Phrase three: “You don’t understand how fast things move.”

This one is personal, and it is easy to take the bait. You raise a risk, and suddenly the conversation is about your mindset instead of the risk.

You don’t need to defend yourself. You only need to bring the conversation back to the specific concern:

“Which risk are we disagreeing about? Let’s look at that one.”

Speed is a real pressure. But speed is also a human choice, and someone made it. Naming the risk keeps the discussion on the work, not on who is “behind.”

Phrase four: “Either we ship it now or we collapse.”

Whenever I hear only two options, I get curious about the third one.

There is nearly always a staged version.

Release to a small share of traffic. Sample the outputs by hand. Keep a person in the loop until the numbers earn trust. It is slower than the dream and faster than the disaster.

The question:

“What is the smaller, safer version we can start with?”

The five questions

These four phrases are symptoms. Underneath them, there is a simple structure I would run in every post-mortem, before anyone is allowed to blame the machine.

1. Who verified the data? If the system learned from or acted on bad data, which person approved that data to come in?

2. Who authorised the testing threshold? Who decided the results were good enough to go live, and what did they look at?

3. What was the override plan? When the signals turned red, who was supposed to step in? Why didn’t they, or couldn’t they?

4. Who owns the outcome? Who carries the commercial, legal, and human cost? Name a person and a company, not a tool.

5. What did we know about this system’s limits before we trusted it? This is the one I added, and it may be the most important.

These systems predict likely patterns. They do not understand your business, and they can be confidently wrong. If the team knew that, what protection did they build?

If they did not know, who was responsible for finding out?

Notice that none of these questions require anyone to be a villain. Most failures are not malice. They are skipped checks, rushed timelines, and unclear ownership. The point of the questions is not to punish. It is to put the responsibility back where it can be acted on.

Why this is a leadership skill

When we let “the tech failed” stand, we lose three things at once.

We lose the lesson, because we fix the tool and not the process that trusted it.

We lose accountability, because everyone leaves the meeting a little less responsible than when they came in.

And we lose a little more of our own judgment, because we are teaching the team that when things go wrong, the answer is always somewhere outside us.

Leadership is not only about what we do when things go well. It is about the questions we insist on when they don’t.

So the next time someone tells you the technology failed, don’t argue with the machine. Ask who reviewed it, who approved it, who was watching, and who turned it on.

And before you answer for yourself, pause for a moment and ask the questions from the last essay:

What do I believe about what happened?
What might my words be hiding?
What am I being asked to accept as inevitable?

Who turned it on, and who is standing behind it now?

Next: how to read an AI headline and find the human behind it.

About the Author
Diamantino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.

I’m pleased to partner with Cozora, a live AI learning community built for people who want practical skills, not hype.

Learn directly from experts who use AI every day, join interactive sessions, and see real workflows in action.

Use this link to receive 10% off your membership

Leadership as a verb

Who turned it on?