The 5 Levels of AI in Power BI Development

AI in Power BI is evolving fast — but most developers are still stuck at Level 1. I see five distinct levels of using AI in Power BI development, and this framework is based on what I’m actually seeing in the community, the tools that exist today, and where the trajectory is pointing. Essentially, it’s not a ranking. It’s a roadmap.

This is my personal take. I might be completely wrong. I might be overlooking something. But after building Power BI solutions for years and watching AI tooling evolve from “paste this DAX into ChatGPT” to full agentic model building in under 18 months, I think we need a common language to talk about where we are and where this is going.

Here’s how I see it — from copy-paste to full autonomy.

Level 1 — AI in Power BI as a Search Engine

Level 1 is where the vast majority of Power BI developers using AI are today — roughly 90% based on what I see in the community. Typically, you open ChatGPT, describe what you want in plain language, get a DAX formula back, paste it into Power BI Desktop, and then spend the next 10 minutes fixing column names because the AI had no idea what your model looks like.

Copy-Paste DAX from ChatGPT — The Typical AI Workflow

You ask something like “write a DAX measure that calculates year-over-year revenue growth.” ChatGPT gives you a formula using generic column names like Sales[Revenue] and Date[Year]. Meanwhile, your actual table is called fact_Financials and your date column is dim_Calendar[FiscalYear]. So you fix it. After that, it throws a circular dependency error. Consequently, you go back, explain the error, get a revised version, paste again. Repeat this 20 times per report.

The tools at this level are ChatGPT, Microsoft Copilot, Bing AI — anything with a chat interface and no connection to your actual data model.

Why AI-Generated DAX Fails Without Model Context

The ceiling here is clear: AI has no idea what your tables are called, what your relationships look like, or what business logic already exists in your model. As a result, every answer is a guess that needs manual correction. It’s faster than Googling — but that’s about it.

“At Level 1, AI has no idea what your tables are called. Every answer needs manual fixing. It’s faster than Googling — that’s the ceiling.”

Level 2 — AI in Power BI with Model Context

Level 2 is where things start to click. Instead of describing your model to AI, you share the model itself. As a result, AI now knows your actual tables, columns, relationships, and existing measures. The output goes from “probably wrong” to “usually right.” Currently, a growing group of developers are here — maybe 10% of those using AI in their Power BI workflow.

How PBIP and TMDL Give AI Your Semantic Model Context

The key enabler is PBIP (Power BI Projects) — a text-based project format that Microsoft introduced to make Power BI models readable outside of Desktop. When you save as PBIP, your semantic model is stored as TMDL (Tabular Model Definition Language) files — human-readable, YAML-like text that describes every table, column, measure, and relationship in your model.

TMDL (Tabular Model Definition Language) is a human-readable text format for describing Power BI semantic models. It replaces the legacy BIM/JSON format with clean, diff-friendly files that AI tools can read and understand natively.

Once your model is in TMDL, you can paste the schema into Claude or ChatGPT as context before asking questions. For instance, some developers use Claude Projects to keep the TMDL context loaded permanently. Others connect a Model Context Protocol (MCP) server so AI reads the live model directly.

MCP (Model Context Protocol) is an open standard that allows AI assistants to connect to external tools and data sources. In Power BI, MCP servers expose your semantic model’s structure so AI can query it in real time — no manual copy-pasting needed.

MCP Servers and Power BI Modeling Tools

The Microsoft Power BI Modeling MCP server, launched at Ignite 2025, is the official way to connect AI to your model. Maxim Anatsko’s MCP Engine is a VS Code extension that connects AI assistants to live Power BI Desktop models — no PBIP export required. Both give AI the model context it needs to generate accurate output.

The Limit: AI Assists but You Still Write the DAX

Despite the improvement, you’re still directing every single step. AI is a very smart assistant at this level, but you’re writing the instructions. Nevertheless, the jump from Level 1 to Level 2 is the biggest quality improvement in the entire framework — and it’s accessible to anyone who enables PBIP format today.

“At Level 2, AI is a very smart assistant — but you’re still writing the instructions. The jump from Level 1 to Level 2 is the biggest quality improvement in the entire framework.”

Level 3 — Agentic Model Building

Level 3 is where AI stops being an assistant and starts being a builder. Rather than giving it a task (“write this measure”), you give it an objective (“build a financial reporting model with these 8 KPIs, define RLS by department, document everything”). AI plans the steps, executes them, and presents the result. You review. You don’t write.

So far, only a tiny group of practitioners worldwide are working at this level. The two names worth knowing: Maxim Anatsko, who builds MCP Engine Pro for agentic Power BI modeling, and Kurt Buhler at Tabular Editor, who’s developing the data-goblin agentic toolkit for autonomous model development.

Agentic DAX Generation and Automated Semantic Model Building

You give the AI agent an objective. It creates the full measure table, builds RLS role definitions, enforces naming conventions via Best Practice Analyzer rules, generates documentation — all as TMDL files committed to Git. You review the diff like a pull request. Approve or reject.

The tooling here includes MCP Engine Pro, the data-goblin agentic toolkit, Claude Code paired with the powerbi-modeling-mcp server, and Tabular Editor CLI for running BPA rules automatically.

Complex DAX and Time Intelligence Still Unreliable

Complex DAX semantics are still unreliable. Specifically, large language models produce plausible-looking but mathematically wrong formulas — especially for time intelligence patterns, multi-step calculations, and context transition scenarios. Because of this, every output still needs human review, and this level is not production-safe without oversight. Even so, it’s a fundamentally different workflow: you stop writing and start reviewing instead.

“At Level 3, you review a diff like a pull request. Approve or reject. For the first time — you’re not writing the code.”

Level 4 — Fabric Automation & CI/CD Pipeline

Level 4 combines two shifts that naturally belong together: automating the Microsoft Fabric service layer and treating Power BI as a full software product with CI/CD pipelines. In practice, this takes AI in Power BI beyond the model and into infrastructure — managing everything from code, no browser, no portal GUI, no clicking through menus — and wrapping it in a proper release process. Almost nobody is doing this with AI yet. Although a handful of enterprise teams run manual pipelines, the AI orchestration layer simply doesn’t exist.

Fabric REST API and CLI Deployment Automation

AI or scripts deploy semantic models and reports to Fabric workspaces via REST API. Deployment pipelines (Dev, Test, Prod) trigger automatically. RLS roles get deployed and validated programmatically. Scheduled refresh is configured via API. Workspaces are provisioned and users assigned by script. Reports are published from PBIR definitions.

fabric-cicd is an official Microsoft-backed, open-source Python package for deploying Power BI Projects (PBIP) to Fabric workspaces. It handles dependency ordering, service principal authentication, and orphan cleanup — replacing manual portal deployments with a single pip install fabric-cicd and a few lines of Python.

Fabric CLI reached general availability in 2025, adding terminal-based workspace management, refresh triggering, and deployment operations to the Fabric ecosystem.

Power BI CI/CD with GitHub Actions and Azure DevOps

In this setup, everything — the semantic model, reports, RLS definitions, documentation — lives in Git as text files (TMDL + PBIR). When a developer commits a change, automated tests fire, Fabric deployment triggers, and stakeholders get notified. Essentially, the same workflow software teams use to ship a web application — branch, code, test, review, merge, deploy — now applies to Power BI.

PBIR (Power BI Report format) is the text-based report definition format that stores report layouts, visuals, and configurations as readable JSON files — making reports versionable and deployable alongside semantic models in the same Git repository.

The pipeline typically includes GitHub Actions or Azure DevOps for orchestration, fabric-cicd for Fabric deployment, Tabular Editor CLI for Best Practice Analyzer rule enforcement, custom DAX testing frameworks for measure validation, and monitoring or alerting configured as code. The report and model are just another artifact in the release pipeline.

Power BI Automation Tools and What’s Missing

The tooling includes Fabric REST APIs, Fabric CLI, the fabric-cicd Python package, the Power BI PowerShell module (MicrosoftPowerBIMgmt), and CI/CD orchestration via GitHub Actions or Azure DevOps. While the APIs exist and work, what’s missing is AI actually orchestrating this end-to-end rather than humans writing the scripts. Currently, a human still writes the code, sets up the pipeline, configures the tests, and reviews failures. Therefore, the jump from here to “AI-driven” is the next frontier — and it’s closer than most people think.

Level 5 — Fully Autonomous BI Agent

What Fully Autonomous AI in Power BI Would Look Like

Nobody is here yet. The infrastructure exists in fragments, but the vision is clear. Picture this: you describe what the business needs in plain language. An AI agent then reads available data sources in the Lakehouse, designs the semantic model structure, writes all DAX, defines RLS based on org chart data, creates report layouts, deploys to Fabric via API, configures refresh schedules and alerts, and notifies stakeholders. One prompt. No Desktop. No Service UI. No human writing code.

Why Autonomous Power BI Development Is Still 2–4 Years Away

Several blockers remain. First, reliable complex DAX generation doesn’t exist yet — LLMs still hallucinate on multi-step calculations. Second, governance frameworks for autonomous deployment haven’t been built. And third, most organizations simply don’t trust it. However, here’s what I find striking: the tooling that makes this possible — PBIP, TMDL, MCP, Fabric CLI, Fabric REST APIs — is all arriving at roughly the same time. That’s not a coincidence. Instead, that’s infrastructure being built for a future that’s coming whether we’re ready or not.

My best guess: 2 to 4 years. It could be faster if DAX generation reliability improves, or slower if governance concerns stall adoption. Either way, the direction is clear.

“The tooling that makes autonomous BI possible — PBIP, TMDL, MCP, Fabric CLI, Fabric REST APIs — is all arriving at roughly the same time. That’s not a coincidence.”

All 5 Levels of AI in Power BI Compared

Here’s every level side by side — what you’re doing, the tools involved, who’s actually there, and what’s holding each level back.

Two Risks Nobody Talks About Enough

The levels are exciting. However, these are the reasons to stay cautious about AI in Power BI. I don’t think the community is having these conversations seriously enough yet.

AI DAX Hallucination — The Invisible Bug

AI generates DAX that looks completely correct — syntactically valid, logically structured, even well-commented — and yet calculates the wrong thing. This is the most dangerous failure mode because it’s invisible. For example, a wrong number in a dashboard doesn’t throw an error. Instead, it just sits there, informing decisions, until someone catches it.

The more autonomous the workflow, the bigger the blast radius. At Level 1, you’re reviewing every line manually. By Level 3, however, an agent is writing 50 measures in a batch — and the review surface grows exponentially. Once you reach Level 5, nobody is reviewing anything. In other words, the risk scales directly with the autonomy.

Power BI Model Data Sent to Third-Party AI APIs

At Level 2, you’re already sending your business logic and model metadata to a third-party API provider. Your table names, relationships, measure definitions, RLS rules — all of it leaves your organization’s perimeter. Most organizations I’ve worked with have zero governance for this. No policy on what model information can be shared with AI tools, no audit trail, no approval process.

Of course, this isn’t a reason to avoid AI in Power BI. Rather, it’s a reason to get governance right before the tools outpace the policies. If you’re exploring advanced Power BI configurations, the security conversation needs to happen first.

Where to Start — Practical Next Steps

This framework for AI in Power BI is only useful if you can act on it. Here’s what I’d recommend based on where you are right now.

Moving from Level 1 to Level 2 — Enable PBIP in Power BI Desktop

Starting at Level 1? Enable PBIP format in Power BI Desktop (it’s in Options → Preview Features). Save your model, then open the TMDL files in a text editor. Next, paste that schema into Claude or ChatGPT before your next DAX question. You’ll immediately feel the difference in output quality. This single step moves you to Level 2.

Scaling from Level 2 to Agentic AI in Power BI

Already at Level 2? Explore MCP servers. The Microsoft Power BI Modeling MCP or Maxim Anatsko’s MCP Engine will save you from manually pasting TMDL every session. As a result, you get the same context delivered automatically.

Working at Level 3 or beyond? Look at fabric-cicd for deployment automation and start building CI/CD pipelines. Even basic automation — for example, a GitHub Action that runs Tabular Editor BPA rules on every commit — will transform your workflow. For the full setup, check the Fabric Git integration documentation.

Finally, regardless of where you are, start thinking about your dashboard development process as a whole. Although the tooling is moving fast, fundamentals like clean model design, proper naming conventions, and solid DAX knowledge still matter at every level.

Frequently Asked Questions

What’s the fastest way to move from Level 1 to Level 2 in Power BI AI?

Enable PBIP (Power BI Projects) format in Desktop, save your model, and paste the TMDL schema files into your AI assistant as context. This gives AI your actual table names, relationships, and measures — so it generates accurate DAX instead of generic guesses. You can do this today in under 10 minutes. For a persistent setup, use Claude Projects or connect a Model Context Protocol (MCP) server.

Is it safe to share my Power BI model with AI tools?

TMDL files contain your model’s metadata — table names, column names, measure definitions, relationships, and RLS rules. They don’t contain actual data rows. However, this metadata can reveal business logic and organizational structure. Before sharing model context with any third-party AI provider, check your organization’s data governance policy. If none exists, that’s the first problem to solve.

Can AI actually write correct DAX measures?

For simple to moderate complexity — yes, especially with model context (Level 2+). Basic aggregations, filters, and common patterns like year-over-year growth are reliable. But complex time intelligence, multi-step calculations involving context transition (CALCULATE with nested filters), and semi-additive measures remain error-prone. AI generates DAX that is syntactically valid but logically wrong — the most dangerous kind of bug because it doesn’t throw an error. Always validate AI-generated DAX against known test values.

What is TMDL and why does it matter for AI in Power BI?

TMDL (Tabular Model Definition Language) is a human-readable text format for describing Power BI semantic models. It replaced the legacy BIM/JSON format with clean, YAML-like files that are easy to diff in Git and easy for AI to read. TMDL matters because it’s the bridge between your Power BI model and AI — without it, AI tools are guessing about your model structure. With it, they know exactly what tables, columns, relationships, and measures exist.

How far away is fully autonomous Power BI development?

My best estimate is 2 to 4 years — but with significant caveats. The infrastructure is arriving fast: PBIP, TMDL, MCP, Fabric CLI, and Fabric REST APIs all landed within roughly the same 18-month window. What’s missing is reliable complex DAX generation (LLMs still hallucinate on multi-step calculations), governance frameworks for autonomous deployments, and organizational trust. The technical pieces are closer than the cultural ones.