Let AI build the dashboard; make finance define what it means

Dashboard construction is becoming the cheap part

Microsoft's preview Power BI agent stack can gather requirements, inspect a semantic model, lock a report brief, author schema-correct PBIR files, validate the report, reload Power BI Desktop, capture screenshots, and publish to Fabric after approval. That compresses work that used to require repeated manual editing. It does not remove the finance judgment that makes the report trustworthy.

A current r/FPandA discussion captures the transition. One practitioner said AI had made hard-won dashboard-building skills feel less valuable. The strongest responses did not deny the automation. They moved the value upstream to defining what should be measured and downstream to reconciling the numbers, explaining the strategy, and telling a decision-useful story. That is the right operating model.

Microsoft's own architecture points in the same direction. The Report Planner uses a Define → Inspect → Brief → Approve sequence before building. The Report Authoring skill edits the report layer. A Modeling MCP server handles tables, relationships, measures, and DAX. A Desktop Bridge reloads the current files and captures visual evidence. Each layer solves a different problem; none certifies the financial meaning on behalf of FP&A.

The Excel COPILOT worksheet function offers a useful boundary. Microsoft says it will retire the function on September 14, 2026 while keeping the broader Copilot in Excel experience. Practitioners objected to putting nondeterministic generated outputs directly into spreadsheet cells used for repeatable work. AI is useful for planning, drafting, classification, and explanation; financial control calculations should remain deterministic, traceable, and re-performable.

Separate meaning, construction, evidence, and release

Store a baseline before agent edits. Microsoft warns that PBIR files are the source of truth for the authoring skill and that unsaved Desktop changes are not included. A finance team should extend that warning: preserve the baseline commit or archive, classify every diff, and stop if the agent changes relationships, measures, security, data sources, or publishing targets beyond the approved brief.

Semantic-model readiness is a separate gate. Microsoft's Prep data for AI guidance uses AI data schemas, instructions, and verified answers to reduce ambiguity. Verified answers are human-approved visuals triggered by matching questions. They improve consistency, but they must be built on measures and filters finance has already approved. A verified answer can consistently return the wrong definition if the metric contract is wrong.

A KPI contract must survive a tool change

“Gross margin,” “active customer,” “headcount,” and “forecast variance” look like labels. In practice they hide policy. Which ledger accounts count? Is freight included? Which currency rate applies? Is the period fiscal or calendar? Are eliminations included? Does a customer count require revenue, an active contract, or any login? AI cannot resolve those choices from a polished chart title.

The contract should be tool-independent. If the team moves from Power BI to another reporting layer, the definition, lineage, owner, and acceptance test remain. The agent can transform the contract into report objects, but it cannot silently rewrite the business policy.

Worked example: the chart is right and the decision is wrong

An agent builds a gross-margin dashboard showing a 220-basis-point decline against forecast. The PBIR validates, every visual renders, and the total matches its semantic-model measure. Reviewers could still make the wrong pricing decision.

The approved forecast used constant currency. Actuals were translated at monthly average rates. The agent compared them directly because both measures existed and the page brief said “actual versus forecast.” The chart is faithful to the model and misleading for the decision. The fix is not a prettier annotation. Finance must choose a comparison basis, implement a deterministic constant-currency measure, and test it against a frozen extract.

This is why finance should approve the question and comparison before authoring. AI makes it easier to build exactly what was requested, including an ambiguous request. The release workflow must make ambiguity expensive before it makes the report persuasive.

Use five validation layers

1. Structural: validate PBIR/PBIP syntax, object bindings, measures, relationships, unsupported visuals, and the intended diff.
2. Numeric: re-perform material formulas, tie source and ledger or plan controls, test tolerance, and keep AI-generated values out of control totals.
3. Behavioral: test filters, drill paths, cross-highlighting, bookmarks, time boundaries, currency, nulls, negatives, exports, refresh state, and row-level security.
4. Visual: reload the current file and inspect screenshots for clipping, misleading axes, units, hierarchy, color-only meaning, empty visuals, timestamps, and mobile overflow.
5. Decision: verify that each headline distinguishes fact, comparison, materiality, uncertainty, hypothesis, implication, owner, and follow-up.

Do not collapse the layers into one green status. A structural validator cannot detect a wrong KPI policy. A numeric tie-out cannot detect that a chart hides a zero baseline. A screenshot cannot prove row-level security. A fluent narrative cannot prove causality. Show each verdict, reviewer, evidence link, and exception separately.

Test the audience, not only an administrator. Use representative roles to confirm that restricted entities, compensation data, customer rows, and forecast versions stay hidden. Then export to the formats recipients actually use. A report that is safe in the service can leak through an unrestricted export or forwarded file.

Bind approval to an exact release evidence pack

A verbal “looks good” cannot identify what was approved after the next refresh or agent edit. The release pack should name the report artifact hash, semantic-model version, source refresh identifier, frozen control totals, agent and skill version, audience, workspace, security roles, reviewer decisions, open exceptions, and approval expiry. If any bound field changes, the previous decision becomes historical evidence rather than permission to publish the new state.

Keep compact evidence for each gate. Structural evidence is the validator output and classified diff. Numeric evidence is the recalculation workbook or query, population total, expected value, observed value, tolerance, and preparer. Behavioral evidence is a filter and role matrix with pass, fail, and screenshot or log references. Visual evidence is a timestamped capture from the reloaded current file. Decision evidence is the approved headline, its cited inputs, the materiality test, and the owner of every unresolved hypothesis.

Use two people for consequential releases: a preparer who assembles the pack and a qualified reviewer who did not author the relevant metric or agent instruction. Smaller teams can rotate the roles, but they should not let the same generated narrative serve as both the work product and its evidence. The pack must point back to deterministic calculations and source records a reviewer can independently re-perform.

The dashboard should expose decisions, not manufacture causes

FP&A adds value by translating evidence into choices. The report should state what changed, compared with what, by how much, whether it is material, which explanations are supported, which remain hypotheses, what decision is due, and who owns the next test. AI can organize this structure and retrieve cited evidence. It should not convert correlation into a driver.

headline: Gross margin is 70 bps below constant-currency forecast
fact:
  actual: 31.4%
  forecast: 32.1%
  period: FY26 P08
materiality: below 150 bps escalation threshold
supported_driver:
  - freight rate variance: -40 bps, tied to logistics ledger
hypotheses:
  - product mix: requires SKU bridge validation
decision:
  - no pricing action; complete mix analysis by Aug 24
owner: Commercial Finance
source_pack: gm-p08-release-7f31...

This format resists the temptation to fill every blank with generated prose. “Requires validation” is a useful output. A named owner and deadline convert the dashboard from a picture into an operating artifact.

Failure modes that survive a polished demo

A 30-day pilot should release one real dashboard safely

1. Days 1-4: choose one recurring management decision, audience, report owner, source population, consequence of error, and current baseline.
2. Days 5-8: inventory the semantic model, approve KPI contracts, freeze control totals, and document security roles and known limitations.
3. Days 9-11: lock the page brief and acceptance tests before the agent edits any report or model file.
4. Days 12-16: run the agent against a preserved PBIP/PBIR baseline; capture diffs, validations, reloads, screenshots, time, tokens, and reviewer interventions.
5. Days 17-20: recalculate material measures, tie sources, run filter and edge-case matrices, and test row-level security and exports.
6. Days 21-23: review visual hierarchy, accessibility, mobile layout, timestamps, and every generated headline or annotation.
7. Days 24-26: close exceptions, rerun the exact current artifact, and assemble the release manifest with hashes and refresh IDs.
8. Days 27-28: finance, data/model, control, security, and report owners decide PUBLISH, RETURN FOR REWORK, LIMIT ACCESS, or STOP.
9. Days 29-30: monitor recipient questions and decision use; record incidents and reviewer corrections as regression cases.

Reapprove when a KPI definition, source, relationship, security role, audience, model, agent skill, publishing route, or materiality threshold changes. “Same dashboard” is not the same control object after its meaning or access path changes.

Frequently asked questions

Can AI build a finance dashboard?

Yes. It can plan, author, validate, render, and iterate on report artifacts. Finance still owns definitions, source reconciliation, materiality, permissions, interpretation, and release.

What should be approved before building?

Approve the audience, decision, sources, semantic model, KPI contracts, grain, time logic, filters, page brief, acceptance tests, permissions, and release authority.

Does a valid Power BI report prove correctness?

No. Structural validity is one layer. Recalculate material measures, tie totals, test filters and security, inspect the current render, and review the decision narrative.

Why avoid nondeterministic formulas for controls?

The same approved inputs should produce the same reviewable result. Let AI propose or explain logic, then implement deterministic formulas and independently test them.

Can the workflow apply outside Power BI?

Yes. KPI contracts, source registers, tie-outs, visual QA, permissions, narratives, and exact-version signoff apply to other BI and dashboard tools. Replace PBIR-specific checks with the target platform's artifact and validation controls.