AI Cyber Coverage: Governance Evidence Analysis

The new tell is not a regulator speech. It is policy wording, the part of the contract nobody reads until the claim file is open and the room gets quiet. AI risk is moving from conference panel material into the dull machinery of underwriting, exclusions, questionnaires, and evidence. That is where product and security teams should pay attention, because insurers rarely ask for documents they do not intend to use.

What affirmative coverage is really asking

Hunton Andrews Kurth, writing in its Law360 analysis, says insurers are responding to AI risk in two opposing ways: AI specific exclusions and affirmative AI specific coverages. The same analysis notes that 72% of S&P 500 companies discussed AI and related risks in annual securities filings, which is a useful proxy for where boards, brokers, and claims teams are looking.

Silent coverage is the old problem, where a cyber, professional liability, directors and officers, or product policy might respond without saying AI. Affirmative coverage is the more explicit version, where the policy names the exposure and then asks the insured to prove what it actually runs.

The arXiv paper Insurance of Agentic AI explains why the questions are getting more specific. It describes agentic AI systems as moving beyond information generation into autonomous planning, tool invocation, decision execution, and persistent modification of digital or physical environments. The paper identifies risk pathways including hallucinations, prompt injection attacks, autonomous decision errors, model drift, dependency failures, and cyber physical harms.

Translation: the underwriting file is no longer satisfied by saying a vendor has an AI feature.

Who gets pulled into the insurance file

Insurance of Agentic AI frames agentic systems as a continuum of autonomy and delegated authority, which is a more useful test than asking whether a product is fashionable enough to be called AI. If a system only drafts text for a human to review, the evidence burden looks different from a system that invokes tools, changes records, makes recommendations in regulated workflows, or triggers downstream transactions.

Security teams should expect questions about prompt injection, access control, logging, monitoring, and incident response. Product teams should expect questions about where the model sits in the workflow and who can override it.

Hunton Andrews Kurth’s point about exclusions matters here because an exclusion is not a philosophical objection to AI. It is contract language that can narrow what happens after a loss. If a company cannot distinguish customer facing models, internal copilots, vendor embedded models, and security automation, it will struggle to explain which exposure was actually insured. This is the glamorous world of compliance: naming things accurately before a claims adjuster does it for you.

What to document before renewal

Zurich Insurance Group and Microsoft, in their paper on artificial intelligence and algorithmic liability, break algorithmic risk into the model input phase, model design and development phase, and model operation and output phase. That is a practical structure for an AI insurance evidence file.

For each system, keep an asset inventory, the data sources or inputs it relies on, the development or configuration owner, the operating context, and the outputs that can affect users, customers, employees, or counterparties. If that sounds like a register, that is because registers are what happen when risk stops being abstract.

The arXiv paper also proposes looking at exposure assessment, scenario analysis, dependency mapping, and product design implications for insurance. In plain English, write down what could go wrong, which vendors or internal services the system depends on, what failure would look like, and who has authority to pause or roll back the system. Incident scenarios should include prompt injection, incorrect autonomous action, data leakage, model drift, and vendor outage if those fit the system.

The useful version is not a poster about responsible AI, it is a file that security, legal, product, and procurement can all recognize.

Vendor dependency maps deserve special attention. Zurich and Microsoft’s paper flags the role of external code repositories and data in managing algorithmic liability risk, and the same logic applies to model providers, orchestration tools, retrieval stores, monitoring services, and human review vendors. Your contract file should show data use limits, security obligations, incident notice duties, audit or assurance rights where available, and limits on subcontracting. If your vendor contract says less about AI than your sales deck, your insurer may notice.

Lawyers have a phrase for this. I will spare you.

Where regulation and underwriting start to overlap

The MIT Press article on credit underwriting and insurance under the EU AI Act says lenders and insurers use external credit scores, proprietary data sources, custom scoring models, and business specific rules to assess borrower risk, and that the EU AI Act raises classification and compliance questions for those activities. Mason Hayes and Curran’s EU AI Act risk category explainer likewise treats the Act as a risk classification framework, not a general mood board.

For companies operating in or selling into Europe, an underwriting question may therefore arrive wearing two badges: insurance evidence and AI Act governance. Builders stuck between jurisdictions will recognize the pattern. The law may require one set of documentation and the insurer may ask for another. Those are not the same thing, despite what slideware suggests.

A high risk AI assessment under the EU AI Act is not automatically an insurance submission, and an insurance questionnaire is not a compliance certificate. Still, the overlap is useful: inventories, model use policies, incident scenarios, vendor dependencies, and exclusion reviews are reusable evidence if they are maintained rather than assembled in a panic.

The next insurance renewal will not turn every AI deployment into a legal emergency. It will make vague answers more expensive. Product leaders should know which AI systems can affect users or records, security leaders should know how those systems fail, and counsel should know which policy wording includes or excludes AI exposure. The market signal is modest and practical: if AI is in the product or the workflow, it now belongs in the insurance file.