Why AI gets your numbers wrong, and how a modeled warehouse fixes it

AI gets your numbers wrong when it has to guess what a number means. Point it at raw tables and it invents a definition of revenue on the spot. Point it at a modeled warehouse, where revenue is defined once, and it reads the same figure your dashboard shows. The fix is modeling, not a better model.

This is the objection we hear most often, and it is a reasonable one. Somebody connects an AI assistant to the company database, asks what last quarter's revenue was, and gets a number nobody recognises. The obvious conclusion is that the AI made it up.

It usually did not. It answered a different question from the one that was asked.

What answering that question costs you today

Before the AI part, look at what already happens when someone asks for a number.

1. A manager asks the financial analyst. Not the system - a person
2. The analyst exports data from each system. Accounting, CRM, the operational tool, one file at a time
3. They prepare the report. Joining the exports by hand, applying the rules they carry in their head
4. They reconcile with accounting. Because the figure never matches the first time
5. They report back to the manager. Days later, and the number is already out of date

That chain is the actual cost, and every company running on exports has some version of it. It also explains why pointing an AI at your database is so tempting: it looks like a way to skip all five steps.

It is not, and the reason why is the interesting part.

Why does AI get business numbers wrong?

Ask a colleague for last quarter's revenue and they carry a dozen unstated rules into the answer. Excluding VAT. Excluding intercompany. Credit notes deducted. Booked on invoice date, not payment date. Unpaid invoices still counted. Test orders removed.

Those rules are step 3 of that chain. They live in the analyst's head, and they are the reason step 4 exists at all.

None of that is written down in the database. It lives in your finance team's heads and in the logic of whoever built the last report.

So when an AI reads your raw tables, it has to make those choices itself. It picks an interpretation, computes it correctly, and hands back a figure. The arithmetic is right. The definition is invented.

Ask the same question three times and you can get three defensible answers, because there genuinely are three defensible answers sitting in the data. That is not a model failure. That is the data being ambiguous.

What is the difference between raw data and modeled data?

Raw data is what your systems write down as they run. Modeled data is that same information after someone has decided what it means.

A production database is built for writing transactions quickly and safely. It is not built for answering questions. Which shows up in specific ways:

• Table and column names are developer shorthand - ord_hdr, amt_2, flg_x
• The same customer exists three times because three systems created them separately
• Business rules live in application code, not in the data
• Five columns hold a date and nothing records which one means the sale happened
• Deleted records are still there with a flag set

A human analyst learns these quirks over months. An AI reading the schema cold has no way to know any of it.

Modeling is the work of writing those decisions down once, in the data itself, so nobody and nothing has to guess again.

Can AI just read our database directly?

Technically yes. Several tools will connect an assistant straight to a production database, and it will start answering.

Three problems with that, and only the first is obvious.

It is querying the system your business runs on. An expensive analytical query against a live transactional database competes with the application for resources. The report is slow and so is checkout.

It sees everything. Salaries, personal data, unredacted customer records. If access is not scoped before the connection is made, it is not scoped at all.

It has no definitions to work from. This is the one that produces the wrong numbers, and no amount of prompting fixes it. You cannot explain your revenue rules in a chat message reliably enough to get the same answer twice.

What does a modeled warehouse actually change?

A managed data warehouse sits between your systems and anything that asks questions of them. Data is copied out on a schedule, cleaned, joined and defined - then reports and AI both read the finished tables rather than the raw ones.

Concretely, in ours: connectors pull from each source nightly, dbt transforms the data through Raw, Staging and business-ready layers, and automated tests catch bad data before a report sees it. A typical mid-size company lands at around 12 tables and four million rows - small enough to be fast, structured enough to be unambiguous.

The important part is the semantic layer. Net revenue is defined once. Active customer is defined once. Gross margin is defined once. Every dashboard and every AI answer inherits those definitions instead of recalculating them slightly differently.

Which means the question changes shape. Instead of "what does this AI think revenue means", it becomes "what does our company mean by revenue" - a question your finance team can actually answer, once, in a meeting.

And it collapses the five-step chain. The rules that lived in the analyst's head are written into the data, so there is nothing to reconcile - the report and the AI answer come from the same definitions. Steps two, three and four stop existing. What is left is asking and getting an answer, which is what everybody wanted in the first place.

The analyst does not disappear from this. They stop assembling exports and start deciding what the definitions should be, which is the part of the job that needed a person.

Is it safe to give an AI access to company data?

It is, if the access is scoped before the AI ever connects rather than after.

Ours connects over MCP with read-only credentials. It cannot write, cannot delete, cannot alter a definition. And it only sees the tables the person asking is permitted to see - a marketing question cannot reach the payments table, because that table is not in scope for that person at all.

That last distinction matters more than it sounds. The AI is not filtering a full answer down to what you are allowed to know. It never received the data in the first place. There is nothing to leak through a cleverly worded question.

Every query is logged. If someone asks something unexpected, that is visible.

How do you know the answer is right?

Ask the same question two ways.

Because the AI and your Power BI dashboards read from the same modeled tables, they should return the same figure. When they agree, you have two independent paths to one number. When they disagree, you have found a gap in the model - and crucially, you know exactly where to look.

That is the practical difference between a modeled warehouse and pointing an assistant at a database. Not that the AI stops being wrong. That when it is wrong, the cause is locatable and fixable, instead of being somewhere inside a language model.

You can also drill from any figure into the rows behind it. An answer you can open is an answer you can trust.

What this does not fix

Modeling removes definitional ambiguity, which is the most common cause of wrong numbers in a business setting. It does not make an AI infallible.

It can still misread an ambiguous question. It can still pick the wrong measure when two are plausible. What changes is that the numbers it returns are real numbers from governed tables that you can verify - not plausible-looking figures assembled from a schema it was seeing for the first time.

Anyone promising that AI will never be wrong about your data is selling you something. The realistic goal is that when it is wrong, you can tell, and you can fix the cause once rather than re-checking every answer forever.

Where to start

If two people in your company can ask the same question and get different numbers, you have a modeling problem, and adding AI to it will make the disagreement faster rather than smaller.

Start by writing down what your five most-argued-about metrics actually mean. That document is the beginning of a semantic model, and it is useful whether or not you ever connect an AI to anything.

Then decide whether you want to build and run that layer yourself, or have it managed. We do the second, at €250 a month plus €15 per user, EU-hosted, with the warehouse, connectors, models and daily refreshes included. Compare that honestly against what a data engineer and an analyst cost before deciding.