Insurance and liability cover for AI-assisted development: the development controls underwriters ask about — and how to evidence them

Last reviewed 2026-08-21 · 8 min read

Underwriters of tech E&O and cyber policies increasingly ask how AI-assisted development is controlled — and the recast Product Liability Directive makes a software maker's development record part of its liability exposure. Demonstrable, verifiable development controls support the insurance conversation and the liability defence; terms, premiums and coverage decisions remain the insurer's and your broker's.

What it is

Two conversations about risk are converging on the same question. The first is with your insurer: technology errors & omissions (E&O) and cyber applications increasingly include questions about AI-assisted development — which tools, what share of the code, whether humans review machine-written changes, how releases are tested. Underwriters are not curious; they are pricing an exposure they cannot yet see in loss data, and they price uncertainty the way underwriters always have.

The second conversation is with the law. From 9 December 2026 the recast Product Liability Directive treats software placed on the EU market as a product under strict liability, gives courts the power to order disclosure of how it was built and attaches a presumption of defectiveness to non-disclosure. The Cyber Resilience Act adds documentation duties and reporting clocks from 11 September 2026. An insurer that will one day handle a claim under those regimes wants to know, today, whether the insured can produce the record the court will ask for.

Both conversations reward the same thing: demonstrable development controls — not a policy that says changes are reviewed, but evidence that they were, for any change, in a form a third party can check. A recorded development chain is that evidence. It does not set your premium, define your cover or decide a claim. It lets you answer the questions with data.

Who it applies to and when

Software companies and software-intensive businesses buying or renewing tech E&O and cyber cover, product companies whose software now falls under product-liability regimes, and agencies and consultancies whose professional indemnity depends on showing a controlled delivery process. Brokers and underwriters sit on the other side of the table; counsel sits beside you when a claim arrives.

The timing is set by renewal cycles and by the regulatory calendar. Applications are asking about AI-assisted development now. The Product Liability Directive applies to products placed on the market from 9 December 2026; the CRA’s reporting duties start 11 September 2026, with full application 11 December 2027; the AI Act’s transparency rules apply since 2 August 2026 and its human-oversight duties for high-risk systems phase in from 2 December 2027. Each date moves a question from the optional section of an application to the required one.

This topic is not part of our regulatory mapping. Insurance is a contractual market, and liability is decided case by case; the support section below uses the mapping’s vocabulary and is explicit about what stays with the insurer and your counsel.

What it asks of your development process

Read the development section of a current E&O or cyber application and the asks are familiar:

Change control. Are changes authorised, reviewed and tested before release? Can you show it per change?
AI governance. Which AI coding tools are used, how much of the code do they write, is their output reviewed by a human, can you tell the two apart?
Secure development and vulnerability handling. Is there a defined process, does it run, how fast are fixes shipped?
Release discipline. Can you tie a production release to the changes and checks behind it?
Records. If a claim arrives, can you produce the record of how the product was built — and will it be believed?

The last point is where insurance and liability meet. In a product- liability claim under the recast directive the manufacturer may be ordered to disclose evidence of the product’s development, and a court may presume defectiveness if it does not. The “development risk” defence — that the defect could not have been discovered given the state of knowledge at the time — is inherently time-stamped: it depends on showing what was known and checked then. An insurer handling such a claim needs the same contemporaneous record the court does; an insured that can only reconstruct its process after the incident is a harder risk to defend and, before that, a harder risk to price.

The honest limits matter here more than anywhere. A record does not make a defect less likely, does not create cover, and does not decide liability. It makes the controls you actually run visible and verifiable — to the underwriter before the policy and to counsel and the insurer after a claim. That is what the questions on the application are trying to establish.

A note on proportion, because insurance conversations attract overstatement. No record changes the probability that software fails; it changes what can be shown afterwards, and what can be shown before. Underwriters know the difference, and they reward the second kind of change modestly and the first kind not at all. The useful framing for an application is therefore not “we have an evidence tool” but “here is how our development controls operate, per change, and here is the record you or a loss adjuster could inspect” — the same framing a court’s disclosure order would demand. Brokers who have read a thousand applications recognise a controlled process when the evidence of it is ordinary and continuous rather than produced for the form.

What OLOBOLO evidence supports

OLOBOLO records each change with its author (human or agent, with tool and model), the human review that approved it, the test evidence and the sealed release it shipped in — append-only, hash-chained, time-anchored with RFC 3161 and exportable for any third party to verify. The table uses our mapping vocabulary; this is not a regulatory mapping — insurance terms and liability outcomes are the insurer’s, the broker’s and the court’s, never ours.

Underwriter / claims question	What you need to show	Chain evidence	Support
Are changes reviewed and tested before release, incl. AI-written ones?	Per-change authorship, human approval and test linkage	`change.authored` (actor type, tool, model) → `change.reviewed` → `test.evidenced` → `release.sealed`	Supports
Can you show how a product was built if a claim or disclosure order arrives?	A contemporaneous, tamper-evident record that predates the dispute	Canonical chain export with RFC 3161 anchors; release evidence reports; open-source verifier	Supports
How fast are vulnerabilities remediated?	The fix’s timeline from authorship to release	The fix’s chain trail with time anchors	Partially supports
Security programme maturity, incident history, financials, contract terms	Broader underwriting inputs	—	Out of scope
Cover, premium, policy wording, claims decision, liability outcome	The insurer’s, the broker’s and the court’s decisions	—	Out of scope

“Partially supports” on remediation is honest: the chain evidences when a fix was authored, reviewed, tested and released; the operational incident response around it is a process the record reflects but does not run.

Evidence, not a legal opinion: this maps what the chain supports as documentation — your broker, insurer and counsel decide what cover and liability require.

How to start

Record before the renewal. Install the recorder on the repositories behind the products and services the policy covers; the next application’s development-control questions then have a record behind every answer.
Make AI authorship and human review explicit. Agents carry tool, model and session in commit trailers; approvals land as change.reviewed. “Is AI-written code reviewed by a human?” becomes a figure, not a claim.
Seal releases. Each sealed release and its evidence report is the “how was this built” answer — for the underwriter now and for counsel if a claim arrives.
Bring your broker and counsel in. Share the export and the mapping; let them decide how the record is used in the application and in any claim. The record is ours to keep honest; the conclusions are theirs.

Evidence can't be reconstructed after the fact — it has to be recorded while you build. Start recording now, free, and every change from this moment is on the record.

Start recording

Frequently asked questions

Will a recorded evidence chain lower our premium?

We cannot promise that, and no vendor honestly can. Pricing is the insurer's decision. What a verifiable record does is let you answer the underwriter's questions about development controls with evidence instead of assertions — which is what the questions are for.

Which policies ask about AI-assisted development?

Technology errors & omissions (professional indemnity for software) and cyber policies are where the questions appear first, in the application's development-practice and change-control sections; product-liability cover for software products is the emerging third, given the Product Liability Directive.

How does this connect to the Product Liability Directive?

Under the recast directive a court can order disclosure of how a software product was built, and non-disclosure can create a presumption of defectiveness. A contemporaneous record is what answers that order — which is also the record an insurer handling the claim will want to see.

Is OLOBOLO offering insurance or legal advice here?

No. This guide describes what development evidence supports in an insurance and liability context. Cover, wording and claims handling are for your broker, your insurer and your counsel.

Sources

Last reviewed 2026-08-21. Dates are cross-checked against our regulatory mapping and radar.

A necessary honesty: OLOBOLO is evidence, not a legal opinion. This guide describes what our chain supports as documentation — Supports / Partially supports / Out of scope — and your counsel decides what compliance requires. No tool can promise the latter.