AI-Native
Business Intelligence

1 · The Dashboard Model Is Under Pressure

For twenty years business intelligence has meant dashboards, and for good reason. A dashboard is a decision someone made once — which numbers matter, at what grain, next to which others — that hundreds of people can then consume without making it again. The economics are sound. Nobody has invented a better way to put the same twelve numbers in front of a thousand people every Monday.

What has changed is what those thousand people do next. They no longer stop at the number. They ask about it — in the meeting, in the channel, in the reply to the email the dashboard was attached to — and the dashboard model has no answer to a question it was not built for except to build another dashboard. Estates grow to hundreds of workbooks this way, each one a question somebody asked once, and most of them never opened again.

Three costs the licence bill does not show

The viewer tax. Most of a BI licence bill is people who open a dashboard, change a filter and read a number. They generate no content and are priced like authors, so organisations ration access — and the people who need the number most are the ones without a seat.

Metric drift. A definition that lives inside a file drifts one workbook at a time. Two teams bring two revenue figures to the same meeting; nobody did anything wrong. The first twenty minutes of the meeting go to reconciling, and the reconciliation is not written down, so it happens again next month.

The Thursday answer. The question that matters is asked on Tuesday, in the room. The analyst who can answer it is a queue. By Thursday the answer is correct, well-formatted, and irrelevant — the decision was made with what was on the screen.

There is a quieter effect. Because the dashboard cannot answer why, managers stop asking it. They learn which questions the tool can take and confine themselves to those. The estate looks well used; the decisions are being made on a fraction of what the data could say.

2 · Anatomy of a Question

Averages hide the shape. Below is one question, timed end to end: a regional director opens the Monday sales dashboard at 09:05, sees that sales fell in August, and wants to know why before the 11:00 leadership call. The organisation has a competent analyst, a governed warehouse and a dashboard that is accurate. It is a well-run estate. This is what happens in it.

Sorted by what each minute was for, rather than when it happened, the shape is stark. Roughly ninety minutes of a skilled analyst's morning went into work with a correct answer that does not depend on who performs it: the same six grouped queries, the same deltas, the same ranking, the same twenty-month comparison. Perhaps ten minutes were judgement — deciding that the order band was the story rather than the region — and the one question that needed a person was never reached at all.

The four bullets in the channel record none of the working. When the same question is asked about September a different manager waits for a different analyst to run the same six queries. Not through carelessness: writing the working down in a message at 10:50 is not a reasonable thing to ask of someone with a call at 11:00.

3 · What AI Should Do, and What It Should Not

There are two failure modes in AI-for-BI programmes and they are mirror images. Doing too little produces a chat box that rephrases the dashboard. Doing too much produces a system that writes its own SQL against the raw warehouse, invents a join, and presents a confident number nobody can trace. Both come from skipping the same step: separating the mechanical from the consequential.

The failure mode that ends pilots

A chat assistant is asked why sales fell. It answers: "Sales fell 32% in August, likely due to seasonal factors and reduced demand in the Technology category." Half of that sentence is a number the model read from a query. The other half is a cause it produced because the question asked for one and the rows did not contain it. Nothing in the sentence says which half is which.

The damage is not the wrong answer — managers are used to reports being wrong. The damage is that the cause was fabricated and presented in the same voice as the fact. Once a finance director catches a system doing that, they stop reading its output permanently, and they say so in the meeting. Trust in this category is spent once. The question that matters is therefore not how often the assistant is right, but how it behaves when the data cannot answer — and whether it knows.

A corollary vendors rarely volunteer: for most of this work, arithmetic beats a model. The contribution of a region to a change is a subtraction; the share is a division; the ranking is a sort. Anything a finance director will question is better served by a deterministic procedure you can point at than by inference you cannot. A system that needs a model to say what moved has put a probabilistic component where a calculator belongs. The model's job is the prose — and the prose is checked.

4 · The Vocabulary Has to Become a Contract

Every organisation has defined its metrics. The definitions are in the workbooks, and they disagree. This is not a discipline problem, and asking teams to "align on definitions" in a workshop will not fix it. A definition that lives inside a file cannot be shared; what cannot be shared is copied; what is copied drifts one edit at a time. The drift is structural.

The difference matters most for the AI. Text-to-SQL against raw tables fails on three things: the wrong join, the inconsistent metric, the invented column. A catalogue removes all three by construction. The model is never asked to write SQL. It is asked to pick dimensions, metrics and filters from the catalogue it was shown — a constrained choice, not free composition — and a deterministic compiler writes the SQL, with the reader's access rules inside it. The model cannot ask for a column it was not shown, so a column policy is enforced by the shape of the question; a row policy is applied in the compiler, invisible to the model and impossible for it to route around.

The catalogue as the AI and the people see it: business names, descriptions, synonyms — never raw SQL. The assistant picks from this list; the compiler does the rest.

The governance argument

This is where the operating-model case is stronger than the productivity case, and it is the part risk functions recognise immediately. A regional manager who may only see their region asks the assistant why sales fell. The answer must be an explanation of their region, computed from the rows they are allowed to see — not a company-wide answer with the other regions blanked out after the fact, and not a leak. When the rules are compiled into every query, there is no version of the answer that was ever computed on data the person could not see.

5 · Reasoning You Can Follow, Not a Chart You Can Read

The most common wrong answer to "why did this move?" is another chart. A breakdown by region invites a breakdown by product, which invites one by segment, and the manager is now doing the analyst's morning with a mouse. The answer to a why-question is not a picture. It is a chain: what moved, what carried it, what moved against it, where it sits in the trend, and what to do about it — each link a click away from the next.

An explanation on the dashboard's own filtered view. The green mark beside each sentence means every figure in it traced back to a cell in the tables beneath; the four buttons at the bottom are the next step, each a single click.

From insight to action, without leaving the page

An insight that ends in a sentence is a report. An insight that ends in an action is a decision. The explanation therefore carries its own next steps, proposed from the numbers: look at the driver on its own narrows the whole dashboard to it; break the driver down runs the same explanation one level deeper; add the average as a reference line puts the context on the chart for everyone; alert if it falls below this again sets a threshold derived from the series' own variance, so the next occurrence is heard before the meeting rather than in it.

The same procedure runs across every panel of a dashboard, latest period against the one before, and ranks the moves. It is on the dashboard, on the home page across every dashboard a person can see, and in the body of the scheduled email above the attachment — so the person who receives the Monday PDF reads the two lines that matter before opening it.

What changed, before anyone asks: each panel's latest period against the one before, the driver under each line, and the explanation one click away. Three panels showed the same sales figure in different shapes; the digest reports it once.

Talking to the data, in a governed way

The conversation is still there — it is simply no longer the front door. Under the explanation a manager can ask the follow-up in words: was it fewer orders or smaller ones? is this unusual for a month? what moved the other way? The answer is drawn from the evidence on the panel — the claims, the trend, the breakdowns — plus at most one further query through the same catalogue and rules, which is shown. When the evidence cannot answer, the assistant says exactly that and names what would. The rule is the one that holds everywhere in the product: an answer may only use what the rows support.

6 · Reference Architecture

The shifts above come together in five layers. The top is where the data already lives; the bottom is the surfaces people actually read. Every layer in between exists to turn the trust of the top into the speed of the bottom without losing either.

Two properties matter more than the boxes. It runs inside your environment — your cloud storage, your credentials sealed, your model endpoint or none — so business data does not leave, and a dataset marked server-only never reaches a browser. And it degrades honestly: a dimension the reader may not see is never tried; a period with no data is reported rather than compared; a summary that carries a figure the rows do not support is dropped with a note, not shown.

7 · What Leaders Should Do Next

This is a programme of work, not a procurement decision, and it earns trust before it asks for it: the definitions first, the explanations on the dashboards people already read, the conversation last.

Measure your own starting point first

Three questions, answerable in a fortnight from systems you already have. Do not buy anything before you can answer them.

1 · What share of your dashboards were opened by anyone in the last ninety days? The usage export answers it in an afternoon, and the number is usually the largest surprise in the exercise.
2 · How many distinct definitions do your top five metrics have across finance, commercial and operations? Count the calculations, not the names. This is your actual project plan.
3 · What is the median time from a "why" question to its answer? Take ten questions from the last month's channels and tickets. This number belongs to no team, so nobody reports it.

Then time three questions by hand — an observation, not a survey. The assembly share from three real questions will be the most useful number in your business case, and it will be yours rather than a vendor's.