Artificial intelligence governance for insurers: Who owns which control under the AI Act and Solvency II

An insurer that uses AI has to show a supervisor that each system is used safely and that someone is accountable for it. Which rules apply depends on the system. AI used for risk assessment and pricing of natural persons in life and health insurance is high-risk under the EU AI Act, with obligations applying from December 2, 2027. AI systems that are not high-risk fall under Solvency II and the IDD, as EIOPA’s August 2025 Opinion explains. The AI Act’s rules on AI literacy and prohibited practices apply to every AI system. This guide maps each key control to its legal basis and usual owner. It compares NIST AI RMF, ISO/IEC 42001, and the OECD AI Principles, which help structure a program but do not replace legal obligations. It also sets out a five-step method for turning the controls into a working program.

Introduction: AI governance in an insurer

Artificial intelligence governance is a structured framework of policies, regulations, and practices that guides how AI systems are developed, deployed, and managed. In practice, it is less a document than an operating structure: the tools, processes, and roles needed to enforce a policy and to keep it current as AI use grows.

For an insurer, governance is not an abstract compliance exercise. AI is already used across the insurance value chain, including pricing, underwriting, claims management, and fraud detection. A pricing model that cannot produce an audit trail, or whose logic cannot be explained to a supervisor or a customer, is a liability regardless of how well it predicts.

This guide is written for architects, risk managers, and compliance leads in insurance companies.

Prerequisites

This guide assumes you understand how AI/ML systems are built and run in production and how governance works in an insurer. Formal training in AI regulation is not required.

What you should already know: how models move from development to production in your organization; the role of the Solvency II key functions (risk management, compliance, internal audit, and actuarial); the basics of the EU AI Act’s risk-based approach.

What you should already have: access to, or a mandate to compile, an inventory of the AI systems in use or under development; an executive sponsor; contacts in legal, risk, compliance, and the actuarial function who can contribute to policy design.

What this guide does not cover: detailed legal interpretation of individual AI Act provisions; governance controls specific to generative AI, which are touched on only in the Limitations section; technical implementation of model-monitoring tooling, which depends on your stack.

Why AI governance matters now

AI governance matters because, without it, an insurer using AI faces compliance failures, reputational damage, and operational risk that grow with every model added. Mirantis notes that demonstrating responsible practices builds consumer and partner confidence, while governance frameworks help identify and reduce risks such as compliance gaps and system failures.

The absence of governance rarely causes one dramatic failure. More often it produces a slow accumulation of untracked model changes, undocumented decision logic, and unclear ownership across teams. When a supervisor asks a direct question, such as who approved a model’s use in underwriting decisions, the organization often cannot give a clear answer.

The stakes are now explicit. Under the AI Act, non-compliance with the obligations of providers, deployers, and other operators, including those for high-risk systems, can be fined up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher. Prohibited practices may result in fines of up to EUR 35 million or 7% (Article 99). For SMEs, and for small mid-caps outside prohibited practices, the lower of the two amounts applies. Governance is becoming a precondition for operating AI in regulated markets, not optional infrastructure.

Artificial intelligence governance in insurance: AI Act, Solvency II, and EIOPA

The first governance question in an insurer is not “which framework?” but “which rules apply to this system?” Two regimes apply in parallel.

High-risk systems under the AI Act

Annex III, point 5(c) of the AI Act lists “AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance” as high-risk. After the AI Omnibus amended the AI Act in July 2026, the obligations for Annex III systems apply from December 2, 2027. Their providers must ensure that such systems meet the high-risk requirements: a risk management system (Article 9), data governance (Article 10), technical documentation (Article 11), record-keeping (Article 12), transparency toward deployers (Article 13), human oversight (Article 14), and accuracy and robustness (Article 15).

An insurer that uses such a system as a deployer must follow the instructions for use, assign human oversight to competent staff, and monitor the system (Article 26). Insurers largely meet their monitoring and log-keeping duties through the Solvency II system of governance (Article 26(5) and (6)). The insurer must also inform individuals that the system is used in decisions about them (Article 26(11)) and carry out a fundamental rights impact assessment before deployment (Article 27).

A person affected by a decision based on the system’s output has the right to an explanation of the AI system’s role and the main elements of the decision (Article 86). The right applies to decisions that produce legal effects or similarly significant effects that the person considers adverse to their health, safety, or fundamental rights. An insurer becomes the provider of a high-risk AI system if it develops the system, or has it developed, and puts it into service under its own name; puts its own name on an existing high-risk system; substantially modifies a high-risk system so that it remains high-risk; or changes the intended purpose of a non-high-risk system so that it becomes high-risk (Articles 3(3) and 25(1)). Annex III high-risk systems already on the market or in service before December 2, 2027 fall under the AI Act’s high-risk rules only if their design changes significantly afterward (Article 111(2)).

Every other AI system under Solvency II and the IDD

Insurance AI such as claims triage, fraud detection, non-life pricing, and customer-service assistants is usually not high-risk under the AI Act, but the classification depends on each system’s intended purpose. These systems are still subject to insurance-sector legislation and to the AI Act’s rules on AI literacy and prohibited practices. Customer-service assistants must also inform people that they are interacting with an AI system, unless this is obvious (Article 50).

On August 6, 2025, EIOPA published an Opinion that clarifies how the Solvency II Directive and the Insurance Distribution Directive apply to AI systems. The Opinion excludes systems that are high-risk or prohibited under the AI Act, does not set new requirements, and follows a risk-based and proportionate approach. Its framework covers data governance, record-keeping, fairness, cybersecurity, explainability, and human oversight.

AI governance compliance: Who owns which control

The matrix below maps each control to the rule it rests on and to the function that usually owns it. The allocation is a common starting point, not a prescription: adapt it to your organization’s structure and confirm it with counsel.

The matrix makes one thing visible that frameworks alone do not: most controls already have an owner in the Solvency II governance system. AI governance in an insurer is largely about extending existing key functions to AI systems, not about building a parallel organization.

Risks and challenges in AI governance

Challenges in AI governance include bias, lack of explainability, and shadow AI, along with regulatory requirements that move faster than internal policy. Bias risk emerges when training data reflects historical patterns that a model then reproduces at scale. For example, an underwriting model trained on historically skewed approval data can encode that skew into future decisions unless it is actively tested.

Explainability risk arises when a model’s decision logic cannot be reconstructed after the fact, a direct liability where an affected person can ask for an explanation. Accountability risk arises when ownership of AI outputs is not tied to identified stakeholders with clear lines of responsibility, a frequent failure when AI projects start without a handoff to the business owner.

Insurers face additional friction that framework documents do not capture. Core policy administration systems were not designed with model governance in mind, and retrofitting audit trails onto them is harder than designing them in. Data spread across product lines and legacy platforms also limits visibility into every AI system in production, a gap addressed directly in Step 1 of the methodology below.

AI governance strategy: Principles and best practices

Mirantis names five core principles of generative AI governance: fairness, accountability, privacy and security, transparency, and human oversight. Principles define what a governance program must achieve; best practices define how an organization puts them into operation.

The five principles

• Fairness: Outcomes must be equitable, and algorithmic decisions must not perpetuate or exacerbate societal inequalities.
• Accountability: Ownership of AI outputs lies with identified stakeholders, supported by clear lines of responsibility and feedback loops to address lapses.
• Privacy and security: Compliance with privacy laws and strong controls protect sensitive data throughout the AI lifecycle.
• Transparency: Open communication about AI capabilities, decision-making processes, and limitations supports informed use and lets stakeholders assess risk.
• Human oversight: Sustained human intervention ensures that unintended consequences are detected and addressed. In insurance, this principle also becomes a legal requirement for high-risk systems from December 2, 2027 (AI Act Articles 14 and 26).

A principle states an obligation (“accountability must exist”); a best practice is the mechanism that fulfills it (“a named model owner recorded in the AI inventory”). Organizations that conflate the two end up with a principles document that has no operational effect.

Best practices that put these principles into operation

• Involve legal, risk, actuarial, IT, and business stakeholders before a governance policy is finalized, not after.
• Run audits on a fixed schedule, not only after an incident.
• Review the governance policy at defined intervals and after every relevant regulatory change.
• Assign clear ownership before expanding AI to new products or processes. Ownership gaps compound as systems multiply.
• Record every governance decision in a form that survives staff turnover and supervisory review.

AI governance standards and frameworks compared

Several recognized frameworks help structure an AI governance program, and each answers a different need. None of them replaces the legal obligations described above; they are ways to organize the work.

Choosing a framework is rarely an either/or decision. A common pattern is to use the OECD principles for policy direction, NIST AI RMF to structure risk management, and ISO/IEC 42001 to formalize and certify the result, with the internal governance model connecting all three to the key functions that already exist.

Roles and responsibilities in AI governance

AI governance depends on clearly defined roles across the board of directors, the key functions, IT, and the business. Without unambiguous ownership, policy exists on paper only. What matters most is that someone owns AI governance and has both the accountability and the authority to act.

Ownership models differ. In some financial institutions, the model risk management team leads; in others, a dedicated AI governance group sits under the chief technology officer or under legal. A federated alternative lets each business unit run its own process within a shared central policy, trading consistency for speed and domain knowledge.

A functional structure typically includes:

• Board / executive sponsor: sets risk appetite and holds ultimate accountability for AI-related outcomes.
• AI governance committee: a cross-functional body (legal, risk, compliance, actuarial, IT, and business) that approves policy and reviews escalations.
• System owners: named individuals accountable for specific AI systems and their day-to-day compliance with policy.
• Key functions: risk management, compliance, actuarial, and internal audit, each covering the AI controls that fall into its existing remit (see the control matrix above).

Reporting lines matter as much as role definitions. A governance committee with no direct line to the executive board has influence but no authority, and authority is what separates enforced governance from a documented aspiration.

Step-by-step methodology for implementing artificial intelligence governance

Implementing an AI governance program takes five sequential steps: inventory and classification, policy design, role assignment, monitoring and audit, and continuous improvement.

Step 1: Inventory and classification

What you need before this step: an executive mandate to request information across business units. What to do: list every AI system in production or development, record its purpose, data sources, and decision impact, and classify it as one of three types: high-risk under Annex III of the AI Act; an Annex III system assessed and documented as not high-risk (Article 6(3) and (4)); or a system subject to sectoral rules and the general AI Act rules.

What you should have after this step: an AI inventory with a classification and a named contact for each system. Common failure point: Teams miss AI embedded in vendor software or deployed outside formal IT channels. Cross-check with procurement and cloud billing records.

Step 2: Policy design

What you need before this step: the inventory from Step 1. What to do: map each applicable requirement (the AI Act, Solvency II system of governance, and the IDD) to a specific policy clause, drafted with legal, risk, actuarial, and business input. What you should have after this step: an approved policy covering purpose, scope, and requirements per system class. Common failure point: a policy written by one function alone is rarely enforceable in practice.

Step 3: Role assignment

What you need before this step: the approved policy from Step 2. What to do: establish the governance committee and assign a named owner to each AI system and to each control in the matrix. What you should have after this step: an accountability map linking every system and control to a responsible person. Common failure point: ownership assigned to a team rather than a named person. Diffuse ownership leaves no one accountable.

Step 4: Monitoring and audit

What you need before this step: the owners from Step 3. What to do: define governance metrics, set a reporting cadence, log decisions, and include AI systems in the internal audit plan. What you should have after this step: a recurring audit calendar and a report to the board that covers governance as well as model performance.

Common failure point: metrics track model accuracy only, not compliance with the policy. Track both. For the data-quality side of monitoring, see Data monitoring for AI and regulatory reporting.

Step 5: Continuous improvement

What you need before this step: at least one completed audit cycle. What to do: review the policy against audit findings and regulatory change on a fixed schedule. What you should have after this step: a revised policy version with a change log. Common failure point: reviews that happen only after an incident turn governance into damage control.

Methodology scope: Insurers implementing a new AI governance program, or formalizing an existing one, across several AI systems and business units.

What this does NOT address: governance of a single isolated model outside a program; detailed legal interpretation of individual AI Act provisions; controls specific to generative AI, touched on only in the Limitations section.

Prerequisites: executive sponsorship, access to legal, risk, compliance, actuarial, and business stakeholders, and an AI inventory. See the Prerequisites section above.

Source: structured around the elements common to NIST AI RMF (Govern, Map, Measure, Manage), ISO/IEC 42001, and the AI Act requirements for high-risk systems.

Enterprise deployment context

In a regulated insurer, an enterprise rollout needs more steps than a pilot. A compliance review usually sits between Step 2 and Step 3: legal sign-off on policy language before roles are assigned reduces rework if requirements later change the policy’s scope.

Governance decisions in Steps 3 and 4 need to be logged in a system that survives staff turnover, not in informal documents. Alignment across business units often takes longer than the technical work because a federated model needs each unit’s leadership to accept a shared policy before monitoring can start consistently.

Practical examples and templates

A policy outline and a committee charter give you a concrete starting point instead of a blank page. They correspond to Steps 2 and 3 of the method above.

AI governance policy outline:

1. Purpose: why the policy exists and which organizational objective it serves.
2. Scope: which AI systems, business units, and data types the policy covers, and how high-risk systems are identified.
3. Roles and responsibilities: the committee, system owners, and key functions, as in the control matrix.
4. Requirements: the AI Act, Solvency II, and IDD requirements the policy implements, mapped per system class.
5. Monitoring and audit: metrics, audit cadence, and reporting lines, as in Step 4.
6. Review process: schedule and triggers for revising the policy, as in Step 5.

Governance committee charter (core elements): the committee’s mandate (authority to approve policy and to stop a deployment), membership, meeting cadence, escalation procedure for findings on high-risk systems, and reporting line to the executive board. Without an explicit mandate, a committee risks becoming an advisory group with no enforcement authority, the issue behind the funded-mandate question in the FAQ.

Both are starting points, not finished documents: adapt each clause to the insurer’s regulatory and organizational context before adoption.

Limitations and scope boundaries

No single governance framework fits every situation; knowing where a framework’s boundaries lie prevents false confidence about compliance.

• Legacy systems limit auditability. Frameworks assume systems can produce decision logs and model lineage; older core systems often cannot, and a separate remediation project may be needed before governance controls can apply.
• Generative AI needs its own controls layer. Generative AI brings risks, including output variability, confabulation, and harder-to-define boundaries that the original frameworks were not designed to address. NIST published a separate Generative AI Profile (NIST AI 600-1) as a companion to the AI RMF; it defines risks that are novel to or exacerbated by generative AI.
• Classification is a legal question. Whether a given system falls under Annex III is decided by the AI Act, not by a framework; confirm borderline cases with counsel rather than assuming that following a framework equals compliance.
• Data silos limit the inventory. Step 1 depends on visibility into every AI system; organizations with fragmented data ownership often underestimate their real AI footprint, which undermines every later step.