Somewhere in your pipeline right now, an enterprise prospect's security team is drafting a questionnaire. A few years ago it would have been the usual SOC 2 checklist. In 2026, it has a new section — one asking who, or what, is making decisions inside your product, on what authority, and how you'd prove it if something went wrong.
Most startups can't answer it yet. Not because the questions are unfair, but because almost nobody has built the paperwork the questions assume already exists.
This piece is about that gap — where it comes from, why an unlikely industry got there first, and what it means for you, whether or not "AI company" is how you'd describe your business.
Before she started writing about AI, governance researcher Lara Stuart-Mueller spent years inside the operational core of a major corporate insurer, handling the accounting, billing, and claims infrastructure behind life insurance policies written for entire companies rather than individuals — the kind of firm large enough that a single account could survive a decade of mergers and a dozen countries' worth of conflicting law.
What she took from that job wasn't actuarial know-how. It was a harder lesson about paperwork: a claim on an account that size gets paid, or doesn't, based on whether the documentation can survive a dispute — sometimes years later, in a courtroom nobody involved in the original contract ever anticipated. The size of the company being insured never bought anyone a pass on that.
She's since applied that discipline to a very different industry. Her core argument: the reason AI liability insurance is struggling to get off the ground isn't a pricing problem or an actuarial one — it's the identical documentation problem the corporate insurance world already solved, just showing up in software instead of file cabinets.
When an AI system's decision causes harm, the real question isn't whether the model behaved reasonably in the moment. It's whether anyone, afterward, can piece together who asked for what, who had the authority to approve it, and what checks were actually watching at the time. That's the same reconstruction problem a claims desk used to face on a disputed corporate policy — except now the record has to come out of application logs instead of paper files.
Today, the honest answer is almost always no. What most AI products generate is engineering telemetry — useful for a developer chasing down a bug, useless to anyone who later has to explain, under an insurance policy or in front of a customer's lawyer, exactly what the system was authorized to do. She calls the piece that's missing the Insurability Layer: the structural layer of an AI system that has to exist before a carrier can put a number on the risk, rather than just writing an exclusion around it.
That gap isn't theoretical anymore. It's already showing up in real underwriting decisions and real enterprise contracts.
Carriers moved on this faster than most founders noticed. Armilla launched one of the first standalone AI liability policies underwritten at Lloyd's, offering coverage for AI-specific failure modes — hallucination, model drift — that general liability was never priced to hold. In March 2026, HSB, Munich Re's specialty arm, rolled out AI liability coverage aimed squarely at small businesses, meant to close the gap left by policies that quietly exclude AI-caused harm rather than pricing it outright. That exclusionary pattern is the industry-wide problem right now: AI risk has been living inside cyber and E&O policies that were never built to hold it, and carriers are starting to write it out in plain language instead of leaving it ambiguous.
Enterprise procurement moved on an independent, arguably faster track. Over the past year, enterprise buyers began adding dedicated AI sections to the vendor security questionnaires most B2B startups already fill out on every enterprise deal — the standard SIG and CAIQ templates — asking about model provenance, output monitoring, subprocessor transparency, and alignment with frameworks like ISO/IEC 42001 and the NIST AI Risk Management Framework. Passing your SOC 2 audit no longer clears the bar by itself. A growing number of enterprise buyers now treat a written AI policy and an AI system that produces auditable evidence of its own operation as two different things — and only the second one satisfies them.
Put those two shifts together and you get the situation founders are actually in: your insurer wants evidence before it will price your AI risk, and your enterprise buyer wants the same evidence before it will sign. Neither will take your word for it.
The instinct to file this under "someone else's problem" is understandable and wrong. If your product uses AI anywhere in a workflow that touches a customer, a decision, or a dollar — support automation, scoring or recommendation logic, agentic tooling that can take action on a customer's behalf — you're carrying the same exposure whether or not AI is your headline pitch. The insurance industry is already treating it that way: liability coverage for AI-caused harm is being written for AI use, not for companies that call themselves AI companies.
If you sell B2B into enterprise, the exposure compounds. Your buyer's AI risk is, contractually, about to become your problem twice over — once in the vendor questionnaire before they'll sign, and again in the liability and indemnification language once they do. A buyer who has to answer to their own regulator, their own board, or their own insurer about third-party AI risk will push that requirement straight down into your contract. "We'll figure it out if it comes up" satisfies neither procurement nor legal, and increasingly it won't satisfy your own insurer either.
Stuart-Mueller's more recent work — a public working draft called the Insurability Rating Schedule — makes an argument worth sitting with even if you never read the full document: insurance has already solved this shape of problem twice before, and both solutions transfer to AI with very little translation.
Corporate life underwriting converts a human risk into a rate through a short list of named, assessable factors, each resolved into a class. Industrial property underwriting goes further: it prices a building on its engineering state — what it's built from, what it's used for, what actively protects it, and how much risk sits just outside its own walls, out of its control — verified by inspection, not assumed from good intentions. That four-factor property framework is close to a century old, and it maps onto AI risk almost without modification:
Her Schedule organizes the underlying diligence surface into eight areas. In plain founder language, they come down to:
The Schedule resolves that assessment into a class — the AI equivalent of the "Highly Protected Risk" designation industrial insurers reserve for buildings that have earned tight pricing: Highly Governed Risk (HGR™) at the top, down through Governed, Conditionally Governed, and Ungoverned, where a deployment with no way to establish a basis for its own actions is, by her framing, simply not insurable — independent of how well the model performs on an average day.
You don't need to adopt her specific schedule to take the underlying point seriously. Enterprise buyers and insurers are converging, independently, on the same question. Not "does your AI work," but "can you prove what it did, and why, before someone asks."
Before your next enterprise renewal, your next diligence pass, or your next insurance conversation, it's worth sitting with these honestly:
If more than one or two of those give you pause, you're not unusual — almost nobody has this fully built yet. But "unusual" won't stay true for long, and the founders who build this evidence discipline before it's demanded of them will close enterprise deals faster than the ones scrambling to produce it under deadline.
This is, in the end, the same discipline we push on the customer discovery side at Venture Mechanics, aimed at a different auditor. Customer discovery asks you to prove, with evidence, that you understand the problem before you build for it. This asks you to prove, with evidence, what your product actually did after you built it. Both are about resisting the urge to describe your business the way you wish it worked, in favor of documenting the way it actually does.
If you're building anything AI-touching and selling into enterprise, put "can we prove this happened" on the list right next to "can we sell this." Increasingly, your buyer's underwriter is going to ask both questions before your buyer signs.
