Governance über Sicherheit hinaus: Wissen, Kontext & Ontologie im Lakehouse

Fragt man die meisten Unternehmen, was Data Governance für KI bedeutet, hört man meist eine Antwort zum Thema Sicherheit: abriegeln, Zugriff einschränken, das Audit bestehen. Im Gesundheitswesen ist Sicherheit nicht verhandelbar – aber sie greift zu kurz. Sicherheit sagt Ihnen, wer auf Daten zugreifen darf. Sie sagt nichts darüber aus, was die Daten bedeuten, ob man ihnen vertrauen kann oder ob ein KI-Modell jemals von ihnen lernen sollte.

Unser Data Empowerment Program (DEP) geht von einer anderen Prämisse aus: Governance bedeutet Wissen, Kontext und Ontologie, nicht nur Kontrollen. Artefakte, die die meisten Teams als Compliance-Overhead betrachten – wie Klassifizierungs-Tags, Richtlinien zur De-Identifizierung, Model Cards und Datenverträge –, sind das Rohmaterial für die Datensemantik im Unternehmen.

So gesehen entscheidet man sich nicht zwischen Governance und KI, sondern Governance hilft beim Aufbau von KI. Im KI-Zeitalter müssen neue Governance-Ansätze implementiert werden. Die einzige Frage ist, ob Sie diese Arbeit erst später erledigen, nur um das Audit zu bestehen, oder jetzt, um das Fundament zu legen, auf dem Ihre KI läuft.

Unser Ziel ist es zu zeigen, dass die Sicherheits- und Governance-Arbeit, die Sie bereits leisten, das Fundament ist, auf dem Ihre KI läuft. Wenn Sie die Daten gut genug verwalten, kann KI auf günstigeren Modellen mit mehr Vertrauen laufen.

Governance muss über fünf Säulen hinweg durch eine einzige Brille ganzheitlicher gedacht werden

Beginnen Sie mit der Perspektive, dass jedes Governance-Artefakt zur Semantik beiträgt. Jedes Klassifizierungs-Tag ist ein Konzept. Jede Model Card ist Kontext. Jeder Datenvertrag ist eine gemeinsame Definition. Jede Lineage-Verbindung ist eine Beziehung. So betrachtet ist der Sicherheits-Stack, den Sie bereits nutzen, der erste Entwurf Ihrer Ontologie, und der Katalog ist der Ort, an dem sie lebt.

Governance ist dann nicht mehr nur eine einzelne Sache, sondern wird zu fünf Facetten einer einzigen Disziplin: die Daten selbst und wie sie kontrolliert werden, die darauf aufbauende KI, die Menschen, die sie verstehen müssen, die Produkte, die sie in das Unternehmen tragen, und der gemeinsame Kontext, der alle vier miteinander verbindet. Es ist dieselbe Perspektive, aber an fünf Fronten.

Mit dem DEP stellen wir uns die Semantik anhand von fünf Säulen vor:

• Data Governance — Katalog, Qualität, Kuratierung, Lineage und integrierte Sicherheit & Compliance wie PII-Klassifizierung, Zugriffskontrolle, HIPAA/GDPR und KI-spezifische Datenschutzrisiken.
• Knowledge (AI/ML) Governance — Modelldokumentation, Governance und Standards für verantwortungsvolle KI (Responsible AI) wie Bias & Fairness, Erklärbarkeit, menschliche Aufsicht und Bereitschaft für den EU AI Act.
• Data Literacy — Schulung, Self-Service-Befähigung, Zertifizierung von Anwendern und KPIs wie Einführungsraten, Nutzungsmetriken und Programm-ROI.
• Data Management — Architektur, Data Engineering und Datenproduktverträge sollten Schemavereinbarungen, SLAs & Qualitätsschwellenwerte sowie Pflichten für Ersteller/Nutzer umfassen.
• Ontology — Glossar, Taxonomie, Knowledge Graph – gipfelt in einem semantischen Layer für KI. Dies umfasst den Kontext für LLMs, RAG-Grounding und die Bereitschaft für Chat-Abfragen.

Operationalisierung der Vision durch Agenten

Sobald Ihre Governance-Artefakte als strukturierte, maschinenlesbare Metadaten vorliegen, sind sie nicht mehr nur Dokumentation, sondern werden zu Befehlssätzen für Agenten.

Wenn wir von „Agenten“ sprechen, meinen wir das in zweierlei Hinsicht: „Build-Agenten“, die Datenprodukte zusammenstellen und bereitstellen, und „Analyse-Agenten“, die darauf aufbauend geschäftliche Fragen beantworten; jeder von ihnen ist an ein einzelnes Datenprodukt gebunden.

Beginnen wir mit den Build-Agenten. Build-Agenten automatisieren den Bereitstellungs-Lebenszyklus von Datenprodukten vom Source Mapping über ETL, Tests und De-Identifizierung bis hin zum Produktions-Release. Alles, was sie benötigen, befindet sich in Unity Catalog als verwaltete Metadaten: Source-to-Target-Mappings, Geschäftsdefinitionen, Klassifizierungsstufen, Richtlinien zur De-Identifizierung, Datenverträge und Model Cards. Die Plattform leitet dies aus Tags, Kommentaren, Zertifizierungs-Flags, Lineage und mit dem Glossar verknüpften Begriffen ab. Der Katalog ist nicht nur der Ort, an dem Sie Governance dokumentieren; er ist die Laufzeitumgebung, gegen die die Agenten ausgeführt werden.

Jeder Agent arbeitet in einer Schleife. Er liest Anweisungen aus dem Katalog, führt eine konkrete Aufgabe aus (z. B. das Generieren von Pipeline-Code, das Ausführen einer Test-Suite, das Erstellen de-identifizierter Daten oder das Bereitstellen eines zertifizierten Datensatzes) und schreibt die Belege dann als Testergebnisse, Qualitäts-Scores, Lineage oder Change-Capture-Daten zurück. Dies wiederholt sich.

In der Praxis schalten wir die De-ID- und Test-Agenten zuerst vor. Sie eliminieren die größten Risiken und die aufwendigste manuelle Arbeit im Vorfeld. Dort anzufangen, wo sich die Investition am schnellsten auszahlt, hilft, frühzeitig an Dynamik zu gewinnen. Während wir die Schleife weiter durchlaufen, agiert kein Agent auf Daten, die nicht im Katalog beschrieben sind.

Moderne Kataloge machen diesen Ansatz skalierbar, da sie Spalten- und Tabellenbeschreibungen zur Genehmigung durch einen Data Steward automatisch generieren, sensible Felder automatisch klassifizieren und Lineage auf Spaltenebene erfassen können, ohne dass dies manuell gepflegt werden muss. Die Rolle des Menschen verlagert sich von der Erstellung der Metadaten zu deren Genehmigung – genau die Art von Beurteilungsarbeit, die Menschen tun sollten.

Der Daten- & KI-Build-Lebenszyklus: Nachweis & kontinuierlicher Kontext

Build-Agenten arbeiten innerhalb eines End-to-End-Lebenszyklus, der darauf ausgelegt ist, zwei Assets gleichzeitig freizugeben: das verwaltete Datenprodukt (Mapping, Kuratierung, Pipeline) und den darauf ausgeführten Analyse-Agenten (semantischer Layer, Prompt-Konfigurationen, Evaluierungs-Suites).

Dieser Ansatz markiert einen grundlegenden Wandel von der Pipeline-zentrierten Entwicklung (Daten von Punkt A nach B verschieben) hin zur Kontext-zentrierten Entwicklung (Daten für LLMs verständlich und nutzbar machen). Anstatt nur die Codequalität zu zertifizieren, validieren die Gates in diesem Lebenszyklus Semantik, Kontext und Ownership.

Zwei Kerneigenschaften unterscheiden dieses Framework von einem traditionellen SDLC:

• Es erbringt den Nachweis automatisch: Der Nachweis der Vertrauenswürdigkeit ist ein natürliches Nebenprodukt der Bereitstellung und keine hektische Audit-Vorbereitung im Nachhinein.
• Es verbessert kontinuierlich den Kontext: Das Verhalten in der Produktion speist eine AgentOps-Schleife – und verwandelt fehlgeschlagene Abfragen, Halluzinations-Cluster und negative Nutzerbewertungen in das semantische Backlog des nächsten Sprints.

Menschliche Stewards dienen als Verantwortungsinstanz für beide Eigenschaften: Agenten schlagen vor, Menschen genehmigen. Auch wenn die Verwaltung von fünf Gates über zwei Tracks hinweg wie die Schaffung langwieriger Engpässe aussehen mag, können die meisten Gates in wenigen Stunden freigegeben werden. Genehmigungen erfolgen direkt in den Standard-Entwicklertools. Automatisierte Test-Suites hängen Datenqualitätsergebnisse, Evaluierungs-Scores und Lineage an, bevor ein Ticket geöffnet wird. Ein formales Gate-Meeting ist eine Ausnahme zur Untersuchung, nicht der Standardablauf.

Die KI-Zertifizierung ist der Motor hinter den Gates

Der Mechanismen, der diese Gates objektiv statt willkürlich macht, ist die KI-Zertifizierung. Diese direkt in Unity Catalog erfasste Zertifizierung fungiert als automatisierte, abfragbare Scorecard und nicht als manuelle rechtliche Bescheinigung. Sie regelt die Freigabeberechtigung über vier Kerndimensionen hinweg:

• Automatische vs. menschliche Bewertung: Governance-, Qualitäts- und Semantik-Scores werden automatisch aus abfragbaren Systemtabellen, Pipeline-Ergebnissen und Evaluierungsläufen berechnet. Der Ownership-Score und der endgültige Bereitstellungsstempel erfordern eine ausdrückliche Unterschrift des Stewards.
• Kontinuierlicher Ablauf: Die Zertifizierung ist dynamisch. Eine Schemaänderung, ein Vertrags-Update oder eine fehlgeschlagene Evaluierungs-Suite entzieht sofort die Zertifizierung, bis die Prüfungen erneut durchgeführt werden und erfolgreich sind.
• Durchsetzung auf Datenebene: Zugriffskontrollen erfolgen über attributbasierte Zugriffskontrolle (ABAC) auf der Datenebene, nicht auf der Anwendungsebene. Wenn ein Benutzer eine Zeile in SQL nicht abfragen kann, kann kein Agent sie über Vektorsuche oder Embeddings abrufen.
• Strikte Grenzisolation: Nicht-Produktionsumgebungen (SIT, Regression, Modelltests) nutzen ausschließlich synthetische oder de-identifizierte Daten. Dies stellt sicher, dass produktive PHI niemals die verwaltete Grenze verlässt.

Wenn der Agent falsch liegt, wer korrigiert ihn?

Zertifizierungen und Gates beweisen, dass ein Agent bei der Veröffentlichung vertrauenswürdig war. Doch die Frage, die sich Governance-Verantwortliche stellen, lautet nicht „Wie funktioniert es?“, sondern „Wer ist verantwortlich, wenn es eine falsche Antwort liefert?“ Die Antwort muss ein konkreter Name sein, kein Lenkungsausschuss.

Um dies zu lösen, wird jeder Analyse-Agent (z. B. ein Databricks Genie Agent) an ein einzelnes, kontrolliertes Datenprodukt mit einem festen Owner gebunden. Wenn ein Agent ein falsches Ergebnis liefert, weil eine zugrunde liegende Metrik falsch definiert war, liegt das Problem nicht beim AI-Engineering-Team. Stattdessen geht es direkt an den Data Product Owner, der die Definition im Katalog korrigiert. Die Bindung eines Agenten an ein domänenspezifisches, zertifiziertes Datenprodukt ist zudem der größte Hebel für Genauigkeit: Ein fokussierter Agent, der zertifizierte Metadaten abfragt, übertrifft konsistent ein globales Modell, das über den gesamten Datenbestand des Unternehmens hinweg rät.

Entscheidend ist, dass diese gemeinsame Metrikdefinition erzwungen und nicht nur dokumentiert wird. Sobald eine zertifizierte Metrik im Katalog definiert ist, muss der antwortende Agent direkt auf dieser Basis rechnen. Dies macht aus statischer Dokumentation aktive Laufzeitlogik.

Die Verantwortlichkeit bleibt bestehen, da es eine strikte Grenze dafür gibt, was die AI unbeaufsichtigt tun darf: Kein Agent bringt Code in die Produktion, ändert Richtlinien oder arbeitet ohne menschliches Eingreifen mit nicht klassifizierten Daten. Während Zertifizierungswerte automatisch berechnet werden, erfordert das finale Release-Gate immer eine menschliche Freigabe. Wenn der Katalog ein Daten-Asset nicht explizit beschreibt, reagiert das System standardmäßig mit Unterdrückung, anstatt zu raten. Zur Laufzeit erzwingt diese Fail-Closed-Richtlinie klare Grenzen:

• Für Analyse-Agenten: Anstatt zu spekulieren oder den Kontext aus Rohdaten abzuleiten, lehnt der Agent die Antwort explizit ab und gibt eine transparente Meldung aus (z. B. „Diesem Datensatz fehlt die aktive Zertifizierung oder das semantische Mapping, das zur Verarbeitung Ihrer Anfrage erforderlich ist.“)
• Für Build-Agenten: Wenn während des Pipeline-Aufbaus ein nicht klassifiziertes Schema oder ein fehlender Datenvertrag erkannt wird, stoppt die Ausführung automatisch vor dem Erreichen von Staging-Umgebungen und protokolliert ein Flag für nicht zugeordnete Assets zur Überprüfung durch den Steward.

Diese Leitplanken auf dem Papier zu definieren ist einfach, aber sie in der Praxis umzusetzen erfordert es, vage Governance-Ausschüsse durch vier klare, verantwortliche Rollen zu ersetzen:

• Data Product Owner: Verantwortlich für die Definitionen und die Qualität eines kontrollierten Produkts. Sie sind der zentrale Ansprechpartner, wenn eine Antwort falsch ist.
• Data & AI Governance Engineer: Übersetzt Richtlinien in ausführbare Katalog-Metadaten (Klassifizierungen, Verträge, Lineage), sodass Regeln zur Laufzeit ausgeführt werden, anstatt in einem PDF zu verstauben.
• Steward: Überprüft automatisierte Ergebnisse und gibt Release-Gates frei. Die Automatisierung schlägt vor, der Steward entscheidet.
• Security / IAM: Ist Inhaber der Klassifizierungsstufen und Zugriffsattribute, die automatisch die De-Identifizierung und Berechtigungen auf Zeilenebene steuern.

Sorgfältig testen, ohne die Sicherheit zu gefährden

Der von uns beschriebene Lebenszyklus birgt eine strikte Voraussetzung: Jede dieser Test- und Evaluierungsphasen benötigt realistische Daten – und im Gesundheitswesen können Sie nicht mit echten PHI testen. Die Herausforderung besteht also darin, überall realistische Testdaten zu benötigen, ohne die Sicherheit zu gefährden.

De-Identifizierung ist der Weg, wie wir Daten für Analysen nutzbar und gleichzeitig sicher halten. Woher bezieht der De-Identifizierungs-Agent sein Wissen? Nicht aus einer manuell gepflegten Tabelle. Er arbeitet auf Basis von Sicherheitsrichtlinien, die die Unternehmenstools bereits bereitstellen. Der Ablauf umfasst drei Schritte:

• Discover – Automatische Discovery-Scanner und InfoSec-Richtlinien-Engines klassifizieren sensible Spalten und Dateien.
• Curate – Klassifizierungen landen im Katalog als kuratierte Richtlinien-Metadaten; der Agent liest diese Kuratierung und führt sie aus.
• Execute – Metadaten aufnehmen und synthetische Daten oder de-identifizierte Quelldateien erstellen. HIPAA-Safe-Harbor-konform, referenziell integer, analytisch nutzbar.

Für das Security- und IAM-Team ist dies keine Einbahnstraße. InfoSec-Richtlinien sind keine PDFs mehr, sondern werden ausführbar: Klassifizierungsstufen und Aufbewahrungsregeln steuern die De-Identifizierung automatisch. Im Gegenzug erhält die Security eine kontinuierlich aktualisierte Sicht auf sensible Daten, einen Fail-Closed-Schutz für neu entdeckte Daten und Restrisiko-Scans, die bei jedem Durchlauf Audit-Belege generieren. Das Zugriffsmodell bleibt durchgängig dasselbe. Da jeder Datenabruf durch einen Agenten die Katalogberechtigungen des abfragenden Benutzers erbt, können RAG-Ansätze kein Embedding einer Zeile anzeigen, die der Benutzer nicht sehen darf. Dieselben ABAC-Regeln gelten sowohl für SQL als auch für die Vektorsuche, und Agenten agieren mit den Berechtigungen des abfragenden Benutzers, nicht mit einem privilegierten Dienstkonto. Jeder Agenten-Prompt wird zusammen mit der für die Antwort verwendeten Lineage protokolliert – unter derselben Governance wie die Daten selbst.

Das ist der eigentliche Durchbruch: ein einziges Berechtigungsmodell für die Daten, die Modelle, die Embeddings und den Audit-Trail – statt eines Datenkatalogs, der mit einer separaten Modellregistrierung und einem separaten Vektorspeicher zusammengestückelt ist. Governance-Arbeit wird so zum AI-Fundament statt zu einem Parallelprojekt.

Metriken erfassen, Ergebnisse belegen, Vertrauen gewinnen

Beachten Sie, was der Lebenszyklus die ganze Zeit über getan hat: Jede Phase, jedes Gate, jede Zertifizierung hat Metriken generiert. Fassen Sie die vier Zertifizierungsdimensionen in einem einzigen AI-Readiness-Score pro Datensatz zusammen und machen Sie diesen operativ nutzbar, statt nur anzustreben. Die Semantik erreicht 100 % erst, wenn jede Spalte eine mit dem Glossar verknüpfte Definition enthält und die Tabelle einen unterzeichneten Datenvertrag hat; Ownership erreicht 100 % erst, wenn ein namentlich genannter Owner auf Probleme reagiert.

Das Ergebnis, das auf diese Bewertung folgt, ist der Business Case für das gesamte DEP-Programm: Metriken belegen die Ergebnisse der AI, Belege schaffen Vertrauen, und Vertrauen macht aus einem Pilotprojekt die tägliche Nutzung. Kein geschäftlicher Anwender nutzt einen Agenten, nur weil das Architekturdiagramm elegant ist. Sie nutzen ihn, weil die Zahlen letzte Woche stimmten und jemand Verantwortliches sie korrigiert hat, als sie nicht stimmten. Der Score erklärt, warum die Zahlen überhaupt stimmen: Je höher der Score, desto weniger muss das Modell raten. Es muss nicht ableiten, was eine Spalte bedeutet, Duplikate ausgleichen oder Joins halluzinieren – weil der Katalog es ihm bereits gesagt hat.

Jagen Sie nicht den neuesten Modell-Schlagzeilen hinterher. Konzentrieren Sie sich auf die Wirtschaftlichkeit der Modelle.

Jede Woche bringt ein größeres, teureres Modell. Was der Hype-Zyklus übersieht: Wenn der Katalog bereits Bedeutung, Qualität und Kontext liefert, muss das Modell dies nicht mehr tun. Kleinere oder Open-Weights-Modelle erfüllen die meisten Anforderungen für Reporting und Analysen auf kontrollierten Daten.

Frontier-Modelle werden oft verwendet, um zugrunde liegende Metadatenlücken zu kaschieren. Wenn Schemata und Geschäftsregeln explizit katalogisiert sind, kleinere, domänenspezifische Modelle die gleiche Genauigkeit zu einem Bruchteil der Token-Kosten liefern.

Dies ist eine Entscheidung zwischen Kosten und Qualität, keine Qualitätsgrenze. Passen Sie die alltägliche Arbeit an (Right-Sizing) und heben Sie sich die Ausgaben für Frontier-Modelle für die Probleme auf, die sie wirklich benötigen – so zwingen Kosten Ihre AI nie zur Pause. Bereinigen Sie die Daten. Passen Sie die Modellgröße an. Behalten Sie die Genauigkeit bei. Das ist es, was eine starke Governance-Basis für eine AI-Strategie bringt: nicht nur günstigere AI, sondern unaufhaltsame AI.

Werden Sie aktiv: Starten Sie mit einem einzigen Datenprodukt

Versuchen Sie nicht, sofort das gesamte Unternehmen umzukrempeln. Beweisen Sie das Modell, indem Sie ein einzelnes Datenprodukt durch den gesamten Lebenszyklus führen:

1. Scan: Aktivieren Sie das automatische Discovery-Scanning für ein einzelnes Zielschema.
2. Define: Legen Sie in Unity Catalog explizite Zertifizierungsschwellenwerte für Vollständigkeit, Semantik und Qualität fest.
3. Bind: Verknüpfen Sie einen Analyse-Agenten mit dem Datensatz, zusammen mit einer dedizierten Evaluierungs-Suite und einem de-identifizierten Testpfad.
4. Assign: Bestimmen Sie einen namentlich genannten Data Product Owner, der für Definitionen und die Behebung von Problemen verantwortlich ist.

Sobald die Schleife läuft, wiederholen Sie den Prozess für ein zertifiziertes Datenprodukt nach dem anderen. Sicherheit sagt Ihnen, wer auf Ihre Daten zugreifen kann, aber Governance sagt Ihnen, was sie bedeuten und ob eine KI ihnen vertrauen kann.

Governance ist nicht das Tor vor einer datengetriebenen Organisation. Richtig gemacht ist sie der Boden unter ihr.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag