Why AI in Underwriting Needs More Than a Good Risk Model

In underwriting and pricing, the model is only part of the decision. What the Library shows about risk decisions, and what to put in place before go-live.

MetroMinds · 18 October 2026 · 7 min read

The chief underwriting officer of a European insurer has just seen the results of an AI underwriting pilot. The new risk model predicts claims better than the old rating tables, the data science team is proud, and the business wants it live before the next renewal round. Then internal audit asks three questions. Who can see why a particular customer got a particular price? What happens when the underwriter disagrees with the model? And where is that disagreement recorded?

Nobody in the room has a good answer, and the go-live date moves. This situation is common, because in underwriting and pricing the model is only part of what has to work. The decision around the model, with its explanations, approvals and records, matters just as much.

From the MetroMinds Library

How the product pricing actuary retests a policy premium at portfolio renewal

Industry Financial Services, Insurance (P&C and Life)
AI domain Prediction, pricing and benchmarking
Role Product Pricing Actuary, with the Underwriting Manager for exceptions
Capability Product and Service Lifecycle > Pricing & Value Engineering > Price Setting and Governance

At renewal, the AI gathers filed peer rates, deal records and underwriting notes, compares like-for-like segments and returns a recommended rate position with a confidence rationale. It flags sparse loss data or a missing sign-off trail, and no rate changes until the actuary decides. Every choice and override reason is recorded.

18 to 35% pricing benchmark review time reduction
4 to 9% price recommendation accuracy improvement
10 to 22% pricing rework cost reduction

This use case scores 5 out of 5 for business value and 5 out of 5 for risk in the Library. Workforce impact: less time reconciling benchmark feeds, more time judging confidence, documenting overrides and keeping the pricing rationale up to date.

Book a demo

Why AI underwriting is different from claims automation

Most insurance AI work happens in claims, where the goal is to handle more files with less effort. Underwriting and pricing are different. A pricing decision affects a whole book of business, a mistake can repeat itself thousands of times before anyone notices, and customers and supervisors increasingly expect an explanation of how a decision was made.

The MetroMinds Library holds 14 insurance use cases about risk, pricing and underwriting decisions: assessing risk, monitoring it, setting prices, testing catastrophe exposure before a reinsurance renewal and checking underwriting attestations. When we compare them with the 24 insurance use cases for claims handling, a clear pattern appears.

Dot plot comparing 14 insurance risk, pricing and underwriting use cases with 24 claims handling use cases: higher risk score (3.93 versus 3.46), decision complexity (3.86 versus 3.42), context volatility (4.64 versus 4.46) and business value (3.93 versus — Source: MetroMinds Library, 4,980 use cases (August 2026). Average scores on a 1 to 5 scale.

Risk and pricing use cases score higher on business value, on decision complexity and on overall risk. They score lower on one specific readiness dimension: safety and policy enforcement, which measures whether the controls exist to keep an AI system within its rules. In other words, the use cases with the most at stake are also the ones where the guardrails are least ready.

Interestingly, the ability of the AI itself to explain and control its output is about the same in both groups: 4.00 for risk and pricing against 4.12 for claims. The gap is not in the model's ability to explain. It is in the organisation's ability to enforce rules, record decisions and route exceptions.

The regulation already draws the line

European regulation makes the same distinction. The EU AI Act lists AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance as high-risk [1]. High-risk systems come with requirements for risk management, data quality, documentation, logging, transparency and .

For AI that falls outside the high-risk categories, such as many uses in non-life insurance, the supervisor has set expectations as well. In August 2025 EIOPA published an Opinion on AI governance and risk management that follows a risk-based and proportionate approach, and that explicitly excludes systems already classed as high-risk or prohibited under the AI Act [2]. The message for underwriters is that there is no category of pricing AI without governance expectations. The only question is which set applies.

Many insurers have responded sensibly so far. In its 2024 report on digitalisation, EIOPA observed that most current solutions have been developed in-house for simpler tasks with more explainable algorithms that retain human oversight [3]. The step towards more powerful models in underwriting is exactly where that approach comes under pressure.

Scenario

One underwriting decision, followed from model to file

In this illustrative example, a health insurer uses an AI model to support individual risk assessment for new applicants. An application arrives from a self-employed 52-year-old with an incomplete medical history. The model recommends a premium loading and gives its three main reasons.

The underwriter reviews the reasons and sees that one of them rests on a data field that was filled in by default because the applicant skipped a question. She overrides the loading, records the reason and asks for the missing information. Because the override is logged with a reason code, the model team sees within a month that the same default field caused eleven other overrides.

Without that record, the error would have stayed invisible. The underwriter would have corrected individual cases, the model would have kept repeating the mistake, and nobody could have shown the supervisor how decisions were controlled. The illustration shows that the value of the model depends on the workflow around it: reasons the underwriter can read, a simple way to disagree, and a log that turns disagreements into improvements.

What needs to be in place before go-live

What the chief underwriting officer in our opening example needs is a decision design around the model he already has. In practice that comes down to five elements, and each can be checked before go-live.

A clear owner for every decision type, with written authority limits that state when the underwriter decides alone and when a manager or actuary must join.
Explanations in the language of the underwriter, linked to the data that produced them, so that a wrong input can be traced.
A simple override with reason codes, so that disagreement is recorded rather than lost in an email.
Monitoring of overrides and outcomes over time, so that a pattern of overrides leads to a model or data fix.
An audit trail that shows a supervisor or customer who decided what, on which information, and when.

None of these elements is technically difficult. They are, however, organisational work: agreeing authority limits, designing reason codes and deciding who looks at override patterns every month. That is why they are so often left until the end, and why they so often delay the go-live.

Side by side

A model on its own versus a model inside a governed workflow

Take the same pricing model and put it into production in two ways.

In the first, the model writes a recommended premium into the policy system. Underwriters can change it, but there is no reason field, no confidence indicator and no link to the input data. Audit sees a final price and a model version. When results drift, the model team learns about it from the quarterly loss ratio.

In the second, the model returns a recommended position, its main reasons and a confidence level. Low-confidence cases go to a senior underwriter. Overrides require a reason code, and a monthly review of overrides is part of the pricing committee agenda. Audit can follow every decision from input to outcome.

The second setup takes longer to build. It is also the only one that will pass an internal audit and keep improving after go-live.

Using the Library to plan the work

The comparison in the chart is also a planning tool. If your AI underwriting plans score high on risk and decision complexity, as the Library suggests they will, the work on controls should start at the same time as the work on the model, not after it. The readiness dimensions show where to begin: safety and policy enforcement, and data access.

It also helps to treat underwriting AI as a separate group in your portfolio. If claims ideas and pricing ideas are assessed with the same expectations, pricing ideas will look slow and expensive. Assessed as a group with their own readiness requirements, they become strategic bets with a clear list of preconditions, which is a much better basis for a funding decision.

How MetroMinds supports underwriting and pricing teams

In MetroMinds, every use case carries its value, feasibility and risk scores, together with a profile that includes safety and policy enforcement. When you add an underwriting idea to your portfolio, you see straight away which readiness conditions it depends on. The AI Readiness Scan then shows how your organisation scores on those conditions, so the gap between what the use case needs and what you have is visible before you commit budget.

If you want a quick first view, the six-dilemma AI Readiness Snapshot takes a few minutes and covers governance, data and technology. For a broader look at choosing between insurance ideas, see our article on AI in claims handling.

How ready are your controls for AI in underwriting? Take the AI Readiness Snapshot

Sources

European Union, Regulation (EU) 2024/1689 (Artificial Intelligence Act), Annex III, point 5(c), 2024.
EIOPA, "EIOPA publishes Opinion on AI governance and risk management", 6 August 2025.
EIOPA, "EIOPA report takes the pulse of digitalisation in the European insurance market", 30 April 2024.
MetroMinds Library, 4,980 AI use cases with benchmark ranges based on real-world implementations, August 2026.