Embedded AI in Actuarial Workflows: Opportunities, Controls, and the New Discipline of Prompt Engineering
Introduction
IntroductionLike Micah Richards’ breakout against Aston Villa, AI ‘burst onto the scene’ in 2022 via large language models (LLMs) and browser‑based chatbots. Overnight, anyone could draft emails, summarise dense documents, sketch code and produce publishable prose. The real business value, however, lies in embedding AI in the tools where work actually happens—IDEs, data pipelines and documentation systems—where it can read context, propose changes and run tests. That turns AI from a novelty into an auditable, context‑aware teammate: faster code, tighter tests, proper versioning and a clear trail of changes.
The Rise of Embedded AI in Actuarial Practice
The step‑up comes when AI lives inside the tools we already use. It can read our code and data and doesn’t just tidy things—it suggests what to try next: “run a regression between parameter A and parameter B,” “check seasonality by month,” “plot residuals to see drift.” With permission, it can make small edits, run those checks, and show the results with a clear change log. That power needs guardrails: keep its access narrow (especially to production data), record every step, and require a person to approve anything that goes live. This is where prompt engineering becomes an actuarial discipline: write prompts like short specs—state the task, give the context, set the boundaries, and say how you’ll verify the answer.
Prompt Engineering: A Structured Actuarial Discipline
Prompt engineering means writing clear, testable instructions so AI produces reliable, repeatable results. It isn’t about clever questions; it’s closer to specification and testing than to “chatting with a bot.”
As the International Actuarial Association puts it (paraphrased): it’s the practice of designing precise, well‑structured inputs so AI returns accurate, relevant and reliable outputs. [1]
Where actuaries meet prompts:
- General LLMs (chat or API) for ad‑hoc analysis and drafting.
- Embedded assistants inside our everyday tools (e.g., coding, notebooks, data wrangling) where AI can read context and suggest next steps.
Why treat it like a discipline?
Model outputs can vary from run to run. So we apply the same controls we expect everywhere else in the model lifecycle: clear objectives, defined data scope, acceptance checks, logging, versioning, and human approval—so work is reviewable, reproducible and auditable.
The workflow (it’s not a one‑shot question):
Define the task → Add context (data, constraints, materiality) → Specify the output format → Let tools run → Validate → Log & version → Re‑test.
Key principles
- Start simple.
- If results wobble in testing, add structure—e.g. fixed output format, a small example, or a tool step—and re‑test.
- Increase complexity only as needed until the output is stable enough for the purpose.
- Keep access tight and changes logged; require human sign‑off before anything goes live.
This mirrors how actuaries build models: keep things as simple and standardised as possible to meet the need—no simpler. For prompts, that means begin with the minimum controls you believe will work, then tighten them step‑by‑step when validation shows you need more.
The following table contains a practical set of prompt patterns and a selection table to help you choose the lightest control that passes your checks, and layer on examples, schemas, retrieval or tool use only when the simple version isn’t stable enough.
| # | Technique | Use it when… | Say this in the prompt | Tiny actuarial example |
| 1 | Zero‑shot instruction | A one‑off task where a clear task + constraints + output format is enough. | State the task, constraints, and the exact output shape. | “Draft a model validation checklist (10 items) covering Data, Methods, Assumptions, Controls; output a numbered list.” |
| 2 | Few‑shot prompting | Zero‑shot is close but misses format, logic, or edge cases; you need the model to learn the pattern and decision rules, not just tone. | Provide 1–5 input → ideal output pairs. Tell it to follow structure/terms and handle the shown edge case; ask it to generalise the pattern, not copy text. | “Produce reserving commentary using the template Context → Signal → Conclusion → Evidence; include the ‘no material change’ behaviour shown in the examples.” |
| 3 | Role & audience | Audience and purpose drive tone, depth, and focus (board vs. regulator vs. devs). | Name the role and audience; set reading level and length | “You are an Actuarial Analyst writing for the Board. Summarise IBNR movement vs. Q1 in ≤200 words, one risk + one mitigation, no jargon.” |
| 4 | Structured output (schema) | Outputs must be consistent and machine‑readable for downstream checks/pipelines. | Provide a JSON/table schema and required fields. | “Return JSON: {test_name, materiality_basis, result, evidence_ref}.” |
| 5 | Tool / function calling | Output must be generated in a controlled way from a specified systems with logged, permissioned runs. | “You may call only: warehouse.query (read‑only), pricingEngine.runScenario. Do not compute results yourself. Plan → APPROVE → Execute → Log run IDs. No production writes.” | “Run Motor +5% scenario via engine; pull LR via warehouse; return outputs with job/run IDs; open a summary PR—no direct writes.” |
| 6 | Retrieval‑augmented (RAG) | You need answers consistent with/coming from internal or regulatory docs with citations. | “Answer only from the attached Assumptions Policy v3.2 and last year’s report. Cite doc + section/page; include a short quote. If not covered, say ‘Not covered’.” | Explain evidence needed to change lapse mid‑year; cite Policy xyx and Gov Std abc; ≤200 words.” |
| 7 | Iterative evaluation (“evals”) | You need stability and auditability over time. | Keep test cases and compare outputs across prompt or model changes. |
Applications Across the Actuarial Profession
The Society of Actuaries have identified a broad range of major actuarial use cases of generative AI [2]. These fall naturally into three tiers:
Tier 1 — Simple, low‑engineering tasks
Fast wins that need clear instructions and a quick check:
- Meeting transcription & actions: Auto‑capture minutes and action items from calls.
- Document summarisation & outlining: condense long policies/regulations; draft report skeletons.
- Basic code help: Small snippets, refactors, or formula translation (e.g., Excel → R/Python).
Controls: clear task + output format; brief human review.
Tier 2 — Moderately complex tasks (needs structured prompting)
Include examples, a role/audience, and a simple output schema; always review the result:
- Coding tasks: Generate/review actuarial code, write unit tests, explain algorithms.
- Data processing/analysis: clean and reshape files; produce summaries or simple visuals.
- Document generation: Templated text (rating reports, audit logs)—use few‑shot examples for consistency.
- Scenario & stress prompts: Craft scenarios with examples drawn from past stress cases.
Controls: few‑shot examples + schema/table format; human approval before use.
Tier 3 — Advanced engineering, higher‑risk tasks
These should be treated like any actuarial model, i.e. have full governance and oversight.
- Pattern recognition & anomaly detection: Detect unusual claims patterns, fraud signals, emerging trends.
- Predictive modelling: Forecast lapse rates, claims frequency/severity, expenses—using internal and external data.
- Simulations & scenarios: Climate/financial scenario generation, stress testing, “what‑if” analysis.
- Image‑assisted claims / fraud analysis: Triage/assessment from photos (e.g., auto damage, property loss).
- Personalisation at scale: Tailored products/pricing from customer data—high risk for bias and data protection.
Controls: formal testing and documentation, bias/fairness evaluation, data‑governance checks, strict permissions, human‑in‑the‑loop for edge cases, and production change approval.
How to use the tiers:
Start at Tier 1. If testing shows results aren’t reliable enough, add structure and move up a tier.
Navigating the Risk Landscape
While embedding AI into actuarial workflows can bring real productivity gains, it also introduces risks. Some of these risks can be material and so must be actively managed. The four most common risk categories—and the controls that keep them in check—are set out below. The emphasis is on controls you can evidence: structured outputs, permissioning, documented decisions, and repeatable tests.
| Risk | What can go wrong | Core controls (process & technical) | Evidence & assurance checks |
| Data bias & fairness | Outputs (e.g., pricing) could differ unfairly by demographic group due to biased or skewed training data, leading to mis‑pricing, reputational damage, or legal issues. | • Vet and approve training/retrieval sources for representativeness.• Test behaviour across protected characteristics and relevant business segments. • Establish escalation thresholds and remediation steps. |
• Slice‑and‑compare results across demographics/segments.• Track fairness metrics over time and document reviews and decisions. |
| Accuracy & completeness | Hallucinated facts, missing fields, or silent logic errors that slip into downstream processes. | • Use fixed output schemas (JSON/tables) so gaps and anomalies are obvious. • Build “truth sets” and checkpoints into the workflow (i.e. evaluate cases with known answers) • Require source provenance for factual claims |
• Pass/fail results on the eval suite before promotion• Reconciliations, totals and cross‑checks documented in the workpaper trail • Check sources |
| Data confidentiality & privacy | Leakage of sensitive data (e.g., personal info/claims details) via prompts, logs, or third‑party retention | • Keep sensitive data inside controlled systems; • Never paste raw data into external tools • Share only the minimum require • Apply masking/redaction, DLP scanning, and least‑privilege access • Record data handling decisions and approvals. |
• Access logs and DLP alerts reviewed; AI platform’s retention settings audited/verified • Data‑flow diagrams and approvals attached to the ticket/work item. |
| Prompt injection & adversarial manipulation | Malicious inputs (via external text, web content etc) steer the model to bypass safeguards or perform undesired and/or unintended actions. | • Segregate untrusted inputs from trusted context • Constrain tool use with allowlists and narrow permissions; sandbox execution. • Require explicit human approval for high‑risk actions (writes, deployments, data exports) • Run adversarial test cases against known attack patterns. |
• Red‑team test results and blocked‑action logs • Validate kill‑switches, timeouts, and audit logs via change control. |
Conclusion: AI as a Technical Colleague
AI is no longer a novelty on the periphery of actuarial work. Embedded in our tooling, it increasingly behaves like a technical colleague—reviewing code, running checks, drafting documentation and proposing changes. This brings real value in faster iteration, clearer audit trails and more consistent execution. However, it also introduces risk.
To manage that risk, we should treat AI‑enabled workflows with the same discipline as actuarial models: define purpose and scope; set data boundaries; enforce structured outputs; validate against truth sets; and require human approval for high‑risk actions. Least‑privilege access, DLP scanning, retrieval from approved sources, adversarial testing and comprehensive logging help reduce risk and strengthen auditability.
As with any major technological shift, the question is not whether actuaries adopt AI, but how to integrate it—safely, consistently and effectively—into day‑to‑day practice. With the right controls, it becomes an invaluable and reliable member of the team.
Sources:
[1] Source: International Actuarial Association, “Prompting for Actuaries,” Jan 2026
[2] SOA – Primer: Generative AI
David McCarthy, Asees Sachdev, Aidan O’Boyle
March 2026