Your policy now excludes the thing you automated.

Silence was never coverage

For most of the last decade, artificial intelligence was not mentioned in commercial policies at all. Teams read that silence as inclusion: nothing excluded it, therefore it was covered, therefore the risk of automating a decision was somebody else's balance sheet problem. That reading was always optimistic, and it is being closed from both ends. Insurers do not enjoy silent exposure — the uncosted, unmodelled kind that shows up in a portfolio only when it turns into a loss — and the standard response to silent exposure is to make it explicit. Explicit can mean an affirmative product priced for the risk. It usually starts as an exclusion.

The mechanism matters more than the trend, because the mechanism is what determines whether your operation is affected. An exclusion arrives as an endorsement on renewal. It is a page or two of wording that modifies a policy nobody reopens once it is signed, and it is negotiated by a risk or finance function that is describing a technical system it does not operate, to an underwriter who is assessing a technical system they cannot inspect. Both sides are working from a summary. The company producing that summary is usually the same one that has not written down what its document pipeline actually does when a field is ambiguous.

None of this is a reason for alarm about insurance. It is a reason to notice that a governance question everyone treated as a compliance exercise has acquired a second, sharper consequence. Controls used to matter because a regulator might ask. They now also matter because they determine which side of an exclusion your loss lands on, and that is a question with a number attached to it.

Where an extraction error actually falls

The reason document automation is exposed is not that document AI is riskier than other automation. It is that a document error is structurally awkward to classify, and coverage is organised by classification. A wrong number extracted from an invoice, a misclassified contract, a payment released against a duplicate — these cause financial loss through a route that no line of cover was designed around.

Read the table as a map of a gap rather than a list of denials. Each line has a defensible reason for its position, and in any individual claim the outcome turns on the specific wording, the jurisdiction and the facts. But the pattern is consistent enough to plan around: the more autonomous the document decision, the less naturally it fits the category each policy was drafted for, and the more the answer depends on an endorsement drafted recently and quickly.

What the wording is doing

AI-related wording appearing on renewals tends to take one of three shapes, and the difference between them is the difference between an operational problem and an existential one for a team that automates decisions.

The blanket exclusion

The broadest form removes loss arising out of, based upon or attributable to the use of artificial intelligence, often with a definition wide enough to include machine learning, generative models and algorithmic decision systems generally. The practical problem with a clause this wide is causation. Almost every modern document workflow touches a model somewhere; if the model touched the process, an insurer can argue the loss arose out of it, even where the proximate cause was a person approving something they did not read. A clause of this shape converts a manageable dispute about facts into a dispute about whether the exclusion applies at all.

The conditioned grant

The more workable form does not remove AI risk. It attaches conditions: cover applies where the AI system is used in accordance with stated controls — documented human review, defined authority limits, testing before deployment, a record of decisions. This is the shape most worth engaging with, because it is the one where engineering choices change the outcome. It is also the one that punishes a gap between the described system and the running system, because the condition is assessed against what happened, not what was written in the policy schedule.

The affirmative product

The third form is a specific grant for AI-related loss, sometimes with its own sublimit, its own retention and its own set of warranties. It is the healthiest direction for the market and the most demanding to buy, because the underwriting is real: the questions are technical, the answers are checked, and the price reflects the controls you can evidence rather than the controls you assert. Everything in the rest of this article is about being able to answer those questions with artifacts.

The human review you promised is now a term

This is the part most teams get wrong, and it has nothing to do with models. When a company applies for cover, someone fills in a form. The form asks whether AI systems make decisions autonomously or with human oversight, and the honest-feeling answer — the one that reflects the design intent, the architecture diagram and the internal policy — is that a person reviews the output. Then that answer is incorporated into the contract, sometimes as a representation, sometimes as a warranty, and sometimes as a condition precedent to cover.

The gap between those three words is worth understanding once. A representation that turns out to be materially wrong can put the whole policy at risk from inception. A warranty that is breached can suspend cover for the period of the breach. A condition precedent that is not met can defeat the specific claim. In each case, the thing being tested is not what the diagram said. It is what the system did on the day.

Now hold that against how document pipelines evolve in practice. A review step ships with the first release. Six months later, a confidence threshold is raised because the queue is too long. A month after that, low-value documents skip review entirely, which is a sensible operational decision made by people who have never seen the insurance application. A quarter later, straight-through processing is a headline metric on an operations dashboard and the review that exists is a screen where a reviewer approves a batch of forty in under a minute. Nothing here is misconduct. It is ordinary drift between the described system and the deployed one, and it is exactly what a coverage dispute will be built from.

Two consequences follow. The first is that a review step which cannot produce evidence of having been performed is, for this purpose, the same as no review step. The second is that nominal review is worse than acknowledged automation: a reviewer who approved without meaningful capacity to check attaches a name to the decision without adding any of the protection the clause was written to buy. If a workflow is going to run without a person, say so on the application, price the cover for it, and build the controls that make it defensible — which is a far better position than a review that exists on a slide.

Underwriting has started asking engineering questions

The questions on an AI-related application form have moved past "do you use AI" and into territory that a risk manager cannot answer without talking to the team that runs the pipeline. Treat the list below as the shape of the conversation rather than a specific insurer's form; the useful exercise is to try to answer each one with an artifact instead of a sentence.

Notice what is absent from that list: model accuracy. Nobody is asking for a benchmark score, because a percentage on a vendor slide is not assessable and everyone involved knows it. What is being assessed is whether the failure is bounded and whether the facts are recoverable — the same two properties that make a system defensible in front of a regulator, an auditor or a customer's counsel. That convergence is the genuinely useful news here: the evidence that satisfies governance is the same evidence that supports a claim, so this is not a second programme to fund.

The four artifacts that carry the argument

When a loss happens, the argument is not about whether the system was good. It is about whether the company behaved reasonably and within the terms it agreed to. Four artifacts do most of that work, and each of them is an engineering deliverable rather than a document produced by the legal team.

1. Thresholds that exist as configuration

A threshold policy stated in prose is an intention. A threshold stored as tenant configuration, versioned, with a record of who changed it and when, is a fact — and it is a fact with dates attached, which is what matters when the question is what the system was doing in March. The version history is doing the heavy lifting here: it demonstrates that the control was live at the time of the loss and, just as importantly, shows whether it had been quietly loosened in the weeks before.

2. Abstention as a recorded outcome

A system that can decline to answer is a different risk from one that always produces a value, and the difference is visible in the data. Escalation rate per field and per document type is the strongest single indicator that oversight is real rather than decorative — it shows the control firing, at a measurable frequency, on the cases it was designed for. A pipeline with a 0% escalation rate is either processing trivially easy documents or answering questions it should have declined, and an underwriter reading that number will reach the second conclusion.

3. Approval bound to consequence

Authority should be a function of what being wrong costs, not of what the model reports about itself. Payment above a value band requires named approval; a new counterparty requires a second check regardless of confidence; a reversible internal classification does not need either. This is proportionality applied to agent authority, and it converts an unbounded exposure into a bounded one — which is the property that makes a risk priceable at all, as opposed to excluded.

4. A log that reconstructs one decision

The test is narrow and it is the one that fails most often: given a document reference from 14 months ago, can you produce what the system extracted, from where on the page, which checks ran and with what result, which configuration and model version were live, whether a person was involved, and what they saw when they approved it. Not a dashboard. Not an aggregate. One decision, reconstructed, with integrity evidence that the record was not edited afterwards. This is the audit trail problem for non-deterministic systems and it is the artifact that decides whether a defensible position can be argued at all, because a claim without reconstruction is a claim about your general practices.

Four ways this goes wrong

1. Assuming last year's policy still means what it meant

Renewal endorsements are the least-read documents in a company. The specific failure is not that nobody reads them; it is that the person who reads them cannot map "algorithmic decision-making" onto the invoice pipeline, and the person who could map it never sees the page. The fix is procedural and cheap: whoever owns the document platform reads the AI wording on the current policies once a year, with the question "does this describe what we run" rather than "is this acceptable language".

2. Describing controls that production does not run

An application answered from the architecture diagram, the internal policy or the vendor's marketing page is answered from the wrong source. The only defensible source is the running configuration, and the uncomfortable version of this exercise is to check each answer against it before submitting — including the ones where the honest answer is worse than the one you would prefer to give. A slightly worse answer priced correctly beats a better answer that fails at claim time.

3. Retention shorter than the claim tail

Document decisions surface late. A wrong figure extracted today may appear as a dispute after an audit cycle, a contract renewal or a change of counsel, and by then the evidence has to still exist. Log retention set for operational debugging, or deletion driven by a storage bill, will routinely destroy the record before anyone needs it. Retention is a legal and commercial parameter with genuine tension in it — privacy obligations push the other way — and it should be set deliberately, per tenant and per document class, rather than defaulting to whatever the platform does.

4. Treating the vendor's cover as your cover

A supplier carrying insurance is useful context and it is not your protection. The limits are shared across their entire customer base, the cover responds to their liability rather than yours, and their contract almost certainly caps that liability at a fraction of what a consequential document error can cost. Ask instead for the things that change your own position: what the platform records, how long it keeps it, whether the record is tamper-evident, and whether you can export it without depending on the vendor's goodwill during a dispute. Those are procurement questions with contract answers, and they belong in the agreement rather than in a security questionnaire nobody revisits.

The trade-off, stated honestly

Everything above costs something, and the case for it is weaker than the confident version of this argument would suggest.

Insurance is not a control. A policy pays money after a loss; it does not stop a wrong payment, and it does not repair the customer relationship that the wrong payment damaged. Optimising a pipeline for insurability rather than for correctness would be a mistake, and the only reason the two point the same way here is that underwriters have, broadly, started asking for the controls that also reduce actual errors. Where they diverge, follow the errors.

The evidence has a real price. Reconstructible logs are the largest artifact class a document pipeline produces, and keeping them for years rather than weeks is a storage and privacy commitment, not a checkbox. Enforced authority ceilings reduce straight-through rates by design. A genuine review step is a staffing line. These costs are worth stating in the same paragraph as the benefit, because a plan that hides them gets dismantled at the first budget review — and a control that was removed for cost reasons is, at claim time, indistinguishable from a control that never existed.

Leverage is unevenly distributed. A company placing a large programme can negotiate wording; a smaller buyer is usually handed a form and asked to sign it. If that is your position, the realistic goal is not to change the endorsement. It is to know precisely what it excludes, to price the retained risk deliberately, and to put the strongest controls on the specific decisions where an uncovered loss would actually hurt — which means knowing which of your document workflows those are.

And the obvious caveat, which is not a formality: this is a technical argument about controls and evidence, not legal or insurance advice. Wordings differ, jurisdictions differ, and the outcome of any real claim turns on the specific contract in front of you. The right conversation is between your broker, your counsel and the people who actually operate the pipeline, in the same room — and the value of that meeting depends almost entirely on whether the third group can produce artifacts when the first two ask.

What to do before the next renewal

A short and genuinely achievable sequence, in the order that produces the most information per hour spent.

• Read the AI wording on the policies you already hold — professional indemnity, tech E&O, cyber and crime — and write one sentence per policy describing what it does to your document workflows.
• List the decisions the system makes alone — not the features, the decisions: what gets committed without a person, at what value, in which workflows, under which threshold configuration.
• Reconcile the last application against production — take each control you described and check it against the running configuration, noting every place where the described system and the deployed one have drifted apart.
• Run one reconstruction drill — pick a decision from a year ago and try to rebuild it end to end; whatever is missing is the gap, and it is cheaper to find it now than during a dispute.
• Fix the authority ceilings first — bounded exposure is the change that most improves both the underwriting conversation and the actual risk, and it is usually a configuration change rather than a project.
• Bring the operator to the broker conversation — the person who can describe what the pipeline does when a field is ambiguous is the person whose answers determine the terms.

Closing thought

The interesting thing about AI exclusions is not that insurers are retreating. It is what they are retreating from: not the technology, but the unmeasurable version of it — systems whose failures are unbounded and whose decisions cannot be reconstructed. That is a coherent position, and it happens to be the same standard that a regulator, an auditor and a customer's lawyer will each apply for their own reasons. A document pipeline with authority limits, real abstention, versioned thresholds and a log that can rebuild one decision from 14 months ago is easier to insure, easier to defend and, incidentally, wrong less often. A pipeline without those is uninsurable for exactly the reason it is ungovernable.

At Cogneris we build extraction so that the record exists before anyone needs it: configurable thresholds per field and document type, human review on what does not clear them, approval bound to value rather than to model confidence, and tamper-evident audit metadata that records what was extracted, what was checked and who released it — with retention set per contract rather than by a default. If you are automating document decisions where a wrong value would become somebody's claim, the useful starting point is the reconstruction drill: pick one decision and see what you can rebuild. See how the API models these boundaries, the pricing page, or talk to our team. Coverage was never the control. The record is.