Leaders Insights
Leaders Insights

Stay at the top of your field, a little every day.

DomainsMarketingDataFinanceAI
ResourcesLearnTestToolsBlogGlossary
© 2026 Leaders Insights — All rights reserved.
Tracks/AI in insurance/Governance, risks and checks/Governance structures that keep pace with model change
4/4+150 XP

Governance, risks and checks

10The regulatory map every insurer must know+15011Where AI models quietly break in production+15012
The pre-deployment checklist that stands up to an audit
+150
13Governance structures that keep pace with model change+150

Governance structures that keep pace with model change

# Governance structures that keep pace with model change

A claims-severity model passes its launch audit in January. By June, three things have quietly changed: the mix of claims filed (more hail damage, fewer collisions), a vendor upstream updated its geocoding APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, and a new state regulation requires a fairness disclosure the model was never built to produce. Nobody flagged any of it, because nobody was assigned to look. This is how compliant AI systems become non-compliant without anyone changing a single line of code.

The fix is not a better audit. It's governance machinery that runs continuously, not once.

Why launch-day compliance isn't enough

Insurance AI models are not static. They face model drift, a gradual degradation in predictive accuracy as real-world data diverges from training data. A pricing model trained on 2022-2023 claims data starts misjudging risk as inflation, climate patterns, or driving behavior shift.

Regulators have caught up to this reality. The EU's AI Act (in force since 2024, with phased obligations through 2026-2027) classifies most insurance pricing and underwriting models as "high-risk," which triggers ongoing obligations, not just pre-market ones: continuous monitoring, logging, and human oversight for the model's entire lifecycle (European Commission AI Act overview).

In the US, the NAIC's Model Bulletin on the Use of AI Systems by Insurers (adopted by most states by 2024-2025) explicitly asks insurers to show a functioning AI governance program, not a one-time review. State insurance departments, including California's and Colorado's, have started requesting these governance artifacts during market conduct exams.

The message from both sides of the Atlantic: prove your oversight is alive, not archived.

The core machinery: three components

1. Model risk committees

A model risk committee is a standing cross-functional body (actuarial, compliance, IT, legal, and increasingly a data ethics lead) that reviews AI models on a schedule, not just before launch.

Concrete mandate: review every high-risk model quarterly, every medium-risk model semi-annually. "High-risk" here means models that materially affect a pricing, underwriting, or claims decision for individual consumers, echoing the AI Act's own risk tiering.

Committees should look at:

  • Performance drift versus baseline (accuracy, calibration)
  • Fairness metrics across protected classes (age, race proxies, disability status, zip code as a proxy variable)
  • Complaint and appeal volume tied to model-driven decisions
  • Vendor changes (e.g., a third-party telematics score provider updating its algorithm)

This mirrors the three lines of defense model long used in banking risk management: the model owner (first line), independent model risk/compliance function (second line), and internal audit (third line). Insurers like Allianz and AXA have publicly described adapting this structure specifically for AI governance.

2. Version control logs

Every model deployed in production needs a version control log: a timestamped record of what changed, why, who approved it, and what testing was done before release.

This isn't optional bookkeeping. Under the EU AI Act, high-risk AI providers must maintain technical documentation and logs sufficient for a regulator to reconstruct the model's decision logic after the fact. Without versioning, an insurer literally cannot answer "what model made this claims denial in March?" a year later.

A minimal log entry should capture:

model_id: claims_severity_v4.2
deployed_date: 2026-03-14
change_summary: retrained on 2023-2025 claims data; added 2 new features
approved_by: model_risk_committee (ref: MRC-2026-011)
validation_results: AUC 0.81 (prior: 0.79); fairness delta <2% across tested groups
rollback_plan: revert to v4.1, tested rollback time 12 min

This is the AI equivalent of a flight data recorder. When something goes wrong (a spike in complaints, a regulator inquiry), the log is the first thing examined.

3. Retraining triggers

The hardest governance question: when do you retrain a model? Waiting for annual review is too slow; retraining on every data blip is wasteful and destabilizing.

The answer is predefined retraining triggers: quantitative thresholds set in advance, so the decision isn't a judgment call made under pressure.

Common triggers used in practice:

  • Performance decay: a drop in model accuracy (e.g., AUC falling more than 3-5 percentage points from baseline) sustained over two consecutive monitoring periods
  • Population drift: a statistical shift in the input data distribution, often measured with a Population Stability Index (PSI); a PSI above 0.25 is a common industry rule-of-thumb for "significant drift" requiring action
  • External trigger: a new law (e.g., a state banning credit-based insurance scores), a catastrophic event that changes risk patterns (a major hurricane season), or a vendor discontinuing a data feed
  • Fairness trigger: disparate impact ratio crossing a set threshold (commonly referenced: the "four-fifths rule" from US employment law, sometimes adapted informally in insurance fairness testing)

Worked example: a motor insurer sets a PSI threshold of 0.25 on its risk score distribution. After a fuel price shock changes driving patterns, the quarterly PSI check reads 0.31. That single number, calculated automatically, triggers a mandatory model risk committee review within 10 business days, per the insurer's own policy. No debate about whether to look. Just a scheduled response.

Knowledge check

1. In the claims-severity model scenario, why did the model become non-compliant by June even though no code changed?

2. What is the best definition of 'model drift' as used in this lesson?

3. Why is a 'launch audit' alone insufficient for high-risk insurance AI models under frameworks like the EU AI Act?

MULTIPLE CHOICE

4. Select ALL correct answers about the underlying problem this lesson's governance machinery is designed to solve.

Select all the correct answers.

MULTIPLE CHOICE

5. Select ALL correct answers about what regulators (EU AI Act and NAIC Model Bulletin) now expect from insurers using high-risk AI models.

Select all the correct answers.

Putting it together: a governance calendar

Insurers that do this well run something like a recurring compliance calendar rather than a single audit event:

| Frequency | Activity |

|---|---|

| Continuous (automated) | Drift and PSI monitoring, fairness metric dashboards |

| Monthly | Complaint/appeal review tied to model decisions |

| Quarterly | Model risk committee review of high-risk models |

| Semi-annual | Medium-risk model review; vendor model re-certification |

| Annual | Full independent validation, regulatory filing update |

| Event-driven | Retraining trigger breach, new regulation, major external shock |

This structure also answers a question regulators increasingly ask directly: "show me your governance framework document," not just "show me your model's accuracy." The UK's Prudential Regulation Authority and Financial Conduct Authority have signaled the same expectation in their joint work on AI in financial services (Bank of England AI survey), even without a UK-specific AI statute equivalent to the EU AI Act.

Common failure modes to guard against

  • Governance on paper only: a committee charter exists but hasn't met in a year. Regulators check meeting minutes, not just charters.
  • No owner for third-party models: an insurer buys a fraud-detection model from a vendor and assumes the vendor's compliance covers them. It doesn't; the insurer using the model is generally still accountable under NAIC and EU frameworks.

Previous

The pre-deployment checklist that stands up to an audit

Triggers set but not acted on
: a PSI breach gets logged but no committee review follows. This is worse than having no trigger, because it creates a paper trail proving inaction.
  • Version logs without narrative: logging that "v4.2 deployed" without recording *why* makes the log useless for an actual audit reconstruction.
  • 🎬 [VIDEO: "Model Risk Management Explained" - youtube.com/results?search_query=model+risk+management+explained - a walkthrough of the three-lines-of-defense framework applied to predictive models, useful background before adapting it to AI-specific triggers]

    Key Takeaways

    • Compliance is a lifecycle property, not a launch-day certificate; both the EU AI Act and NAIC's Model Bulletin require continuous oversight, not one-time review.
    • A model risk committee needs a fixed review cadence (quarterly for high-risk models is a reasonable default) and cross-functional membership: actuarial, compliance, IT, legal.
    • Version control logs must capture the "why," not just the "what," so a decision can be reconstructed months or years later during a regulatory inquiry.
    • Retraining triggers should be quantitative and pre-agreed (e.g., PSI above 0.25, AUC drop beyond a set threshold) so retraining decisions aren't made reactively under pressure.
    • The biggest real-world failure isn't lacking a framework, it's having one that exists on paper but doesn't actually trigger action when thresholds are breached.