At MeasureCamp Dublin in May, during my session, I asked analytics practitioners two questions.
First: who here has dropped a CSV into ChatGPT and asked it to find something? Almost every hand went up.
Second: who was happy with the answer? Almost every hand went down.
Photo by Ryan Conophy
I have asked versions of these questions at several events now, and the result never changes. It should worry everyone working in data. We handed analytics teams powerful AI tools before we gave them any way to judge whether the answers those tools produce can be trusted.
That gap, not model accuracy, is the real risk in analytics right now.
On its own, an LLM is close to useless for serious analysis. Hand it a real dataset with thousands of rows, and it will give you totals that don’t add up, trends that were never there, and a tone so confident you won’t think to check. In one example I showed in Dublin, an AI built an entire story about expansion into Japan from data that had no Japan column at all.
The industry keeps filing these under “accuracy problems” that a smarter model will eventually fix. That framing is flawed. The issue is not that AI gets things wrong, but that we cannot tell when it is wrong, because the failure arrives wrapped in fluent, authoritative prose. Spotting it is our job, not the model’s.
The root cause is simple once you accept it: an LLM does not calculate; it predicts the next token. It can tell you 1 + 1 = 2, because the internet is full of that sentence. The moment it faces your actual numbers, it is guessing. It is an interpretation engine, and we have been using it as a calculator.
This matters now because the rest of tech has already moved. Engineers adopted AI almost immediately after MCP arrived about 18 months ago. Tools like Cursor and Claude Code became standard for writing and reviewing code. At the largest companies, the share of AI-generated code now runs from roughly 30% to nearly 100%.
Code worked first because it is structured, testable, and self-correcting: you run it and find out instantly whether it works: you run it and find out instantly whether it works.
Analytics has the same structural properties but none of the guardrails. And the consequences are worse. A bad pull request gets caught in review. A bad number in a board deck becomes a decision, and that decision moves through a business long before anyone traces it back to a hallucinated total.
At Coupler.io, we deliberately changed our lead scoring form to filter for higher-quality prospects. We expected fewer scheduled sales calls and got exactly that. Then our AI analyzed the funnel and flagged a “massive acquisition problem,” because calls were dropping. The AI read the data correctly and drew the wrong conclusion because nobody had told it we changed the form. The detail that stays with me: our sales manager, looking at the same dashboard, reached the identical wrong conclusion.
This was never an AI problem. It was a context problem, and it hits people and machines the same way. Two things fix this, and you need both.
First, make the outputs more reliable by changing how AI processes your data. Stop pasting spreadsheets into a chat window. Connect your data sources through MCP and let a real analytical engine, not an LLM, do the math.
The flow is clean: the AI reads your schema, writes the query, the engine runs it and returns pre-calculated results, and only then does the AI interpret what comes back. The model never adds, averages, or counts anything itself. It only interprets numbers that have already been verified.
Second, keep a validator in the loop. Reliable inputs reduce the errors. They do not remove your responsibility to check the interpretation, though.
That means documenting your business context in a way both your team and your AI can read: how you define your core metrics, what to exclude, and what changed last quarter. It means building reusable skills rather than one-off prompts, and introducing AI agents to validate every report before it ships. (The lead-scoring story would have been a non-event if the context had been written down once.)
This shift will not be led by model vendors or by executives who have never cleaned a dataset. It will be led from inside the profession, by the people who already know what a believable-but-wrong number looks like.
The analyst role is not going anywhere. What changes is the work itself: less time running the queries, more time designing how the work gets done and deciding what to trust. AI fluency is becoming as fundamental as SQL.
The teams that build this discipline now will be operating on a different level within a year. The ones who still drop files into a chat and believe the answer won’t see what they got wrong until it has already cost them.