Many "AI for underwriting" pilots get past the head of innovation, reach the actuarial team and stop there. Actuaries are trained to be sceptical of correlations they cannot explain, and they are right to be. Here is what an underwriting AI has to look like to ship through an actuarial review, and how to prepare for that meeting.
What actuaries reject, and rightly
- Black-box models that produce a risk score with no reasoning trail.
- Features that correlate with protected attributes (age, gender, location proxies) without justification.
- Models trained on data that does not represent the relevant policy population.
- "Continuous learning" systems that drift in production without locked, versioned baselines.
Each of these is a regulatory and reputational risk. Actuarial pushback is not obstruction; it is the right defence.
What gets through
Three patterns tend to survive actuarial review because they assist the underwriter rather than replace their judgement:
- Document-extraction copilot. A vision-capable LLM extracts structured fields from medical reports, KYC documents and income proofs. The underwriter still makes the call. Intake gets faster, risk decisions stay the same, and there is no regulatory novelty. At heart this is a document processing problem with an underwriting-specific schema.
- Risk-flag triage. The model surfaces "this application has these unusual features compared with our book". It is an exception queue, not a decision, and the underwriter still owns the outcome.
- Customer communication assistant. Drafts plain-language explanations of policy terms, exclusions and underwriting requirements in regional languages. It does not touch the underwriting decision; it makes the decision easier to understand.
What still does not pass
Autonomous underwriting decisions, fully ML-driven pricing, and "AI-detected fraud" labels that arrive without an explanation. Explainability expectations and regulator scrutiny mean these scopes need to be human-supervised at minimum and, in most cases, human-decided. In the EU, the AI Act lists AI used for risk assessment and pricing of individuals in life and health insurance as high-risk, with obligations covering risk management, data governance, record-keeping and human oversight. Do not scope autonomous decisions yet.
Preparing for the actuarial review
Bring a short pack that answers the questions actuaries will ask anyway:
- Scope: exactly which decision the model informs, and which it does not.
- Data: sources, time period, the policy population it represents and known gaps.
- Features: the full list, with a rationale for each and a check for proxies of protected attributes.
- Validation: performance on a held-out period, broken down by segment and compared with the current process.
- Controls: version locking, override logging, monitoring and the process for changing the model.
The version-locking discipline
An underwriting model is locked at a version, validated, then deployed. Changing it requires actuarial sign-off, not just a deploy. Instrument every prediction with the model version, the prompt template version and the retrieval corpus version. When someone asks why a particular policy was flagged on 12 April, you should be able to reproduce exactly that output.
Audit trail as a first-class feature
For every model output that feeds an underwriting decision, log the input features, the model output, the underwriter's acceptance or override, and a reason code. This is what you will want in front of you in a regulatory examination or an internal audit, and it is the raw material for the next iteration of the model. Override patterns are especially useful: if underwriters reject one type of flag most of the time, that flag needs rework. Insurers operating in India should map these controls to current requirements from IRDAI, which publishes its regulations and circulars online.
Multilingual customer communication is underrated
Insurance is a category where customer understanding drives complaints. Explanations of policy terms in Hindi, Tamil, Bengali and other languages, drafted by AI, vetted by compliance and served at issuance, address a common cause of disputes. Track complaint themes and early lapses before and after launch so you can show the effect on your own book. It is easy to ship and hard to argue against.
Common mistakes
- Pitching accuracy numbers before explaining what the model is allowed to decide.
- Asking an LLM to produce a risk score directly, rather than to extract and summarise evidence.
- Letting prompts change in production without the same controls as model changes.
- Treating the audit log as a later phase.
FAQ
Can we use a general-purpose LLM to extract data from medical reports?
Often, yes, provided the deployment meets your data protection and residency requirements, outputs are validated against a schema, and low-confidence fields go to a person. Measure field-level accuracy on your own documents before rollout, and keep measuring after it.
Who should own the model once it is live?
Underwriting should have a named business owner, with actuarial sign-off on changes and engineering responsible for monitoring. Shared ownership without a named owner is how drift goes unnoticed.
Where should a first project start?
With document extraction on one product line. It delivers visible time savings, leaves decisions untouched and builds the logging and versioning habits every later use case will need.
How we approach this at Velura Labs
Our custom LLM applications work in InsurTech focuses on the assistive, not decisional, surfaces above, with version locking and audit trails built in. Read our guardrails playbook for the broader regulated-industry pattern, and talk to us before pitching your actuarial team; we can review the architecture with you so the meeting does not end the project.
Our clients for this span US tech hubs (San Francisco, Seattle, Austin, New York), European markets (Paris, Milan, Rome), the Middle East (Dubai, Riyadh, Abu Dhabi) and India. Start a conversation from anywhere.