Data Governance — belegtes Verhalten, nicht Richtlinien auf Papier

Arbeitsentwurf — Prüfung vor der Veröffentlichung. Dieser Grundpfeiler trägt die Betriebsmodell-Hälfte von Cordatas Fabric + Mesh Argument. Die Fabric-Substrat-Hälfte — Katalog, Lineage, Policy-as-Code-Durchsetzung — steht im Data-Engineering-Grundpfeiler und in der Fabric + Mesh auf AWS-Referenz.

Governance ist Entscheidungen plus Nachweise — nicht Papier

Data Governance ist einer der am meisten verwaschenen Begriffe im Enterprise-Data-Gespräch. Die Definition am ersten Tag falsch zu bekommen kostet ein Programm Jahre und Millionen.

Drei häufige Verwechslungen trüben jedes Gespräch, in das Cordata hineingeht. Sie zuerst zu benennen — mit dem konkreten Fehlermodus, den jede erzeugt — spart eine Stunde später:

Data Governance ist nicht Datenmanagement. Datenmanagement ist die Pipeline- / Speicher- / Katalog-Schicht — das technische Fundament. Das ist die Fabric-Hälfte des Arguments, behandelt im Data-Engineering-Grundpfeiler. Die häufigste Verwechslung, die Cordata sieht: Eine Bank stellt einen Chief Data Officer ein, um „Governance zu reparieren", und bekommt stattdessen ein Data-Lake-Modernisierungsprogramm. Achtzehn Monate später ist die Plattform stark verbessert; wer was unter welchen dokumentierten Bedingungen und mit welchem Nachweis sehen darf, ist dasselbe unentschiedene Chaos wie vorher.
Data Governance ist nicht Stammdatenmanagement. MDM ist die Form der gemeinsam genutzten Referenzdaten — Kundenstamm, Produktstamm, Kontenrahmen. In einem Mesh ist MDM eine Fachbereichs-Domäne wie jede andere, nicht die Governance-Schicht über dem Mesh. Die Verwechslung: Ein Customer-360-Projekt wird als „Governance-Initiative" verkauft, weil es Referenzdaten behandelt. Sechs Monate später existiert eine Golden-Record-Engine; es wurde keine Entscheidung getroffen, wer auf den Golden Record zugreifen darf, unter welchen Bedingungen, zu welchem Zweck — diese Entscheidungen fallen weiterhin per Ad-hoc-E-Mail.
Data Governance ist nicht IT-Sicherheitsrichtlinie. Zugriffskontroll-Primitive (Rollen, Berechtigungen, Verschlüsselungsschlüssel) sind das, womit Governance Entscheidungen durchsetzt. Aber die Entscheidungen selbst — wer besitzt diese Daten, wer darf sie unter welchen Bedingungen sehen, wie wird eine Änderung autorisiert — sind Governance, nicht Sicherheit. Die Verwechslung: Das IT-Sicherheitsteam wird gebeten, Governance zu verantworten, weil „sie schon Zugriffskontrolle machen". Ergebnis: Role-Based Access Control (RBAC) wird gegen Job-Titel vergeben statt gegen Datenzwecke. Ein Marketing-Analyst kann Fraud-Transaktions-Logs abfragen, weil beide unter dieselbe breite Analytics-Rolle fallen — nicht weil jemand im Fraud-Fachbereich eine gezielte Entscheidung über diese Freigabe getroffen hat.

Die positive Definition, mit der Cordata arbeitet, ist bewusst klein gehalten:

Data Governance ist die Menge der Entscheidungen über Daten — wer sie besitzt, wer sie unter welchen Bedingungen sehen darf, wie eine Änderung autorisiert wird — plus die Nachweise, dass diese Entscheidungen tatsächlich gelebt und nicht nur dokumentiert werden.

Sie sitzt über dem Fabric-Fundament und innerhalb des Mesh-Betriebsmodells. Sie ist Verhalten mit Nachweis, nicht Papier. Jede substanzielle Behauptung im Rest dieses Grundpfeilers ist stromabwärts von dieser Definition.

Drei Jahre nach „wir haben ein Data Governance Council"

Ein DACH-Mid-Market-Unternehmen startet Anfang 2023 ein Data-Governance-Programm. Ein Steuerungskomitee wird gebildet, mit hochrangigen Sponsoren aus IT, Recht, Risiko und zwei Fachbereichen. Ein Governance-Framework wird gewählt — ein anerkanntes Branchen-Framework wie DAMA-DMBOK wird in der Kickoff-Präsentation genannt. Ein Council trifft sich monatlich. Richtlinien werden geschrieben für Zugriffsverwaltung, Datenklassifikation, Aufbewahrung, Weitergabe an Dritte. Eine RACI-Matrix wird unterschrieben. Verzeichnisse von Verarbeitungstätigkeiten (RoPAs, das nach DSGVO Art. 30 erforderliche Verzeichnis) werden für jede Verarbeitungsoperation quer über den DACH-Fußabdruck befüllt. Compliance zeichnet die Artefakte bis Ende Q3 ab. Es gibt Sekt.

Fünfzehn Monate später trifft sich das Council quartalsweise, dann nur noch vor Audits. Richtlinien aus 2023 stehen im Wiki; ein Vergleich mit dem tatsächlichen Grant-Log der Plattform zeigt, dass die beiden seit neun Monaten nicht übereinstimmen. Fachbereichsteams sagen — off the record —, dass sie bei fachbereichsübergreifendem Zugriff ihren Kollegen slacken, nicht das Governance-Council. Der RoPA ist bekanntlich zu etwa 40 % falsch. Das Compliance-Team weiß es. Niemand hat das Mandat, das zu beheben, weil „die Fachbereiche das besitzen" — und die Fachbereiche sagen „Compliance besitzt das".

Wir bei Cordata haben dieses Muster über die Jahre immer wieder gesehen — in Variationen, quer durch Banking, Versicherung und Telekommunikation, als Engineers auf diesen Projekten. Zwei konkrete Arten, wie die obige Definition regelmäßig nicht erfüllt wird, tauchen wiederholt auf:

Der zentrale Engpass. Governance-Entscheidungen laufen über ein zentrales Team oder Council; die Skalierung übersteigt die Kapazität; Genehmigungszeiten wachsen; Fachbereichsteams umgehen es. Shadow-IT taucht unter einem anderen Namen wieder auf — eine geteilte Confluence-Seite mit „temporären Ausnahmen", die nie ablaufen. Entscheidungen werden getroffen — nur nicht von jemandem, der Verantwortung trägt.
Die Artefakte-Abweichung. Richtlinien, RACI, RoPAs, Datenschutz-Folgenabschätzungen (DPIAs, gemäß DSGVO Art. 35) existieren und bestehen das Audit — aber sie spiegeln nicht wider, was tatsächlich mit Daten passiert, und treiben es auch nicht. Die Artefakte und die Realität driften still auseinander, und alle wissen es. Der Nachweis ist Dokumentation, nicht Verhalten.

Beide sind derselbe zugrundeliegende Bruch der Definition — Entscheidungen und Nachweise sind entkoppelt — der sich in zwei Richtungen zeigt. Der Satz, den Cordata Interessenten mitgibt, wenn das Governance-Gespräch diesen Punkt erreicht:

Eine Richtlinie, der niemand folgt, ist leeres Theater. Eine Warteschlange, die niemand abarbeiten kann, ist ein manueller Engpass. Keines davon ist Governance.

Die DORA-Wende — Governance ist jetzt Verantwortung des Vorstands

Die Geschichte oben spielte sich 2023-2024 ab, bevor DORA in Kraft trat. Seit Januar 2025 haben sich die persönlichen Stakes verändert.

Der Digital Operational Resilience Act trat im Januar 2025 in Kraft; die Durchsetzung wurde Ende 2025 aktiv. Für jedes DACH-Haus, das Finanzdienstleistungen berührt, verwandelt DORA Governance von einem Compliance-Overhead in eine aufsichtsrechtliche Verantwortungskette, die bis zum Leitungsorgan reicht:

Art. 5 — IKT-Risikomanagement ist eine Verantwortung des Leitungsorgans, keine delegierbare Aufgabe. Der Vorstand genehmigt die Strategie, und der Vorstand unterzeichnet die Restrisiko-Akzeptanz.
Art. 5(2) — Governance-bezogene Fehler können persönliche Haftung an Mitglieder des Leitungsorgans binden.
Art. 15–17 — IKT-bezogene Vorfallsmeldungen müssen innerhalb enger regulatorischer Fenster das Leitungsorgan erreichen, mit einer Verantwortungskette, die von Erkennung bis Eskalation dokumentiert ist.
Art. 24 — das Programm zum Testen der operativen digitalen Resilienz (TIBER-EU) erfordert Genehmigung und Berichterstattung durch das Leitungsorgan.
Art. 28–30 — Drittparteien-Risikomanagement wendet dieselbe nachweisgestützte Verantwortungskette auf Auftragsverarbeiter an.

Der praktische Effekt: Wenn der RoPA zu 40 % falsch ist, ist das jetzt ein Leitungsorgan-Thema mit persönlicher Haftung — kein Papierkram-Problem eines Compliance-Teams. Governance ist keine Richtlinien-Ordner-Frage mehr. Es ist eine persönliche Haftungsfrage auf Vorstandsebene, belegt durch Verhalten und Audit-Trail, nicht durch Wiki-Seiten.

DORA ist der Beschleuniger. Was Cordata Verhalten mit Nachweis nennt, ist die Form, die ein Aufseher jetzt einfordern kann — kein Nice-to-Have mehr.

Föderierte computergestützte Governance — die vier Züge

Das Governance-Modell, das den Kontakt mit einem echten Mesh — und mit DORA — überlebt, ist föderierte computergestützte Governance: gemeinsam entschiedene Richtlinien, automatisch an Plattformgrenzen durchgesetzt, aus Verhalten belegt statt in ein Wiki getippt. Vier Züge machen es funktionsfähig:

Föderierte Entscheidungen. Richtlinienfragen (Aufbewahrungsfristen, Sensitivitäts-Taxonomie, fachbereichsübergreifende Freigaberegeln) werden von einem Council mit rotierender Vertretung aus den Fachbereichen plus dem Plattformteam entschieden. Nicht ein dauerhaftes zentrales Gremium mit Veto-Recht. Die Aufgabe des Councils ist es, gemeinsame Entscheidungen zu erreichen, nicht einzelne Anfragen zu genehmigen.
Computergestützte Durchsetzung. Entscheidungen werden als Policy-as-Code ausgedrückt — Open Policy Agent-Regeln, LakeFormation LF-Tag-Ausdrücke, Databricks Unity Catalog-Grants, dbt-Modellkontrakte. Die Plattform führt sie automatisch an Lese-, Schreib- und Abfragegrenzen aus. Es gibt keinen separaten „Compliance-Schritt" zwischen einem Fachbereichsteam und der Richtlinie, die wirksam wird.
Nachweis aus Verhalten. Audit-Artefakte (wer hat was gelesen, wessen Daten wohin geflossen, welche Richtlinie hat wann gefeuert) werden aus echten Systemereignissen erzeugt — CloudTrail, dem Lineage-Graphen, dem Katalog-Subscription-Log. Sie werden nicht einmal im Quartal von einem Compliance-Team in eine Tabelle getippt. Das ist es, was den RoPA aktuell und DORA-antwortfähig hält.
Gemeinsames Vokabular, lokales Eigentum. Die Tag-Ontologie (LF-Tags, Purview-Labels, Collibra-Klassifikationen — das konkrete Werkzeug ist weniger wichtig als die Form) ist über die Organisation hinweg geteilt, aber jeder Tag-Wert wird von einem spezifischen Fachbereich verantwortet. Sensitivität ist ein gemeinsames Vokabular; diese Spalte ist sensitivity=high ist eine Entscheidung des Fachbereichs.

Die Fabric + Mesh auf AWS-Referenz geht die konkrete AWS-Implementierung aller vier Züge durch — LF-Tag-Ontologie, zweischichtige DataZone-Segmentierung, die Katalog-über-Katalogen-Falle und die drei DACH-Compliance-Prüfpunkte in echtem Terraform. Die Aufgabe dieses Grundpfeilers ist das Betriebsmodell; die Aufgabe des Begleiters ist die Maschinerie.

Behaviour-first Governance

Die vier Züge fügen sich zu einer spezifischen Betriebsform zusammen. Der zentrale architektonische Anspruch dieses Grundpfeilers, würdig als Pull-Quote:

Governance ist das, was die Plattform durchsetzt, was die Fachbereiche tun und was die Nachweise zeigen — in dieser Reihenfolge. Die Artefakte (Richtlinien, RACIs, RoPAs) sind Nebenprodukte dieses Verhaltens, keine Lieferergebnisse an sich.

Kontrast zwischen zwei Betriebsformen:

Artefakt-First-Governance. Ein Richtlinienbinder wird geschrieben. Eine RACI wird unterschrieben. Eine vierteljährliche Compliance-Prüfung findet statt. Artefakte sind das Ziel; der Kalender wird um sie herum gesetzt. Was mit Daten tatsächlich passiert — wer sie liest, wer sie in was joint, wessen Abonnement-Genehmigung durchgewinkt wurde — ist undokumentiert und oft unbekannt. Sechs Monate später driften Artefakte und Realität auseinander. Zwölf Monate später wissen es alle, und niemand hat das Mandat, es zu beheben.

Behaviour-First-Governance. Richtlinien sind als ausführbare Regeln an Plattformgrenzen kodiert — ein Grant ist ein Richtlinienausdruck, eine Abonnement-Genehmigung ist ein signiertes Audit-Ereignis. Die RACI wird aus den Eigentümer-Metadaten des Katalogs abgeleitet, die die Fachbereiche aktuell halten, weil ihr eigener Abonnement-Workflow davon abhängt. Die vierteljährliche Compliance-Prüfung wird aus dem Lineage-Graphen und dem Subscription-Log gezogen, nicht getippt. Artefakte stimmen immer mit der Realität überein, weil sie aus ihr erzeugt werden.

Diagramm-Erläuterung. Drei Schichten, von unten nach oben. Das Fabric-Fundament (unten) liefert Katalog, Lineage-Graph, Policy-as-Code-Engine und Subscription-Log — die Rohereignisse und Metadaten, von denen alles darüber abhängt. Die föderierte Governance-Schicht (Mitte) nimmt diese Rohereignisse und macht drei Dinge daraus: föderierte Entscheidungen (das Council erreicht gemeinsame Richtlinienpositionen), computergestützte Durchsetzung (diese Positionen werden als Policy-as-Code ausgedrückt, die an Plattformgrenzen feuert), und Nachweiserzeugung (die Audit-Aufzeichnungen, die beweisen, dass Durchsetzung stattfand). Die Artefakte (oben) — RoPA, RACI, Audit-Bericht — werden aus der Schicht darunter erzeugt, nicht von Hand getippt. Der gestrichelte Pfeil zurück zur mittleren Schicht schließt die Schleife — die Artefakte informieren die nächste Council-Entscheidung, die Durchsetzung ändert, die ändert, was das Audit zeigt.

Der Begleitbeitrag Behaviour-first Governance in der Praxis geht die konkrete Maschinerie durch — wie man den RoPA aus Lineage, die RACI aus Katalog-Eigentum und den Audit-Bericht aus dem Subscription-Log erzeugt — mit echtem Terraform, SQL und YAML.

Mesh liefert die Form. Fabric liefert die Durchsetzungs- und Nachweisschicht. Zusammen ermöglichen sie Behaviour-First-Governance. Ohne beide zerfällt Governance innerhalb eines Jahres zurück zu Artefakt-First — die Geschichte weiter oben in diesem Grundpfeiler wiederholt sich.

Ein Drei-Wege-Vertrag — Plattform, Fachbereich, Council

Föderierte computergestützte Governance ist nur unter einem Drei-Wege-Vertrag stabil. Plattform, Fachbereich und Governance-Council schulden einander jeweils etwas Spezifisches und Nicht-Verhandelbares.

Die Plattform schuldet der Governance:

Policy-as-Code-Primitive, gegen die Governance autoren kann, nicht nur konsumieren — eine Richtliniensprache, die ein Fachbereichs-Engineer direkt schreiben kann, schlägt eine, die eine Übersetzung durch das zentrale Team verlangt
Eine Nachweiserzeugungs-Oberfläche (Audit-Log + Lineage + Subscription-Aufzeichnungen), die die Frage eines Aufsehers „beweisen Sie es" übersteht
Einen Änderungs-Autorisierungs-Workflow, der selbst audit-belegt ist — jede Richtlinienänderung trägt ihre eigene Aufzeichnung

Der Fachbereich schuldet der Governance:

Metadaten-Korrektheit für die Tags, gegen die Governance-Richtlinien Grants vergeben — ein falsches sensitivity=confidential auf einer sensitivity=high-Spalte ist ein echter Governance-Fehler, kein Papierkram-Fehler
Rechtzeitige Bearbeitung von Abonnement-Prüfungen — die Plattform kann die Anfrage routen, aber nur der Fachbereich kann sie genehmigen
Ehrliche Erklärung der abgeleiteten Datennutzung innerhalb des Fachbereichs — damit der RoPA keine Fiktion ist

Die Governance schuldet Plattform und Fachbereich:

Entscheidungen innerhalb SLA-definierter Fenster — ein föderiertes Council, das langsamer liefert als ein zentraler Engpass, ist schlimmer als beides
Richtlinien, die zu 80 % der Zeit kleiner sind als die letzte Version — Governance driftet standardmäßig in Richtung Komplexität; die Disziplin ist Subtraktion
Keine Richtlinie, die nicht an einer Plattformgrenze durchgesetzt werden kann — wenn sie nur durch Wachsamkeit und Schuldzuweisung durchgesetzt werden kann, ist es keine Richtlinie

Diagramm-Erläuterung. Governance sitzt zwischen Plattform und Fachbereich, nicht über ihnen — ein Hub mit Zwei-Wege-Verpflichtungen zu jeder Seite. Die drei Bullet-Listen oben sind der exakte Inhalt jedes Austauschs: Plattform und Fachbereich schulden der Governance unterschiedliche Dinge (Nachweismaschinerie auf der einen Seite, Metadatenqualität und ehrliche Selbst-Erklärung auf der anderen), und die Governance schuldet beiden dieselben drei Dinge zurück — Entscheidungen innerhalb der SLAs, Richtlinien, die mit der Zeit schrumpfen, und keine Richtlinie, die sie nicht an einer Plattformgrenze durchsetzen kann. Jede Seite, die ihre Verpflichtungen nicht erfüllt, lässt die Komposition zusammenbrechen.

Wo eine Seite aufhört, ihre Seite des Vertrags zu erfüllen, kollabiert die Komposition zurück in den zentralen Engpass oder die Artefakte-Abweichung von weiter oben. Cordata-Mandate beginnen damit, zu prüfen, welche Verpflichtungen bereits erfüllt sind, welche aspirational sind und welche still kollabiert sind.

Leitplanken, keine Gates — angewandt auf Governance

Cordatas Position zu der Frage, wo Governance in einem Fabric + Mesh Hybrid sitzt — übernommen aus der Haltung des Data-Engineering-Grundpfeilers —, ist, dass Automatisierung Governance schneller und sicherer macht als manuelle Prüfung, und Fachbereiche niemals durch einen zentralen Engpass zwingt.

Die Unterscheidung ist konkret. Ein Gate ist eine Warteschlange des zentralen Teams für Richtlinienausnahmen — jede Anfrage steht in der Schlange, die menschliche Kapazität begrenzt den Durchsatz, Entscheidungen dauern Tage. Eine Leitplanke ist ein Richtlinienausdruck, der entweder den Zugriff verweigert (mit audit-belegter Aufzeichnung) oder gewährt (mit audit-belegter Aufzeichnung) an der Plattformgrenze — keine Schlange, kein Engpass, immer belegt. Gates schützen durch Veto und werden zum Engpass, den sie verhindern sollten. Leitplanken schützen durch Information — die Plattform führt die Entscheidung automatisch aus, das Audit zeigt, was gefeuert hat und warum.

Fast alle Governance-durch-Veto-Systeme, die Cordata beobachtet hat, degenerieren letztlich zu Shadow-IT-Umgehungen, weil die Veto-Schlange innerhalb eines Jahres ihre menschliche Kapazität übersteigt. Leitplanken skalieren mit der Plattform, weil sie aus denselben aktiven Metadaten erzeugt werden, die die Fabric bereits pflegt.

Die DACH-Kräfte jenseits von DORA

DORA bekommt oben einen eigenen Abschnitt, weil es die persönlichen Stakes verändert hat. Der Rest der DACH-regulatorischen und organisatorischen Landschaft macht Behaviour-First-Governance besonders passend, und Cordata-Mandate planen um all das herum:

BaFin § 25b KWG und FINMA-Cloud-Outsourcing — aufsichtliche Prüfung von Auslagerungen erfordert belegte Kontrollketten. Eine unterschriebene Richtlinie reicht nicht — der Nachweis, dass die Kontrolle tatsächlich lief, muss aus der Plattform hervorbringbar sein.
DSGVO Art. 28-30 organisatorische Seite — Auftragsverarbeiter-Pflichten erfordern dokumentierte Prozesse UND nachweisbare Durchsetzung. Verhalten-mit-Nachweis, erneut, angewandt auf Auftragsverarbeiter-Grenzen.
Betriebsrat / Personalrat-Rhythmus — die Kadenz von Richtlinienänderungen ist langsamer als die Kadenz von Plattformänderungen; Governance-Design muss beides in Einklang bringen und darf nicht so tun, als gäbe es die Diskrepanz nicht. Sprint-Geschwindigkeit ist ein realer Preis dafür, das richtig zu machen; die Alternative — ein Rollback, nachdem nachgelagerte Konsumenten gegen eine Änderung gebaut haben — kostet mehr.
Multi-Jurisdiktions-Governance — DE / CH / AT plus HU / SK / PL Backoffice ist eine häufige Konstellation. Wo endet die DE-Governance und wo beginnt die CH-Governance? Föderiertes Eigentum ist die einzige Struktur, die das sauber skaliert.

Die technische Durchsetzungsseite dieser Kräfte wird in der Fabric + Mesh auf AWS-Referenz behandelt. Die Behaviour-First-Maschinerie — wie die Artefakte, die diese Kräfte fordern, tatsächlich erzeugt werden — wird im Begleitbeitrag Behaviour-first Governance in der Praxis behandelt. DSGVO Art. 17 (Recht auf Löschung) über ein verteiltes Mesh hinweg bekommt einen eigenen Folgebeitrag.

KI in der Governance — entwerfen, nicht entscheiden

KI hat einen ehrlichen Platz in Governance-Workflows: als Entwurfs- und Konsistenz-Assistent, sitzend auf dem Betriebsmodell. Sie hat einen ehrlichen Ausschluss: jeden Entscheidungspfad, der das Artefakt of record produziert.

Entwurfs-Schicht — wo KI hingehört, wenn sie gerechtfertigt ist:

RoPA- und DPIA-Entwurf. Ein LLM schlägt einen Erst-Entwurf-Datensatz aus dem Lineage-Graphen plus dem Katalog plus dem Subscription-Log vor. Der Datensatz durchläuft dann eine Human-in-the-Loop (HITL)-Prüfung und Unterschrift. Die KI hat einen halben Tag gespart; die Verantwortungskette ist unverändert.
Richtlinien-Konsistenzprüfungen. Ein LLM liest den gesamten Richtlinien-Korpus und markiert Widersprüche — ein häufiger Fehlermodus, wenn Governance in Richtung Komplexität driftet. Das LLM behebt sie nicht; es macht sie für das Council sichtbar.
Drift-Erkennung, die Richtlinien-Verletzungen sichtbar macht. Aktive-Metadaten-Alarme, übersetzt in menschenlesbare Governance-Signale — „der Fraud-Fachbereich hat diese Woche dreimal sensitivity=high außerhalb seines erklärten Zwecks gelesen" — speisen die nächste Council-Prüfung.
Natural-Language-Richtlinien-Abfragen. „Unter welchen Bedingungen darf der Fraud-Fachbereich Transaktionsdaten mit Analytics teilen?" aus dem Richtlinien-Korpus beantwortet, in der tatsächlichen Regel begründet, mit Zitat der spezifischen Richtlinie, die anwendbar ist.

Entscheidungs-Schicht — wo KI NICHT hingehört, niemals:

Nicht ein LLM eine Zugriffsanfrage automatisch genehmigen oder ablehnen lassen. Der Audit-Trail überlebt kein LLM in der Schleife, wenn das Artefakt persönliche Verantwortung nach DORA Art. 5 tragen muss.
Nicht ein LLM einen RoPA, eine DPIA oder eine Drittparteien-Risikobewertung unterzeichnen lassen. Diese Artefakte erfordern benannte menschliche Verantwortung nach DSGVO Art. 30 und DORA Art. 28. Ein KI-entworfenes, menschlich signiertes Artefakt ist in Ordnung. Ein KI-signiertes Artefakt ist es nicht.
Nicht Richtlinien-Korpora, RoPAs oder Audit-Logs an Drittanbieter-LLM-APIs senden. Die Governance-Artefakte selbst werden zu sensiblen Daten, die die Auftragsverarbeiter-Grenze verlassen — die Compliance-Oberfläche ist um einen Anbieter gewachsen, ohne dass der CIO es bemerkt. Wenn Entwurfs-KI legitim ist, führen Sie die Inferenz innerhalb der Compliance-Grenze aus.

Jeder DACH-Interessent, mit dem Cordata über KI-in-Governance spricht, stellt diese Fragen innerhalb der ersten fünfzehn Minuten. Das Muster, das Cordata ablehnt, ist „wir haben KI hinzugefügt, weil das jeder tut". Jede Verwendung muss eine spezifische Menschstunde pro Woche reduzieren oder eine spezifische Klasse von Drift reduzieren — messbar. Wenn nicht, gehört sie nicht dazu.

Wenn föderierte Governance die falsche Form ist

Die drei „falscher Shop"-Ausschlüsse aus dem Data-Engineering-Grundpfeiler gelten hier ebenfalls, in ihrer Governance-spezifischen Form — der zugrundeliegende Grund ist in beiden Grundpfeilern derselbe: der Overhead der Föderation lohnt sich erst ab einer bestimmten Skalen- und Komplexitätsschwelle. Kurz:

Ein-Fachbereichs-Häuser — es gibt keine Föderation zu bauen. Ein gut geführtes zentrales Richtlinienset ist die ehrliche Antwort; einer Gruppe, die in einen Slack-Kanal passt, föderiertes-Governance-Vokabular überzustülpen, ist unnötiger Overkill.
Greenfield-Teams unter sechs Engineers — der Overhead eines rotierenden Councils + Policy-as-Code-Autorenschaft + Nachweiserzeugungs-Oberfläche übersteigt die Drift, die ein einzelner gut informierter Lead durch Aufmerksamkeit einfängt.
Regulierte Ausschnitte mit einer kanonischen Antwort (regulatorisches Reporting ist der kanonische Fall) — zentrales Eigentum dieses Ausschnitts ist oft richtig, auch innerhalb eines föderierten Hauses. Dieser Grundpfeiler verbietet Zentralisierung nicht; er verbietet die Zentralisierung von allem.

Ein Governance-Grundpfeiler, der nie „nein" sagt, ist das Compliance-Theater, vor dem er warnt. Dieser hier tut es.

Wie Cordata engagiert

Cordata lehnt es ab, (a) Governance-Strategie-Mandate zu verkaufen, die einen Richtlinien-Ordner ohne einen ausführbaren Durchsetzungspfad produzieren, oder (b) Compliance-Audit-Vorbereitungen, die in Artefakt-Erzeugungs-Theater umschlagen. Ein Richtlinien-Ordner ohne ausführbare Durchsetzung ist der Papierkram, der beim nächsten Audit wieder auftaucht. Audit-Vorbereitungs-Mandate ohne Verhaltensänderung sind derselbe Papierkram mit einem frischen Zeitstempel. Beide Absagen kommen aus Erfahrung.

Was Cordata verkauft: Mandate, die beide Hälften des Governance-Fehlers gleichzeitig schließen.

Die Form ist bewusst eng. Ein zweiwöchiges Discovery: ein Audit der aktuellen Governance-Oberfläche (Richtlinien, RoPAs, Entscheidungsgremien und das tatsächliche Grant-Log in Produktion), strukturierte Interviews mit zwei Fachbereichen und einer zentralen Funktion und eine ehrliche Karte, wo der zentrale Engpass und die Artefakte-Abweichung heute jeweils sitzen.

Von dort aus werden Mandate auf 6-12 Wochen zugeschnitten, nicht offen. Die Lieferergebnisse sind immer beide:

Organisatorisch — eine föderierte Council-Charta mit Rotation und SLAs, Entscheidungsrechte über die Fachbereiche hinweg, eine RACI, die aus Katalog-Eigentümer-Metadaten abgeleitet ist, und ein Richtlinien-Subtraktions-Plan für den aktuellen Korpus.
Technisch — Policy-as-Code am Platz, eine Nachweiserzeugungs-Oberfläche verdrahtet, ein Fachbereich Ende-zu-Ende als Referenzform onboarded.

Handover-first. Jedes Mandat baut Cordatas Ersetzbarkeit in das Lieferergebnis ein. Der Maßstab eines erfolgreichen Mandats ist, ob das Team des Klienten die Governance-Oberfläche sechs Monate später ohne uns erweitern kann.

Wenn Sie ein Governance-Programm in der obigen Form haben zerfallen sehen — oder eines geliefert haben, das den Kontakt mit einem echten Mesh überlebt hat — würde ich wirklich gerne hören, wo die Nähte sichtbar wurden. Die Tür steht offen unter cordata.tech/contact.

Begleiter + Folgebeiträge: Behaviour-first Governance in der Praxis — Artefakte aus Plattform-Ereignissen erzeugen geht die konkrete Maschinerie aus § 5 mit echtem Terraform, SQL und YAML durch (erscheint zusammen mit diesem Grundpfeiler als sein technischer Begleiter); DSGVO Art. 17 über ein Mesh hinweg behandelt die Löschungs-Mechanik, wenn die Daten eines Kunden in acht Konten liegen.