Power BI + Claude

Dashboards beantworten die Fragen, für die sie gebaut wurden. Die interessanten Folgefragen kommen danach: „Warum ist der Umsatz in Deutschland im November eingebrochen?“ „Wie sieht das ohne die Kampagne aus?“ „Kannst du mir das als Folie für den Vorstand aufbereiten?“ Bisher bedeutete das: Ticket an das BI-Team und auf neue Auswertungen warten.

Mit dem Model Context Protocol lässt sich diese Lücke schließen. Wir haben Claude Desktop direkt an Power BI Service angebunden. Claude formuliert eigenständig DAX-Queries gegen das semantische Modell, nutzt dabei die dort definierten Measures und liefert die Ergebnisse direkt weiter in PowerPoint-Folien oder aufbereitete PDFs.

In diesem Artikel zeigen wir den technischen Aufbau und erklären, warum ein zusätzlicher Context Layer in Form von YAML-Dateien den Unterschied zwischen „nette Spielerei“ und „verlässliches Analyse-Tool“ macht.

Die Architektur im Überblick

Das Setup besteht aus drei Bausteinen:

1. Ein lokaler MCP-Server, ein einzelnes Python-Skript, das den Power BI Service über die REST-API anbindet und Claude vier Tools zur Verfügung stellt: Workspaces auflisten, semantische Modelle auflisten, Modellstruktur beschreiben und DAX-Queries ausführen.
2. Delegierte Authentifizierung über Microsoft Entra (Device Code Flow). Man meldet sich einmalig mit dem eigenen Konto an, ein Refresh-Token wird lokal gecacht. Claude agiert damit unter der Identität des angemeldeten Nutzers. Row-Level Security greift automatisch, und es werden keine Client Secrets gespeichert.
3. Ein Context Layer pro semantischem Modell: eine YAML-Datei mit Business-Kontext, die Claude vor jeder Analyse liest.

Der Ablauf einer Anfrage: Der Nutzer stellt eine Frage in natürlicher Sprache. Claude liest den Kontext zum Modell, formuliert eine DAX-Query, führt sie über den MCP-Server gegen das Live-Modell aus und interpretiert das Ergebnis, inklusive Rückfragen und Folgeanalysen im selben Chat.

Warum das Setup ohne Fabric funktioniert

Der übliche Weg, programmatisch auf semantische Modelle zuzugreifen, führt über den XMLA-Endpoint, der eine Premium-, PPU- oder Fabric-Kapazität voraussetzt. Unser Setup nutzt stattdessen den REST-Endpoint executeQueries, der auf Shared Capacity verfügbar ist. Auf Nutzerseite braucht es dafür eine Power BI Pro-Lizenz und Build-Berechtigung auf dem jeweiligen semantischen Modell.

Der Zugriff ist dabei bewusst rein lesend: Die Entra-App fordert ausschließlich Read-Scopes an (Workspace.Read.All, Dataset.Read.All). Am Modell selbst kann über diesen Weg nichts verändert werden, was für die Governance ein wichtiger Punkt ist. Claude konsumiert das Modell wie ein Report-Nutzer, nicht wie ein Entwickler.

Die technischen Grenzen von executeQueries (eine Query pro Aufruf, rund 100.000 Zeilen pro Ergebnis, etwa 120 Requests pro Minute) sind für interaktive Analysen in der Praxis kein Engpass.

Der eigentliche Hebel bei Power BI + Claude: Das semantische Modell als Single Source of Truth

Ein häufiger Kritikpunkt an „KI auf Daten“ ist, dass jedes Tool Kennzahlen anders berechnet. Genau dieses Problem umgeht das Setup, weil Claude nicht auf Rohdaten arbeitet, sondern auf dem semantischen Modell, also derselben Schicht, aus der auch die Power BI Reports gespeist werden.

Ein Revenue-Measure ist dort einmal definiert, inklusive aller Feinheiten wie Rabattlogik, Zeitintelligenz und Filterkontext. Wenn Claude in seiner Query [Revenue] referenziert, anstatt ein eigenes SUM() zu erfinden, ist garantiert, dass die Zahl im Chat dieselbe ist wie im Dashboard. Auch die vom Modellautor gepflegten Beschreibungen von Tabellen, Spalten und Measures kommen über die Modellabfrage mit. Dokumentationsarbeit im Modell zahlt sich hier also doppelt aus.

Das ist der Unterschied zu einem klassischen Text-to-SQL-Ansatz: Claude beantwortet tiefergehende Fragen auf Basis der bereits definierten und abgestimmten Metriken, statt sie ad hoc neu zu berechnen.

Der Context Layer: Was das Modell nicht weiß

So gut ein semantisches Modell gepflegt sein mag, es weiß nichts über das Geschäft drumherum. Warum gibt es im November eine Datenlücke? Was war im Februar los, als ein einzelnes Produkt plötzlich explodiert ist? Solches Wissen steckt normalerweise in den Köpfen der Analysten.

Ein Sprachmodell bringt dieses Wissen nicht mit. Und weil es im Zweifel trotzdem antwortet, entsteht ohne dieses Wissen die gefährlichste Sorte Ergebnis: eine plausibel klingende, sauber formatierte, falsche Analyse.

Wir haben dieses Wissen in eine YAML-Datei pro semantischem Modell ausgelagert, die im Claude-Projekt hinterlegt ist. Die Datei enthält typischerweise eine Beschreibung und Domäne des Datasets, eine Event-Timeline mit geschäftlich relevanten Ereignissen wie Kampagnen, IT-Ausfällen oder manuellen Korrekturen, Beispiel-Fragen mit fertigen DAX-Queries als Muster, und bekannte Stolperfallen.

Was der Semantic Layer technisch leistet und wie er sich vom Context Layer abgrenzt, zeigen wir im zweiten Teil dieser Serie.

Ein Auszug aus unserem Demo-Setup mit dem Northwind-Datensatz:

dataset:
  name: Northwind Sales
  domain: B2B-Großhandel mit Spezialitäten-Lebensmitteln
  time_grain: Eine Zeile pro Bestellposition

event_timeline:
  - 2024-10-30: Service-Token der Order-API für Deutschland abgelaufen,
      Re-Authentifizierung erst am 2024-12-03.
  - Februar 2025: Umsatzspitze bei Côte de Blaye in Deutschland
      durch Marketing-Kampagne.
  - März 2025: Probleme in der Supply-Chain für Getränke in Deutschland

known_caveats:
  - "Revenue ist Menge x Einzelpreis ohne Rabatt und Fracht,
     nicht als Netto-Umsatz oder Rohertrag beschreiben."

Der Effekt in der Praxis: Fragt man nach dem Umsatzeinbruch in Deutschland im März 2025, rechnet Claude nicht wild Hypothesen durch, sondern erkennt anhand der Timeline, dass eine Umsatzspitze bei einem Produkt im Februar und ein Lieferproblem bei Getränken im März zusammen den Rückgang erklären, und weist entsprechend darauf hin, statt eine Erklärung zu halluzinieren. Genau diese Einordnung unterscheidet eine brauchbare Analyse von einer irreführenden.

Neue Modelle anzubinden ist bewusst leichtgewichtig: neue YAML-Datei im Projekt anlegen, dataset_id eintragen, Kontext schreiben, und die Einrichtung ist fertig. Keine Installation, kein Neustart.

Vom Ergebnis zum Deliverable: Integration in Claude Desktop und Cowork

Der zweite große Vorteil gegenüber isolierten „Chat-with-your-data“-Tools: Die Analyse endet nicht im Chatfenster. Weil das Setup in Claude Desktop beziehungsweise Claude Cowork läuft, stehen alle weiteren Fähigkeiten direkt zur Verfügung. Aus den Query-Ergebnissen wird im selben Arbeitsschritt eine PowerPoint-Präsentation mit den Kernzahlen für das Management, ein aufbereitetes PDF als Report für Stakeholder, oder eine weiterführende Analyse mit Visualisierungen.

Grenzen des Setups

Der Vollständigkeit halber: Q&A-Synonyme und die „Prep data for AI“-Konfiguration eines Modells liegen in dessen linguistischer Schicht, die nur über XMLA und damit Premium oder Fabric erreichbar ist. In der Praxis übernimmt der Context Layer in Form der YAML-Datei genau diese Rolle, mit dem Vorteil, dass er versionierbar, lesbar und ohne zusätzliche Kapazität pflegbar ist. Änderungen sind sofort wirksam, ohne Deployment oder Modell-Refresh.

Fazit

Die Kombination aus semantischem Modell und Context Layer macht Claude zu einem Analyse-Tool, das mit denselben Kennzahlen arbeitet wie die bestehenden Reports und dabei Fragen beantwortet, für die kein Dashboard gebaut wurde. Die Einstiegshürde ist niedrig: eine Entra-App-Registrierung, ein Python-Skript, eine Pro-Lizenz. Den größten Unterschied macht am Ende aber nicht die Technik, sondern wie gut der Business-Kontext gepflegt ist.

Wir bei Hopmann Marketing Analytics helfen BI-Teams und Marketing-Organisationen dabei, dieses Setup aufzubauen: von der technischen Integration über die MCP-Konfiguration bis zum Aufbau eines strukturierten Context Layers, der die KI-gestützte Analysen wirklich verlässlich macht. Möchten Sie wissen, wie ein solches Setup mit Ihren Power BI-Modellen aussehen könnte?

Was unsere Kunden häufig wissen möchten.

FAQ: Claude + Power BI per MCP

Tobias Lanzl ist Manager Data Analytics bei Hopmann Marketing Analytics, zertifizierter Power BI-Experte und spezialisiert auf KI-gestützte Analyse-Architekturen an der Schnittstelle von semantischen Modellen, Context-Layern und Large Language Models. Als ehemaliger wissenschaftlicher Mitarbeiter und Dozent bringt er die Fähigkeit mit, komplexe Zusammenhänge so aufzubereiten, dass sie in der Praxis funktionieren und verstanden werden.