Who Is Responsible When AI Causes Harm? Understanding Causality in AI Incidents

An AI system causes—or contributes to—a harmful outcome.

The immediate question is obvious:

What happened?

The harder question may ultimately matter more:

Why did it happen?

As AI systems become more autonomous and more deeply integrated into business operations, determining causality is becoming a critical part of AI incident management.

The harm may have resulted from the AI system’s behavior. But it could also have originated with a human prompt, a configuration decision, an organizational policy, inadequate controls, a third-party model—or some combination of them.

Understanding that chain of causation matters because what caused an AI incident can shape accountability, regulatory obligations, remediation, and potential liability.

Who is responsible when AI causes harm?

No single answer applies to every AI incident.

Responsibility depends on the facts surrounding the event, the parties involved, the technology being used, and the applicable legal and regulatory requirements.

That’s precisely why organizations need to investigate causality rather than conclude that “the AI did it.”

Consider the potential chain behind an AI outcome:

Human instruction → Organizational policies and controls → AI system/model → Autonomous action → Real-world outcome

A failure or contributing factor could exist at any point in that chain.

The important question isn’t simply whether AI was involved.

It’s how the harmful outcome occurred.

What causes an AI incident?

AI incidents can have multiple contributing causes.

Human prompts or instructions

An AI system may produce a harmful outcome because a user explicitly or inadvertently instructed it to perform a problematic task.

That raises questions about authorized use, employee training, access controls, and organizational policy.

Model or system behavior

The AI itself may behave unexpectedly or generate an outcome no user explicitly requested.

As organizations deploy more autonomous and agentic AI systems, this distinction becomes increasingly important.

Configuration and deployment

The underlying model may function as designed, but the organization’s implementation can create risk.

Permissions, integrations, data access, thresholds,s and workflow design can all influence an AI system’s behavior.

Policies and controls

Sometimes the technology isn’t the only issue.

An organization may lack an appropriate policy, control, escalation process, or human oversight mechanism that could have prevented or mitigated the outcome.

Third-party AI providers

Organizations increasingly rely on external models and AI services.

When those technologies contribute to harm, determining responsibility may require understanding what the provider controlled, what the deploying organization controlled, and how the system was actually used.

Multiple contributing causes

Perhaps most importantly, causality may not be binary.

A human prompt could interact with an organizational configuration and an unexpected model behavior to produce a harmful outcome.

In those situations, “human or AI?” is the wrong question.

The better question is:

What factors contributed to this outcome, and how?

Why does causality matter in AI incident management?

Causality transforms an AI incident from a technology problem into a decision-making problem.

Once an organization understands what happened, it may need to determine:

• Who or what contributed to the harm?
• Which organizational policies or controls were implicated?
• Which laws, regulations,s or frameworks apply?
• Does the event create reporting or notification obligations?
• What remediation is appropriate?
• Could the same event happen again?
• What evidence supports the organization’s conclusions?

These questions can affect accountability and potential liability.

They can also determine what an organization needs to fix.

If a problematic prompt was the root cause, the response might involve access, training, or acceptable-use controls.

If the issue arose from system configuration, the remediation may be technical.

If an autonomous system behaved unexpectedly, organizations may need to reconsider oversight, escalation, or deployment controls.

Without causality, remediation risks treating symptoms rather than the root cause.

How should organizations investigate causality in an AI incident?

Start the investigation with evidence, not assumptions.

Organizations should reconstruct the sequence of events surrounding the outcome:

• What was the system supposed to do?
• What inputs, instructions, or prompts did it receive?
• What data and systems could it access?
• What actions did it take?
• What policies and controls governed those actions?
• Where did actual behavior diverge from expected behavior?
• What harm or hazard resulted?
• Which human and machine decisions contributed to that outcome?

That creates something organizations increasingly need as AI becomes more autonomous: a defensible chain between instruction, action, outcome, and decision.

AI accountability requires more than knowing that AI was involved

As AI adoption grows, saying “the AI caused it” will rarely explain enough.

Organizations need to understand how humans, models, systems, policies, and controls interacted to produce the outcome.

That’s why causality should become a foundational component of AI incident management.

When something goes wrong, the critical questions aren’t only:

What happened?

They’re: Why did it happen? Who or what contributed to it? What obligations follow? And can we prove how we reached that conclusion?

Those questions turn AI incident response into defensible AI accountability.