Responsibility when AI applications make a mistake

An AI application makes a mistake. A decision is wrong, advice is misleading, a customer is unjustly rejected. The question that follows is not only technical. Who should have seen this coming, who managed the system, and who can explain why it was deployed the way it was.

That answer does not exist apart from a register. Responsibility presupposes that someone knows an application exists, what it is for, and who is in charge of it. Without that basis, the question of liability is rhetorical: there is no one who knows, so there is no one who can explain it.

What an inventory does and does not solve

A Responsible AI Scan maps out what is running, who uses it and what risk level that involves. That is a starting point, not a verdict on blame. The scan classifies an application by role and risk; it does not assess whether an individual decision was correct. That assessment belongs to the incident itself, not to the inventory that preceded it.

What the scan does provide is the structure within which that assessment can later be made. If it is known who acquired an application, who manages it and for what purpose it was approved, there is a line to fall back on. Without that structure, the question of responsibility falls back on guesswork after the fact.

The IT list is not the practice

Most organisations have an overview of approved software. That overview is almost never complete. Employees use tools that no one has registered, often because the work goes faster and no one asked. That is not by definition irresponsible behaviour; it is what happens when an organisation offers no other way.

Anyone who wants to know what is actually being used has to ask. And that only works if asking has no consequences. As soon as an employee suspects that an honest answer leads to a corrective conversation, the answer stops. What do you do about employees who use a tool no one has approved is about exactly that mechanism: the inventory is only as good as the trust with which it is gathered.

This also raises the question of what happens to company information the moment it is typed into an external window. What do you do about company data in a free chat window describes a risk that has nothing to do with malicious intent: someone simply wants a text checked, and in doing so types along something that should not have been shared.

Demonstrability, not guarantee

A governance set that follows an inventory arranges who approves an application, who exercises oversight and how that is recorded. This aligns with the risk structure an organisation already has for other domains: the same committees, the same reporting lines, the same escalation paths. No new apparatus is added alongside the existing one; a category is added to what already exists.

This yields demonstrability: a board can show that something was reviewed, classified and that oversight was put in place. It does not yield a guarantee that an application will never make a mistake again. Those two are separate matters, and the scan makes no claim about the second. What it delivers is a basis on which a board can explain what was done, not an insurance against what may still happen.

Why a second process usually does not stick

A frequently made mistake is setting up a separate AI process, disconnected from the existing risk and compliance structure. That process gets attention at first and then fades into the background, because no one keeps maintaining a second system alongside the first. Why a second process alongside the existing one gets ignored explains why alignment with existing structures is not a matter of efficiency, but a condition for something to continue to exist.

It is also worth noting that an inventory is a moment, not an endpoint. New applications are added, existing ones change in function, and a classification that was correct at delivery is not automatically still correct a year later. How often should you reclassify and how do you keep an AI register up to date describe what that maintenance requires in practice, and why a register that was drawn up once will, within a foreseeable time, no longer match reality.

The people who work with these applications are, moreover, part of the solution, not merely a risk that needs to be managed. What employees do and do not understand about the systems they use determines whether a governance set means anything in practice. What does AI literacy mean for your employees addresses that aspect.

The next question

Once it is known which AI applications are running and who is in charge of them, a follow-up question naturally arises: which part of the work currently done manually is actually suitable to be handed over to an AI application. That is a different question from responsibility, but one that relies on the same inventory. The work scan from FTE TO AI calculates, per task, which part of the work can be taken over by AI, as a next step once it is clear what is already running and who decides on it.