How to Tell When an AI Analytics Answer Is Wrong

The failure has a specific shape

AI analytics does not usually fail by hallucinating a fact. It fails by computing a real number from the wrong data and presenting it with the same confidence as a right one.

This is a different problem from chatbot hallucination and it needs different controls. There is no fabricated citation to catch. The query ran. The rows are real. The arithmetic is correct. The answer is still wrong, because the question the system answered is not the question you asked.

Call it a silent failure. It is the dominant risk in analytics and the least discussed.

The six ways a number comes back wrong

1. Wrong metric definition

You asked for sales. The system used gross sales; finance means net of returns and markdowns. The gap is typically 3 to 12% and it is stable, which makes it worse: the number looks consistent across periods, so nothing flags.

2. Join fan-out

The transaction table joined to a table with multiple rows per key. Every sum is inflated by the average fan-out factor. Revenue reads 2.3x actual, or 1.15x, which is the dangerous magnitude because it is plausible.

3. A missing filter

Test stores are in the data. Closed stores are in the data. Employee transactions, franchise locations, and the warehouse pseudo-store that carries transfers are all in the data. The analyst's query excluded them out of habit. The generated query did not, because nothing in the schema says to.

4. Wrong time window

"Last month" against a fiscal calendar that starts on a Sunday, or a 53-week year, or a period that closed three days ago and is still receiving late transactions. The system picks calendar month. Off by 4 to 9%.

5. Wrong grain

Averaging an average. Store-level margin percentages averaged across stores is not chain margin percentage, and the difference grows with store size variance. This one reliably survives review because the number looks reasonable.

6. Nulls treated as zero

A missing cost gets summed as zero, so margin reads higher. The affected rows are usually the new SKUs, which are the ones you were asking about.

How to check an answer in under two minutes

Four checks, in order of how often they catch something.

Check the row count against something you know. If the query says 400 stores and you operate 387 plus a warehouse pseudo-store, the filter is wrong. Row count is the fastest signal available and almost nobody looks at it.

Check the total against a known anchor. You know roughly what a week of sales is. If the answer implies a week that is 15% off your mental baseline, stop. This catches fan-out and definition errors immediately.

Read the WHERE clause, not the whole query. You do not need to audit the SQL. You need to see what was excluded. Ninety percent of silent failures are visible in the filters alone.

Ask the same question a second way. Request the same number sliced differently, by month instead of by quarter, and check that it sums. Inconsistent decompositions expose grain and join errors that a single answer hides.

What the system should do so you have to check less

Checking every answer does not scale, which is the entire reason this matters. The controls have to live in the tool.

Cited SQL, always visible. Not behind a toggle labeled "advanced." If the query is hidden, the WHERE-clause check is unavailable and five of the six failure modes become undetectable.

A named metric, not an ad hoc calculation. The answer should say which definition it used: "net sales, finance definition, excludes returns and employee purchases." Now the definition error is visible without reading SQL.

Stated row counts and time bounds. "412,338 transactions across 387 stores, fiscal weeks 27 to 30." Two of the six failure modes are caught by reading one line.

Calibrated refusal. The system should decline when the question is ambiguous rather than picking. A tool that never says "did you mean net or gross" is not being helpful, it is guessing on your behalf and hiding that it guessed.

Reconciliation against a trusted source. The strongest control available. If revenue answers are automatically checked against the finance close and flagged when they diverge beyond a threshold, entire classes of error stop reaching a human at all.

The control that matters most is not technical

Run a monthly sample. Pull twenty answers the system produced, have an analyst reproduce them independently, and record the exact-match rate.

This costs about half a day and it is the only thing that tells you whether trust in the system is calibrated. Teams that do not do this land in one of two states within a year: they trust it completely and are wrong sometimes without knowing, or they trust it not at all and quietly went back to asking the analytics team.

Both states waste the investment. The sample is what keeps you out of them.

Key takeaways

• AI analytics rarely hallucinates a fact. It computes a real number from the wrong data, with full confidence. The query ran, the rows are real, the arithmetic is right, and the answer is wrong.
• Six failure modes cover nearly all of it: wrong metric definition, join fan-out, missing filter, wrong time window, wrong grain, and nulls summed as zero.
• The dangerous errors are the plausible ones. A 2.3x inflation gets caught. A 1.15x inflation gets presented to the board.
• Four checks catch most of it in under two minutes: row count against a known store count, total against a mental anchor, read the WHERE clause only, and ask the same question sliced differently to see if it sums.
• Tool-side controls that remove the need to check: always-visible SQL, a named metric definition in the answer, stated row counts and time bounds, calibrated refusal on ambiguous questions, and automatic reconciliation against the finance close.
• A tool that never asks "did you mean net or gross" is guessing on your behalf and concealing that it guessed. Zero refusals is a warning sign, not a feature.
• The most important control is organizational: sample twenty answers monthly and have an analyst reproduce them. Half a day. Without it, teams end up either uncalibrated-trusting or quietly back on the old queue.