Operations
Large language model (LLM)
Also called: LLM, foundation model
Definition
A large language model is a statistical system trained on vast text that predicts the most plausible continuation of an input, which is why it is fluent by construction and correct only by supervision.
An LLM does not look facts up and does not know when it is wrong. It produces the most likely next piece of text given everything it has seen, which makes it extraordinary at language work and unreliable as a source of truth. Every dependable deployment supplies the truth from somewhere else and uses the model for judgment, phrasing, and structure, rather than trusting its internal recall of facts it was never designed to store reliably.
Fluency is not accuracy
The same mechanism that produces a clean, confident paragraph also produces a clean, confident wrong paragraph, with no detectable difference in tone or certainty between the two. There is no internal signal that distinguishes them, so confidence in the output tells you nothing about its correctness, no matter how authoritative the phrasing sounds to a reader. Controls have to live outside the model — in retrieval, in validation, in human review — because the model itself will never flag its own error for you.
What it is genuinely good at
Reading unstructured documents, normalising messy inputs, drafting, summarising, classifying, and following a stated procedure are all tasks where an LLM performs remarkably well, often at a level that would have required a specialized system a few years ago. These are the bulk of operational work in insurance and financial services, which is why the technology matters even with its limits fully priced in — the majority of the value in a well-run deployment comes from these language tasks, not from the model acting as a database of facts.
Version changes are invisible by default
Providers update the models behind an API regularly, and unless a deployment pins a specific version and monitors for changes, the system running today may not be the one that was evaluated at launch. This matters because behavior can shift in subtle ways with a version update — phrasing, refusal patterns, edge-case handling — without any announcement reaching the team that built on top of it. Treating the underlying model as a stable component rather than a monitored dependency is one of the most common oversights in production AI deployments.
In practice
- Give the model the facts rather than trusting it to recall them
- Judge outputs against a frozen case set, not against how good they sound
- Assume the model version underneath you can change without notice
- Pin and monitor the specific model version your workflow depends on where possible
