What are analysts for when AI can analyse?

Imagine a CEO asking the awkward question in a leadership meeting:

If AI can write SQL, make charts, summarise customer feedback, explain trends, and suggest what to look at next, why do we still need data analysts?

It is tempting to treat that as an ignorant question. I don't think it is any more.

The first answer many of us reach for is productivity. We still need analysts, the argument goes, but AI will make them faster: less time on SQL, charts, documentation, and boilerplate; more time thinking about the problem.

I believe that. It is already happening.

But it is not quite enough.

The uncomfortable part is that AI is getting better at the thinking too. It can suggest hypotheses, summarise feedback, spot obvious anomalies, draft narratives, propose cuts of the data, and explain a chart in language that sounds plausible. The old bargain - machines do the implementation, humans do the judgement - is still directionally right, but it is becoming too simple.

So I don't want to write the defensive version of this essay: "how dare you, of course analysts still matter, there is far too much craft here." I think the more useful response is: fair point. Let's take a cold, hard look at what the role actually is now, and where it's going. Because that role could be quite different to where you started out, and you might decide it's no longer for you.

The question then is: if AI can do a decent first pass at both the SQL and the interpretation, where does the analyst actually add value?

I don't think we can answer that by listing supposedly unique human skills in advance. My approach has been to let AI do as much as possible and see what remains.

A customer satisfaction example

I had a customer satisfaction driver analysis recently that made this feel very real.

AI was incredibly useful. It helped me move quickly through first-pass exploration, generate hypotheses, write queries, and think of possible cuts. The mechanics were much faster than they would have been even a year ago.

But the first pass had a lot of "so what?" energy.

It produced things that were interesting, but not yet useful. Averages moved. Themes appeared. Some groups looked better than others. There were plausible explanations. But it was not yet clear what anyone should do differently.

The first useful move was not a clever query. It was framing.

I thought the right way in was to look at inbound customer service contacts (calls and email), focus on quality indicators like CSAT and repeat contact rate, but then use two key decompositions:

• Who handled the contact? - if there's a big variance across teams or individuals then there might be opportunities to address gaps in training or performance management.
• What was the contact about? - is bad experience concentrated on specific topics and journeys? That would help steer us towards deeper dives on journeys with enough pain/volume.

But then another problem appeared. The contact reason classifier we were relying on was not sharp enough for the question we were asking. I looked at the transcripts: some of the categories were still a mish-mash. My mental model of what certain contacts were really about had become meaningfully sharper than the AI classification.

That mattered. If the categories are muddy, a driver analysis can become a very polished way of over-interpreting the wrong labels. So the work had to loop back into the ML pipeline: are the classes right, are the examples clean, are the outputs good enough to support this decision?

AI helped there too. It accelerated exploration and generated ideas. But it did not remove the need to notice that the classification layer itself had become part of the analysis.

Then came the human loop.

I played the early ideas back to PMs and people closer to the process. They clarified how things actually worked. They gave their take on where to look deeper. They explained which levers were real and which were mostly theoretical. They challenged some interpretations and added context I would not have found in the warehouse.

That was the point where the analysis started to become useful.

Part of the challenge was deciding what not to do. Once I judged I had gone deep enough on a specific call topic, and that my time was better spent on the next one, I brought that judgement to the group and owned it.

AI made each move faster. It did not take responsibility for deciding which moves were worth making, or for connecting them into an answer the organisation could use.

Judgement, not just context

One reading of the CSAT example is that I had context the AI lacked. I knew enough about the organisation to choose a useful framing, notice that the classifier was weak, and find people who understood the process.

That is true, but I am not sure it is a durable answer. AI will gain access to more organisational context. It will remember previous analyses, consume meeting notes, inspect operational systems, and ask people questions. “The human knows things the AI does not” may be an advantage today, but it is a shrinking window.

I used to think critical thinking would remain the obvious edge. I am less sure about that too. AI is getting better at challenging assumptions, proposing counterarguments, spotting weak logic, and asking reasonable follow-up questions.

What seems more durable is judgement: deciding which incomplete, conflicting signals to act on when the consequences are real - including when to stop and move on.

AI will improve at that too. The distinction is not that only a human can contribute judgement. It is that an organisation still needs someone to own it.

That can sound like a retreat from analytical rigour into instinct. I don't think it is. Judgement is not a substitute for evidence; it is the act of deciding what the evidence can support, how much weight it can bear, and what to do when it runs out.

For years, the popular ambition was to become more “data-driven”. That language sometimes implied that data could make the decision for us. A more mature standard is data-informed judgement: evidence disciplines experience, while experience helps recognise which evidence matters and where its limits lie.

The analyst's contribution, then, is not “I had the context” or even “I thought more critically than the model”. It is owning the reconciliation of evidence, constraints, and consequences into a claim about what the analysis can support.

Someone still has to stand behind the answer

We used to talk about trust in data mostly through quality: freshness, tests, definitions, monitoring. That still matters.

But AI changes the emotional contract. People are surprisingly willing to accept that an AI answer might be rough, directional, or wrong on first pass. In exploration, that tolerance can be useful. It makes people more willing to ask messy questions and iterate quickly.

The danger is when the same tolerance follows the answer into a decision.

At some point, someone has to stand behind the analysis. Not because they personally wrote every query, but because they are willing to say: I have checked the framing, the assumptions, the evidence, and the limits of this claim. I am prepared to recommend that we act on it.

An AI can apologise after the fact. It can say "good catch" and revise the answer. That is useful during exploration. It is less useful after the big decision has already been made.

This is the analyst's accountability: deciding when something has moved from directional exploration to a claim the organisation can responsibly act on. They may not own the final business decision, but they should retain the final say on whether the analysis is fit to support it.

An organisation can automate a decision, but it cannot automate away responsibility for the consequences. AI does not answer to customers, regulators, or boards when an analysis causes harm or sends the business in the wrong direction. People do.

But that responsibility is hollow if the person holding it cannot interrogate the work. It cannot simply move to whichever manager owns the decision: they still need someone close enough to the evidence to explain its limits, challenge how it was produced, and say when it is not ready.

What this means for analysts

I don't think the answer is to defend the tasks we used to perform or compete with AI on speed. It is to move from being the primary executor of analysis towards being accountable for its direction and quality.

That means using AI aggressively, staying technical enough to interrogate what it produces, and getting close enough to decisions to learn which levers are real and what happened after. Judgement develops through that feedback loop, not by producing more analyses in isolation.

It also means deciding what should outlive the analysis: a classifier fix back in the ML pipeline, a segment that becomes a governed definition, a caveat that was really a population boundary. Steering the analytical system is part of the job, not a side effect of answering one question.

This shift will not appeal to everyone. If implementation itself is what you most enjoy, there may be less of it. But if you have always taken joy from the impact of your work - from the hard thinking, connecting ideas, and bringing people together around a decision - then you may enjoy being a data analyst more than ever.

AI can make the whole loop much faster. It can propose routes, do much of the work, and challenge the person at the wheel.

So, why do we still need analysts?

Because speed does not remove the need for someone to steer: to decide what is not working, connect the evidence to reality, reject a plausible but inadequate answer, and stand behind the one the organisation uses.