AI for insurance: where it pays off and where it doesn't

Conversations about AI for insurance usually land on one of two useless extremes: the brochure promising instant underwriting and claims that settle themselves, and the department that has run the same tables for twenty years and sees no reason to change. The truth sits in between and is fairly concrete. Insurance is a business of documents, rules and probability — exactly what an AI system handles well. What it does not handle is the judgement call of when to break the rule, and in insurance that comes up every day.

This guide walks the full cycle — acquisition, underwriting, issuance, claims, fraud, renewal — and for each stage says three things: what can be automated today with a safety net, what data it needs to work, and what remains human work. It applies equally to a fifteen-person brokerage and to an insurer's technical department, even if the starting point and the budget look nothing alike.

One caveat up front: the insurance sector has been building models for decades. Pricing tables are models. The novelty is not "using maths", it is that text, images and unstructured documents can now be processed — and that opens up the 80% of administrative work that was never automatable before.

Where does AI for insurance actually pay off?

Ordered by what we see working first, not by what sounds best in a deck.

| Stage | Concrete use case | Maturity | Who feels it | |---|---|---|---| | Document intake | Reading competitor policies, claim forms, invoices and loss adjuster reports into fields | High | Admin, back office | | Service | Answering coverage and claim-status questions 24/7 | High | Customer, call centre | | Claims | Classifying, estimating cost and routing the file to the right handler | Medium-high | Claims handling | | Underwriting | Pre-filling and prioritising risks, flagging inconsistencies in the proposal | Medium | Underwriter | | Fraud | Flagging unusual files for human review | Medium | Investigation | | Portfolio | Predicting non-renewal and prioritising the call | Medium | Sales | | Damage from images | Estimating vehicle or property damage from photos | Medium-low | Loss adjusting |

Two readings of that table. First: the most mature work is the least glamorous. Nobody gives a keynote about reading claim forms, and that is where most of the real savings sit. Second: the further down you go, the more the system decides about somebody's money, and the more control you need around it.

In insurance, the right order is to automate what decides nothing first, and earn with that the permission to touch what does decide.

What does AI change in underwriting?

Underwriting is where AI for insurance promises the most and where you need the most care. What works today, specifically:

Pre-filling the proposal. A broker who receives the client's current policy as a PDF can have the data in their system in seconds instead of typing it: policyholder, coverages, sums insured, deductibles, expiry. It is the same mechanism we describe in document data extraction, applied to policy wordings. It saves hours and, more importantly, removes transcription errors that surface later during a claim.

Inconsistency detection. A system that compares what was declared against what is already on record — activity, square metres, fleet, loss history — and flags what does not add up before issuance. It does not reject; it warns. That is quality control, not a decision.

Queue prioritisation. When more proposals arrive than the team can study, ranking them by fit with the risk appetite and expected value means the underwriter spends their best hours on the risks that matter.

Risk summaries. For commercial risks, a report that condenses company accounts, prevention reports, site visits and previous submissions into a two-page brief. The underwriter reads the brief and goes to the source whenever something feels off.

What we do not recommend: delegating fine-grained pricing to an opaque model. A tariff has to be explainable, defensible before a supervisor and stable over time. A model that improves the combined ratio by a point but cannot be explained is a liability, not an asset. If a model does enter pricing, it should come with justified variables, technical documentation and drift monitoring, as covered in MLOps for business.

And a legal boundary worth settling before designing anything: some variables cannot be used, and some correlations reintroduce them through the back door. Postcode, for instance, is an actuarially reasonable variable in some lines and a proxy for ethnic origin in others. The question is not whether the data is available, it is whether you can justify why you use it.

How do you automate a claim without losing control?

The claim file has more documents per euro than anything else in the sector, and it is what frustrates customers most when it stalls. The automatable stretch, phase by phase:

1. Opening. Read the claim form, the email or the web form and open the file with the fields already populated: policy, date, coverage affected, description. 2. Classification. Assign claim type and complexity. A simple domestic water leak and a liability claim with an injured party do not belong in the same queue or with the same profile. 3. Preliminary estimate. A range of expected cost based on the history of similar cases. Useful for reserving and for deciding whether a loss adjuster is needed. 4. Missing documents. Detect which document is absent and request it from the customer automatically — the number one cause of stalled files. 5. Simple handling. For low-value claims with clear coverage, an automatic settlement proposal with human review by sampling. 6. Communication. Keep the insured informed of the status without anyone having to call. A well-scoped chatbot resolves most status enquiries here.

Point 5 separates those who have thought the project through from those who have not. Paying automatically below a threshold is defensible if you have sampling, logging and a measured error rate. What is not defensible is automatic rejection. A rejection affects the insured's rights and needs a person who signs it and can explain the reason with the policy wording in hand.

On image-based loss adjusting: it works reasonably well for visible, standard bodywork damage and poorly for everything else. It is useful as a preliminary estimate and to orient the insured, not as a replacement for the adjuster in disputed claims or structural damage. Anyone selling it as a full replacement has never handled a difficult claim.

Does AI fraud detection actually work?

It works, with two conditions that the demo rarely mentions.

First: fraud is rare. If confirmed fraud is 2% of files, a model that always says "no fraud" is right 98% of the time and is worth nothing. What matters is not overall accuracy, it is how many of the files it flags turn out to be fraud — precision — and how much real fraud it catches — recall. Always ask for those two numbers, never a bare accuracy percentage.

Second: you only learn from what you investigated. The history of confirmed fraud is biased by whatever the team happened to look at. If certain profiles were always investigated, the model learns to flag those profiles. It is the same underlying problem as in lead scoring: the label reflects the team's attention, not reality.

What does add value, in order of difficulty:

• Well-maintained hard rules. A claim filed days after inception, matching bank accounts across unrelated files, repairers that always appear together. Many brokerages do not even have this, and it is the cheapest layer.
• Anomaly detection. Flagging files that resemble no known pattern. It does not say "this is fraud", it says "this is unusual".
• Relationship graphs. Connecting people, vehicles, garages, adjusters and accounts across files. That is where networks get uncovered, not isolated cases.
• Narrative consistency. Cross-checking the description in the claim form against the documented damage and the dates. Free text holds more information than anyone exploits.

And the limit on all of it: a fraud signal is a working hypothesis for a person, never an accusation or grounds for automatic rejection. The flagged file goes to investigation together with the reason it was flagged, and a human decides there.

What data does each use case need?

The question that decides whether the project is viable this year or next.

| Use case | Minimum data | Sign you are not ready | |---|---|---| | Document reading | 200-300 real documents of the type you will process | You don't have the PDFs, or they are on paper or in personal inboxes | | Claim classification | 2-3 years of files with type and final cost | Type is filled in by hand and nobody reviews it | | Cost estimation | History with initial reserve and closing cost | You cannot cross reserve and settlement in the same system | | Fraud detection | Investigated files, with outcome, at least 3 years | The investigation outcome is never recorded | | Non-renewal | 3 years of portfolio with new business, lapses and reason | Lapses are recorded with no reason or a generic one | | Automated service | Current policy wordings and real call-centre FAQs | Wordings are out of date or duplicated |

If the right-hand column describes your house, the first project is not an AI project — it is a data quality project. We say that without drama, because it is usually faster to fix than it looks and because everything else depends on it.

What legal and compliance limits apply?

Four fronts that overlap in insurance and are best handled together from the start.

Automated decisions about people. Rejecting a proposal, denying a benefit or setting a price purely automatically falls into the territory the GDPR restricts. The safe route: the system proposes, a person with real authority to change it decides, and it is all logged. We cover this in GDPR and AI.

Health data. Health, life and accident lines process special categories of data. That changes the legal basis, the technical measures and who can see what. It is not just another use case.

Explainability to customer and supervisor. You need to be able to explain why it was priced that way, why that claim was denied and which model version was live that day. If the system does not store this by default, you will be reconstructing it precisely when you have no time.

Risk classification of the system. The European AI framework specifically addresses systems used for risk assessment and pricing in life and health insurance, with obligations on documentation, human oversight and data quality management. What that means for a mid-sized company is in the EU AI Act.

On top of that there is something that is not legal but costs just as much: the relationship with the broker. If the tool makes the broker lose visibility over what happens with their client, they will not use it, however good it is. That is a change management problem, and it gets solved by designing with them, not by presenting them the result.

Where does a brokerage start, and where does an insurer?

It is not the same project, even if the headline is.

Brokerage. The bottleneck is administrative: comparing policies, preparing proposals, chasing documents, answering status enquiries. The first profitable project is almost always document reading plus automated handling of simple enquiries. Contained investment, visible results in weeks, and zero decisions delegated. After that, portfolio non-renewal — money you already have that is walking out.

Insurer. The bottleneck is claims handling and claims cost. The first project is usually classification and routing of files, with a preliminary cost estimate. It is measurable against a clear baseline — handling days, reserve deviation — and it does not touch pricing, the most regulated ground.

In both cases, the metric that matters in year one is not model accuracy. It is how many hours of a specific process were freed up and what they were spent on instead. How to measure that honestly is in measuring AI ROI.

Frequently asked questions

Can AI reject a claim automatically?

It is not advisable and it conflicts with GDPR limits on automated decisions that significantly affect a person. The system can propose the rejection with the reason and the relevant clause of the wording, but a handler who can overturn it signs the decision, and it is logged.

How much history does a brokerage need to start with AI?

For document reading and customer service, almost none: they work from the policy wordings and a few hundred sample documents. History is only needed for prediction — non-renewal, claim cost, fraud — and there you want two or three years with the outcome properly recorded.

Does AI replace the loss adjuster or the underwriter?

Not in the work that justifies their salary. It replaces the mechanical part: transcribing, searching, summarising, preparing. The adjuster still decides on disputed damage and the underwriter on the risk that falls outside the table, which is where money is actually won or lost.

What about health data in life or health insurance?

It is a special category of data and requires a specific legal basis, strict access control and, usually, a prior impact assessment. It is best not to mix it into the same project as general lines: the level of control changes and it deserves its own design.

---

If you are weighing up where to start and want a map of which processes in your brokerage or department can be automated with the data you already hold, an audit puts it in writing, with the order and the cost of each step. And if you would rather test it in half an hour against a real claim file, let's talk.