The Underwriter's File

Part 1 argued that when an AI underwriter has no loss table to read, they price the company instead, and the renewal questionnaire is the instrument they use to do it. This part is the file that questionnaire probes for: the nine documents that make a company insurable, and the frameworks that give the whole thing a language the underwriter already trusts.

The Nine Documents

---

It helps to give the file a shape, and the shape that the questionnaires converge on is roughly nine documents. They are not nine boxes to check and forget. Each one answers a distinct fear the underwriter carries into a risk they cannot price from a table, and the quality of each document, not merely its existence, is what moves the terms. A model inventory that is a stale spreadsheet nobody maintains is worse than none, because it invites reliance on a record the company itself does not trust. What follows walks through each document in turn, and the folio below the essay collects them into the checklist a buyer can actually work from.

The first is a model inventory. Before an underwriter can price how a company's AI might fail, the company has to be able to say what AI it runs. The inventory is the living register of every model in use, whether built in house or called through a vendor's interface, and of what each one touches: which decisions it informs, which customers it reaches, what data it consumes. This is the AI equivalent of knowing where the electrical panels and the fuel stores are in a building you are asked to insure against fire. A company that cannot produce this list is telling the underwriter, without meaning to, that it does not fully know its own exposure, and an underwriter cannot price an exposure the operator cannot even enumerate. The inventory is the foundation the other eight documents sit on, because every one of them refers back to specific systems the inventory names.

An underwriter cannot price an exposure the operator cannot even enumerate.The underwriter's file

The second is a record of human oversight, the human-in-the-loop and human-on-the-loop controls that sit between the model and a consequential outcome. Underwriters are acutely aware that the worst AI harms tend to arrive when a machine's output flows straight through to a customer or a decision with no competent human between them. The document that answers this fear describes, system by system, where a person reviews, where a person can intervene, where a person must approve before the machine's output takes effect, and what training and authority that person has. Recognized frameworks put this control near the center of responsible AI, and the EU AI Act makes effective human oversight an explicit obligation for the high-risk uses it regulates,^[1] which means the same document that satisfies an underwriter increasingly satisfies a regulator as well.

[1] EU AI Act — High-Level Summary (human oversight, high-risk obligations)

The third is the evidence of bias and red-team testing. This is where a company demonstrates that it has gone looking for the failure modes that have no precedent in any actuarial table: the model that discriminates against a class of applicants, the prompt that jailbreaks the system into saying something it should never say, the input crafted to steer the machine off its intended behavior. Testing for these is the AI analogue of a fire drill and a stress test combined, and the document records not just that the tests were run but what they found and what was done about what they found. The measurement functions of the recognized frameworks exist precisely to structure this work, and the framework built for generative systems catalogues the specific risks a red team should be probing for.^[2][3] An underwriter reading this document is asking a simple question behind it: has this company already found its own worst cases, or is it waiting for a claimant to find them first?

[2] NIST — AI RMF Playbook (GOVERN/MAP/MEASURE/MANAGE)  ·  [3] NIST — AI 600-1, Generative AI Profile

The fourth is an incident response plan written for AI failures specifically. Every mature security program has an incident plan for a breach; the AI version answers a different and in some ways harder question, namely what the company does in the first hours after a model causes a harm rather than after data is stolen. Who is called, who has the authority to take a system offline, how the affected customers are identified and told, how the faulty behavior is diagnosed and contained, and how the whole event is documented so that the next version of the system does not repeat it. The discipline of incident response is well codified in the security world, and the current federal guidance on handling incidents translates cleanly onto AI events with the harms redefined.^[4] An underwriter reads this plan as a direct input to loss severity, because a company that can contain a bad outcome quickly turns a catastrophe into an incident, and the difference between those two words is often the difference between a survivable claim and a ruinous one.

[4] NIST — SP 800-61r3, Incident Response Recommendations and Considerations

The fifth is data governance and provenance, the record of where the data feeding the models came from, what rights the company holds to use it, how it is protected, and how it moves through the systems the inventory names. Much of what goes wrong with an AI system can be traced upstream to the data it was trained or grounded on: a copyright exposure baked into a training set, private information that should never have entered the pipeline, a dataset skewed in a way that guarantees a biased output no amount of downstream tuning can fully cure. The provenance document lets an underwriter see whether these upstream risks have been managed at the source, and it has grown in importance as the legal exposure around training data has sharpened. A company that can trace its data can defend its models; a company that cannot is carrying risks it has never measured.

The sixth is a written AI usage policy, the internal document that governs how the organization itself uses these systems. This is the constitution the rest of the file operates under, the statement of what the company permits, what it forbids, who is accountable for which decisions, and what standard every deployment must meet before it goes live. Its value to an underwriter is partly its content and partly its mere existence, because a company that has written down its own rules for AI has demonstrated that AI is governed at the level of policy rather than left to the discretion of whichever team happens to be building with it this quarter. Regulators have moved in the same direction, with insurance regulators themselves publishing model guidance that expects insurers to maintain a written program governing their own use of AI systems,^[5] which is a telling sign of where the baseline expectation is settling for everyone else.

[5] NAIC — Model Bulletin on the Use of Artificial Intelligence Systems by Insurers

The seventh is a record of third-party and vendor AI risk. Very few companies build all their own AI, and the model an organization calls through a vendor's interface carries risk into the business just as surely as one built in house, with the added complication that the operator can see less of it. The document that addresses this maps the AI a company inherits from its suppliers, the contractual terms and audit rights it holds over that AI, and the diligence it has done on the vendors themselves. The maturing market has made this concrete, with underwriting practice moving toward warranted audit rights over a vendor's training data and testing programs as a condition of cover.^[6] An underwriter fears the risk a company does not control and cannot see, and vendor AI is the purest example of both, which is why the vendor file has become one of the questions that separates a serious applicant from an optimistic one.

[6] Armilla AI — AI Insurance Becomes a Procurement Requirement (audit rights)

The eighth and ninth documents are, in a sense, the thread that ties the other seven together, and they are the two that increasingly decide the outcome. The eighth is alignment to a recognized framework, the mapping of everything above onto a standard the underwriter already trusts, so that the governance reads not as a company's private habits but as a disciplined implementation of the NIST AI Risk Management Framework, the ISO/IEC 42001 management-system standard, or the obligations of the EU AI Act. The ninth is the evidence of independent assurance, the audit reports, certifications, and third-party evaluations that let an underwriter take the other eight documents on more than the company's own word. These last two are what convert a well-organized file into a priced advantage, because an underwriter can lean far harder on a control that a credible outside party has verified than on one a company merely asserts. The frameworks are covered in detail in the section that follows, because they are the spine the whole file is built around.

The Frameworks Are the Common Language

---

The reason the frameworks matter so much to an underwriter is that they solve a problem of trust and translation at the same time. A company's own account of how well it governs its AI is, by itself, hard for an outsider to weigh, because every company describes its own controls in flattering and idiosyncratic language. A framework replaces that idiosyncrasy with a common structure the underwriter already knows how to read. When a buyer says its governance is aligned to a named standard, the underwriter can map each of the nine documents onto a rubric they have seen many times before and judge the file against a shared benchmark rather than against a sales pitch. Three frameworks have become the common language of this market, and a buyer preparing to be insured should understand what each one is for.

The first is the NIST AI Risk Management Framework, a voluntary framework published by the United States National Institute of Standards and Technology that organizes the whole task of managing AI risk into four functions: govern, map, measure, and manage.^[7] Its great virtue for a buyer is that it is a practical scaffold rather than a certification regime, with a companion playbook of suggested actions and a dedicated profile for the specific risks of generative systems.^[8][2] The four functions map almost directly onto the nine documents: govern gives you the usage policy, map gives you the inventory and the vendor register, measure gives you the bias and red-team testing, and manage gives you the human oversight and the incident response. A company that builds its file around these functions is building it in a shape the underwriter can read at a glance.

[7] NIST — AI Risk Management Framework  ·  [8] NIST — AI 100-1 (AI RMF 1.0)  ·  [2] NIST — AI RMF Playbook

The second is ISO/IEC 42001, the international standard for an artificial-intelligence management system.^[9] Where the NIST framework is a scaffold a company can adopt on its own terms, ISO/IEC 42001 is a certifiable standard, which means an accredited body can audit a company against it and issue a certificate that outside parties can rely on. That difference is exactly the difference between the eighth document and the ninth, between alignment a company asserts and assurance a third party verifies, and it is why this standard has become such a direct lever on insurability. When a market treats a 42001 certification as a formal underwriting input that opens pathways to insurability and preferential terms, it is because the certificate does for the underwriter what a hundred years of claims does for a fire policy: it lets them rely on something outside the applicant's own word.^[10]

[9] ISO/IEC 42001:2023 (via BSI)  ·  [10] Armilla AI — From ISO/IEC 42001 Certification to Insurable AI

The third is the EU AI Act, which is not a voluntary framework at all but a binding law, the first comprehensive legal regime for artificial intelligence, and it changes the calculus in a way the other two do not.^[11] For the uses it classifies as high risk, the Act imposes concrete obligations that read like a governance file made mandatory: a risk-management system, data governance, technical documentation, record-keeping, transparency, human oversight, and a required level of accuracy and robustness.^[1] For any company touching the European market, these obligations are not optional evidence a buyer chooses to prepare but legal duties a buyer must discharge, and the same documents that discharge them are the documents an underwriter asks for. The Act's obligations and the underwriter's questionnaire have begun to describe the same file, which is why building for one increasingly satisfies the other, and why a buyer preparing for coverage and a buyer preparing for compliance are, more and more, the same buyer doing the same work.

[1] EU AI Act — High-Level Summary  ·  [11] European Commission — Regulatory Framework on AI

There is a market dimension to all of this that sits alongside the litigation dimension, and both belong to companion essays rather than this one. The shape of the standalone AI insurance market, the thin capacity and the affirmative offerings from established carriers such as Munich Re and its Hartford Steam Boiler unit that price AI coverage rather than exclude it,^[12] and the reasons this risk is so structurally hard to price, is the subject of Who Insures the Machine. The claims and lawsuits that are beginning to give the empty table its first entries are the subject of the essay on the first AI claims. This essay stays deliberately on the practical ground between them: what the underwriter asks, and how a buyer answers well.

From File to Terms

---

Here is the shift that matters, stated as plainly as I can make it. For a mature line of insurance, the price is set by the risk, and there is very little a buyer can do in the weeks before renewal to change a rate that a century of loss data has already fixed. For AI, where that century does not exist, the price is set in significant part by the file, and the file is the one thing a buyer wholly controls. That is an unusually hopeful fact buried inside an otherwise difficult market. The part of your AI risk that you actually govern is the part the underwriter can see, and the documentation you build is the instrument that makes your governance visible to the person setting your terms. Building it well, and building it early, is the single most useful thing a buyer can do to move its own price.

For AI, the price is set in significant part by the file, and the file is the one thing a buyer wholly controls.From file to terms

This reframes the entire posture a company should take toward AI coverage. The instinct, when a difficult market quotes a high number or declines outright, is to treat the outcome as fixed and to shop for a friendlier carrier. Sometimes that is the right move. But often the more productive response is to ask what the file was missing, because a declination for insufficient governance is not a verdict on the company's worth; it is a description of a gap the company can close. The nine documents are not a toll to be paid grudgingly on the way to a policy. They are the mechanism by which a buyer converts the one governable part of an ungovernable-seeming risk into evidence an underwriter can price, and a company that treats them that way tends to find that its second application looks nothing like its first.

The work also compounds in a way that few compliance exercises do. A model inventory built for an insurance application is the same inventory a regulator will ask for, the same inventory the security team needs to defend the systems, and the same inventory the company itself needs to decide where to deploy AI next. Human oversight documented for an underwriter is human oversight the EU AI Act may require and human oversight the company's own risk sense should have wanted anyway. The file assembled to become insurable is very largely the file assembled to be well run, which is why the effort rarely feels like waste even to the companies that resented starting it. Insurability and good governance have converged on the same evidence, and a buyer who builds that evidence is buying more than a policy.

If you want a concrete place to begin, this site maintains the checklist itself. The coverage-readiness checklist walks through the nine documents underwriters want, one at a time, with what good looks like for each, and it is the natural next step from this series because it turns the argument above into a file you can actually build. And before you assume your existing policies still cover your AI use at all, it is worth reading whether your errors and omissions or general liability coverage still reaches AI in 2026, because the governance file matters most precisely where the old silent coverage has already been written out from under you. The questions come before the policy. The best time to answer them is now, in the calm, with the documents in hand, rather than later, in the noise, with a claim already filed and the questionnaire answered in a way you can no longer take back.