What would happen if you gave a brilliant new developer access to your Power BI environment but explained absolutely nothing?
They could inspect the models, read the DAX, and trace the relationships. But they would still struggle with some of the most important questions: Why does this KPI work this way? Why does this exception exist? What could break if I change it?
AI has exactly the same problem. And that made me wonder: if we want AI to become genuinely useful inside Enterprise BI, what does it actually need to know?
Inside this article
- What changes when AI can inspect the Power BI model directly
- Why semantic model access still leaves an important context gap
- How to build the context AI actually needs for Enterprise BI
- Where to draw the line between AI investigation and execution
- What changes when AI-powered BI reaches business users
Give AI Access to the Model
The first thing most of us would probably try is giving AI better access to Power BI itself. Instead of copying DAX, relationships, and screenshots into a chat, let it inspect the semantic model directly.
That already opens up much more interesting possibilities. AI could inspect measures, trace dependencies, understand relationships, and investigate the model around a problem. With model metadata, TMDL, XMLA, APIs, and MCP-based tooling, we are already getting closer to making this possible.
Start with read access, not an AI agent.
The first useful step is simply giving AI a reliable way to inspect the model without letting it change anything.
But there is still a missing piece. The semantic model can tell AI how something works. It doesn't necessarily tell AI why it works that way. And in Enterprise BI, that difference matters a lot.
The Things Your Semantic Model Doesn't Know
Take two measures: Revenue and Revenue Adjusted.
AI can see exactly how they differ. What it can't see is that Revenue Adjusted was introduced three years ago after Finance requested an exception, or that the original measure still exists because another team depends on it.
An experienced developer might know that history. Or they know where to find it. They remember the discussion, recognise the naming convention, check an old ticket, or know who to ask before touching anything.
That knowledge sits around the semantic model, not necessarily inside it. And there is a lot of it in Enterprise BI: business definitions, exceptions, previous decisions, ownership, expected behaviour, and the history behind why something was designed a certain way.
This is where the problem becomes more interesting. If we want AI to investigate with the same context we use ourselves, connecting it to Power BI is only one part of the setup.
Building the Context AI Actually Needs
If I were starting this in a real BI environment, I wouldn't try to build an AI layer across everything. I'd pick one investigation I already understand well and see how much of the context I normally gather manually can be made available to AI.
Take a KPI that suddenly changes after a release.
The semantic model is the easiest starting point because much of that context is already structured. Through TMDL, XMLA, APIs, or MCP-based tooling, AI can be given read access to measures, relationships, columns, and other model metadata. But the next pieces are different.
Change history could come from the PBIP repository, commits, or deployment information. Lineage could come from Power BI/Fabric metadata or whatever catalogue the organisation already maintains. And for business context, I wouldn't start by feeding AI an entire Confluence space. I'd begin with something much smaller: the KPI definition, owner, important exceptions, and the reason behind any non-obvious logic.
The first context path might look something like:
Now give AI a way to retrieve from those sources when the investigation requires it. MCP can become interesting here because Power BI doesn't have to be the only system AI can inspect. The point isn't one giant prompt containing everything. AI should be able to pull the relevant context when it needs it.
Start With Context You Can Trust
This is also where I would be careful about adding more sources.
Old documentation can be worse than no documentation. Git tells AI what changed, but rarely why. Lineage can return dozens of dependencies without telling us which ones actually matter. Connecting an entire documentation repository might give AI five different versions of the same KPI definition.
So for a team starting today, I would begin with a handful of important KPIs, not the whole stack. Make sure their definitions, ownership, and important exceptions are captured. Connect the technical context around them, and then replay investigations the team has already solved.
And I wouldn't solve documentation freshness with a quarterly clean-up. Update the context when the decision changes. A KPI change should update its definition. A new exception should capture why it was introduced. An ownership change should update the owner.
Then expand from there. The goal isn't to connect AI to everything. It is to build one trusted context path, prove that it improves the investigation, and grow it from there.
Where Would I Draw the Line?
Once AI can investigate properly, the tempting next step is letting it fix what it finds. I would allow that, but only up to a very specific point.
AI can inspect the model through XMLA, TMDL, or MCP, read the Git history, trace dependencies, and investigate the problem. It can even prepare the PBIP/TMDL change in a development branch and generate the tests. My boundary would be the pull request.
AI can get the change ready for review, but it cannot approve its own change or push it through the deployment pipeline. The developer still reviews the diff, checks the wider impact, and decides whether it moves forward.
The biggest mistake would be letting the same AI investigate the problem, choose the fix, validate its own work, and release it. At that point, the controls might exist technically, but they are no longer independent. AI can shorten the path to a production-ready change. It shouldn't be the one deciding that the change is production-ready.
Could You Hand This Over to the Business?
If this starts working well for developers, there is a natural next question: could some of it move into the hands of business users?
I think yes, but I would change the context first. A developer might need DAX, relationships, Git history, and lineage. A business user probably doesn't. They need the approved KPI definition, current numbers, relevant business exceptions, and enough context to explain what changed.
That could already take care of questions such as “Why did this KPI move?” “What exactly is included?” or “Is this expected?” without every question becoming a BI ticket.
The tricky part is allowing AI to turn an explanation into a conclusion. It might correctly identify that Revenue fell because one region declined, but why the region declined could require business knowledge that doesn't exist anywhere in the BI environment.
So I would start with explanation, not decision-making. Keep RLS and existing data permissions in place, expose only governed business context, and give AI a clear route back to the KPI owner when the evidence runs out.
| BEFORE HANDOVER Get the context ready | AFTER HANDOVER Test the experience |
|---|---|
| 01 Approved definition | 01 Ask naturally |
| 02 Current numbers | 02 Explain from evidence |
| 03 Known exceptions | 03 Respect permissions |
| 04 Change context | 04 Show uncertainty |
| 05 Clear ownership | 05 Escalate when needed |
That is where this gets interesting for me. We aren't giving the business an AI version of the BI developer. We're giving them better access to the knowledge already sitting behind their BI.
Closing Thought
I suspect AI will become capable of doing much more inside Power BI faster than most of us expect. But I'm not convinced capability will be the difficult part.
We can give AI better model access, connect more systems, and eventually let it prepare increasingly complex changes. But if the KPI definition is outdated, an exception lives in someone's head, or nobody remembers why a piece of logic exists, a smarter AI doesn't solve the context problem.
That is why I'm starting to see AI readiness differently. It isn't only about which models, agents, or tools we bring into BI. It is also about whether the environment around them is understandable enough to work with.
And perhaps that is a useful test for Enterprise BI in general: if we struggle to explain why our own BI environment works the way it does, we probably aren't ready to ask AI to understand it for us.
Comments
Join the discussion below (GitHub login required), or share your thoughts on LinkedIn . I’m most active there.