AI in insurance in Europe: use cases under GDPR and the AI Act

Why should an insurer's AI stay in Europe?

Because insurers hold some of the most sensitive data in Europe, and the rules for it follow the data to every AI provider an insurer uses. Claims files, medical questionnaires, bank details and fraud notes all pass through the models that read them. GDPR treats health data as a special category, DORA makes an insurer name the countries where each ICT provider processes its data, and the AI Act adds its own duties for life and health underwriting.

The European insurance sector is already using generative AI at scale. In EIOPA's survey of 347 insurance undertakings in 25 EU and EEA countries, 65% were actively using generative AI, data privacy and regulatory compliance such as GDPR were among the biggest barriers, and the dominant strategy was buying off-the-shelf tools or building on third-party models (EIOPA, published 2 February 2026). So the choice of AI provider is now a supervisory question, not only an IT one.

US law follows US companies, not servers. The CLOUD Act obliges a US provider to disclose data in its "possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States" (18 U.S.C. § 2713). An EU region of a US cloud changes where a claims file is stored, not which law the company answers to. Once a policyholder's data sits with a US company, that company's terms and US law decide what happens to it, and both can change without the insurer having a say.

EUrouter keeps the whole chain European. EUrouter B.V. is an Amsterdam company under Dutch law, its DPA requires all processing of personal data to take place in the European Economic Area (section 5), it keeps no request content by default (section 10), and every request goes to EU-hosted model providers. On 28 October 2026, 15 of the 17 providers in EUrouter's catalog are headquartered in the EU, and 103 of its 156 models have at least one of them (providers).

What does EUrouter put in writing for your DPO and your DORA register?

EUrouter answers the first questions a DPO, a compliance officer or a DORA register asks about an AI provider in documents you can read today. These are inputs for your own assessment: whether a contract meets Article 30 of DORA, or a use case meets GDPR, is a decision your insurer makes with its legal team.

Every EUrouter request goes only to EU-hosted provider endpoints, from the Free plan up (routing docs, pricing). Set eu_owned: true on a request, or once for a whole API key in a routing rule, and EUrouter uses only providers headquartered in the EU, such as Mistral AI, Scaleway, OVHcloud, IONOS and Berget AI. Microsoft Foundry and AWS Bedrock, the two providers with US headquarters, are then excluded.

What can insurers use AI for?

Five uses fit insurance work today: claims intake, document reading, customer service, call notes and fraud triage. Underwriting support is the sixth, and in life and health insurance it is the one the AI Act treats as high-risk. The tables below read the live EUrouter catalog, show only models served by providers headquartered in the EU, and list prices in EUR; the model catalog has the rest.

Claims intake

AI claims intake reads a first notice of loss (an email, a web form or a transcribed call) and turns it into structured fields: policy number, date and cause of loss, damaged items and whether an emergency repair was done. Claims handlers then start from a filled-in file instead of a blank one, and unclear claims go to a person. Models that return JSON to a schema you define do this reliably; each of these is served by at least one provider headquartered in the EU:

The code example further down builds exactly this.

Reading claims documents and photos

Vision models read invoices, repair quotes, police reports and photos of damage, so a claims handler can check a quote against the policy without retyping it. Keep a person on any payout decision, and keep medical reports out unless your legal ground and your provider contract both cover health data. Each of these vision models is served by at least one provider headquartered in the EU:

Customer service on your own policy wording

An AI assistant answers policyholders' and brokers' questions about cover, excesses and claims status from the insurer's own policy wording, and quotes the clause it used. That is retrieval-augmented generation: an embedding model indexes the policy documents, and a chat model answers from the passages it retrieves. Since 2 August 2026, an AI system that talks directly to people must be designed so that they know they are dealing with an AI, unless that is obvious (Article 50). Each of these embedding models is served by at least one provider headquartered in the EU:

The RAG chatbot guide builds the whole pipeline with code.

Call notes and complaint summaries

Speech-to-text turns claims calls and complaint calls into text that a chat model summarises into a file note, so handlers spend the call listening instead of typing. Tell callers before you record, and keep the note to what was said. Each of these speech-to-text models is served by at least one provider headquartered in the EU:

Fraud triage

AI fraud triage scores incoming claims against the red flags your fraud team defines and sends the suspicious ones to an investigator. It should flag, not decide: a claim refused on a fraud score alone is a decision based solely on automated processing, which Article 22 GDPR restricts. EUrouter's decision models classify each claim against the options you define and return a probability for every option, so borderline cases go to a person (decisions guide):

Underwriting support

AI underwriting support summarises applications, broker submissions and loss histories so an underwriter decides faster. In life and health insurance, AI intended for risk assessment and pricing in relation to natural persons is high-risk under the AI Act (Annex III, point 5(c)). A summary that only prepares an underwriter's assessment can fall outside that, but an Annex III system that profiles natural persons is always high-risk (Article 6(3)). GDPR defines profiling as using personal data to evaluate or predict aspects of a person such as their economic situation, health or behaviour (Article 4(4)), which is what individual risk pricing does. Motor, home and travel pricing is not on the Annex III list, but GDPR and the ban on pricing by sex still apply (see the rules below). EUrouter supplies the models; the insurer that builds or deploys an underwriting tool carries these duties, so plan for them before the first pilot.

Which rules apply to AI in insurance in Europe?

Four sets of rules apply to AI in insurance in Europe: GDPR, the EU AI Act, insurance supervision (EIOPA, Solvency II and the Insurance Distribution Directive) and DORA. Sending policyholder data to a company outside the EEA adds a fifth question: whether that transfer has a legal basis and who else can reach the data.

GDPR and health data

GDPR applies to every claims file, application and call note that names a person, and it sets these duties for AI on policyholder data:

• Health data is special-category data. Article 9(1) prohibits processing data concerning health unless a ground in Article 9(2) applies. The caveat, plainly: Article 9 has no ground for "needed for the insurance contract". Insurers need another ground, such as the policyholder's explicit consent (Article 9(2)(a)), legal claims (Article 9(2)(f)) or a national law, and Member States may add further conditions for health data (Article 9(4)). An AI tool doesn't create a new ground: if you can't process the health data without AI, you can't with it.
• No decisions by machine alone. Article 22 gives people the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal or similarly significant effects, such as a refused claim, a cancelled policy or a premium. The exceptions (a contract, a law, explicit consent) require safeguards, at least human intervention, a chance to state one's view and to contest the decision. Under Article 22(4), such a decision may use health data only with explicit consent or under a substantial public interest law.
• Scores count. The EU Court of Justice held on 7 December 2023 that an automatically generated score is an automated individual decision where the company that uses it gives it a determining role (CJEU press release 186/23, Case C-634/21 SCHUFA). A risk or fraud score that decides in practice is treated like a decision.
• A DPIA first. Article 35(3) requires a data protection impact assessment for systematic and extensive evaluation of people based on automated processing, including profiling, and for large-scale processing of special categories. Underwriting and claims AI usually meet one of the two.
• Transfers need a basis. Making personal data available to an organisation outside the EEA is a transfer that must meet Chapter V of GDPR on top of every other rule (EDPB). Processing the model call in the EEA with a European provider keeps that hop out of Chapter V.

The GDPR text is on EUR-Lex. For DPAs, transfers and the questions to ask any AI provider, read the GDPR-compliant AI explainer.

The EU AI Act

The AI Act treats life and health underwriting and pricing as high-risk and makes insurers that deploy such systems assess their impact on fundamental rights first. These are the rules that matter for insurers, with the date each applies:

The dates come from the Commission's AI Act Service Desk timeline, which marks 2 December 2027 for the Annex III rules as amended by the Digital Omnibus on AI. Article 27 names deployers of the systems in Annex III, points 5(b) and 5(c), credit scoring and life and health pricing, and, as amended by the Digital Omnibus, lets them include cross-references to, or parts of, their GDPR DPIA in that assessment (Article 27(4)). Article 26 lets deployers that are financial institutions under Union financial services governance rules meet its monitoring duty through those rules and keep the logs with that documentation. Point 5(b) carves out AI used to detect financial fraud; point 5(c) has no such carve-out.

EIOPA, Solvency II and the IDD

EIOPA, the EU insurance supervisor, expects insurers to govern every AI system they use under the insurance rules they already follow, whether or not the AI Act calls it high-risk. Its Opinion on AI governance and risk management (6 August 2025) covers the AI systems that are neither prohibited nor high-risk, sets no new requirements, and reads existing law onto AI:

• Governance in proportion to risk. Solvency II (Article 41) requires an effective system of governance, and the Insurance Distribution Directive (Article 25) a product approval process. Insurers should assess the risk of each AI system and scale their measures to it.
• Responsibility stays with the insurer. Insurers are ultimately responsible for the AI systems they use, built in-house or bought. They should get adequate information and assurances from third-party providers about the system, its training data and its limits, and cover the gaps with contract clauses, audits or testing.
• Fair treatment. Article 17 of the IDD requires distributors to act honestly, fairly and professionally in the customer's best interests, and EIOPA expects a customer-centric approach across the whole life of an AI system, with ethics and fairness guidance and training for staff.
• Security and resilience. EIOPA links AI accuracy, robustness and cybersecurity to the ICT risk management framework DORA requires.

The Opinion is on EIOPA's website (EIOPA-BoS-25-360). One pricing rule predates all of this: since 21 December 2012, insurers in the EU may not use sex as a factor in premiums and benefits (CJEU press release 12/11, Case C-236/09 Test-Achats). A pricing model that learns sex from proxies such as first names or purchase histories brings that problem back, so test for it.

DORA and AI providers

DORA treats an AI API as an ICT service, so an insurer must manage it like any other ICT third-party provider. DORA has applied since 17 January 2025 to insurance and reinsurance undertakings, among 20 types of financial entities (EIOPA). For an AI provider that means:

1. Register it. Keep the provider in your register of information on all ICT contractual arrangements (Article 28(3)).
2. Assess concentration. Assess whether the contract adds to ICT concentration risk (Article 28(4)(c)), for example when all your AI runs through one cloud provider.
3. Write the locations into the contract. The contract must state the regions or countries where the service is provided and data is processed, including storage, and require the provider to notify you in advance before changing them (Article 30(2)(b)).
4. Plan the exit. For ICT services supporting critical or important functions, keep an exit strategy (Article 28(8)).

The regulation text is on EUR-Lex. An OpenAI-compatible API keeps the exit cheap: moving between providers behind EUrouter, or away from EUrouter, is a change of base URL and model name, not a rewrite.

Can insurers use ChatGPT, Azure OpenAI or Bedrock?

Not through staff's own consumer accounts, and a company plan from a US provider still leaves policyholder data with a US company. Personal accounts sit outside the insurer's contracts: no data processing agreement between the insurer and the provider covers what a claims handler pastes in, and the insurer cannot list it in its DORA register.

A company plan fixes the contract, not the jurisdiction. Azure OpenAI and Amazon Bedrock can process requests in EU regions, but Microsoft and Amazon are US companies: EUrouter's own providers page lists Microsoft Foundry and AWS Bedrock with US headquarters, and eu_owned: true excludes them. The CLOUD Act reaches data such a company controls, wherever it is stored. Running open-weight models on your own servers also keeps data in-house, at the cost of operating GPUs, models and their security yourself.

The European way is to give claims, service and underwriting teams approved tools that run on European models from European providers, and to make them the easy option. A tool built on EUrouter keeps every request in the EEA with a European company and names the provider of each request.

How do you build AI for insurance on EUrouter?

EUrouter is OpenAI-compatible: point the OpenAI SDK at https://api.eurouter.info/api/v1, pick a model, and add a provider object that keeps the request on EU-headquartered providers with zero data retention. This example turns a home insurance claim email into structured fields with Mistral Small 3.2 24B, which Berget AI, GreenPT, OVHcloud and Scaleway serve (EUrouter catalog, 28 October 2026). The email carries a policy number but no name or health data: the model needs the facts of the loss, not the person.

import json
import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["EUROUTER_API_KEY"],
    base_url="https://api.eurouter.info/api/v1",
)

claim_email = (
    "Policy H-48213. On 24 October water came through our kitchen ceiling "
    "from the flat above. The ceiling and two cupboards are damaged. "
    "A plumber fixed the leak the same day. Photos attached."
)

claim_schema = {
    "type": "object",
    "properties": {
        "policy_number": {"type": ["string", "null"]},
        "date_of_loss": {"type": ["string", "null"]},
        "cause": {"type": "string", "enum": ["water", "fire", "storm", "theft", "other"]},
        "damaged_items": {"type": "array", "items": {"type": "string"}},
        "emergency_repair_done": {"type": "boolean"},
        "needs_human_review": {"type": "boolean"},
    },
    "required": [
        "policy_number",
        "date_of_loss",
        "cause",
        "damaged_items",
        "emergency_repair_done",
        "needs_human_review",
    ],
    "additionalProperties": False,
}

raw = client.chat.completions.with_raw_response.create(
    model="mistral-small-3.2-24b",
    messages=[
        {
            "role": "system",
            "content": "You read first notice of loss emails for a home insurer. "
            "Extract only what the email states. Use null for anything it does not state.",
        },
        {"role": "user", "content": claim_email},
    ],
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "claim_intake", "strict": True, "schema": claim_schema},
    },
    extra_body={
        "provider": {
            "eu_owned": True,
            "zdr": True,
            "data_collection": "deny",
        }
    },
)

completion = raw.parse()
claim = json.loads(completion.choices[0].message.content)
print(json.dumps(claim, indent=2))
print("Served by:", raw.headers.get("x-provider-slug"))

The x-provider-slug response header names the provider that served each request, so your DORA register, your DPIA and your audit trail get a per-request record of which company processed it. To make these settings the default for every key a claims tool uses, save them in a routing rule: a request can never loosen a rule's retention limit. To answer policyholders from your policy wording, follow the RAG chatbot guide. The quickstart covers API keys.

What to check before going live

Before an AI tool touches policyholder data, the insurer should be able to answer each of these with a document, not an assumption. Where EUrouter has an answer, it is in the item.

1. Classify the use case. Check it against Annex III, point 5(c) and Article 6(3) of the AI Act: risk assessment and pricing for natural persons in life and health insurance is high-risk from 2 December 2027, and profiling keeps it there.
2. Find your Article 9 ground. If the tool sees health data, write down the Article 9(2) ground and the national conditions in each market. Otherwise keep health data out of prompts. EUrouter's DPA (Annex 1) requires a written agreement before special-category data is sent, so raise it in a DPA review.
3. Pseudonymise first. Replace names, addresses and policy numbers with IDs where the task allows, and keep the key in your policy or claims system.
4. Keep a person on decisions. No refused claim, cancellation or premium should rest solely on AI output (Article 22 GDPR), and a fraud score should route a claim to an investigator, not refuse it.
5. Run the DPIA and, for high-risk systems, the FRIA. Record the risks, the safeguards and the decision, and reuse the DPIA in the fundamental rights impact assessment where Article 27 allows. EUrouter assists with a DPIA on request (DPA section 6).
6. Register the provider under DORA. Add each AI provider to your register of information and check the contract states the processing locations and advance notice of changes. EUrouter's DPA limits processing to the EEA (section 5), lists each sub-processor and model provider with its country, and notifies sub-processor changes at least 10 business days ahead (section 7).
7. Lock the routing. On EUrouter, set eu_owned: true, zdr: true and data_collection: "deny", and save them in a routing rule that is the default rule of every API key your insurance tools use.
8. Keep traces in the EU. EUrouter's Broadcast sends request and response content to the observability tool you choose. Leave it off for claims and health data, or send it only to a destination hosted in the EU.
9. Test pricing for bias. Check that a pricing or underwriting model doesn't rebuild sex or health from proxies, and document the test in the governance file EIOPA expects.
10. Tell people. Label chatbots as AI (Article 50), and for high-risk systems inform the people they are used on (Article 26(11)).

Start building insurance AI in Europe

Create a free account, point your claims or service tool at https://api.eurouter.info/api/v1, and your next request runs in Europe with a European company. Create a free account, compare plans, read the routing docs, or talk to us about a DPA review, including any health data your use case needs. More industries are on the use cases page, such as AI for HR.