Data Governance: vom Rahmenwerk zum Nachweis

Auf einen Blick

• Data Governance bezeichnet das Betriebsmodell für Daten: wer entscheidet, nach welchen Regeln, in welchen Prozessen, auf welcher Technologie. Darin sind sich sämtliche Leitfäden einig.
• Geändert hat sich das Ergebnis. Sobald KI-Systeme im Bestand sind, muss Data Governance Nachweise hervorbringen und nicht mehr bloß Entscheidungen.
• Artikel 10 der KI-Verordnung stellt acht ausdrückliche Anforderungen an Trainings-, Validierungs- und Testdaten.
• DAMA-DMBOK, DCAM, DGI und COBIT stammen aus einer Zeit vor der Regulierung von Trainingsdaten. Als Gerüst taugen sie weiterhin, doch keines sagt, was abzulegen ist.
• Eine einzige Prüffrage entscheidet: Kann Ihre Data Governance für jedes produktive Modell ein Datenblatt, einen Herkunftsnachweis und einen Bericht zur Verzerrungsprüfung vorlegen?

Was Data Governance tatsächlich bedeutet

Data Governance ist das Betriebsmodell, das festlegt, wie eine Organisation Daten erhebt, speichert, schützt und nutzt. Es besteht aus vier wiederkehrenden Bestandteilen: Richtlinien und Standards, die die Regeln setzen, Rollen und Verantwortlichkeiten, die die Rechenschaftspflicht tragen, Prozesse, die Regeln in Routine überführen, und Technologie, die festhält, was geschehen ist.

Dieser Konsens ist zutreffend und zugleich unvollständig, weil er eine Entscheidungsstruktur beschreibt und kaum etwas darüber sagt, was diese Struktur hervorbringen muss. Zwei Jahrzehnte lang fiel das nicht ins Gewicht, denn der Adressat des Modells war die Organisation selbst: ein Qualitätsdashboard, ein Steuerungsgremium und ein Katalog, der den Fachbereichen beim Auffinden von Beständen half.

Das gilt nicht mehr. Sobald Daten ein KI-System speisen, kann der Adressat Ihrer Data Governance eine benannte Stelle, eine Marktaufsichtsbehörde oder ein Großkunde sein, der eine Lieferantenprüfung durchführt. Diese Leser akzeptieren kein Betriebsmodell als Antwort, sondern verlangen Unterlagen. Ein Modell, das keine liefern kann, ist eine Compliance-Erzählung, und das ist etwas anderes. Eingebettet ist das Thema in die weitere Frage der KI-Governance als operative Disziplin.

Data Governance und Datenmanagement

Die Abgrenzung ist einfacher, als die meisten Darstellungen vermuten lassen. Datenmanagement ist Ausführung: Pipelines, Speicherung, Qualitätsregeln, Stammdaten, Integration. Data Governance ist die darüberliegende Autoritätsebene: wer entscheiden darf, welcher Standard gilt und wie die Organisation belegt, dass der Standard eingehalten wurde.

Eine brauchbare Merkregel lautet, dass das Management das Wie beantwortet, während die Governance beantwortet, wer es angeordnet hat und wo der Beleg liegt. Wer ausschließlich Prozessdokumentation erzeugt, hat Management beschrieben und es Governance genannt.

Die vier Referenzmodelle und wofür sie geschaffen wurden

Alle einschlägigen Darstellungen nennen dieselbe Liste. Diese Modelle konkurrieren nicht miteinander, sondern wurden für unterschiedliche Aufgaben entworfen.

Modell	Herausgeber	Zweck	Sinnvolle Verwendung
DAMA-DMBOK	DAMA International	Datenmanagementpraxis über elf Wissensgebiete definieren	Als Praxisreferenz und Begriffsapparat
DCAM	EDM Council	Reifegrad gegen einen Maßstab bewerten	Als Bewertungsinstrument
DGI-Rahmenwerk	Data Governance Institute	Entscheidungsrechte und Rechenschaftswege gestalten	Als Organisationsebene
COBIT	ISACA	IT- und Technologierisiken durchgängig steuern	Als Prüf- und Kontrollvokabular

Das verbreitete Muster des Jahres 2026 kombiniert sie: DAMA-DMBOK definiert die gute Praxis, DCAM misst den Abstand dazu. Die in Arbeit befindliche Fassung DMBOK 3.0 erweitert den Geltungsbereich auf das Datenmanagement für maschinelles Lernen, was die Richtung der Entwicklung deutlich anzeigt.

Warum keines für KI-Systeme entworfen wurde

Alle vier wurden konzipiert, um Daten als Vermögenswert der Organisation zu steuern. Keines wurde konzipiert, um Daten als Bestandteil eines regulierten Produkts zu steuern. Diese Verschiebung ist nicht kosmetischer Natur.

Im Vermögenswertmodell lautet die Frage an einen Datenbestand, ob er richtig, auffindbar, gesichert und einem Eigentümer zugeordnet ist. Im Produktmodell lautet sie anders: War genau dieser Trainingsdatensatz relevant und hinreichend repräsentativ für genau den Zweck, zu dem das Modell in Verkehr gebracht wurde, und können Sie den Nachweis führen? Eine Data Governance, die auf dem Vermögenswertmodell aufsetzt, beantwortet die erste Frage mühelos und die zweite überhaupt nicht.

Was sich ändert, wenn KI in den Datenbestand eintritt

Drei Dinge ändern sich gleichzeitig.

Erstens werden Trainings-, Validierungs- und Testdaten zu einem regulierten Gegenstand mit gesetzlich festgelegten Qualitätskriterien. Sie sind keine bloßen Eingaben einer Auswertung mehr, sondern die Beweisgrundlage einer Konformitätsaussage über ein Produkt.

Zweitens erhält jeder Datenbestand einen Verantwortlichen, der für Repräsentativität einstehen muss und nicht nur für Richtigkeit. Das sind verschiedene Eigenschaften, denn ein Datensatz kann völlig zutreffend sein und dennoch die falsche Population abbilden.

Drittens verliert das Inventar, auf dem Ihre Data Governance beruht, seine Verlässlichkeit. Das Modell setzt voraus, dass bekannt ist, welche Systeme welche Daten verarbeiten. Nicht gemeldete Werkzeuge brechen diese Annahme unbemerkt auf, weshalb Schatten-KI zuerst ein Datenproblem und erst danach ein Sicherheitsproblem ist. Wenn ein Team Kundendaten in einen nicht freigegebenen Assistenten einfügt, verzeichnet kein Register diesen Fluss, und keine Richtlinie hat gegriffen.

Artikel 10 der KI-Verordnung: die zu erfüllenden Pflichten

Artikel 10 ist die Vorschrift, die Data Governance von einer guten Praxis zu einer Rechtspflicht für Hochrisiko-KI-Systeme macht. Nach Artikel 10 Absatz 1 müssen Hochrisikosysteme, die mit Trainingsverfahren entwickelt werden, auf Trainings-, Validierungs- und Testdatensätzen beruhen, die den in der Vorschrift genannten Qualitätskriterien genügen.

Absatz 2 verlangt, dass diese Datensätze angemessenen Daten-Governance- und Datenverwaltungsverfahren unterliegen, und zählt acht Punkte auf, die abzudecken sind. Als Lastenheft gelesen, verlangen sie die Dokumentation von:

1. Gestaltungsentscheidungen, festgehalten statt unterstellt.
2. Erhebungsverfahren und Herkunft der Daten, bei personenbezogenen Daten einschließlich des ursprünglichen Erhebungszwecks.
3. Aufbereitungsschritten wie Annotation, Kennzeichnung, Bereinigung, Aktualisierung, Anreicherung und Aggregation.
4. Annahmen darüber, was die Daten messen und abbilden sollen.
5. Bewertung von Verfügbarkeit, Menge und Eignung der benötigten Datensätze.
6. Prüfung auf Verzerrungen, die Gesundheit, Sicherheit oder Grundrechte beeinträchtigen können, einschließlich diskriminierender Wirkungen.
7. Geeigneten Maßnahmen zur Erkennung, Verhinderung und Abschwächung solcher Verzerrungen.
8. Ermittlung von Datenlücken und Mängeln, die der Konformität entgegenstehen, samt Abhilfe.

Absatz 3 setzt die Messlatte selbst: Datensätze müssen relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig im Hinblick auf die Zweckbestimmung sein, mit angemessenen statistischen Eigenschaften für die betroffenen Personengruppen. Absatz 4 verlangt, die Besonderheiten des geografischen, kontextuellen, verhaltensbezogenen oder funktionalen Umfelds zu berücksichtigen. Ein Bewerbungsmodell, das auf einem nationalen Arbeitsmarkt validiert wurde, nimmt diese Validierung nicht über die Grenze mit.

Absatz 5 enthält eine enge und häufig missverstandene Erlaubnis: Anbieter dürfen ausnahmsweise besondere Kategorien personenbezogener Daten verarbeiten, soweit dies zur Erkennung und Korrektur von Verzerrungen unbedingt erforderlich ist, vorbehaltlich geeigneter Garantien und nur dann, wenn andere Daten den Zweck nicht wirksam erfüllen können. Es handelt sich um eine eingehegte Ausnahme und nicht um eine Erlaubnis zur routinemäßigen Erhebung sensibler Merkmale, worauf auch die Datenschutzaufsicht in ihrer Spruchpraxis regelmäßig hinweist. Absatz 6 schließt den Kreis für Systeme, die nicht aus Daten lernen: Dort gelten die Pflichten nur für Testdatensätze. Der Gesamtaufbau dieser Pflichten ist in unserem operativen Leitfaden zur KI-Verordnung dargestellt.

Anhang IV und die Pflicht zum Datenblatt

Artikel 10 sagt, wie die Daten beschaffen sein müssen. Anhang IV sagt, was schriftlich vorliegen muss. Nummer 2 Buchstabe d des Anhangs IV verlangt, dass die technische Dokumentation gegebenenfalls Datenblätter enthält, die Trainingsmethoden und -verfahren sowie die verwendeten Trainingsdatensätze beschreiben: allgemeine Beschreibung, Herkunft, Umfang und wesentliche Merkmale, Art der Beschaffung und Auswahl, Kennzeichnungsverfahren sowie Verfahren der Datenbereinigung. Nummer 2 Buchstabe g erstreckt dieselbe Disziplin auf Validierungs- und Testdaten sowie auf die Metriken für Genauigkeit und Robustheit.

Dieser Satz verändert die Arbeit. Herkunftsverfolgung ist kein Komfort mehr für Analysten, sondern ein Dokumentationsergebnis in vorgegebener Form. Die wissenschaftliche Grundlage dazu liefert die Arbeit von Gebru und Kolleginnen, Datasheets for Datasets, die genau dieses Format vorschlug: Motivation, Zusammensetzung, Erhebungsprozess, Vorverarbeitung, Verwendungszwecke, Verbreitung und Pflege. Unser Leitfaden zur KI-Systemdokumentation behandelt die übrige Akte.

Was Betreiber nach Artikel 26 Absatz 4 schulden

Die einschlägige Literatur wendet sich fast immer an den Dateneigentümer. Die Verordnung bindet aber auch das Unternehmen, das das System lediglich einkauft. Nach Artikel 26 Absatz 4 muss ein Betreiber, der Kontrolle über die Eingabedaten ausübt, dafür sorgen, dass diese Daten der Zweckbestimmung des Hochrisikosystems entsprechend relevant und hinreichend repräsentativ sind. Absatz 6 verlangt, die automatisch erzeugten Protokolle mindestens sechs Monate aufzubewahren.

Wer also ein Scoring-Modell lizenziert und mit eigenen Beständen speist, trägt über diese Bestände eine gesetzliche Pflicht. Der Einkauf des Modells lagert die Datenpflicht nicht aus.

Die Säulen auf ISO 42001 und das NIST AI RMF abbilden

Der sinnvolle Schritt besteht nicht darin, das Bestehende zu ersetzen, sondern darin, jede Säule so neu zuzuschneiden, dass sie ein Ergebnis abwirft. Die folgende Tabelle fasst die Zuordnung zusammen.

Klassische Säule	ISO/IEC 42001 Anhang A	NIST AI RMF	Zu erzeugender Nachweis
Richtlinien und Standards	A.7.2 Daten für die Entwicklung, A.7.4 Datenqualität	MAP 2.3	Schriftliche Qualitätskriterien je Zweckbestimmung
Rollen und Verantwortlichkeiten	A.7.3 Datenbeschaffung	MAP 4.1, MAP 4.2	Benannter Verantwortlicher und Prüfung fremder Daten
Prozesse	A.7.6 Datenaufbereitung	MAP 2.3	Kennzeichnungsprotokoll, Bericht zur Verzerrungsprüfung
Technologie	A.7.5 Datenherkunft	MEASURE 2.2	Herkunftsnachweis vom Quellsystem bis zur Modelleingabe

Die Norm ISO/IEC 42001 bündelt ihre Datenanforderungen im Anhang-A-Control A.7, Daten für KI-Systeme, gegliedert in A.7.2 Daten für Entwicklung und Verbesserung, A.7.3 Datenbeschaffung, A.7.4 Datenqualität, A.7.5 Datenherkunft und A.7.6 Datenaufbereitung. Wer eine Zertifizierung anstrebt, arbeitet gegen genau diese Liste, die sich mit Artikel 10 verzahnt, ohne ihn zu verdoppeln. Warum ISO 42001 allein die Konformität mit der KI-Verordnung nicht herstellt, haben wir gesondert dargestellt.

Das NIST AI RMF liefert demgegenüber ein Risikovokabular und kein Zertifizierungsziel. Die Unterkategorie MAP 2.3 behandelt wissenschaftliche Integrität sowie Test, Bewertung, Verifizierung und Validierung und schließt dabei Versuchsplanung sowie Datenerhebung und Datenauswahl ausdrücklich ein. MAP 4.1 und 4.2 betreffen Risiken aus Fremddaten und die Pflicht, extern bezogenes Material vor der Freigabe auf Verzerrung, Datenschutz und Sicherheit zu prüfen. Dieser Punkt gewinnt jährlich an Gewicht, da die meisten Organisationen inzwischen auf Daten trainieren, die sie nicht selbst erhoben haben. Die vollständige Gegenüberstellung findet sich in unserem Vergleich von NIST AI RMF, ISO 42001, KI-Verordnung und OECD-Prinzipien.

Die Liste der vorzulegenden Nachweise

Die praktische Übersetzung lautet: Eine Data Governance, die KI-Systeme abdeckt, muss auf Anforderung und je System die folgenden neun Unterlagen vorlegen können.

1. Ein Datenbestandsregister, das mit dem KI-Inventar verknüpft ist, damit jedes Modell den verarbeiteten Daten zugeordnet werden kann.
2. Ein Datenblatt je Trainings-, Validierungs- und Testdatensatz in der Form des Anhangs IV.
3. Ein Herkunftsnachweis vom Quellsystem bis zur Modelleingabe einschließlich aller Transformationen.
4. Ein Bericht zur Verzerrungsprüfung mit Angabe der geprüften geschützten Merkmale und der Methode.
5. Ein Entscheidungsprotokoll zur Abschwächung, das auch die Annahme verbleibender Verzerrung und die entscheidende Person festhält.
6. Ein Register der Lücken und Mängel mit Verantwortlichen und Fristen, womit Absatz 2 Buchstabe h operativ wird.
7. Ein Annotationsprotokoll, bei wertenden Kennzeichnungen mit Maß für die Übereinstimmung zwischen Annotierenden.
8. Ein Nachweis zu Aufbewahrung und Rechtsgrundlage, verknüpft mit der Datenschutz-Folgenabschätzung, soweit personenbezogene Daten betroffen sind.
9. Eine namentliche Freigabe je Datensatzversion, denn eine nicht gezeichnete Unterlage ist eine Behauptung und keine Kontrolle.

Die Punkte vier und fünf sind in den meisten Programmen am schwächsten ausgeprägt und werden von Prüfern zuerst verlangt. Unser Leitfaden zu KI-Bias behandelt die Prüfmethoden selbst.

Das Register kritischer Datenelemente, auf KI erweitert

Regulierte Unternehmen führen bereits ein Register kritischer Datenelemente. Sie brauchen kein zweites Register, sondern einen Fremdschlüssel.

Ergänzen Sie eine Beziehung zwischen jedem kritischen Datenelement und den KI-Systemen, die es verarbeiten, und das Register ist nicht länger ein Qualitätsartefakt, sondern beantwortet Compliance-Fragen: Welche Modelle sind betroffen, wenn sich dieses Element verschlechtert, welche Datensätze haben dessen bekannte Mängel geerbt, und welche Modellverantwortlichen sind zu informieren, wenn sich seine Definition ändert. Diese eine Verknüpfung verwandelt bereits geleistete Arbeit zu geringen Kosten in Nachweise und ist damit die wirksamste Änderung an einem bestehenden Modell.

Aufbau in neunzig Tagen

Eine belastbare Reihenfolge für Organisationen, die bereits über Data Governance verfügen und sie nun auf KI ausdehnen müssen.

1. Woche 1 und 2, Geltungsbereich und Rechtsauslöser. Klären Sie, welche Systeme hochriskant sind, welche Modelle mit allgemeinem Verwendungszweck Sie lediglich betreiben und welche außerhalb liegen. Die Pflichten unterscheiden sich erheblich, und Einordnungsfehler werden später teuer.
2. Woche 3 und 4, Inventar. Erfassen Sie KI-Systeme und die jeweils verarbeiteten Datenbestände. Rechnen Sie im ersten Durchgang mit Lücken und planen Sie eine Suche nach nicht gemeldeten Werkzeugen ein.
3. Woche 5, Klassifizierung. Kennzeichnen Sie jeden Bestand nach Sensibilität, Rechtsgrundlage, Herkunft (intern, Dritte, synthetisch, gescrapt) und nach Trainings-, Validierungs- oder Testeigenschaft.
4. Woche 6, Verantwortlichkeiten. Benennen Sie je Datenbestand eine verantwortliche Person, kein Team. Geteilte Verantwortung ist fehlende Verantwortung.
5. Woche 7 bis 9, Dokumentation. Verfassen Sie die Datenblätter in der Form des Anhangs IV und beginnen Sie beim risikoreichsten System, weil das Format dort belastet wird.
6. Woche 10 und 11, Repräsentativitätsprüfung. Vergleichen Sie die statistischen Eigenschaften der Bestände mit der Zielpopulation und dem Einsatzumfeld. Halten Sie die gefundenen Abweichungen fest, statt sie stillschweigend zu bereinigen.
7. Woche 12, Freigabe und Takt. Holen Sie die namentliche Freigabe ein und legen Sie den Auslöser für die Überprüfung fest. Koppeln Sie ihn an Nachtrainings und nicht an den Kalender.

Gerade der Takt wird am häufigsten falsch gesetzt. Wenn Ihr KI-Governance-Rahmenwerk die Daten jährlich prüft, während Modelle wöchentlich nachtrainiert werden, beschreibt die Dokumentation ein System, das nicht mehr existiert.

Die fünf wiederkehrenden Fehlschläge

Reifegrad als Inszenierung. Das Programm bewertet sich selbst an einem Reifemodell und meldet Fortschritt, ohne dass ein Beleg hinter der Note steht. Eine Erklärung des Managements ist kein Nachweis.

Werkzeug vor Regel. Ein Katalog wird beschafft, bevor die Richtlinie geschrieben ist, die er durchsetzen soll. Das Werkzeug kodiert dann die Konventionen desjenigen, der es eingerichtet hat.

Kein Verantwortlicher für Trainingsdaten. Quellsysteme haben Eigentümer. Der daraus abgeleitete Trainingsdatensatz, aus vier Quellen zusammengeführt, gefiltert, neu gekennzeichnet und für eine Modellversion eingefroren, hat in der Regel keinen.

Register ohne Verknüpfung. Datenkatalog und KI-Inventar liegen in verschiedenen Werkzeugen und werden von verschiedenen Teams gepflegt, sodass keine Abfrage beantworten kann, welches Modell welche Daten genutzt hat. Das ist der häufigste Grund, warum ein KI-Audit nichts Verwertbares vorfindet.

Geltungsbereich endet bei personenbezogenen Daten. Datenschutzprogramme decken personenbezogene Daten gut ab. Artikel 10 erfasst sämtliche Trainingsdaten, auch betriebliche, sensorische und synthetische ohne jeden Personenbezug.

Häufige Fragen

Was sind die vier Säulen der Data Governance?

Richtlinien und Standards, Rollen und Verantwortlichkeiten, Prozesse sowie Technologie. Manche Anbieter gliedern das in fünf, sieben oder zehn Bestandteile, doch die Ergänzungen sind Unterteilungen und keine neuen Kategorien: Datenqualität, Metadatenverwaltung und Herkunftsverfolgung gehören zu Prozessen und Technologie. Sobald KI-Systeme im Spiel sind, ist ein fünfter Aspekt zwingend, obwohl er selten genannt wird: die erzeugten Nachweise, also Datenblätter, Herkunftsnachweise und Verzerrungsberichte, die eine Aufsicht tatsächlich lesen kann.

Was sind die wichtigsten Grundsätze?

Rechenschaft mit benannter Verantwortung je Datenbestand, Transparenz über Herkunft und Transformationen, Qualität gemessen an einem erklärten Zweck statt im Abstrakten, Schutz entsprechend Sensibilität und Rechtsgrundlage sowie Nachvollziehbarkeit von der Quelle bis zur Nutzung. Unter der KI-Verordnung wiegen Qualität und Nachvollziehbarkeit am schwersten, weil Artikel 10 Absatz 3 einen zweckbezogenen und keinen allgemeinen Maßstab anlegt.

Worin unterscheiden sich Data Governance und KI-Governance?

Die eine steuert die Daten. Die andere steuert die darauf errichteten Systeme samt Modellen, Einsatzentscheidungen, menschlicher Aufsicht und Vorfallbehandlung. Sie überschneiden sich an genau einer Stelle, den Trainingsdaten, und dort setzt die KI-Verordnung ihre schwersten Dokumentationspflichten an. In der Praxis sollten beide ein Inventar und eine Risikotaxonomie teilen, aber getrennte Verantwortliche und getrennte Prüftakte behalten.

Welches Rahmenwerk sollten wir wählen: DAMA-DMBOK, DCAM oder DGI?

Eine Auswahl ist meist gar nicht nötig. DAMA-DMBOK liefert Praxisdefinition und Begriffe, DCAM die Reifegradmessung, DGI die Gestaltung der Entscheidungsrechte. Üblich ist die Kombination aus DMBOK für die Praxis und DCAM für die Fortschrittsmessung. Sind KI-Systeme im Geltungsbereich, genügt keines der drei für sich, weil keines die von Anhang IV geforderten Unterlagen spezifiziert. Dafür ist Anhang A.7 der ISO/IEC 42001 zu überlagern.

Verlangt die KI-Verordnung eine Data Governance?

Für Hochrisikosysteme im Ergebnis ja. Artikel 10 Absatz 2 verlangt, dass Trainings-, Validierungs- und Testdatensätze angemessenen Daten-Governance- und Datenverwaltungsverfahren unterliegen, und benennt anschließend acht abzudeckende Punkte. Die Verordnung nennt kein Rahmenwerk und schreibt kein bestimmtes Modell vor, sodass ein angepasstes bestehendes Vorgehen genügen kann. Vorgeschrieben ist jedoch das dokumentarische Ergebnis, und zwar über Anhang IV.

Wer trägt die Verantwortung?

Sie liegt üblicherweise beim Chief Data Officer oder einer gleichwertigen Funktion, unterstützt von einem Gremium für bereichsübergreifende Entscheidungen. Wichtiger als der Titel sind zwei Bedingungen: dass die Verantwortung auf Ebene des einzelnen Datenbestands persönlich ist und dass ihr Träger eine Freigabe blockieren kann. Sind KI-Systeme betroffen, müssen die Verantwortlichen für Data Governance und für KI-Governance gemeinsam über Trainingsdaten entscheiden, weil keiner von beiden allein freigeben kann.

Fazit

Die verfügbaren Leitfäden sagen Ihnen, dass Data Governance auf vier Säulen ruht und dass Sie ein Rahmenwerk wählen sollten. Das trifft zu, und dort endet der übliche Rat. Die schwierigere Frage lautet, was Sie herausgeben, wenn eine Stelle außerhalb Ihrer Organisation wissen will, wie der Trainingsdatensatz eines Modells zusammengestellt wurde, ob er die Menschen abbildete, auf die das Modell angewendet werden sollte, und wer ihn freigegeben hat.

Wenn die ehrliche Antwort heute aus einer Richtlinie und einem Screenshot des Katalogs besteht, liegt die Schwäche nicht bei den Säulen. Sie liegt bei den Unterlagen, die von ihnen nie verlangt wurden. Beginnen Sie mit dem Datenbestandsregister, das mit Ihrem KI-Inventar verknüpft ist: Der Rest der Nachweiskette findet dann seinen Anker.

Erfahren Sie, wie AI Sigil Pflichten der Data Governance in prüffeste Nachweise überführt.