top of page

What Causes AI Hallucinations in Business Data (and How Architecture Prevents Them)

  • Writer: Matt Lazarus
    Matt Lazarus
  • Jun 11
  • 5 min read

Every executive who has piloted generative AI has a version of the same story. The assistant was asked a routine question - last quarter's revenue, the current headcount, the warranty terms - and answered fluently, confidently and wrongly.

 

The popular diagnosis is that the AI "lied" or "made it up". The engineering diagnosis is more useful: the model improvised, because the grounding it needed was absent, ambiguous or contradictory.

 

That distinction matters, because improvisation has architectural causes - and architectural causes have architectural fixes.

 

Key Takeaways

 

  • Hallucination over business data is a grounding failure - the model fills gaps when sources are missing, stale or conflicting.

  • Your data conditions set the hallucination rate: four conflicting revenue tables guarantee improvised answers.

  • The fix is engineered, not prompted: retrieval grounding, certified semantic layers and evaluation harnesses drive the rate down measurably.

 

What Is an AI Hallucination, Mechanically?

 

A hallucination is a fluent output that is not supported by the model's grounding - produced because language models generate the most plausible next words, not verified facts. When the evidence available to the model is incomplete or contradictory, plausibility and accuracy part ways, and the model continues speaking anyway.

 

The crucial point is that nothing malfunctions. The model is doing precisely what it was built to do: produce coherent language. Coherence is guaranteed; correctness is conditional - conditional on what the system around the model supplies as evidence.

 

That is why the same foundation model hallucinates constantly in one organisation and rarely in another. The difference is never the model's honesty. It is the quality of the evidence each organisation puts in front of it.

 

Why Does Business Data Make Hallucinations Worse?

 

Business data multiplies hallucination risk because enterprises systematically produce the exact conditions that force improvisation: multiple versions of the same fact, undefined terminology and stale content presented as current. A model grounded in a typical corporate estate is grounded in contradictions.

 

The four conditions that do most of the damage:

 

  • Conflicting sources: revenue exists in four tables with four values; the model selects one - plausibly, and differently each session.

  • Undefined business logic: "active customer" or "margin" carries no certified definition, so the model supplies the internet's average meaning rather than yours.

  • Stale and duplicate content: retrieval surfaces the 2021 policy alongside the current one, and the answer blends them seamlessly.

  • Coverage gaps: the genuinely needed document was never digitised, indexed or permissioned - so the model bridges the gap with fluent invention.

 

None of these is an AI problem. Every one of them existed before the pilot. The model simply converts latent data debt into visible wrong answers - at speed, in front of leadership.

 

A fifth condition compounds the other four: volatility without versioning. When policies, prices and structures change but the content estate keeps no authoritative record of what superseded what, even a diligent retrieval layer cannot distinguish the current truth from its predecessors - and the model inherits the confusion at answer time.

 


How Does Architecture Prevent Hallucinations?

 

Architecture prevents hallucinations by controlling what the model is allowed to treat as evidence: retrieval grounded in curated sources, business logic certified in a semantic layer, and numeric questions routed to deterministic calculation rather than generation. The model keeps its fluency - the system supplies the truth.

 

The countermeasure stack, layer by layer:

 

  • Grounded retrieval: answers must cite retrieved passages from deduplicated, current, permission-aware sources - and decline when nothing relevant is found. "I cannot find that" is a feature, not a failure.

  • A certified semantic layer: metrics and terms defined once, calculated identically everywhere - so "what was Q2 revenue?" is resolved by certified logic, not linguistic plausibility. This is the discipline behind semantic layer consulting.

  • Constrained generation for numbers: the model orchestrates the question; a governed query computes the figure. Language models should narrate calculations, not perform them.

  • Evaluation harnesses: a standing test set of business questions with known answers, scored on faithfulness before and after every change - making the hallucination rate a tracked metric.

 

Can Prompting Alone Fix Hallucinations?

 

No. Instructions like "only answer from the documents" reduce some failure modes but cannot repair conflicting sources, missing definitions or stale content - the model cannot retrieve evidence that does not exist or adjudicate contradictions it has no authority over. Prompting shapes behaviour at the margins; the floor is set by the data.

 

This is the most expensive misunderstanding in enterprise AI right now: teams iterating on prompts for months to compensate for an estate problem that a bounded remediation programme would fix permanently. The work of preparing your data for AI is precisely that programme - consolidating sources, settling definitions and cleaning the retrieval pool the model grounds against.

 

How Do You Measure Your Hallucination Rate?

 

You measure it with an evaluation set: a curated battery of business questions with verified answers, run against the system on a schedule, scored for faithfulness to the grounding sources. The score - not anecdotes from frustrated users - becomes the metric that tells you whether changes helped and where remaining failures live.

 

Building the set is less work than it sounds, and the discipline pays immediately:

 

  • Harvest real questions: fifty to a hundred questions staff genuinely ask, drawn from support tickets, search logs and workshops - not invented ideal queries.

  • Verify the answers once: each question gets a confirmed correct answer and the source it should ground on, signed off by the business owner.

  • Score three properties: accuracy (is the answer right?), faithfulness (is it supported by the cited source?) and refusal quality (does the system decline when no grounding exists, rather than improvise?).

  • Run on every change: new content, new index, new model version - the battery runs, the score moves, and regressions surface before users find them.

 

The refusal property deserves emphasis because teams routinely optimise it backwards. A system that answers everything scores well with demo audiences and terribly with auditors; a system that says "I cannot find that in the current sources" exactly when it should is displaying the behaviour that makes the other answers trustworthy.

 

Which Business Questions Are Most Vulnerable to Hallucination?

 

The highest-risk questions share a profile: they demand a precise numeric answer, they span more than one source system, or they depend on which version of a document is current. "What was Q3 revenue?", "how many active customers do we have?" and "what is our current travel policy?" are the questions most likely to be answered wrongly - and most damaging when they are.

 

This profile is useful because it makes risk testable before deployment. Build your evaluation set from exactly these question types - numeric, cross-system and time-bounded - rather than from easy single-document lookups. An assistant that survives the hard profile has earned trust; one validated only on softball questions has earned a future incident.

 

Treat the Rate, Not the Anecdote

 

Organisations that conquer hallucination stop treating it as an anecdote and start treating it as a rate. They measure it with an evaluation set, attribute each failure to its layer - retrieval, definition, coverage or generation - and fix the layer. Within a few cycles, the assistant that invented numbers becomes the assistant that cites its sources or politely declines.

 

The model never changed. The evidence did.

 
 
bottom of page