Our AI wrote the code. Are we covered if it breaks?

The question underneath the question

When an operator asks whether AI-written code is covered, they are usually asking one of two quite different things and have not yet separated them. The first is whether a claim arising from a defect will be defended and paid the way a claim about hand-written code would be. The second is whether the fact that a model produced the code gives an insurer a reason to decline. Those have different answers, and the second one is the one that has moved.

On the first: insurance does not have a category for how a defect was authored. A claim is assessed on what you contracted to deliver, what the software actually did, who was harmed and how, and whether a policy in your programme responds to that kind of harm. A wrong calculation is a wrong calculation. Nobody at a claims desk asks which keystrokes were suggested.

On the second: the market has started writing exclusions whose defined term reaches you whether or not anybody at your business thinks of themselves as an AI company. That is the part worth reading closely, because it is decided by a definition rather than by an intuition about what your business does.

The definition names code

Two market forms are worth knowing by their wording rather than their reputation. Both were read from specimens of the form carrying the Insurance Services Office copyright line rather than from a filing record, and we say so every time we cite them.

A specimen of CG 40 48 01 26, headed "EXCLUSION" and "GENERATIVE ARTIFICIAL INTELLIGENCE (COVERAGE B ONLY)", modifies the commercial general liability coverage part and defines the term this way: "'Generative artificial intelligence' means a machine-based learning system or model that is trained on data with the ability to create content or responses, including but not limited to text, images, audio, video or code."

A specimen of CG 35 08 01 26, headed "EXCLUSION" and "GENERATIVE ARTIFICIAL INTELLIGENCE", modifies the products and completed operations liability coverage part and carries the identical definition, word for word.

Read what that definition does and does not do. It names code explicitly, alongside text and images, so there is no argument to be had about whether a coding assistant is in scope. It says nothing about autonomy, so a developer accepting a suggestion in an editor is inside the definition exactly as a self-directing agent would be. And it says nothing about review, so the fact that a senior engineer read the diff, understood it and approved it does not take the output back out of the definition. The whole endorsement in the first case is two sentences. Its brevity is the point: there is no carve-out to argue about because there is no carve-out.

A third form in the same series is widely described in broker and trade commentary as a broader version, removing both Coverage A and Coverage B rather than Coverage B alone. We have not read it. No specimen was obtainable, so we do not cite its number, its title, its edition or its wording, and we would suggest treating any source that quotes all four confidently with some caution, because the confident versions in circulation disagree with each other. What matters for you is not the form number in any case. It is whether an exclusion of this shape is on your schedule, which is a question your broker can answer in a day.

The broader map of what these endorsements do to a small business programme is at the AI absolute exclusion decoded, and the general shape of the exclusion landscape is at the guide to AI policy exclusions.

Route one: code you deliver to a client

The most common exposure by a wide margin. An agency, a consultancy, a contract development shop or a product company doing bespoke integration work writes software under a contract that says, in some form, that the work will be performed with reasonable skill and care and will conform to an agreed specification.

If the delivered software miscalculates, mishandles an edge case, loses data or fails at load, the claim is an ordinary professional negligence or breach of contract claim. It lands in professional indemnity, or in technology errors and omissions where the programme is structured that way. The route into difficulty is not the AI. It is that the client's loss can be very large relative to the fee, and that a small business often carries a limit sized to the fee rather than to the exposure.

What the AI adds is a specific and answerable question that will come up in the defence: was the standard of care met. That is not a question about tools. Using an assistant is not negligent, any more than using a framework or a library is negligent. Shipping something nobody understood is. The distinction is documented review, and it is worth knowing that the documentation you need is almost certainly already being produced by your version control system and simply never treated as an insurance record.

Route two: software sold as a product

Different route, different policy, and this is the one the second specimen form above is pointed at. Where software is sold as a product rather than performed as a service, or is embedded in something physical, the products and completed operations part is in play, and CG 35 08 01 26 modifies exactly that part.

This is the route that catches hardware businesses, device makers, and anyone shipping firmware or an embedded controller. It is also the route with the longest tail, because a defect introduced into a product in 2026 can produce a claim years later from a unit still in service, at which point the question of what your development practice was at the time is a question about records you may no longer keep. That tail is worth thinking about alongside the retroactive date on your policy, which is treated at agentinsured.eu, on retroactive dates and prior acts.

Route three: your own operations, failing outward

Not every piece of software a business writes is sold. Most of it runs the business: the billing job, the pricing rule, the stock allocation, the script that emails customers. A defect here does not produce a professional negligence claim, because there is no client and no professional deliverable. It produces something more ordinary and often more immediate.

A pricing defect that undercharges is a commercial loss you absorb. A pricing defect that overcharges is a consumer matter, and depending on scale and sector, a regulatory one. A billing defect that double-charges produces refunds, complaints and reputational cost. A scheduling defect that sends the wrong message to the wrong customer list is a data protection question rather than a software question.

The reason this route is worth naming separately is that it falls outside the two policies most businesses assume cover their software. It sits with general liability, with cyber, with regulatory exposure, or with nothing at all. The overlap with the internal AI question is direct, and the fuller treatment is at our AI is internal only, do we still need insurance.

Route four: the defect that is a security hole

A category of defect that behaves differently from the rest, because the consequence is not that the software does the wrong thing, but that somebody else can make it do the wrong thing.

Insecure handling of untrusted input, an authorisation check in the wrong place, a secret committed where it should not be, an outdated cryptographic choice reproduced because it is the pattern that appears most often in training data. None of these is unique to generated code. What is different is the mechanism by which they enter: an assistant reproduces patterns, and patterns include the common wrong ones. A code review calibrated to catch logic errors is not necessarily calibrated to catch a subtly missing check that looks entirely idiomatic.

When one of these produces an incident, the claim is a cyber claim, and it usually arrives as several claims at once: incident response cost, business interruption, third party liability, and a regulatory dimension where personal data is involved. Whether an AI exclusion in another part of the programme reaches across into the cyber tower is a wording question with no general answer, which is precisely why it should be asked in writing before you need to know. Our note on AI agent insurance where you already have cyber covers the boundary.

Route five: what the code brought with it

The narrowest route and the least discussed. Assistants suggest dependencies as readily as they suggest code, and a suggested package name is a supply chain decision made by a system that is optimising for plausibility.

Two distinct problems live here. The first is provenance: a package that does not exist, or exists under a name close enough to a real one that nobody looked twice. That is a security question and it belongs with route four. The second is licensing: code or a dependency arriving with terms that are incompatible with how you ship. That is not a security question and it does not land in cyber. It lands in intellectual property, and most small business programmes handle IP exposure narrowly if at all. We treat that separately in my AI copied someone else's work, is my business covered, and it is worth reading if you distribute software at all.

The thing that actually changed

It is tempting to locate the risk in the model. That is not where it is. Assistants produce code of variable quality, which is also true of people, and quality is not the variable that moved.

Throughput is. A team that produced a certain volume of code last year produces considerably more this year with the same number of reviewers and the same number of hours. Unless review capacity grew in proportion, and it almost never does, the share of shipped code that a human genuinely read and understood has fallen. Nobody decided that. No policy was changed. It is an arithmetic consequence of one input rising while another stayed fixed, and it is invisible in every metric a small business tracks, because delivery velocity went up and that reads as good news.

The insurance consequence follows directly. The defence to a negligence claim is that a competent person exercised judgement over the thing that failed. That defence gets thinner as the ratio moves, and it gets thinner silently. If you take one operational action from this article, make it the one that reads the ratio: how much code shipped, how much was reviewed by someone who could have written it themselves, and how has that changed since last year.

Four questions for your broker

All four are answerable from documents that already exist, and none of them requires you to characterise your business as an AI company.

1. Does any policy in our programme carry an exclusion, endorsement or definition that refers to artificial intelligence, machine learning or generated content? If yes, send us the wording rather than a summary of it, and tell us which policies it sits on.
2. If that wording defines generative artificial intelligence by reference to a system that can create content including code, does our use of coding assistants fall inside it, and what is the practical effect on a claim arising from delivered software?
3. Our professional indemnity, technology errors and omissions, products and cyber policies each cover a different route by which our software can cause loss. Where are the gaps between them, and does the answer change if the software was AI-assisted?
4. What is expected at our next renewal, and what would you want to be able to tell an underwriter about our development practice by then?

The fourth question is the useful one. Programmes are changing faster than businesses are, and the time to discover an exclusion is while you can still negotiate around it rather than after a loss. The script for the wider conversation is in what to tell your insurance broker about AI agents, and the pre-deployment version of the exercise is at the AI agent pre-deployment insurance checklist.

The record that decides the claim

A claim about software written eighteen months ago is decided on what your practice was eighteen months ago. Almost nobody can evidence that, and the good news is that most of the evidence already exists as a byproduct of ordinary engineering work. It just needs to be treated as a record rather than as infrastructure.

• Which assistants are in use, by which teams, and since when. Including the ones nobody procured, which in most small businesses is where the interesting answers are.
• Which repositories they are permitted in. A stated boundary is worth having even where enforcement is imperfect, because it evidences that a decision was taken.
• Review evidence with an identifiable reviewer. Your version control has this. Nobody has ever exported it for an insurance purpose.
• Dependency provenance. What was added, when, and on whose decision.
• The date any of the above changed. This is the one that gets forgotten and the one a claim turns on, because the question is never what your practice is today.

The same discipline, scored formally, is what a certification assessment examines, and the change control half of it is set out at agentcertified.eu, on change control as certification evidence. For a European business also thinking about where the regulatory line falls, the provider and deployer distinction that decides which obligations attach is at agentliability.eu, on the Article 3 definitions, and the position for operators outside the EU is at agentliability.co, on extraterritorial reach.

The honest summary

AI-assisted code is not uninsurable and it is not a new species of risk. It is ordinary software risk arriving faster than review capacity grew, inside programmes that are quietly acquiring a definition broad enough to catch it. The businesses that will have a bad time are not the ones using the tools. They are the ones that cannot say, at claim stage, which tools were in use, where they were permitted, and who read the code before it shipped. That list takes an afternoon to assemble and it is worth more than any wording argument you will ever have.

Questions

Does business insurance cover a bug in code an AI helped write?

There is no separate answer for AI-assisted code, which is both the good news and the problem. A defect in software you delivered is assessed the same way whatever produced it: what did you promise, what did the software do, who suffered a loss, and does a policy in your programme respond to that kind of loss. Professional indemnity or technology errors and omissions is the usual home when the software was a deliverable. Products and completed operations sits behind software sold as a product. Cyber responds to security consequences. The complication is not that AI code is uninsurable. It is that a growing number of programmes now carry an exclusion whose definition of generative artificial intelligence expressly includes the creation of code.

Does a generative AI exclusion apply to a coding assistant?

Read the definition rather than the exclusion. A specimen of market form CG 40 48 01 26 defines generative artificial intelligence as a machine-based learning system or model that is trained on data with the ability to create content or responses, including but not limited to text, images, audio, video or code. Code is named in the list. Nothing in that wording distinguishes an autonomous agent from a developer accepting a suggestion in an editor, and nothing in it asks whether a human reviewed the output before it shipped. If a programme carries an exclusion built on that definition, an ordinary coding assistant is inside the definition on its face.

Which policy responds if AI-assisted code causes a loss?

It depends on how the loss travelled, not on the tool. Software written for a client under a contract is professional indemnity or technology errors and omissions territory. Software sold as a product, or embedded in a physical product, engages the products and completed operations part. A defect that opens a security hole is a cyber question, and often several at once, because the same event produces a data claim, a business interruption claim and a third party claim. A billing or pricing defect in your own operations produces an ordinary contractual or consumer claim. No single policy owns AI-assisted code.

Does it help that a developer reviewed the AI output before it shipped?

It helps enormously in defending a negligence claim and not at all against an exclusion. Those are two different fights. Against a claim that you fell below a reasonable standard of care, contemporaneous evidence that a qualified person reviewed the change, understood it and approved it is close to the whole defence. Against an exclusion built on the definition above, the review step is invisible, because the wording asks what produced the content and not what happened to it afterwards. Review protects you from the claim and disclosure protects you from the coverage argument, and you need both.

Do we have to tell our insurer that we use AI coding tools?

If you are asked, you answer accurately, and proposal forms increasingly ask. Beyond that, the duty in most European and United Kingdom markets is to present the risk fairly, which means disclosing what a prudent underwriter would want to know rather than only what the form happens to ask. A material change in how your software is produced is the kind of thing that qualifies. The practical risk of silence is not usually a voided policy. It is a coverage argument at the worst possible moment.

What records should we keep about AI-assisted code?

Five, and all five are byproducts of ordinary engineering discipline. Which assistants are in use and by which teams. Which repositories they are permitted in. Evidence that changes were reviewed, in whatever your version control already records, with the reviewer identifiable. The provenance of third party dependencies, because a package name a model suggested is a supply chain event. And the date any of the above changed, because a claim turns on what your practice was on the day the defect was introduced rather than on what it is now.

Sources

1. CG 40 48 01 26, headed "EXCLUSION" and "GENERATIVE ARTIFICIAL INTELLIGENCE (COVERAGE B ONLY)", modifying the commercial general liability coverage part. Definition quoted verbatim: "'Generative artificial intelligence' means a machine-based learning system or model that is trained on data with the ability to create content or responses, including but not limited to text, images, audio, video or code." Read from a specimen of the form carrying the Insurance Services Office copyright line and form footer, 17 August 2026. This is a specimen rather than a filing record and is described as such throughout.
2. CG 35 08 01 26, headed "EXCLUSION" and "GENERATIVE ARTIFICIAL INTELLIGENCE", modifying the products and completed operations liability coverage part, carrying the identical definition. Read from a specimen on the same basis and with the same caveat.
3. A third form in the same series is described in trade and broker commentary as a broader version removing both Coverage A and Coverage B. No specimen has been obtained by this desk, so its number, edition date, title and wording are all omitted here rather than repeated from commentary. Circulating descriptions of it are mutually inconsistent on the title and the edition, which is the reason for the omission.
4. Regulation (EU) 2024/1689 (EU AI Act), Article 3, definitions of provider and deployer. Text at the European Commission AI Act Service Desk, ai-act-service-desk.ec.europa.eu.
5. Regulation (EU) 2026/1744, the AI Omnibus, in force 27 July 2026. Annex III standalone high-risk obligations apply from 2 December 2027 and Annex I from 2 August 2028. European Commission, AI Omnibus enters into force.
6. Policy structure described in this article reflects the common shape of professional indemnity, technology errors and omissions, general liability, products and cyber wordings in the United Kingdom and European markets. No individual carrier form is cited beyond the two specimens named above, and no clause identifier is asserted. Wordings vary materially between insurers and between renewals, and the only reliable answer is the one read off your own schedule.