FCA authorised · FRN 724952 0117 325 0027Quote & buy →
Apex Insurance Brokers
Speak to a brokerGet a quote →

Aipedia: Actuaries

LLM-written code and spreadsheets for actuaries

Actuaries can use AI assistants to write and convert code, but generated code is part of the model and must be understood, tested and documented like any other. The danger is a calculation error that runs without complaint and spreads into every result.

In short

Actuaries may ask a generative AI chatbot or coding assistant to write Python, R, SQL or VBA, to translate old spreadsheets, or to explain unfamiliar code. The FRC Models guidance brings open-source and third-party code into scope and asks for code to be documented, and the IFoA guide urges care with third-party generative AI tools. Generated code often looks right and runs, which is the problem: errors in discounting, joins or missing-data handling can go unnoticed. Model-error claims usually fall within actuarial PI, subject to the policy terms, but repeated use of one flawed routine can create aggregation questions.

How actuaries use AI to write code

Coding is among the uses of generative AI in actuarial teams. The Lloyd's Market Association's discussion paper lists coding among actuarial AI uses. Typical tasks include writing data-cleaning scripts, converting a legacy spreadsheet into Python or R, producing VBA macros, writing SQL to extract data, generating unit tests and commenting existing code.

Used well, an assistant speeds up routine work and can make code more readable. Used badly, it introduces code that nobody in the team fully understands, written in a style that does not match house standards, with assumptions buried in it. Generated code is also non-deterministic: asking the same question twice can produce different code. That makes it important to save the version actually used, rather than relying on being able to regenerate it. Spreadsheets carry similar risks: an assistant can suggest formulas or macros that work on the example in front of it but break when a row is added or a range changes, and spreadsheet errors are notoriously hard to spot once a workbook is in regular use.

The duties that apply

Pasting client data or proprietary code into an unapproved tool raises confidentiality issues; see actuaries, AI and client data confidentiality.

What can go wrong

Illustrative scenario: an analyst asks an AI assistant to convert a cash flow spreadsheet into Python. The code runs and totals reconcile on the test case. But the generated routine treats missing values as zero when joining two data sets, and uses a slightly different timing convention for discounting. Neither shows up in the test case. Results for several clients are produced with the new code before a reviewer spots a discrepancy months later.

Other risks: a library function the assistant invented or misused, code licensed on terms that conflict with the firm's use, and spreadsheet formulas that overwrite rather than reference inputs. Errors like these rarely announce themselves, which is why review matters; see AI in peer review under APS X2.

How PI usually responds

A claim that a coding error caused a client loss is a model-error claim that would usually fall within actuarial PI, subject to the policy terms. Where the same flawed routine is used across many clients or reports, the policy's aggregation clause decides whether the claims are treated as one or several, affecting limits and excesses. Copyright or licence disputes over generated code are a different risk, and policies vary on intellectual property cover; see AI-generated content and IP infringement. Insurers may ask how firms control AI use; see what to document about AI use.

Practical controls

How Apex helps

Apex arranges PI for actuaries and actuarial consultancies; a broker can review how your policy handles model-error claims and aggregation. See the AI in actuarial work overview and whether PI covers AI mistakes.

Sources

Frequently asked

Can I use an AI assistant to write actuarial code?

Yes, as long as you understand, test and document the result. The code becomes part of your model, so TAS 100 Principle 5 applies to it. The IFoA guide also asks for care with third-party generative AI tools, particularly on accuracy, privacy and copyright.

Do I need to record that code was AI-generated?

No rule specifically says so, but the FRC Models guidance asks for open-source code to be documented and for additional governance around AI. Recording where AI was used helps reviewers focus their checks and helps you explain the work if it is challenged.

What if one coding error affects many clients?

That is mainly an aggregation question. Depending on the wording, related claims may be treated as one claim subject to one limit and one excess, or as separate claims. A broker can explain how your policy's aggregation clause would apply.

Check your PI covers how you use AI

Tell us about your firm and the work you do. A broker will review how your current PI treats AI-assisted work, or arrange new cover. No fee for a quote. Or call 0117 325 0027.

Start a PI quote Request a callback

Apex Insurance Brokers Limited is authorised and regulated by the Financial Conduct Authority. Registered in England and Wales, company number 07014570. This page is general information about how AI is used in the profession and how insurance may respond. It is not legal, regulatory or insurance advice on your circumstances, and it does not guarantee that cover will be available or on what terms.