Can AI Build Your Dashboard Yet? What Works and What Breaks

Ask any modern BI tool for a sales dashboard and you will get one in about twenty seconds.

Whether you should ship it is a completely different question, and unlike most AI questions this one has actual answers, because people have benchmarked it.

This post goes through the five things AI is doing to dashboards right now, and for each one gives the published evidence rather than the demo. Some of it works better than the marketing suggests. Most of it works worse.

Who This Is For

• Analytics leads deciding which AI features to turn on and which to disable
• Founders being sold an AI BI platform and wondering what is real
• BI developers who have watched a copilot produce a confidently wrong chart
• Consultants who have to defend a recommendation to a client

What You Will Need

Nothing to install. But to judge any of this honestly you need three things in place first, and they are the same three that made dashboards work before AI:

• a semantic layer so metrics mean one thing (see semantic layers for trustworthy dashboards)
• a governed query path so generated SQL cannot go anywhere it should not (see text-to-SQL without a BI team)
• an evaluation set of questions with known-correct answers

Without the third one, every claim below — mine and the vendors’ — is unfalsifiable on your data.

The Pattern

The five trends are variations on one shift: the model moves from drawing the dashboard to deciding what the dashboard says.

flowchart TD
  Q[Question or metric] --> G[Model proposes]
  G --> S{What kind of claim?}
  S -->|Layout or chart| D[Design rules can check it]
  S -->|Narrative or cause| H[Only a human can check it]
  S -->|Forecast| E[Backtest can check it]
  D --> R[Ship with review]
  E --> R
  H --> V[Ship only with a named owner]

That split is the whole post. Where a machine can verify the output, adopt it now. Where verification requires knowing the business, keep a person’s name on it. The trends below sort cleanly into those two buckets, and the industry has been sorting itself the same way over the last twelve months.

1. Generating the Dashboard From a Prompt

Generation is the trend with the loudest marketing and the clearest evidence.

The capability is real. Open-source projects will take a sentence and hand you a running data app in a sandbox, and every serious framework now ships documentation written for models rather than humans — agent skills, cheatsheets, llms.txt files. Generating a dashboard is a solved problem.

Correctness is not. The most useful number in this whole field comes from VisEval, a Microsoft Research benchmark published at IEEE VIS: across 2,524 queries over 146 databases, GPT-4 passed 75.27% — and 21.44% of its outputs were “illegal”. Illegal does not mean it crashed. It means the code ran, a chart appeared, and the chart used the wrong type, mapped a field to the wrong channel, sorted incorrectly, or dropped the legend. It looked finished and it was wrong.

Then there is ambiguity. The nvBench 2.0 benchmark makes the point that a real dashboard question usually has several correct answers: “show me sales by region” could reasonably be a bar chart, a map, or a small-multiples trend. GPT-4o scored 58.96% on ambiguous queries. The model resolves the ambiguity silently, and you never see the choice it made on your behalf.

The most instructive evidence is not a benchmark at all. McKinsey built a prompt-to-dashboard library, shipped it, and then discontinued it. Vizro’s dashboard generation is no longer actively developed; it was superseded by an MCP server that hands a coding agent tools and templates and lets the agent write the app. Microsoft’s Data Formulator, the one high-star LLM visualisation project that survived the cycle, survived by making the same move — away from one-shot generation and toward iterative, branchable workflows where you can compare paths and see the trail.

There is also a gap between what the category is sold on and what the largest vendors actually ship. Tableau’s agent explicitly cannot build a dashboard. Looker’s conversational analytics cannot create Looks or dashboards either. Two of the three biggest names in BI do not offer the headline capability, which is worth knowing before you sit through a demo that implies otherwise.

The pattern across Rill, Lightdash, Evidence, Cube and Gradio is identical: stop building a chat window into the tool, start shipping MCP servers and agent skills so the tool becomes a well-documented target. Which is exactly the architecture agentic dashboards with MCP describes.

Verdict: adopt for drafts, never for delivery. A generated dashboard is a starting point that costs twenty seconds instead of an afternoon. That is genuinely valuable. Treating it as output is how a wrong encoding reaches an executive.

2. Automated Data Storytelling

The pitch is that the dashboard writes its own executive summary and explains what moved and why.

Start with a fact that should give everyone pause. Tableau shipped a narrative feature built on Narrative Science, the company that invented commercial natural-language generation. It was deterministic: it computed statements from the data and could not invent one. Tableau retired it in January 2025 and replaced it with an LLM-based summary. The technology that could not hallucinate was withdrawn in favour of one that can, and the stated reason was advances in natural language technology.

Whether that was the right trade depends entirely on which half of the job you are asking the model to do.

Describing what a chart shows is safe. Computing that revenue fell 12% week on week and writing that sentence is arithmetic with a nice voice on top.

Explaining why is not. It requires knowing things that are not in the data: that marketing ran a promotion, that a supplier changed, that the tracking script broke on Tuesday. And the research on whether language models can bridge that gap is unusually blunt. On a 200,000-sample benchmark for inferring causation from correlation, seventeen models scored close to random. A separate paper puts it plainly: models recite the causal knowledge in their training data rather than reasoning about mechanism.

Vendors are inconsistent about mentioning this, and the inconsistency is more revealing than silence would be.

Tableau’s older Explain Data feature carries one of the clearest warnings I have seen shipped in a product. It tells you plainly that correlation is not causation, that explanations “are not causal explanations”, and that when two variables move together “the data patterns are exactly the same” whether A causes B, B causes A, or a third factor drives both — and an algorithm cannot tell the difference.

That warning does not appear on the newer, AI-powered driver insights in the same vendor’s own product. And a competitor’s equivalent feature opens its documentation by promising you can “discover the cause with just a few clicks”, with no qualification anywhere. A third promises summaries that tell users “not just what happened, but why”.

The caveat existed. It got quieter as the feature got smarter.

The documented failure

Uber published the case that makes this concrete. A fare component went missing from a critical dataset for 10% of sessions across key US cities. The cause was not a crash or a market shift: an app experiment started logging fares differently. It was found after 45 days, manually, by a data scientist, and Uber estimates the modelling impact at millions of dollars.

Their own diagnosis is the line worth keeping:

“Data regressions are hard to catch because the most impactful ones are generally silent. They do not impact metrics and ML models in an obvious way until someone notices something is off… But by that time, bad decisions are already made.”

Uber measured that these silent corruptions take five times longer to detect than pipelines that simply fail. And one detail should worry anyone running auto-insights: the drift was invisible in the overall column statistics and only appeared when the data was cut by city, app version and device OS. The broken slice is precisely the slice an auto-insight engine surfaces as your top driver.

Why the narrative is more dangerous than the chart

Two findings from human-computer interaction research explain why this is worse than it sounds.

The first: a CHI 2021 study found that AI explanations did not improve accuracy at all. What they did was increase the chance that people accepted the recommendation regardless of whether it was correct. The explanation buys compliance, not correctness.

The second is more specific to dashboards. Research on titles and charts found that readers’ recall of a visualisation’s message aligned more often with the title than with the visualisation, while they continued to perceive the chart itself as impartial. Put a wrong sentence above a right chart and the reader remembers the sentence, and trusts it more for having come with a picture.

But the fix is not less text

This is where the honest answer diverges from the easy one. A 302-participant study found that heavily annotated charts were not penalised — participants preferred the charts with the most textual annotation over sparser ones or text alone. Readers want the words. Removing them makes dashboards worse.

So the rule is not “no narrative”. It is narrate the facts you computed, never assert a cause you cannot verify.

That happens to be the architecture the more careful vendors reached independently: classical statistics compute the numbers, and the language model only puts them into sentences. Tableau documents this explicitly for Pulse — the model “doesn’t analyze your data”, it “draws upon pre-calculated insights that are rooted in statistical analysis”. The oldest natural-language-generation vendor in the market splits the job the same way, sending numbers through a deterministic engine and using the LLM only for non-numerical content.

It is a meaningfully safer design than pointing a model at a chart and asking what it means, and it is worth asking any vendor which of the two they are doing.

One more design idea worth stealing: at least one vendor now runs data-quality anomalies through the same detection surface as business anomalies, so a missing-value spike and a revenue spike arrive in the same place. That is the structural answer to Uber’s problem — the pipeline bug and the business event compete for the same alert, instead of the bug quietly wearing the business event’s clothes.

Verdict: adopt for description, reject for causation. And if you add the friction that makes people check — a warning, a click-through to reveal the answer — expect it to work and expect users to dislike it. Research on cognitive forcing found exactly that: the designs that reduced overreliance the most were the ones people rated worst.

3. Forecasting and Forward-Looking Metrics

Here is the good news, and it is genuinely good.

Forecasting is the one part of the AI dashboard stack that works, is cheap, and carries no licensing trap. Classical statistical forecasting runs on a CPU in milliseconds and is interpretable enough to explain to a finance director. Time-series foundation models now forecast series they were never trained on, which matters when you have ten thousand SKUs and no history per SKU.

And unusually for this field, every practical library is Apache-2.0 or MIT. No Business Source License, no “free for non-commercial”, no seat pricing. You can put forecasting into a client system without a procurement conversation.

Two cautions worth carrying:

Use a real benchmark, not the vendor’s. GIFT-Eval covers seven domains and multiple frequencies with a non-leaking pretraining set, and since late 2025 it marks which claimed results are actually reproducible. Every foundation model claims to beat everything; the leaderboard is where that gets tested.

Know which engine you are actually calling. A widely used forecasting library entered maintenance mode on 1 August 2026 while still sitting inside two major warehouses’ default forecast functions. One of those functions quietly changed engine between versions, moving to an unnamed foundation model. The SQL you write looks identical either way. If a forecast feeds a decision, pin the version and keep the backtest, because the thing behind the function call is not guaranteed to be the thing you evaluated.

Forecast the metric, not the business. A model extrapolating your revenue series has no idea you are about to lose a customer that is 30% of it. Forecasts are a baseline expectation to detect deviation against, which is what makes them genuinely useful for alerting — the pattern in dashboards that trigger actions.

Verdict: adopt now. Start with a fast statistical model, keep the backtest visible next to the forecast, and only reach for a foundation model when you have thousands of series and no per-series history.

4. Role-Based Personalisation

The pitch is reasonable: a warehouse manager and a CFO should not see the same fourteen tiles, and cognitive overload is a real cause of dashboards going unread.

Two things to keep straight.

Personalisation is not security. Row-level and object-level security decide what someone is allowed to see. Personalisation decides what they are shown first. If you implement the second and call it the first, you have built a dashboard that hides numbers without enforcing anything.

The governance risk is quiet. When everyone sees a different view, “the number” stops being a shared object, and two people can walk out of a meeting with different figures and no idea they disagreed. The mitigation is not less personalisation — it is that every personalised view resolves to the same metric definitions underneath, which is the semantic layer’s job again.

There is a concrete version of this problem in Power BI today. Models configured with object-level security are not supported by Smart Narrative visuals, so the moment you restrict a column, the AI narrative stops working with it. And the “test as role” feature does not validate Copilot — the tool you would reach for to check what a restricted user sees cannot check what the AI shows them.

Read that twice if you are responsible for who sees what. The verification tool does not cover the surface most likely to leak, which means the check has to be manual, per role, and repeated whenever the model changes.

Verdict: adopt for layout, be careful with content. Reorder and hide tiles by role. Do not let the model decide which numbers a role does not need to know.

5. Cognitive and Perceptual Chart Selection

The most interesting evidence, and the most counter-intuitive answer.

There is real science here. Cleveland and McGill established decades ago that people read position on a common scale more accurately than length, angle, area or colour. That ranking should drive chart choice, and mostly it does not — defaults do.

So can a model apply it? DracoGPT, a University of Washington study at IEEE VIS, tested exactly that and found model design preferences “substantially diverge from guidelines drawn from human subjects experiments”. Worse, models aligned with perceptual findings for comparing individual values but not for aggregate summary tasks — which is what a business dashboard almost always does.

A 2026 follow-up translated formal design constraints into natural language and asked models to spot violations: F1 up to 0.82 on obvious mistakes, below 0.15 on perceptual subtleties. Models catch the errors you would already catch.

The best result in this area is the most deflating. A 2026 study found Gemini 3 scoring 93.68% on a standard visualisation literacy test, beating the human baseline — while the same models hallucinated thousands of misleading elements that were not present in the charts, and flagged phantom problems in charts that had already been corrected. They read charts better than we do. They cannot tell you whether one is honest.

What actually works is older and less glamorous: encode the design rules as constraints and solve them. Draco does this — visualisation design knowledge as a constraint program, with weights learned from graphical-perception experiments rather than hand-tuned. It is a small, actively maintained, MIT-licensed project, and the research consensus in 2025–26 has been to put it in the loop: let the model handle language and orchestration, and let the solver choose the encoding.

Verdict: do not let the model choose the encoding. Give it a constrained set of chart types that are already correct for your data shapes, and let it pick from that. The model is good at language and orchestration; the solver is good at design. Keep the jobs separate.

The Part Nobody Sells You

A trends post that stops here would be dishonest, because the loudest question in analytics right now is whether the dashboard is the right artefact at all.

The case against is real. Dashboards go unread. They accumulate, nobody deletes them, and the ones that survive are often maintained out of habit. The case that AI fixes this is weak: generating dashboards faster mostly produces more unread dashboards, and personalisation produces more variants of them.

But the replacement story is weaker still. Microsoft’s own Fabric data agent caps answers at 25 rows by 25 columns. On DashboardQA — a benchmark of 112 real dashboards where agents must filter, drill and navigate — the best agent managed 38.69%. Hex’s DataBench found agents scoring 75% on question answering but 54% on tasks containing a trap. They answer questions well and exercise judgement badly.

The honest reading is that chat is not replacing the dashboard; the semantic layer is replacing the dashboard as the thing you build first. Databricks now argues the semantic layer, not the dashboard, is the primary artefact. Snowflake improved text-to-SQL accuracy from 57% to 78% by having agents refine the semantic model rather than the prompt. Define the metric once, and the dashboard becomes one of several ways to render it, alongside chat, alerts and agents.

Whether the dashboard still earns its place at all, and what the evidence for that actually is, gets its own treatment in do you still need a dashboard.

Benn Stancil put the underlying reason better than anyone: software is self-validating, in that if it runs it probably works. Analysis is not. Verifying a chart requires reconstructing how it was built — which is precisely the work generation was supposed to save.

Before and After

Before	After
Building a dashboard starts with a blank canvas	It starts from a generated draft you correct
Chart type comes from the tool’s default	It comes from a constrained set that fits the data shape
The summary is written by whoever presents it	The model drafts it and a named person owns it
Forecasting is a separate data-science project	A forecast baseline sits next to the actual, with its backtest visible
The dashboard is the deliverable	The metric definition is the deliverable; the dashboard renders it
Everyone sees the same fourteen tiles	Layout adapts by role, resolving to the same definitions

Failure Modes to Avoid

• Treating “it rendered” as “it’s right.” A fifth of a strong model’s rendered charts were structurally wrong in benchmark conditions. Rendering is not validation.
• Letting a narrative assert causes. The model does not know about your promotion, your outage, or your broken tracking script, and it will explain the spike anyway.
• Buying a foundation forecasting model before trying a statistical one. The cheap option runs on a CPU, is interpretable, and often wins.
• Confusing personalisation with permissions. Hiding a tile is not access control.
• Skipping the eval set. Without questions whose answers you already know, you cannot tell an improvement from a regression.
• Choosing tools on star counts. Three of the most-cited “LLM makes charts” projects are abandoned, and the largest open-source BI tool by stars still has no AI features at all. Last-commit date and licence file are the leading indicators; stars are a lagging one.
• Generating more of what nobody reads. If a dashboard was unread before, an AI-generated version of it is an unread dashboard that took less effort to produce.

What to Build First

1. Write twenty real questions with known-correct answers. This is your eval set and everything else is measured against it.
2. Fix the semantic layer before turning on any AI feature. Every accuracy gain in the published research came from improving the model of the business, not the model.
3. Turn on generation for drafts only, and require a human to approve the encoding before anything is shared.
4. Add a forecast to one metric that already has an alert, with the backtest visible beside it.
5. Add narrative last, restricted to description, with an owner’s name on the page.
6. Instrument whatever you switched on. AI features in a BI stack are agents, and they need the same run, failure and latency visibility as any other — see monitoring dashboards for AI agents.
7. Delete the dashboards nobody opened this quarter. This is the highest-value item on the list and it involves no AI at all.

Final Take

So can AI build your dashboard yet?

It can build the draft, and that is worth having. It can forecast the metric, and that works today. It can describe what a chart shows, accurately and quickly.

It cannot reliably choose the encoding, it cannot know why a number moved, and it cannot tell you whether the chart in front of it is honest. Those are the three jobs that made dashboard work hard in the first place.

The teams getting value are not the ones generating the most dashboards. They are the ones who fixed their metric definitions, then let the machine render them a dozen different ways.