EU AI Act for insurers: life and health pricing duties

Does the EU AI Act for insurers reach only life and health pricing?

Yes, for the insurance uses it names. Annex III point 5(c) makes high-risk AI systems intended for risk assessment and pricing of natural persons in life and health insurance. Other insurance lines, such as motor, property or general liability, are not listed in that point. The test is the use, not the sector label. An insurer's model that scores applicants for life or health cover, or sets their premiums, falls in scope. A model that performs fraud detection or claims triage for a property line does not fall under that point on the same basis. Because the list is tied to use, the insurer should map each AI system to the decision it supports and record whether that decision is a life or health risk assessment or pricing step. Confirm any borderline case against the draft Commission guidelines on high-risk classification and with counsel before relying on an exclusion. The high-risk rules for Annex III systems apply from 2 December 2027, following the 2026 amendment that moved the date from 2 August 2026. That date is the planning anchor for the insurer's program, but it does not reduce the work. Inventory, risk management, data governance, logging, human oversight and the explanation duties all need to be built and tested before that date, and the fundamental rights impact assessment described elsewhere on this page must be completed before first use of the system. Insurers should confirm with their national supervisor how the 2027 date interacts with systems already in use. The insurer's role depends on who builds the model. Most life and health insurers act as deployers, using a vendor's pricing or underwriting tool under their own authority. An insurer that develops the model in-house, or substantially modifies a vendor system and puts it into service under its own name, can become the provider and takes on the provider duties, including the quality management system and conformity assessment. The insurer owns its compliance in either role. An implementation partner can prepare systems, documentation and evidence, but only an independent auditor, assessor or certification body issues reports or certificates.

Which insurance uses fall inside Annex III point 5(c)?

Annex III point 5(c) reaches risk assessment and pricing for natural persons in life and health insurance, and nothing else in insurance. The cards below test common insurance uses against that single line, so insurers can see which uses need a full high-risk assessment and which fall outside it.

Life underwriting scores

A model that scores an applicant's life insurance risk and drives acceptance, decline or loading is the clearest case inside point 5(c). The output concerns a natural person and shapes the terms they receive. Confirm that the score feeds a real underwriting decision, not just a triage queue that a human always re-underwrites from scratch, and document where that boundary sits. Assume high-risk status until counsel confirms otherwise.

Health underwriting scores

Health underwriting models that rate an applicant's medical risk and set cover, exclusions or premiums fall within point 5(c) when they are used for health insurance. Check which product lines the model serves, because the point names health insurance specifically. Map the input data sources, including any clinical or wearable data, since these affect both the risk assessment and the fundamental rights impact assessment that follows.

Life or health pricing models

Pricing models that set premiums for individual life or health policies are in scope where they perform risk assessment and pricing for natural persons. Group schemes and purely portfolio-level rate setting need separate analysis. Confirm whether the model outputs an individual price or only a benchmark that a pricing actuary later applies, and record how much discretion the output leaves to the human decision maker.

Claims and fraud tools feeding pricing

Claims triage or fraud detection tools fall outside point 5(c) when they only detect fraud or process claims. They move into scope when their output feeds back into the risk assessment or premium of a natural person, for example when a fraud flag raises a policyholder's renewal price. Trace each data flow to see whether a claims score ever reaches a pricing input, and document any firewall that keeps the two apart.

Property, motor and other lines

Pricing for property, motor, travel and other non-life lines is not listed in point 5(c), so these models are not high-risk on that basis. Insurers should still confirm that no shared model or feature set reaches life or health decisions. The AI Act's other rules, such as transparency and general governance duties, can still apply, so do not treat non-listed status as a full exemption.

Shared models and reuse

A single model that scores both life and motor customers, or a general risk engine reused across product lines, can bring non-listed uses into scope through reuse. Ask whether the output for a life or health applicant is produced by the same system that handles other lines, and whether the purpose changed when the model moved. Record the intended purpose of each deployment, since that purpose drives classification.

What the fundamental rights impact assessment requires from insurers

The insurer must complete a fundamental rights impact assessment before first use of a life or health insurance pricing system that is high-risk under Annex III point 5(c). Article 27(1) sets out the required content in six parts, and the insurer, as deployer, owns the document. An independent body does not issue it unless the organization chooses to engage one. Start by listing every pricing or risk assessment model that touches natural persons in life or health lines, because the assessment is written per system and each one needs its own record.

Article 27(1) asks for six things. The first is a description of the deployer's processes in which the system is used, plus the period and frequency of use. The second is the categories of people likely to be affected, such as applicants, policyholders or groups defined by health or age. The third is the specific risks of harm to those groups, for example unfair premium loadings or exclusion from cover. The fourth describes human oversight, meaning who can review, override or stop a model output. The fifth sets out what the insurer will do if those risks materialize. The sixth covers governance and complaint mechanisms. Assemble evidence for each part before drafting: process maps, pricing change logs, underwriter review records, and the complaint log design. Confirm with your legal team how each element maps onto your existing product governance and conduct rules.

Article 27(3) requires you to notify the market surveillance authority of the results by submitting the filled-out template. For an insurer that is a financial institution, confirm with your financial supervisor which authority receives the notification, because Article 74(6) assigns market surveillance for high-risk systems used by regulated financial institutions to the national authority responsible for their financial supervision. Keep the assessment current when the pricing model, its data or its use changes. Review the consolidated AI Act text with counsel to confirm the template version and filing steps that apply on your date of use.

How insurers should sequence the work before the December 2027 date

The sequence moves from knowing which models fall under Annex III point 5(c) to a documented fundamental rights impact assessment, customer explanations and a notification on file with the market surveillance authority. Each phase hands a defined record to the next, so the work can be checked in order before high-risk rules apply from 2 December 2027.

Build the AI system inventory
Start by listing every model, scoring tool, rules engine with a statistical component and vendor product that touches underwriting, pricing or claims for individual people. Include systems built in-house, bought from vendors and embedded in core policy administration platforms, since embedded features are easy to miss. Pull owners, data sources, the decisions each system informs and the business lines it serves. The output is a complete inventory signed off by the business owner for each system, and you know it is done when a second reviewer can trace every pricing and risk assessment decision in the insurer to a listed system.
Scope life and health pricing systems
Test each inventory entry against Annex III point 5(c), which covers AI intended for risk assessment and pricing of natural persons for life and health insurance. Other lines such as motor or property are not listed under that point, so record why each excluded system falls outside it, and also check whether it meets another Annex III category or an Annex I route. Confirm the intended purpose in writing, because the classification follows the purpose the provider sets out and the way the insurer actually uses the system. The output is a scoped register that marks each system as in scope, out of scope or unclear, with the reasoning and the person who approved it. Draft guidelines on classification were published on 19 May 2026, so check them when you record the reasoning.
Confirm provider or deployer role for each system
For each in-scope system, decide whether the insurer is the provider (it develops the system or places it on the market under its own name) or the deployer (it uses a system supplied by someone else). Many insurers hold both roles for different systems, and a vendor product customized for the insurer can shift the role, so review contracts and change history rather than relying on the vendor's marketing. Ask each vendor for the technical documentation and instructions for use it has provided. The output is a role record per system with the contract clause or development evidence that supports it. The step is complete when every in-scope system has a named role and every vendor has confirmed what it supplies.
Complete the fundamental rights impact assessment
Under Article 27(1), a deployer of a life and health insurance pricing system must complete a fundamental rights impact assessment before first use. The assessment has to describe the deployer's processes and how long and how often the system runs, the groups of people affected, the specific risks of harm, the human oversight measures, and what the insurer will do if those risks materialize, including governance and complaint handling. Involve the risk, legal, data protection and actuarial functions, and keep the reasoning behind each risk rating. The output is a dated, approved assessment for each system. The step is complete when the assessment is ready to be submitted in the template the market surveillance authority requires.
Put quality management and documentation in place
Where the insurer is the provider of an in-scope system, set up a quality management system that covers the aspects listed in Article 17, including the risk management, data governance, technical documentation, logging, record keeping and post-market monitoring duties that apply to high-risk systems. Article 17(4) deems financial institutions compliant for most of these through their existing governance rules under financial services law, but risk management, post-market monitoring and incident reporting remain separate duties, so confirm with your supervisor how your governance rules cover each one. The output is a documented QMS and a technical file for each system you provide. Ask whether the harmonised standard EN 18286:2026 on quality management, cited in the Official Journal on 14 October 2026, applies to your setup and how your current quality framework maps to it.
Design customer explanation processes
Article 86(1) gives an affected person the right to clear and meaningful explanations of the role the AI played in a decision with legal or similarly significant adverse effects on health, safety or fundamental rights. For life and health pricing, this typically covers decisions such as a higher premium, a declined application or altered cover. Write a standard explanation that states the AI's role and the main factors in the decision, train the staff who answer complaints, and define how a customer requests a review by a person. Test the explanation on a sample of real cases before launch. The output is an approved explanation template, a complaint and review procedure, and logs showing that requests were routed and answered.
Notify the market surveillance authority
Article 27(3) requires the deployer to notify the market surveillance authority of the results of the fundamental rights impact assessment by submitting the completed template. For high-risk systems used by regulated financial institutions in direct connection with financial services, Article 74(6) names the national authority responsible for their financial supervision as the market surveillance authority, so confirm with your supervisor which body receives the notification. Keep a record of the submission date, the system it covers and the version of the assessment sent, and set a process to update the notification when the system or its assessment changes. The output is a notification record for each system. The step is complete when each in-scope system has a filed notification and a named owner for updates.
Confirm the schedule and scope in writing
Timing depends on the number of models, vendors and contracts that need review, and on how much of the QMS and documentation already exists. Ask any implementation partner for a written scope that lists the systems covered, the deliverables for each phase, the evidence each deliverable produces and the responsibilities of your staff, vendors and any independent assessor. Be clear that a partner can prepare systems, controls and evidence, while only the regulator or an independent body makes formal determinations. The output is a signed scope and plan that you can measure progress against.

What EU AI Act compliance for insurance pricing costs and who is paid

This table lists who is paid for each part of AI Act work on life and health risk assessment and pricing, whether the cost is one-time or recurring, and what drives it up. Use the last column to build a written scope that vendors and advisers can price against, since no fixed figures apply to every insurer.

Cost component	Who is paid	One-time or recurring	What drives cost and what to request in a quote
Internal actuarial, data science and model owners	Your own staff	Recurring	Number of life and health pricing models in scope and how often they are recalibrated. Ask the adviser or partner to name the internal roles they expect you to fill and the hours they assume for each.
Internal legal and compliance staff	Your own staff	Recurring	Breadth of the model estate and the number of product lines affected. Confirm who signs off the Article 27 assessment and who answers customer explanation requests under Article 86.
Implementation partner for AI system inventory, documentation and evidence	External implementation partner	One-time, then periodic refresh	Number of systems, data sources and vendor-supplied models to document. Request a written scope listing deliverables, the systems covered and what remains with your team.
Fundamental rights impact assessment support	External adviser or partner, with internal sign-off	One-time, with periodic review	Number of deployments and the depth of analysis for each. Request the assessment template you will use, the review cycle and the process for filing results with the market surveillance authority under Article 27(3).
Tooling for logs, model registry and documentation	Software vendor or hosting provider	One-time setup, recurring licences or hosting	Where logs are stored, retention needs, and whether the tools run inside your own infrastructure. Ask for itemized setup work and recurring licence or hosting terms, and confirm which features are included.
Legal advice on scope and financial supervisor relationship	External counsel	One-time, then as needed	Questions on whether specific products fall under life and health pricing, and how your national financial supervisor will act as market surveillance authority under Article 74(6). Ask for a fixed-scope opinion with a defined list of questions.
Conformity or certification work by an independent body	Independent assessor or certification body, where one applies	One-time, with periodic surveillance where applicable	Only needed where a specific system falls under a route that requires third-party involvement. Most Annex III systems use internal control under Annex VI, so confirm the route in writing before engaging any body.

Is the insurer the deployer, the provider or both?

When an insurer licenses a life or health pricing or risk assessment model from a vendor and uses it under its own name and decisions, the insurer is normally the deployer. The deployer duties apply to how the system is used: following the provider's instructions, assigning human oversight to people with the right competence, keeping logs under its control, monitoring operation, and telling affected people when they are subject to the system. Before first use, Article 27 requires a fundamental rights impact assessment that describes the processes, period and frequency of use, affected groups, specific risks of harm, oversight measures, and what happens if risks materialize. The results are notified to the market surveillance authority using the template.

Deployer obligations (Article 26): use the system per the provider's instructions, assign oversight, keep logs, and monitor operation.
Article 27 assessment: complete the fundamental rights impact assessment before first use and file the results with the authority.
Evidence kept: the assessment, oversight records, log retention, monitoring reports and customer explanation templates.
Contract asks: the instructions for use, the documentation the vendor will provide, log access, notice of model changes, and cooperation with the insurer's assessment.
Incident and change terms: how the vendor reports serious incidents and substantial modifications to the insurer.

Confirm with the insurer's supervisor how the financial supervisor will receive the Article 27 results and which internal governance rules apply.

How customer explanations and supervisory notifications work for insurers

Article 86(1) gives a person affected by a deployer's decision based on the output of an Annex III high-risk system the right to clear and meaningful explanations. For an insurer, the trigger is a life or health pricing or risk assessment decision that has legal effects or similarly significant adverse effects on the customer's health, safety or fundamental rights, such as a declined application or a materially higher premium. The insurer, as deployer, owns this duty, and the explanation must cover the AI's role in the decision and the main elements that drove the outcome. Decide now who writes these explanations, who approves them and where they are stored, because a customer complaint is the usual moment this duty is tested. A practical explanation pack usually contains four items: a plain statement that an AI system contributed to the decision and at what stage, the main factors that influenced the outcome in terms the customer can follow, the human review route, and a clear description of how to contest the decision and to whom. Test the pack with a sample of real decisions, including adverse ones, and check that a reviewer can rebuild the explanation from the logs and model outputs without the data science team. Confirm with your legal and compliance function how much technical detail the explanation must carry, since the Article does not prescribe a format.

Article 74(6) matters for insurers because, for high-risk AI systems placed on the market, put into service or used by regulated financial institutions in direct connection with financial services, the market surveillance authority is the national authority responsible for financial supervision. In practice, your notifications, requests from authorities and any supervisory questions about these systems will usually go to that financial supervisor rather than a general AI or data authority. Whether your life or health insurance activity falls under this rule depends on how your national law designates the supervisor and how your licensing is organized, so confirm the authority and the reporting channel with your supervisor before the first use of the system. The notification route is linked to the fundamental rights impact assessment under Article 27(3), which requires the deployer to notify the market surveillance authority of the results using the filled-out template. Ask your supervisor which contact point, format and timing it expects, and whether it wants the explanation templates and complaint records made available on request. Build those requests into your record keeping so that a supervisory question can be answered from existing evidence.

What makes insurance AI compliance heavier or lighter

For life and health pricing, the workload depends less on the AI technology than on how many models, vendors, product lines and jurisdictions the insurer runs, and how well it already documents and explains them. The cards below cover the factors that expand or shrink the work, and the controls an insurer can put in place early.

Number of pricing models in use

Each live model used for risk assessment or pricing of natural persons in life or health insurance needs its own classification decision, documentation, and fundamental rights impact assessment before first use. An insurer running a handful of models can work through them one at a time. One running dozens of scoring variants across underwriting, renewal and claims triage must first find them all. Build one model register that records every model, its purpose, its owner and whether it touches life or health pricing, then classify each entry against Annex III point 5(c) before scoping the work.

Third-party vendor models

When a pricing model comes from a vendor, the insurer is usually the deployer and the vendor is usually the provider, and the two sides hold different evidence. The insurer needs the vendor's technical documentation, instructions for use and logging design to run its own assessment, while the vendor may resist sharing training data details. Check contracts now for documentation access, change notification, audit rights and incident cooperation. A model that the insurer retrains or repurposes can also shift provider duties onto the insurer.

Quality of existing model documentation

Insurers that already keep actuarial model documentation, validation reports and change logs will find much of the required description of processes, affected people and oversight measures easier to assemble. Insurers whose pricing logic lives in spreadsheets, in the heads of a few modellers or in vendor black boxes will spend most of their effort reconstructing it. Test documentation against the elements the fundamental rights impact assessment asks for: processes, period and frequency of use, categories of people affected, specific risks of harm and oversight measures.

Retention of data lineage and logs

Human oversight, post-market monitoring and any later explanation depend on being able to show which inputs produced which outcome, under which model version, at what time. Insurers that retain input data, feature derivations, model versions and decision outputs for the relevant periods can reconstruct a contested decision. Those that overwrite data or do not version models will struggle. Confirm with the team that owns pricing data which logs exist today, how long they are kept, and whether they can be tied to a specific model release.

Product lines and jurisdictions

Each product line that uses life or health risk assessment, and each EU member state where it is sold, adds scope. A life product in one country and a health product in several may share one model or require local variants, and national supervisors or procedures can differ in practice. Map which products use which models and in which markets, so that one set of documentation and one assessment can be reused where the models are truly shared, and separate work is limited to genuine local differences.

How customer explanations are produced

Article 86 gives affected people a right to clear and meaningful explanations of the AI's role and the main elements of a decision that has significant adverse effects on them. An insurer that already generates underwriting reasons from a stable factor set, using a standard template, has a head start. An insurer that answers complaints case by case, or relies on a model that cannot give factor-level reasons, will need new processes and staff training. Draft one explanation template, test it against real underwriting outcomes, and confirm with legal counsel how it fits national rules.

Questions insurers ask about EU AI Act pricing duties

Does the AI Act cover motor or property insurance pricing?

No, not as a high-risk category, based on the Annex III text. Annex III point 5(c) lists AI systems used for risk assessment and pricing of natural persons in life and health insurance, and other insurance lines are not listed. That does not end the analysis. Confirm the scope with counsel before concluding that a motor or property model is outside the Act, because other obligations, such as transparency duties or the general AI literacy duty, may still apply, and the draft Commission guidelines on classifying high-risk systems should be checked for how the list is read. Document the classification decision for each model, including the reasoning.

Can our insurer carry out the fundamental rights impact assessment ourselves?

Yes. Under Article 27(1), the fundamental rights impact assessment is the deployer's duty, so the insurer, as the body using a life or health pricing system, must complete it before first use. The assessment describes its processes, period and frequency of use, affected groups, specific risks of harm, human oversight, and measures if risks materialize, including governance and complaint mechanisms. Under Article 27(3), the results are submitted to the market surveillance authority on the filled-out template. Outside help is optional. A partner can help structure the evidence, but the assessment and its conclusions stay with the insurer.

How much time from our actuarial, model and legal teams will this need?

The work draws on several internal roles, and the effort depends on how many pricing models are in scope and how well they are already documented. Actuarial teams explain the rating factors, model purpose and known limits. Model owners provide data lineage, version history, validation results and monitoring. Legal and compliance review the classification, the assessment and any customer-facing explanations. Customer operations define how complaints and explanation requests reach a person. Ask any partner for a written breakdown of these roles and the hours they expect from each, and check that the quote separates one-time documentation work from the recurring monitoring and review.

Does an external auditor have to certify our pricing system?

Usually not under the AI Act. Most Annex III high-risk systems use internal control, the conformity route in Annex VI, under which the provider checks its own compliance. Notified bodies are involved only for certain biometric systems and Annex I products under Article 43. Life and health pricing systems are generally not in those categories. An independent auditor or certification body can still be hired to review your evidence, but only an independent body issues a report or certificate. The insurer, as deployer, owns its compliance statements and cannot delegate them to a consultant.

How does the 2 December 2027 date affect our planning?

As amended by Regulation (EU) 2026/1744, the high-risk rules for Annex III systems apply from 2 December 2027, instead of 2 August 2026. That date is the point by which the high-risk duties, including the fundamental rights impact assessment for life and health pricing deployers, must be in place. Plan backward from it: inventory pricing models, classify each one, collect provider documentation, run the assessment, and set up explanation and complaint handling. Confirm the date against the consolidated text on EUR-Lex, because the Act has been amended twice, and track any updates to the harmonised standards that may change how you show conformity.

What should we ask a partner before we hire one?

Ask for a written scope that lists each model, the deliverables, and who signs what. Confirm the partner will prepare systems, controls and evidence, and that it does not issue audit reports or certificates. Ask how it will work with your actuarial, legal and model owner teams, and what internal time you need to provide. Ask how it handles the Article 86 explanation duty and the Article 27 assessment, and how it documents monitoring after launch. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure and prepares compliance evidence, and most engagements are fixed-scope with a written quote following the agreed scope.

How DeployOpen prepares insurance AI evidence ahead of supervisory review

DeployOpen prepares the systems, records and documents that a life or health insurer needs to show how its pricing and risk assessment AI works, who oversees it and how customers are told about decisions. The organization keeps ownership of its controls and its fundamental rights impact assessment, and an independent auditor or assessor reviews the result.

How we scope

We confirm which life and health risk assessment and pricing systems fall under Annex III point 5(c) and which lines sit outside it.
The written scope lists the systems, deployment environments, data flows, business units and documents covered before work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing, and ongoing support is available as a retainer.

How we build

We set up logging of model inputs, outputs and human overrides inside your own infrastructure so decisions can be reconstructed later.
We prepare the data needed for a fundamental rights impact assessment, covering processes, affected customer groups and oversight measures.
We document how individual decisions can be explained to customers in clear and meaningful terms, with tested complaint and review routes.

How we hand over

You receive the scoped documentation, evidence index and configuration records, mapped to the articles agreed in the statement of work.
We walk your compliance, actuarial and model risk teams through the evidence so they can answer supervisory questions themselves.
Where your financial supervisor needs the impact assessment results submitted, your team files them, and we confirm the template is complete.

How we support

A retainer can cover updates when pricing models change, evidence refreshes and periodic testing of the explanation and logging controls.
Ask any partner to confirm in writing which deliverables they hand over and which decisions stay with your internal governance and your auditor.
Confirm with your financial supervisor and legal counsel how the Article 17(4) financial sector route applies to your governance rules.

EU AI Act for insurers: life and health pricing