Coverage-Ready: the 9 documents underwriters want before they'll insure your AI

What it is. A single register of every AI system your organization uses or ships: the model or product, its version, training date, validation date, deployment scope, and a named owner. It covers both AI you build and AI you buy, including the AI features inside SaaS tools your teams adopted without asking anyone.

Why underwriters ask. An underwriter cannot price a risk they cannot see, and most organizations genuinely do not know their own AI footprint. Model inventories are named specifically in WTW's description of where AI underwriting is heading [src]. The inventory is also the foundation document: every other item on this list refers back to it. In practice this is where I tell clients to start, because you cannot write an acceptable use policy or a risk register for systems you have not enumerated.

What good looks like. A maintained register, not a one-time spreadsheet. Each entry carries version, training date, validation date, deployment scope, and owner [src], plus a last-reviewed date. Good inventories distinguish customer-facing systems from internal ones and flag which systems touch consequential decisions. A stale inventory reads worse than an honest, short one.

What it is. The written rules for how people in your organization may and may not use AI: approved tools, prohibited uses, data that must never be entered into external models, and who approves exceptions.

Why underwriters ask. It is the fastest signal of whether AI usage is governed at all. An organization with no acceptable use policy has, by definition, ungoverned AI usage, and the underwriter must assume the worst case. The AUP appears first in published compilations of underwriter documentation expectations [src].

What good looks like. Short, specific, and enforced. It names the approved tools from your inventory rather than speaking in generalities, states clearly what data classes cannot leave your control, and defines consequences. It carries an effective date, a review date, and evidence that staff have acknowledged it (which connects to item 8, training records). A ten-page policy nobody has read is worth less than two pages with signed acknowledgments.

What it is. The document that says who is accountable for AI risk: the governance structure, decision rights, escalation paths, and evidence that oversight reaches board or leadership level, such as minutes or a standing agenda item.

Why underwriters ask. Governance practices are exactly what insurers now scrutinize before granting coverage [src]. Published expectations call for a governance framework plus a board-level oversight record [src]. Accountability that stops at the IT department tells an underwriter that AI risk is being treated as a technical issue rather than a business one.

What good looks like. Named roles rather than committees in the abstract: who owns AI risk, who approves new systems onto the inventory, who can order one shut off. Plus proof the structure operates, meaning dated records of leadership reviewing AI risk, not just a charter. For a small business this can be one page and a recurring leadership agenda item; scale of ceremony matters less than evidence it actually happens.

What it is. A living list of the ways your AI systems could fail and cause harm, tied to the systems in your inventory, with likelihood, impact, mitigations, and owners.

Why underwriters ask. Failure mode documentation is named directly in the direction of AI underwriting [src], and a risk register with AI failure modes appears in the published documentation set [src]. A business that has written down "our chatbot could give a customer harmful advice" and mitigated it is a different risk from one that has never asked the question.

What good looks like. Specific failure modes per system, not generic entries like "AI risk." Each entry links to a system in the inventory, states the harm scenario, the mitigation in place, and the residual risk you have accepted. Reviewed on a stated cadence. Underwriters read honesty well here: a register that acknowledges real residual risks is more credible than one where everything is marked mitigated.

What it is. Dated evidence that you tested your AI systems' outputs before and during deployment: validation results, bias and fairness testing where systems affect people, and records of what you did when a test failed.

Why underwriters ask. Bias mitigation is one of the specific practices the market is moving to underwrite [src], and bias testing plus validation records appear in the published documentation set [src]. Discrimination and bias claims are among the perils that AI-specific products are explicitly built to cover, which tells you where carriers expect losses [src].

What good looks like. Records, not policy statements: what was tested, when, against what criteria, what the results were, and what changed as a result. For systems that influence decisions about people, such as hiring, lending, or eligibility, the bar is higher and the testing should be recurring rather than one-time. If you rely on a vendor's testing, keep their documentation on file and note that reliance in your vendor due diligence file (item 6).

What it is. For every third-party AI product or model you depend on: the diligence you performed before adopting it, and the contract terms that allocate risk, specifically indemnity and performance commitments.

Why underwriters ask. Most organizations' AI risk is actually vendor risk, since most use AI they bought rather than built. The published documentation set calls for vendor due diligence files together with AI-specific contract provisions such as indemnity and performance SLAs [src]. An underwriter wants to know whether a vendor failure lands entirely on you or is contractually pushed back where it belongs.

What good looks like. A file per significant vendor: what you evaluated, what the vendor represented about their model, and where the contract addresses AI output, indemnification, and performance. Where contracts predate AI features, note the gap and your renewal plan honestly. Perfection is not the standard; knowing where your paper is thin is.

What it is. Your incident response plan, extended to AI failure scenarios: harmful or wrong output reaching a customer, model behavior changing after an update, discovery of biased outcomes. Plus a log of adverse outcomes that have actually occurred.

Why underwriters ask. The published documentation set specifies an incident response plan covering AI incidents together with adverse outcome tracking [src]. Claims cost depends heavily on response speed and containment, so a business that can detect, stop, and document an AI failure is a materially better risk than one that finds out from a lawsuit.

What good looks like. AI scenarios named explicitly in the plan, with a defined trigger, a person empowered to take a system offline, and a communication path. The adverse outcome log matters as much as the plan: a dated record of AI-related incidents and near misses, even minor ones, shows the tracking mechanism is real. An empty log at a company using AI heavily invites the question of whether nothing has gone wrong or nothing is being tracked.

What it is. Dated evidence that the people using AI systems were trained on your policies and on the limits of the tools: what the systems can and cannot be trusted to do, and what must be checked by a human.

Why underwriters ask. Employee training records appear in the published documentation set [src]. Policies without training are shelfware, and many AI losses are ordinary human misuse: unreviewed output shipped to a client, confidential data pasted into a public tool. Training records are the evidence that your acceptable use policy exists in practice, not just on paper.

What good looks like. Who was trained, on what, when, with completion tracked, and refreshed when tools or policies change. Content matters more than length: training that covers your actual approved tools and real failure modes beats generic AI awareness modules. New tools added to the inventory should trigger training updates, which is another reason the inventory (item 1) anchors everything else.

What it is. The document that defines where a human must review, approve, or be able to override AI output before it affects someone, and the evidence that those checkpoints operate.

Why underwriters ask. Documented human oversight is named specifically among the practices the market is moving to underwrite [src], and human oversight documentation for consequential decisions closes the published nine-item set [src]. From a liability standpoint this is the sharpest question of all: for the decisions that can really hurt someone, was a human in the loop, and can you prove it?

What good looks like. A defined list of consequential decision points drawn from your inventory and risk register, the oversight mechanism at each (review, approval, override), and operational evidence such as review logs or sign-off records. "A human checks everything" is not credible at volume; a specific, auditable set of checkpoints at the decisions that matter is.