AI Agent Causes Damage: Who Pays, and With What Evidence

Who pays for the damage an AI agent causes: the answer comes from two European texts and from a log file. EU Regulation 2024/1689 requires high-risk systems to record events. Directive (EU) 2024/2853 on liability for defective products, by contrast, leads to a presumption of defect when the requested evidence stays out of the proceedings.

In between sits everyday practice: an agent that touches accounting and payments either leaves a trail, or it leaves a gap.

The action log is the only witness

EU Regulation 2024/1689, Article 12, requires high-risk systems to automatically record events throughout the system's lifetime. The rule bears on design, ahead of operational choices: the system must be capable of recording.

When an agent gets a payment wrong, its log remains the only witness to the sequence.

People remember the outcome. The log preserves the order of the steps: which document came in, which tool was called, with which parameter, at what time. Anyone who wants to reconstruct the chain of the decision needs that trail, legible to third parties as well.

Six months of retention, and who answers for it

Article 19 places on providers the retention of the logs generated by their high-risk systems. The minimum period is six months, unless different terms are set by Union or national law.

Article 26(6) repeats the obligation for deployers, that is, for the companies that use the system in their own business.

Financial institutions have one extra rule: they keep the logs within the documentation already required under Union financial services law. For a bank, the agent's log therefore becomes supervisory documentation. The timeframes change, the format changes, who can ask for it changes.

High-risk: the perimeter and the 2 December 2027 date

These obligations apply to high-risk systems, so the perimeter has to be defined before anything else. An assistant that summarises internal emails falls outside; a system that assesses a natural person's creditworthiness falls within Annex III.

For the Annex III cases, the Digital Omnibus has pushed application back to 2 December 2027.

That date is a project window. Anyone signing a three-year contract on an agentic platform today is buying a system that will have to be compliant before the contract expires. The question for the procurement committee therefore becomes contractual: does the supplier guarantee compliant logging by that date, and under what penalty?

Directive 2024/2853 presumes the defect

Directive (EU) 2024/2853^[1] treats software as a product. Article 9 allows the court to order the defendant to disclose the relevant evidence in its possession.

Article 10(2)(a) adds the consequence: the defect is presumed when the defendant fails to make that disclosure.

Here lies the point that matters to anyone who builds. An architecture without verifiable logs creates an impossibility of proof, and the rule reads that against the party on the receiving end. Technical debt on observability becomes procedural debt.

Between businesses, the contract decides

Between businesses the game is played on the contract. The directive protects the injured person; the relationship between customer and platform provider runs instead on clauses, service levels and liability caps. In that dispute, the log says who caused the error.

Three typical cases, with opposite outcomes. The model produced a wrong output on correct data. The orchestrator passed the agent a context that was already dirty. The operator approved a proposal flagged as doubtful.

Each of these cases shifts liability onto a different party. And each is distinguished from the others solely by the execution trail, field by field. An expert report arriving two years later works on what the system wrote back then.

AI performance policies ask for controls

The insurance market has started writing cover dedicated to the performance of AI systems, alongside classic liability and cyber policies. The subject matter changes: what is insured is the gap between the promised result and the result produced.

Cover of this kind lives on measurement. To settle a claim you have to show the error, its date and its economic effect.

Underwriting follows the same logic. Whoever sells the policy looks at the design of the controls, the quality of the logging and the retention periods. Those who bring partial records pay more, or are left outside cover. Logging thus moves out of the compliance chapter and into the price of risk.

What an agent on accounting and payments must record

An agent operating on accounting and payments should be designed around a single question: who decided what, under which delegation, on which data, at which moment. Every field in the log answers a piece of that question.

• Agent identity: its own credential, never the human user's shared one.
• Active delegation: scope, amount thresholds, permitted counterparties, expiry of the mandate.
• Version: model, system prompt, tool catalogue, with a fingerprint for each.
• Retrieved inputs: identifier and hash of every document that entered the context.
• Tool calls: parameters, outcome, error code, repeated attempts.
• Human approval: who approved, what they saw on screen, at which instant.
• Time: synchronised timestamp, declared source, time zone expressed in UTC.
• Integrity: append-only writing, hash chain, immutable storage.

Two details separate a useful log from a debug file. The first is the link between the agent's proposal and the accounting entry, held by a common identifier that survives downstream too, inside the payment system. The second is the recording of rejected actions: the defence often runs through showing what the control stopped.

The log must then remain legible to someone outside the code. An external auditor opens the file and has to understand, line by line, which mandate covered the action. This requirement changes the format: stable field names, explicit values, declared versions.

Three questions for the team taking agents into production

There are three useful questions to ask before the next release on financial processes.

1. Does the log hold up as evidence in front of a third party, or does it take an engineer to read it?
2. Does retention reach the six-month minimum, and, for financial activities, the timeframes of supervisory documentation?
3. Does the supplier export the logs in an open format, or keep them inside its own environment?

The third weighs more than the others. A log that lives solely in the supplier's console creates architectural lock-in over the evidence: at the moment of the dispute, the company depends on its technology counterparty to demonstrate its own diligence.

Decisions for the next planning cycle: log export as a contractual requirement, a hash chain on every operation that moves money, a named identity for every agent. The liability clause needs revisiting too, in the light of Directive 2024/2853.

The log is defensive infrastructure. It is built before the damage, because afterwards only what was written remains.