Who Gets Blamed When the Model Is Wrong?

A hospital uses a diagnostic tool that misidentifies a serious condition.

A bank’s automated system denies loans in a pattern that appears discriminatory.

A city’s predictive policing model recommends increased patrols in specific neighborhoods, leading to escalation.

In each case, the question eventually arrives:

Who is responsible?

The chain is long: the model made a recommendation, the system executed it, the company deployed it, the provider built it, the employee oversaw it, the person affected suffered the consequences.

The problem is not that nobody is at fault—it’s that everyone can point elsewhere.

The Pointing Chain

The developer can say they built a tool, not a policy.

The company can say they used a commercially available product.

The employee can say they followed the established procedure.

The provider can say their terms of service disclaim liability.

The model cannot say anything at all.

Each step in the chain is technically correct.

The model is a computation.

The provider built it.

The company bought it.

The employee used it.

The customer trusted it.

Technical correctness, however, is not the same as moral or legal responsibility.

As AI moves from advisory roles to decision-making roles, we are discovering that existing systems for assigning responsibility were designed for a world in which humans made decisions and humans could be held accountable.

When the machine participates, we are still learning where the blame should land.

The Liability Question Is Becoming Real

For years, artificial intelligence operated primarily in a gray zone of moral responsibility.

We could talk about bias, fairness, and transparency.

But actual liability was rare.

That is changing.

Regulators are beginning to treat AI harm as a concrete legal problem, not a hypothetical one.

European enforcement mechanisms are moving toward a model in which providers, deployers, and users may all bear responsibility depending on their role in the decision chain.

The United States, by contrast, has taken a more fragmented approach: sector-specific regulations, state-level oversight, and a patchwork of industry standards.

The difference is not merely academic.

When a banking algorithm denies a home loan to a qualified applicant, does the responsibility lie with the bank that used the system, the company that sold it, or the engineers who trained the model?

The answer may depend on which legal system you are in.

That creates a problem for institutions operating across borders.

The Gap Between Capability and Control

Part of the difficulty is that AI systems increasingly perform tasks that organizations never directly taught them to do.

A model trained on general medical knowledge may diagnose a condition the hospital never explicitly asked it to consider.

A customer service system trained to resolve disputes may make offers the company never approved.

A hiring tool designed to screen résumés may reject candidates for reasons the developers never anticipated.

This is not necessarily a failure.

It is a property of systems that learn from data rather than being explicitly programmed.

But it creates a responsibility gap.

If a human employee takes an action the employer never authorized, the employer is typically still liable.

If an AI system does the same, the employer may claim they did not instruct the machine to behave that way.

The question is whether an organization can delegate authority to a system it cannot fully predict.

Liability Often Falls on the Deployer

In practice, the pattern that is emerging is straightforward:

The deployer usually gets blamed.

When a mortgage lender uses an algorithm that systematically disadvantages minority borrowers, the lender faces enforcement action.

When a hospital uses a diagnostic tool that fails to detect a serious condition, the hospital is sued.

When a city deploys a facial recognition system that misidentifies innocent people, the city faces lawsuits and public criticism.

The provider of the system may also be drawn in.

But the institution that deployed it and put it into contact with the public is rarely able to escape responsibility by pointing at the vendor.

There is logic to this.

The deployer chose to use the tool.

The deployer integrated it into their workflow.

The deployer made decisions about how it would be used.

The deployer is also the entity best positioned to oversee the system and catch problems before harm occurs.

But this creates a tension.

Organizations are being held accountable for systems they may not fully understand and cannot completely control.

The Provider Problem

From the provider’s perspective, this is a difficult position.

Build a system that is too limited, and customers will not buy it.

Build a system that is too powerful, and you may become a co-defendant when something goes wrong.

Most providers attempt to solve this problem through terms of service.

The contract typically says: we provide the tool; you are responsible for how you use it.

That is legally sensible.

It is not always practically meaningful.

If a provider knows their system will be used for high-stakes decisions and provides limited documentation, limited testing tools, or limited transparency about how it reaches conclusions, they may still face questions about their responsibility for the harm.

Regulators are increasingly asking whether providers have a duty to ensure their systems are safe for the uses they enable.

If a company sells a car with a known defect, they are liable.

If a company sells an AI system with known failure patterns, the legal standard is still evolving.

The Employee in the Middle

There is another person in the chain who often receives little attention:

The employee who actually uses the system.

The loan officer who signs the rejection.

The doctor who reviews the diagnosis.

The police officer who acts on the recommendation.

These individuals are sometimes positioned as a safety check.

The idea is that a human will catch the machine’s mistakes.

In practice, this can be unfair to the human.

If an employee overrides an automated recommendation and is wrong, they are responsible.

If they accept the recommendation and it is wrong, they may still be responsible.

The system creates a double bind.

It also creates a psychological problem.

If a person knows that questioning the system will increase their workload and accepting it will not, organizations should not be surprised when employees defer to the machine.

That is not laziness.

It is rational behavior in a system that makes human review expensive and automatic acceptance cheap.

The Person Who Was Harmed

There is one more participant in the chain who rarely appears in policy discussions:

The person who was harmed.

The applicant who was denied a loan without explanation.

The patient who received the wrong diagnosis.

The citizen who was stopped based on a flawed prediction.

These people rarely chose to interact with an AI system.

They may not even know one was used.

They simply want a decision reviewed, an error corrected, or a harm acknowledged.

Existing legal systems are often slow to provide any of those.

The time between harm and resolution can stretch into years.

The person who was harmed may never receive a clear explanation of what went wrong or why.

This is not merely a legal problem.

It is a legitimacy problem.

If institutions deploy powerful systems that affect people’s lives but cannot provide meaningful redress when those systems fail, people eventually stop trusting the institutions.

Responsibility Must Be Explicit

The emerging pattern suggests that organizations need a new approach to AI accountability.

They cannot treat AI deployment as a technology adoption problem alone.

They must treat it as a responsibility allocation problem.

Before deploying a system, an organization should be able to answer:

Who will be harmed if this goes wrong?

Who is responsible for catching errors?

Who has the authority to override the system?

Who will answer to the person who is harmed?

How will we know the system is working as intended?

Those questions are not technical.

They are organizational.

The institutions that get this right will not necessarily be the ones with the most advanced technology.

They will be the ones that recognize that AI does not remove responsibility from the chain.

It merely moves responsibility to new places.

And those places must be named before the system goes live.

Dale Joseph is the author of Thought Partners: Preserving Cognitive Sovereignty in the Age of AI and founder of the Emergence Institute. He worked for years as a consultant helping install hospital networks before turning to writing and systems thinking. He lives in Boynton Beach, Florida.