Connect an AI Agent to Power BI: Reports on Demand

To connect an AI agent to Power BI is to put a layer between your reports and the people who consume them: someone asks "why did margin drop on product line B last month?" in plain language, the agent queries the Power BI semantic model, returns the number with its breakdown, and attaches the chart. Nobody opens the report, nobody sets filters, nobody waits for the analyst to have a free slot.

The chat is not the interesting part. What matters is everything around it: alerts that fire when a metric leaves its normal range, reports that generate and distribute themselves every Monday with the commentary already written, and a question log that tells you — with data, for the first time — what your organization actually needs and which reports nobody opens. We run our own dashboards this way: an agent watches the BI layer, and people only receive what changed.

What does an agent connected to Power BI actually do?

Three things: it answers questions against the data model, it monitors metrics, and it distributes results. It does not replace Power BI — the semantic model, the DAX measures and data governance remain the foundation — it removes the friction between that model and the person who needs an answer.

The typical flow: the agent receives the question, translates it into a query against the semantic model (not against loose tables), retrieves the result, compares it with the prior period, and writes the answer with the number, the variance, and the two or three dimensions that best explain the change. If the question can't be answered with the current model, it says so instead of approximating.

That distinction is the technical crux of the project: the agent queries the semantic model, not the raw database. The measures are already defined, row-level security applies exactly as it does for a human user, and "margin" means precisely what finance decided it means. An agent that queries the warehouse directly invents its own definition of margin — and that is where the trouble starts.

How do you stop the agent from inventing numbers?

With three controls implemented from day one. First, the agent doesn't generate numbers: it runs a query and transcribes the result. Everything in the answer must come from an executed query, and that query is logged.

Second, every answer carries its provenance: which measure was used, which filters were applied, over what period. When the sales director asks "where does that 12% come from?", the answer is already in the answer. Without traceability, the first disputed figure kills the whole project.

Third, the agent is allowed to say "I don't know". This is the most neglected piece and the one that builds the most trust: questions the model can't answer — because the data isn't there, because the granularity doesn't go that deep, because the period isn't loaded — return "this isn't in the model, you'd need X" instead of a plausible-sounding estimate. An agent that never declines is an agent you can't rely on.

The same principle applies to any business-system integration: it's what we describe when connecting an AI agent to Dynamics 365 Business Central, where the ERP is the source of truth and the agent reads and writes only through its APIs, never underneath them.

Beyond asking: alerts and automated distribution

The biggest savings don't come from chat — they come from what happens when nobody asks. Two patterns cover most SMB cases.

Alerts with context. Instead of the classic Power BI alert ("metric crossed threshold"), the agent detects the deviation, investigates the dimensions that explain it, and sends something usable: "Northern region sales are 18% below the same month last year; 70% of the gap comes from two accounts that placed no order in September." That lands in email, Teams or Slack, with a suggested next step attached.

Automated distribution with commentary. Every Monday the agent compiles the weekly report, writes a five-to-eight-line summary of what changed versus last week, and sends each manager their own slice. The rep gets their book of business, the operations lead gets theirs, the GM gets the consolidated view. Exactly the task a person spends two hours on every Monday morning.

The most valuable side effect shows up at month three: the question log. You'll know what people genuinely ask, in what words, and how often. In every deployment we've run, that log has triggered a redesign of the data model — reports nobody opened, metrics everybody wanted that didn't exist. It's a free audit of your own BI estate.

Power BI Copilot, custom agent, or neither?

All three are legitimate; the answer depends on how far your case sits from the standard one. The honest comparison:

Rule of thumb: if the need is "let people ask without opening the report" and your model is clean, start with Copilot. If the need is "have something watch the numbers, write the commentary and hand it round", you need an agent — because that work happens outside Power BI.

What does it cost, and how long until it runs?

A first scope — natural-language questions over one or two semantic models, plus alerts and weekly distribution — lands between €8,000 and €25,000 and takes 4 to 8 weeks to reach supervised production. Below that range you're buying configuration on top of existing tools, which for many cases is the right entry point.

Two recurring lines sit on top: language-model consumption (for typical internal use, tens to a few hundred euros a month) and system maintenance, 10-20% of the initial cost per year. We break that second line down in our guide to what it costs to maintain an AI agent.

The variable that moves the price most isn't the AI — it's the state of your data model. If measures are defined, documented and undisputed, the project is quick. If "sales" means three different things depending on the department, phase one is fixing that — and it's money well spent, because that problem is already costing you without any agents involved.

How to build it, step by step

1. Audit the semantic model. Which measures exist, which are used, which are duplicated, which nobody can explain. Skip this and there is no project.
2. Collect 15-20 real questions from the three or four roles that consult reports most. They are your specification and your test suite.
3. Connect the agent to the model, not the database, honouring the row-level security you already have configured.
4. Validate against those 20 questions, comparing the agent's answer with what the report says today. Any discrepancy gets resolved before anyone else sees the system.
5. Open it to a pilot group of 5-10 people for two or three weeks and log everything they ask.
6. Add alerts and distribution based on what you learned, and only then roll out organization-wide.

What should you not automate here?

Consequential interpretation and metric definition. An agent explains what happened and where; deciding what it means for the business and what to do about it stays human, and blurring the line destroys more value than it creates.

• Official reported figures. Numbers that go to the board, the bank or the auditor are validated through the accounting process, not a conversational query.
• KPI definitions. What the company measures, and with what formula, is a leadership decision. The agent applies definitions; it doesn't propose new ones as if they were truth.
• Sensitive data without access control. If the agent can read payroll, salaries or per-customer margin, row-level security isn't optional — it is the project.
• Causal diagnosis. The agent surfaces correlations and dimensions; asserting "it dropped because of the price increase" is a hypothesis a person validates.

To see where this piece fits inside a broader executive dashboard, we cover it in our article on the KPIs of an AI-First company. And if you'd rather scope it with a team that builds these integrations every week, that's how we work from our AI consulting practice.

Frequently asked questions

Do I need Power BI Premium or a Fabric capacity?

It depends on how the agent queries. Reaching the semantic model through the service APIs typically requires Premium or Fabric capacity; with Pro licences alone there are alternative routes, but more constrained ones. This is the first thing checked during discovery, because it shapes the whole architecture.

Can the agent write to Power BI, or only read?

The standard — and the recommendation — is read-only against the model and write access on the output channels: email, Teams, a document, a ticket. Modifying reports or measures from an agent is technically possible and almost never a good idea, because it breaks the data governance that justifies having Power BI at all.

How many users does it take to be worth it?

The maths rarely runs on user count; it runs on analyst hours freed. If your data team spends more than 5-8 hours a week on ad-hoc report requests and recurring distributions, the project pays back inside a year even if only the leadership team uses it.

Does it work with systems other than Power BI?

Yes, and that's where most of the value sits: the same agent can cross the Power BI figure with the customer record in the CRM and the order status in the ERP to answer a single question. Each integration adds cost, so you start with one and expand on results. We have an equivalent guide for connecting an agent to SAP.

How long before results are measurable?

Savings on ad-hoc requests show up in week one. Business metrics — decisions made sooner, deviations caught earlier — need a quarter of data to read seriously. That's why you measure the baseline first: analyst hours spent on requests, and days between a deviation happening and someone noticing.