AI and Solvency II: Models, Governance and Outsourcing

Solvency II does not address AI specifically. It reaches AI through governance, risk management, internal control, and outsourcing requirements that apply regardless of technology, which makes the questions practical rather than novel. This guide covers them, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

Where does AI meet the framework?

Through the existing requirements rather than through new ones.

Requirement area	Where AI arises
Governance	Accountability for systems supporting decisions
Risk management	AI failure modes in the risk framework
Internal control	Controls around model use and change
Key functions	Reliance on AI outputs, documented
Outsourcing	Model providers, where critical or important
Documentation	Written policies reflecting actual practice

When does a model provider count as outsourcing?

When a third party performs an activity that would otherwise be undertaken internally, and the activity is critical or important.

A model service embedded in a pricing or claims process may well meet that, which brings notification, due diligence, contractual, and ongoing oversight requirements. Firms that onboard a provider through a procurement card and discover this during a supervisory review have a problem that is administrative rather than technical, and no less disruptive for it.

How do AI systems affect key functions?

Where a system supports actuarial, risk management, compliance, or internal audit work, its use and limitations need documenting so the function holder can rely on it and explain the reliance.

The practical question a supervisor asks is what the function holder understands about the system's limits. A function relying on outputs it cannot characterise has a governance gap regardless of how good the outputs are.

What about pricing and underwriting?

Judgement stays with qualified staff. AI can assemble evidence, surface patterns, extract data from submissions, and prepare recommendations.

The decision on terms and pricing remains a regulated judgement with accountability attached. Build that boundary structurally, so the system cannot bind terms that a qualified person has not approved — and so that fairness questions about differential outcomes have a human decision to examine.

What evidence do you need?

Documentation of where AI supports key functions and with what limitations, outsourcing registers including model providers where relevant, due diligence and contract evidence, validation records, and the basis for pricing and underwriting decisions.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes limitation documentation and decision-basis capture into delivery. A function holder relying on a system needs a written account of what it does badly, not only what it does well, and producing that requires evaluation against realistic failure cases.

For pricing and claims, capturing the basis of each recommendation is what makes later fairness and consistency questions answerable at all.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Onboarding a model provider without considering outsourcing requirements. Documenting capabilities without limitations. Letting a system bind terms without approval. And treating differential-outcome testing as optional in pricing contexts.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How does this interact with the EU AI Act?

They stack. Solvency requirements apply through existing supervision, and AI Act obligations apply where a system falls within its scope — including certain insurance pricing and risk assessment uses.

One evidence base serves both, and firms that build documentation, testing, and oversight evidence once find the Act's requirements largely a mapping exercise. See EU AI Act high-risk obligations.

What should you do first?

Check whether any model provider in a pricing, underwriting, or claims path has been assessed under your outsourcing framework. That gap is common and administratively expensive to close late.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: limitations documented alongside capabilities so function holders can explain their reliance, decision bases captured for pricing and claims recommendations, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and Basel model risk.