B8. Regulatorik und Compliance
Regulatorik ist für KI kein Randthema, sondern eine Gestaltungsgröße der Strategie. Der EU AI Act (Verordnung 2024/1689) ist das weltweit erste umfassende KI-Gesetz und gilt mit extraterritorialer Wirkung: Betroffen ist jedes Unternehmen, das KI-Systeme entwickelt, in Verkehr bringt oder einsetzt, sofern Menschen in der EU berührt werden, unabhängig vom Unternehmenssitz.
Was dieses Kapitel liefert: die Einordnung der Pflichten, einen Entscheidungsbaum zur Risikoeinstufung, die Hochrisiko-Pflichten im Detail und die Verzahnung mit DSGVO, Sektoraufsicht und deutschem Arbeitsrecht. Es ersetzt keine Rechtsberatung; verbindliche Bewertungen erfolgen mit Recht und Compliance.
Stand: Juli 2026. Die Darstellung berücksichtigt den Digital Omnibus on AI: Zustimmung des Europäischen Parlaments am 16. Juni 2026, finale Zustimmung des Rats am 29. Juni 2026. Die Veröffentlichung im EU-Amtsblatt stand zum Redaktionszeitpunkt unmittelbar bevor; die Änderungen treten am dritten Tag nach der Veröffentlichung in Kraft. Bis dahin gelten die ursprünglichen Fristen rechtlich fort. Quellen: Europäische Kommission (digital-strategy.ec.europa.eu), Rat der EU (consilium.europa.eu), EU-Amtsblatt. Details zur Aktualisierung siehe Kapitel E2.
Was ist der Digital Omnibus? Der EU AI Act ist das Gesetz selbst; der Digital Omnibus on AI ist ein 2026 beschlossenes Änderungspaket, das den AI Act an einzelnen Stellen nachjustiert, ohne seine Grundarchitektur zu verändern. Er verschiebt vor allem die Anwendungsfristen der Hochrisiko-Pflichten, ergänzt ein Verbot (Art. 5) und formuliert die KI-Kompetenzpflicht weicher. Wo dieses Kapitel „per Omnibus" schreibt, ist eine dieser Änderungen gemeint.
Aufbau des Kapitels: Das Kapitel hat drei Teile. Teil 1 gilt für alle Anwendungsfälle: Risikoklassen, Entscheidungsbaum zur Einstufung, die Rollenfrage Anbieter oder Betreiber, die KI-Kompetenzpflicht (Art. 4) sowie Fristen und Sanktionen. Teil 2 betrifft nur bestimmte Konstellationen: die Pflichten der Risikoklasse Hochrisiko und die Regeln für GPAI-Modelle. Teil 3 behandelt Recht, das parallel zum AI Act gilt: DSGVO, Sektoraufsicht sowie Mitbestimmung und Haftung. Dazu zwei Checklisten mit unterschiedlichen Aufgaben: Die Hochrisiko-Checkliste wird je System geführt und steht in Teil 2; die operative Compliance-Checkliste am Kapitelende prüft die unternehmensweite Organisation.
Teil 1: Grundlagen für alle Anwendungsfälle
Dieser Teil gilt unabhängig von Risikoklasse und Rolle für jeden KI-Anwendungsfall: Er klärt die Einstufung (Risikoklasse und rechtliche Rolle), die Pflicht zur KI-Kompetenz sowie Fristen und Sanktionen.
Der risikobasierte Ansatz: vier Stufen
Der AI Act reguliert nicht die Technologie, sondern den Einsatzzweck. Je höher das Risiko für Gesundheit, Sicherheit und Grundrechte, desto strenger die Pflichten.
| Stufe | Bedeutung | Beispiele | Pflichten |
|---|---|---|---|
| Unannehmbares Risiko | Verboten (Art. 5) | Social Scoring, manipulative Techniken, bestimmte biometrische Praktiken; neu per Omnibus: Erzeugung nicht einvernehmlicher intimer Inhalte und CSAM (Übergangsfrist bis 2. Dez 2026) | Einsatz untersagt |
| Hochrisiko | Streng reguliert | Annex III (eigenständig): Personalauswahl, Kreditwürdigkeit, Bildung, Strafverfolgung, Migration; Versicherung: Risikobewertung und Preisbildung in der Lebens- und Krankenversicherung. Annex I (eingebettet): Medizinprodukte, Maschinen, Fahrzeuge | Umfassende Anbieter- und Betreiberpflichten, Konformitätsbewertung (Details in Teil 2) |
| Begrenztes Risiko | Transparenzpflicht (Art. 50) | Chatbots, generierte Texte, Bilder, Audio | Offenlegung der KI-Interaktion, Kennzeichnung KI-erzeugter Inhalte |
| Minimales Risiko | Frei | Spamfilter, Empfehlungen, die meisten internen Werkzeuge | Keine besonderen Pflichten; gute Praxis empfohlen |
Für die Versicherungswirtschaft besonders relevant: Risikobewertung und Preisbildung bei Lebens- und Krankenversicherungen für natürliche Personen zählen ausdrücklich zu den Hochrisiko-Anwendungen nach Annex III. Wer hier KI einsetzt, fällt in das anspruchsvollste Pflichtenregime.
Entscheidungsbaum: In welche Risikoklasse fällt mein Anwendungsfall?
Jeder Anwendungsfall wird der Reihe nach geprüft. Die Prüfung beginnt beim schärfsten Fall (Verbot) und arbeitet sich zur mildesten Stufe vor; sobald eine Stufe zutrifft, ist die Einstufung gefunden. Das Ablaufdiagramm zeigt alle Wege und Abzweigungen auf einen Blick; die Kriterien zu den einzelnen Fragen stehen in der Legende darunter.
Die fünf Prüffragen im Einzelnen, mit derselben Nummerierung wie im Diagramm:
- Verbotene Praxis? (Art. 5) Fällt der Einsatz unter Art. 5, z. B. Social Scoring, manipulative oder bestimmte biometrische Praktiken? → Ja: unannehmbares Risiko, nicht zulässig. Stopp. Nein: weiter mit Frage 2.
- Annex-III-Bereich? Betrifft der Einsatz einen der Hochrisiko-Bereiche nach Annex III (Personal, Kreditwürdigkeit, Versicherungs-Risikobewertung und -Preisbildung, Bildung, Strafverfolgung, Migration, kritische Infrastruktur)? → Ja: weiter mit Frage 3 (Ausnahmeprüfung). Nein: weiter mit Frage 4.
- Ausnahme nach Art. 6 Abs. 3? Auch ein Annex-III-System ist nicht hochriskant, wenn es kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte darstellt, weil es nur eine der folgenden Aufgaben erfüllt: eine eng begrenzte Verfahrensaufgabe (z. B. Dokumente strukturieren), die Verbesserung des Ergebnisses einer bereits abgeschlossenen menschlichen Tätigkeit (z. B. Textglättung), die Erkennung von Mustern oder Abweichungen ohne eigene Bewertungshoheit (der Mensch bewertet) oder eine rein vorbereitende Aufgabe. Die Ausnahme gilt nie bei Profiling natürlicher Personen. Die Einstufung ist zu dokumentieren und muss einer Prüfung durch die Aufsicht standhalten. → Ausnahme greift: kein Hochrisiko, weiter mit Frage 5. Greift nicht: Hochrisiko.
- In ein reguliertes Produkt eingebettet? (Annex I) Ist die KI Sicherheitskomponente eines bereits regulierten Produkts (Medizinprodukt, Maschine, Fahrzeug)? → Ja: Hochrisiko. Nein: weiter mit Frage 5.
- Transparenzfall? (Art. 50) Interagiert die KI direkt mit Menschen oder erzeugt sie Inhalte? → Ja: begrenztes Risiko, Offenlegungs- und Kennzeichnungspflichten. Nein: minimales Risiko (keine besonderen Pflichten; gute Praxis wie Dokumentation und Tests trotzdem empfohlen).
Das ist eine vollständige Einstufung: Jeder Anwendungsfall endet in genau einer der vier Risikoklassen. Zwei Pflichten gelten jedoch zusätzlich und unabhängig von der Risikoklasse: Werden personenbezogene Daten verarbeitet, gilt die DSGVO parallel (Teil 3); wer ein GPAI-Modell selbst bereitstellt, erfüllt zusätzlich die GPAI-Pflichten (Teil 2).
Der Entscheidungsbaum am Beispiel
Die folgenden Anwendungsfälle zeigen den Weg durch das Diagramm. Die mittlere Spalte nennt die Prüffragen in der Reihenfolge, in der sie durchlaufen werden; übersprungene Fragen tauchen nicht auf, weil eine Abzweigung sie umgeht. So lässt sich jedes Beispiel Schritt für Schritt im Diagramm nachverfolgen.
| Anwendungsfall | Weg durch das Diagramm | Einstufung |
|---|---|---|
| Interner IT-Helpdesk-Chatbot | 1 nein → 2 nein → 4 nein → 5 ja | Begrenztes Risiko: Nutzer müssen erkennen können, dass sie mit KI interagieren |
| KI-gestützte Vorauswahl und Reihung von Bewerbungen | 1 nein → 2 ja (Beschäftigung) → 3 greift nicht (Reihung ist Profiling) | Hochrisiko: voller Pflichtenkatalog; zusätzlich DSGVO (Art. 22) und Mitbestimmung (Teil 3) |
| Zusammenfassung von Schadenakten als Arbeitsvorbereitung | 1 nein → 2 ja (Versicherung berührt) → 3 greift (rein vorbereitend, kein Profiling) → 5 nein | Art.-6(3)-Ausnahme: kein Hochrisiko, Einstufung dokumentieren; DSGVO parallel beachten |
| KI-Preisbildung in der Krankenversicherung | 1 nein → 2 ja → 3 greift nicht (Preisbildung ist die Bewertung selbst und Profiling) | Hochrisiko, keine Ausnahme möglich |
Anbieter oder Betreiber? Die entscheidende Rollenfrage
Nach der Risikoklasse ist die Rolle die zweite Weichenstellung. „Rolle" meint hier etwas anderes als in Kapitel B7: Dort geht es um organisatorische Rollen (wer im Unternehmen welche Aufgabe hat), hier um die rechtliche Rolle nach AI Act, die bestimmt, welcher Pflichtenkatalog überhaupt gilt. Beide Ebenen sind unabhängig: Dieselbe Person kann organisatorisch Product Owner sein, während ihr Unternehmen rechtlich zum Anbieter wird. Der AI Act verteilt seine Pflichten danach, ob ein Unternehmen ein KI-System herstellt und in Verkehr bringt (Anbieter) oder es unter eigener Verantwortung einsetzt (Betreiber). Dieselbe Hochrisiko-Einstufung bedeutet für den Anbieter Konformitätsbewertung und CE-Kennzeichnung, für den Betreiber vor allem Aufsichts-, Protokoll- und Informationspflichten. Die meisten Unternehmen sind Betreiber, haben aber eigene Pflichten und können unbemerkt zum Anbieter werden.
| Rolle | Definition | Kernpflichten (Hochrisiko) |
|---|---|---|
| Anbieter (Provider) | Entwickelt ein KI-System oder bringt es unter eigenem Namen in Verkehr | Risikomanagement, Datennachweise, technische Dokumentation, Konformitätsbewertung, Registrierung (Details in Teil 2) |
| Betreiber (Deployer) | Setzt ein KI-System unter eigener Verantwortung ein | Einsatz gemäß Anweisung, menschliche Aufsicht sicherstellen, Protokolle führen, Betroffene informieren, Monitoring (Details in Teil 2) |
Achtung Rollenwechsel (Art. 25): Wer ein zugekauftes System unter eigenem Namen vertreibt, es wesentlich verändert oder einen Zweck daraus macht, der es zum Hochrisiko-System macht, wird selbst zum Anbieter mit dem vollen Pflichtenkatalog. Praxisrelevant: Ein per Feinjustierung und eigenem Prompt-Rahmen stark angepasstes System für einen neuen, hochriskanten Zweck kann diesen Wechsel auslösen. Vor jeder wesentlichen Anpassung die Rollenfrage neu bewerten.
KI-Kompetenz (Art. 4)
Neben den systembezogenen Pflichten enthält der AI Act eine Querschnittspflicht, die jedes Unternehmen unabhängig von Risikoklasse und Rolle trifft, und sie gilt bereits. Deshalb steht sie hier in Teil 1: Seit Februar 2025 müssen Unternehmen dafür sorgen, dass Personen, die KI-Systeme betreiben oder nutzen, über ausreichende KI-Kompetenz verfügen. Der Digital Omnibus formuliert die Pflicht weicher (Entwicklung von KI-Kompetenz unterstützen statt sicherstellen), an der praktischen Konsequenz ändert das wenig: Ohne nachweisbare Schulung sind weder die Betreiberpflichten (befähigte Aufsichtspersonen, Art. 26) noch wirksame menschliche Aufsicht (Art. 14) erfüllbar. Praktische Umsetzung: rollenspezifische Schulungspfade und Nachweise, siehe Kapitel B11.
Aktuelle Anwendungstermine (mit Digital Omnibus)
Die folgende Übersicht zeigt, welche Pflichten ab wann gelten. Sie ist die Grundlage der eigenen Umsetzungsplanung: Jede Frist wird mit den Anwendungsfällen aus dem eigenen KI-Register abgeglichen, um zu erkennen, welche Pflicht wann welches System betrifft.
| Datum | Was gilt | Status |
|---|---|---|
| 1. Aug 2024 | Inkrafttreten der Verordnung | In Kraft |
| 2. Feb 2025 | Verbotene Praktiken (Art. 5) und KI-Kompetenzpflicht (Art. 4) | In Anwendung |
| 2. Aug 2025 | Pflichten für GPAI-Modelle, Governance-Regeln, nationale Behörden, Sanktionsrahmen | In Anwendung |
| 2. Aug 2026 | Transparenzpflichten (Art. 50): Offenlegung der KI-Interaktion, Kennzeichnung KI-erzeugter Inhalte | Bleibt bestehen |
| 2. Dez 2026 | Schonfrist für Wasserzeichen bei Altsystemen (vor Aug 2026 in Verkehr); Übergangsende für neues Art.-5-Verbot | Per Omnibus |
| 2. Dez 2027 | Hochrisiko-Pflichten für eigenständige Annex-III-Systeme | Verschoben (Omnibus, beschlossen Juni 2026), zuvor 2. Aug 2026 |
| 2. Aug 2028 | Hochrisiko-Pflichten für in regulierte Produkte eingebettete Annex-I-Systeme | Verschoben (Omnibus) |
Wichtig: Parlament und Rat haben den Omnibus im Juni 2026 beschlossen; rechtskräftig werden die neuen Fristen mit der Veröffentlichung im Amtsblatt (erwartet Juli 2026). Die Transparenzpflichten zum 2. August 2026 sind von der Verschiebung nicht betroffen. Verantwortliche sollten die gewonnene Zeit als Umsetzungspuffer nutzen, nicht als Grund zum Stillstand: Die Pflichten kommen, und Daten-Governance, Dokumentation und Aufsichtskonzepte brauchen Vorlauf.
Sanktionen
Verstöße sind dreistufig gestaffelt und können DSGVO-Bußgelder übersteigen. Es gilt jeweils der höhere Betrag; für KMU und Start-ups gilt jeweils der niedrigere.
| Verstoß | Bußgeld bis |
|---|---|
| Verbotene Praktiken (Art. 5) | 35 Mio. Euro oder 7 % des weltweiten Jahresumsatzes |
| Verstöße gegen sonstige Pflichten (u. a. Hochrisiko-Pflichten, Transparenz, GPAI) | 15 Mio. Euro oder 3 % des weltweiten Jahresumsatzes |
| Falsche oder irreführende Angaben gegenüber Behörden | 7,5 Mio. Euro oder 1 % des weltweiten Jahresumsatzes |
Teil 2: Pflichten für bestimmte Konstellationen
Dieser Teil betrifft nur einen Teil der Anwendungsfälle: die Pflichten, die bei der Einstufung Hochrisiko greifen, und die Regeln für GPAI-Modelle, die zusätzlich gelten, wenn ein Unternehmen ein Basismodell selbst bereitstellt. Wer nach dem Entscheidungsbaum nur Transparenz- oder Minimalfälle im Portfolio hat und keine Modelle selbst bereitstellt, kann diesen Teil überspringen.
Hochrisiko-Pflichten im Detail
Dieser Abschnitt betrifft ausschließlich Anwendungsfälle der Risikoklasse Hochrisiko, also die zweite Stufe der Risikopyramide aus Teil 1. Die folgende Tabelle übersetzt die Pflichten der Art. 9 bis 27 in konkrete Arbeitsschritte und Nachweise. Sie ist die Arbeitsgrundlage für jeden als Hochrisiko eingestuften Anwendungsfall; die Checkliste danach dient der Fortschrittskontrolle. Viele der Nachweise in der rechten Spalte müssen nicht von Hand gepflegt werden: Wer Deployment und Evaluierung über eine standardisierte Pipeline führt, erzeugt Modellkarten, Testberichte und Protokolle automatisiert mit (siehe Kapitel B6).
| Pflicht (Artikel) | Was konkret verlangt wird | Typische Artefakte und Nachweise |
|---|---|---|
| Risikomanagementsystem (Art. 9) | Kontinuierlicher, dokumentierter Prozess über den gesamten Lebenszyklus: Risiken für Gesundheit, Sicherheit und Grundrechte identifizieren, bewerten, durch Design und Maßnahmen mindern, Restrisiken bewerten und kommunizieren; Tests vor Inverkehrbringen | Risiko-Register je System (siehe Kapitel D3), Bewertungs- und Testprotokolle, dokumentierte Maßnahmen |
| Daten und Daten-Governance (Art. 10) | Trainings-, Validierungs- und Testdaten müssen relevant, hinreichend repräsentativ und möglichst fehlerfrei und vollständig für den Zweck sein; Erhebungsverfahren, Datenherkunft und mögliche Verzerrungen sind zu prüfen und zu dokumentieren | Datenkarten, Qualitätsberichte, Verzerrungsanalysen (siehe Kapitel B4 und B10) |
| Technische Dokumentation (Art. 11, Annex IV) | Vor Inverkehrbringen erstellen und aktuell halten: Systembeschreibung und Zweck, Entwicklungsprozess, Architektur, Trainingsdaten, Leistungsmetriken und Grenzen, Risikomanagement, Änderungen über den Lebenszyklus | Systemakte, erweiterte Modellkarte, Architekturdokumentation |
| Aufzeichnungspflichten (Art. 12) | Automatische Protokollierung relevanter Ereignisse über die Lebensdauer, um Risiken und wesentliche Änderungen rückverfolgen zu können | Log-Konzept, Aufbewahrungsregeln, Protokolle (siehe Kapitel B9) |
| Transparenz gegenüber Betreibern (Art. 13) | Verständliche Gebrauchsanweisung: Fähigkeiten, Leistungsgrenzen, bekannte Risiken, erforderliche menschliche Aufsicht, erwartete Lebensdauer, Wartung | Gebrauchsanweisung, Freigabedokumentation |
| Menschliche Aufsicht (Art. 14) | Systeme so gestalten, dass Menschen sie wirksam beaufsichtigen können: Eingriffs- und Abbruchmöglichkeit, Verständnis der Grenzen, Vorkehrungen gegen Automatisierungs-Übervertrauen (Automation Bias) | Aufsichtskonzept je Anwendungsfall (siehe Kapitel B10), Schulungsnachweise der Aufsichtspersonen |
| Genauigkeit, Robustheit, Cybersicherheit (Art. 15) | Angemessene Genauigkeit deklarieren und erreichen, Widerstandsfähigkeit gegen Fehler und Angriffe (inkl. KI-spezifischer Angriffe wie Data Poisoning und Adversarial Attacks) | Evaluationsberichte mit Schwellenwerten (siehe Kapitel D1), Sicherheitstests und Red-Teaming-Berichte (siehe Kapitel B9) |
| Qualitätsmanagementsystem (Art. 17, Anbieter) | Dokumentiertes QMS: Regelkonformitätsstrategie, Entwurfs-, Entwicklungs- und Prüfverfahren, Datenmanagement, Risikomanagement, Vorfallmeldung, Verantwortlichkeiten | QMS-Handbuch oder Integration ins bestehende QMS/ISMS |
| Konformitätsbewertung (Art. 43) und CE-Kennzeichnung (Art. 47, 48) | Vor Inverkehrbringen: Konformitätsbewertungsverfahren durchführen (je nach Fall interne Kontrolle oder mit benannter Stelle), EU-Konformitätserklärung ausstellen, CE-Kennzeichnung anbringen | Konformitätserklärung, Bewertungsbericht |
| Registrierung (Art. 49) | Eintragung relevanter Annex-III-Systeme in die EU-Datenbank vor Inbetriebnahme; auch dokumentieren, wenn die Art.-6(3)-Ausnahme in Anspruch genommen wird | Registrierungsnachweis, dokumentierte Ausnahme-Einstufung |
| Betreiberpflichten (Art. 26) | Einsatz gemäß Gebrauchsanweisung; Aufsicht durch befähigte, geschulte Personen; Kontrolle der Eingabedaten auf Eignung; Monitoring im Betrieb; Aufbewahrung der Protokolle; Information von Beschäftigten und Betroffenen über den Einsatz | Betriebskonzept, Schulungsnachweise, Monitoring-Berichte (siehe Kapitel D1) |
| Grundrechte-Folgenabschätzung FRIA (Art. 27) | Vor Inbetriebnahme durch bestimmte Betreiber (öffentliche Stellen sowie private Betreiber u. a. bei Kreditwürdigkeit und Lebens-/Krankenversicherungs-Preisbildung): betroffene Prozesse und Personengruppen, Risiken für Grundrechte, Aufsichtsmaßnahmen, Abhilfemaßnahmen beschreiben | FRIA-Dokument; mit der Datenschutz-Folgenabschätzung verzahnen, Doppelarbeit vermeiden |
Checkliste: Pflichten für Hochrisiko-Systeme
Diese Checkliste gehört zum Hochrisiko-Abschnitt: Sie wird je Hochrisiko-System geführt und dient der Fortschrittskontrolle zur Pflichtentabelle oben. Für jeden als Hochrisiko eingestuften Anwendungsfall:
- Risikomanagementsystem (Art. 9) über den gesamten Lebenszyklus etabliert
- Daten-Governance (Art. 10): Datenqualität und Verzerrungen geprüft und dokumentiert
- Technische Dokumentation (Art. 11) vollständig und aktuell
- Protokollierung (Art. 12) aktiv, Aufbewahrung geregelt
- Gebrauchsanweisung (Art. 13) liegt vor bzw. wurde vom Anbieter eingefordert
- Menschliche Aufsicht (Art. 14) konzipiert, Personen benannt und geschult
- Genauigkeit, Robustheit, Cybersicherheit (Art. 15) getestet und nachgewiesen
- Qualitätsmanagementsystem (Art. 17, Anbieter) vorhanden
- Konformitätsbewertung (Art. 43) durchgeführt, CE-Kennzeichnung wo erforderlich
- Registrierung (Art. 49) in der EU-Datenbank erfolgt bzw. Ausnahme dokumentiert
- Betreiberpflichten (Art. 26) im Betriebskonzept umgesetzt
- FRIA (Art. 27) geprüft und wo erforderlich durchgeführt
GPAI-Modelle (General-Purpose AI)
Was GPAI ist: KI-Modelle mit allgemeinem Verwendungszweck, also breit einsetzbare Foundation Models wie große Sprachmodelle (Begriffe in Kapitel A2). Der AI Act reguliert sie in einem eigenen Pflichtenblock, der neben den Risikoklassen steht: Die Risikoklassen bewerten den konkreten Einsatzzweck eines Systems, die GPAI-Regeln das Basismodell dahinter. Wer Foundation Models oder LLMs selbst bereitstellt (auch intern nach wesentlicher Anpassung), fällt unter die GPAI-Regeln der Art. 53 ff.:
- Alle GPAI-Anbieter (Art. 53): technische Dokumentation des Modells, Informationen und Dokumentation für nachgelagerte Anbieter, Strategie zur Einhaltung des EU-Urheberrechts (inkl. Text-und-Data-Mining-Vorbehalte), öffentliche Zusammenfassung der Trainingsinhalte.
- GPAI mit systemischem Risiko (Art. 51, 55): Ab einer Trainingsrechenleistung von 10^25 FLOP wird systemisches Risiko vermutet. Zusätzlich: Modellevaluierungen inklusive Adversarial Testing, Bewertung und Minderung systemischer Risiken, Meldung schwerwiegender Vorfälle, angemessene Cybersicherheit.
- Der GPAI Code of Practice (seit Juli 2025) ist das praktische Nachweisinstrument: Wer ihm beitritt und ihn einhält, kann die Vermutung der Regelkonformität für sich nutzen.
Die meisten Unternehmen sind Nutzer zugekaufter Modelle. Die Anbieterpflichten liegen dann beim Modellanbieter, der eigene Anwendungsfall darüber bleibt aber je nach Zweck eigenständig einzustufen. Was Nutzer vom Modellanbieter vertraglich einfordern sollten: die Dokumentation nach Art. 53, Zusicherungen zur Urheberrechts-Compliance, Unterstützung bei den eigenen Transparenz- und Dokumentationspflichten sowie Klarheit zur Nutzung der eigenen Eingaben (kein Training ohne Zustimmung). Der Anbieter-Fragenkatalog in Kapitel B3 enthält die passenden Fragen.
Teil 3: Parallel geltendes Recht
Dieser Teil verlässt den AI Act und behandelt drei Rechtsgebiete, die unabhängig von ihm gelten und in der Praxis gleichzeitig zu erfüllen sind: den Datenschutz (DSGVO), die Finanz- und Versicherungsaufsicht sowie das deutsche Arbeits- und Haftungsrecht. Die drei folgenden Abschnitte nehmen sie der Reihe nach.
Schnittstelle zur DSGVO
Die wichtigste Parallele ist der Datenschutz. Die Faustregel zur Abgrenzung: Der AI Act regelt das KI-System, die DSGVO die personenbezogenen Daten darin. Der AI Act ersetzt die DSGVO also nicht; beide gelten parallel, sobald personenbezogene Daten verarbeitet werden.
- Rechtsgrundlage der Verarbeitung geklärt (Training, Feinjustierung und Betrieb getrennt betrachten)
- Datenschutz-Folgenabschätzung (DSFA/DPIA) durchgeführt, wo erforderlich; mit der FRIA verzahnt
- Betroffenenrechte (Auskunft, Löschung, Widerspruch) umsetzbar, auch für Daten in Wissensbasen und Trainingsbeständen
- Automatisierte Einzelentscheidungen (Art. 22 DSGVO) bewertet: Bei rechtlicher oder ähnlich erheblicher Wirkung (Kredit, Versicherung, Personalauswahl) ist eine ausschließlich automatisierte Entscheidung nur in engen Ausnahmen zulässig; wirksame menschliche Prüfung muss mehr sein als ein Abnicken
- Auftragsverarbeitung mit Modell- und Plattformanbietern vertraglich geregelt (Art. 28 DSGVO)
Sektoraufsicht: Finanzwirtschaft und Versicherung
Für regulierte Finanzinstitute bleiben die nationalen Aufsichtsbehörden zuständig, in Deutschland die BaFin. Der AI Act gilt dabei zusätzlich zu bestehenden aufsichtsrechtlichen Anforderungen, nicht an deren Stelle. Der Schlüssel zur effizienten Umsetzung: gemeinsame Artefakte statt paralleler Dokumentationswelten. Die Tabelle zeigt, wo AI-Act-Pflichten und bestehende Anforderungen dasselbe verlangen.
| AI-Act-Anforderung | Bestehende Anforderung (Beispiele) | Gemeinsames Artefakt |
|---|---|---|
| Risikomanagementsystem (Art. 9) | MaRisk/MaGo Risikomanagement, VAIT/DORA IKT-Risikomanagement | Ein Risiko-Register, um KI-Risiken erweitert (siehe Kapitel D3) |
| Protokollierung (Art. 12) | DORA Logging und Überwachung, VAIT Protokollierungsanforderungen | Ein Log- und Monitoring-Konzept |
| Robustheit und Cybersicherheit (Art. 15) | DORA Resilienz- und Penetrationstests | Gemeinsamer Testplan, KI-Szenarien ergänzt (siehe Kapitel B9) |
| Menschliche Aufsicht, Modellvalidierung (Art. 14, 15) | Aufsichtliche Erwartungen an Modellrisiko-Management und Validierung | Validierungsberichte, Modellkarten (siehe Kapitel B7: Model Risk Management) |
| Zukauf von Modellen und Plattformen | VAIT/MaGo Auslagerung, DORA IKT-Drittparteirisiko | Ein Vertrags- und Exit-Dossier je Anbieter (siehe Kapitel B3) |
Hochrisiko-Anwendungsfälle (Risikobewertung und Preisbildung Leben/Kranken) sollten früh mit Compliance und ggf. der Aufsicht abgestimmt werden.
Nationale Marktüberwachung
Über die Sektoraufsicht hinaus braucht der AI Act in jedem Mitgliedstaat eine Marktüberwachungsbehörde, die seine Einhaltung durchsetzt. In Deutschland übernimmt diese Rolle die Bundesnetzagentur als zentrale Stelle, ergänzt um die bestehenden sektorspezifischen Aufsichten (etwa BaFin und die Datenschutzbehörden). Grundlage ist das KI-Marktüberwachungs- und Innovationsförderungsgesetz (KI-MIG), das der Bundestag im Juni 2026 beschlossen hat; die Zustimmung des Bundesrats und die Verkündung stehen zum Redaktionsstand noch aus. Für die Praxis heißt das: Die Behörde, an die Nachweise, Registrierungen und Vorfallmeldungen gehen, ist benennbar und sollte im KI-Register hinterlegt werden.
Deutsche Spezifika: Mitbestimmung und Haftung
Betriebsrat und Mitbestimmung. KI am Arbeitsplatz berührt regelmäßig Mitbestimmungsrechte, unabhängig von der AI-Act-Einstufung:
- Systeme, die Verhalten oder Leistung von Beschäftigten überwachen können (dazu reicht die technische Eignung), unterliegen der Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG. Das trifft auf viele KI-Werkzeuge mit Protokollierung zu.
- Der Betriebsrat ist bei der Planung von KI-Einsatz zu unterrichten (§ 90 BetrVG) und darf zur Beurteilung von KI ohne besondere Begründung Sachverständige hinzuziehen (§ 80 Abs. 3 BetrVG).
- Praktische Konsequenz: Betriebsrat früh einbinden und eine Rahmen-Betriebsvereinbarung KI anstreben, statt jedes Werkzeug einzeln zu verhandeln. Das beschleunigt jede spätere Einführung und zahlt auf die Akzeptanz ein.
Haftung. Die neue EU-Produkthaftungsrichtlinie (2024/2853) erfasst Software und KI-Systeme ausdrücklich als Produkte; die Umsetzung in deutsches Recht ist bis Dezember 2026 fällig. Der Entwurf einer eigenen KI-Haftungsrichtlinie wurde 2025 zurückgezogen; es gelten die allgemeinen Regeln (Vertrag, Delikt, Produkthaftung). Für die Praxis heißt das: Dokumentation, Protokollierung und Evaluationsnachweise aus diesem Kapitel sind zugleich die Beweismittel, mit denen sich ein Unternehmen im Haftungsfall entlastet. Für Geschäftsführung und Vorstand kommt die Organhaftung hinzu (§ 43 GmbHG, § 93 AktG): Wer KI ohne angemessene Kontroll-, Dokumentations- und Aufsichtsstruktur einsetzt, riskiert bei Schäden oder Bußgeldern die persönliche Inanspruchnahme, die eine D&O-Versicherung nur begrenzt abfedert. Dieselben Nachweise begrenzen daher auch das persönliche Haftungsrisiko der Leitung.
Checkliste: operative Compliance (unternehmensweit)
Anders als die Hochrisiko-Checkliste in Teil 2, die je System geführt wird, prüft diese Liste die unternehmensweite Compliance-Organisation:
- KI-Register: Inventar aller eingesetzten und geplanten KI-Systeme gepflegt
- Risikoeinstufung je System dokumentiert (Entscheidungsbaum in Teil 1), inkl. begründeter Art.-6(3)-Ausnahmen
- Rollen je System geklärt: Anbieter oder Betreiber; Rollenwechsel-Risiko bei Anpassungen bewertet
- KI-Kompetenz (Art. 4): rollenspezifische Schulungen etabliert und nachweisbar
- Transparenz umgesetzt: Kennzeichnung von Chatbots und KI-erzeugten Inhalten (ab 2. Aug 2026)
- Verantwortliche Stelle für AI-Act-Compliance benannt (siehe Kapitel B7)
- Beschaffung: Verträge sichern Dokumentation nach Art. 53, Datenhoheit, Audit-Rechte (siehe Kapitel B3)
- Cybersicherheitspflichten geprüft: NIS2 für Einrichtungen in geregelten Sektoren, im Finanzsektor DORA (Meldewege und Fristen siehe Kapitel B9)
- Betriebsrat eingebunden, Betriebsvereinbarung geprüft bzw. abgeschlossen
- Fristen-Monitoring: Anwendungstermine gegen das KI-Register abgeglichen, Verantwortliche je Frist benannt
- Regelmäßige Überprüfung bei neuen Anwendungsfällen, geänderten Systemen oder geänderter Rechtslage
Diese Inhalte dienen der Orientierung und sind keine Rechtsberatung. Verbindliche Einstufungen und Maßnahmen sind mit den zuständigen Funktionen für Recht, Datenschutz und Compliance abzustimmen.