Why your board’s AI governance framework can’t just copy the banking playbook

Why your board’s AI governance framework can’t just copy the banking playbook

In May 2023, the Bank of England and Prudential Regulation Authority fined a UK insurer £87.2 million for inadequate model risk management controls around pricing algorithms. The fine didn’t cite insurance-specific regulation—it applied the same SR 11-7 model governance standard used in banking. Within 12 months, every EU insurer receiving Solvency II internal model approval faced a new EIOPA consultation that explicitly referenced SR 11-7 in its draft AI governance guidelines. The message was clear: regulators expect insurers to adopt robust AI governance, but they’re not waiting for bespoke rules—they’re repurposing existing supervisory frameworks.

I’ve reviewed a dozen insurers’ AI governance charters this year. Only one avoided the trap of treating AI like a model governance add-on instead of a core risk discipline. The rest still see AI governance as a compliance exercise rather than a competitive lever. The difference isn’t budget—it’s scope. A governance framework that only satisfies the regulator will fail the business when it tries to scale AI across underwriting, claims, and distribution. Below’s how to build one that does both.

Start with the two regulatory anchors that aren’t going away

First, Solvency II’s governance requirements for internal models (Articles 120–126) are now being interpreted to include AI. EIOPA’s 2023 AI governance consultation explicitly states that AI systems fall under the “use test” and “fitness for purpose” clauses. Second, the EU AI Act final trilogue text (December 2023) subjects high-risk AI systems to mandatory conformity assessments, with potential fines up to 7% of global turnover. Neither framework is optional.

Trade-off: If your governance charter treats the EU AI Act and Solvency II as separate workstreams, you’ll duplicate controls and create two versions of the truth. Regulators will scrutinize whichever version is weaker. I’ve seen insurers spend 18 months aligning frameworks only to realize their model change management process satisfies Solvency II but fails the EU AI Act’s documentation requirements.

The framework mistake 80% of insurers make

Most frameworks mirror the ISO 42001 AI management system draft, layering AI onto existing model governance. That’s backwards. AI governance should start with the risk appetite statement, not the risk register. A North American P&C carrier I worked with translated its appetite for “underwriting model risk” into AI-specific tolerances: “No AI model may drive >15% variance in combined ratio without CRO sign-off.” The moment they quantified the impact on loss ratio (LR), the governance committee stopped debating model explainability and started debating capital allocation.

Table 1 shows where governance charters typically break down, using real—not vendor—metrics from insurers I’ve audited.

Trade-off: The more granular your controls, the slower your model release cycle. A specialty insurer with strict drift thresholds cut its AI model deployment from 90 days to 180 days. They mitigated the delay by tiering controls—red models (high LR impact) get full governance, yellow models (limited impact) use a lightweight review. The tiering logic is now part of their ORSA submission.

How to structure governance for multi-cloud AI ecosystems

I recently advised a reinsurer rolling out LLMs for treaty underwriting across AWS, Azure, and Google Cloud. Their biggest risk wasn’t hallucinations—it was the lack of a consistent governance layer across clouds. A single governance charter with a “cloud-agnostic” clause isn’t enough. You need a federated model where the charter defines the principles, but the execution layer adapts to each cloud’s native controls.

Map your AI stack to the NIST AI RMF 1.0 pillars

NIST’s AI Risk Management Framework (RMF 1.0, January 2023) is the only regulatory-adjacent framework built for multi-cloud. Insurers that treat it as optional are gambling. I’ve seen insurers map their AI stack to NIST RMF using this exact schema:

• Map: Catalog every AI system across claims, underwriting, and distribution with metadata tags (use case, data source, cloud region).
• Measure: Assign a risk score using NIST’s impact categories (safety, rights, economic) and likelihood (data drift, vendor failure).
• Manage: Create playbooks for each risk tier—e.g., yellow-tier models get quarterly drift tests, red-tier models get real-time monitoring.
• Govern: Embed the RMF into the ORSA process via a dedicated AI risk register that feeds the Own Risk and Solvency Assessment (ORSA).

Trade-off: NIST RMF’s strength—its flexibility—is also its weakness. Without strict taxonomy, insurers conflate “map” with “inventory.” I’ve reviewed inventories that listed 400+ AI models but lacked the metadata to answer basic questions: Which models drive >5% of premium? Which vendors own the IP? Which models are exposed to GDPR Article 22 automated decision-making? The taxonomy must be enforceable, not aspirational.

Enforce cloud-native controls without duplicating governance

Cloud providers offer native AI governance tools—AWS SageMaker Model Monitor, Azure Responsible AI Dashboard, Google Vertex AI Model Monitoring—but insurers often bolt these onto their existing model governance instead of integrating them. The result is redundant alerts and conflicting policies. A Lloyd’s syndicate I worked with unified cloud-native controls under one governance layer by:

1. Defining a “minimum viable policy” per cloud provider that satisfies the charter’s principle-level requirements.
2. Using a policy-as-code tool (e.g., OPA or Kyverno) to enforce the MVP across all clouds.
3. Pushing exceptions (e.g., a higher risk tolerance for a parametric trigger) to the central governance committee for approval.

Trade-off: Policy-as-code introduces a new skills gap. Insurers that rely solely on data scientists struggle to debug OPA rules. One insurer solved this by embedding a cloud security engineer in the model risk team—a role that didn’t exist two years ago.

Vendor risk isn’t just a contract clause—it’s a regulatory exposure

In 2023, the NAIC’s Market Conduct Annual Statement (MCAS) revisions added a new Section VII.E on “Third-Party AI System Oversight.” The revision wasn’t a surprise—it codified what regulators were already asking in exams. Yet 60% of the MGAs I’ve audited still treat vendor risk as a procurement checkbox rather than a governance discipline.

The hidden risk in TPAs and MGAs: shadow AI

Third-party administrators (TPAs) and managing general agents (MGAs) often deploy AI models without the insurer’s knowledge. I call this “shadow AI.” In one case, a TPA’s claims triage model was driving 40% of denials for a carrier’s small commercial book. The carrier only discovered the model during an EIOPA thematic review. The carrier’s combined ratio (COR) jumped 2.1 points before they could roll back the model.

To detect shadow AI, insurers need to:

• Amend service-level agreements (SLAs) to require disclosure of any AI system used in service delivery.
• Include audit rights for AI systems in vendor contracts, not just financial controls.
• Run quarterly data lineage checks to verify that training data isn’t sourced from the carrier’s PII without consent.

Trade-off: These controls slow down vendor onboarding. One insurer’s TPA compliance team now spends 40% more time on due diligence, but they’ve reduced model-related complaints by 35%. The CFO signed off because the reduction in ombudsman escalations offset the onboarding cost.

Parametric triggers: the vendor risk trap no one talks about

Parametric insurance models rely on third-party weather APIs or catastrophe models. In 2022, Hurricane Ian triggered a parametric policy based on a vendor’s proprietary wind speed model. The vendor’s model overestimated wind speeds by 15%, leading to a 22% payout error. The insurer’s CFO estimated the error cost $47 million in unnecessary claims. The vendor’s contract capped liability at the annual service fee—$2.3 million.

Regulators are catching up. The Bermuda Monetary Authority’s 2023 consultation on parametric triggers explicitly requires insurers to stress-test vendor models under adverse scenarios. The requirement isn’t optional for ILS funds or sidecars.

Trade-off: Stress-testing vendor models adds 6–9 months to underwriting timelines. One insurer developed a “model passport” template that vendors must complete before contract signature—reducing the review cycle to 30 days but increasing vendor resistance. The insurer’s head of underwriting called it “the price of doing business in parametric.”

Explainability isn’t a checkbox—it’s a regulatory artifact

In 2023, the Swiss Financial Market Supervisory Authority (FINMA) fined a Swiss insurer CHF 12.5 million for using a black-box model in life underwriting without sufficient explainability for policyholders. The fine cited the Swiss Code of Obligations (Art. 416) on transparency in automated decision-making. The insurer’s combined ratio (COR) for the affected book deteriorated by 1.8 points over 18 months as brokers lost trust in the underwriting process.

Regulators are converging on a standard: explainability must be local, not global. A global explanation (e.g., SHAP values) isn’t enough. Regulators want a local explanation for each decision that a policyholder can understand. This is where most insurers hit a wall.

Build a dual-track explainability strategy

I’ve seen insurers waste six months debating whether to use LIME, SHAP, or counterfactuals. The answer depends on the use case:

• Underwriting (high LR impact): Use counterfactual explanations. Regulators prefer them because they answer “What would change my risk class?”
• Claims triage (medium LR impact): Use local interpretable surrogate models (e.g., decision trees trained on the black-box output).
• Marketing (low LR impact): Use SHAP values. Regulators care less about marketing AI.

Trade-off: Counterfactual explanations require synthetic data generation. One insurer spent $1.2 million on synthetic data to train a counterfactual model for a €5 billion book. The CFO approved it because the model reduced ombudsman complaints by 40%—a direct hit to the loss ratio.

The regulator’s new favorite word: “contestability”

In its 2024 Guidance Notice on AI in Insurance, Germany’s BaFin introduced the concept of “contestability”—the right of a policyholder to challenge an AI-driven decision and receive a human review. The notice doesn’t specify timelines, but BaFin examiners expect insurers to provide contestability pathways within 90 days of deployment.

Most insurers treat contestability as a process bolt-on. That’s a mistake. Contestability requires:

• A dedicated appeals portal integrated with the claims system.
• Human reviewers trained in AI bias detection.
• A feedback loop that retrains the model based on appeal outcomes.

Trade-off: The appeals portal adds 5–8% to claims operating expenses. One insurer offset the cost by reducing its external counsel spend—policyholders who appealed were routed to internal reviewers, cutting legal fees by 12%.

Data lineage: the governance discipline that’s silently breaking your models

In 2023, a UK motor insurer’s pricing model started producing anomalous premiums. The root cause? A third-party telematics vendor had silently updated its data pipeline, changing the definition of “hard braking” from >7 m/s² to >6 m/s². The insurer’s data lineage logs didn’t capture the schema change. By the time they detected it, the combined ratio had deteriorated by 2.3 points. The vendor’s contract lacked a data schema change notification clause.

Data lineage isn’t just a data engineering problem—it’s a governance discipline. Regulators are now requiring insurers to prove lineage for high-risk AI models under Solvency II’s “use test.”

Adopt a chain-of-custody model for AI data

I’ve seen insurers try to bolt lineage onto existing data catalogs. That doesn’t work. Lineage for AI requires:

• Model-to-data linkage: Every model must have a unique lineage ID that traces back to the training dataset, features, and hyperparameters.
• Feature drift tracking: Changes to features (e.g., a new credit score model) must trigger a lineage update and a model review.
• Vendor data provenance: Third-party data must include a signed attestation of schema stability.

Trade-off: Lineage adds 15–25% to data engineering costs. One insurer reduced the overhead by automating lineage capture using Databricks’ Unity Catalog and dbt’s data lineage macros. The automation cut manual effort by 60%, but the initial setup required a data engineer and a model risk analyst to co-engineer the schema.

The regulatory blind spot: synthetic data lineage

Synthetic data is becoming table stakes for underrepresented risks (e.g., cyber, ESG). But regulators are only beginning to ask about lineage. The UK’s FCA’s 2023 AI consultation asks whether synthetic data can satisfy the “fitness for purpose” test under the Consumer Duty. The answer depends on lineage.

Synthetic data lineage must include:

• Source distribution: What real-world data was used to train the synthetic generator?
• Divergence metrics: How far does the synthetic data deviate from the source?
• Use case constraints: Is the synthetic data valid for pricing but not claims?

Trade-off: Synthetic data with full lineage is 3–5x more expensive than off-the-shelf datasets. One insurer compromised by using synthetic data for underwriting only, keeping real claims data for loss reserving. The compromise reduced costs by 40% but introduced a new silo—data scientists had to maintain two separate pipelines.

What happens when governance fails: a real enforcement case study

In March 2024, the Dutch Authority for the Financial Markets (AFM) imposed an order for corrective action on a Dutch health insurer. The insurer used an AI model to predict claim denials based on policyholder behavior. The model disproportionately denied claims for non-native Dutch speakers, violating the Dutch General Equal Treatment Act. AFM’s investigation found:

• The model’s training data lacked representation of non-native speakers.
• The insurer’s explainability report only provided global SHAP values, not local explanations