ISO 42001 und DSGVO ergänzen sich bei der Governance von KI-Systemen, weil der Standard Datenqualität und Transparenz adressiert, während die DSGVO personenbezogene Daten schützt. Für Unternehmen bedeutet das eine doppelte Compliance-Pflicht: KI muss organisatorisch beherrscht und datenschutzrechtlich sauber legitimiert, dokumentiert und überwacht werden. Genau deshalb sollten Sie ISO 42001 und DSGVO nicht getrennt, sondern als integriertes Steuerungsmodell betrachten.
Wer die Grundlagen zuerst einordnen will, findet den Überblick im ISO-42001-Leitfaden, die Basisdefinition im Beitrag Was ist ISO 42001? und die regulatorische Abgrenzung im Beitrag KI-Verordnung vs. DSGVO. Der eigentliche Praxisgewinn entsteht jedoch erst dann, wenn Datenschutz, KI-Governance, Einkauf, IT und Fachbereiche dieselben Systeme mit derselben Dokumentationslogik bewerten.
ISO 42001 und DSGVO — Warum beides zusammenhängt
ISO 42001 und DSGVO hängen zusammen, weil fast jedes produktive KI-System irgendwann personenbezogene Daten berührt. Das gilt nicht nur für Recruiting-Modelle, Scoring, Support-Automatisierung oder Fraud Detection, sondern auch für generative KI in Office-Prozessen, wenn Prompts Kundendaten, Beschäftigtendaten oder Vertragsinhalte enthalten. Sobald ein Personenbezug vorliegt, reicht eine reine KI-Governance ohne Datenschutzprüfung nicht aus.
Die DSGVO beantwortet in solchen Fällen die Rechtsfragen. Unternehmen müssen nach Art. 5 und Art. 6 DSGVO klären, zu welchem Zweck Daten verarbeitet werden, welche Rechtsgrundlage trägt, wie lange Daten gespeichert werden dürfen und welche Betroffenenrechte zu wahren sind. ISO/IEC 42001:2023 beantwortet dagegen die Governance-Fragen: Wer ist verantwortlich, welche Risiken wurden identifiziert, wie werden Kontrollen betrieben, wie wird menschliche Aufsicht organisiert und wie wird die Wirksamkeit regelmäßig überprüft.
Die Synergie liegt darin, dass beide Regelwerke auf denselben betrieblichen Tatsachen aufsetzen. Wenn Sie Trainingsdaten, Testdaten, Prompt-Prozesse, Modellgrenzen, Anbieterrollen und Freigaben dokumentieren, entsteht ein Nachweiskern, der sowohl für Datenschutzprüfungen als auch für das AI-Management-System verwendbar ist. Das Research zu ISO 42001 und DSGVO zeigt deshalb nachvollziehbar, dass rund 15 der 38 Annex-A-Controls einen direkten oder mittelbaren Bezug zu Datenschutz, Transparenz, Datenqualität oder Rechenschaftspflichten haben.
Für die Praxis ist wichtig: ISO 42001 ersetzt die DSGVO nicht, und DSGVO-Compliance ersetzt keine KI-Governance. Ein datenschutzkonformer Vertrag mit einem Cloud-Anbieter sagt noch nichts darüber aus, ob Trainingsdaten biasarm, Freigaben sauber dokumentiert und menschliche Kontrollen wirksam organisiert sind. Umgekehrt genügt ein gutes AIMS nicht, wenn die Rechtsgrundlage nach Art. 6 DSGVO fehlt oder Betroffenenrechte nicht umgesetzt werden. Wer diese Trennung verstehen will, sollte auch den Beitrag Was ist ISO 42001? sowie die Einordnung DSGVO und AI Act – zwei Schulungen? lesen.
Überschneidungen im Überblick
ISO 42001 und DSGVO überschneiden sich vor allem bei Dokumentation, Risikobewertung, Verantwortlichkeiten und Datenkontrollen. Unternehmen sollten diese Überschneidungen bewusst nutzen, statt zwei parallele Nachweiswelten aufzubauen. Das reduziert Medienbrüche, verkürzt Freigabeprozesse und verbessert die Prüfbarkeit gegenüber Management, Datenschutzaufsicht oder internen Audits.
| DSGVO-Anforderung | Relevante ISO-42001-Control oder Anforderung | Gemeinsame Dokumentation |
|---|---|---|
| Art. 5 Zweckbindung und Datenminimierung | A.7 Daten für KI-Systeme, besonders Datenbedarf und Datenqualität | Dateninventar, Use-Case-Beschreibung, Freigabekriterien |
| Art. 6 Rechtsgrundlage | Kontext, Betrieb und dokumentierte Rollen im AIMS | Verarbeitungszweck, Rechtsgrundlage, Verantwortlicher |
| Art. 13 bis 15 Transparenz und Auskunft | Transparenz-, Informations- und Dokumentationspflichten im KI-Lifecycle | Datenschutzhinweise, Modellbeschreibung, Nutzerinformationen |
| Art. 22 automatisierte Einzelentscheidungen | Controls zu menschlicher Aufsicht, Eingriffsmöglichkeiten und Monitoring, insbesondere Bezug zu Annex A.9 | Entscheidungslogik, Eskalationsweg, Override-Prozess |
| Art. 28 Auftragsverarbeitung | Lieferantensteuerung, externe Parteien, vertragliche Anforderungen | AVV, Leistungsbeschreibung, TOM, Subunternehmerliste |
| Art. 30 Verzeichnis von Verarbeitungstätigkeiten | Dokumentations- und Nachweispflichten des AIMS | Verarbeitungsverzeichnis mit KI-spezifischen Feldern |
| Art. 32 Sicherheit der Verarbeitung | technische und organisatorische Kontrollen, Zugriff, Logging, Incident-Management | TOM, Sicherheitsmaßnahmen, Incident-Playbooks |
| Art. 35 DSFA | Clause 8.4 AI Impact Assessment | Kombiniertes DPIA/AIIA-Dokument |
Die inhaltliche Schnittmenge ist groß, aber nicht deckungsgleich. Die DSGVO fokussiert die Rechte und Freiheiten natürlicher Personen. ISO 42001 betrachtet zusätzlich Genauigkeit, Robustheit, Nachvollziehbarkeit, Fairness, menschliche Aufsicht und organisationale Reife. Ein gemeinsamer Dokumentationsansatz funktioniert daher nur dann, wenn beide Perspektiven sichtbar bleiben und nicht zu einem allgemein formulierten Risikodokument verwässern.
Besonders effizient ist ein einheitliches Evidence-Modell. Das bedeutet: dieselbe Systembeschreibung, dieselbe Datenflussdarstellung, dieselbe Anbieterbewertung und dieselben Freigabeschritte werden einmal erstellt und anschließend für mehrere Zwecke verwendet. Ein Datenschutzbeauftragter braucht dann keine isolierte Beschreibung eines KI-Systems mehr, wenn das AIMS bereits nachvollziehbar dokumentiert, welche Datenquellen, Modellgrenzen, Betriebsrollen und Kontrollmechanismen existieren. Ergänzend lohnt sich ein Blick in den Beitrag Was ist ISO 42001? und in das Glossar zu Daten-Governance.
DSFA und AI Impact Assessment
DSFA und AI Impact Assessment verfolgen unterschiedliche Schwerpunkte, können aber in vielen Fällen gemeinsam durchgeführt werden. Die Datenschutz-Folgenabschätzung nach Art. 35 DSGVO ist verpflichtend, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Das AI Impact Assessment nach ISO 42001 Clause 8.4 ist breiter angelegt und erfasst zusätzlich gesellschaftliche, ethische, betriebliche und sicherheitsbezogene Auswirkungen eines KI-Systems.
Der wichtigste Unterschied liegt im Trigger. Eine DSFA wird nicht wegen jeder KI-Nutzung fällig, sondern wegen eines datenschutzrechtlich hohen Risikos. Ein AI Impact Assessment ist dagegen auch dann sinnvoll, wenn ein System keine besonders sensiblen Personendaten verarbeitet, aber etwa Bias-Risiken, Intransparenz, Fehlsteuerung oder organisatorische Kontrolllücken erzeugen kann. In der Praxis überschneiden sich beide Assessments häufig, wenn KI über Personen entscheidet, Profile bildet oder sensible Geschäftsprozesse unterstützt.
Ein gemeinsames Assessment ist vor allem dann praktikabel, wenn es beide Mindestanforderungen ausdrücklich abbildet. Dazu gehören für die DSFA die Beschreibung der Verarbeitung, die Prüfung von Notwendigkeit und Verhältnismäßigkeit, die Bewertung der Risiken für Betroffene und die vorgesehenen Abhilfemaßnahmen. Für ISO 42001 kommen die Betrachtung von AI-spezifischen Auswirkungen, Governance-Rollen, Monitoring, menschlicher Aufsicht, Bias-Risiken und Lifecycle-Kontrollen hinzu. Das Research empfiehlt deshalb eine kombinierte Struktur, die beide Nachweislogiken in einem Dokument vereint.
Inhaltlich sollte ein gemeinsames Dokument mindestens neun Bausteine enthalten: Systemscope, Datenkategorien, Zweck und Rechtsgrundlage, Alternativenprüfung, Risikobewertung, Art.-22-Prüfung, technische und organisatorische Maßnahmen, Monitoring und Freigaben. Dadurch lassen sich Doppelarbeiten vermeiden, ohne dass Datenschutzfragen im KI-Jargon untergehen. Ein solches Dokument ersetzt allerdings nicht die Pflicht, den Datenschutzbeauftragten einzubinden, wenn Art. 35 DSGVO greift.
Praktisch bedeutet das: Nicht jede DSFA ist zugleich ein brauchbares AI Impact Assessment, und nicht jedes AI Impact Assessment erfüllt automatisch Art. 35 DSGVO. Eine rein ethische Folgenbetrachtung ohne Angaben zur Rechtsgrundlage, Betroffenenkategorie oder Speicherfrist reicht datenschutzrechtlich nicht aus. Umgekehrt genügt eine klassische DSFA oft nicht, wenn keinerlei Aussage zu Modellverhalten, Bias, menschlicher Aufsicht oder Überwachungsmaßnahmen getroffen wird. Unternehmen sollten ihre Vorlagen daher zusammenführen, aber die beiden Perspektiven bewusst separat ausweisen.
Trainingsdaten und Art. 6 DSGVO
Trainingsdaten brauchen eine tragfähige Rechtsgrundlage nach Art. 6 DSGVO, sobald personenbezogene Daten in Training, Validierung oder Test eines KI-Systems einfließen. Genau hier entstehen in Unternehmen die meisten Missverständnisse. Nicht jede KI-Nutzung braucht eine Einwilligung, aber jede Verarbeitung braucht eine Rechtsgrundlage. Ob Vertragserfüllung, rechtliche Verpflichtung, berechtigtes Interesse oder Einwilligung einschlägig ist, hängt vom konkreten Zweck, der Datenkategorie und dem Kontext ab.
Für viele interne Unternehmensszenarien wird die Einwilligung überschätzt. Einwilligungen sind nur wirksam, wenn sie freiwillig, informiert und widerrufbar sind. Gerade im Beschäftigungskontext oder bei großen Datenbeständen ist das oft keine stabile Lösung. Häufiger kommt ein berechtigtes Interesse nach Art. 6 Abs. 1 lit. f DSGVO in Betracht, etwa wenn ein Unternehmen ein System zur Verbesserung interner Prozesse trainieren oder feinjustieren will. Dann ist jedoch eine dokumentierte Interessenabwägung erforderlich, die den Nutzen, die Erforderlichkeit und die Auswirkungen auf Betroffene nachvollziehbar darstellt.
Anonymisierung und Pseudonymisierung müssen sauber getrennt werden. Wirksam anonymisierte Daten fallen nicht mehr unter die DSGVO, was für viele Trainingsszenarien die risikoärmste Lösung ist. Pseudonymisierte Daten bleiben dagegen personenbezogene Daten und erfordern weiterhin eine Rechtsgrundlage sowie Schutzmaßnahmen. Unternehmen sollten deshalb in ihrer Datenpipeline genau festhalten, ob Datensätze lediglich maskiert, aggregiert, gehasht oder tatsächlich anonymisiert wurden. Gerade bei KI-Modellen besteht sonst die Gefahr von Re-Identifikation oder Modellmemorierung.
ISO 42001 ergänzt diese rechtliche Prüfung um Governance-Anforderungen für Datenherkunft, Datenqualität, Aufbewahrung und Nachvollziehbarkeit. Für Trainingsdaten sollten Sie daher mindestens dokumentieren, aus welcher Quelle Daten stammen, auf welcher Grundlage sie erhoben wurden, wer sie verändert hat, welche Vorverarbeitung stattgefunden hat und welche Qualitätskriterien gelten. Das entspricht dem Kern der Data-Governance-Controls in Annex A und schafft zugleich die operative Basis für Transparenz, Löschung und Auditierbarkeit.
Besonders kritisch ist der Zweckwechsel. Daten, die ursprünglich für Kundenservice, Vertragsabwicklung oder Recruiting erhoben wurden, dürfen nicht automatisch für KI-Training weiterverwendet werden. Unternehmen müssen prüfen, ob der neue Zweck mit dem ursprünglichen Erhebungszweck vereinbar ist oder eine neue Rechtsgrundlage benötigt. Ein sauber gepflegtes Verarbeitungsverzeichnis und ein erweitertes Dateninventar sind deshalb keine Formalie, sondern die Voraussetzung dafür, dass Trainingsdaten nicht rechtswidrig in Modellprozesse gelangen.
Für generative KI und externe Foundation-Model-Anbieter stellt sich zusätzlich die Frage, ob eingegebene Inhalte in ein Anbietertraining zurückfließen. Wenn dieser Punkt vertraglich oder technisch nicht ausgeschlossen ist, verändert sich die datenschutzrechtliche Bewertung erheblich. Dann geht es nicht mehr nur um eine unterstützende Verarbeitung, sondern möglicherweise um eine weitergehende Nutzung Ihrer Eingaben für fremde Trainingszwecke. Diese Konstellation sollte immer gemeinsam von Datenschutz, Einkauf und KI-Verantwortlichen bewertet werden.
Art. 22 DSGVO — Automatisierte Einzelentscheidungen
Art. 22 DSGVO greift, wenn eine Entscheidung ausschließlich automatisiert erfolgt und für die betroffene Person rechtliche Wirkung entfaltet oder sie in ähnlich erheblicher Weise beeinträchtigt. Typische Beispiele sind die automatisierte Ablehnung einer Bewerbung, Kreditentscheidungen, Versicherungsbewertungen oder bestimmte Scoring-Verfahren. Viele Unternehmen unterschätzen diese Schwelle, weil sie annehmen, eine nachgelagerte Stichprobe durch Menschen reiche bereits aus. Das ist regelmäßig nur dann tragfähig, wenn die menschliche Prüfung tatsächlich substantiell und eingriffsrelevant ist.
Für KI-Systeme ist Art. 22 deshalb ein zentrales Prüffeld. Wenn ein Modell nur Empfehlungen abgibt und ein verantwortlicher Mitarbeiter die Entscheidung erkennbar eigenständig trifft, kann Art. 22 außerhalb des Anwendungsbereichs bleiben. Wenn die menschliche Kontrolle aber nur formal ist, etwa weil Scores praktisch immer übernommen werden, spricht viel für eine automatisierte Einzelentscheidung. Unternehmen sollten diesen Punkt nicht pauschal, sondern pro Use Case dokumentieren.
ISO 42001 unterstützt hier vor allem über Anforderungen an menschliche Aufsicht, Transparenz, Verantwortlichkeiten und Monitoring. Im Ticket ist der Bezug zu ISO 42001 Annex A.9 besonders wichtig, weil dort Kontrolllogiken für Betrieb, Überwachung und Eingriffsmöglichkeiten anschlussfähig werden. Datenschutzrechtlich reicht es nicht, einen Menschen im Organigramm zu benennen. Er muss die Entscheidung verstehen, hinterfragen und korrigieren können. Das setzt nicht zwingend vollständige Quellcode-Erklärbarkeit voraus, wohl aber sinnvolle Informationen über Kriterien, Grenzen, Unsicherheiten und Eskalationswege.
Die Ausnahmen in Art. 22 Abs. 2 DSGVO bleiben eng. Eine automatisierte Entscheidung kann zulässig sein, wenn sie für einen Vertrag erforderlich ist, auf Unions- oder Mitgliedstaatenrecht beruht oder auf einer ausdrücklichen Einwilligung basiert. Selbst dann müssen jedoch geeignete Maßnahmen zum Schutz der Rechte und Freiheiten der betroffenen Person bestehen. Dazu gehören mindestens das Recht auf menschliches Eingreifen, die Möglichkeit zur Darlegung des eigenen Standpunkts und die Möglichkeit, die Entscheidung anzufechten.
Für die Praxis empfiehlt sich ein vierstufiges Prüfschema. Erstens: Hat die Entscheidung rechtliche oder ähnlich erhebliche Wirkung? Zweitens: Ist sie ausschließlich automatisiert? Drittens: Greift eine Ausnahme nach Art. 22 Abs. 2? Viertens: Welche Schutzmaßnahmen und Nachweise sind erforderlich? Diese Prüfung sollte in DSFA und AI Impact Assessment integriert werden. Gerade in HR-, Finanz- und Versicherungsprozessen ist sie kein Spezialthema, sondern ein Kernpunkt der Governance.
Auftragsverarbeitung bei Cloud-KI
Bei Cloud-KI ist Auftragsverarbeitung fast immer ein eigener Risikoblock, weil technische Leistungserbringung, Datenverarbeitung, Unterauftragsverhältnisse und Drittlandbezüge zusammenkommen. Unternehmen müssen klären, ob der Anbieter Auftragsverarbeiter, eigener Verantwortlicher oder in Teilen beides ist. Für typische Enterprise-Setups mit ChatGPT, Azure OpenAI, AWS-basierten KI-Diensten oder spezialisierten SaaS-Anwendungen ist regelmäßig zumindest ein Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO erforderlich.
Ein AVV allein genügt allerdings nicht. Unternehmen sollten zusätzlich prüfen, welche Datenkategorien verarbeitet werden, ob Prompts gespeichert werden, wo Daten gehostet werden, welche technischen und organisatorischen Maßnahmen gelten und welche Subunternehmer beteiligt sind. Gerade bei generativer KI ist die Liste der Unterauftragsverarbeiter nicht nur ein Einkaufsdetail, sondern datenschutzrechtlich und auditseitig relevant. Wer personenbezogene Daten in Cloud-KI nutzt, muss die Lieferkette nachvollziehen können.
Drittlandtransfers bleiben ein kritischer Punkt. Werden Daten in die USA oder andere Drittländer übertragen, müssen Unternehmen die Transfergrundlage und das Restrisiko bewerten. Standardvertragsklauseln, zusätzliche Verschlüsselung, regionale Datenhaltung und klare Deaktivierung von Trainingsnutzung sind typische Bausteine. In manchen Fällen ist eine europäische oder rein interne Betriebsform die pragmatischere Lösung, wenn sensible Daten oder besonders strenge Branchenanforderungen betroffen sind.
ISO 42001 verschärft hier nicht die DSGVO, aber es strukturiert die Lieferantensteuerung. Ein AIMS sollte definieren, welche KI-Dienste freigegeben sind, welche Vertragsunterlagen vorliegen müssen, wie Anbieter überwacht werden und wann eine Re-Evaluierung erforderlich ist. Damit wird aus dem klassischen Datenschutzvertrag ein integriertes Lieferantenkontrollmodell. Für viele Organisationen ist das der entscheidende Schritt von punktueller Vertragsprüfung zu belastbarer KI-Governance.
Praktisch sollten Sie bei Cloud-KI immer mindestens diese Fragen beantworten: Gibt es einen AVV? Gibt es Subunternehmerlisten? Gibt es Drittlandtransfers? Ist Anbietertraining deaktiviert? Welche Löschfristen gelten? Welche Logs entstehen? Welche Personen dürfen welche Daten eingeben? Wer diese Fragen dokumentiert, verbindet Datenschutz, Beschaffung und AIMS sinnvoll in einem Prozess.
Gemeinsame Dokumentation und Prozesse
Gemeinsame Dokumentation ist der schnellste Hebel, um ISO 42001 und DSGVO effizient zusammenzuführen. Statt ein klassisches Verzeichnis von Verarbeitungstätigkeiten isoliert neben einem KI-Register zu pflegen, sollten Unternehmen ihr Verarbeitungsverzeichnis um KI-spezifische Felder ergänzen. Dazu gehören Systemname, Anbieter, Version, Anwendungszweck, Datenquellen, Modelltyp, Grad der Automatisierung, menschliche Aufsicht, Risikoklasse, Freigabestatus und Verweise auf Impact Assessments.
Genauso sinnvoll ist die Zusammenführung von TOM und Controls. Technische und organisatorische Maßnahmen nach Art. 32 DSGVO überschneiden sich mit vielen Kontrollanforderungen aus ISO 42001, etwa bei Zugriffsschutz, Logging, Rollenrechten, Incident-Management, Qualitätssicherung und Überwachung. Unternehmen müssen diese Maßnahmen nicht doppelt formulieren. Besser ist ein gemeinsames Kontrollverzeichnis mit Kennzeichnung, welcher Nachweis sowohl für Datenschutz als auch für KI-Governance verwendet wird.
Ein integrierter Prozess beginnt bereits bei der Use-Case-Freigabe. Fachbereich, Datenschutz, IT-Sicherheit und KI-Verantwortliche sollten dieselbe Einreichung sehen und dieselben Mindestangaben verlangen. Dazu zählen Zweck, Datenkategorien, Anbietermodell, Entscheidungsauswirkungen, Nutzerkreis, Risiken und geplante Schutzmaßnahmen. Aus dieser Eingangserfassung können anschließend AVV-Prüfung, Art.-22-Prüfung, DSFA-Screening und AI-Impact-Bewertung abgeleitet werden.
Ebenso wichtig ist die gemeinsame Änderungssteuerung. KI-Systeme verändern sich schneller als klassische Software, etwa durch neue Modelle, geänderte Trainingsstände, zusätzliche Funktionen oder geänderte Prompt-Flows. Wenn das Datenschutzteam nur die ursprüngliche Einführung dokumentiert, verliert die Dokumentation schnell ihre Aussagekraft. Ein AIMS sollte daher definieren, welche Änderungen erneut bewertet werden müssen und wann Datenschutzdokumentation, TOM oder Assessments anzupassen sind.
Aus Audit-Sicht zahlt sich dieser Ansatz mehrfach aus. Das Management erhält eine konsistente Sicht auf Risiken und Maßnahmen. Der Datenschutzbeauftragte muss keine zweite Schatten-Dokumentation führen. Interne Audits prüfen weniger Form, sondern eher Wirksamkeit. Und Fachbereiche verstehen schneller, warum KI-Projekte nicht mit einem Toolkauf abgeschlossen sind, sondern laufende Governance benötigen.
Praktische Umsetzung — DSB und KI-Beauftragter
Datenschutzbeauftragter und KI-Beauftragter sollten keine konkurrierenden Rollen sein, sondern zwei Blickwinkel auf dasselbe Steuerungssystem. Der Datenschutzbeauftragte bleibt für die datenschutzrechtliche Bewertung, Beratung und Überwachung zuständig. Ein KI-Beauftragter oder AI Governance Lead koordiniert dagegen Scope, Controls, Freigabeprozesse, Lieferantensteuerung, Schulung und Monitoring im KI-Management-System. Beide Rollen brauchen klare Berichtswege und definierte Schnittstellen.
In der Praxis scheitert Zusammenarbeit oft nicht an fehlender Fachkenntnis, sondern an unklaren Zuständigkeiten. Wenn der DSB erst kurz vor Go-live eingebunden wird, kann er nur noch Symptome dokumentieren. Wenn der KI-Verantwortliche keinen Zugriff auf Vertragsprüfung, Dateninventar oder Incident-Reports hat, bleibt Governance oberflächlich. Deshalb sollte die Zusammenarbeit organisatorisch festgelegt werden: gemeinsamer Review neuer Use Cases, abgestimmte Mindestdokumentation, definierte Eskalationskriterien und regelmäßige Berichte an Geschäftsführung oder Compliance-Gremium.
Ein wirksames Rollenmodell trennt Verantwortung und Kontrollfunktion sauber. Der DSB ist nicht der operative Eigentümer jedes KI-Systems und sollte diese Verantwortung auch nicht übernehmen. Der Fachbereich bleibt für den jeweiligen Einsatz verantwortlich, der KI-Beauftragte steuert das Rahmenwerk, und der DSB bewertet die datenschutzrechtliche Seite unabhängig beratend und überwachend. Dieses Modell verhindert, dass Datenschutz zum alleinigen Ersatz für fehlende KI-Governance wird.
Sinnvoll ist ein gemeinsames Reporting entlang weniger Kennzahlen. Dazu gehören Anzahl freigegebener KI-Use-Cases, offene Assessments, Cloud-Anbieter mit Drittlandbezug, Incidents, ausstehende Schulungen, Systeme mit Art.-22-Relevanz und überfällige Re-Assessments. Solche Kennzahlen schaffen ein einheitliches Lagebild für die Leitung und verankern das Thema aus dem Projektstatus heraus in regulärer Governance.
Unternehmen, die diesen Aufbau jetzt sauber beginnen, sparen später erheblichen Aufwand. Wenn Sie ISO 42001 nicht nur als Dokumentenprojekt, sondern als Steuerungsrahmen für Datenschutz, KI-Risiken und operative Freigaben nutzen wollen, ist eine spezialisierte ISO-42001-Schulung der sinnvollste nächste Schritt.
FAQ
Brauche ich neben DSGVO-Compliance auch ISO 42001?
Ja, wenn Sie KI systematisch einsetzen und Governance nachweisbar strukturieren wollen, ist ISO 42001 ein sinnvoller Ergänzungsrahmen. DSGVO-Compliance bleibt bei personenbezogenen Daten immer Pflicht, aber sie beantwortet nicht alle Fragen zu Rollen, Kontrollen, Monitoring und AI-spezifischer Risikosteuerung.
Kann die DSFA das AI Impact Assessment ersetzen?
Nein, nicht vollständig. Eine DSFA deckt die datenschutzrechtliche Perspektive ab. Ein AI Impact Assessment betrachtet zusätzlich Themen wie Bias, Transparenz, Robustheit, menschliche Aufsicht und organisationale Auswirkungen. In vielen Fällen können beide Assessments aber in einem kombinierten Dokument zusammengeführt werden.
Welche DSGVO-Anforderungen deckt ISO 42001 ab?
ISO 42001 deckt DSGVO-Anforderungen nicht rechtlich ab, unterstützt aber deren Umsetzung operativ. Besonders hilfreich ist der Standard bei Daten-Governance, Dokumentation, Aufbewahrung, Rollenverteilung, Incident-Management, Lieferantensteuerung und menschlicher Aufsicht. Die rechtliche Prüfung nach DSGVO bleibt dennoch erforderlich.
Wie dokumentiert man KI-Trainingsdaten DSGVO-konform?
Sie sollten Herkunft, Zweck, Rechtsgrundlage, Kategorien personenbezogener Daten, Vorverarbeitung, Anonymisierung oder Pseudonymisierung, Aufbewahrungsfristen, Löschlogik und Qualitätskriterien dokumentieren. Zusätzlich ist wichtig festzuhalten, ob Daten intern erhoben, extern bezogen oder an Anbieter weitergegeben werden.
Was ist der Unterschied zwischen DSB und KI-Beauftragtem?
Der DSB überwacht und berät zur DSGVO. Der KI-Beauftragte oder AI Governance Lead steuert das KI-Management-System, koordiniert Kontrollen, Assessments, Anbieterprüfung und interne Freigaben. Beide Rollen sollten eng zusammenarbeiten, aber nicht miteinander verwechselt werden.
Welche Rolle spielt Art. 22 DSGVO bei KI-Systemen?
Art. 22 DSGVO ist relevant, wenn KI-Systeme ausschließlich automatisierte Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung treffen. Dann brauchen Unternehmen Ausnahmen nach Art. 22 Abs. 2 DSGVO und zusätzliche Schutzmaßnahmen wie menschliches Eingreifen, Anfechtungsmöglichkeit und transparente Information.
Fazit
ISO 42001 und DSGVO lassen sich am wirksamsten gemeinsam umsetzen: Die DSGVO liefert die rechtlichen Grenzen, ISO 42001 die steuerbare Governance-Struktur. Unternehmen sollten deshalb Assessments, Verarbeitungsverzeichnis, Kontrollen, Lieferantenprüfung und Rollenmodell integriert aufbauen, statt getrennte Silos zu pflegen.
Wenn Sie die Anforderungen für Ihr Unternehmen strukturiert in Prozesse, Verantwortlichkeiten und Nachweise übersetzen wollen, vertiefen Sie das Thema im ISO-42001-Leitfaden, im Beitrag Was ist ISO 42001? und mit einer praxisnahen ISO-42001-Schulung.