A copilot can write the query, but it cannot tell you when a clean answer is wrong for your business. Your experienced analysts can, and that judgment is what makes AI safe to use.
So keep the people who own the definitions and give them the copilot. Do not trade them for it.
The pitch skips the hard part
The pitch is simple. A copilot writes the SQL and explains the result in plain English. Why pay a team of analysts to do the same work more slowly?
I understand the appeal. Analytics teams cost money, and request queues are long. A tool that answers in seconds looks like a clear win on a budget slide.
But writing the query was never the hard part. The hard part is knowing what the business means when it asks a question. That knowledge lives in people, not in the warehouse.
What the analyst knows that the warehouse does not
Picture an analyst who has supported the same sales team for years. A leader asks why revenue fell last month.
A copilot reads the tables and finds the drop. It writes a clean summary with a confident cause.
The analyst asks a different question first. Did something change in how we record revenue? The analyst remembers that one region moved its billing date, so revenue shifted into the next month.
Nothing fell. The number moved because a process changed.
That memory is not in any table. It is in the person who was in the room when the change happened. A copilot cannot recall a meeting it did not attend.
Often, the most useful thing an analyst knows is why a number looks strange. That context rarely gets written down. It leaves when the analyst leaves.
Judgment is the safety layer
Leaders often treat AI safety as a model problem. Pick the right vendor and add guardrails.
In analytics, most of the risk sits somewhere else. The model returns an answer that is fluent and plausible but wrong for your business. Experienced analysts catch that.
Here is what they do that a copilot cannot do on its own:
- They know what the business means by each metric, not only what the column is called.
- They know which sources are trusted, which are stale, and which are known to be broken.
- They notice when a number is too good, too round, or too sudden to be true.
- They know the history behind odd values, such as a migration, a reorg, or a pricing change.
- They ask what decision the question supports before they answer it.
- They tell a leader when the data cannot support the conclusion.
In my last post I wrote that nobody owns the metric, so the model can't either. The people best placed to own those definitions are often the analysts on the cut list.
The judgment that makes an AI answer safe is the same judgment you remove when you cut the analyst.
The cost shows up later
Cutting an experienced analyst saves money right away. The cost arrives slowly, so it is easy to miss.
- Wrong answers do not announce themselves. A chat answer looks the same whether it is right or wrong. Without someone who knows the business, nobody checks.
- Context decays next. Definitions drift because nobody defends them. New hires learn the tool but not the business, and the team slowly forgets why the numbers look the way they do.
- Then a leader makes a large decision on a confident answer that nobody questioned. That is the real bill for the savings.
Rehiring does not fix it quickly. You can hire SQL skill fast. You cannot hire years of context about your own business.
Before you cut an analyst
If you are under pressure to replace analysts with a copilot, do this work first:
- List the decisions each analyst supports today, not the reports they build.
- Ask each analyst which definitions, caveats, and data problems they carry in their head.
- Write that context down in a shared, versioned place before anyone leaves.
- Run the copilot side by side with the analyst on real questions for a few weeks.
- Have the analyst mark each answer as correct, wrong, or right for the wrong reason.
- For each wrong answer, ask who would have caught it if the analyst were gone.
- Decide based on what you learned, not on the demo.
I expect you will find two things. The copilot is fast. The analyst is the reason it is safe.
Pair the analyst with the copilot
The better question is not analyst or copilot. It is how to make your best analysts more useful with one.
Here is how I would set that up:
- Give analysts the copilot first, so they learn where it fails before anyone else uses it.
- Make analysts the owners of the definitions and certified views the copilot reads from.
- Send copilot answers on high-stakes questions to an analyst for review before they reach a leader.
- Log the questions the copilot gets wrong and treat them as work for the analyst team.
- Move analyst time from routine report building to review, teaching, and better questions.
This changes the job. The analyst does less typing and more judging. That is a better use of the person you already trust.
Keep the people who know why
The copilot will keep getting better at writing queries. It will not learn why your numbers look the way they do unless someone tells it.
Before you cut the people who know the business, ask who will tell the copilot when it is wrong. If the answer is nobody, keep the analysts.