Most conversations about AI and data analysis get stuck on the tools. Can it write SQL? Can it build a chart? Can it find a pattern faster than an analyst?
Yes, usually. That is the easy part.
The harder part is deciding whether the pattern means anything, whether the recommendation fits the business, and whether acting on it will create a better outcome. That is where I still want a human making the decision.
I use AI regularly in analytical work. It helps me explore a problem, write and check code, test different explanations, document a method, and get through repetitive work faster. I do not use it as an oracle. The model can help with the analysis, but I still own the question, the assumptions, the validation and the recommendation.
AI can see the dataset. It cannot see the organisation.
A dataset is only one layer of a business problem. Around it sits domain knowledge, internal context, external context, relationships and politics. Those layers often determine whether an analytical answer is useful, misleading or impossible to act on.
This is the part that gets lost when people describe analysis as a neat sequence of data in, insight out. Real analytical work is messier. The same number can mean different things depending on what changed in the business, who owns the decision, what the customer is doing, and what happened in the market last week.
1. Domain knowledge changes what you look for
AI is good at generating plausible hypotheses. Domain knowledge tells you which hypotheses deserve attention.
In retail and FMCG, a sales decline might come from distribution loss, pricing, promotional timing, availability, competitor activity, seasonality, range changes, packaging, or a change in how the data is classified. A model can list all of those. It does not automatically know which ones are normal for the category, which signals tend to move first, or which explanations are commercially realistic.
Domain knowledge also helps you notice when the data is technically correct but conceptually wrong. I have seen clean sales data understate a segment because a major brand had fallen out of the category hierarchy. Nothing was broken in the file. The definition no longer matched the market.
That is why I treat AI-generated analysis the same way I treat any other analytical output: useful evidence, not a conclusion. Before I trust it, I still ask what the data represents, what is missing, whether the categories reconcile, and what decisions it is safe to support.
2. Internal context explains the numbers the model cannot
Internal context includes the things that rarely live in the data warehouse: a packaging change, a sales process change, a retailer dispute, an out-of-stock issue, a new target, a reporting definition that changed quietly, or a campaign that launched late.
This context can completely reverse the interpretation. A conversion rate may have fallen because customer demand weakened, or because the application process added another step. Sales may be down because the product is less appealing, or because it disappeared from shelves for three weeks. The chart can look identical.
A practical example: the product decline that was not a pricing problem
At BIC, a key product range declined 48% within one month. The obvious explanations were price, product quality, distribution or competitor pressure. The product and price had not changed, distribution was stable, and other products in the category were behaving normally.
I combined scan data, consumer panel data and custom shopper research. The sales data showed where the decline was happening. The panel data showed previous buyers switching away. The research explained why: the packaging had changed from transparent to opaque, and shoppers could no longer tell what they were buying.
AI could have helped me organise the data, write analysis code, generate a hypothesis list or summarise survey responses. It would not have known, without being told, that the packaging had recently changed, that a retailer range review was approaching, that global teams controlled the redesign, or that retailer buyers needed a defensible reason to protect the range.
Those facts shaped both the analysis and the recommendation. The business case led to a redesign, and the range returned to 18% growth the following year.
The useful answer was not simply “packaging is correlated with the decline.” It was a plan that could survive internal review, retailer scrutiny and the time lag before new packaging reached the shelf.
3. External context tells you whether the business caused the change
A business never operates inside its own dashboard. Competitor launches, retailer decisions, regulation, economic conditions, seasonality, media coverage and changes in customer behaviour can all move the result.
Internal data tends to make every problem look internal. If sales fall, the first instinct is often to review the campaign, product or sales team. Sometimes the category is shrinking. Sometimes a competitor has changed the market. Sometimes a retailer has moved the shelf, altered its ranging strategy or changed how promotions are funded.
AI can help search for external explanations and compare them with internal trends, but someone still has to judge source quality, timing and relevance. A news article, a competitor claim and a reliable market dataset are not interchangeable just because they all appear in the same answer.
4. Stakeholder and client relationships are part of the analysis
Good analysis is not only about finding the right answer. It is also about understanding the person who needs to use it.
A finance leader, sales director, product manager and retailer buyer can look at the same finding and ask completely different questions. One wants confidence in the numbers. One wants to know what action is possible this quarter. One wants to understand customer impact. One wants to know what they will have to defend in the next meeting.
The relationship tells you how much background is needed, where the trust gaps are, and how directly you can challenge an assumption. With long-term clients, you also build memory. You know which metrics they rely on, where the data is weak, what has been tried before, and which recommendations are realistic within their operating model.
At Nielsen, a large part of the job was not producing another cut of the data. It was understanding what the client was really asking, explaining the method in plain English, and turning the result into something they could use with their own stakeholders. Sometimes the stated question was not the real question. A request for a market-share chart might actually be anxiety about a range review or a need to explain a miss to leadership.
AI does not have that relationship. It has the words in the prompt. Those are not the same thing.
5. Organisational politics changes what can happen next
Politics is usually treated as a dirty word, but in analytical work it often just means incentives, ownership, risk and influence.
Who owns the metric? Who controls the budget? Which team is being asked to change? Who will be exposed if the recommendation is accepted? Does the decision need local approval, global approval, customer approval, or all three? Is there enough time to act before the next planning cycle?
A technically correct recommendation can fail because it arrives too late, threatens a team's ownership, ignores a commercial commitment, or asks someone to take a risk they cannot defend. Pretending those constraints do not exist does not make the analysis more objective. It makes it less useful.
I do not change the finding to suit the politics. I change how I build the case. That might mean bringing a stakeholder into the analysis earlier, showing the assumptions more clearly, separating what is known from what is directional, or presenting a staged recommendation instead of one large leap.
AI can help structure the argument. It cannot take responsibility for the trade-off.
Where I actually use AI in the workflow
The safest way I have found to use AI is to give it a defined role inside the analytical process rather than handing it the whole problem.
1. I define the decision first
Before opening an AI tool, I write down what decision the work is meant to support, who will use it, and what would change if the answer points one way or another.
2. I assemble the context
I include metric definitions, known data issues, recent business changes, relevant market events, stakeholder constraints and anything that would change how the result should be interpreted.
3. I use AI to accelerate the work
This can include drafting SQL or Python, checking formulas, generating alternative hypotheses, summarising qualitative responses, producing test cases, documenting methodology or challenging my first interpretation.
4. I validate independently
I check totals, reconcile against source systems, review sample records, test edge cases and read the code. A confident explanation is not evidence that the output is correct.
5. I compare the output with domain and organisational reality
Does it fit what we know about the category, customer, process and market? If it conflicts, is that a valuable surprise or a sign that the analysis is missing context?
6. I make and own the recommendation
AI can show options and help explain trade-offs. The final recommendation is mine because I am the one connecting the evidence to the people, constraints and consequences around the decision.
The context pack matters more than the clever prompt
When I ask AI to help with analysis, the quality usually depends less on prompt tricks and more on whether I have supplied the right context. My useful context pack is normally:
- the business question and the decision it supports
- what one row represents and how the key metrics are defined
- known exclusions, hierarchy changes and data-quality limitations
- recent internal events and relevant external events that may explain the pattern
- the stakeholders involved, their constraints and the level of evidence they need
- what the model should do, and what it should not decide
That last point matters. I might ask AI to identify anomalies, propose hypotheses or critique my reasoning. I do not ask it to decide whether a product should be removed, a price should change, a client should be challenged, or a team should redirect investment. Those decisions require accountability.
The point is not to keep AI at arm's length
I am not cautious about AI because I think analysts should protect every manual task. Quite the opposite. I want it doing as much of the repetitive, technical and exploratory work as it can do reliably.
The value of an analyst was never typing every formula by hand. It is knowing what problem is worth solving, whether the evidence is trustworthy, what the result means in context, and how to help people act on it.
AI makes that distinction more important. When the cost of producing analysis falls, judgement becomes the scarce part.
My rule is simple: use AI to widen the analysis, speed up the build and challenge the thinking. Do not outsource the decision.