Ask five AI vendors what they sell and you will hear the same words in different orders: evals, testing, observability, monitoring. Ask a compliance officer at an insurance carrier what they need and you will hear something none of those vendors quite said: a defensible answer to whether the AI is ready, and proof that it stays that way.
The confusion is not the buyer's fault. These four practices share machinery, and the tooling market has blurred them for years. But they are separable, and separating them is the fastest way to figure out what your organization actually has, what it is missing, and what an examiner or internal auditor will ask for.
The cleanest way to tell them apart is by the question each one answers.
| Evals | Testing / Validation | Observability | Production Monitoring | |
|---|---|---|---|---|
| Question answered | Is version B better than version A? | Is this system safe to turn on, and can I prove it? | What is the system doing right now? | Is it still behaving the way it did when we approved it? |
| When it runs | During development, on every change | At release events: before deployment, after vendor updates, after prompt changes, at periodic revalidation | Always on, passive | Always on, active, on a schedule |
| What gets processed | Curated test datasets | Curated test cases scored against defined rubrics, with criteria locked before the run | Raw production traffic: traces, tokens, latency, cost | Sampled production traffic, scored and compared against a baseline |
| What it produces | Score deltas and pass/fail per metric | A governed verdict plus an evidence document | Dashboards and logs. Descriptive, with no opinion on whether behavior is good | Drift signals, alerts, and incident records when behavior shifts |
| Rigor around the judge | An engineer tunes criteria until output looks right | The judge is calibrated against human expert scores before any result counts; uncertain cases go to human review | No judge involved | Judge required; the same calibration question applies |
| Primary user | Developer or ML engineer | Testing teams, engineering leaders, product owners, and the compliance function that signs off | Platform engineer debugging issues | Risk, compliance, and the operational owner of the AI system |
| Failure it catches | "My change made it worse" | "This system is not ready," or "we cannot prove it is ready" | "Latency spiked, cost doubled, this trace errored" | "It was fine at launch and has quietly degraded since" |
Evals and testing look identical until someone hostile asks a question
Mechanically, an eval and a test are the same loop: feed the system an input, capture the output, have a judge score it against criteria. The open source ecosystem for this is genuinely good, and engineering teams use these frameworks to catch regressions on every code change the same way unit tests catch broken logic.
The difference is everything wrapped around the loop. Who wrote the criteria, and would a domain expert endorse them? Were the pass thresholds fixed before anyone saw results, or adjusted afterward until the numbers looked acceptable? Was the judge itself ever validated against human judgment, or is an unexamined model grading another model? Can a person who does not read code review what happened and stand behind the conclusion?
An eval becomes a test the moment its result can survive someone hostile asking: why should I believe this? For a developer shipping a feature, that bar is unnecessary. For an organization about to let an LLM touch claims, credit, or coverage decisions, that bar is the entire point. This is why a team can be running hundreds of evals in their build pipeline and still, accurately, tell their risk committee that the system has never been tested.
Every serious review of LLM-scored testing arrives at the same objection: why should anyone trust a language model grading another language model? There is only one defensible answer, and it is procedural. Calibrate the judge against human expert scores on a sample before its ratings count, measure the agreement, surface the cases where the judge is uncertain, and route those to a human. A score with that provenance is evidence. A score without it is an opinion with extra steps.
Observability tells you what happened. It has no opinion about whether it was right.
Observability platforms capture what your AI system actually did: every trace, every prompt and response, token counts, latency, cost per call. When something breaks at 2 AM, this is how an engineer finds the failing component. It is necessary infrastructure, and the tools that provide it are mature.
But observability is descriptive by design. It can tell you the model returned a response in 800 milliseconds for a fraction of a cent. It cannot tell you the response misclassified a total-loss claim as routine. Judging correctness requires criteria, a judge, and a baseline, none of which live in a tracing tool. Vendors sometimes label alerting on latency or cost as monitoring, which is true for infrastructure and misleading for behavior. If the alert cannot fire because the answers got worse, it is not behavioral monitoring.
Production monitoring asks the question that testing answered, forever
A validation run passing in March says nothing about August. Foundation model providers update models without notice. Prompts get tweaked. Production inputs drift away from the test set. The system that was approved is, gradually and silently, replaced by a system nobody approved.
Behavioral monitoring closes that gap: sample real production behavior on a schedule, score it with the same calibrated judgment used at validation, and compare against a baseline with statistical drift detection so that slow degradation triggers an alert instead of a customer complaint. The distinguishing feature against observability is that monitoring has an opinion. It knows what correct looked like, because someone defined it, and it notices when reality moves away from it.
The four form a lifecycle, and the handoffs are where organizations fail
Run the practices in order and they form the lifecycle of a responsibly deployed AI system. Evals during development keep the build honest. Testing at the gate produces the sign-off decision and the evidence behind it. Observability and monitoring take over in production, one watching the infrastructure, the other watching the behavior.
The failures we see are almost never inside a box. They are at the handoffs. A team runs evals but never graduates them into governed testing, so deployment happens on engineering's self-assessment. Or a system passes validation and goes live with no behavioral monitoring, so the approval decays silently. The most valuable handoff is also the least practiced: the validation run that earned the sign-off is the natural baseline for production monitoring. Monitoring then asks a precise question with a documented answer: is production behavior still consistent with what we approved? Very few organizations can construct that sentence today, because it requires the testing evidence and the monitoring infrastructure to share criteria, and in most stacks they do not even share a vendor.
What regulated teams should take from this
If you are deciding whether an LLM is ready for a regulated process, ask which of the four questions each tool in front of you actually answers. Your engineers likely have evals and may have observability; both are worth keeping. What determines whether deployment is defensible is the other pair: a testing practice rigorous enough that its verdict survives scrutiny, and a monitoring practice that notices when the approved behavior stops. Regulators are converging on the same pairing. The NAIC Model Bulletin expects insurers to validate and test AI systems for errors, bias, and unfair discrimination, and to keep governing them after deployment; the examination frameworks now entering use ask for evidence of both. For the details on what that guidance requires, see our breakdown of the NAIC AI bulletin, and for the wider category, what AI behavioral assurance means.
Frequently asked questions
What is the difference between LLM evals and LLM testing?
Mechanically they run the same loop: feed the system inputs, capture outputs, score them against criteria. The difference is governance. Evals are a development practice where an engineer tunes criteria to catch regressions. Testing, or validation, wraps that loop in controls that make the result defensible: criteria written with domain experts, pass thresholds locked before the run, a scoring judge calibrated against human judgment, and an evidence document a non-engineer can review. An eval answers whether a change made the system better. A test answers whether the system is safe to turn on and whether you can prove it.
Is AI observability the same as AI monitoring?
No. Observability captures what an AI system did: traces, prompts, responses, latency, token counts, and cost. It is descriptive and has no opinion on whether an output was correct. Behavioral monitoring samples production outputs on a schedule, scores them with calibrated judgment, and compares the results against an approved baseline so that degrading answers trigger an alert. If a tool cannot alert because the answers got worse, it is observability, not behavioral monitoring.
Why should anyone trust an LLM judging another LLM?
Only because of procedure, never by default. A defensible setup calibrates the judge against human expert scores on a sample before any result counts, measures and documents the agreement, and routes cases where the judge is uncertain to a human reviewer instead of counting them silently. A score with that provenance is evidence. A score without it is an opinion with extra steps.
Do we need both evals and validation before deploying an LLM?
They serve different decisions, so mature teams keep both. Evals run during development on every change and keep the build honest. Validation runs at release events: before go-live, after a vendor model update, after prompt changes, and at periodic revalidation. A team can run hundreds of evals in its pipeline and still be unable to show a risk committee that the system was ever tested, because evals lack locked criteria, judge calibration, and reviewable evidence.
What evidence do regulators expect before an AI system goes live in insurance?
The NAIC Model Bulletin, adopted in over half of US states, expects insurers to validate and test AI systems for errors, bias, and unfair discrimination, and to keep governing them after deployment. In practice that means documented test criteria that were fixed before the run, results showing the system met them, evidence that automated scoring was checked against human judgment, records of how uncertain cases were resolved, and ongoing monitoring showing behavior stayed consistent with what was approved. The examination frameworks now entering use ask for evidence of both the pre-deployment testing and the post-deployment monitoring.
How often should an LLM system be revalidated?
At every event that can change behavior: a provider model update, a prompt or configuration change, a vendor switch, or a material shift in production inputs. Between events, periodic revalidation on a fixed schedule catches slow drift, and continuous behavioral monitoring closes the gap between scheduled runs. The validation run that earned sign-off should become the monitoring baseline, so revalidation and monitoring answer the same question with the same criteria.
Testing an LLM for a regulated process today?
AnchorDrift provides guided pre-deployment validation and continuous behavioral monitoring for AI systems in regulated industries. Rubrics, test cases, and judge calibration are tuned to your specific use case with your experts.
Book a Discovery Call