A message lands in the analyst’s chat: “Can you pull the new FTS numbers?”

It feels like a thirty-second favour. The reality runs deeper. Hidden inside that one sentence are at least half a dozen questions, none of them asked: which metric, which season, which period, compared to what, for what decision.

That tiny exchange is the smallest possible version of the entire relationship between business and data teams. Answered well, it produces something someone can act on. Answered badly, it manufactures false confidence with a deadline attached. Multiply by every Slack message in every company, every week. That is where becoming data-driven gets built or broken.

The paradox

When senior data leaders are asked what is blocking them, they point at people, culture, and process. They name the human side as the wall they keep hitting. Then in the same conversations, fewer than one in fifty rank data literacy as an investment priority.

Four in five name the problem. Fewer than one in fifty invest in fixing it.

The split shows up on both sides. Business leaders describe their organisations as “very data-driven”. Technical leaders in the same companies report struggling to deliver business priorities with data. Same companies, opposite verdicts.

Why this happens

The easy reading is corporate hypocrisy. The honest reading is harder. The second problem is genuinely harder than the first.

Data literacy programmes are slow. They are expensive. Their benefits are diffuse. And “data literacy” itself is contested. The field has no agreed definition of what it actually means. A discipline cannot easily fund, scope, or measure what it has not yet defined.

There is a second possibility. The leadership making the budget calls may not yet have enough data literacy themselves to recognise which interventions actually matter. Low literacy at the top compounds the problem twice: once in failing to invest, and again in misjudging what to invest in.

Where AI makes it worse

With AI in the picture, the dynamic changes less than people think.

A vague question to an analyst produces correct-but-useless work. A vague prompt to a language model produces fluent-but-wrong work. In the chat version, someone competent and a little annoyed pushes back. In the LLM version, nobody asks.

The same cognitive failure that produces “pull the FTS numbers” in a Slack message now produces “summarise FTS performance” as a prompt. A vague question goes in. A beautifully written, plausibly framed, confidently wrong answer comes out.

Every existing data-quality problem is therefore also an AI problem. An organisation that already distrusts a meaningful slice of its own data does not see that distrust resolved by AI. The system presents the same flawed inputs with more polish.

The thread

The recurring failure across all of it is the same. The problem is a question that was never framed properly before the work began.

Fix that, and the rest becomes tractable. Leave it broken, and AI just amplifies the noise.

The second part of this pair looks at what fixing it actually involves. The full argument with sources lives in the long-form article.