The Role of the Analyst: The Case for Analysts in a World Full of AI

TLDR/key takeaways:

• The future of BI analysts is a shift in effort: less time building dashboards and more time defining data products, validating AI output, and finding root causes.
• With AI tools such as Claude Dashboards building dashboards in minutes, analyst effort moves toward the data products that dashboards and AI agents depend on.
• Analysts are best positioned to sign off on AI-built dashboards and to write agent instructions, because they know both the semantic layer and the business rules behind each number.
• Dashboards and AI both require AI-ready data, and the lead analyst is usually the person who knows whether that data is ready.

If anyone can build a dashboard, what is the analyst for?

Business intelligence as we know it is changing. Nearly every day there’s a new LinkedIn post or headline about “headless this,” “MCP that,” or a vibe-coded HTML dashboard. It’s easy to get swept up in what’s new and lose sight of the practical impact on your business. That makes the future of BI analysts a fair question, and it’s the one this post sets out to answer.

This is the third post in a series about the point of view you can bring to BI while it changes faster than anyone can keep up. The first made the case that dashboards aren’t dead. The second covered when to use dashboards vs AI agents. This one takes on the role of the analyst.

Since then, in October 2026, Anthropic launched Claude Dashboards, which generates dashboards from connected data and refreshes them as the data changes. That reinforces the first post’s argument: dashboards aren’t going anywhere. They’re getting quicker to build and becoming a natural part of agentic analytics. So the next question is obvious. If anyone can build a dashboard, and development time drops from weeks to minutes, what role do analysts play?

The future of BI analysts is a shift in effort

The short answer: your analysts finally get to be analysts again. At the start of the self-service analytics era, analysts did investigative work, finding problems in the business through data and communicating what they found. Somewhere along the way, self-service analytics became IT-service analytics, complete with dashboard queues. If your analytics team exists to build dashboards and close tickets, they aren’t truly analysts. They’re analytics developers.

As AI takes on more of the build work, the effort shifts, and the expertise shifts with it. The three kinds of expertise an analyst always needed stay the same: data, reporting, and business communication. What changes is how much of the week each one gets.

Data expertise: building data products for humans and AI

Less time building visualizations and more reliance on agents means more effort goes into analysis-ready data assets. The traditional path had analysts create data sources in a BI tool so other people could build dashboards on top of them. Now those assets have to be ready for both humans and AI across the entire analytics stack.

I call these assets data products. A data product is data that has been transformed and enriched with metadata so that both people and AI can use it. (Our post on data mesh vs centralized data teams covers how they fit a domain-owned model.) In practice, a data product combines gold-layer views, warehouse-sourced semantic models such as Snowflake semantic views, and BI-tool-specific data sources. Because analytics now show up in so many places and formats, analysts can no longer rely on BI-tool-specific data sources alone. They need to define and enrich data products at several layers of the data-to-insight journey.

One example is Tableau Knowledge, generally available since September 2026 in Tableau Cloud+ and Tableau+. It builds knowledge graphs from your existing Tableau assets, and subject-matter experts can add business context that Tableau Agent and other AI agents connected through MCP use when answering questions. Managing systems like Tableau Knowledge is going to be an important analyst skill. For a hands-on example of adding business context in the BI layer, see bringing semantics to business intelligence.

Notice where analysts still fit in the data process. I wouldn’t place them early, setting up integrations, or even through most of a medallion architecture. They still sit at the gold layer. But they should take a stronger role in defining semantics and structuring gold-layer definitions, based on what they know about how the results will be surfaced. The answer is still data engineer plus analyst, working from a shared data strategy.

BI and agentic reporting expertise: why analysts sign off on what AI builds

Why not combine the data engineer and analyst roles? Because the end goal of a data product is reporting, and the analyst group usually has the most reporting experience. Analysts already know their BI tools: each tool’s strengths and weaknesses, how it handles different data structures, how to optimize for performance, and how to troubleshoot errors as they appear. Adding reporting to a data engineer’s plate also adds work to a bandwidth that is most likely already bursting at the seams.

Why not replace analysts with business users? Not every business user speaks data, and not every data engineer speaks business. And an AI that can build a dashboard in minutes won’t always build one that’s correct or performant.

Imagine one of your sales reps vibe-codes a dashboard and hits an error or wildly inaccurate numbers. Will they know how to troubleshoot it? More likely, they’ll prompt back and forth until the AI returns a number that seems reasonable. What they won’t realize is that they’ve bullied the AI into using the wrong fields, or ignoring a rule that should have applied, just to get numbers that felt right. In the 2026 State of Analytics Engineering report from dbt Labs, 71% of data professionals cited incorrect or hallucinated outputs reaching stakeholders as a top concern. Analysts are best positioned to review what gets built and sign off that a dashboard shows what it should.

The primary new function here is agentic reporting, and reliable agent reporting depends on a deep understanding of the data behind the agent. In other words, the data products. Paired with integration teams or data engineers for the technical setup, the analyst is the person best placed to write agent instructions grounded in the semantic layer and the business, because the dashboards are built on that same semantic layer. That’s the core of modern Tableau consulting work, too.

Business communication expertise: finding the root cause

At the root of a good analyst is a deep understanding of business processes and the ability to explain technical findings in less technical terms. To analyze means to examine something carefully and methodically, breaking it into its parts to find the root cause. AI should now be the start of that process. Analysts review the findings and keep going until the true nature of the data is clear. AI didn’t remove the need for analysts. It’s making them faster at finding the root cause.

Knowledge is ultimately a collection of facts. Intelligence is the ability to hold that knowledge, take meaning from it, and act on it. If Tableau Knowledge and similar tools are where knowledge is stored, the analyst is where the intelligence is stored.

Put the three kinds of expertise together and the role looks less like a developer working a queue and more like what we call an analytics curator: someone who defines a data product, governs how it’s used, puts it to work in the decisions it supports, and measures whether it changed anything.

AI, dashboards, and analysts all depend on AI-ready data

Data expertise, reporting expertise, and business communication expertise. You may be thinking that’s what an analyst does. You’re right. It’s a shift in effort, not a complete career change.

For the last 10-plus years, BI analysts could hold a fairly niche position as experts in one or two BI tools. The growing need to define data products for LLMs and business users has pushed them back toward what an analyst was supposed to be in the first place: data and business experts who know how to define data requirements for reporting, turn data into visualizations, investigate data from a business perspective, and hold the institutional knowledge that comes from years of working with end users.

To wrap up the series, at the risk of sounding like AI myself: the answer isn’t AI or dashboards, and it isn’t AI or analysts. It’s AI and dashboards and analysts.

You may also have noticed that every post in this series comes back to data. Analysts need to define good data products. Dashboards and AI both need well-structured data, wherever you use them. If your data isn’t ready, AI won’t be ready either. That gap is common. A Gartner survey of 1,203 data management leaders found that 63% of organizations either don’t have, or are unsure if they have, the right data management practices for AI. In the same release, Gartner predicted that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data.

Frequently asked questions

What is the future of BI analysts?

The future of BI analysts is a shift in effort toward data products, AI oversight, and root-cause analysis. As AI tools build dashboards in minutes, analysts spend less time in the dashboard queue and more time defining the data that dashboards and agents use, validating AI output, and explaining findings to the business.

Will AI replace BI analysts?

AI is taking over much of the dashboard build work, but it can’t confirm that a dashboard uses the right fields and business rules. Analysts are best placed to validate AI-built reporting and to carry an investigation from the first AI answer to the root cause.

What is a data product in analytics?

A data product is data that has been transformed and enriched with metadata so both people and AI can use it. It typically combines gold-layer views, semantic models in the data warehouse, and BI-tool data sources, all sharing the same business definitions.