↑ Resources / Essay · Series
Part II of III The Confidence Infrastructure for Autonomous AI

The Law Has Assigned Liability. Nobody Can Yet Prove What Happened.

Essay · Regulatory · 7 min read · June 2026

Part I traced the historical pattern by which transformative technologies achieve scale: not through engineering alone, but through the confidence infrastructure, standards, inspection, insurance, that grows up around them. This essay examines the legal architecture that is now forming around autonomous AI, and the gap at its center.

Three regulatory frameworks are currently in force across the European Union that directly govern AI agents operating in enterprise environments. Each establishes a distinct set of obligations. Each, examined carefully, points to the same unresolved problem.

The EU AI Act, whose high-risk enforcement provisions take effect December 2, 2027, requires automatic logging of events throughout a high-risk AI system's lifecycle, log retention for a minimum of six months, causal reconstructability sufficient to enable human oversight, and technical documentation demonstrating compliance before deployment. It does not specify how logs must be structured, who must hold them, or what makes a record credible rather than merely present.

The Product Liability Directive 2024/2853, published in the Official Journal in November 2024 and entering national transposition by December 2026, extends strict liability to software and AI systems. It introduces rebuttable presumptions: where a claimant faces excessive difficulty establishing a causal link between an AI system's behavior and a harm, courts may presume both defect and causation. It establishes joint and several liability across the supply chain, developers, importers, substantial modifiers, platform operators. The defendant who cannot produce contrary evidence bears the loss.

DORA, the Digital Operational Resilience Act, has been in force since January 2025. It requires financial entities to maintain audit trails of third-party ICT provider interactions that are independent of the provider, not stored on their infrastructure, not dependent on their cooperation for retrieval, not subject to their retention policies. It mandates forensic evidence production within 72 hours of a significant incident. For banks, insurers, and investment firms using AI agents built on LLM providers, every model call is an interaction with a third-party ICT provider. The independent audit trail requirement is not optional.

Read together, these three frameworks establish something important: the law has already assigned liability for AI agent failures. What the law has not yet established, because it cannot establish it by fiat, is the information infrastructure that makes liability adjudicable.

The proof problem

When a steam boiler exploded in 1867, establishing what happened was difficult. But it was not conceptually impossible. The physical evidence existed. Metallurgical analysis could establish whether the steel was defective. Inspection records could establish whether maintenance had been performed. Witness testimony could establish the sequence of events. The causal chain, once investigated, could be reconstructed.

When an AI agent causes harm, when it approves a fraudulent transaction, when it retrieves a deprecated policy document and uses it to guide a consequential decision, when it is manipulated through prompt injection to exfiltrate sensitive data, the proof problem is fundamentally different.

The agent's behavior emerges from the interaction of a model, a context, a set of retrieved documents, a sequence of tool calls, and an input that may itself have been adversarially crafted. The model that produced the output may have been updated since the incident occurred. The context that shaped the decision may not have been logged. The tool calls that executed the harmful action may be recorded only in the logs of individual downstream systems, each of which captures its own slice of the event but none of which captures the complete decision chain.

In Moffatt v. Air Canada, the tribunal held the airline liable for incorrect information its chatbot provided, rejecting the argument that the bot was a separate legal entity. The precedent is clear: the organization that deploys an agent is responsible for what it does. What the case did not establish, because the facts did not require it, is what happens when the organization cannot reconstruct what the agent actually did.

Under the PLD's rebuttable presumptions, that inability is not neutral. If a claimant can establish that they suffered harm, and that an AI system was involved, and that the defendant cannot produce evidence demonstrating what the system did and why, courts may presume causation. The defendant who lacks the evidence trail does not simply face uncertainty. They face a legal presumption that works against them.

This is the liability gap. Not a gap in the law, the law is reasonably clear. A gap in the infrastructure that makes compliance with the law demonstrable.

What the DRCF called the "Many Hands" problem

In March 2026, four UK regulators, the Competition and Markets Authority, the Financial Conduct Authority, the Information Commissioner's Office, and Ofcom, jointly published a foresight paper on agentic AI. Among its most precise observations was what it called the "Many Hands" problem.

When multiple model providers, system integrators, platform operators, and deploying organizations all contribute to an agent's behavior, attributing responsibility for a specific outcome becomes extremely difficult. The deploying organization may have configured the agent correctly. The model provider may have updated the model in ways that changed its behavior. The tool provider may have modified an API. The data source the agent retrieved from may have been compromised.

Each party bears some responsibility. None bears it clearly. The DRCF's conclusion was equally precise: when something goes wrong, regulators expect to see who authorized what, when, against which data. Most organizations currently cannot produce that record for AI agent activity at the level of detail enforcement will demand.

The "Many Hands" problem is not primarily a governance design problem. It is an evidence architecture problem. The record that would allow responsibility to be attributed, and that would allow the PLD's rebuttable presumptions to be rebutted, does not currently exist as a standard infrastructure component.

The certification layer and its limits

The emergence of AIUC-1, the SOC 2 equivalent for AI agents, represents the most significant step so far toward building the certification layer of the confidence infrastructure.

AIUC-1's 51 requirements across six domains cover data and privacy, security, safety, reliability, accountability, and societal impact. The standard is updated quarterly, with the Q2 2026 revision introducing mandatory controls for MCP and A2A protocol security, runtime containment, and agent identity and access management. ElevenLabs' February 2026 certification, the first AIUC-1-backed insurance policy, demonstrates that the model works in practice.

Certification answers the question: did this system meet the standard at the time it was tested?

This is genuinely valuable. Enterprise procurement teams have a concrete signal. Insurers have an actuarial basis for initial underwriting. Regulators have documented evidence of due diligence.

But certification has an inherent temporal limitation that becomes acute when applied to probabilistic, non-deterministic systems. A SOC 2 report attests to the state of an organization's security controls at the time of the audit. For traditional software systems, the interval between audits is manageable, systems change on defined release cycles, and the gap between certification and current state is bounded.

AI agents are different. The model version changes. Behavioral drift accumulates. New attack patterns emerge. The agent that was certified in February may present a meaningfully different risk profile in June, not because of any discrete failure, but because of the compounding effect of continuous change.

AIUC-1 itself acknowledges this: its quarterly retesting requirement exists precisely because the threat surface moves faster than annual certification can track. But quarterly retesting is still point-in-time assessment of a system that operates continuously. The retesting tells you what the system looked like on the day it was tested. It does not tell you what it was doing on the day of the incident.

What liability adjudication actually requires

For the legal frameworks to function as designed, for the PLD's presumptions to be rebutted, for DORA's 72-hour reporting obligation to be met, for the EU AI Act's human oversight requirements to be meaningful, a specific category of evidence must exist for every high-risk AI agent deployment.

It must be complete. Every agent action, every model call, every tool invocation, every data retrieval, every decision point, must be captured. Partial logs do not satisfy forensic requirements. An investigation that must reconstruct the decision chain from fragmented records across ten vendor consoles will not produce the evidence that liability adjudication requires.

It must be continuous. The record must exist from the moment of deployment, not assembled retrospectively when an incident surfaces. Evidence that is gathered after the fact, in response to a claim, does not satisfy the regulators' expectation that controls were active between audit cycles.

It must be independent. An audit trail that lives on the model provider's infrastructure, is signed by the provider's keys, and is accessible only through the provider's console does not satisfy DORA's independence requirement. In a dispute involving the provider, its evidentiary value is compromised.

It must be tamper-evident. Software logs on a host that the defendant controls can be modified. The PLD's rebuttable presumptions cannot be rebutted by evidence whose integrity depends on the word of the party producing it. Tamper-evidence requires cryptographic integrity, every record signed at the point of capture, every record chained to the previous one so that any modification is detectable.

These four requirements, completeness, continuity, independence, tamper-evidence, define the behavioral data layer that the confidence infrastructure for autonomous AI requires. Certification bodies like AIUC establish what safe behavior looks like. Insurers price the residual risk. But both depend on this layer to function accurately.

It is the layer that, as of today, does not exist as standard infrastructure in most enterprise AI deployments.

The shape of what comes next

The historical pattern from Part I suggests how this resolves. The technology exists. The regulatory frameworks have been written. The legal consequences of inadequate governance have been established. What remains is for the infrastructure to catch up to the obligations.

Hartford Steam Boiler didn't wait for Congress to mandate boiler inspections. It built the inspection infrastructure because it had financial exposure to the outcome of every boiler failure. The insurers who are now writing AI agent policies will face the same pressure, as claim complexity increases, as adjudication reveals the evidentiary gaps, as the difference between insurable and uninsurable deployments becomes concrete.

The behavioral data layer, continuous, independent, tamper-evident, is what the market will require. Not as a regulatory checkbox. As the precondition for the legal and insurance ecosystem to function as designed.

KYDE Gateway

KYDE produces the continuous, independent, tamper-evident behavioral record that makes the PLD's rebuttable presumptions rebuttable and DORA's 72-hour reporting obligation achievable. Every agent action, every provider, one cryptographically signed ledger.