The vendor pitch is always horsepower: faster intake, faster quoting, fewer touches. The questions your carrier will ask are about control: who approves, what gets logged, whose models saw the data. An MGA that can answer the control questions can adopt the horsepower safely. An MGA that can't is accumulating a risk it hasn't priced. This guide covers the four guardrails, what they look like in a live system, and what to ask any vendor who says "AI" in a demo.
Why your carrier suddenly cares
The regulatory environment shifted. The NAIC adopted a model bulletin on insurers' use of artificial intelligence, and 24 states plus the District of Columbia have since adopted it, with others issuing their own AI-specific insurance guidance (NAIC adoption map, status as of 7 July 2026). Its core expectation is simple: an insurer should govern its use of AI. And that expectation does not stop at the carrier's front door, regulators look through the carrier to the vendors and delegated partners operating under its paper. A delegated underwriting authority is exactly that kind of arrangement.
So when your carrier's diligence questionnaire grows an AI section, it isn't curiosity. The carrier is being asked to account for how decisions are made under its authority, including the ones your systems touch. Two answers fail that review. The first is "we use AI" with nothing behind it. The second, increasingly, is "we don't use AI", because it's rarely true once you count the tools your team and your vendors already rely on. The answer that survives is an inventory: here is where AI touches our operation, here is who approves its output, and here is the paper that proves it.
The four guardrails
Four artifacts turn "trust us" into "read it." They are the same set we describe on our governed AI solution page and in our security and AI-governance practices, and none of them requires exotic technology. They require decisions about who is in charge.
1. Approval gates
Nothing rates, binds, quotes, or files without a named person signing off. The gate has to live in the software, not in a memo, the same discipline as the underwriter checkpoints in a submission-to-issuance workflow, where in-appetite business flows and anything outside refers to a person before it moves. If a vendor's answer to "where does a human approve?" is a policy document rather than a screen, keep asking.
2. Suggestion logging
Every suggestion the system makes is recorded with its reasoning and its ranked alternates, and every human decision is recorded next to it, accepted, overridden, or referred. The log is what makes the other guardrails checkable. When someone asks why a particular Classification was assigned to a particular risk months ago, the answer should be a lookup, not an archaeology project.
3. Provider inventory
A current list of which models and services touch your data, disclosed in writing and kept current as components change. "Which AI providers are in your stack?" is now a standard diligence question, and the answer should be a document, not a guess. The inventory is also where data boundaries live: whether your submissions can be used for model training, and where the agreement says so.
4. A written AI-use policy
One readable document that says what the AI is for, what it may touch, and what only people do, plain language, not legalese. This is usually the first artifact a carrier's reviewer reads, because it tells them whether the other three exist on purpose or by accident.
The operating rule behind all four: if it touches rating or binding, a person approves it, and the file can prove a person approved it.
Scope is the other half of that rule. The AI Operational Workforce takes the mundane, repeated work around the decision (reading the submission, proposing Classifications and data, chasing what is missing, assembling the file) with feedback loops that correct it as it goes, and the four guardrails are what keep it from drifting past that line.
What good looks like in practice
The pattern to look for is narrow, visible, and checkable. Our reference example is a classification assist running inside a working MGA, and rather than describe it, we stand up a working system you operate in production for 30 days yourself. You describe a risk in plain language; it suggests Classifications with ranked alternates and the reasoning behind each; a person accepts or overrides; the suggestion and the decision are both logged. It does not rate, does not bind, and makes no unattended decision anywhere in the flow.
Notice what the narrowness buys. A tightly scoped assist with a clean log can be explained to a reviewer in a paragraph and verified in a sitting. A sweeping "AI underwriting platform" whose boundaries nobody can state is neither, whatever its demo looks like.
Questions to ask any vendor about AI
Five questions separate governed AI from a demo with a chatbot in it:
- Where, exactly, does a person approve? Ask to see the screen, not the slide.
- Can we read the suggestion log for a real decision? Reasoning and alternates included, if the log doesn't exist yet, that answers the question too.
- Which providers and models touch our data? In writing, and kept current as components change.
- Is our data used for training? And where, specifically, does the agreement say so?
- What happens when the AI is wrong? Who catches it, how the override is recorded, and what changes afterward.
These five are the AI section of a longer diligence conversation. Our guide to questions to ask MGA software vendors covers the rest, and the pillar guide on how to choose MGA software puts all of it inside a full selection process, because AI governance is one criterion among several, not the whole decision.
If you'd rather start from your own operation than a vendor's deck, start with the inventory: where AI already touches your intake, rating handoffs, and reporting, and who approves what today. That is part of what the MGA Systems Assessment puts on paper, 2–3 weeks against your actual systems, with the governance answers written down before anyone's questionnaire arrives.