.png){kind=small}
Power BI Report Authoring Skill: Berichte mit AI-Agenten kontrolliert erstellen
Power BI Reports per Prompt verändern, neue Seiten anlegen oder Visuals automatisch umbauen: Mit dem Power BI Report Authoring Skill wird genau dieser Teil der Berichtsentwicklung agentisch. Entscheidend ist aber nicht, dass ein AI-Agent PBIR-Dateien schreiben kann. Entscheidend ist, ob Änderungen nachvollziehbar, validierbar und visuell prüfbar bleiben.
Der Report Authoring Skill arbeitet am Report-Layer: an Seiten, Visuals, Filtern, Slicern, Formatierung und Themes. Damit wird Power-BI-Reportentwicklung stärker wie Software Engineering behandelbar – mit Dateien, Git, klaren Scopes und Reviews.
Der eigentliche Sprung liegt deshalb nicht bei „AI baut Reports“, sondern bei einem kontrollierten Workflow aus PBIP/PBIR, Git, Agenten, Validierung und Review.
Was ist der Power BI Report Authoring Skill?
Der Power BI Report Authoring Skill ist ein von Microsoft dokumentierter Agentic Skill für die Bearbeitung von Power-BI-Berichten im dateibasierten PBIP-/PBIR-Format. Er ist aktuell als Preview eingeordnet. Das ist für produktive Entscheidungen wichtig: Die Architektur lässt sich bereits konkret erproben, Schnittstellen, Fähigkeiten und unterstützte Werkzeuge können sich aber noch verändern.
Der Skill nimmt natürlichsprachliche Anforderungen entgegen und übersetzt sie in Änderungen an der Report-Definition. Typische Aufgaben sind neue Seiten, Diagramme, Karten oder Slicer, das Anpassen von Filtern, Formatierungen und Themes oder das Modernisieren bestehender Visuals.
Damit unterscheidet er sich von einem klassischen Chat-Assistenten. Der Agent formuliert nicht nur eine Empfehlung, sondern arbeitet direkt an Dateien, die Teil eines Power-BI-Projekts sind. Eine automatisch erzeugte Änderung ist damit ein echtes Entwicklungsartefakt und sollte auch so behandelt werden.
Die breitere Architektur aus Modeling MCP, Remote MCP und Report Authoring ordnen wir in Power BI MCP: Modeling, Remote MCP und Report Authoring erklärt ein. Für den Report Authoring Skill ist vor allem eine Grenze entscheidend: Er ist für die Berichtsschicht zuständig, nicht für die Geschäftslogik im Modell.
Wo der Skill im Power-BI-Agentic-Stack sitzt
Agentic Power BI besteht aus mehreren Bausteinen, die unterschiedliche Aufgaben lösen. Sie sollten nicht austauschbar behandelt werden.
Report Planning strukturiert Anforderungen und den Weg von der Idee zur Umsetzung. Report Design hilft bei offener visueller Gestaltung und Designentscheidungen. Report Authoring setzt konkrete Änderungen an der PBIR-Reportdefinition um. Modeling MCP ist für Tabellen, Beziehungen, Measures, DAX und andere Änderungen am semantischen Modell zuständig. Remote Power BI MCP dient dagegen primär dazu, vorhandene Modelle abzufragen und Insights zu gewinnen.
Diese Trennung ist mehr als Produktlogik. Sie ist eine sinnvolle Governance-Grenze: Report Authoring verändert, wie Informationen dargestellt und gefiltert werden; Modeling MCP verändert, was Kennzahlen und Daten fachlich bedeuten.
Wer beide Ebenen in einem undifferenzierten Auftrag vermischt, erhöht das Risiko, dass ein Agent technisch plausible, fachlich aber unerwünschte Änderungen erzeugt. Teams sollten deshalb bereits im Auftrag festlegen, ob eine Anforderung den Report-Layer, das semantische Modell oder beide Ebenen betrifft.
Gerade beim Modell lohnt sich diese Trennung. Ein sauber aufgebautes semantisches Modell in Power BI bleibt die fachliche Grundlage, auf der der Agent später Visuals und Berichtsseiten aufbaut.
Warum PBIP und PBIR die eigentliche Grundlage sind
Der Skill funktioniert nicht nach dem Prinzip „Agent klickt wie ein Mensch durch Power BI Desktop“. Seine Stärke entsteht durch das Power BI Project Format, kurz PBIP, und die Power BI Report Definition, kurz PBIR. Beide Bausteine werden von Microsoft weiterhin als Preview dokumentiert.
PBIP zerlegt ein Power-BI-Projekt in dateibasierte Bestandteile. PBIR speichert den Report strukturiert in Dateien, unter anderem für Seiten, Visuals und Bookmarks. Damit lässt sich eine Änderung nicht nur speichern, sondern auch mit Git versionieren, vergleichen und im Review nachvollziehen.
Für agentische Entwicklung ist das entscheidend. In einer einzelnen binären Datei wäre schwer erkennbar, was ein Agent tatsächlich verändert hat. In PBIR kann ein Team Diffs prüfen, Änderungen in Branches isolieren und bei Bedarf auf einen bekannten Stand zurückgehen.
Ein guter Ausgangspunkt ist deshalb:
Bericht als PBIP-Projekt vorhalten,
aktuellen funktionsfähigen Stand committen,
Agent nur auf einer klar begrenzten Aufgabe arbeiten lassen,
Änderungen anschließend technisch und visuell prüfen.
So entsteht kein magischer „AI Report Builder“, sondern ein kontrollierter Entwicklungsprozess.
So sieht ein belastbarer Authoring-Workflow aus
Die größte Gefahr bei agentischer Report-Entwicklung sind nicht fehlende Ergebnisse, sondern Änderungen, die auf den ersten Blick plausibel wirken und erst später Layout-, Filter- oder Interaktionsprobleme zeigen. Deshalb sollte der Prozess in kleine, prüfbare Schritte zerlegt werden.
1. Einen belastbaren Ausgangspunkt sichern
Bevor der Agent arbeitet, wird der aktuelle PBIP-Stand committed. Dadurch ist klar, welche Dateien bereits vorhanden waren und welche Änderungen tatsächlich aus dem neuen Auftrag stammen.
2. Den Auftrag auf den Report-Layer begrenzen
Ein guter Prompt beschreibt nicht nur das gewünschte Ergebnis, sondern auch den Scope. Beispiel: „Ergänze auf der bestehenden Management-Seite einen Monatsvergleich und einen Slicer für Region. Verändere keine Measures und keine Beziehungen.“
Diese Scope-Grenze verhindert, dass Report- und Modelländerungen unkontrolliert vermischt werden.
3. PBIR in kleinen logischen Batches ändern
Statt einen kompletten Bericht in einem Schritt umzubauen, sollte der Agent Änderungen blockweise umsetzen: erst eine Seite, dann Visuals, anschließend Filter und Formatierung. Kleine Batches erleichtern Diff, Fehlersuche und Rollback.
4. Die Report-Definition validieren
Nach jedem logischen Änderungspaket muss die PBIR-Struktur geprüft werden. Ein Agent sollte Felder, Objekttypen oder Schema-Strukturen nicht aus dem Gedächtnis erraten, wenn die tatsächliche Definition beziehungsweise Capability geprüft werden kann.
5. In Power BI Desktop laden und rendern
Strukturell korrekt bedeutet noch nicht visuell korrekt. Deshalb gehört der Reload in Desktop zum Prozess. Dort zeigt sich, ob Visuals tatsächlich laden, Abstände stimmen, Filter funktionieren und die Seite lesbar bleibt.
6. Screenshot, Diff und fachliches Review
Am Ende werden Datei-Diff und gerenderte Fassung gemeinsam geprüft. Erst wenn technische und visuelle Änderungen nachvollziehbar sind, sollte der Branch gemergt werden.
Ein valides PBIR ist noch kein guter Bericht. Render-QA und fachliches Review bleiben Pflicht.
Damit unterscheidet sich ein produktiver Agenten-Workflow deutlich von ungeführtem Vibe Coding in Power BI: Geschwindigkeit ist willkommen, ersetzt aber keine Qualitätskontrolle.
Was der Report Authoring Skill gut kann
Der Skill ist besonders stark bei Aufgaben, die klar beschreibbar und auf der Report-Ebene verankert sind. Dazu gehören wiederkehrende Seitentypen, das Ergänzen von Visuals, Filter- und Slicer-Logik, Theme-Anpassungen oder definierte Modernisierungen bestehender Reports.
Interessant wird das bei größeren Reporting-Landschaften. Ein Team kann Design- und Strukturregeln explizit machen und dem Agenten wiederholbare Aufgaben geben. Dadurch sinkt der manuelle Aufwand für Fleißarbeit, ohne dass die fachliche Kontrolle aufgegeben werden muss.
Auch Varianten lassen sich schneller testen. Statt jedes Layout manuell aufzubauen, kann ein Agent einen Entwurf erzeugen, der anschließend anhand klarer Reporting-Standards bewertet wird. Dafür braucht es allerdings ein gutes Zielbild. Wer keine Regeln für Hierarchie, Visualauswahl oder Informationsdichte hat, automatisiert sonst nur Inkonsistenz.
Deshalb bleibt Dashboard Design in Power BI relevant: Der Authoring Skill beschleunigt die Umsetzung, entscheidet aber nicht automatisch, welche Darstellung für eine Managemententscheidung wirklich gut ist.
Was der Skill nicht übernehmen sollte
Drei Grenzen sind besonders wichtig.
Erstens: Das semantische Modell gehört nicht in den Report-Authoring-Scope. Neue Measures, veränderte Beziehungen oder fachliche Modelllogik sollten über Modeling MCP beziehungsweise die dafür vorgesehene Modellierungsfunktion bearbeitet und separat geprüft werden.
Zweitens: Visuelle Qualität kann nicht aus syntaktischer Validierung abgeleitet werden. Ein Report kann technisch valide sein und trotzdem eine schlechte Informationshierarchie, abgeschnittene Beschriftungen oder unruhige Interaktionen haben.
Drittens: Preview-Funktionen gehören nicht ungeprüft in einen geschäftskritischen Produktionsprozess. Teams sollten Versionen, Skill-Verteilung und unterstützte Werkzeuge beobachten und einen reproduzierbaren Fallback behalten.
Der Skill ist damit kein Ersatz für Power BI Desktop, BI-Governance oder erfahrene Report-Designer. Er verschiebt einen Teil der Ausführung in einen agentischen Entwicklungsprozess.
Git und Review werden wichtiger, nicht unwichtiger
Agentic Authoring macht es möglich, Reportänderungen stärker wie Code zu behandeln. Ein sinnvoller Branch enthält eine klar beschriebene Änderung. Der Pull Request zeigt die betroffenen PBIR-Dateien. Die gerenderte Fassung zeigt, ob die Änderung visuell funktioniert. Der Reviewer kann damit technische und fachliche Qualität gemeinsam beurteilen.
Je autonomer ein Agent arbeitet, desto wichtiger wird eine belastbare Änderungshistorie.
Für Governance sollten Unternehmen deshalb festlegen, welche Agenten in welchen Repositories arbeiten dürfen, welche Verzeichnisse verändert werden dürfen und welche Prüfungen vor einem Merge erforderlich sind. So wird aus „AI in Power BI“ ein steuerbarer Entwicklungsprozess statt eines zusätzlichen Schattenwegs neben der bestehenden BI-Governance.
Typische Einsatzszenarien im Unternehmen
Für den Einstieg eignen sich Aufgaben mit klaren Grenzen und niedrigem fachlichem Risiko. Ein BI-Team kann wiederkehrende Berichtsseiten aus einem definierten Muster aufbauen lassen. Ein CoE kann bestehende Reports an neue Layout- oder Theme-Regeln anpassen. Entwickler können zusätzliche Slicer, Karten oder Detailseiten erzeugen lassen und anschließend die Ergebnisse prüfen. Auch die Modernisierung von Alt-Visuals ist ein plausibler Use Case.
Weniger geeignet ist ein Auftrag wie „Mach unseren Management-Report besser“. Ohne Zielbild, Kennzahlenlogik und Designregeln fehlt dem Agenten die Entscheidungsgrundlage. In solchen Fällen sollten zuerst Report Planning und Report Design klären, was gebaut werden soll.
Für Unternehmen empfiehlt sich deshalb ein Reifegradpfad:
kleine Änderungen an bestehenden PBIP-Projekten,
wiederholbare Report-Muster mit Git und Review,
standardisierte Design- und Governance-Regeln,
erst danach weitergehende agentische Report-Erstellung.
Grenzen der Preview
Der aktuelle Produktstatus ist ein wesentlicher Teil der Bewertung. Der Report Authoring Skill sowie PBIP und PBIR werden weiterhin als Preview dokumentiert.
Das bedeutet nicht, dass Unternehmen das Thema ignorieren sollten. Jetzt ist ein guter Zeitpunkt, den Workflow mit nicht geschäftskritischen Projekten zu erproben, Standards zu entwickeln und zu verstehen, welche Prüfungen später automatisierbar sind.
Architekturentscheidungen sollten dabei reversibel bleiben. Repositories, Prompts und Review-Prozesse sollten nicht voraussetzen, dass heutige Skill-Namen, Verteilung oder Capability-Grenzen unverändert bleiben. Ein produktionsnaher Pilot braucht deshalb eine klare Scope-Grenze, vollständige Versionierung und einen manuellen Qualitätsweg, der auch ohne Agent funktioniert.
Entscheidungshilfe: Wann welcher Baustein?
Eine einfache Zuordnung hilft:
Anforderungen, Story und End-to-End-Vorgehen strukturieren → Report Planning
visuelle Richtung, Layout und Designentscheidungen klären → Report Design
Seiten, Visuals, Filter, Slicer, Themes und Formatierung in PBIR umsetzen → Report Authoring Skill
Tabellen, Beziehungen, Measures oder DAX verändern → Modeling MCP / Semantic Model Authoring
bestehende Modelle abfragen und Insights abrufen → Remote Power BI MCP
das gerenderte Ergebnis prüfen → Power BI Desktop plus visuelles Review
Diese Arbeitsteilung verhindert, dass ein einzelner Agent unnötig viele Verantwortlichkeiten übernimmt. Sie macht außerdem klarer, welche Art von Review nach einer Änderung notwendig ist.
Fazit: Agentic Authoring braucht mehr als gute Prompts
Der Power BI Report Authoring Skill macht eine Entwicklung sichtbar, die für BI-Teams wichtiger ist als ein einzelnes neues Feature: Reports werden zunehmend als strukturierte, versionierbare Artefakte behandelbar, die AI-Agenten kontrolliert verändern können.
Der produktive Wert entsteht nicht durch maximale Autonomie, sondern durch eine klare Trennung von Report- und Modell-Layer, kleine Änderungen, technische Validierung und visuelles Review.
PBIP, PBIR und Git schaffen dafür die technische Grundlage. Report Planning, Report Design, Report Authoring und Modeling MCP übernehmen unterschiedliche Rollen. Wer diese Rollen sauber trennt, kann Agenten beschleunigen lassen, ohne Kontrolle über fachliche Logik und Reportqualität abzugeben.
Nächste Schritte
Wenn ihr PBIP/PBIR, MCP und AI-Agenten nicht nur ausprobieren, sondern in einen kontrollierten Entwicklungs- und Governance-Prozess überführen wollt, unterstützen wir euch im Power BI Consulting bei Architektur, Standards und Umsetzung.
