BI Operations mit Agenten: Betrieb, Monitoring und Changes im laufenden Reporting.

Projekte werden geplant, der Betrieb passiert. In den 1.843 Tickets aus zwölf Projekten steckt die ehrliche Beschreibung dessen, was nach der Abnahme anfällt: Deployment-Verwechslungen zwischen Dev, Test und Prod, ein Bericht, der „auf dem Dev-Branch geöffnet mit Prod verbunden war“, Gateway-Refresh am Monatsende, Rechte, die in Prod fehlen, Rollenarten, die mitten im Monat auftauchen, Kostenarten, die SAP im neuen Geschäftsjahr neu nummeriert — 65 Tickets, bis jemand die Quelle findet. Dazu die Übergabe: „den SQL Data Mart an den neuen Entwickler des Kunden übergeben, mit dem Lineage-Graphen“, zweimal in einem Projekt.

Rund 30 Prozent der Projektkosten sind Fehlersuche; bei größeren Migrationen 30 bis 90 Tausend Euro. Nach dem Go-live wird daraus ein Dauerzustand, und er ist strukturell reaktiv: Ein Fehler fällt im Bericht auf, jemand geht manuell zurück durch Modell und Pipeline, findet die Ursache in der dritten Nachtschicht und weiß nicht, wer die Änderung gemacht hat. Mit KI-Agenten in der Entwicklung verschärft sich das: Nicht die Entwicklung wird zum Engpass, sondern Prüfung und Review — mehr Änderungen in kürzerer Zeit brauchen einen Betrieb, der sie sieht.

Der Kreislauf unterscheidet sich vom klassischen Betrieb in der Richtung: Er beginnt nicht beim Fehler im Bericht, sondern bei der Beobachtung der Metadaten — und er endet nicht mit einer Reparatur, sondern mit aktualisierter Dokumentation und einem nummerierten Change Request. Jede Station hat einen klaren Besitzer: Der Agent macht die Menge an den Stationen eins, zwei, drei und sechs; der Mensch entscheidet an Station vier; Station fünf ist Prozess.

• 1 Beobachten: täglich, auf Metadaten — Refresh-Status je Modell und Umgebung, Compliance-Score gegen die 61 Regeln, Lineage-Drift (neue oder gebrochene Kanten gegenüber dem Vortag), Rechte und Rollen, Strukturänderungen in den Quellen.
• 2 Befund: Regelverstoß mit Schweregrad, Abweichung einer Kennzahl zum Vortag oder zum Referenzwert, verwaistes Measure, Measure ohne Beschreibung, Spalte mit Personenbezug ohne Klassifikation — je Befund Objekt, Regel, Erklärung.
• 3 Vorschlag: der Agent repariert, dokumentiert und testet — als Vorschlag im PBIP/Git, nie direkt im Modell; mit Impact-Liste aus dem Graphen: welche Visuals und Berichte berührt sind.
• 4 Freigabe: ein Mensch, mit Name und Zeitstempel. Ein kritischer Verstoß bleibt blockiert, bis er behoben ist — auch wenn man den Agenten um eine Ausnahme bittet.
• 5 Change: nummerierter Change Request, Deployment durch Dev, Test und Prod, Datensätze parametrisiert, damit sie zwischen Test und Produktion umschalten; Monatsabschluss als eigener Workstream „Month-end stability“.
• 6 Doku und Log: Dokumentation aus dem ausgelieferten Modell neu erzeugt, Agent-Log und Regelverstoß-Scan als auditierbares Paket — die Nachweise für EU AI Act und DSGVO entstehen mit.

Die Beobachtung läuft ausschließlich auf Metadaten: Strukturen, Formeln, Beziehungen, Rollen, Refresh-Protokolle, Ausführungslogs. Der Agent sieht nicht, ob der Umsatz gestiegen ist; er sieht, ob das Measure, das den Umsatz berechnet, heute anders definiert ist als gestern, ob eine Spalte, an der 58 Objekte hängen, umbenannt wurde, und ob der Refresh um 06:10 durchgelaufen ist. Wo eine Abweichung in den Werten geprüft werden muss — Checksumme je Sparte gegen den Vortag —, läuft eine lesende DAX-Abfrage mit der Rolle des Betriebs; es verlassen nur aggregierte Befunde das Modell.

Ein Betrieb ohne Kennzahlen ist ein Kostenblock; ein Betrieb mit Kennzahlen ist ein Vertrag. Die vier Kennzahlen unten sind die, die sich in Projekten als vertragsfähig erwiesen haben — jede ist von beiden Seiten jederzeit neu messbar, keine ist eine Meinung. Der Compliance-Score als Abnahmekriterium steht bereits im Dokumentations-Kapitel; im Betrieb wird aus der Abnahmeschwelle eine Untergrenze, die täglich gehalten wird.

• Compliance-Score ≥ 75 Prozent, null kritische Verstöße — täglich gemessen; sinkt er, ist der Befund schon im Kreislauf, bevor jemand ihn sucht.
• Refresh-Erfolgsquote je Modell und Umgebung, mit Alarm vor dem Fachbereich — die Kennzahl für die 316 Deployment- und Refresh-Tickets.
• Tickets je Monat nach Cluster — Abweichung, Rechte, Performance, Doku; die Kurve muss sinken, sonst beobachtet der Agent das Falsche.
• Durchlaufzeit je Change — vom Befund bis zur freigegebenen Änderung in Prod; Referenz: 20 nummerierte Change Requests in drei Tagen umgesetzt, bei Sprint-Abnahme mit zehn Werktagen Prüffrist.

Der Takt bleibt, die Frequenz darin steigt. Sprints mit Abnahme per Pull Request und zehn Werktagen Prüffrist geben dem Fachbereich die Sicherheit, dass nichts unbemerkt in Produktion geht; innerhalb des Sprints laufen Befunde und Reparaturen täglich. Das ehrliche Angebot an den Kunden lautet: mehr Inhalt pro Sprint statt kürzerer Rechnung — der Agent verdoppelt nicht das Tempo der Freigabe, sondern die Menge, die je Freigabe geprüft vorliegt.

Die Rollen sind dieselben wie im Projekt, nur dauerhaft: Der Agent führt aus, schlägt vor und dokumentiert jeden Schritt; ein benannter Freigeber entscheidet und haftet dafür; Fachbereich, Datenschutz und IT werden über Protokoll und Befunde informiert. Data Stewards entscheiden im Rahmen der Richtlinie, welche Datenbereiche für den Agenten frei sind. Der Rahmen ist vertraglich: nur Metadaten, AVV nach Art. 28 DSGVO, KI-Zusatzvereinbarung, Prüfrecht des Auftraggebers — als Managed Agentic BI monatlich buchbar, mit Effort Cap statt offener Tagessätze und Cost Prediction statt Überraschung.

Ein guter Betrieb endet mit einem Kunden, der ihn allein weiterführen kann. Deshalb ist die Übergabe nicht der letzte Schritt, sondern Teil jeder Runde: Der Lineage-Graph wächst mit jedem Change, das Troubleshooting-Wiki wird aus den Befunden erzeugt, das Agent-Log ist der Nachweis — und alle drei gehen an das eigene Team. In einem Energietechnik-Projekt ist genau das zweimal passiert: Übergabe des Data Marts an den neuen Entwickler des Kunden, mit Lineage-Graph und Wiki, ohne Wissensverlust; der Agent trägt dort heute rund 15 Prozent der Entwicklungsaufgaben.

Die Reihenfolge ist dieselbe wie im ganzen Guide: Erst Ordnung, dann Tempo. Wer den Betrieb mit einem Agenten startet, bevor Lineage, Katalog und Regelsatz stehen, beobachtet ein Modell, das der Agent nicht versteht. Wer sie hat, bekommt einen Betrieb, der Fehler auf Metadaten findet, bevor sie im Bericht landen — und ein Team, das den nächsten Monatsabschluss nicht mehr in der Nachtschicht rettet. Das Betriebshandbuch im Arbeitsmaterial ist die Vorlage dafür: Signale, Kennzahlen, Rollen, Takt, Übergabe.