What makes an AI idea a poor first project?

It decides on a customer's behalf, it depends on data the insurer does not yet have, or nobody in the business owns it. These ideas can still be good second or third projects.

Should the first AI project be customer-facing?

Usually not. A back-office use case where staff check the output lets the organisation learn with less risk. Customer-facing tools can follow once the controls are proven.

Can a small insurer start with AI without a data team?

Yes, if the first use case uses data that already exists in a usable form, such as documents and emails. If the use case needs new data infrastructure, that work should come first.

What governance does a first AI project need?

Something proportionate: a named owner, a clear view of the data used, a way of checking results, a review schedule and a way to explain outcomes to customers. Finanstilsynet expects the framework to be in place before advanced methods are used.

How do you measure whether an AI pilot worked?

Measure the starting point first, such as handling time, backlog or error rate. Agree the target before the pilot starts, then compare the result with the starting point.

How many AI use cases should an insurer start with?

One. A single, well-chosen project builds the skills, controls and trust that the next ones depend on.

Who should own an AI use case?

A named person in the business area the tool serves, such as the head of claims or customer service. IT and vendors support the project, but the business owns the outcome.

← Back to blog

How to Choose Your First AI Use Case in Insurance

Notes from Hundred Solutions, DVERSI's founding implementation partner, on putting AI to work in insurance.

Insurance

Nearly two-thirds of European insurers now use generative AI, but most are still at proof-of-concept stage. The insurers that get past the pilot usually chose their first project well. This guide sets out six tests for a good first AI use case, scores common ideas against them, explains what Finanstilsynet expects before a pilot starts, and gives five steps for running it.

Hundred Solutions8 min read

New here? Start with how we work, or read about where DVERSI fits if you're trying to work out whether a platform or a custom build is the right call.

Key points

The first AI project sets the tone for every one after it. A failed pilot costs more than time: it costs trust.
Across Europe, nearly two-thirds of insurers now use generative AI, but most are still at proof-of-concept stage.
The usual obstacles are well known: data quality and access, unclear business value, missing skills and regulatory concerns.
A good first use case passes six tests: clear value, usable data, a stable process, a named owner, a person who checks the result, and a fit with existing systems.
Start with work that prepares a decision, not work that makes one.
Put the governance in place before the pilot starts, as Finanstilsynet expects.

Picture a workshop at a Norwegian insurer. Twelve AI ideas are on the whiteboard: a customer chatbot, automated claims decisions, smarter pricing, document sorting, fraud flags, an internal search tool and six more. Every idea has a sponsor. The budget covers one.

Choosing well matters more than choosing fast. The first project decides whether the board, the staff and the control functions believe in the next one.

Why do so many AI pilots stall?

Getting started is no longer the hard part. Finishing is.

EIOPA surveyed 347 insurers in 25 European countries between May and July 2025, and published the results in February 2026. Nearly two-thirds were already actively using generative AI, but most were still at proof-of-concept stage. The respondents named the main hurdles as data privacy and security, regulatory compliance and a lack of sufficiently skilled staff.

The Norwegian picture points to similar causes. When Finanstilsynet surveyed 31 insurers in mid-2024, the smaller insurers that used little advanced technology gave three reasons: lack of competence, not seeing enough business value, and too little data or data of poor quality.

Most of these obstacles can be avoided, or at least seen in advance, by choosing the first project well.

What makes a good first AI use case?

A first use case does not have to be the most valuable idea on the board. It has to be one the insurer can finish, measure and stand behind. In our experience, it should pass six tests.

1. The value is clear and measurable. You can name the number that should change, such as handling time, backlog or error rate, and you can measure it today.

2. The data exists and you may use it. The inputs are available, reasonably complete and allowed for this purpose. If the data has to be collected or cleaned first, that is the project.

3. The process is stable and agreed. Experienced staff would handle the same case in the same way. If they would not, settle the process before you automate it.

4. A named person owns it. One person in the business is responsible for the outcome, not only IT or a vendor.

5. A person checks the result. The AI prepares the work and an employee decides. If the AI is wrong, the mistake is caught before it reaches a customer.

6. It fits the systems you already run. The tool can read from and write to your existing systems without a major integration project.

A use case that fails any of the six tests is not necessarily a bad idea. It is a bad first idea.

How do common ideas score?

The table below applies the six tests to ideas that come up often in insurance. The ratings are a general guide, not an assessment of any particular insurer.

Idea	Value clear?	Data ready?	Process stable?	Owner clear?	Person checks?	Fits systems?	Good first project?
Sorting and summarising claims documents	Yes	Usually	Usually	Yes	Yes	Usually	Strong candidate
Internal search across policies and procedures	Yes	Usually	Yes	Usually	Yes	Yes	Strong candidate
Drafting replies to routine emails for staff to send	Yes	Usually	Usually	Yes	Yes	Usually	Strong candidate
Flagging possible fraud for an investigator	Yes	Depends	Depends	Yes	Yes	Depends	Possible, if data is good
Customer-facing chatbot giving advice	Unclear	Depends	Depends	Depends	No	Depends	Better later
Automated claims decisions	Yes	Depends	Often not	Yes	No	Often not	Better later
AI-driven pricing	Yes	Depends	Specialist	Yes	Partly	Depends	Better later, with actuaries

The strong candidates share one feature: they prepare a decision rather than make one. That keeps the risk low while the organisation learns.

Which use cases should wait?

Some ideas are valuable but make poor first projects.

Anything that decides on a customer's behalf. Finanstilsynet expects insurers to ensure sufficient human oversight of systems, processes and results. It also expects prices to be explainable to the customer. A first project that removes the person from a customer decision tests all of this at once.

Anything that depends on data you do not have yet. If the use case needs a data warehouse, a new integration or months of cleaning, treat that work as a project of its own.

Anything without an owner in the business. A tool that IT builds and nobody in claims or customer service asked for will be finished technically and unused in practice.

What should be in place before the pilot starts?

Finanstilsynet's position is short: the framework must be in place before such methods are used ("Rammeverket må vere etablert før slike metodar blir tekne i bruk"). Its 2024 report also sets out what insurers are expected, or advised, to do:

ensure sufficient human oversight of systems, processes and results
carry out regular audits to check that systems work as intended
make sure the data used is accurate and relevant
document data processing and modelling methods so they can be traced and checked
have the board and management carry out thorough risk assessments before deciding to go ahead

For a first project, this can be done in proportion to its size. In our reading, a one-page answer to five questions covers most of it: who owns the project, what data it uses, how results are checked, how often it is reviewed, and how a customer gets an explanation if they ask.

This is a description of the regulator's stated expectations, not legal advice. Each insurer should confirm its own obligations with a qualified adviser.

How do you run the first project?

At Hundred Solutions we work by a simple rule: solve first, automate later. For a first AI project, that gives five steps.

Measure the starting point. Record how long the work takes now, how many cases there are and how often errors occur.
Map the process as it really works. Write it down with the people who do it, including the exceptions.
Set the success measure before you build. Agree what result would justify going further, and what result would mean stopping.
Run it with a person in the loop. Let the AI prepare the work and let staff decide. Collect their corrections.
Decide on the evidence. Compare the result with the starting point. Then scale it, adjust it or stop it.

Stopping a pilot that does not meet its measure is not a failure. Continuing one that cannot be measured is.

Not sure which AI idea to start with? Hundred Solutions helps insurers test their ideas against the six tests above, map the chosen process and put governance in place before anything is built.

Sources

EIOPA, press release on its survey of generative AI use among European insurers (2 February 2026): https://www.eiopa.europa.eu/eiopa-survey-generative-ai-shows-swift-cautious-adoption-among-europes-insurers-2026-02-02_en
EIOPA, survey launch (15 May 2025): https://www.eiopa.europa.eu/eiopa-surveys-european-insurers-their-use-generative-ai-2025-05-15_en
Finanstilsynet, "Kartlegging av forsikringsføretaka sin bruk av avansert teknologi" (2024): https://www.finanstilsynet.no/publikasjoner-og-analyser/andre-rapporter/forsikringsforetakenes-bruk-av-avansert-teknologi/kartlegging/kartlegging-av-forsikringsforetakenes-bruk-av-avansert-teknologi/

Frequently asked questions

Work that is repetitive, text-heavy and easy for a person to check, such as sorting and summarising claims documents, searching internal procedures or drafting routine replies for staff to send.