AI Act: life and health pricing among high-risk uses

Classify systems, establish provider and deployer obligations, and prepare controls for the applicable high-risk requirements.

Overview

Regulation (EU) 2024/1689 has applied since 2 August 2026, subject to the specific dates in Article 113. The transparency obligations in Article 50 also started to apply on that date, with transitional provisions to assess for existing systems.

For insurers, the main extension concerns the high-risk systems listed in Annex III. Sections 1 to 3 of Chapter III apply to those systems from 2 December 2027. Annex III, point 5(c), expressly covers AI systems intended for risk assessment and pricing in relation to natural persons in life and health insurance.

Insurers should use this period to classify their use cases, establish their role under the regulation and adapt their controls. An inventory, a documented assessment for each system and a high-risk compliance plan are practical starting points.

1. Application dates

DateProvisionsOperational consequence
2 February 2025Chapters I and II, including Article 4Define appropriate AI literacy and training measures.
2 August 2025Governance and general-purpose AI modelsIdentify models used in internal or purchased systems.
2 August 2026General application date; Article 50Review interfaces, generated content and information provided.
2 December 2027Chapter III, sections 1 to 3, Annex IIIBring relevant systems, including certain life and health systems, into compliance.
2 August 2028Chapter III, sections 1 to 3, Annex IExamine regulated products and their safety components.

The AI Omnibus entered into force on 27 July 2026. The European Commission confirms the extended dates for Annex III and Annex I high-risk systems. Specific transitional provisions still need to be checked for each system.

2. Classifying use cases

The inventory should cover production systems, pilots, purchased solutions and local developments that may meet the definition of an AI system. Each record should identify the intended purpose, the decisions made or supported, the people concerned, the data used, the responsible legal entity and any provider.

For Annex III use cases, Article 6(3) provides an exception where the system does not pose a significant risk of harm to health, safety or fundamental rights and does not materially influence the outcome of decision-making. The provision identifies four situations:

  • a narrow procedural task;
  • improving the result of a previously completed human activity;
  • detecting patterns or deviations, subject to appropriate human review;
  • a preparatory task for an assessment covered by Annex III.

An Annex III system that profiles natural persons remains high-risk. A provider relying on the exception must document its assessment before placing the system on the market or putting it into service, and register the system in the EU database.

Classification therefore belongs at use-case level. One technical solution may have different intended purposes and classifications depending on the entity using it and the decision it supports.

3. Other insurance AI use cases

P&C pricing, fraud detection, claims processing, document analysis, employee assistants and customer-service tools do not automatically fall under Annex III, point 5(c). Some uses may fall under another Annex III category, including recruitment, task allocation or employee assessment.

EIOPA’s Opinion of 6 August 2025 covers insurance AI systems that are neither prohibited nor high-risk under the AI Act. It addresses national supervisors and does not create new requirements. It explains how existing insurance governance and risk-management requirements apply to these uses.

The proportionate assessment considers:

  • the nature, volume and sensitivity of data;
  • the number of customers concerned, including vulnerable customers;
  • system autonomy and influence on decisions;
  • effects on customers, business continuity and financial position;
  • the ability to explain output, monitor changes and handle complaints.

These activities can fit existing risk management, model management, Product Oversight and Governance, internal control and outsourcing processes.

4. Provider and deployer responsibilities

An insurer’s role depends on what it does with the system. Under Article 25(1), a deployer can become the provider of a high-risk system by placing its own name or trademark on it, making a substantial modification or changing the intended purpose so that the system becomes high-risk.

Contracts with software vendors should therefore establish regulatory responsibilities and access to technical documentation, known limitations, testing conditions, version changes, incidents and logs.

For high-risk systems, Article 26 gives deployers operational obligations:

  • follow the instructions for use;
  • assign human oversight to people with appropriate competence, training and authority;
  • check input-data relevance and representativeness where the deployer controls the input;
  • monitor operation and handle incidents;
  • retain logs under their control for an appropriate period, at least six months unless other rules apply;
  • inform people when an Annex III system makes or supports decisions concerning them.

For financial institutions, some controls and logs can be included in governance and documentation already required by EU financial-services law.

5. Documentation

Keep documentation by system, including the history of classification decisions. The working file should include:

  1. system identification and intended purpose;
  2. scope and risk-classification assessment;
  3. roles of the insurer, vendor and other providers;
  4. data, quality controls and known limitations;
  5. human oversight and escalation procedures;
  6. test plan, test results and acceptance record;
  7. versions, incidents, drift and corrective actions;
  8. available logs and retention periods;
  9. information provided to users, customers and authorities.

For Annex III, point 5(c), Article 27 also requires a fundamental-rights impact assessment before first deployment. Existing data-protection impact assessment work can be reused or cross-referenced where it covers the relevant issues.

6. An initial 90-day programme

PeriodActionPurposeSuggested owner
Days 1–15Define inventory scope and appoint its owner.Establish coverage for classification and deadlines.Sponsor; data or transformation lead.
Days 16–45Assess each use case and document the conclusion.Account for purpose, entity role and profiling.Business, Compliance, Legal, IT and Data.
Days 46–75Test the process on two different systems.Review classification, vendor documentation, human oversight and acceptance testing.Business, Actuarial where relevant, Risk, Compliance and IT.
Days 76–90Approve classifications, control gaps and remediation.Assign responsibilities, budget and deadlines.Relevant existing committee.

At the end of this first cycle, management should have an initial inventory, reasoned classifications, assigned responsibilities, identified control gaps and a plan for systems subject to the 2 December 2027 deadline.

Sources: Regulation (EU) 2024/1689, Articles 6, 25, 26, 27, 50 and 113, Annex III; European Commission, AI Omnibus entry into force; EIOPA Opinion, 6 August 2025.

This scoping analysis retains its original publication date. The English edition and the main application dates were reviewed on 16 October 2026. Specific use cases require their own legal assessment.
Your next assignment

Let’s discuss what you need to deliver.

A programme to scope, a close to improve, a system to implement or a Finance function to lead. Let’s discuss your requirements and the assignment.

xro@xavier-robitaille.com+33 6 64 89 09 43LinkedIn · Xavier Robitaille ↗Based in Paris. France and international assignments.
Delivery in French and English.