Actuarial AI: structuring domain knowledge for reliable, explainable AI

Insurers hold decades of business rules, actuarial models, documentation and lessons learned. Yet much of this heritage remains scattered and hard to use. With generative and agentic AI, the question shifts: the challenge is no longer just choosing the most powerful model, but passing this domain knowledge on to it.

This was the topic of the Institut des Actuaires (France) podcast, featuring Antoine Gruet, Head of Data & AI at Addactis, and Kevin Poulard, Actuarial AI Solutions Lead. This article covers the key points of their discussion: what domain knowledge really means, why it remains underused, how to integrate it into an AI system, and its impact on explainability, traceability and the role of the actuary.

For predictive AI, the source of value is well established: it lies first in the training data. For generative and agentic AI, the logic is different. Large language models (LLMs) are today overwhelmingly generic. Without domain knowledge, tools, a document corpus or formulas, their added value remains limited.

Value is created at three levels: a precise definition of the business need, its technical translation into the system, and the domain expertise the AI can access.
A model trained on public data relies on information that is often non-specific, not always validated and sometimes outdated. In a field as specialized as actuarial science, its performance is mechanically weaker and less reliable.

Domain knowledge is not a collection of documents. It is everything that turns a need into a relevant decision. It can be structured into four blocks:

• The need: which problem to solve, for which user, and what a good answer looks like.
• The resources: data, models, assumptions, business rules and regulatory references.
• The safeguards: controls, exceptions and limits of use. In other words, when to use a result and when to challenge it.
• Lessons learned: past decisions, corrections and insights from practice.

This is the difference between information and knowledge. A rule becomes domain knowledge when you know why, how and within which limits to apply it.

This knowledge exists in every insurance company, but remains underused. It is both deep and broad, spread across many people and teams. It is not always written down: a large part lives in oral practice and keeps evolving.

Documentation alone is therefore not enough. The approach is to give the AI reliable, ideally deterministic, tools and controls to query these resources. The AI then acts as a router rather than carrying everything itself. The method depends on the use case: a chatbot explaining a standard from a document corpus faces different challenges from a reserving solution, where the task is mainly to translate knowledge into formulas and optimization metrics.

This requires profiles able to bridge actuarial expertise and technical skills (software, security, AI). It is a barrier to entry, and a differentiating advantage for organizations that combine these skills.

We distinguish three notions. Explainability makes it possible to understand a result. Traceability makes it possible to retrieve what the system actually used. Reliability means checking that the system works correctly within the scope it was designed for.

A justification written after the fact, however convincing, is not proof. You need to be able to retrieve the sources consulted, the data used, the rules and formulas applied, and the tools involved. When a calculation is needed, it should be handled by a controlled tool rather than by AI. For example, if you ask why an IFRS 17 result has changed, the system must identify what varied, trace back the calculation dependencies and separate facts from its own interpretation.

Reliability is measured and maintained: testing on representative and edge cases before release, the ability to ask for clarification or to abstain, then performance monitoring as data, uses and regulations evolve. For an insurer, reliability does not mean infallible, but tested, traceable, monitored and open to challenge.

An AI can optimize what it is asked to, but cannot decide on its own what should be optimized. The actuary first sets the course: which problems to solve, what a good answer is, and which criteria to weigh. In reserving, choosing the method that best reproduces the past is not enough. Portfolio changes, data quality, stability between two closing dates and the ability to justify the choice must also be considered.

The actuary then defines the scope of validity: the data, methods and rules that apply, specific to each company. A general-purpose AI cannot know them unless they are passed on to it. Finally, the actuary brings professional judgement to make decisions under uncertainty and to know when the system must hand back control. Hence the message to actuaries: do not stay at the end of the chain. Without becoming AI engineers, they need to understand these systems well enough to keep control of what they delegate and to contribute to their design.

The value of actuarial AI depends less on the power of the model than on the domain knowledge that feeds it: a clearly defined need, structured resources, explicit safeguards and capitalized experience. This structuring is what makes explainable, traceable and reliable AI possible, provided actuarial expertise, software skills and AI are brought together.

The work does not stop at go-live. Products and regulations evolve: a system that is relevant today will need to be challenged, enriched and sometimes corrected. Actuaries have a central role to play.