AI Analytics Hallucinations: How to Trace Every Number Back to SQL

AI is confidently wrong about your business – and you can't tell which number is the lie.

That's the whole problem in one sentence. Not that AI makes mistakes. That its mistakes arrive formatted exactly like its right answers. I've watched this play out live, mid-call, and I'll tell you that story below.

Your mandate: AI value without AI liability

If you own AI rollout at your company – Head of AI, innovation lead, Head of Data & AI – you're living between two clocks.

Clock one: the board wants visible AI value, this year, not a two-year platform story. Clock two: every AI deployment you approve carries the risk that a fabricated number surfaces in a real decision – a reorder, a budget cut, a board update – with your name attached to the tooling that produced it.

Most AI analytics pitches only talk about the first clock. This piece is about beating both at once, because the way you beat the second clock is precisely what makes the first one winnable: ship AI the organization can actually trust, and adoption stops being a fight.

How often AI actually hallucinates

Let's put real numbers on it, because "AI hallucinates" gets thrown around loosely.

The 2026 benchmarks are task-dependent – and that's the important part. On simple summarization, frontier models hallucinate on only 1–2.5% of outputs. On retrieval-grounded tasks, 4–9%. But on hard, domain-specific queries the numbers fall apart: a 2026 benchmark across 37 models found rates between 15% and 52%, and Stanford's research measured 69–88% on specific legal queries. 

Even more uncomfortable: the newest reasoning models regress on factual recall – OpenAI's gpt-5.4 mini hallucinated 33% of the time on the PersonQA benchmark, double its predecessor.

Now ask yourself which category "compute my blended ROAS across three ad platforms with our custom attribution window" falls into. Not the summarization one.

Here's what makes analytics uniquely dangerous: the answer arrives with no error bar. A wrong revenue figure reads exactly like a right one. Confidence is the interface.

Why "AI on your warehouse" guesses

So why does pointing a smart model at your own data still produce wrong numbers? Because of what these tools actually ask the model to do.

The typical "chat with your data" architecture hands the LLM your raw schema and lets it write SQL on the fly. Every question becomes an improvisation: the model guesses which of your 400 tables holds the truth, guesses what `status = 3` means, and – the killer – invents joins between tables that were never meant to be joined. Each guess is plausible. That's the model's job: producing plausible output. LLMs are genuinely useful for drafting SQL when an analyst reviews every line. Remove the reviewing analyst and put the output straight into an executive's chat, and you've built a confident-nonsense machine.

Here's what an invented join looks like in practice. Your orders table and your ad-spend table both have a `campaign` column – one holds campaign IDs, the other holds campaign names. A human analyst knows they don't match and joins through the mapping table. The model doesn't know that mapping table exists. It joins the two columns directly, drops half your conversions on the floor, and reports a ROAS that's 40% off – in a fluent paragraph, with a nice chart. Nobody wrote wrong SQL on purpose. The architecture asked a text predictor to do data engineering.

One claim, one proof: the model that writes ad-hoc SQL against raw schema will eventually invent a join – and the wrong ROAS it returns will be formatted identically to the right one.

The governed alternative: AI narrates, SQL computes

The fix is not a smarter model, better prompting, or another accuracy benchmark. The fix is architectural: take the model out of the math.

Here's the division of labor that works. Your data analyst publishes governed data marts – controlled, reusable datasets with the business logic, metric definitions, and joins they wrote and approved. The AI connects to those data marts through MCP (Model Context Protocol – the open standard that lets an AI chat talk to external systems through a controlled interface; here's how it works with BigQuery and Claude). When someone asks a question, deterministic, analyst-written SQL computes the number. The language model's only job is language: narrate the result, draw the chart, put it in a Sheet.

To be precise – because precision is the entire point: this doesn't make the AI incapable of error. It makes the AI incapable of inventing your numbers, because it never computes them.

‍

Only analyst-authored joins run

The governance isn't a policy document. It's enforced at the query level.

In this setup, the LLM physically cannot improvise a join – the only joins that exist are the ones your analyst authored into the data governance layer. Ask a question the governed data marts can answer, and you get a traceable answer. Ask something outside that surface, and the request fails loudly – "I don't have that data" – instead of fabricating something plausible.

That failure mode is a feature. An AI that says "I can't answer that" is annoying for a moment. An AI that invents an answer is expensive for a quarter.

Every number traces back

Trust isn't a feeling; it's a property you can check.

In a governed setup, every figure in every AI answer traces back to SQL a human wrote and approved. And every query the AI runs – including the ones where it tried to reach for something outside its permissions – lands in Run History, visible to your data team. Your analyst doesn't hope the AI behaved; they can see exactly what it did.

For the AI lead, this changes what you're presenting to the board. Not "our AI is usually right" – an argument you lose the first time it isn't – but "every number this system produces is auditable to human-authored logic." One is a bet. The other is infrastructure.

‍

The board-liability clock

One more reason this stopped being optional: the regulatory clock.

The EU AI Act, in force since August 2025, mandates traceable logic for AI systems in scope, with fines reaching €35M. Whatever your exposure to that specific law, the direction is unambiguous – "the AI said so" is not a defensible provenance for a number that drove a decision. An untraceable AI answer in a board deck used to be an embarrassing meeting. Increasingly, it's a legal artifact.

And there's the career math on top: Gartner projects that by 2027, 75% of chief data and analytics officers who fail to show measurable AI value will be reassigned or removed. Shipping AI the org distrusts is the express lane into that statistic. Shipping traceable AI is how you stay out of it.

The mid-call disconnect

Here's the moment that turned this from theory into conviction for me.

I was on a working session with the CEO of a US ecommerce brand – a founder who'd spent years trying to get straight answers out of his own data. He'd been testing two MCP connections to his business data side by side – one of the DWH-native connectors (Windsor), and a governed setup on OWOX data marts. Same chat, same questions, both connections answering in parallel.

For a few questions, the answers agreed, and the whole exercise felt academic. Then one of them returned a figure that was wrong. Not absurdly wrong – plausibly wrong, which is worse: a number he would have accepted on any other day, in any other meeting. The governed connection returned the number his analyst could trace to the SQL behind it. He looked at the two answers, said something I won't quote in polite company, and disconnected the ungoverned MCP mid-call. Not at the end of the evaluation. During it.

One company, one CEO, one call – and I'm keeping him anonymous because it was a working session, not a testimonial shoot. But I watched a skeptical operator run the only benchmark that matters: his own data, side by side, with the ability to check who was right.

"But our AI tool already answers questions"

This is the objection I hear most from teams that already bought a chat-with-your-data tool or turned on a DWH-native MCP server. It already answers! It's fast! True. The question was never whether it answers – it's who wrote the SQL behind the answer.

‍

To be fair to those tools: as pipes, many are fine. The difference isn't connectivity – everyone has connectors now. The difference is whether the model is allowed to do arithmetic unsupervised. If you're comparing AI analytics tools, that's the one column that matters.

And if your data analyst is the one raising this objection from the other side – good. That skepticism is exactly the instinct you want in the person who governs the surface. Hand them something real before asking for anything: we built a free visual data-modeling tool at model.owox.com – open format, no signup wall. It's a better opening move than a pitch deck.

Ask a better question

Everyone evaluating AI analytics asks "which AI is smartest?" Wrong question. They're all smart, and they all hallucinate – the benchmarks above aren't close calls.

Ask instead: which setup makes it impossible for the AI to lie about my numbers? That's not a model property. It's an architecture property – AI narrates, analyst-written SQL computes, every figure traces back.

You can test it without a transformation program: have your analyst publish one governed data mart, connect it to the chat you already use, and ask one real question. You can start free with OWOX Data Marts – and send your data person to model.owox.com first. The rollout that survives is the one they help build.