The support ticket comes in on a Tuesday. A user got a confident, well-formatted answer from your AI assistant — complete with a citation to a policy document that doesn't exist. Your error rate dashboard shows green. Latency is fine. The model returned a 200. Nothing in your infrastructure monitoring flagged anything, because nothing in your infrastructure monitoring could flag this.
That's the core problem with hallucinations in production: they succeed. The model always produces something, and that something is often fluent and wrong. As Confident AI's failure taxonomy puts it, "a hallucinated answer, a wrong tool call, and an ignored escalation request can all complete without errors." Status-code monitoring is structurally blind to semantic failures.
The teams that handle this well have figured out that hallucination detection isn't one problem — it's three distinct jobs running at different points in the system lifecycle. Conflating them is how you end up with a detection strategy that looks comprehensive on paper and misses the failures that actually reach users.
Pre-Deployment Checks Catch the Predictable Failures
Before any prompt touches production traffic, you should be running deterministic checks against known hallucination patterns. Schema validation, format enforcement, required-field presence — these are cheap, fast, and catch a class of failures that don't require any semantic reasoning to detect.
Beyond deterministic checks, Openlayer's production detection guide describes a layered pre-deployment approach: LLM-as-judge scoring with roughly 81% human correlation for faithfulness, and semantic entropy signals across repeated generations. The key insight is that these evaluations run against your specific documents and domain rules, not generic benchmarks. A model that scores well on public hallucination leaderboards can still fabricate citations in your domain if you haven't tested against your actual retrieval corpus.
For RAG pipelines specifically, Giskard's detection framework makes a distinction most teams miss: you need to check that retrieval ran before you check whether the answer is grounded in what was retrieved. An LLM judge can score an answer as "grounded" while the retrieval trace is empty. Invented citations pass judges surprisingly often when nobody inspects the sources or tool_calls fields. The discipline is: deterministic retrieval checks first, groundedness scoring second.
Production Monitoring Catches the Distributional Failures
Here's what pre-deployment testing won't catch: the model update your provider shipped last Thursday that quietly degraded faithfulness on one use case while everything else held. Or the prompt edit someone pushed that shifted output quality in a specific conversation type. Or the index refresh that changed what your retriever returns.
Confident AI's framework calls this out directly — quality degrades a use case at a time, and aggregate metrics hide localized regressions until users complain. The system changes under you without any deploy on your side.
What this requires is continuous groundedness and faithfulness scoring against live traffic, tagged by feature, conversation type, and user segment. Datadog's AI agent observability approach frames this as end-to-end trace analysis plus guardrail signals — not just model latency and error rates. You need to see the full decision path: which tools were called, what was retrieved, what the model did with it.
The operational reality is that you're looking for distributional drift, not individual bad outputs. A single hallucinated response is a support ticket. A 3% shift in groundedness scores across refund-related conversations is a regression that's costing you money and trust before anyone files a ticket.
Runtime Blocking Is the Last Line, Not the Only Line
Runtime guardrails — blocking responses when groundedness falls below threshold — are where most teams start and stop. They're visible, they feel like control, and they're genuinely useful. Openlayer recommends configuring blocking thresholds around 85% for high-stakes domains.
But runtime blocking alone is expensive and brittle. Every blocked response is a failed user interaction. If your block rate is high, you have a detection problem masquerading as a guardrail problem — the real issue is upstream, in retrieval quality or prompt design, and you're paying per-inference to discover that at the worst possible moment.
Honeycomb's agent observability framing is useful here: surface loops, retries, and runaway agents the moment they start, so a quality regression never makes it to a customer. That's the right mental model for runtime guardrails — they're a circuit breaker, not a quality assurance strategy.
The teams that have this working well treat runtime blocking as the signal that something earlier in the pipeline needs fixing, not as the fix itself. A spike in blocked responses triggers an investigation into retrieval quality and prompt groundedness, not just a threshold adjustment.
The practical checklist: deterministic schema checks and retrieval verification before generation, LLM-as-judge faithfulness scoring in CI against your actual corpus, continuous groundedness monitoring tagged by feature and conversation type in production, and runtime blocking configured as a circuit breaker with alerting that routes to the right upstream fix. Each layer catches what the others miss. Running only one of them and calling it a hallucination strategy is how you end up with a green dashboard and a user who just got a citation to a document that doesn't exist.
