Claude und Power BI: Vom MCP-Server zum echten Agentic-BI-Workflow | DBI Analytics

Claude an Power BI anzubinden macht aus einem Chat-Assistenten einen Mitarbeiter, der dein semantisches Modell liest, DAX schreibt und Migrationen vorbereitet – aber erst die Governance-Schicht darüber entscheidet, ob daraus Tempo wird oder beschleunigte technische Schulden.

Kurzantwort: Claude kann über den Power BI MCP Server auf semantische Modelle zugreifen, Modellstrukturen analysieren, DAX schreiben, Dokumentation erzeugen und Migrationen vorbereiten. Für produktive BI-Projekte reicht der MCP-Server allein aber nicht aus. Unternehmen brauchen zusätzlich Governance, Regeln, Versionierung, Impact-Simulation und menschliche Freigabe. Genau diese Schicht übernimmt ABIS.

Was Claude und Power BI zusammen können – und warum das mehr ist als ein Chatbot im Report

Die meisten kennen KI in Power BI als Copilot-Funktion: Du tippst eine Frage, bekommst ein Visual. Das ist nützlich, aber es ist nicht das, worüber wir hier sprechen. Wenn wir Claude an Power BI anbinden, läuft die KI nicht im Bericht, sondern daneben – als eigenständiger Agent, der über ein offenes Protokoll auf dein Datenmodell zugreift, es analysiert, dokumentiert und verändert.

Der Unterschied liegt im Wort Agentic . Ein klassischer Assistent antwortet auf Fragen. Ein Agent plant mehrstufige Aufgaben, ruft Werkzeuge auf, schreibt Dateien, führt DAX-Queries aus und arbeitet eine Migration über mehrere Arbeitssitzungen hinweg ab – unter menschlicher Aufsicht. Genau das tun wir bei DBI seit Monaten in echten Kundenprojekten. Dieser Beitrag ist der Bericht aus dem Maschinenraum: was die Anbindung kann, wo sie allein scheitert und was unsere hauseigene Schicht ABIS oben drauf bringt.

Wer Altsysteme nach Microsoft Fabric und in die Cloud migriert, bekommt mit diesem Stack kein Spielzeug. Er bekommt einen Weg, den Engpass aufzulösen, der BI-Projekte seit Jahren ausbremst: das manuelle Bauen sauberer Semantikmodelle.

Die Architektur: drei Schichten, sauber getrennt

Unser Aufbau besteht aus drei Schichten, die sich klar voneinander trennen lassen.

1. Oben die Intelligenz – ein KI-Assistent (in unserem Fall Claude Desktop), der plant, Code schreibt und Queries ausführt.

2. In der Mitte das offene Protokoll – das Model Context Protocol (MCP). MCP ist ein offener Standard, über den KI-Anwendungen wie Claude oder ChatGPT mit Datenquellen, Tools und Workflows verbunden werden können. Vereinfacht: USB-C für KI-Werkzeuge. Jeder MCP-kompatible Tool-Server kann von jedem MCP-kompatiblen Assistenten bedient werden.

3. Unten die spezialisierten Tool-Server – ein Power-BI-MCP-Server, der das semantische Modell als Werkzeuge exponiert, und unser eigener Kontextgraph- und Governance-Layer ABIS. Microsofts eigene Power-BI-MCP-Server befinden sich aktuell in der Public Preview und decken zwei Szenarien ab: einen lokalen Modeling-Server zum Bauen und Verändern von Semantikmodellen und einen Remote-Server zum Abfragen bestehender Modelle. Preview heißt: Die Tools funktionieren, aber Definitionen und Schnittstellen können sich bis zur General Availability noch ändern. Genau in diesem Umfeld bewegt sich der Markt gerade – und genau hier entscheidet sich, ob ein Team mit KI sauber arbeitet oder schnell Chaos produziert.

Der Witz an diesem Aufbau: Die KI sieht nie die kompletten Quelldaten. Sie sieht Strukturmuster, Formelmuster, Beziehungsgraphen und Metadaten. Das reicht, um einen Migrationsplan zu schreiben, eine Sternschema-Struktur vorzuschlagen und Power-Query- oder DAX-Code zu generieren. Und es ist wenig genug, um datenschutzrechtlich unkritisch zu bleiben. Für regulierte Branchen ist das kein Detail. Es ist die Voraussetzung dafür, dass KI überhaupt zum Einsatz kommen darf.

Warum ABIS? Der MCP-Server gibt dem Agenten Zugriff auf Power BI. ABIS entscheidet, ob eine Änderung fachlich, technisch und regulatorisch vertretbar ist. Ohne diese Governance-Schicht entsteht Geschwindigkeit. Mit ihr entsteht belastbare Produktivität.

Power BI MCP Server allein vs. Power BI MCP Server mit ABIS

Was der Power BI MCP Server allein leistet

Ein MCP-Server läuft neben Power BI Desktop und macht dein semantisches Modell für die KI ansprechbar – ohne das Modell selbst zu verändern, solange du keine Schreiboperation freigibst. Damit übernimmt Claude eine Reihe von Aufgaben, die vorher Handarbeit waren:

Für eine schnelle Modellanalyse reicht das oft. Für ein echtes Kundenprojekt nicht. Und genau hier beginnt der Teil, den du im Sales Pitch eines Tool-Anbieters nie hörst.

Wo der MCP-Server allein an seine Grenzen stößt

Ein Large Language Model erzeugt keinen Satz, weil der Satz wahr ist, sondern weil er wahrscheinlich ist. Für kreative Textarbeit ist das brillant. Für eine Datenmodellmigration ist es gefährlich – und zwar genau dann, wenn die Aufgabe unscharf formuliert wurde.

Vier Probleme kamen immer wieder. Nicht theoretisch. In echten Projekten.

1. Die KI ist selbstbewusst falsch. In einem Migrationsprojekt für einen großen europäischen Versicherer hat Claude im ersten Versuch eine Mapping-Tabelle geliefert, die perfekt aussah: Spalten sauber benannt, Struktur konsistent, Kommentare ausgefüllt. Drei Stichproben stimmten. Die vierte: ein Variablencode war zwei Fachbereichen zugeordnet. Die fünfte: eine ganze Gruppe von Variablen fehlte. Der Grund war banal und folgenschwer. Die KI hatte nur die Tabs ausgewertet, die sie im Kontextfenster sah. Was sie nicht sah, existierte für sie nicht.

2. Regeln greifen nicht im Moment der Generierung. Im selben Projekt hat die KI zwei Tabellen direkt mit dem Präfix DIM_ angelegt und damit den vereinbarten Staging-Schritt ( raw_ ) übersprungen. Eine KI, die 20 Measures in 30 Minuten schreibt und die Hälfte mit inkonsistenten Namen ausstattet, ist kein Produktivitätsgewinn. Das ist beschleunigter Aufbau technischer Schulden.

3. Kein Gedächtnis zwischen Sitzungen. Der Chatverlauf ist nach jedem neuen Thread weg. Ein Agent, der nach jeder Session vergessen hat, was vorher entschieden wurde, ist kein Werkzeug für mehrwöchige Projekte. Er ist ein Wiederholungstäter.

4. Fachlogik kennt die KI nicht. Das Insights-Deck unseres Versicherer-Projekts behauptete, der Kunde liege in drei Journey-Phasen unter Markt. Die Charts waren schön, die Aussage war falsch. Die Likert-Skala der Branche ist invers – niedriger ist besser. Der Versicherer war dort Marktführer. Nichts in den Daten schrie die KI an, dass die Richtung invers ist. Gefangen hat den Fehler ein Mensch mit zwölf Jahren Branchenerfahrung, kein automatischer Check.

In drei von vier Fällen hat ein Mensch mit Domänenwissen den Fehler gefangen, nicht die KI. Das ist keine Anklage gegen KI. Das ist die Gebrauchsanweisung. Und es ist der Punkt, an dem ein reiner MCP-Server aufhört und eine Governance-Schicht beginnen muss.

Was ABIS oben drauf bringt

ABIS (Agentic Business Intelligence System) ist unsere Schicht zwischen MCP-Server und LLM. Sie läuft vollständig lokal als Desktop-Anwendung, überträgt keine Kundendaten in die Cloud und schließt genau die vier Lücken von oben. Vier Bausteine machen den Unterschied.

Der Kontextgraph. Bevor die KI auch nur eine Zeile Power Query sieht, laden wir die Quelle – eine Excel-Datei oder ein Power-BI-Modell – in den Kontextgraph. Jede Entität (Zelle, Tabelle, Measure, Formel) wird zum Knoten, jede Abhängigkeit zur Kante. Plötzlich wird Komplexität sichtbar: die eine zentrale Zelle, von der 5.000 andere abhängen; das Formelmuster, das sich 68-mal wiederholt; die Blöcke, die bloße Präsentation sind, und die, die den Faktenkern tragen. Für eine belastbare Aufwandsschätzung ist das Gold wert. Der Berater sagt binnen Minuten, ob eine Excel-Datei zwei Tage oder zwei Wochen Arbeit bedeutet – und belegt es mit einem Artefakt statt mit Bauchgefühl.

Die Metafile-Persistenz. Alle Pläne, Analysen, Code-Snippets und Risikoregister liegen serverseitig als Metafiles im Projekt-Workspace, nicht im flüchtigen Chatverlauf. Über ein Dutzend Sessions hinweg weiß der Agent, wo er aufgehört hat, was der letzte beschlossene Plan war und welche Regeln gelten. Der Übergang zur nächsten Arbeitssitzung wird unauffällig. Genau das will man als Berater: keine Showeffekte, sondern kontinuierliche Arbeit.

Die Rules-Engine. Naming Conventions, Staging-Logik und Best-Practice-Regeln werden nicht zur Erinnerung dokumentiert, sondern aktiv geprüft. Die DIM_ -Verletzung von oben wurde gefangen, als wir die Rules-Engine gegen die Tabellenliste laufen ließen. Die Tabellen wurden umbenannt, der Staging-Schritt dokumentiert und als Checkliste für künftige Sessions verankert. Ohne diesen Check wäre der Fehler produktiv gegangen und Monate später teuer aufgefallen.

Der Governance-Layer mit Impact-Simulation. Bevor eine Schreiboperation ausgeführt wird, simuliert ABIS die Änderung gegen den Graphen. Die Pipeline läuft in festen Schritten: SOP-Blocker-Prüfung, Compliance-Regeln, Ausdrucksvalidierung, dann die Graph-Impact-Simulation über Lineage, Visual- und Slicer-Referenzen, Measure-Abhängigkeiten und Unused-Status. Das Ergebnis ist entweder ein „blockiert" mit Begründung und Lösungsplan oder ein vollständiger Risikobericht plus die freizugebende Ausführung. So sieht der Mensch vor jedem Eingriff, was kippen könnte – inklusive der impliziten Folgen auf Berichte, wenn sich das Datenmodell darunter ändert.

Typische Workflows aus der Praxis

So sieht ein Arbeitstag mit dem Stack konkret aus. Wir bauen zuerst ein umfassendes, aktuelles Kontextfenster auf. Erst danach planen, schätzen und migrieren wir. Diese Reihenfolge ist Pflicht. Sonst produziert der Agent sehr schnell etwas, das gut aussieht und trotzdem falsch ist.

Autodokumentation eines Modells. Der Agent verbindet sich mit dem geöffneten Power-BI-Modell, prüft die ABIS-Health und dokumentiert das komplette Datenmodell:

// AUTODOC#000 – komplette Modelldokumentation
list_ports          // verfügbare Power-BI-Instanzen finden
connect_model       // Verbindung herstellen (nicht überspringen!)
abis_system_health  // ABIS-Status prüfen
auto_document_project

Typische Ausführungszeit: rund 48 Sekunden für etwas, das von Hand Stunden dauert.

DBML-Schema und Modellbeschreibungen. Ein visuelles Schemadiagramm des Semantikmodells entsteht in etwa 90 Sekunden. Handarbeit dafür liegt bei einem knappen Arbeitstag. Reichhaltige Beschreibungen für alle Tabellen, Spalten und Measures, die wir manuell auf rund 56 Stunden taxieren, erzeugt der Agent in unter einer Minute und schreibt sie auf Wunsch direkt ins Modell zurück.

DAX-Measure-Migration. Ein häufiger Performance-Hebel: hartcodierte Spalten in Visuals durch saubere Measures ersetzen. Der Workflow läuft SOP-gesteuert in klar abgegrenzten Phasen – Bootstrap, Sammeln, Analysieren, Planen, Ausführen, Testen, Dokumentieren – und stoppt nach jeder Phase mit einer klickbaren Rückfrage. Der Mensch gibt jeden Schritt frei. Measure-Namen werden dabei sprechend gemacht ( CTR wird zu Click Through Rate ), nicht aus dem Spaltennamen übernommen.

Aufwandsschätzung gegenüber dem Kunden. Aus den persistierten Dokumenten, den SQL-Dateien und Workflow-Exporten leitet der Agent eine Komplexitätsanalyse ab, benennt die Effort-Treiber je User Story und stellt Mensch- gegen Agent-Aufwand gegenüber – als Executive Summary, die ein Finanzchef nachrechnen kann.

Compliance-Gap-Analyse in regulierten Umgebungen. Für ein GxP-reguliertes Datenmart-zu-Power-BI-Reporting prüft der Agent das Modell gegen die hinterlegten Business-Regeln, listet die Lücken je View auf und liefert einen Remediation-Plan mit priorisierten To-dos.

Jeder Flow protokolliert die gesparte Zeit, die wir intern gegen die manuelle Schätzung tracken. Das hält die Versprechen ehrlich.

Use Cases, die wir tatsächlich hatten

Wir anonymisieren im Folgenden, wie wir es in allen kundenseitigen Materialien tun.

• Versicherung – Excel zu Power BI. Quartalsweise Kundenzufriedenheits-Dashboards eines großen europäischen Versicherers. Wide-Format mit neuer Spalte je Quartal, dreistufige Header, versteckte Variablencodes in weißer Schrift, inverse Likert-Skala. Der Kontextgraph machte die wahre Komplexität in der ersten Stunde sichtbar. Die Schätzung hielt. Zwei kritische Fehler wurden vor der Auslieferung gefangen – einer von der Rules-Engine, einer vom menschlichen Domänenwissen.

• Energieversorger – eMobility-Cockpit. Ein Management-Cockpit für Ladestationen in Süddeutschland aus einer verschachtelten JSON-Quelle, ausgewertet über mehr als 500 Standorte. Genau die Datenmodellierung, in der die Agenten am stärksten beschleunigen.

• Energietechnik-Konzern – F&E-Finance-Autodoc. Vollständige Modelldokumentation eines Finanzberichts mit Ist und Budget, auf Knopfdruck statt in Tagen.

• Pharma – GxP-Compliance. Ein Databricks-Datenmart mit Power-BI-Reporting für Qualitätsprozesse, der vor der nächsten Mart-Schicht regelkonform sein musste. Der Stack lieferte die Transparenz und den Gap-Plan für die Freigabe.

• Industriekonzern – Tableau-Ablösung. Migration und Veredelung einer Toolbox auf Power BI / Microsoft Fabric mit governter Datenbasis und besserer UX.

Wie sich das Team DBI umgestellt hat

Der Stack hat unsere Arbeitsweise verändert, nicht nur unser Tooling. Fünf Anpassungen sind geblieben.

1. Vorlage-First statt KI-First. Wir erstellen die ersten 10 bis 20 korrekten Mappings manuell und definieren darin Schema und Regeln. Erst dann vervollständigt die KI die weiteren 100 bis 500 Einträge nach diesem Muster. Das fühlt sich langsamer an, ist aber schneller. Die Prüfung gegen ein klares Schema folgt einem bekannten Muster.

2. Kleine Schritte mit validierbarem Output. Statt „Migriere diese Excel" geben wir abgegrenzte Teilaufgaben mit jeweils prüfbarem Ergebnis. Nach jedem Schritt wird geprüft und dokumentiert.

3. Versionierung ist Pflicht. KI-gestützte Entwicklung ohne Git ist russisches Roulette. Du wirst Zustände produzieren, die du zurückdrehen musst, und Diffs, die du nachvollziehen musst.

4. Der Mensch validiert fachlich. Ob eine DAX-Formel syntaktisch stimmt, sagt der Compiler. Ob sie das Richtige berechnet, sagt nur jemand mit Domänenwissen. Die Verantwortung für Logik, Kontext und Qualität bleibt beim Menschen.

5. Datensicherheit ist Architektur, keine Einschränkung. Vertrauliche Daten bleiben lokal, die KI bekommt nur Struktur und Metadaten. Genau das macht KI in regulierten Branchen erst einsetzbar.

Was es auf den Tisch gebracht hat – ehrlich gerechnet

Hier trennen wir Marketing von Realität. Es gibt zwei Zahlen, und beide sind wahr, weil sie verschiedene Dinge messen.

Auf der Modellierungs-Stufe – dem eigentlichen Engpass – ist der Sprung dramatisch. Was einen erfahrenen BI-Engineer zwei bis vier Wochen kostet, liefert der Agent in wenigen Stunden, ohne ein einziges Mal Power BI Desktop manuell zu öffnen. Auf dieser Stufe reden wir über Faktor 10 und mehr.

Auf der Projekt-Ebene sieht die Rechnung nüchterner aus. Ein realer Auftrag enthält auch Workshops, Anforderungsabstimmung, Deployment und Schulung – Arbeit, in der KI wenig beiträgt. In einem modelllastigen Referenzprojekt haben wir rund 42 Prozent des Gesamtaufwands eingespart (280 von 480 Stunden). In einem workshop-lastigen Projekt liegt der realistische Beschleunigungsfaktor eher bei 1,3 bis 1,5 auf den assistierten Arbeitspaketen. Wer dir Faktor 10 fürs ganze Projekt verspricht, verkauft Folien.

Strukturell ist der Effekt größer als jede Stundenzahl. Der Engpass zwischen Kopfzahl und Output ist gebrochen. Dieselbe Mannschaft bewegt sich durch deutlich mehr Projekte, weil die Modellierung nicht mehr der Taktgeber ist. Berater verschieben sich von Produktion zu Beratung – genau der Arbeit, die Kunden am höchsten bezahlen. Bei einer typischen BI-Beratungsmarge von 15 bis 20 Prozent hebelt das den EBIT spürbar nach oben.

Der wertvollste Posten taucht in keiner Brutto-Stunden-Rechnung auf: die verhinderten Fehler . Die Naming-Verletzung, die Wochen später technische Schulden produziert hätte. Der Skalen-Fehler in einem Management-Deck, der einen Reputationsverlust verursacht hätte. Diese vermiedenen Schäden sind real, auch wenn sie nicht passiert sind. Genau hier rechtfertigt ein Governance-Layer seinen Preis.

Ein Pfad zur Digitalisierung – nicht ein Tool-Kauf

Für Teams, die Altsysteme nach Microsoft Fabric und in die Cloud bringen, ist dieser Stack kein Selbstzweck, sondern ein gangbarer Weg. AS/400, Access oder On-Premise-SQL werden in einen Kontextgraphen geladen, alte Schemata auf neue Strukturen gemappt, jede Transformation dokumentiert und die Datenqualität vor dem Go-Live validiert. Der Kunde bekommt eine lückenlose Lineage-Dokumentation und ein Migrations-Dashboard – und spart sich Monate manueller Mapping-Arbeit.

Wichtig ist die ehrliche Heuristik, wann sich der Governance-Layer lohnt: bei Projekten über mehrere Sessions, bei regulatorischen Nachvollziehbarkeits-Anforderungen, bei Teams mit echten Standards, bei wiederkehrenden Lieferungen und bei hohen Beraterstundensätzen. Bei einer schnellen Ad-hoc-Analyse auf einer einzelnen CSV braucht es ihn nicht. Überdimensionierte Architektur ist auch eine Form von Verschwendung.

Agentic AI nimmt uns nicht das Denken ab. Sie nimmt uns die repetitive Arbeit ab – das hundertfache Schreiben ähnlicher Measures, das Durchklicken großer Excel-Dateien. Die Verantwortung für Logik, Kontext und Qualität bleibt beim Menschen. Die Teams, die das in den nächsten Jahren am besten machen, sind nicht die, die am meisten KI einsetzen, sondern die, die am klarsten definiert haben, wer wofür zuständig ist.

Claude Power BI FAQs

Ersetzt Claude den Power BI Copilot?

Nein, sie lösen verschiedene Probleme. Copilot benötigt eine bezahlte organisatorische Fabric- oder Power-BI-Premium-Kapazität. Claude über MCP verfolgt einen anderen Ansatz: Der Agent arbeitet neben dem Modell und nutzt MCP-Tools für Analyse, Modellierung, DAX und Dokumentation. In der Praxis ergänzen sich beide.

Verlassen meine Daten das Haus, wenn ich Claude an Power BI anbinde?

Bei unserem Aufbau nicht. ABIS ist eine lokale Desktop-Anwendung; analysierte Dateien werden auf deinem Gerät verarbeitet und gespeichert. Die KI bekommt Strukturinformationen, Formelmuster und Metadaten – nicht die vertraulichen Rohinhalte. Schreiboperationen auf das Modell werden einzeln freigegeben.

Was ist der Unterschied zwischen dem MCP-Server und ABIS?

Der MCP-Server macht das semantische Modell für die KI ansprechbar – Schema, DAX, Lineage. ABIS legt sich als Governance-Schicht dazwischen: Kontextgraph für Komplexität und Schätzung, Metafile-Persistenz für das Gedächtnis über Sessions, Rules-Engine für aktive Regeldurchsetzung und eine Impact-Simulation vor jeder Schreiboperation.

Sind die Power BI MCP Server schon allgemein verfügbar?

Microsofts offizielle Power-BI-MCP-Server sind aktuell in der Public Preview – mit einem lokalen Modeling-Server und einem Remote-Server. Funktionen und Schnittstellen können sich bis zur General Availability noch ändern. Für produktive Projekte heißt das: zusätzliche Governance und menschliche Freigabe sind kein Luxus, sondern Pflicht.

Wie realistisch ist die versprochene Zeitersparnis?

Auf der Modellierungsstufe sehr hoch – Stunden statt Wochen. Aufs Gesamtprojekt gerechnet realistisch zwischen rund 1,3-fach und etwa 42 Prozent Aufwandsreduktion, je nachdem, wie modelllastig das Projekt ist. Ein nennenswerter Anteil der gewonnenen Zeit fließt zurück in die Validierung der KI-Outputs. Das rechnen wir offen ein.

Brauche ich für diesen Stack tiefe Programmierkenntnisse?

Du beschreibst die Zielarchitektur in natürlicher Sprache; den Star-Schema-Aufbau, die DAX-Measures und die Dokumentation erzeugt der Agent. Was du brauchst, ist BI-Fachverständnis für die Validierung – nicht das manuelle Klicken im Power Query Editor.

Über den Autor

David Chang ist Gründer und Geschäftsführer der DBI Analytics GmbH (Kirchheim bei München), Microsoft Solutions Partner für Data & AI. Er begleitet seit über zehn Jahren komplexe Cloud-BI-Migrationen in Enterprise-Umgebungen und hat mehrfach Projektvolumina im zweistelligen Millionen-Euro-Bereich verantwortet. Mit ABIS, dem hauseigenen Agentic-Business-Intelligence-System, baut DBI als einziger DACH-Anbieter Agentic-BI- und MCP-Server-Workflows in echten, regulierten Kundenprojekten – lokal, vendor-agnostisch und mit europäischer Datensouveränität.

Mit uns über Claude Power BI sprechen

Agentic BI in der Praxis – kostenlose Webinarreihe

Wir zeigen an konkreten Fallbeispielen aus laufenden Projekten, wie man Agentic-BI-Workflows im Unternehmen identifiziert und aufbaut – welche Voraussetzungen deine Organisation mitbringen muss und wie ein Pilotprojekt aussieht, das nicht scheitert.

DBI Analytics - Daten & KI mit europäischer Datensouveränität. — Microsoft Solutions Partner für Data & AI. Power BI Beratung, Microsoft Fabric Migration und Agentic BI für den DACH-Mittelstand und Konzerne.