KI-Compliance und Datenschutz: Was einer Prüfung tatsächlich standhält

Warum eine einmalige Prüfung dem Kontakt mit Aufsichtsbehörden nicht standhält

Prüfer wollen nicht Ihre Richtlinie. Sie wollen Belege: Protokolle, Entscheidungsdokumentationen, eine namentlich benannte Person, die das Risiko verantwortet, und den Nachweis, dass jemand das System auch sechs Monate nach dem Launch noch beobachtet. Dieser Perspektivwechsel verändert, was „Compliance“ in der Praxis bedeutet. Sie ist keine juristische Freigabe mehr, sondern eine operative Gewohnheit, die fest in die Entwicklung, den Rollout und die anschließende Überwachung des KI-Systems eingebettet ist.

Das ist aus fünf Gründen wichtig, die uns in nahezu jedem bisherigen Projekt begegnet sind:

• Personenbezogene Daten lösen Pflichten aus, sobald sie in die Verarbeitungskette gelangen. Ob die Daten für Training, Inferenz oder lediglich zur Protokollierung genutzt werden, ist der DSGVO und dem CCPA gleichgültig.
• Bias kündigt sich nicht an. Ein Modell, das auf historischen Kredit- oder Einstellungsdaten trainiert wurde, kann still und leise genau die Muster übernehmen, die Aufsichtsbehörden zu unterbinden versuchen. Dafür braucht es einen Prozess, der aktiv danach sucht – nicht die Hoffnung, dass es solche Muster nicht gibt.
• Betroffene einer KI-Entscheidung können eine Erklärung verlangen. Wenn niemand im Team beschreiben kann, wie das Modell zu seinem Ergebnis gelangt ist, ist das eine Lücke – kein technisches Detail.
• Vorfälle brauchen einen Plan, bevor sie eintreten. Meldefristen und Ursachenanalysen lassen sich während eines tatsächlichen Zwischenfalls kaum improvisieren.
• Das Risiko von Anbietern bleibt Ihr Risiko. Wenn ein KI-Anbieter personenbezogene Daten in Ihrem Auftrag verarbeitet, halten Aufsichtsbehörden Sie für dessen Umgang damit verantwortlich.

Nichts davon ist ungewöhnlich. Es ist dieselbe Disziplin, die gute Engineering-Teams bereits im Bereich Sicherheit anwenden. Der Unterschied besteht darin, dass die meisten Organisationen diese Disziplin bisher nicht darauf ausgeweitet haben, wie ihre KI-Systeme mit personenbezogenen Daten umgehen.

Welche Rahmenwerke sind für KI-Compliance im Jahr 2026 relevant

Drei Referenzpunkte tauchen in Kundengesprächen ständig auf: der Leitfaden der ICO, das AI Risk Management Framework des NIST und zunehmend der EU AI Act. Hier eine aktuelle Einordnung, denn vieles, was online dazu geschrieben wird, ist bereits überholt.

Das NIST AI RMF ist um vier Funktionen aufgebaut: Govern, Map, Measure und Manage. Nicht „assess and monitor“, wie es häufig verwechselt wird. Govern steht über den anderen drei und sorgt dafür, dass sie über den gesamten KI-Lebenszyklus hinweg wiederholbar bleiben; Map umreißt das System und seine Risiken; Measure quantifiziert diese; Manage handelt auf Basis der Ergebnisse von Measure. Das Framework ist freiwillig, liegt seit Januar 2023 in der aktuellen Fassung (1.0) vor, und trotz vieler Gerüchte gibt es noch keine Version 2.0. Stattdessen hat NIST das Rahmenwerk durch branchenspezifische Profile erweitert, darunter eines für generative KI.

Das NIST Privacy Framework 1.1 ist noch nicht final. NIST hat es im April 2025 als Initial Public Draft veröffentlicht, bis Mitte 2025 Rückmeldungen eingeholt und arbeitet Anfang 2026 noch an der finalen Fassung. Ein Detail, das Ihr Team bei Zitaten aus diesem Rahmenwerk beachten sollte: Der KI-spezifische Abschnitt des Entwurfs (1.2.2) wurde in späteren Überarbeitungen aus dem Core entfernt, damit das Rahmenwerk technologieneutral bleibt. Zitiert ein Beitrag, den Sie lesen, „Abschnitt 1.2.2“ als gültige Leitlinie, ist das ein Hinweis darauf, dass die Quelle nicht auf dem aktuellen Stand ist.

Der EU AI Act gehört neben DSGVO und ICO-Leitlinien in diese Diskussion, fehlt in vergleichbaren Beiträgen aber meist. Die Pflichten für Hochrisikosysteme sind seit dem 2. August 2026 formal durchsetzbar. Parallel verhandeln EU-Gesetzgeber ein „Digital Omnibus“-Paket, das dieselben Fristen für Hochrisikosysteme auf Dezember 2027 und August 2028 verschieben würde. Zum Zeitpunkt dieses Textes ist diese Verlängerung gesetzlich noch nicht beschlossen. Wenn Ihre Systeme in irgendeiner nennenswerten Weise – über Verkauf, Zugang oder nachgelagerte Integrationen – den EU-Markt berühren, sollten Sie mit dem Aufbau Ihrer Compliance-Grundlage nicht auf politische Klarheit warten. Technische Dokumentation und Risikomanagement-Prozesse sind unabhängig davon sinnvoll, welche Frist am Ende gilt.

Wie unterscheiden sich die KI-Compliance-Regeln im Gesundheits- und Bildungswesen

Compliance-Programme im Gesundheits- und Bildungsbereich scheitern häufiger als andere – aus einem bestimmten Grund: Teams greifen zu einer generischen Datenschutz-Checkliste, statt sich mit dem auseinanderzusetzen, was tatsächlich reguliert ist.

Im Gesundheitswesen setzt HIPAA nicht einfach „Grenzen“ für KI-Anbieter. Wenn ein Anbieter geschützte Gesundheitsinformationen (Protected Health Information, PHI) im Auftrag einer verpflichteten Einrichtung erstellt, empfängt, aufbewahrt oder übermittelt, ist dieser Anbieter rechtlich ein Business Associate, und HIPAA verlangt ein unterzeichnetes Business Associate Agreement (BAA), bevor irgendwelche PHI an ihn fließen dürfen – ohne Ausnahme. Kein BAA, keine PHI, unabhängig davon, wie der Vertrag ansonsten gestaltet ist. Wir haben erlebt, wie das Teams speziell bei KI-Tools überrascht hat: Ein Dokumentationsassistent für den klinischen Alltag oder ein KI-„Scribe“ fällt darunter, selbst wenn der Anbieter sich als „reiner Textverarbeiter“ präsentiert.

Wir haben einen digitalen Avatar-Assistenten für Menschen entwickelt, die sich in einer Krebsbehandlung zurechtfinden müssen, und die Fragen, die dieses Projekt geprägt haben, waren nicht abstrakt. Sie drehten sich darum, welche Daten der Avatar aus einem Gespräch sinnvoll behalten darf und wo die Grenze verläuft, ab der ein BAA oder eine ausdrückliche Einwilligung der Patientin oder des Patienten zwingend erforderlich wird. Jedes Gesundheits-KI-Projekt, an dem wir beteiligt waren, beginnt mit genau dieser Frage – nicht mit einer generischen Risikomatrix.

Im Bildungsbereich enden die meisten Compliance-Gespräche bei Title VI, Title IX und Section 504, die das Office for Civil Rights des Bildungsministeriums gegenüber diskriminierenden KI-Ergebnissen in Zulassung, Benotung oder Mittelverteilung durchsetzt. Was dabei oft ausgelassen wird, ist FERPA, der Family Educational Rights and Privacy Act, das eigentliche Rückgrat des Schutzes von Schüler- und Studentendaten in den USA. FERPA regelt, wer auf die Bildungsakte einer Schülerin oder eines Studenten zugreifen darf und unter welchen Bedingungen eine Bildungseinrichtung einem externen KI-Anbieter überhaupt Zugriff darauf gewähren kann – typischerweise über die eng gefasste Ausnahme des „school official“. Ein KI-Tool, das Aufsätze bewertet oder gefährdete Lernende markiert, verarbeitet FERPA-geschützte Daten, ob dem Anbieter das bewusst ist oder nicht.

De-Identifikation ist eine Methode, keine Garantie

HIPAA sieht zwei anerkannte Wege vor, um PHI zu de-identifizieren, bevor sie für das Training eines KI-Systems verwendet werden. Die Safe-Harbor-Methode entfernt 18 festgelegte Kategorien von Identifikatoren und setzt voraus, dass keine positive Kenntnis darüber besteht, dass die verbleibenden Daten eine Person weiterhin identifizieren könnten. Die Expert-Determination-Methode verlangt, dass ein qualifizierter Statistiker das Re-Identifikationsrisiko als „sehr gering“ nach 45 CFR § 164.514(b)(1) bescheinigt, mit entsprechender Dokumentation.

Beide Methoden wurden entwickelt, bevor Large Language Models existierten. Das ist relevant, denn LLMs und andere ML-Systeme, die auf de-identifizierten Daten trainiert wurden, können unter Umständen identifizierende Details rekonstruieren – insbesondere bei gezielten Abfragen oder in Kombination mit öffentlich zugänglichen Datenquellen. Ein einmaliges Bestehen von Safe Harbor oder Expert Determination beseitigt das Risiko nicht dauerhaft. Es erfordert eine fortlaufende Überwachung mit versionskontrollierten Aufzeichnungen darüber, was wann getan und wann zuletzt überprüft wurde.

Model Drift ist ein technisches Problem – nicht automatisch ein rechtliches

Hier eine Unterscheidung, die in der Compliance-Literatur häufig verwischt wird: Data Drift, also die Verschiebung der statistischen Eigenschaften eingehender Daten im Zeitverlauf, ist eine Frage der Modellqualität. Sie macht ein System nicht automatisch non-compliant. Solange sich Ihre Verfahren zur Datenverarbeitung, Ihre Einwilligungsgrundlage und Ihre Informationspflichten nicht geändert haben, ist Drift allein kein Rechtsverstoß.

Zum Compliance-Problem wird Drift dann, wenn niemand darauf achtet und das System stillschweigend beginnt, Ergebnisse zu produzieren, die unfair oder diskriminierend sind oder außerhalb dessen liegen, was Sie den betroffenen Personen offengelegt haben. Genau deshalb sind „Manage“ und „Monitor“ als fortlaufende Funktionen wichtig – und nicht als Häkchen am Tag des Launches. Die technischen und die rechtlichen Risiken hängen zusammen, sind aber nicht dasselbe. Sie gleichzusetzen, führt in der Regel dazu, dass weder das eine noch das andere ordentlich gesteuert wird.

Wie ein Compliance-Programm aussieht, das tatsächlich standhält

Organisationen, die sich am Ende nicht gegenüber einer Aufsichtsbehörde erklären müssen, haben einige Gewohnheiten gemeinsam. Sie benennen für jedes KI-System eine konkrete verantwortliche Person für die Compliance-Verantwortung, kein Gremium. Sie führen Überprüfungszyklen durch, die an tatsächliche Auslöser gekoppelt sind – etwa ein Modell-Update oder eine neue Datenquelle –, nicht nur an eine Kalendererinnerung. Und sie behandeln die Ergebnisse des Monitorings als Input für die nächste Überprüfung, sodass Probleme sichtbar werden, bevor sie ein Prüfer entdeckt.

Yuri Svirid, CEO von Silk Data, dazu, wie sich das bei konkreten Kunden zeigt: „Das Compliance-Gespräch, das wir mit neuen Kunden führen, dreht sich selten um die Frage, ob eine DSFA durchgeführt werden soll. Es geht darum, wer diese DSFA sechs Monate später verantwortet – und ob die Antwort auf diese Frage einer Nachfrage durch einen Prüfer standhält.“

Wir haben diese Art von Rückkopplungsschleife in Projekten aus den Bereichen Finanzen, Gesundheit und Handel etabliert. Bei einem Dokumentenanalyse-System für einen US-amerikanischen Finanzdienstleister etwa lag die schwierigere Engineering-Aufgabe nicht in der OCR- oder NLP-Pipeline selbst, sondern darin, dafür zu sorgen, dass die Verarbeitung der Finanzunterlagen des Kunden über zehn Entwicklungsmonate hinweg nachvollziehbar blieb, auch als sich Dokumententypen und Volumina veränderten. Genau diese Nachvollziehbarkeit ist das, was Prüfer tatsächlich meinen, wenn sie sagen: „Zeigen Sie mir Ihren Prozess“ – egal, ob es um das Bankwesen oder die Medizin geht.

Wenn Sie ein KI-System aufbauen oder prüfen, das in einer regulierten Branche personenbezogene Daten verarbeitet, arbeitet das Team von Silk Data genau an dieser Art von Fragestellung: Governance, Fairness-Monitoring und datenschutzfreundliche Analytik, die von Anfang an in das System eingebaut werden – statt kurz vor einem Launch-Termin angesetzt zu werden. Wir sprechen gern mit Ihnen darüber, wo es um Ihre konkrete Situation steht.