Three gaps between an agent and an insurable risk.
Insurers, auditors and supervisors look for the same things in a file: what the system is, who is watching it, and against which published standard it was built. Few organisations produce these for an autonomous agent yet. This is the framework we use to describe the distance, and the shape of what closes it.
How liability moves along the chain.
When an AI agent causes harm, three parties stand in different places. The Act binds the deployer to procedural duties, the revised Product Liability Directive binds the maker of a defective product, and the person harmed gets a rebuttable presumption in their favour.
The provider
Designs the AI system and places it on the Union market. Conformity assessment, technical documentation and, under Directive (EU) 2024/2853, strict liability for a defective product. AI Act Articles 16 and 25.
The deployer
Puts the system into service in the course of a professional activity. Use according to instructions, human oversight and logs under Article 26, and exposure to the presumption of defect under Article 10 of the Directive.
The affected party
The natural or legal person who suffers harm traceable to the system. Can ask a court to order disclosure of evidence under Article 9 of the Directive, and may rely on its presumptions.
An allocation of obligations, standards of proof and presumptions across the AI value chain under EU law. It describes the law; it is not legal advice.
Three artefacts decide whether a policy is possible.
The European market has underwritten software, cyber exposure and professional liability for decades. Dedicated AI liability cover has begun to appear, and most existing policies still say little about autonomous agents. With the three artefacts below an underwriter can price the risk. Without them, the default is exclusion.
-
01
The verification gap
The system cannot prove what it did. Most production agents run without a tamper evident log of prompts, tool calls, retrieved context and outputs. Where logs exist, they are kept for incident triage, not for external audit. An insurer or supervisor arriving after the fact cannot reconstruct the decision with certainty, and so cannot attribute harm to the behaviour of the system rather than to the user or an adjacent service.
Closing it takes three things: a durable record of the inputs the agent saw, the actions it took and the model versions active at the time; a cryptographic or otherwise tamper evident way of preserving that record; and a retention schedule that outlives the commercial life of the system, so that late claims can still be investigated.
-
02
The governance gap
No named person owns the agent's behaviour. Article 14 of the AI Act calls for human oversight by natural persons with competence, authority and support. In practice oversight is often diffuse: product, security and legal each assume another team holds the pen. When an incident occurs, the supervisor asks who was on watch, and the organisation cannot give a single answer that survives cross examination.
It closes when the operator keeps an oversight register: a short document naming the system, the people accountable for it, the thresholds that trigger intervention, the training those people received, and the reporting line to the board or an equivalent senior authority. It is the artefact underwriters and auditors ask for first.
-
03
The standards gap
There is no single yardstick yet. The AI Act does not prescribe technical standards. It invites harmonised standards through CEN and CENELEC, sits alongside existing instruments such as ISO/IEC 42001 and the NIST AI Risk Management Framework, and expects the market to converge. Convergence is slow, and in the meantime operators produce bespoke governance documentation that no outside party is obliged to accept.
It is the slowest gap to close, because it depends on bodies outside the operator's control. What an operator can do now is adopt ISO/IEC 42001 as the organisational baseline, map its controls to the NIST AI RMF functions of Govern, Map, Measure and Manage, and follow AIUC-1, the agent standard published by the Artificial Intelligence Underwriting Company (AIUC). An operator that does this is ready on the day a harmonised standard is published and cited by supervisors.
Each gap, and the question it answers.
How the three artefacts map to what an underwriter asks and to the instruments behind them.
| Gap | Operator artefact | The underwriting question it answers | Reference |
|---|---|---|---|
| Verification | Tamper evident activity log with defined retention. | Can the insurer reconstruct the agent's behaviour at the time of loss? | ISO/IEC 42001 § 8.3, NIST AI RMF Measure 2 |
| Governance | Oversight register with named people and escalation paths. | Who is accountable, and does that accountability reach the board? | AI Act Article 14, NIST AI RMF Govern |
| Standards | Attestation against a recognised framework with external review. | Against what baseline was the system designed and operated? | ISO/IEC 42001, AIUC-1, CEN and CENELEC harmonised standards work |
The short reading.
An operator that holds a verification log, an oversight register and a standards attestation has assembled a file that supervisors, auditors and insurers all recognise. None of the three can be produced after an incident. They have to exist in advance, kept as a live record of how the system runs, and be available on request. The work is procedural and unglamorous. It is also the only route available today to a defensible position under Article 26 and to a risk an underwriter can transfer.
The framework is deliberately narrow. It leaves aside the questions of AI autonomy, agency and moral status, and describes only the paperwork a European organisation needs to run an AI agent lawfully and to pass residual risk to an insurance market.
Agent Certified assesses one agent against a published rubric