An analyst’s AI stack has four slots, not ten tools: a chat model to reason over a sample of the data, a copilot inside the tool where the work already lives, a code assistant for the automation layer, and a transcription tool that turns talk into text. A tool earns its slot only when checking its output is faster than doing the work by hand. Defining the metric stayed manual.
Last updated 4 September 2026 · by Inam Ul Haq, data analyst and automation engineer · about the author
Every list of AI tools for data analysts is ranked the same way. Ten products, a feature line each, a use case tag. None of them answer the question you actually have, which is not what exists but what any of it took off your desk, and what it quietly added back.
So this is the stack I run as a working analyst, written as a ledger. Four slots, what sits in each one, what it evicted, what it did not, and the cost every one of them charges in checking time. The tools change every few months. The slots have not changed since I started.
A tool that answers in four seconds and takes twenty minutes to verify has not saved you anything. It has moved the work somewhere you trust less.
Why does a stack have four slots instead of ten tools?
Because an analyst’s week only has four places where a machine can stand. There is the thinking you do against a sample of data, the building you do inside Excel or Power BI, the code that runs when you are not there, and the talking that has to become writing. Everything marketed at analysts fits into one of those four.
Once you see it as slots, the buying decision changes. A new tool does not get added, it has to evict the one already in its slot, and eviction means beating the incumbent on the same job with the same data. That one rule has kept my stack small while the market added a product a week.
| Slot | What I run in it | What it genuinely replaced | What it did not replace |
|---|---|---|---|
| Reason over a sample | A chat model with the data pasted or uploaded | Searching forums for how to approach a shape of data | Any access to your live systems |
| Inside the tool | The copilot in Excel or Power BI | Looking up syntax for a formula or a measure | Reading a sheet humans laid out for humans |
| The code layer | A chat model drafting Python and M | The blank file, and the first hour of boilerplate | Knowing which edge case will break it |
| Talk into text | Transcription, then a model to structure it | Retyping a call into notes nobody reads again | Deciding which requests in the call were real |
| Not a slot | Autonomous insight generators | Nothing I have been able to measure | The question worth asking in the first place |
The last row matters more than the other four. Tools that promise to find the insight for you are selling the one step that was never the bottleneck. Finding a correlation is cheap. Knowing which of them a person will act on this quarter is the job, and nothing has been near it.
What does the chat model actually replace?
It replaces the part of the work where you do not yet know how to approach the data. You paste in twenty rows and the column names, describe what the business wants, and argue about the shape before you build anything. That is thinking out loud with something that has read more schemas than you have.
Concretely, four jobs a week. Explaining a formula somebody else wrote, drafting the regex nobody enjoys writing, listing the ways a join could produce duplicate rows, and turning a finished analysis into three sentences a manager can repeat. That last one is the same craft as turning data into a story, and the model is genuinely good at the first draft of it.
The limit is the one the product pages skip. OpenAI’s own data analysis documentation states that the Python environment cannot make external web requests or API calls, and that you should upload the data or connect a supported source instead. The sandbox is real, but it is a room you carry files into. Pointing it at your warehouse is not what this slot does.
Is the copilot inside Power BI or Excel worth it?
Inside Excel, yes, for one narrow thing. Writing the formula whose logic you already know but whose syntax you do not. That is the verify-first habit I wrote about in asking AI for Excel formulas, and it holds here. The formula arrives instantly and you still check it against a row you calculated by hand.
Where it disappoints is the sheet you most wanted help with. Copilots want a clean rectangle with one header row, and the file a client sends has merged title cells, a blank row under the header and three tables on one tab. The tool is least useful exactly where cleaning messy Excel data is hardest, which is the reverse of the order the roundups imply, and the Claude add-in carries a harder limit of its own that I set out in what Claude in Excel can and cannot read in a workbook.
Power BI carries a bigger condition, and it is a licensing one that tools lists leave out. Microsoft’s documentation for enabling Copilot in Power BI states that the workspace must be on Premium capacity (P1 and above) or paid Fabric capacity (F2 and above), and that trial SKUs are not supported. A Pro licence on its own does not get you the feature.
That single fact reorders the comparison for most readers. If you are a freelancer or a small team on Pro licences, the Power BI copilot is not in your stack however well it reviews, and slot two is Excel plus the chat model. Knowing it before you evaluate saves an afternoon.
One thing in this slot has changed since I first wrote it, and it has a date on it. Microsoft is retiring the =COPILOT() worksheet function on 14 September 2026, so the version of this you could type straight into a cell is going and the side pane is what remains. If you have a workbook with that formula in it, what happens to a workbook that already uses =COPILOT() walks through the audit to run before the date. It does not change the slot itself, because the copilot was always most useful for syntax whose logic you already know, and that is still where it earns its place.
| The task | How it goes | What I still do myself |
|---|---|---|
| Write a formula whose logic I know | Reliable, fast, worth the slot | Check it on one row I calculated by hand |
| Explain a formula I inherited | Good, and it names the edge cases | Confirm against the data, not the description |
| Summarise a clean table | Fine, and rarely wrong | Decide whether the summary is the point |
| Read a human-formatted sheet | Poor, and confidently so | Flatten it to one header row first |
| Draft a measure or a page layout | A usable starting point | Fix the filter context and the totals |
How do you tell a tool that saves time from one that moves it?
Net time is what the tool saved, minus what it cost to check, minus what it cost to fix whatever got past the check. Every roundup reports the first number. The second decides whether a tool is still in your stack in month three.
So I run three questions against anything new. Can I check the output faster than I could have produced it? Does it fail loudly rather than quietly? Does it leave a trace I can hand to someone else? A tool that fails all three is not a tool, it is a source of the silent errors that reach the final report.
- 01Cheap to check beats cleverA formula I can test on one row costs seconds to verify. A rewritten dataset with no record of what changed costs an afternoon. I will take the less impressive tool with the cheaper check every time.
- 02Loud failure beats a plausible answerA tool that stops and names the missing column is safer than one that guesses a mapping and continues. Plausible but wrong is the expensive failure, because nobody goes looking for it.
- 03A trace beats a resultIf the output is a query, a script or a list of steps, I can read it, keep it and run it again next month. If the output is only a number in a chat window, I have to trust the same tool again next month.
- Give a new tool one recurring job for two weeks, then compare it against how you did that job before
- Keep the prompt that worked in the same folder as the file it worked on
- Let AI write the thing you can test, and test it on data where you already know the answer
- Drop a tool the month it stops earning its slot, even if the subscription runs to the year end
- × Add a tool because it is new, without asking which incumbent it evicts
- × Trust a summary of a file you have not opened yourself
- × Paste client data into a tool whose retention terms you have not read
- × Count the time saved without counting the time spent checking
Where does AI written code belong in an analyst’s week?
In the automation layer, and nowhere near a number a client reads without review. A model drafts the script that collects the exports, renames them and writes one clean file, and drafting is most of the typing. What it cannot do is know which of your real files breaks it.
The division that works for me: AI writes the draft, I own the failure mode. I add the column check, the loud stop, the log line and the archive step myself, because those come from having watched this particular data misbehave. It is the same lowest-tier-that-survives rule as choosing between Power Query and Python for a job.
If you cannot yet read what the model writes, that is the gap to close before adding anything else to your stack, and learning enough Python with AI beside you is a faster route than it was three years ago. Reading the code is what turns this slot from a gamble into a tool.
What has AI not taken off the desk?
The two steps at each end of the pipeline, and they are the ones that decide whether the number is right. At the front, defining the metric and choosing the grain. At the back, reconciling to the source of truth and explaining to a person why their number changed.
Nothing in my stack can tell me whether an active customer means one order in ninety days or one in a year, because that is a decision somebody in the business has to own. Nor can it settle whether a number belongs at daily or monthly grain, which is the choice that quietly determines every total downstream.
At the other end, reconciling stays manual because the source of truth is a person’s system and a person’s expectation. When finance says the total is wrong, the work is finding which of you changed a filter, and that is a conversation held over two screens. The transcription slot helps me capture it. It does not have it for me.
That is also the honest career answer. The middle band got much faster, so an analyst now gets judged on the ends: framing the question and standing behind the answer. If you want the full setup I use to run all four slots as one system, prompts and folder structure included, that is Build Your Own AI Operating System, and the free short version is the article it grew out of.
Four slots, then. A chat model for reasoning against a sample, a copilot inside the tool for syntax whose logic you already know, a code assistant for the automation layer whose failure modes you still own, and transcription so a call becomes text before anyone forgets it. Everything else is a candidate that has to evict one of them.
Run the two week test before you subscribe to anything: one recurring job, measured against how you did it before, with the checking time counted honestly. Most tools fail that test, and the ones that pass tend to stay for years. If you want a second opinion on your own stack, or a build that fits it, start a project and tell me what your week actually looks like. The slots are the stack. The logos in them are temporary.