AI for Life and Health Insurance Pricing: EU AI Act Compliance Guide
AI for life and health insurance pricing is high-risk under Annex III point 5(c). Provider, deployer, and FRIA obligations apply from 2 December 2027.
Annex III of the EU AI Act catches a specific slice of the insurance market — not all of it. Point 5(c) covers AI systems "intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance." Motor insurance pricing, commercial property underwriting, marine cargo — none of those fall under this provision (though GDPR and sector regulation still apply). If your AI system prices life cover or health premiums, you are in scope. If it prices a fleet policy, you probably are not.
That scope limit matters because the compliance obligation stack for a high-risk system under Annex III is heavy. Understanding exactly what triggers it — and what does not — is the first decision you need to get right.
What Annex III Point 5(c) Actually Covers
Annex III organises high-risk use cases under eight headings. Point 5 addresses "access to essential private and public services and benefits." Sub-point (c) within that heading covers life and health insurance risk assessment and pricing.
The trigger is the intended purpose of the system. An AI that ingests health questionnaire responses, medical history, and actuarial data to set a life insurance premium or to determine a health insurance risk band is clearly within scope. So is a system that decides whether to accept or decline an applicant, or that determines which conditions to exclude from coverage.
The Article 6(3) filter can exempt some Annex III systems from high-risk status — but only where the system poses no significant risk of harm to health, safety, or fundamental rights. A system that directly prices access to health or life insurance for natural persons will not survive that filter. Access to life and health insurance is treated as an essential service; disparate pricing or wrongful exclusion from cover can cause serious financial and health harm. Any system that profiles natural persons in this context is always high-risk.
Providers asserting a 6(3) exemption must document their reasoning and still register the system under Article 49 in the EU database.
The Scope Limit Worth Knowing
Motor insurance pricing is not caught by Annex III point 5(c). Neither is commercial lines underwriting or property insurance. That does not mean those domains are unregulated — GDPR, Solvency II, and sector conduct rules apply — but they do not inherit the full EU AI Act high-risk obligation stack from this provision.
Some AI vendors serve multiple insurance lines with the same model. If a single scoring model is used for both life insurance and car insurance pricing, the life and health use triggers high-risk classification for that deployment. The provider's obligations attach to the intended purpose, and if that purpose includes life or health pricing, the full regime applies.
Provider Obligations: The High-Risk Stack
A provider under Article 16 is the entity that develops or places the AI system on the market under its own name. In insurance AI, that is typically the insurer that built a proprietary pricing model in-house, or the insurtech vendor supplying a scoring engine to insurers. The provider bears the heaviest obligations.
Risk management system — Article 9. Before the system goes on the market, the provider must establish, document, and maintain a risk management system that runs across the system's entire lifecycle. This is not a one-time exercise. It includes iterative risk identification, estimation, and evaluation; residual risk controls; testing under real-world conditions; and documented measures to address each identified risk. For a life insurance pricing model, actuarial bias, data quality failures, and distributional shift as the insured population ages are all foreseeable risks that the Article 9 system must address.
Data and data governance — Article 10. Training, validation, and testing datasets must meet quality criteria relevant to the intended purpose. For life and health insurance, that means examining whether historical underwriting data encodes prior discriminatory practices — older datasets often reflect exclusions or loadings for conditions that are now prohibited grounds under GDPR and the Equal Treatment Directive. Article 10 requires the provider to document data sources, data-cleaning measures, and the representativeness of datasets. If the training data under-represents a demographic group, the provider must document that limitation and its effect on accuracy.
Technical documentation — Article 11 and Annex IV. Before placing the system on the market, the provider must compile the Annex IV documentation package: a general description of the system and its intended purpose; a description of the components and their development; the risk management records from Article 9; performance monitoring and testing data; the data governance measures from Article 10; the logging capabilities; information provided to deployers; and the instructions for use. This is a substantial document. Insurers building a pricing model in-house often discover it takes six to nine months to assemble if they have not been maintaining the underlying records throughout development.
Transparency to deployers — Article 13. High-risk systems must come with clear information enabling deployers to understand the system's capabilities, limitations, accuracy, and the conditions under which it may fail. For an insurance pricing engine, this means the provider must disclose known accuracy variances across demographic groups, what the system cannot do (for example, it does not account for post-diagnosis changes in health status), and how the deployer should configure human oversight.
Human oversight by design — Article 14. The provider must design the system so that natural persons can oversee its operation, understand its outputs, and intervene or halt it. In practice this means the system must produce outputs that are intelligible to a human underwriter — not simply a score with no supporting explanation — and must include a mechanism to flag cases where the system's confidence is low or where inputs fall outside the training distribution.
Accuracy, robustness, cybersecurity — Article 15. The system must achieve an appropriate level of accuracy throughout its lifecycle, remain resilient against errors, faults, and inconsistencies, and meet cybersecurity standards commensurate with the risks. For health data, cybersecurity controls must be correspondingly strong given the sensitivity of the inputs.
Conformity assessment — Article 43. Before market placement, the provider must undergo a conformity assessment. For most Annex III high-risk systems, the conformity assessment takes the form of an internal control assessment following Annex VI — the provider carries it out itself against the Article 9–15 requirements. A notified body is mandatory only where a third-party assessment is required by the specific Annex III provision or by a product safety regulation (Annex I systems). Providers should verify which pathway applies to their system. The output of the conformity assessment feeds into the EU Declaration of Conformity under Article 47.
Registration — Article 49. Before placing the system on the market, the provider must register it in the EU database. The registration must include the information in Annex VIII. Deployers can verify that their vendor's system is registered before they deploy it.
Post-market monitoring — Article 72. After market placement, the provider must actively collect and review data on the system's performance in real-world conditions, assess whether the system continues to meet its intended purpose and accuracy levels, and feed findings back into the Article 9 risk management system. Serious incidents — unexpected malfunctions with consequences for health or safety, or infringements of fundamental rights — must be reported to market surveillance authorities under Article 73.
Deployer Obligations: What Insurers Must Do
The deployer under Article 26 is the insurer using the AI system to price life or health policies for its customers. Most insurers buying a third-party pricing engine are deployers; an insurer that builds and markets its own model is likely both provider and deployer.
Deployer obligations under Article 26 include:
- Using the system strictly in accordance with the instructions of use provided by the provider under Article 13.
- Assigning human oversight to individuals with the necessary competence and authority to understand the system's outputs, identify anomalies, and intervene or halt the system where necessary.
- Monitoring the system for risks that emerge in their specific deployment context — the provider's post-market monitoring covers the system generally, but the deployer sees the real customer outcomes.
- Informing the provider of any serious incidents or risks they identify under Article 73.
- Ensuring that the natural persons involved in human oversight have the resources to perform that role effectively.
If an insurer substantially modifies the system — retraining the model on its own proprietary data, materially changing the intended purpose — Article 25 may convert it from a deployer into a provider, inheriting the full provider obligation stack.
The Fundamental Rights Impact Assessment (FRIA)
Article 27 requires certain categories of deployer to conduct a Fundamental Rights Impact Assessment before deploying a high-risk AI system. Insurers deploying AI for life and health pricing fall squarely within scope.
The FRIA under Article 27 must:
- Describe the deployment context, including the categories of natural persons affected and the decisions the system will inform or make.
- Identify the fundamental rights that could be affected — for insurance pricing AI, the principal risks are non-discrimination (access to essential services on equal terms regardless of protected characteristics), privacy and data protection (the system processes health data), human dignity, and access to healthcare or financial security.
- Assess the probability and severity of those risks.
- Identify the measures taken to mitigate or prevent those risks.
- Register the FRIA outcome in the EU database alongside the system registration.
The FRIA is not a bureaucratic formality. An insurer that prices health insurance using a model trained on historical claims data is making decisions that affect whether people can afford cover for pre-existing conditions, chronic illness, or disability. The proportionality and non-discrimination dimensions deserve genuine analysis, not boilerplate.
GDPR Intersection: Health Data and Automated Decisions
Two GDPR provisions intersect directly with AI life and health insurance pricing.
GDPR Article 9 prohibits processing special categories of data — including health data — except under specific lawful bases. Medical history, prescription records, and health questionnaire responses are all Article 9 data. An insurer using health data to price cover needs a lawful basis under Article 9(2), and the most defensible basis in insurance is typically explicit consent (Article 9(2)(a)) or substantial public interest with appropriate safeguards (Article 9(2)(g)). A data protection impact assessment (DPIA) under GDPR Article 35 will almost certainly be required given the scale and sensitivity of the processing.
GDPR Article 22 restricts automated individual decision-making that produces legal or similarly significant effects. A fully automated insurance pricing decision — where no human reviews the output before a premium is quoted or a policy declined — likely engages Article 22. The data subject is entitled to request human review, contest the decision, and obtain an explanation. Deployers should map their decision workflows against Article 22 before launch. Human oversight under EU AI Act Article 14/26 and GDPR Article 22 overlap in function, but they are separate obligations from separate instruments.
The interaction between these two frameworks means that a compliant life or health insurance pricing deployment requires coordinated legal analysis under both the EU AI Act and GDPR — not two parallel checklists run in isolation.
Discrimination and Actuarial Fairness
This is the sharpest practical tension in life and health insurance pricing AI. Actuarial fairness — the principle that premiums should reflect the individual's risk — has historically justified differentiation based on characteristics correlated with risk. Age, smoking status, and pre-existing conditions are examples. EU non-discrimination law and the GDPR significantly constrain which characteristics can be used and how.
The Gender Directive (2004/113/EC) has already prohibited using gender as a pricing factor in insurance (following Test-Achats, Case C-236/09). The EU AI Act adds an additional layer: even where a characteristic is legally permissible as a pricing factor, the provider must document the data governance around it (Article 10), test for disparate impact on protected groups (Article 9 risk management), and ensure the system's outputs do not constitute indirect discrimination by using proxies that correlate with protected characteristics.
A model trained on postal codes, occupation categories, or purchasing behaviour may appear neutral on its face but systematically charge higher premiums to groups sharing protected characteristics. Providers must audit their feature sets for proxy discrimination — and deployers must monitor live outcomes for disparate impact, both as a matter of EU AI Act post-market monitoring (Article 72) and as a matter of non-discrimination law.
Worked Example: A Mid-Sized Health Insurer
VitalCover GmbH is a German health insurer with 80,000 policyholders. It has licensed a proprietary health insurance pricing engine from an insurtech vendor. The engine ingests applicant responses to a health questionnaire, age, and occupation, and outputs a risk band that VitalCover's pricing team uses to set the annual premium.
Provider obligations — the insurtech vendor: The vendor is the provider under Article 16. It must maintain Article 9 risk management documentation covering known accuracy limitations of the model (for example, reduced accuracy for applicants over 70 because that cohort is underrepresented in the training data). It must compile the Annex IV technical documentation, complete the Article 43 conformity assessment, register the system under Article 49, and supply VitalCover with instructions for use that disclose the model's limitations and specify what human oversight the deployer must maintain. Any serious incidents — for example, systematic overpricing of a demographic group discovered post-launch — must be reported under Article 73.
Deployer obligations — VitalCover GmbH: VitalCover is the deployer under Article 26. Its compliance tasks include:
- Verifying that the vendor has completed conformity assessment and that the system is registered in the EU database before it goes live.
- Designating experienced underwriters as the Article 14/26 human oversight function, with clear authority to override the model's output and a documented escalation path when they do.
- Conducting the Article 27 FRIA before launch, documenting the fundamental rights risks (particularly for applicants with chronic conditions or disabilities) and the controls in place.
- Establishing a monitoring programme: quarterly review of pricing outcomes disaggregated by age band, occupation category, and declared health conditions; root cause analysis of any premium clusters that suggest proxy discrimination.
- Maintaining a GDPR Article 9 legal basis for health data processing and implementing the Article 22 mechanism allowing applicants to request human review of automated pricing decisions.
The compliance deadline for both vendor and insurer is 2 December 2027, under the Digital Omnibus political agreement of May 2026 (which deferred the original 2 August 2026 high-risk deadline). That is breathing room, not a reprieve — the vendor's Annex IV documentation alone, if it does not exist yet, will take months to build from scratch.
Penalties and the SME Cap
Failure to comply with the high-risk obligations attracts fines of up to €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(4)). This covers most provider and deployer failures: missing risk management documentation, absence of conformity assessment, inadequate human oversight, and failure to register.
For companies that qualify as SMEs or start-ups under Article 99(6), the fine is capped at the lower of the fixed amount and the percentage — a meaningful protection for smaller insurers or insurtech vendors. It is not an exemption from the obligations themselves.
Supplying incorrect or misleading information to a national market surveillance authority is a separate tier: up to €7,500,000 or 1% (Article 99(5)).
How Confir Helps
Three of the heaviest compliance tasks for insurers and insurtech providers have a process problem as well as a content problem — there is no shortcut to the substance, but there is no good reason for the structure to be assembled manually from scratch.
Classification certainty. Confir's rule-based classification engine applies the Article 6 and Annex III logic systematically: it captures the intended purpose, the user group, and whether the system profiles natural persons, and derives the risk tier. An insurer uncertain whether its analytics tool is a high-risk pricing system or a non-high-risk reporting tool gets a documented, reproducible finding — not a judgment call by a single lawyer.
Annex IV documentation and FRIA scaffolding. Once a system is classified as high-risk, Confir generates the Article 11 / Annex IV technical documentation structure and runs the Article 27 FRIA workflow. Both are pre-structured to the Act's requirements, so the compliance team fills in the substantive content rather than building the framework. The outputs are print-ready for submission to a notified body or a market surveillance authority.
Audit log and register. Every step — classification finding, documentation version, FRIA completion, Article 49 registration — is timestamped in an immutable audit log. If an insurer is asked to demonstrate compliance by a supervisory authority, the evidence trail is already assembled.
Confir's engine is rule-based and deterministic: same inputs produce the same outputs, the logic is human-readable, and there is no model that hallucinates a compliance conclusion.
Frequently Asked Questions
Does Annex III point 5(c) cover all insurance AI, or only life and health? Only life and health insurance. The provision covers "risk assessment and pricing in relation to natural persons in the case of life and health insurance." Motor, property, marine, and commercial lines are not caught by this specific provision — though GDPR, Solvency II, and other sector rules continue to apply to those domains.
Can an insurer claim the Article 6(3) exemption to avoid high-risk classification? The exemption requires that the system poses no significant risk of harm to health, safety, or fundamental rights. A system that directly prices life or health cover for natural persons — and that profiles those persons in doing so — will not meet that threshold. The Act specifies that any AI system involving the profiling of natural persons is always high-risk, regardless of other arguments.
Who is responsible for conformity assessment — the insurer or the AI vendor? The provider — typically the vendor that developed and places the model on the market under its own name — is responsible for the Article 43 conformity assessment. The insurer deploying the model under Article 26 must verify that the vendor has completed it and that the system is registered in the EU database (Article 49) before the insurer deploys it.
Is a Fundamental Rights Impact Assessment mandatory for insurers? Yes. Insurers deploying high-risk AI for life and health pricing are within the Article 27 FRIA requirement. The FRIA must be completed before deployment and registered alongside the system in the EU database. It must address discrimination risks, data protection risks, and any other fundamental rights risks material to the specific deployment.
How does GDPR Article 22 interact with EU AI Act human oversight requirements? They are parallel obligations from separate instruments. EU AI Act Articles 14 and 26 require the system to be designed and deployed so that humans can oversee and intervene. GDPR Article 22 gives the individual data subject the right to obtain human review of any automated decision with legal or similarly significant effects. Both must be satisfied. In practice, the deployer's human oversight function should also be the mechanism through which Article 22 requests are handled — but the two regimes have different triggers and different remedies.
What is the compliance deadline? 2 December 2027, under the Digital Omnibus political agreement of May 2026. This deferred the original 2 August 2026 high-risk deadline for stand-alone Annex III systems. Formal adoption is expected before 2 August 2026.
What fine applies if an insurer has no FRIA and no conformity assessment in place by the deadline? Up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). For SMEs and start-ups, the fine is capped at the lower of the two figures under Article 99(6) — but the obligation to have completed both the FRIA and the conformity assessment is not reduced.
Related guides
- Article 6 high-risk classification
- Article 6 high-risk classification
- Annex III high-risk AI list
- EU AI Act compliance requirements
- Article 3 key definitions
- Article 26 deployer obligations
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →