Why insurance pricing models should be human readable, especially when AI writes them
As AI drafts more insurance pricing logic, the format of the model becomes a control. This article explains why declarative, readable pricing models are faster to review and audit than generated code.
When AI writes a pricing model, the speed of writing matters less than how quickly a person can check the result. That makes the format of the model a governance decision as well as a technical one.
Two ways for AI to build a pricing model
Generating code. An AI can write the rater in a general-purpose programming language. This is flexible and quick, but the result is a program with control flow, helper functions and edge-case handling. Reviewing it takes an engineer, and confirming it matches the rating guide takes an engineer who also understands the rating guide.
Generating configuration. An AI can instead write the model in a constrained, declarative format: inputs with types and descriptions, rate tables as rows, calculations as formulas and underwriting rules as named conditions. This is deliberately less flexible, and much easier to review.
What a readable model looks like
A readable pricing model has:
- Named inputs with plain-English descriptions, for example "Annual vet-fee limit: the maximum the policy pays each year".
- Rate tables stored as tables, with rows and columns that can be compared line by line with the source document.
- Formulas that match the rating guide, such as
round(base_premium × age_factor × region_factor, 2). - Named rules, for example "Decline: pet older than 14 at inception".
- Tests stored with the model, made up of the actuary's worked examples and their expected results.
An underwriter or actuary can review this without reading code, and an auditor can follow it. An AI agent can also read and edit it accurately, because the structure shows where everything is.
Why constraints help AI
It might seem that more flexibility would make AI more capable. For pricing, the reverse is usually true. A constrained format gives an AI:
- A schema to validate against, so structural mistakes are caught straight away rather than when quotes are being priced.
- A small set of step types, such as lookup, calculate, exclude and refer, which match the way rating guides are written.
- Precise places to edit, so a change such as "update the London region factor" affects one cell rather than a function.
- Quick feedback, because tests can run after every edit.
A clear audit trail
Because a declarative model is data, every version can be stored, compared and reproduced. A question such as "what changed between version 26 and version 27?" can be answered by comparing two files. Combined with per-quote debug traces, this shows which rules and values produced any price on any date.
When configuration is not enough
Some products need logic that does not fit a declarative step, such as a call to an external data source or an unusual aggregation. A good rating engine allows this as a clearly marked exception. If most of the model is readable and a small, well-tested part is not, reviewers can focus on the part that needs the most attention.
Summary
AI can now write pricing logic faster than people can review it, so review has become the slower step. A model format that people can read and that AI can edit accurately keeps both speed and confidence.
Every Ptally model is built this way. A full worked example is on our model building page.