AI is in actuarial work now. The interesting question is no longer whether to use it — that argument is over — but what the actuarial estate has to look like underneath for AI to actually deliver. The teams getting maximum value are not the ones who bolted an LLM onto their existing stack. They are the ones who have rethought the stack itself.
What is genuinely possible in 2026
Three years ago this list would have been speculative. Today it is a description of work we are doing for clients now.
- Agentic exploration of model outputs. A chief actuary asks “show me where the IFRS 17 movement on this product is coming from”, and an agent walks the engine outputs, the assumption history and the policy data to produce a defensible answer. Not “draft me a slide” — actual analysis with sources.
- End-to-end regression-tested model migration. Excel/VBA, SAS or in-house projection models migrated into Python, C# or F# with full regression testing against the legacy outputs. We have done this in months where it would previously have taken years.
- Conversational retrieval over the actuarial knowledge base. Methodology papers, control evidence, regulatory correspondence and historical assumption decisions become queryable in plain English, with citations.
- Anomaly detection across experience studies. Lapse, mortality and expense studies surface unusual cohorts and time-bucket movements before the actuary spots them, not after.
- Automated re-validation. When an assumption set changes or a foundation model gets re-trained, the validation harness reruns automatically and flags drift before the next reporting cycle.
- Documentation that keeps up. Model documentation regenerated from the live model, the assumptions service and the methodology source — not maintained by hand and out of date by the next close.
Why the old stack cannot capture this
The actuarial estate at most insurers is a chain of workbooks, vendor UIs, file handoffs and ad-hoc queries. The model engine produces files. A spreadsheet picks them up. Another spreadsheet reconciles. A pack gets assembled by hand. Methodology lives in PDFs filed by quarter. Assumptions live in someone’s drive.
AI tooling — agents, retrieval-augmented generation, code-modification systems — assumes the opposite of all of that. It assumes APIs, structured data, machine-readable documentation and reproducible runs. Pointed at a workbook estate, an AI agent can produce plausible answers and confident-sounding analysis, but it cannot ground them in your actual numbers. The “maximum capability” the AI vendors describe is real. It depends on prerequisites that most actuarial teams have not yet put in place.
Six properties an AI-native actuarial stack needs
None of these are exotic. They are the engineering disciplines we have been writing about for two years, applied to the new question.
- API-first engine access. The projection engine, the assumption set and the model outputs are all reachable through APIs. Anything that happens in the UI also happens through an API. Without this, agents cannot act on the engine; they can only narrate around it.
- Versioned, governed data products. Assumption sets, model runs and reporting outputs each live as a versioned data product with an owner and a contract. AI grounded in messy data is dangerous. AI grounded in a versioned, contracted dataset is reliable.
- Machine-readable methodology. Method papers, control evidence and historical decisions stored in a form RAG can consume — markdown or structured documents, not scanned PDFs. The same documents the auditor needs are the documents the agent needs.
- Reproducibility. Any prior reporting cycle can be regenerated bit-for-bit from versioned inputs. This is now table stakes, but most estates still do not meet it. Without it, AI cannot rerun comparisons or reproduce a finding.
- Granular permissions. Agents operate within explicit scope. Read these data products, write to that sandbox; do not touch production. The discipline is the same as for human users — just more carefully enforced because agents are faster.
- Evaluation harnesses. Every AI-assisted decision point has a defined test set, a tolerance and a cadence. Output that drifts outside tolerance gets paused for human review. This is how you make AI safe for production rather than confident-sounding for demos.
The migration question
The single most concrete thing AI changes for actuarial work right now is migration. Migrating an existing Excel, VBA or SAS model into Python, C# or F# used to be a two-year programme with a team of engineers and an actuary at the front. With current AI tooling and the right engineering harness around it, the same migration is a months-long engineering project. End-to-end regression tested. Reproducible. Cheaper than running the legacy system for another two years.
This matters because it changes what is realistic. Models that were too expensive to migrate three years ago are not too expensive now. The question moves from “can we afford to migrate this engine?” to “what would the team do once the migration is done?” That is a different conversation.
Where to start
If you are the chief actuary or CIO looking at this and trying to decide where the wedge is, here is the order we recommend.
Audit what the engine exposes. APIs, UI, file dumps. The size of the API surface tells you how much of the AI capability list above is available to you today and how much is blocked. This is a one-week exercise.
Pick one end-to-end use case. Pick narrow. Migration of one product family. Documentation of one model. Anomaly detection on one experience study. End-to-end means: source data → engine → model output → validation → disclosure, with AI-assisted steps at each stage.
Build the harness, not the agent. The valuable engineering investment is the evaluation harness, the API layer and the data products underneath. The AI agent on top is the easy part — and increasingly a commodity. The harness is the moat.
Treat it as ongoing telemetry, not a one-shot programme. AI in actuarial work is not a transformation that completes; it is a new operating mode. Drift, prompt sensitivity, retrieval freshness — these are recurring concerns, not project deliverables. We have written about how to validate AI-assisted actuarial workflows in detail elsewhere; the same discipline applies.
What “maximum capability” looks like, two years in
The well-run actuarial estate two years from now produces reproducible numbers, regenerates its own documentation, retains experienced actuarial judgement at the points that matter and lets AI do the heavy lifting in between. The team is smaller; the output is more defensible; the close cycle is shorter; the validation cycle is continuous. Documentation is current because it has to be — the AI generating it would otherwise drift. Numbers reconcile because the data products underneath enforce that.
None of that arrives by buying an AI product. It arrives by getting the underlying stack right. The teams that recognise this — and who treat AI as the forcing function for the engineering work they have been deferring — will get a compounding advantage. The teams that bolt AI onto the legacy estate will discover, expensively, that the chaos amplifies.
If you want to scope what an AI-native actuarial stack would look like for your estate, our Finance Modernisation practice and our Data Engineering practice cover the full set — APIs, versioned data products, evaluation harnesses, end-to-end regression-tested migration.