Start · Orientation · Everyone · ~15 min
Insurance runs on unstructured information: submissions, loss runs, policy wording, claims files, and broker correspondence. Large language models can read and structure that material at scale. Start with the two mental models below, or choose the category that matches your role.
What this technology is, in brief
Large language models (LLMs), the technology behind ChatGPT, Claude, and Gemini, are software systems trained on enormous volumes of text that can read, summarize, draft, extract, classify, and reason over language. Think of them as an extremely fast, extremely well-read junior analyst: broad knowledge, strong language skills, tireless, but one who occasionally states wrong things with complete confidence, and whose work always needs review before it leaves the building.
They are not databases, search engines, or calculators. An LLM does not "look up" answers; it generates them. That is why it can draft a coverage summary in seconds, and also why it can invent a plausible-sounding policy exclusion that doesn't exist. This failure mode is called hallucination, and managing it is the central discipline of using LLMs well.
Two mental models to carry through everything
Context in, quality out. An LLM answers from what it absorbed in training (general knowledge; nothing about your company, nothing recent) and from whatever is in front of it during the conversation. Almost every disappointing answer traces back to not giving the model enough to work with.
That second part is no longer only what you paste. Connected to tools, through the Model Context Protocol (MCP) or a provider's own browsing and search, a model can look something up while it works: read a live web page, pull a filing, query a database, call an internal system, then reason over what it found. The training cutoff stops being a hard boundary on what it can know. It does not stop being your problem: retrieved material is still context, it can still be wrong, out of date, or deliberately hostile, and a claim the model fetched needs the same check as a claim it remembered.
A bright junior colleague on their first day. Capable, fast, well-read, but they don't know your account, your appetite, or your standards until you tell them, and you review their work before it goes anywhere. This one rule resolves most questions about appropriate use.
Context in, quality out
A model answers from three sources, and you decide what goes into two of them. Supplying them is a craft with its own ladder: the same question answered from a pasted document and from a versioned skill are not the same question.
Levels of context engineering
Each level costs more to build and reaches further. Which one a task deserves depends on how often it recurs and how much the answer matters, not on how advanced you want to look.
-
1
Paste it in The submission or the wording, dropped into the conversation. Reach: one question, one person, once.
-
2
Structure it A reusable prompt carrying the format, a worked example, and the standard the output must meet. Reach: the same task, repeatably, across a team.
-
3
Retrieve it RAG over your guidelines and appetite guides, or a connected tool that fetches from outside them, so the answer is drawn from a named source and cites it. Reach: answers that stay current as the guidelines change, and are checkable.
-
4
Package it A versioned skill: the procedure, its scripts, and its checks, loaded only when the task calls for them. Reach: an organizational procedure that can be tested, corrected once, and reused everywhere.
The fourth level is where a model stops starting from scratch. A model has no memory of yesterday, but the skill does: it is a file, so a correction made after one bad output becomes the instruction every later run reads. Catch a habit of quoting the wrong endorsement form, write the rule into the skill, and the mistake does not recur. Do that for a year and the procedure is better than the one you started with, and better in a way you can read, diff, and roll back. This is how an agent improves at your work: not by the model learning about your company, but by the procedure around it accumulating what your people know.
Practice · Concepts · Everyone · ~10 min
The terms you'll hear and an honest account of model strengths and weaknesses.
Terminology, one line each
| Term | Plain-English meaning |
|---|---|
| LLM / foundation model | A general-purpose AI model trained on vast text; the "engine" (e.g., GPT, Claude, Gemini) |
| Generative AI | AI that creates content (text, images, code) rather than just scoring or classifying |
| Prompt | The instruction you give the model; prompt quality drives output quality |
| Hallucination | Confident, fluent output that is factually wrong or fabricated |
| Context window | How much material the model can "hold in mind" at once (now: entire claim files or policy forms) |
| RAG | Retrieval-augmented generation: connecting the model to your documents so answers cite your guidelines and forms. The main technique for grounding output in fact |
| Fine-tuning | Additional training on your own data to specialize a model; less common than RAG in practice |
| Agent | A system that uses a model and tools to complete a multi-step job, rather than answer once |
| Agentic | A workflow pattern in which an agent plans, acts, observes results, and continues within defined boundaries |
| Tool use | Letting the model call something outside itself while it works: a web search, a database, a script, an internal system |
| MCP | Model Context Protocol: the open standard for connecting a model to those tools and data sources, so the same connector works across products |
| Context engineering | Designing what the system sees: instructions, source material, examples, state, and retrieved evidence |
| Skill | A packaged, versioned procedure the model loads when a task calls for it: the steps, the scripts they run, and the checks that must pass |
| Human-in-the-loop | A named person approves consequential output or reviews exceptions surfaced by the harness |
| Guardrails | Technical and policy controls that constrain what the AI can see, say, and do |
| Token | The unit models read and produce (~¾ of a word); usage is billed per token |
| Machine learning | The broader field; existing pricing models are ML but not generative AI. Governance for both is converging |
How retrieval grounds an answer in your documents
RAG is the main technique for making a model answer from your guidelines rather than from its training. The retrieval step is the whole difference.
Without step 2 the model answers from general training, which is where invented exclusions come from. With it, a wrong answer is traceable to a document you can fix.
What it does well, and where it fails
Five strengths, five failure modes, and which failures are fixable
The failures are not all the same kind, and treating them as one list is why programmes over-invest in the wrong controls. Two can be removed from the step entirely. The other three can be caught far more often than they can be prevented, and that residual is what a named approver is for.
Good at
- Reading and summarizing large volumes of documents
- Drafting, where the model produces the first version and a person produces the final one
- Extracting structured data from unstructured text
- Explaining, translating, and reformatting information
- Writing and reviewing code
Fails at
- They do not reliably do arithmeticUnaided, a model guesses at a calculation with the same confidence it uses for prose. Engineer it out
- They are non-deterministicThe same question can return a slightly different answer, which is what makes reproducibility and audit hard. Engineer it out
- They fabricateFluency is not accuracy, and a wrong answer looks exactly like a right one. Grounded retrieval, forced citations, schema validation, and a checking hook that verifies each claim against its source turn most invented content into a failed check rather than a delivered document. Engineer it down
- They can be manipulatedPrompt injection: instructions hidden in a document the model reads, written to be obeyed rather than summarized. Least-privilege tools and separating instructions from untrusted content limit what a successful injection can reach. Engineer it down
- They reflect training-data biasA direct concern under unfair-discrimination law. Outcomes testing measures it on your own book and makes it reviewable, which is what regulators ask for; it does not remove it. Engineer it down
The tags split on what is left over, not on how much work is involved. Engineer it out means the failure stops existing for that step. Engineer it down means a control catches most instances before a person sees them, and nothing certifies absence, which is why a named person still approves consequential output.
What the engineering actually is
The first two fixes are the same move: stop asking the model to be the part of the process that has a right answer.
- Arithmetic and data manipulation belong in code. Given a tool, the model writes and runs the calculation instead of guessing at it. The number then comes from a script you can rerun and inspect, and the model's job shrinks to deciding what to compute and reading the result.
- Non-determinism is bounded by fixing the procedure, not the wording. Package the task as a versioned skill: the steps, the scripts they call, the schema the output must satisfy, and the checks that must pass before anyone sees it. The steps that must be identical every time are executed deterministically; the model supplies judgment in the places that genuinely need it, and a failing check stops the run rather than producing a quietly different answer.
The other three work differently: you cannot remove them, so you make them detectable and you bound what they can reach. Fabrication is the clearest case. Ground the answer in retrieved passages and require it to cite them; validate the output against a schema so a malformed answer fails rather than ships; run a checking step whose only job is to hold each claim against its source; gate releases on an eval set with known answers so a regression shows up before a reader does. Hooks like these are why a governed pipeline is not the same product as the same model in a chat window, and they change the arithmetic of review: a person checking exceptions is doing a different job from a person re-reading everything.
What they do not do is certify absence. A check catches what it was written to catch, so the residual is real and it is why accountability stays with a named person rather than with the pipeline. Treat the difference between a 5% error rate and a 0.5% one as worth engineering for, and the difference between 0.5% and zero as something to govern instead.
This is what the context ladder above is for. Level 4 is not a more advanced way to chat; it is the point at which a task stops varying, because the parts that must not vary have been moved out of the model and into code that runs the same way twice.
Where things stand right now
Capability, adoption, and regulation are not moving at the same speed, and confusing them is the most common planning error. Frontier models can already do far more than most insurers have absorbed; the binding constraint is organizational rather than technical. Meanwhile the supervisory framework has moved from consultation to expectation, so a programme started today inherits obligations that did not exist two years ago.
The timeline plots all three on one scale, marks where August 2026 falls, and separates documented events from clearly labelled estimates. Read it before the integration phases: it is what makes the sequencing argument legible.
Choose a category
Three routes through the rest of the site. Strategy decides whether and in what order; Practice covers doing the work; Sources lets you check any of it.
Strategy
Start with where the technology stands, then the insurance opportunity, investment, sequencing, capability progression, economics, and governance.
Timeline · AI in insurance · Specialty & E&S · integration phases · Capability ladders · Costs & value · Governance
Practice
Write prompts that work, run agents safely, and go as deep as the actuarial work requires.
Sources
Inspect evidence, methodology, ownership, and further reading.
Evidence · How it’s built · About · Resources