An AI chatbot working with your business data gives accurate answers when it knows what your figures mean. That takes four things: agreed definitions for your key KPIs, an owner for each definition, visibility into data quality and access to the same source as your dashboards. More data or a more powerful model will not solve this. The chatbot reads the same ambiguous definitions as your colleagues, just faster and with more confidence.
Why more data does not make a chatbot smarter
Many teams think a chatbot will give better answers if you give it more tables and documents. That is not the case. More sources often mean more versions of the same concept, increasing the chance that it chooses the wrong one.
Here is an example. Someone asks the chatbot: "What was our revenue in the second quarter?" Finance calculates revenue after discounts. The sales dashboard shows revenue before discounts. The data warehouse also has a column containing invoice amounts including VAT. The chatbot picks one, calculates correctly and gives a confident-sounding answer.
The figure is not made up. It is simply not the figure your CFO has in mind. And the reader cannot see which definition the chatbot used.
In practice, this is the same problem you have had with dashboards for years. Two reports, two figures and a meeting spent discussing the number rather than the decision. The chatbot just makes it more visible by delivering the answer in a single sentence.
What does an AI chatbot working with our business data need?
A language model can calculate and write well. What it cannot do is guess what your organisation means by a particular word. You need to provide that context.
- Agreed definitions. One sentence in plain language for each KPI in a board or management report. What counts, what does not and what period it covers.
- An owner for each definition. One person authorised to change the definition and whom you can contact if an answer looks odd. Not a team, a name.
- Context for the data. Which table or measure corresponds to each concept, which filters apply by default and which columns are best avoided.
- Visibility into data quality. Has all of today's data been loaded? Are there known issues with a source? A chatbot that does not know this will report a partially loaded day as a bad day.
- The same source as your dashboards. If the chatbot works with raw tables while your dashboards use a semantic model, you will inevitably end up with two versions of the truth.
None of these five requirements is new. This is the same work that makes your dashboards reliable. The difference is that a chatbot cannot hide the fact that this work has not been done.
How do I make sure our AI chatbot gives the same figures as our dashboards?
Have the chatbot read from the same place as your reports, and give it the same definitions.
- Use your semantic model as the source. In Power BI, your measures are already in the semantic model. If the chatbot uses those measures instead of writing its own SQL against raw tables, it calculates figures the same way as your dashboards.
- Document the definition alongside the measure. The name "Revenue" says too little. A short description in plain language helps both the report reader and the chatbot.
- Create a test set. Take twenty questions whose answers you know from a certified dashboard. Ask the chatbot those questions. Every discrepancy is a signal.
- When figures differ, check the definition first. The chatbot is usually using a different table, filter or period. Fix that in the definition, not in the prompt.
- Have the chatbot show its source. You can check an answer that says "based on the Net Revenue measure, owned by Finance". You cannot check a number on its own.
How do I create a single source of truth for people and AI?
It is tempting to create a separate document for the chatbot: a list of definitions that you put in the system prompt or a knowledge base. That works for a few weeks. Then you have two lists drifting apart, one for people and one for AI.
A single source of truth means there is one place where a definition, its owner and its quality status are maintained. People read that information in their reports. The chatbot reads from the same place. If Finance changes the definition of net revenue, it changes for everyone at once.
In practice, this requires three things. A place maintained by the owners themselves, not by one person in IT. A connection to your reports, so people see the definition where they read the figure. And a way for your AI applications to retrieve the same information.
Where does a chatbot get its context?
| Source of context | Same figure as your dashboard | Who keeps it up to date | Can the reader see the definition |
|---|---|---|---|
| Raw tables in the data warehouse | Rarely | No one in particular | No |
| Semantic model with measures | Yes, if the chatbot uses the measures | The model builder | Only if the description is visible |
| Separate document in the prompt or knowledge base | Sometimes, until it becomes outdated | Whoever wrote the document | No |
| Shared layer with definitions, owners and data quality | Yes, if it points to the same model | The named owner | Yes, in the report and in the answer |
A practical framework: Agree, Assign, Connect, Check, Test
- Agree: one plain-language definition for every KPI in a management report.
- Assign: one named owner for each definition, authorised to change it.
- Connect: each definition points to the measure or table that supplies the figure.
- Check: a quality status for each dataset, so people and the chatbot know whether today's data is usable.
- Test: a fixed set of questions with known answers, asked again after every change.
Where dScribe fits
A semantic layer is not code. It is a business layer that connects your terms, their owners and the reports in which they appear. dScribe helps you build that layer with smart suggestions. These help you define terms and KPIs and link them to the reports and datasets where they appear to be used. They also identify duplicate definitions and help document lineage. Defining a KPI still involves some manual work, but the owner starts with a proposal rather than a blank page.
That semantic layer does not stay inside dScribe. Through an MCP server, dScribe makes definitions, owners, links and known quality issues available to other chatbots, AI agents and workflows. Your chatbot can then access the same meaning as your colleagues, who see the definition and owner alongside the figure in Power BI through the browser plugin.
Bringing it all together
A chatbot working with your business data is only as good as the agreed definitions behind it. If your people are still debating what revenue means, the chatbot will not settle that debate. It will simply pick a side. Agree on the definitions first, assign an owner to each and have people and AI read from the same source.
Frequently asked questions
Why does our AI chatbot give different figures from our dashboards?
Usually because it uses a different definition: a different table, filter or period. Have the chatbot calculate using the measures in your semantic model and give it the same definitions your reports use.
Does a chatbot working with business data need a semantic model?
Not strictly, but it helps a lot. A semantic model defines how a KPI is calculated. Without one, the chatbot writes its own calculation, which often differs from what your dashboards show.
Is putting our definitions in the prompt enough?
For a pilot project, yes. Over time, you will end up with two lists of definitions that drift apart. A better approach is one place that both your reports and your chatbot read from.
Who should manage the definitions for an AI chatbot?
The same people who manage the definitions for your reports: the business owner of each KPI. The BI team or AI team can build the connection, but the business owns the meaning.
How do you test whether an AI chatbot gives accurate answers about business data?
Ask a fixed set of questions whose answers you know from a certified dashboard. Repeat that set after every change to the model, data or definitions. Each discrepancy usually points to an ambiguous definition.