Power BI Dokumentation und Regelprüfung automatisieren: Compliance-Score statt Pflichtübung.

Dokumentation scheitert nicht am Willen, sondern an der Architektur. Sie wird als Extra geschrieben — am Projektende, als eigene Position, als Erstes gestrichen, wenn das Budget eng wird. Sie lebt woanders — im Wiki, in Confluence, in einer PowerPoint —, und die Änderung am Modell erreicht sie nie. Sie misst nichts — „ist dokumentiert“ ist eine Meinung, kein Prüfergebnis. Und niemand ist zuständig: Der Entwickler baut, der Fachbereich liest, keiner pflegt.

Das Ergebnis kennt jedes gewachsene Modell: 180 Measures, zwölf mit Beschreibung, drei davon heißen „Umsatz“. Der Best Practice Analyzer lief einmal und fand 212 Hinweise, von denen keiner behoben wurde, weil niemand wusste, welche davon wichtig sind. Und im Audit die Frage, die niemand beantworten kann: Wer hat „Umsatz_alt“ geändert, wann und warum? Für einen KI-Agenten ist dasselbe Modell unlesbar — er rät die fehlenden drei von fünf Feldern, wie Kapitel 7 zeigt. Dokumentation ist deshalb keine Pflichtübung, sondern die zweite Schicht, die ein Agent braucht.

Der Regelsatz ist über Projekte gewachsen und wird am Ende jeder Projektphase eingefroren: Die Fassung, gegen die abgenommen wurde, bleibt der Standard für die Folgephasen. Jede Regel hat eine Kategorie, einen Schweregrad (kritisch, hoch, mittel, Hinweis) und einen Objekttyp, auf den sie wirkt — Knoten oder Kante im Graphen. Die Tabelle zeigt je Kategorie drei Beispielregeln; der vollständige Auszug mit zwanzig Regeln ist das Arbeitsmaterial dieses Kapitels.

Der Score ist der Anteil erfüllter Regeln, gewichtet nach Schweregrad, über alle Objekte des Modells. Er ist kein Schulzeugnis, sondern ein Messwert, den beide Seiten jederzeit neu laufen lassen können — und genau das macht ihn vertragsfähig. In einem laufenden Projekt bei einem regionalen Energieversorger steht er als Abnahmekriterium im Einzelauftrag: Ausgangswert 60 Prozent, Zielwert mindestens 75 Prozent, null kritische Verstöße. Traditionelle Projekte nehmen auf „sieht in der Demo richtig aus“ ab; dieses nimmt auf eine Zahl ab.

Der Score hat einen zweiten Nutzen, der oft übersehen wird: Er ordnet die 212 BPA-Hinweise, die niemand abarbeitet. Dreizehn kritische Regeln zuerst, dann die hohen, dann der Rest — und das Modell steigt in der Reihenfolge, die für Agenten und Copilot am meisten bringt. Welcher Score für welche Stufe des Reifegradmodells nötig ist, steht dort: Stufe 4 heißt Regelsatz und Freigabe im Betrieb, nicht nur im Projekt.

Der Best Practice Analyzer in Tabular Editor ist ein gutes Werkzeug, und viele unserer Regeln haben dort ihren Ursprung. Der Unterschied liegt nicht in den Regeln, sondern darin, wann sie laufen und was passiert, wenn sie verletzt sind. Der BPA läuft, wenn ein Entwickler ihn startet, und gibt eine Liste aus. Der Regelsatz läuft vor jedem Schreibvorgang eines Agenten, blockiert kritische Verstöße und schreibt jeden Befund mit Datum und Objekt ins Protokoll — das ist der Nachweis, den der EU AI Act verlangt.

Der Kreislauf hat fünf Stationen, und nur eine davon ist Handarbeit. Der Agent prüft das Modell gegen die 61 Regeln je Knoten und Kante; jeder Verstoß wird zum Befund mit Schweregrad, Objekt und Erklärung. Der Agent repariert — als Vorschlag im PBIP, nie direkt im Modell: Beschreibung ergänzen, Measure umbenennen, Zeitintelligenz auf die Datumstabelle umstellen, inaktive Beziehung dokumentieren. Ein Mensch gibt jede Reparatur frei, mit Name und Zeitstempel. Dann wird die Dokumentation aus dem Modell erzeugt — vollständig, nicht ergänzt.

Im Projekt läuft dieser Kreislauf je Sprint; im Betrieb täglich. Was er kostet, steht im Kosten-Kapitel: Die Regelprüfung ist der Fall mit der geringsten Vorarbeit und der höchsten Wiederholung — genau dort, wo sich der Graph am schnellsten rechnet. Was er verhindert, steht in den Tickets: 261 von 1.843 Projekttickets drehen sich um Zahlen, die abweichen, und ein großer Teil davon hat eine Regelverletzung als Ursache, die vor dem Go-live sichtbar gewesen wäre.

Wenn Dokumentation aus dem Modell erzeugt wird, kostet sie nichts mehr zu produzieren — deshalb steht sie im Angebot des Referenzprojekts als eigene Position mit 0,00 Euro und wird bei Abnahme übergeben. Sie enthält je Measure die fünf Felder, je Tabelle Quelle und Zweck, je Beziehung die Begründung, je Seite Zielgruppe und Filter, und je Objekt die Lineage bis zur Quellspalte. Sie kann nicht veralten, weil sie bei jeder Änderung neu entsteht, und sie ist in Fachsprache geschrieben, weil der Agent die Beschreibungen aus Katalog und Kontext zieht, nicht aus dem Formelnamen.

Was bleibt, ist die eine Entscheidung, die kein Agent trifft: Welche Beschreibung ist fachlich richtig? Ein Agent schlägt „Umsatz netto: Betrag abzüglich Rabatt und Skonto, in Euro, Verantwortlich: Controlling“ vor — ob Skonto dazugehört, sagt der Fachbereich. Die Freigabe ist deshalb keine Formalität, sondern der Moment, in dem Dokumentation zur Definition wird. Und mit jeder freigegebenen Definition wird das Modell für den nächsten Agenten, für Copilot und für den nächsten Entwickler lesbarer.