AI-Governance auf Databricks: EU AI Act und DSGVO technisch umsetzen
Die Kernaussagen auf einen Blick.
- AI-Governance auf Databricks entsteht aus dem Zusammenspiel mehrerer Plattformkomponenten und nicht durch den Kauf eines einzelnen Werkzeugs.
- Je nach Anwendungsfall können EU AI Act und DSGVO Nachweise zu Risikoklassifizierung, Datenherkunft, Modellversionen und protokollierter Nutzung erfordern.
- Eine externe Governance-Plattform ist vor allem dann sinnvoll, wenn relevante KI-Workloads auf mehreren Plattformen betrieben werden.
- AI-Governance sollte über verbindliche Tags, Owner und Lineage in Unity Catalog verankert werden.
- Für produktive LLM-Zugriffe sollte ein zentraler Gateway-Ansatz als bevorzugter Zugang geprüft werden.
Inhaltsverzeichnis
Warum ein Extra-Tool die Plattformbasis nicht ersetzt
Mit näher rückenden regulatorischen Fristen steigt der Druck, KI-Systeme nachvollziehbar zu dokumentieren. Gleichzeitig laufen erste GenAI-Anwendungen bereits produktiv. Das zentrale KI-Inventar besteht jedoch häufig nur aus einer manuell gepflegten Tabelle. Fragt Datenschutz oder Revision nach der Herkunft einer Modellantwort, führt die Suche möglicherweise zu einem alten Notebook oder einer nicht mehr gepflegten Projektdokumentation. Dieses Muster tritt häufig auf, wenn Governance erst kurz vor einer Prüfung als separates Dokumentationsprojekt verstanden wird.
Der Wunsch nach einer zentralen Governance-Oberfläche ist nachvollziehbar. Externe Governance-Plattformen wie Credo AI oder Holistic AI bieten zentrale Inventare, Risikobewertungen und Berichtsoberflächen. In einer Produktdemo wirkt dieser Ansatz zunächst überzeugend. Ohne technische Integration kann im Betrieb jedoch zusätzliche Doppelarbeit entstehen. Ein externes Tool kennt Datenquellen, Modellpipelines und Endpoints nicht automatisch. Fehlende Integrationen müssen durch manuelle Pflege oder zusätzliche Schnittstellen ausgeglichen werden.
Dadurch entstehen zwei parallel gepflegte Informationsstände. Der technische Ist-Zustand liegt in Databricks. Die regulatorische Dokumentation wird separat in einem weiteren System geführt. Ohne automatisierte Synchronisation können beide Stände schnell voneinander abweichen. Im ungünstigsten Fall enthält das zusätzliche Tool lediglich manuell übertragene Informationen aus bestehenden Dokumentationen. Die technische Nachvollziehbarkeit muss aus den produktiven Systemen selbst entstehen. Ein Governance-Werkzeug kann diese Informationen nur sinnvoll zusammenführen, wenn die Plattform sie verlässlich bereitstellt. Je nach Plattformumfang kann ein Teil der Governance-Auswertung bereits direkt in Databricks erfolgen.
Was ist AI-Governance auf Databricks?
AI-Governance auf Databricks verbindet Datenverwaltung, Modellbetrieb, Protokollierung und Verantwortlichkeiten. Mehrere technische Komponenten müssen dafür konsistent zusammenspielen. Es gibt dafür nicht das eine Produkt, das alle Governance-Aufgaben allein übernimmt. In der Praxis bedeutet das: Daten, Modelle und Endpoints erhalten definierte Zugriffsrechte, Tags und verantwortliche Owner. Soweit technisch unterstützt, werden Datenflüsse und Abhängigkeiten in der Lineage erfasst. Produktive Modellzugriffe sollten über einen zentral verwalteten und protokollierten Zugang erfolgen. Produktive Modelle sollten versioniert und mit Metadaten in Unity Catalog verwaltet werden. Relevante Modellaufrufe und Berechtigungsänderungen sollten in auswertbaren Protokollen erfasst werden.
Ein praktisches Qualitätsmerkmal ist die Zeit, die für eine belastbare Auditantwort benötigt wird. Sind Metadaten, Lineage und Logs strukturiert verfügbar, lassen sich viele Prüfungsfragen mit SQL deutlich schneller beantworten:
- Welche Modelle und Datenprodukte hängen von einer bestimmten personenbezogenen Spalte ab?
- Welche Anwendungsfälle wurden nach dem internen und rechtlich geprüften Risikomodell als hochriskant eingestuft?
- Welche protokollierten Anfragen wurden in einem definierten Zeitraum an einen bestimmten Endpoint gesendet?
Die technische Abdeckung hat jedoch klare Grenzen. Workloads außerhalb von Databricks werden nur erfasst, wenn sie über definierte Schnittstellen und Loggingprozesse angebunden sind. Direkte Modellaufrufe aus externen Anwendungen können außerhalb des zentralen Inventars liegen. Lokale Skripte und nicht verwaltete Experimente bleiben ohne zusätzliche Kontrollen unsichtbar. Dasselbe gilt für eigene APIs, die zentrale Gateway- und Loggingprozesse umgehen. Solche Zugriffswege müssen organisatorisch und technisch gesondert kontrolliert werden.
Wie die zugrundeliegende Datenschicht aussieht, klären wir im Überblick zu Unity Catalog Access Control. Berechtigungen sind die Voraussetzung für jede Governance-Aussage.
Sieben Plattform-Schichten tragen gemeinsam die AI-Governance auf Databricks: die Datenschicht (Unity Catalog mit Berechtigungen, Owner und Tags; Unity Catalog Lineage), die Modellschicht (Unity AI Gateway, Managed MLflow, Mosaic AI Model Registry) und die Betriebs- und Auditschicht (Lakehouse Monitoring, System Tables).
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Was EU AI Act und DSGVO verlangen
Die Verordnung (EU) 2024/1689, kurz EU AI Act, ist in Kraft, ihre Pflichten werden jedoch gestaffelt wirksam. Einzelne Verbote und Pflichten gelten bereits, weitere Anforderungen folgen zu späteren Zeitpunkten. Welche Fristen für einen konkreten Anwendungsfall gelten, sollte vor jeder Compliance-Entscheidung anhand aktueller Rechtsquellen geprüft werden. Regulatorische Termine und Übergangsregeln sollten nicht aus statischen Architekturunterlagen übernommen, sondern aktuell rechtlich verifiziert werden.
Der EU AI Act unterscheidet verschiedene Risikokategorien mit unterschiedlichen Pflichten. Dazu gehören unter anderem verbotene Anwendungen, Hochrisikosysteme und Anwendungen mit besonderen Transparenzpflichten. Die konkrete Einordnung hängt vom Einsatzgebiet, der Rolle des Unternehmens und der Funktion des Systems ab.
Für die technische Architektur lassen sich drei zentrale Anforderungsbereiche ableiten.
Inventar & Risikoeinstufung
Ein nachvollziehbares Inventar mit dokumentierter Risikoeinstufung pro KI-System.
Datenquellen & Bias-Prüfung
Dokumentierte Datenquellen, Qualitätsprüfungen und, wo einschlägig, Bias-Analysen.
Logs & Aufsicht
Geeignete Logs, menschliche Aufsicht und nachvollziehbare Entscheidungsprozesse.
Für Anbieter und Betreiber von General-Purpose-AI-Modellen gelten teilweise zusätzliche Transparenz- und Dokumentationspflichten.
Die DSGVO stellt zusätzlich Anforderungen an Rechtmäßigkeit, Transparenz, Betroffenenrechte und Löschprozesse. Werden personenbezogene Daten für Training oder Inferenz verarbeitet, müssen Datenquellen, Zwecke, Empfänger und Verarbeitungsvorgänge nachvollziehbar dokumentiert sein. Eine möglichst vollständige Verbindung zwischen Quelldaten, Verarbeitung, Modellversion und produktiver Nutzung erleichtert diese Nachweise. Beide Regelwerke erhöhen den Bedarf an strukturierter Datenherkunft, Zuständigkeit und Protokollierung. Die benötigten Nachweise sollten möglichst aus technischen Metadaten und nicht ausschließlich aus manuell gepflegten Dokumenten entstehen.
Welche Databricks-Komponente welche Anforderung trägt, lässt sich als Mapping-Matrix zusammenfassen: A Risiko-Klassifizierung pro Use Case · B KI-Inventar mit Owner und Versionen · C Datenherkunft & Trainingsdaten-Nachweis · D Inferenz-Protokollierung · E Drift-, Qualitäts- und Bias-Monitoring · F Audit-Trail über Zugriffe und Berechtigungen · G Betroffenenrechte / Löschnachweis.
| Komponente | A | B | C | D | E | F | G |
|---|---|---|---|---|---|---|---|
| Unity Catalog | ✓ | ✓ | ✓ | ✓ | |||
| Unity Catalog Lineage | ✓ | ✓ | |||||
| Unity AI Gateway | ✓ | ✓ | ✓ | ||||
| Managed MLflow + Mosaic AI Model Registry | ✓ | ✓ | |||||
| Lakehouse Monitoring | ✓ | ||||||
| System Tables | ✓ | ✓ | ✓ |
Wie steuert Unity Catalog Berechtigungen?
Unity Catalog bildet die zentrale Grundlage für Zugriffssteuerung, Ownership und Metadaten von Daten- und Modellobjekten. Drei Funktionen sind dafür besonders relevant. Der dreistufige Namespace aus Catalog, Schema und Objekt strukturiert Daten- und Modellassets. Er bündelt Tabellen, Views, Volumes und seit der Aufnahme von Models in Unity Catalog auch Modelle. Zugriffsrechte lassen sich über gemeinsame Hierarchien und Grants verwalten. Tags können zusätzliche Klassifizierungs- und Governanceinformationen speichern, etwa pii=true, sensitivity=restricted oder eu_ai_act_risk=high. Für jedes relevante Asset sollte ein verantwortlicher Owner festgelegt werden.
Daraus ergibt sich eine wichtige organisatorische Vorgabe. Assets außerhalb von Unity Catalog können nicht mit denselben nativen Tags, Berechtigungen und Lineagefunktionen verwaltet werden. Legacy-Registries, lokale Artefakte und nicht registrierte Modelle erschweren eine einheitliche Governance. Es sollte festgelegt werden, welche produktiven KI-Assets verpflichtend in Unity Catalog verwaltet werden. Für verbleibende externe Assets braucht es einen gesonderten Inventar- und Kontrollprozess. Nicht mehr benötigte oder nicht konforme Zugriffswege sollten kontrolliert zurückgebaut werden.
Ein praktikables Taggingmodell kann drei Bereiche abdecken.
Risiko & Regulatorik
Risikoeinstufung und regulatorische Relevanz, etwa eu_ai_act_risk und dsgvo_relevant.
Sensitivität & Personenbezug
Sensitivität, Personenbezug und Datenkategorie, etwa sensitivity, pii und data_category.
Use Case & Owner
Anwendungsfall, Business Owner und technische Verantwortung, etwa use_case_id und business_owner.
Ob und wie Tags automatisch an nachgelagerte Assets übertragen werden, hängt von den verfügbaren Funktionen und eigenen Automatisierungen ab. Personenbezug sollte in nachgelagerten Datenprodukten und Modellen nachvollziehbar bleiben, darf aber nicht ohne technische Prüfung als automatische Vererbung vorausgesetzt werden. Ziel ist eine Klassifizierung, die technische Abhängigkeiten berücksichtigt und nicht nur manuell pro Asset gepflegt wird.
Wie zeigt Lineage Abhängigkeiten?
Unity Catalog kann viele Datenflüsse und Abhängigkeiten automatisch erfassen. Dazu gehören Beziehungen zwischen Quell- und Zieltabelle. Je nach Verarbeitung kann auch eine Spalten-Lineage verfügbar sein. Zusätzlich können beteiligte Jobs und Notebooks sichtbar werden. Die Lineage-Sicht ist sowohl in der UI verfügbar als auch über die System Tables abfragbar.
Diese Informationen helfen bei zwei typischen Prüfungsfragen. Erstens: Welche Tabellen, Views, Modelle und Endpoints könnten von einer Änderung oder Löschung einer sensiblen Spalte betroffen sein? Die Antwort lässt sich über Lineage- und Metadatentabellen ermitteln, sofern die relevanten Verarbeitungsschritte erfasst wurden. Zweitens: Welche Trainingsdaten und Verarbeitungsschritte gehören zu einer bestimmten Modellversion?
Dafür müssen Unity-Catalog-Lineage und MLflow-Metadaten miteinander verbunden werden. Abhängig von Framework, Zugriffsmethode und Instrumentierung können verwendete Tabellen automatisch oder explizit im Run dokumentiert werden. Bei sauberer Integration lässt sich eine zusammenhängende Kette von Quelltabellen über Features und Trainingslauf bis zur Modellversion aufbauen. Eine kombinierte Abfrage kann die Modelle identifizieren, die direkt oder indirekt von einer bestimmten Tabelle abhängen. In der Praxis können dafür mehrere System- und Metadatentabellen sowie ergänzende Run-Informationen notwendig sein. Der manuelle Abstimmungsaufwand lässt sich dadurch deutlich reduzieren.
Wie sich diese Lineage in Modell- und Pipeline-Architekturen einbinden lässt, klären wir im Überblick zu Unity Catalog Lineage.
Wie steuert das Unity AI Gateway Modellzugriffe?
Das Unity AI Gateway kann als zentraler Zugang zwischen Anwendungen und Modellendpoints eingesetzt werden. Dies gilt sowohl für Databricks-gehostete als auch für angebundene externe Modelle. Ohne gemeinsamen Zugang verwenden Anwendungen häufig eigene Anbieterendpoints und Zugangsdaten. Solche Aufrufe sind in Databricks nur sichtbar, wenn sie zusätzlich protokolliert oder über eine zentrale Schnittstelle geführt werden. Über ein Gateway können Modellaufrufe zentral authentifiziert, begrenzt und protokolliert werden.
Vier Funktionen sind besonders relevant.
Audit-Logging
Anfragen und Antworten werden für Audit, Evaluation und Fehleranalyse protokolliert.
Nutzungslimits
Limits lassen sich je Endpoint, Anwendung oder Identität festlegen.
Datenschutz- & Sicherheitsprüfungen
Prüfungen laufen vor oder nach einem Modellaufruf.
Kosten-Transparenz
Nutzung und Kosten werden über gemeinsame Metadaten ausgewertet.
Nicht verwaltete Modellzugriffe lassen sich nur reduzieren, wenn Netzwerk-, Beschaffungs- und Entwicklungsrichtlinien den zentralen Zugang tatsächlich durchsetzen. Ein Netzwerkblock kann direkte Anbieterzugriffe einschränken, benötigt aber ein sorgfältig geplantes Ausnahme- und Betriebsmodell. Sind Gateway- und Inferenzlogs vollständig vorhanden, können viele Nutzungsfragen mit SQL ausgewertet werden.
MLflow und Model Registry als Modellinventar
Managed MLflow dokumentiert Experimente, Trainingsläufe, Parameter, Metriken und Artefakte. Die Model Registry verwaltet Modellversionen, Aliases, Metadaten und Freigaben. Zusammen bilden sie Entstehung und Lebenszyklus eines Modells ab. MLflow zeigt, wie eine Modellversion erstellt und bewertet wurde. Die Registry zeigt, welche Versionen existieren und welche davon produktiv genutzt werden.
Für Governance sind drei Punkte besonders wichtig.
Eindeutige Identifikation
Jede produktive Modellversion sollte eindeutig identifizierbar sein.
Alias-Steuerung
Aliases unterstützen kontrollierte Tests, Rollouts und Rollbacks.
Verknüpftes Monitoring
Bereitstellung und Monitoring sind mit der registrierten Modellversion verknüpft.
Nicht registrierte Modelle sollten über Plattformrichtlinien und Deploymentprozesse von der produktiven Bereitstellung ausgeschlossen werden.
Ein Modellinventar kann aus Unity-Catalog- und MLflow-Metadaten aufgebaut werden. Welche Angaben direkt verfügbar sind, hängt von Metadatenpflege, Alias-Konzept und Tabellenzugang ab. Wie der Modell-Lifecycle konkret aussieht, klären wir im Überblick zu Managed MLflow auf Databricks und zum Mosaic AI Model Registry.
Lakehouse Monitoring für Daten- und Modell-Drift
Lakehouse Monitoring kann statistische Kennzahlen und Driftvergleiche auf Inferenzdaten berechnen. Drei Analysen sind dabei besonders relevant.
Daten-Drift
Veränderungen in der Verteilung von Eingabedaten.
Qualitäts-Drift
Veränderungen in fachlichen Qualitätsmetriken, sofern Referenzwerte oder Labels verfügbar sind.
Segment- & Fairness-Vergleich
Vergleiche zwischen fachlich oder regulatorisch relevanten Gruppen und Segmenten.
Für hochriskante Anwendungen können solche Monitoringdaten einen wichtigen technischen Beitrag zur laufenden Überwachung leisten. Die Ergebnisse können in Qualitätsberichte und regulatorische Dokumentationen einfließen.
Die Aussagekraft hängt vollständig von der protokollierten Datenbasis ab. Ohne ausreichend detaillierte Inferenzdaten lassen sich Drift, Fairness und Performance nur eingeschränkt bewerten. Für produktive Modelle sollte festgelegt werden, welche Eingaben, Ausgaben, Modellversionen und Referenzwerte protokolliert werden. Dabei müssen Auditbedarf, Datenschutz, Aufbewahrung und Speicherkosten gegeneinander abgewogen werden.
Was liefern System Tables fürs Audit?
System Tables stellen operative Metadaten und Nutzungsinformationen als abfragbare Tabellen bereit. Für Governance und Audit sind insbesondere mehrere Metadatenbereiche relevant.
Audit-Tabellen
Protokollierte Aktionen, Identitäten und Zeitpunkte im Rahmen der verfügbaren Ereignisse und Aufbewahrungsfristen.
Lineage-Tabellen
Erfasste Abhängigkeiten zwischen Datenobjekten.
Serving- & Nutzungsdaten
Auswertung nach Endpoint, Zeitraum und Verbrauch, je nach verfügbarem Schema.
Information-Schema
Informationen zu vorhandenen Objekten, Ownern und Strukturen.
Viele technische Auditfragen lassen sich damit in wiederverwendbare SQL-Abfragen und Berichte überführen. Welche Modell- und Datenobjekte hängen beispielsweise von einer sensiblen Kundentabelle ab? Dafür kann eine Kombination aus Lineage, Modellmetadaten und MLflow-Run-Informationen erforderlich sein. Wie die System Tables im Detail strukturiert sind und welche Aufbewahrungs-Regeln gelten, klären wir im Überblick zu Unity Catalog System Tables.
System Tables dokumentieren in erster Linie vergangene Ereignisse. Präventive Kontrollen müssen weiterhin über Berechtigungen, Policies, Gatewayregeln und Deploymentprozesse erfolgen. System Tables liefern den Nachweis, ersetzen aber keine aktive Zugriffskontrolle.
Die regulatorische Einordnung hängt in erster Linie vom konkreten Einsatzgebiet und der Rolle des Systems ab. Dasselbe Modell kann je nach Anwendung unterschiedlichen regulatorischen Anforderungen unterliegen. Ein Einsatz in einem gesetzlich definierten Hochrisikobereich kann zusätzliche Pflichten auslösen. Die Risikoeinstufung sollte mit dem Anwendungsfall und den eingesetzten Modellversionen verknüpft sein.
Jeder produktive Anwendungsfall sollte eine eindeutige Kennung erhalten. Diese Kennung kann über Tags oder Metadaten mit Tabellen, Modellen und Endpoints verbunden werden. Ein einfaches, verbindliches Metadatenschema ist meist wirkungsvoller als ein umfangreiches, aber uneinheitlich gepflegtes Modell. Typische Felder sind Anwendungsfall-ID, Risikokategorie, Business Owner und regulatorische Relevanz.
Fehlende Pflichtmetadaten sollten über Deploymentkontrollen, Policies oder automatisierte Prüfungen verhindert werden. Produktive Freigaben sollten nur erfolgen, wenn die erforderlichen Metadaten vollständig sind. Vor einer produktiven Bereitstellung sollte die Risikoeinstufung des Anwendungsfalls dokumentiert und freigegeben sein.
Mit konsistenten Tags kann ein Großteil des Inventars automatisiert aus Plattformmetadaten erzeugt werden. Manuelle Dokumentation bleibt für rechtliche und fachliche Bewertungen notwendig, muss aber nicht alle technischen Fakten doppelt pflegen.
Wann braucht es eine externe Governance-Plattform?
Externe Governance-Plattformen sind vor allem für heterogene Technologielandschaften interessant.
Native Databricks-Governance ausreichend, wenn
- Der Großteil der KI-Landschaft bereits in Databricks liegt
- Nur ein geringer Teil der KI-Workloads außerhalb der Plattform betrieben wird
- Sich für jedes Metadatenfeld eindeutig festlegen lässt, welches System führend ist
Externe Governance-Plattform sinnvoll, wenn
- Modelle und KI-Anwendungen auf mehreren Clouds, SaaS-Diensten und eigenen Plattformen betrieben werden
- Ein gemeinsames Inventar und einheitliche Bewertungsprozesse über heterogene Technologielandschaften hinweg gebraucht werden
- Der Zusatznutzen den Lizenz-, Integrations- und Pflegeaufwand einer zweiten Datenbasis nachweislich übersteigt
Die relevante Frage lautet weniger Produkt A gegen Produkt B, sondern wie viel der relevanten KI-Landschaft außerhalb von Databricks betrieben wird.
In welcher Reihenfolge Governance aufbauen?
Eine klare Reihenfolge verhindert, dass Dokumentation vor der technischen Grundlage entsteht. Ohne Priorisierung entstehen leicht parallele Prozesse und unklare Zuständigkeiten. Die Einführung kann in mehrere klar abgegrenzte Phasen aufgeteilt werden; Dauer und Umfang hängen vom Ausgangszustand ab.
Fundament: Unity Catalog & Ownership
Unity Catalog, Gruppen, Owner und produktive Asset-Struktur etablieren. Ohne verlässliches Inventar und Berechtigungsmodell fehlt die Grundlage für weitere Governance-Schritte.
Tagging & Lineage
Taggingmodell, bestehende Assets und Lineageabdeckung aufbauen. Für kritische KI-Pipelines sollte eine möglichst vollständige Lineage angestrebt und regelmäßig geprüft werden. Erste technische Auditfragen werden reproduzierbar beantwortbar.
Zentraler Modellzugriff & Registry
Zentrale Modellzugriffe, Registry-Prozesse und Freigaben etablieren. Für relevante LLM-Anwendungen sollte ein zentraler Gatewayzugang verbindlich gemacht werden. Direkte Anbieterzugriffe können technisch eingeschränkt werden, benötigen aber geregelte Ausnahmen und Betriebsprozesse.
Monitoring & Audit-Reports
Inferenzlogging, Monitoring, Evaluation und regelmäßige Auditberichte einführen. Für regulatorisch relevante Anwendungen sollten geeignete Segment- und Fairnessanalysen fachlich definiert werden. Wiederverwendbare SQL-Berichte können regelmäßige interne Kontrollen unterstützen.
Wer mit Berichten und Modellkarten beginnt, bevor technische Metadaten und Verantwortlichkeiten verlässlich sind, erzeugt zusätzlichen manuellen Pflegeaufwand.
Wie AI-Governance in die größere KI-Architektur einbettet und welche weiteren Bausteine relevant sind, zeigen wir im Überblick zu Artificial Intelligence auf Databricks.
Grenzen
Plattformbasierte Governance ist nur so vollständig wie die technisch erfassten Workloads und Datenflüsse. Vier Einschränkungen sollten dauerhaft berücksichtigt werden.
Nicht verwaltete Modellzugriffe
Zugriffe außerhalb der Plattform werden nicht automatisch erfasst. Dafür sind Netzwerkregeln, Beschaffungsvorgaben, Schulungen und klare Entwicklungsrichtlinien notwendig.
Keine vollständige regulatorische Bewertung
Die Plattform liefert technische Fakten, aber keine vollständige regulatorische oder fachliche Bewertung. Risikoeinstufung, Zweckbeschreibung und Angemessenheit müssen gemeinsam mit Fachbereich, Compliance und Recht bewertet werden.
Begrenzte Einsicht bei Foundation Models
Bei proprietären Foundation Models sind Trainingsdaten und interne Modellmechanismen nur begrenzt einsehbar. Welche Pflichten beim Anbieter und welche beim einsetzenden Unternehmen liegen, hängt von Rolle, Vertrag und Anwendungsfall ab.
Sich weiterentwickelnde Rechtslage
Rechtsauslegung, Standards und technische Leitlinien entwickeln sich weiter. Tagging, Logging und Evaluationsprozesse sollten deshalb regelmäßig überprüft und angepasst werden.
Fazit
AI-Governance auf Databricks sollte als Kombination aus Architektur, Prozessen und Verantwortlichkeiten verstanden werden.
AI-Governance auf Databricks sollte als Kombination aus Architektur, Prozessen und Verantwortlichkeiten verstanden werden. Unity Catalog, Lineage, Unity AI Gateway, MLflow, Model Registry, Lakehouse Monitoring und System Tables übernehmen dabei unterschiedliche Aufgaben. Sind diese Komponenten sauber verbunden, lassen sich viele technische Nachweise automatisiert oder mit wiederverwendbaren SQL-Abfragen erzeugen.
Ein sinnvoller Ausgangspunkt ist ein verbindliches Tagging-, Owner- und Lineagekonzept in Unity Catalog. Produktive LLM-Zugriffe sollten möglichst über einen zentral verwalteten und protokollierten Zugang erfolgen. Das technische Modellinventar sollte aus Unity-Catalog-, MLflow- und Systemmetadaten aufgebaut werden. Eine externe Governance-Lösung sollte nur ergänzt werden, wenn sie eine reale Multi-Plattform-Lücke schließt und nicht lediglich bestehende Metadaten doppelt pflegt.
Ein sinnvoller Ausgangspunkt ist ein verbindliches Tagging-, Owner- und Lineagekonzept in Unity Catalog.
FAQ
AI-Governance auf Databricks ist eine Architektur-Disziplin. Sieben Plattform-Schichten (Unity Catalog, Lineage, Unity AI Gateway, Managed MLflow, Mosaic AI Model Registry, Lakehouse Monitoring, System Tables) tragen gemeinsam die regulatorische und betriebliche Pflicht für KI-Systeme. Sie bildet sich aus dem Zusammenspiel von Berechtigungen, Klassifizierung, kontrolliertem LLM-Zugriff, Modell-Inventar, Drift-Monitoring und Audit-Datenbasis.
