Who is responsible when an AI system causes harm?

AI does not replace responsibility

An AI model is a component inside a larger system. A company may select the model, define the workflow, set permissions, integrate data, deploy the product and decide what happens when the system is uncertain.

Those choices matter because a harmful outcome can arise from more than the model itself. Poor data, unsafe integration, missing human review or inappropriate deployment can all contribute.

The European approach shows how the rules are evolving

The EU has been updating its product liability framework for digital technology. The revised Product Liability Directive explicitly treats software, including AI systems, as products for its purposes and addresses issues such as defects arising through software updates and certain forms of continuous learning under manufacturer control.

That does not mean every AI mistake automatically makes a provider liable. The applicable rules and facts still matter.

Risk controls can become evidence

From a product perspective, good governance is not just about compliance. Documentation, testing, logging, version control and incident response can help an organisation understand what happened when something fails.

The AI Act also creates obligations for certain high-risk systems, including requirements around risk management, documentation, logs and human oversight. These requirements reinforce a broader principle: organisations need to know how their systems are being used and controlled.

Contracts do not answer everything

Vendors often divide responsibilities through contracts: one party provides a model, another integrates it, and a customer deploys the final system. Contracts can allocate commercial risk, but they do not necessarily eliminate statutory duties or consumer protections.

That is why product teams should not treat a legal agreement as a substitute for technical safeguards.

A practical responsibility map

For an AI product, document who controls the model, data, prompts, tools, permissions, deployment environment and user-facing decisions. Define who monitors incidents and who can shut the system down.

This article is general information, not legal advice. AI liability is jurisdiction-specific, and organisations dealing with consequential decisions should consult qualified legal professionals.

Liability is not the same as model blame

When an AI system causes harm, it can be tempting to ask whether the model is responsible. In practice, legal and operational responsibility is more complicated. A model may be supplied by one company, integrated by another, configured by a third and used by an organization that makes the final decision.

The relevant question is often what each party did, what it knew, what it was expected to control and what the applicable law says. That is why AI governance cannot stop at model evaluation.

Product design can reduce uncertainty

Teams can make responsibility easier to manage by defining ownership before deployment. Who approves the use case? Who monitors performance? Who handles complaints? Who can disable the system? Who investigates incidents? If these questions have no clear owner, a failure can become an organizational problem before it becomes a technical one.

Clear product boundaries also matter. If a system is designed to recommend an action but a human must make the final decision, the interface should preserve that distinction. If the system is allowed to act automatically, the controls should reflect the higher level of authority.

Evidence matters after an incident

An organization may need to reconstruct what the system received, what it produced, what a human did and which version of the system was running. Useful logs can include timestamps, model or software version, relevant inputs, outputs, approvals and intervention events, subject to privacy and security requirements.

Logging should be designed with data minimization in mind. Keeping everything forever is not automatically responsible. The goal is enough evidence to understand and improve the system while respecting applicable privacy requirements.

Contracts help, but they are not a complete safety system

Vendor agreements can allocate responsibilities, warranties, indemnities and notification duties. They can also define service levels and restrictions. But a contract cannot turn an unsafe product into a safe one, and it may not remove statutory obligations.

Procurement teams should therefore ask for technical documentation and incident processes, not only legal clauses.

Questions organizations should answer

• What decisions can the AI influence?
• Which failures could cause meaningful harm?
• Who owns monitoring and incident response?
• Can the system be stopped or rolled back?
• What evidence is retained for investigation?
• Which vendor and regulatory obligations apply?

Questions readers ask

Can a company simply say “the AI made the decision”?

That phrase does not resolve responsibility. Organizations remain responsible for how they deploy systems and for complying with applicable law.

Does using a reputable AI provider eliminate risk?

No. A capable provider can reduce some technical risk, but the deployment context can introduce new risks. Organizations still need appropriate controls, testing and oversight.

What is the most useful first step?

Create a responsibility map for the complete workflow. Identify who provides the model, who configures it, who deploys it, who approves important actions and who responds when something goes wrong.

The practical lesson is that accountability should be designed before an AI system becomes operational. Clear ownership, traceability and escalation do not guarantee that harm will never occur, but they make responsible deployment more achievable and incidents easier to investigate.

How responsibility can be mapped before launch

A practical starting point is to draw the chain of decisions around the system. Who selected the model? Who configured it? Who supplied the data? Who integrated it into a product? Who decided where it could be used, and who monitors it after release? The answers may involve several organizations, but a contract or technical handoff does not automatically remove every legal duty.

Teams should document the intended use, foreseeable misuse, known limitations and the safeguards applied at each stage. For high-impact workflows, define who reviews the output, what evidence is required before an action is taken and how an affected person can challenge an outcome. These controls should be tested, not merely described. If the human reviewer routinely approves every recommendation without time or context, the nominal presence of a human may not provide meaningful oversight.

Evidence helps resolve incidents

When something goes wrong, investigators need to reconstruct the sequence of events. Useful records can include the version of the model and application, the relevant input, retrieved information, tool calls, human approvals, warnings shown to the user and the action ultimately taken. Logging should be proportionate and designed with privacy, security and retention requirements in mind; collecting everything forever is not a responsible default.

Procurement teams can ask providers for documentation of testing, limitations, change management, security measures and incident notification. Product teams should decide how they will evaluate updates and whether a change in model behavior requires a new review. These practices improve accountability even where the precise legal outcome is uncertain.

The central lesson is that responsibility should be designed into the system. A clear owner, a route for complaints, an incident process and an auditable record make it more likely that harm can be investigated and corrected. They also help organizations avoid treating “the AI did it” as an explanation that ends the conversation.