Does BI make sense when Claude can make dashboards?

I think many BI providers are on the back foot when it comes to how quickly people can create and iterate with AI.

It’s totally natural to be dissatisfied right now with the BI landscape. If you’ve already been frustrated with the workflow in tools like Tableau or Looker, the contrast with asking Claude to make a chart can be pretty stark. The question is whether your existing tool can improve that experience quickly enough.

Caveat: I’m writing this in October 2026, and at the current pace of change, this will likely be obsolete by Jan 2027 🤷.

That means there are really two questions we’re asking:

1. In the long run, will there be a place for BI tools in my organisation?
2. In the short run, how do I respond to the reality that my team is more productive working outside the standard BI tools, which makes them look kind of useless?

In some ways, I think the long run question is easier to answer.

In the long run, will there be a place for BI tools in my organisation?

#

My view is yes. But there’s some subtlety to that answer.

• People will definitely want graphs and charts.
• People will want places where they can find consistent views of data, which they can share with others for monitoring or group decision making.
• There will need to be access control on views of data. Even in very small orgs, there’s important data and tracking, which is not suitable for everyone in that organisation - and certainly not the general public. In larger orgs, there will also be a need to restrict edit access to trusted users.
• These places cannot be static, they will need to be fed with fresh data and allow iteration and updates from groups of people.

Those bullet points I think define the space which BI tools currently occupy, and where there will still be a need even in the AI-enabled world. Generating a dashboard is one thing; running it as a reliable, shared service is another.

It’s worth being precise about “Claude dashboards” here. A shared artifact inside Claude and a standalone app written by Claude Code have different hosting, sharing and data access models. Claude artifacts already support sharing with specific people and, on Enterprise, groups. Artifacts which use connected apps can use each viewer’s own connections. So this isn’t a claim that Claude has no permissions. The question is whether your chosen setup covers the permissions, refreshes, maintenance and collaboration that your organisation actually needs.

A dashboard with one maintainer and data approved for everyone who can open it can already be a great fit. More complicated requirements need a closer look, whether the dashboard was written by an AI agent or built in a BI tool.

Where existing BI tools can still hold back analysts and data teams is in the edit loop. Point and click can feel painfully slow next to iterating on a chart with Claude. That doesn’t mean agentic authoring is impossible in those tools: Tableau’s MCP server supports publishing workbooks, for example, with version requirements and authoring features that need enabling. But the existence of an integration isn’t the same as a smooth workflow for your team.

There are also lightweight approaches like dbt charts or Observable Framework (for a live example, the SQLFluff stats page uses Observable). They make code-based iteration attractive, but with a self-hosted site you still need to arrange hosting and access control. That’s a different proposition from choosing a managed BI platform.

What I’m looking for is a BI platform which makes agentic authoring feel natural, supports version control and audit trails, and has a robust permissions model suitable for a modern enterprise. Lightdash already documents agent-driven authoring, version-controlled content and permissions. Tools like it and Superset belong on the evaluation list. I haven’t yet found an answer I’d recommend across the board; that’s different from saying nobody is building one.

In the short run, how do I respond to what’s actually happening in my org?

#

Right now we’ve got people across organisations, from execs to analysts, all using the kind of “shadow BI” that we’ve been trying to resist as a profession for years. The first thing to call out is that trying to hold back this tide isn’t much of a strategy.

If, as a data leader or analyst, you try and prevent the rest of your org from making their own graphs and charts in Claude/ChatGPT, you’re likely to push that work out of sight. There is too much momentum (and too much dissatisfaction with legacy BI tooling) for “just stop doing it” to be a useful response. Help people do it well instead.

There are a few actions we can take, but I think we should frame each in the context of the problem it’s trying to solve.

1. People making decisions on bogus numbers

#

This is the most impactful risk, and one many have tried to restrict through making BI tools “idiot proof”. Now that people are making their own charts there is no more idiot proofing. In a very positive move in my mind, we now need to set expectations that everyone is accountable for ensuring their numbers and decisions are robust.

• If you’re a data team person: you remain responsible for the shared foundations you maintain, but that doesn’t make you responsible for every interpretation someone else’s AI produces. Agree that boundary with your leadership team now.
• If you’re a business leader: set the expectation that everyone is responsible for their own AI use, including checking the analysis they produce. Team leaders and directors cannot pass the blame to a separate data team if bad numbers are used to make bad decisions - they remain accountable for the decisions their own people make (as in my view they always have been).

Beyond the conversation on accountability, make your existing BI estate searchable from your AI tooling. This could have the really positive effect of prompting people with your existing dashboards rather than them reinventing the wheel. Sure, Claude can make dashboards, but it can also find dashboards that already exist - and faster too.

2. Chart-splosion, or drowning in dashboards

#

The speed that people can make content has accelerated, and teams were already struggling to manage their backlog of old and dusty dashboards. There is a belief, which used to be somewhat true, that having more content would make it hard to find the right content. This is a case where data teams have to change their operating pattern: In a world where there is more content, the desire to have trusted & validated sources actually goes up. As data teams, we should spend less time deleting and debugging the junk, and more time curating the sources of ground truth.

Alongside that, having AI tooling which can create content, also provides an avenue to use that same tooling to remove it. Bias toward tools which track usage and age, and enforce processes that offboard content which isn’t explicitly designed to be durable once it reaches a certain age. It’s easier to recreate a throwaway chart now, but keep the definitions, queries and evidence behind important decisions. Re-running a query on changed data won’t necessarily reproduce what someone saw at the time.

3. Mistrust in existing tooling, and in existing teams

#

Your colleagues are going to start questioning why you still have legacy BI tooling, and in doing so will start to question why your team exists. Lean in:

• Acknowledge the current shortcomings in the tooling, and articulate your view of how this should work.
• If the view of your data team was that “they make charts”, you need to start rebranding. That was never really all you did, but if that’s what people think you’re for, they will also start thinking you now serve no purpose. Emphasise what your team does in making data available and trustworthy - which are only going to become even more necessary as AI use accelerates. I’ve written more about what a data team is responsible for once making dashboards stops being its defining task.
• In particular, lean on your role to champion validated sources of truth, for cross checking AI enabled work.
• If you’re being pushed to sunset existing BI tooling sooner, check what savings are actually available. If you’ve already paid for it, switching it off won’t recover that licence spend. Usage and support costs may fall sooner, but the renewal is often the bigger decision. Be open that you might not renew unless the tool can catch up.

4. Budget and procurement risk

#

If your current tooling isn’t developing fast enough, that can be a real headache for budget setting and procurement.

• Start the conversation with your existing BI tool early, and be very open that if they don’t innovate, you will likely not renew. Give them the chance to make your life easier.
• Start the conversation with your finance team early, giving them the heads up that you are reviewing the spend (and so there might be savings), but that you still think there’s a role for a platform which enforces permissions and governance (finance teams like governance). It’s unlikely that you won’t have any spend - but it’s very likely that it will look different.

What’s the takeaway?

#

We’re in a time of huge change, your team isn’t sure what to do and neither are you. That’s ok, and this is a case where it’s ok to share that. Especially with your exec team - letting them know that you’re not ignoring it - but there also isn’t consensus here yet on what’s “best”.

The biggest dissatisfaction I’m describing here is around enabling people to create. If your BI tool makes that feel slow next to Claude, its other benefits become harder to explain. That doesn’t mean those benefits have disappeared, but it does mean the tool needs to make a better case for itself.

There are some very simple organisations where Claude can be their entire BI solution. They do exist, but they tend to be small, and very flat organisations where only a few people have access to data at all, and within that group there is very little restriction.

If you’re trying this with Snowflake, I’ve written a practical guide to connecting AI agents to Snowflake without another service to run. That covers giving agents permission to query the data; hosting and sharing the dashboards they create is a separate part of the setup.

For most of the rest of us, BI isn’t gone - but it’s about to change significantly.

It’s just being a little slow in getting there.