My feed has split into two camps on Claude dashboards. One says BI is dead. The other says an LLM writing fresh SQL on every load is a governance nightmare waiting to happen.

Both are wrong, and the second camp is closer. The worries are real, but they’re not about Claude. They’re about teams that never wrote their metric definitions down. Claude just makes that impossible to hide.

"Will the numbers be the same every time?"

Only if you build it that way. And you should.

The fear goes like this: you ask for monthly active users on Monday, Claude writes one query. You ask again on Thursday, it writes a slightly different one, filters out test accounts this time, and the number moves by 4%. Nobody notices until the board deck.

That failure is real, but it comes from a design choice, not from the model. If a dashboard regenerates its SQL on every load, you’ve built a slot machine. The fix is boring:

  • Generate once, then freeze. Let Claude write and explain the query, a human reviews it, and the dashboard runs that exact query from then on.
  • Version the query like code. A definition change should be a diff someone approves, not a side effect of rephrasing a prompt.
  • Show the SQL. Every tile should let you see what it ran. If you can’t inspect it, don’t trust it.

Use Claude where it’s strongest: authoring and explaining. Execution should be deterministic. That’s how good analysts already work; Claude just makes the first draft faster.

"You still need a semantic layer"

Yes. That’s the whole point, not an objection.

Ask Claude what “revenue” means against a raw warehouse and it will guess: gross or net, with or without refunds, booked or recognised. It will often guess well. “Often” is not a standard you’d accept from a junior analyst either.

A semantic layer (dbt metrics, Cube, LookML, whatever you already have) turns that guess into a lookup. Claude stops inventing definitions and starts composing governed ones. That is a much easier job, and it’s the one LLMs are reliably good at.

So the semantic layer isn’t made obsolete by Claude. It becomes the most valuable thing in your stack, because it’s the contract the model reads. The teams that skipped it to “move fast” are the ones who’ll get burned first.

If you don’t have one, start small: write down your ten most-argued-about metrics, with owner, SQL and edge cases. That file alone will improve Claude’s answers more than any prompt tweak.

Where they win, and where they don't

Claude dashboards are excellent for the long tail: the question a product manager has on Tuesday that would otherwise sit in a ticket queue for two weeks. They’re great for exploring, prototyping a view before it’s productionised, and explaining why a number moved.

They’re the wrong tool for anything audited or contractual. Finance close, regulatory reporting and the KPIs bonuses are paid on belong in a governed, frozen pipeline with an owner. You can still use Claude to build that pipeline. Just don’t let it improvise the answer on the day it matters.

Bottom line

Claude doesn’t create your data governance problem. It exposes it, fast and in public. That’s a feature.

Before you roll out Claude dashboards, check four things:

  1. Your core metrics are defined in one place Claude can read.
  2. Production tiles run frozen, versioned queries, not fresh generations.
  3. Every number shows the SQL behind it.
  4. Each key metric has a named human owner.

Get those right and the LinkedIn worries mostly go away. Skip them and no BI tool, AI or otherwise, was going to save you.