Language models hallucinate. Every model, every provider, every parameter count. The question facing a Geschäftsführer is not whether your AI system will produce a confident, well-formatted, completely wrong answer — it will — but how often, in which workflows, and whether anyone catches it before it reaches a customer, a regulator, or the board.
This is the single most misunderstood risk in enterprise AI. Vendors quote a benchmark number, a pilot looks clean, and the system ships. Then it meets real inputs. Understanding what the research genuinely supports — and, just as importantly, what it does not — is the difference between deploying AI you can defend and deploying a liability you have not yet noticed.
What the evidence actually shows
The most disciplined public measurement of hallucination is Vectara's Hallucination Leaderboard. It does not ask models open-ended questions; it gives each model a source document and asks for a faithful summary, then scores how often the output introduces claims the source does not support. This is the friendliest possible test — the answer is sitting right there in the prompt — and it is the closest analogue to a well-built retrieval system.
Even on that generous task, the results are sobering. The leaderboard now spans well over a hundred models against a refreshed corpus of more than 7,700 documents, some running to tens of thousands of tokens. The best-performing frontier models keep faithfulness errors to a low single-digit percentage. Many widely deployed models, including some of the most capable reasoning models on the market, sit closer to ten percent. The headline you should take away is not a specific number for a specific model — those shift with every release — but the shape of the finding: when the correct answer is handed to the model verbatim, strong systems still fabricate a few percent of the time, and many do considerably worse.
Move from summarisation to a real knowledge task and the picture hardens. Stanford's RegLab and Human-Centered AI institute tested the leading retrieval-augmented legal research tools — purpose-built, retrieval-grounded products from LexisNexis and Thomson Reuters, marketed as hallucination-resistant. They hallucinated on roughly 17 to 33 percent of queries. General-purpose chatbots, asked the same kind of specific legal questions, were wrong far more often. The study's lasting contribution was puncturing the marketing: retrieval grounding measurably reduces hallucination, but vendor claims of "hallucination-free" output did not survive contact with an independent benchmark.
Two conclusions follow, and they should govern every deployment decision. First, grounding works — connecting a model to authoritative sources is the highest-leverage intervention available. Second, grounding is not a cure — even the best retrieval architecture leaves a residual error rate that, in high-stakes domains, is large enough to matter.
The arithmetic of "good enough"
A residual error rate that sounds trivial in a demo behaves differently at volume. The instinct of most leadership teams is to treat a low single-digit error rate as a rounding error. It is not, because the number you care about is not the percentage — it is the count, and the cost of each miss.
A contract-review assistant that processes several hundred documents a month at even a low single-digit error rate will, by simple arithmetic, surface a handful of materially wrong analyses every month. Whether that is acceptable depends entirely on what happens next. If a lawyer reads every output anyway, the assistant is a drafting aid and the error rate is a productivity question. If the output flows unread into a negotiation or a filing, the same error rate is an uninsured exposure. The model's accuracy did not change between those two scenarios. The architecture around it did.
This is the reframe that matters for the Mittelstand: hallucination is not primarily a model-selection problem. It is a workflow-design problem. The right question is never "which model hallucinates least" — though that matters at the margin — but "where in this process does an unverified machine claim become a decision, and what stands between the two."
Building the verification layer
A practical mitigation architecture has three layers, and their order is deliberate. Each one is cheaper and more effective the more work the layer beneath it has already done.
Ground everything in your own sources. No enterprise workflow of consequence should rely on a model's parametric memory. Connect the model to your contracts, your product documentation, your policies, your records, and require it to answer only from retrieved material and to cite what it used. This is the minimum viable architecture, not an optimisation. The Vectara and Stanford evidence both point the same way: grounding is what moves you from unusable to usable. It is also what makes the next two layers possible, because verification requires a source to verify against.
Automate the checks you can. Once outputs carry citations, much verification becomes mechanical. Confirm that cited documents exist and that quoted passages actually appear in them. Flag answers where the model's own confidence is low or where retrieval returned weak matches. Use a second model to check the first against its sources for the cases that warrant the extra cost — a pattern that catches a meaningful share of what slips through, though it is no substitute for the final layer. These checks are not free; they add latency and inference cost. Spend them where a wrong answer is expensive, not uniformly.
Reserve humans for the decisions that deserve them. For outputs with material consequence — legal positions, financial figures, compliance determinations, anything that reaches a customer or a regulator — human review remains non-negotiable. The discipline is to make that review fast rather than redundant. Surface the source documents next to the generated claim, highlight the low-confidence passages, and design the interface so a reviewer verifies in seconds rather than re-doing the work the system was meant to save. A review process that duplicates the original labour defeats the purpose; one that focuses human judgement exactly where the machine is least certain is where the productivity actually lives.
Why this is now a compliance question
For DACH enterprises in financial services, healthcare, energy, and manufacturing, this stopped being a purely technical conversation. From 2 August 2026, the EU AI Act's obligations for high-risk systems apply. Article 15 requires high-risk AI systems to achieve an appropriate level of accuracy and robustness and to declare their accuracy metrics in the instructions for use — you will have to state, in writing, how well your system performs and how it handles error. Article 14 requires effective human oversight: systems must be designed so a competent person can understand their limitations, recognise automation bias, interpret outputs correctly, and override them. The three-layer architecture above is, in substance, what these articles ask for.
The GDPR adds a second axis. The accuracy principle in Article 5(1)(d) requires that personal data be accurate and kept up to date, with reasonable steps taken to rectify what is wrong. A hallucination-prone system that generates or acts on incorrect personal data is not merely producing a bad answer — it is creating a data-protection exposure with its own enforcement regime behind it.
None of this is an argument against AI. It is an argument against deploying AI as if the model's output were the finished product. The organisations that will scale AI across regulated processes are the ones that treat verification as core infrastructure from the first pilot — not as a remediation project after the first incident. The architecture that satisfies the regulator is the same architecture that lets you deploy with confidence. Build it once, build it early, and hallucination becomes a managed operational parameter rather than a latent liability.
A Fit Call maps where in your workflows an unverified AI output becomes a decision — and what verification layer belongs there — before a wrong answer reaches a customer or a regulator.
References: Vectara, "Hallucination Leaderboard" (github.com/vectara/hallucination-leaderboard), updated 2026; Magesh et al., "Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools," Stanford RegLab / HAI, 2024 (hai.stanford.edu/news/ai-trial-legal-models-hallucinate-1-out-6-or-more-benchmarking-queries); EU AI Act, Articles 14 and 15 (artificialintelligenceact.eu/article/14, /article/15); GDPR Article 5(1)(d) (gdpr-info.eu/art-5-gdpr).