Governance gehört ins System, nicht in einen Ordner.
Ein Konzept, das niemand liest, hilft in keiner Prüfung. Wir bauen Rollen, Herkunftsnachweise, Qualitätsregeln und Protokolle dort ein, wo die Daten tatsächlich verarbeitet werden — und schreiben die Dokumentation daraus, nicht umgekehrt.
Wann Unternehmen uns rufen
Selten, weil jemand Lust auf Governance hat. Sondern weil einer dieser drei Sätze im Raum steht:
- „Welche Zahl gilt denn nun?“ Drei Bereiche rechnen dieselbe Kennzahl unterschiedlich, alle drei vertretbar, und niemand ist befugt zu entscheiden.
- „Woher kommt dieser Wert?“ Im Bericht steht eine Zahl, und der Weg von der Quelle bis dorthin lässt sich nicht in vertretbarer Zeit nachvollziehen.
- „Wer darf das eigentlich sehen?“ Berechtigungen sind über Jahre gewachsen, wurden bei Umzügen mitgeschleppt, und niemand traut sich, etwas wegzunehmen.
Alle drei sind keine Werkzeugprobleme. Sie entstehen, wenn Verantwortung für Daten nie zugeordnet wurde — und lassen sich deshalb auch nicht durch den Kauf eines Katalogprodukts lösen.
Ein Katalog, den niemand pflegt, ist nach neun Monaten schlechter als kein Katalog. Denn dann glaubt man ihm noch.
Was wir aufbauen
| Baustein | Was er leistet |
|---|---|
| Verantwortlichkeiten | Je Datenbereich und je Kennzahl eine benannte fachlich verantwortliche Person — keine Abteilung, ein Mensch. Das ist der Baustein, an dem die meisten Vorhaben scheitern, weil er politisch ist und nicht technisch. |
| Kennzahlendefinitionen | Eine verbindliche Herleitung je Kennzahl, versioniert und mit Gültigkeitszeitraum. Ändert sich die Definition, ist nachvollziehbar, ab wann welche Fassung galt — sonst brechen Zeitreihen unbemerkt. |
| Katalog | Ein Verzeichnis dessen, was es gibt und was es bedeutet. Automatisch befüllt aus den Systemen, nicht per Hand gepflegt. Was nur manuell entsteht, veraltet innerhalb eines Jahres. |
| Datenherkunft | Der Weg jeder Zahl von der Quelltabelle bis in den Bericht, technisch erfasst statt gemalt. Damit lässt sich die Frage nach der Herkunft in Minuten beantworten statt in Tagen — und die Folgen einer Änderung vorher abschätzen. |
| Qualitätsregeln | Prüfungen, die bei jeder Beladung mitlaufen: Vollständigkeit, Wertebereiche, Abgleich mit dem Quellsystem. Mit definierter Eskalation, wenn eine Regel bricht — sonst laufen die Prüfungen ins Leere. |
| Berechtigungen | Ein Rollenmodell entlang fachlicher Aufgaben statt gewachsener Einzelrechte, und ein wiederkehrender Nachweis, wer worauf Zugriff hat. Einschließlich der unbequemen Aufräumarbeit. |
| Protokolle | Wer hat wann welche Daten abgefragt und welche Beladung ist wann gelaufen. Aufbewahrt in einer Form, die einer Prüfung standhält und nicht erst aufbereitet werden muss. |
Der Unterschied zu einem Governance-Projekt
Klassische Vorhaben dieser Art beginnen mit einem Zielbild, führen über ein Rahmenwerk und enden mit einem Foliensatz, den die Fachbereiche nie zu sehen bekommen. Was danach im Betrieb passiert, bleibt unverändert.
Wir gehen umgekehrt vor: an einem konkreten, strittigen Bereich anfangen — meistens dem, über den zuletzt gestritten wurde. Dort Verantwortlichkeit klären, Definition festschreiben, Herkunft technisch erfassen, Prüfungen einbauen. Erst wenn das an einem Beispiel funktioniert, wird daraus ein Vorgehen, das sich auf weitere Bereiche übertragen lässt.
Der Vorteil ist nicht nur Geschwindigkeit. Ein Fachbereich, der einmal erlebt hat, dass die Frage nach der Herkunft in Minuten beantwortet ist, macht bei den nächsten Bereichen freiwillig mit.
Was wir nicht anbieten. Wir schreiben keine Richtlinien, die anschließend niemand anwendet, und wir verkaufen kein Werkzeug. Wenn ein Katalogprodukt bei Ihnen sinnvoll ist, richten wir es ein — aber die Entscheidung dafür hat kein Provisionsinteresse hinter sich.
Was Aufsicht und Prüfung davon haben
Die Anforderungen unterscheiden sich je nach Haus, laufen aber auf dieselben Fragen hinaus: Ist nachvollziehbar, woher eine Zahl kommt. Ist geregelt, wer sie verantwortet. Ist belegbar, wer darauf zugegriffen hat. Ist dokumentiert, was sich wann geändert hat.
- Banken und Finanzdienstleister: Anforderungen an Datenaggregation und Risikoberichterstattung sowie an das Auslagerungs- und IT-Risikomanagement — einschließlich der Nachweispflichten aus DORA.
- Versicherer: Nachvollziehbarkeit der Datengrundlagen für versicherungstechnische Berechnungen und Berichterstattung.
- Versorger und kritische Infrastruktur: Nachweise zu Zugriffen, Protokollierung und Wiederanlauf.
- Übergreifend: Für KI-Anwendungen verlangt der EU AI Act Transparenz über Datengrundlagen und Dokumentation — vieles davon fällt bei sauberer Governance ohnehin an.
Zur Einordnung: Wir bereiten Nachweise so auf, dass Ihre Compliance und Ihre Revision damit arbeiten können. Die rechtliche Bewertung, welche Anforderung in welchem Umfang für Ihr Unternehmen gilt, treffen Sie und Ihre Fachabteilung — nicht wir.
Und der Zusammenhang mit KI
Governance wirkt hier nicht als Bremse, sondern als Voraussetzung. Ein Assistent, der Berechtigungen respektieren soll, braucht ein Rollenmodell, das diesen Namen verdient. Einer, der Zahlen nennt, braucht verbindliche Kennzahlendefinitionen. Und einer, der geprüft werden soll, braucht Protokolle, die auch die Zwischenschritte festhalten.
Das ist der Grund, warum wir Unternehmen, die mit KI beginnen wollen, regelmäßig raten, einen abgegrenzten Governance-Schritt vorzuziehen. Nicht das ganze Programm — die zwei, drei Dinge, ohne die die Anwendung später nicht abnahmefähig ist.