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
| Date | Provisions | Operational consequence |
|---|---|---|
| 2 February 2025 | Chapters I and II, including Article 4 | Define appropriate AI literacy and training measures. |
| 2 August 2025 | Governance and general-purpose AI models | Identify models used in internal or purchased systems. |
| 2 August 2026 | General application date; Article 50 | Review interfaces, generated content and information provided. |
| 2 December 2027 | Chapter III, sections 1 to 3, Annex III | Bring relevant systems, including certain life and health systems, into compliance. |
| 2 August 2028 | Chapter III, sections 1 to 3, Annex I | Examine 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:
- system identification and intended purpose;
- scope and risk-classification assessment;
- roles of the insurer, vendor and other providers;
- data, quality controls and known limitations;
- human oversight and escalation procedures;
- test plan, test results and acceptance record;
- versions, incidents, drift and corrective actions;
- available logs and retention periods;
- 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
| Period | Action | Purpose | Suggested owner |
|---|---|---|---|
| Days 1–15 | Define inventory scope and appoint its owner. | Establish coverage for classification and deadlines. | Sponsor; data or transformation lead. |
| Days 16–45 | Assess each use case and document the conclusion. | Account for purpose, entity role and profiling. | Business, Compliance, Legal, IT and Data. |
| Days 46–75 | Test 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–90 | Approve 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.
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.