EU AI Act for Insurers: Building an AI Governance Programme
EU AI Act for insurers: life and health insurance AI is high-risk (Annex III 5(c)). FRIA required. Deployer duties, GDPR overlap, deadline 2 December 2027.
Most insurers are already deployers, not providers. That distinction shapes everything. When a life insurer licences a third-party underwriting model to price individual policies, it sits on the deployer side of Article 26 — lighter obligations than the vendor who built the model, but still consequential ones: human oversight under Article 14, a Fundamental Rights Impact Assessment under Article 27, log retention for at least six months under Article 26, and ongoing monitoring of how the system performs in live use.
This page covers the governance-programme angle — inventory, classification, FRIA, oversight, documentation, and monitoring — for insurers building or deploying AI. If you want the classification analysis for life and health insurance risk-assessment and pricing specifically (Annex III point 5(c)), that use-case breakdown has its own page at EU AI Act and insurance risk pricing.
Which AI Systems in Insurance Are High-Risk?
The EU AI Act does not treat insurance as a uniformly high-risk sector. Classification is system-by-system, use-case-by-use-case, using the Article 6 rules.
The entry point that catches most insurers is Annex III, point 5(c): AI systems used for risk assessment and the setting of premiums for natural persons in life insurance and health insurance. That is the specific scope. Motor insurance, property insurance, marine cargo, and commercial liability lines do not fall under point 5(c) on the strength of the insurance connection alone — though they face their own obligations under GDPR and sectoral regulation, and individual use cases may still trigger other Annex III points.
The other Annex III points relevant to insurance operations:
- Point 5(b): creditworthiness assessment and credit scoring for natural persons — catches some payment-protection or credit-linked insurance decisions.
- Point 4(a): AI used in recruitment, selection, and promotion — catches HR systems at any large insurer.
- Point 1: biometric categorisation or emotion recognition systems — catches certain fraud-detection or customer-interaction tools (and some uses are prohibited outright under Article 5 rather than merely high-risk: see below).
The Article 6(3) filter
A system that falls within an Annex III point is not automatically high-risk. Article 6(3) provides that a system is excluded if it does not pose a significant risk of harm to health, safety, or fundamental rights — for example, it performs a narrow procedural task, or does preparatory work without influencing an individual outcome. The exclusion cannot be claimed lightly: any system that profiles natural persons remains high-risk regardless. And providers claiming the exclusion must document the assessment and register it. In practice, a model that determines or materially influences whether a natural person receives life or health insurance cover will rarely satisfy Article 6(3).
Prohibited practices (Article 5) — no governance programme fixes these
Three categories are banned outright with no compliance pathway:
- Emotion recognition in workplace or customer-interaction contexts (Article 5(1)(f)) — call-centre emotion scoring tools are prohibited.
- Real-time remote biometric identification in public spaces for law enforcement purposes (Article 5(1)(h)) — insurers running fraud investigations cannot deploy it on this basis.
- Social scoring that rates individuals based on social behaviour or inferred personal characteristics, with detrimental treatment in unrelated contexts (Article 5(1)(c)) — aggregating social-media or payment-pattern data to infer risk in ways that score the "whole person" crosses this line.
These have been prohibited since 2 February 2025. Inventory work should flag them for immediate retirement.
The Insurer's Role: Usually a Deployer
Most insurers procure and deploy AI systems built by specialist vendors — actuarial modelling tools, claims-triage engines, fraud-detection services. That makes them deployers within Article 26. The vendor who trained and placed the model on the market is the provider under Article 16, with the heavier obligation set.
The deployer's core duties under Article 26:
- Follow the provider's instructions for use.
- Ensure human oversight as required by Article 14 — see below.
- Monitor the system in production and inform the provider (and, where relevant, the competent authority) of serious incidents or malfunctions (Article 26, cross-referencing Article 73).
- Keep logs of the system's operation for at least six months (Article 26).
- Before deploying in workplaces, inform workers' representatives (Article 26).
An insurer that takes a vendor model and substantially modifies it — retrains it on proprietary data, changes its intended purpose, or puts its own name on it for market placement — shifts from deployer to provider under Article 25. That is a significant escalation in obligation. Document which systems you have materially adapted.
When the FRIA applies (Article 27)
The Fundamental Rights Impact Assessment is not a universal deployer obligation. Article 27 applies to deployers that are public bodies, and to deployers of systems covered by Annex III point 5(b) (creditworthiness) or point 5(c) (life/health insurance risk and pricing). If you are a private insurer deploying a life or health insurance pricing model, Article 27 applies to you. The FRIA must be conducted before deployment, registered in the EU database under Article 49, and updated whenever the system changes materially.
What the AI Governance Programme Covers
An insurer's AI governance programme under the EU AI Act is not a one-time project. It is a standing set of documented processes.
1. AI system inventory
Before you can classify anything, you need to know what you have. Map every AI system across underwriting, claims, fraud detection, pricing, HR, and customer service. For each system, record: the vendor and version, the intended use, the data inputs, the outputs and how they affect individuals, and the role your organisation plays (deployer or provider).
An inventory that lives in a spreadsheet and is updated annually is not sufficient. The Act expects a maintained register — Confir's assessment module builds and stores this as a structured AI inventory, classifying each entry and flagging gaps.
2. Classification under Articles 5 and 6
For each system in the inventory, determine the risk tier:
- Unacceptable risk (Article 5): retire immediately.
- High risk (Article 6 + Annex III): full obligation set applies.
- Limited risk (Article 50): transparency disclosure duties — chatbots must disclose they are AI; emotion-recognition outputs in permitted contexts require notification.
- Minimal risk: no mandatory obligations.
For every system potentially within Annex III, document either the basis for high-risk classification or the Article 6(3) exclusion assessment.
3. Fundamental Rights Impact Assessment (Article 27)
For life and health insurance pricing and risk-assessment AI, the FRIA must cover:
- The system's purpose, scope, and the population of natural persons affected.
- How the system was tested for disparate outcomes across protected characteristics — age, gender, disability status, ethnic origin.
- The interaction with GDPR Article 9 (health data is special-category data) and GDPR Article 22 (automated decision-making with legal or significant effects).
- The interaction with the EU Gender Directive (2004/113/EC), which prohibits using gender as an actuarial factor in retail insurance — a pricing model that learns gender as a proxy through correlated variables still raises compliance questions even if the variable is not explicitly in the feature set.
- Mitigation measures: thresholds for human review, overrides, recourse mechanisms.
The FRIA is a living document. It should be updated when the model changes, when new bias indicators emerge in monitoring, or when the regulatory guidance evolves.
4. Human oversight (Article 14)
Article 14 requires that deployers are able to:
- Understand the system's output and reasoning to the extent needed to detect and correct errors.
- Override or halt the system before a decision takes effect.
- Monitor whether the system operates as intended.
In practice, for a life or health insurance underwriting system, this means that no individual underwriting decision can be finalised by the model alone. A qualified professional — an actuary, an underwriter with domain knowledge — must review the system's output, have access to the reasoning (feature weights, confidence scores, anomaly flags), and retain the authority to reject or modify the recommendation. Training records should document that oversight personnel understand what the model does and does not do.
The oversight requirement is not satisfied by a checkbox review. A reviewer who approves every model output without engaging with the reasoning is not exercising meaningful oversight. Build review workflows that surface the model's uncertainty and demographic performance data.
5. Technical documentation and the provider's package (Article 11)
If your insurer is the provider (built the system in-house, or adapted it enough to shift roles under Article 25), you must compile and maintain Annex IV technical documentation: training data characteristics, model architecture, performance metrics disaggregated by subgroup, validation protocols, known limitations. That documentation must be available to competent authorities on request.
If you are a deployer, you do not produce the technical documentation — the provider does. But you should review it before deployment. Article 13 requires providers to give deployers sufficient information to use the system correctly, including the system's intended purpose and limitations. Requesting and reviewing that package is part of deployer due diligence.
6. Post-deployment monitoring (Article 72 for providers; Article 26 for deployers)
Compliance does not end at deployment. Providers must maintain a post-market monitoring system under Article 72. Deployers must monitor for serious incidents and malfunctions and report them to the provider — and, where relevant, to the competent authority — under Article 26 and the timelines in Article 73.
Key Article 73 timelines for providers: 15 days from awareness for a serious incident (Article 73(2)); 2 days where there is a widespread infringement or serious disruption of critical infrastructure (Article 73(3)); 10 days where a death has occurred (Article 73(4)). Deployers are responsible for informing the provider promptly when they become aware of such events.
For insurers, "serious incident" in the context of an underwriting model could include a systematic error that caused a class of policyholders to be wrongly declined or materially overpriced — monitor for demographic outliers in outcomes, not just overall accuracy.
Interaction with GDPR and Sectoral Rules
The EU AI Act sits alongside GDPR, not in place of it. The most significant intersections for insurers:
GDPR Article 9 prohibits processing health data (special-category data) without an explicit legal basis. Life and health insurance models consume health data. Your lawful basis, data minimisation logic, and retention limits must be documented separately from the AI Act FRIA — but both exercises should happen together.
GDPR Article 22 restricts solely automated decisions that produce legal or significant effects on individuals. An insurer that declines a life policy application based purely on a model output, with no human review, may violate Article 22 independent of the AI Act. Article 14 of the AI Act raises a parallel (and often stricter) human-oversight requirement. Meeting the AI Act's human-oversight standard typically satisfies Article 22(3), which requires the right to human review — but map both obligations explicitly.
The EU Gender Directive (Council Directive 2004/113/EC) prohibits gender as a risk factor in retail insurance. This is enforced at the feature level, but proxy discrimination through correlated variables is a real risk that the FRIA process should surface. An actuarial model that does not name gender but learns it through postcode, vehicle type, or browsing behaviour still presents a compliance exposure.
The Deadline: 2 December 2027
Under the Digital Omnibus (political agreement reached 7 May 2026), stand-alone high-risk AI systems under Annex III — including life and health insurance risk-assessment and pricing AI — must comply by 2 December 2027. The original 2 August 2026 date has been deferred. Formal adoption of the Omnibus is expected before 2 August 2026.
That is not a long window for insurers who need to run an inventory, classify dozens of systems, conduct FRIAs, build or verify oversight mechanisms, and produce or obtain technical documentation. The documentation alone — even for a deployer reviewing a vendor's package — takes time to assemble properly. Governance programmes that start in 2026 are not early; programmes that start in 2027 are late.
Non-compliance with high-risk obligations (Article 99(4)): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, the fine is capped at the lower of the two figures (Article 99(6)).
How Confir Helps
Confir is a self-serve EU AI Act compliance tool for compliance, legal, and IT teams. Its rule-based, deterministic engine — same intake produces the same finding, with the logic human-readable and audit-defensible — maps directly onto an insurer's governance programme needs.
The classification module walks you through the Article 5 and Article 6 analysis for each system in your inventory, applying Annex III point 5(c) (life/health insurance), point 4(a) (employment), and point 1 (biometrics) logic via plain-English checklists. It derives your role — deployer, provider, or a mixed position — and sets the obligation scope accordingly.
The FRIA workflow covers Article 27's requirements for life and health insurance deployers: purpose scope, affected population, protected-characteristic testing, GDPR Article 9 and Article 22 cross-mapping, and mitigation documentation.
The assessment covers all four compliance areas — AIRC (classification and conformity), AITR (data and technical robustness), AITO (transparency and human oversight), AIGM (governance and monitoring) — and generates a compliance health score and risk register you can present to a regulator or board.
Pricing starts at €600/year. No consultants, no implementation project.
Frequently Asked Questions
Is all insurance AI high-risk under the EU AI Act?
No. High-risk classification is use-case specific. Under Annex III point 5(c), AI systems used for risk assessment and premium-setting for natural persons in life insurance and health insurance are high-risk. Motor, property, commercial, and other lines do not fall under point 5(c) on the insurance connection alone — though individual tools may trigger other Annex III points (employment AI under point 4(a), biometric tools under point 1) or face GDPR obligations regardless.
Most insurers buy underwriting models from vendors. Are they still responsible?
Yes, as deployers under Article 26. The vendor (provider) carries the heavier obligation set, but the deployer must follow the provider's instructions, ensure human oversight under Article 14, keep logs for at least six months (Article 26), monitor performance, and conduct a FRIA under Article 27 for life and health insurance pricing systems. The deployer cannot outsource accountability by pointing to the vendor — it must verify the vendor's compliance package before deployment.
What is the Article 27 FRIA and does every insurer need one?
The Fundamental Rights Impact Assessment (Article 27) is required for deployers of systems covered by Annex III point 5(b) (creditworthiness) and point 5(c) (life and health insurance risk and pricing), and for public-body deployers. A private motor insurer deploying only claims-triage AI does not owe a FRIA on that system. A life insurer deploying a premium-rating model does. The FRIA must be conducted before deployment and registered in the EU database under Article 49.
How does GDPR Article 22 interact with the AI Act's human-oversight requirement?
They overlap but are not identical. GDPR Article 22 restricts purely automated decisions with legal or significant effects on individuals — it requires a lawful basis, transparency, and the right to human review. The EU AI Act Article 14 requires meaningful human oversight of high-risk AI outputs before decisions take effect. An insurer that implements genuine Article 14 oversight — a trained actuary reviews the model's recommendation with access to the reasoning and retains authority to override — typically satisfies Article 22(3)'s right to human review at the same time. Document both obligations, but run the compliance check on each.
Does the EU Gender Directive affect how we use AI in insurance pricing?
Yes, indirectly. Council Directive 2004/113/EC prohibits using gender as an actuarial factor in retail insurance contracts. A model that does not contain gender as an explicit variable can still learn it through proxy variables — postcode, vehicle type, marital status, digital behaviour. The FRIA process required under Article 27 should include testing for proxy discrimination by gender and by other protected characteristics. Finding a proxy-gender effect does not automatically create a Directive violation, but it creates an obligation to investigate and document.
What is the compliance deadline for insurance AI?
Under the Digital Omnibus agreed in May 2026, the deadline for stand-alone high-risk AI systems — including life and health insurance pricing AI under Annex III point 5(c) — is 2 December 2027. This pushes back the original 2 August 2026 date. AI embedded in regulated products under Annex I follows a later deadline of 2 August 2028. The penalty ceiling for non-compliance with high-risk obligations is €15,000,000 or 3% of worldwide annual turnover, whichever is higher (Article 99(4)).
What records does a deploying insurer need to keep?
Logs of the system's operation must be kept for at least six months (Article 26). Technical documentation — produced by the provider — should be retained and available to regulators for the life of the system plus the statutory retention period. FRIA documentation must be registered and kept current. Human-oversight decisions, including overrides of model outputs, should be logged with timestamps and reasoning for audit purposes. If you are a provider, technical documentation and post-market monitoring records must be kept for ten years (Article 18).
Related guides
- EU AI Act risk classification levels
- responsible AI governance framework
- Article 6 high-risk classification
- EU AI Act explained
- Article 9 risk management system
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 →