7 Compliance-Verantwortliche und IT-Leiter im öffentlichen Sektor betreten zunehmend unbekanntes Terrain: die Entwicklung von KI und Machine Learning. Ihr Unternehmen entwickelt Machine-Learning-Modelle. Die Teams iterieren schnell. Data Scientists drängen auf Agilität. Gleichzeitig sind Sie für Governance, Audit-Trails und regulatorische Compliance verantwortlich. Diese Prioritäten scheinen manchmal im Widerspruch zu stehen. Das Spannungsfeld ist real, aber lösbar. Der Schlüssel ist zu verstehen, wie sich die Datenspeicherung für MLOps mit Compliance-Anforderungen überschneidet. Wenn Ihr Unternehmen Trainingsdaten speichert, die Modellentwicklung überwacht und KI-Entscheidungen auditiert, unterliegen diese Aktivitäten denselben regulatorischen Frameworks wie die klassische IT-Infrastruktur: der DSGVO für personenbezogene Daten, HIPAA für Daten aus dem Gesundheitswesen, SOX für Finanzdienstleistungen und zunehmend KI-spezifischen Vorschriften wie dem EU AI Act. Dieser Beitrag richtet sich an Compliance-Verantwortliche, die mit MLOps-Teams zusammenarbeiten müssen, ohne tiefes technisches ML-Wissen zu benötigen. Er erklärt, was die Datenspeicherung für MLOps umfasst, warum Compliance wichtiger ist, als die meisten Data Scientists zunächst annehmen, und wie Sie eine Governance aufbauen, die schnelle KI-Entwicklung ermöglicht und zugleich regulatorische Pflichten erfüllt. Was Compliance-Verantwortliche über ML-Trainingsdaten wissen müssen Machine-Learning-Modelle werden mit Daten trainiert. Das können Kundendatensätze, Krankengeschichten, Finanztransaktionen oder Sensorwerte sein. Unabhängig von der Quelle gilt: Enthalten die Trainingsdaten personenbezogene Informationen oder unterliegen sie regulatorischen Anforderungen, müssen Compliance-Kontrollen greifen. Genau hier stolpern viele Unternehmen: Sie behandeln Trainingsdaten anders als operative Daten. Ein Finanzunternehmen hat vielleicht strenge Kontrollen für Kundentransaktionsdaten im Produktivsystem, aber deutlich lockerere Kontrollen für dieselben Daten, sobald sie in eine ML-Trainingsumgebung kopiert wurden. Das ist eine Compliance-Lücke. Aus regulatorischer Sicht sind Trainingsdaten Daten. Gilt die DSGVO für Kundendaten in Ihrem operativen System, gilt sie auch für Kundendaten in Ihrer ML-Trainingsumgebung. Gilt PCI-DSS für Zahlungskartendaten, gilt es auch für Zahlungskartendaten in Trainingsdatensätzen. Das regulatorische Framework ändert sich nicht dadurch, ob die Daten in einer Datenbank oder einem Trainingsdatensatz liegen. ML-Training schafft jedoch besondere Compliance-Herausforderungen, die es in der klassischen IT nicht gibt: Daten werden über mehrere Trainingsläufe hinweg dupliziert, Datensätze werden versioniert und archiviert, Modelle werden mit Daten trainiert, die mit der Zeit schwerer nachzuverfolgen sind, und Entscheidungen von Modellen, die mit verzerrten Daten trainiert wurden, können regulatorische Folgen haben. Datenherkunft und Audit-Trails für das ML-Training Eine zentrale Compliance-Anforderung ist es zu wissen, woher Daten stammen und was mit ihnen geschehen ist. Bei klassischen Datenbanken ist das einfacher: Transaktionslogs zeigen, welcher Benutzer wann welchen Datensatz geändert hat. Bei ML ist die Kette komplexer. Ein Modell wird mit einem Datensatz trainiert. Dieser Datensatz ist vielleicht eine Teilmenge der Produktionsdaten, kombiniert mit historischen Daten, wobei einige Datensätze entfernt oder transformiert wurden. Der Datensatz wird versioniert. Vielleicht nutzte v1.0 Datensätze aus 2023, v2.0 ergänzte Datensätze aus 2024 und entfernte Ausreißer, und v3.0 wandte eine Transformation an, um Probleme mit der Datenqualität zu beheben. Welche Version wurde für das Training des Produktivmodells verwendet? Eine Lösung für skalierbaren Speicher für KI-Pipelines (auf Englisch) mit Versionierung macht die Nachverfolgung dieser Herkunft einfach. Aus Compliance-Sicht müssen Sie beantworten können: Mit welchen Daten wurde dieses Modell trainiert? Woher stammen diese Daten? Lag eine gültige Einwilligung vor (für die DSGVO)? Waren die Daten für diese Nutzung freigegeben? Wurden die Daten seit dem Training aktualisiert (etwa weil ein Kunde die Löschung beantragt hat)? Falls ja: Muss das Modell neu trainiert werden? Das erfordert eine systematische Nachverfolgung der Datenherkunft. Ihre MLOps-Infrastruktur sollte automatisch Folgendes erfassen: Metadaten der Datensätze: Jeder Datensatz sollte Angaben zu Erstellungsdatum, Version, Quellsystem, Datenverantwortlichem und Aufbewahrungsrichtlinie enthalten. Erstellt ein Data Scientist einen Trainingsdatensatz, sollten diese Felder ausgefüllt werden (über Vorlagen oder Automatisierung, nicht als Freitext). Datenprovenienz: Das System sollte nachverfolgen, welche Produktionsdatensätze in den Trainingsdatensatz eingeflossen sind. Müssen Sie die personenbezogenen Daten eines Kunden löschen (aufgrund eines Löschantrags nach der DSGVO), sollten Sie ermitteln können, welche Trainingsdatensätze diese Daten enthielten und ob die damit trainierten Modelle neu trainiert werden müssen. Protokolle des Modelltrainings: Jeder Trainingslauf sollte protokolliert werden: welcher Datensatz, wann, wer ihn gestartet hat, welche Parameter verwendet wurden und wie leistungsfähig das resultierende Modell war. Diese Protokolle bilden Ihren Audit-Trail. Protokolle der Modellbereitstellung: Geht ein Modell in Produktion, protokollieren Sie diese Entscheidung. Wer hat sie genehmigt? Welche Tests wurden durchgeführt? Dieses Protokoll ist entscheidend, wenn Ermittler von Aufsichtsbehörden später fragen, warum ein Modell mit verzerrten Entscheidungen in Betrieb genommen wurde. Bias und Fairness im Compliance-Kontext KI-Regulierung befasst sich zunehmend mit algorithmischem Bias. Der EU AI Act adressiert ausdrücklich KI-Systeme mit hohem Risiko, darunter solche für Personalentscheidungen, Kreditwürdigkeitsprüfungen und die Strafjustiz. Aufsichtsbehörden wollen Belege dafür sehen, dass Ihr Unternehmen Modelle vor der Inbetriebnahme auf Bias getestet hat. Aus Sicht der Compliance bedeutet das: Bias-Tests müssen dokumentiert werden: Ihr Data-Science-Team sollte Modelle vor dem produktiven Einsatz auf Bias in Bezug auf geschützte Merkmale (Herkunft, Geschlecht, Alter usw.) testen. Diese Tests sollten mit ihren Ergebnissen und allen ergriffenen Gegenmaßnahmen protokolliert werden. Zeigt ein Modell Bias, dokumentieren Sie, warum das akzeptabel war oder was Sie dagegen unternehmen. Die Zusammensetzung der Trainingsdaten zählt: Sind Ihre Trainingsdaten verzerrt (stammen etwa nur 5 % der Kreditantragsteller in Ihrem Trainingsdatensatz aus Minderheitengruppen), wird das resultierende Modell vermutlich ebenfalls verzerrt sein. Die Compliance sollte die Zusammensetzung Ihrer Trainingsdaten kennen. Ist sie repräsentativ für die Bevölkerung, für die das Modell eingesetzt wird? Folgenabschätzungen sind erforderlich: Führen Sie bei KI-Systemen mit hohem Risiko vor der Inbetriebnahme eine KI-Folgenabschätzung durch. Ähnlich wie eine Datenschutz-Folgenabschätzung dokumentiert sie mögliche Schäden, Strategien zur Risikominderung und das laufende Monitoring. Ermittler von Aufsichtsbehörden werden diese Abschätzung sehen wollen. Monitoring und Audit-Trails: Ist ein Modell in Betrieb, brauchen Sie ein laufendes Monitoring, um zu erkennen, ob sich sein Verhalten ändert oder es beginnt, verzerrte Entscheidungen zu treffen. Dafür müssen Vorhersagen und Ergebnisse protokolliert werden, und Audit-Trails müssen zeigen, welche Modelle welche Entscheidungen treffen. Datenresidenz und Datensouveränität bei MLOps Compliance-Frameworks verlangen zunehmend, dass Daten in bestimmten Rechtsräumen bleiben. Die DSGVO beschränkt die Übermittlung personenbezogener Daten aus der EU in Drittländer (mit wenigen Ausnahmen). Die UK GDPR enthält ähnliche Beschränkungen. Neue Vorschriften in Kanada, Australien und anderen Rechtsräumen bringen zusätzliche Anforderungen an die Datenresidenz mit sich. Beim Training von ML-Modellen müssen die Daten oft dorthin, wo die Rechenleistung ist. Steht Ihre Trainingsinfrastruktur in den USA und haben Sie Daten aus der EU, brauchen Sie ein konformes Verfahren für die Übermittlung und Verarbeitung dieser Daten. Optionen sind: Training On-Premises: Die Trainingsinfrastruktur steht in der EU, die Daten bleiben in der EU. Das sichert die Compliance, erfordert aber erhebliche Infrastrukturinvestitionen und begrenzt die Skalierung. Freigegebene Cloud-Regionen: Viele Cloud-Anbieter bieten Optionen für die Datenresidenz. Sie können Modelle mit Cloud-Rechenleistung in EU-Regionen trainieren und die Daten in EU-Speicher ablegen. Prüfen Sie, ob die Auftragsverarbeitungsverträge des Anbieters DSGVO-konform sind. Datenminimierung: Nutzen Sie nur die für das Training minimal erforderlichen Daten. Lässt sich ein wirksames Modell mit anonymisierten oder synthetischen statt mit personenbezogenen Daten trainieren, verringert das den Umfang der Anforderungen an die Datenresidenz. Vertragliche Absicherung: Setzen Sie für das Training einen Auftragsverarbeiter ein (einen Cloud-Anbieter oder ein externes ML-Team), sollte ein Auftragsverarbeitungsvertrag (AVV) Datenhandhabung, Aufbewahrung und Datenresidenz regeln. Der AVV ist Ihre Compliance-Dokumentation. Für Organisationen im öffentlichen Sektor ist die Datensouveränität (wo Daten physisch gespeichert und verarbeitet werden) oft ebenso wichtig wie die Datenresidenz. Womöglich müssen Sie sicherstellen, dass Daten das Land nie verlassen, auch nicht verschlüsselt. Aufbewahrung und Löschung von Trainingsdaten Trainingsdaten müssen irgendwann gelöscht werden. Regulatorische Frameworks legen in der Regel keine ausdrücklichen Aufbewahrungsfristen für Trainingsdaten fest, doch das Prinzip ist klar: Daten nur so lange aufbewahren, wie sie benötigt werden. Für ML-Teams ist „benötigt“ jedoch mehrdeutig. Daten, mit denen ein Produktivmodell trainiert wurde, werden womöglich unbegrenzt aufbewahrt, weil sich das Modell ohne sie nicht neu trainieren lässt. Wird das Modell ersetzt, werden die Trainingsdaten des alten Modells womöglich nicht mehr gebraucht. Legen Sie ausdrückliche Aufbewahrungsrichtlinien für Trainingsdaten fest: Aufbewahrung nach Nutzung: Ein Datensatz für das aktive Modelltraining sollte so lange aufbewahrt werden, wie das Modell in Produktion ist, plus eine gewisse Zeit danach (falls das Modell reproduziert werden muss). Wird das Modell ausgemustert, können die Trainingsdaten gemäß Ihrem Aufbewahrungsplan gelöscht werden. Klare Richtlinien zur Datenaufbewahrung sorgen für eine einheitliche Anwendung über alle Modelle hinweg. Gesetzliche Aufbewahrung: Für manche Daten gelten gesetzliche Aufbewahrungspflichten. Personalakten, Krankenakten und Finanzdaten müssen womöglich für bestimmte Zeiträume aufbewahrt werden. Selbst wenn das Modell ausgemustert ist, müssen die Daten aus regulatorischen Gründen womöglich bestehen bleiben. Lösch-Workflows: Legen Sie einen Prozess für Löschanträge fest. Ein Datenverantwortlicher oder Compliance-Verantwortlicher sollte die Löschung eines Datensatzes beantragen können. Der Antrag sollte ein Audit-Logging und die Prüfung auslösen, dass keine aktiven Modelle von den Daten abhängen. Anschließend erfolgt die endgültige Löschung (mit Protokollierung). Die Löschung sollte für einen gewissen Zeitraum umkehrbar sein (falls der Antrag fehlerhaft war), dann aber endgültig werden. Recht auf Löschung (DSGVO): Die DSGVO gibt Personen das Recht, die Löschung ihrer personenbezogenen Daten zu verlangen. Beantragt jemand die Löschung, müssen Sie seine Daten aus den Produktivsystemen entfernen – und ebenso aus allen Trainingsdatensätzen, die seine Daten enthalten. Wurde ein Modell mit diesen Daten trainiert, müssen Sie es womöglich neu trainieren, um den Einfluss der Daten tatsächlich zu entfernen. Ein Framework für die Data Governance bei MLOps aufbauen Damit das gelingt, müssen Data Science, MLOps, Compliance und IT zusammenarbeiten. Ein praxisnaher Ansatz: Beginnen Sie mit einem Dateninventar: Dokumentieren Sie, welche Daten für ML genutzt werden. Klassifizieren Sie sie nach Sensibilität und regulatorischem Geltungsbereich. Benennen Sie Datenverantwortliche (Personen, die für Datenqualität und Compliance zuständig sind). Legen Sie Datenrichtlinien fest: Erstellen Sie Vorlagen für die Anlage von Datensätzen. Erstellt ein Data Scientist einen Trainingsdatensatz, gibt er an: Name des Datensatzes, Quellsystem, Zeitraum, enthaltene personenbezogene Daten (ja/nein), Aufbewahrungsfrist und Genehmigung (durch den Datenverantwortlichen und bei sensiblen Daten durch die Compliance). Führen Sie ein Audit-Logging ein: Ihre MLOps-Plattform sollte die Erstellung von Datensätzen, das Modelltraining und die Bereitstellung automatisch protokollieren. Diese Logs speisen Ihr Audit-System und Ihr Compliance-Reporting. Legen Sie Zugriffskontrollen fest: Nicht jeder sollte auf sensible Trainingsdaten zugreifen. Setzen Sie eine rollenbasierte Zugriffskontrolle ein: Data Scientists, die an freigegebenen Modellen arbeiten, können auf ihre Daten zugreifen, alle anderen nicht. Protokollieren Sie jeden Zugriff. Schaffen Sie einen Prozess für die Datenlöschung: Legen Sie fest, wie Datensätze gelöscht werden. Verlangen Sie eine Genehmigung. Prüfen Sie, dass keine Modelle von den Daten abhängen. Führen Sie die Löschung durch und protokollieren Sie sie. Dokumentieren Sie die Löschung in Ihren Compliance-Unterlagen. Führen Sie regelmäßige Audits durch: Auditieren Sie Ihre MLOps-Daten vierteljährlich oder jährlich. Werden Datensätze länger als nötig aufbewahrt? Wurden Löschanträge bearbeitet? Sind die Audit-Logs vollständig? Dokumentieren Sie Befunde und Abhilfemaßnahmen. Die Rolle der Compliance bei MLOps-Entscheidungen MLOps-Teams sehen Compliance oft als Hindernis. Compliance-Teams kennen sich oft nicht mit ML-Prozessen aus. Arbeiten beide jedoch systematisch zusammen, beschleunigt die Compliance die Entwicklung, statt sie zu bremsen. Die Compliance liefert Klarheit darüber, welche Daten genutzt werden dürfen (statt Annahmen). Sie liefert Audit-Trails, die das Unternehmen schützen, wenn etwas schiefgeht. Und sie erkennt Probleme mit Bias oder Fairness frühzeitig vor der Inbetriebnahme. Das senkt das Risiko. MLOps liefert technische Lösungen, die Compliance effizient machen (automatisiertes Logging, Datenversionierung, Nachverfolgung von Deployments), statt sie manuell und aufwendig zu gestalten. Eine gute MLOps-Infrastruktur macht Governance einfach. Die Zusammenarbeit funktioniert am besten, wenn die Compliance früh in Architekturentscheidungen eingebunden ist, wenn MLOps-Teams Audit-Trails und Zugriffskontrollen als Wegbereiter statt als Bremsen verstehen und wenn beide Seiten über geschäftliche Risiken statt über abstrakte Regeln sprechen. Der Weg nach vorn Entwickelt Ihr Unternehmen ML-Modelle und sind Sie für die Compliance verantwortlich, verschaffen Sie sich zunächst einen Überblick über Ihre aktuellen Praktiken im Umgang mit ML-Daten. Wo werden Trainingsdaten gespeichert? Wer hat Zugriff? Wie lange werden sie aufbewahrt? Was passiert, wenn jemand die Löschung von Daten beantragt? Womöglich entdecken Sie Lücken. Bauen Sie dann gemeinsam mit Ihrem MLOps-Team eine systematische Governance auf. Sie muss nicht komplex sein. Sie beginnt mit der Erfassung von Metadaten, der Protokollierung von Zugriffen, der Festlegung von Aufbewahrungsrichtlinien und der Pflege von Audit-Trails. Das meiste davon lässt sich über die Plattform automatisieren. Mit Tiered Storage für KI lassen sich Governance und Kostenmanagement zusätzlich vereinfachen. KI-Regulierung kommt, und sie wird sich genau auf diese Praktiken konzentrieren. Unternehmen, die ihre Data Governance für MLOps bewusst aufgebaut haben, werden die regulatorische Compliance mühelos erfüllen. Alle anderen geraten unter Druck. Ihre Aufgabe als Compliance-Verantwortliche ist es, Ihre ML-Teams zu befähigen, mit Zuversicht zu entwickeln – in dem Wissen, dass Data Governance von Anfang an eingebaut ist und nicht nachträglich aufgesetzt wird. Das schafft zugleich Wettbewerbsvorteile und regulatorische Resilienz. Weiterführende Artikel KI-Datenpipelines: Architektur, Phasen und Best Practices DSGVO-Anforderungen an die Datenspeicherung Best Practices für Identitäts- und Zugriffsmanagement (IAM) Was ist das NIST Cybersecurity Framework? Hybrid-Cloud-Datenstrategie für KI-Workloads Datenverschlüsselung: Leitfaden für Compliance- und IT-Verantwortliche
