Alle Artikel
Grundlagen 19. Juli 2026 12 Min. Lesezeit

DSGVO trifft KI-Verordnung: Die Doppel-Compliance-Roadmap 2026 für den Mittelstand

Mit dem KI-Marktüberwachungsgesetz (KI-MIG) und der nationalen Aufsicht durch die Bundesnetzagentur wird die Ueberlappung von DSGVO und AI Act erstmals scharf prüfbar. Datenschutz-Folgenabschätzung (Art. 35) und AI-Act-Dokumentation sind nur gemeinsam sauber umsetzbar – und US-Cloud-KI bringt mit dem CLOUD Act zusätzliche Transferrisiken mit.

Zwei Regelwerke, ein Fahrplan
DSGVO
Art. 35 · DPIA
DPIA
Logging
Risikomanagement
Schnittmenge
AI Act
Tech-Doku · Risiko
12-Punkte-Roadmap
1 Inventur 2 Risikoklasse 3 TIA 4 AVV 5 Transparenz 6 Aufsicht 7 Logging 8 Schulung 9 Löschkonzept 10 Recht 11 Incident 12 Review
KI-Transparenzhinweis: Dieser Beitrag wurde teilweise mit Unterstützung von KI-Systemen erstellt und vor der Veröffentlichung redaktionell geprüft. Kennzeichnung gemäß EU-KI-Verordnung (Verordnung (EU) 2024/1689).
Kurz gefasst

DSGVO und AI Act lassen sich nur gemeinsam sauber umsetzen. Mit dem KI-Marktüberwachungsgesetz (KI-MIG) und der nationalen Aufsicht durch die Bundesnetzagentur wird die Überlappung beider Regelwerke erstmals scharf prüfbar.

Zwei getrennte Projekte – Datenschutz hier, KI-Governance dort – erzeugen doppelte Arbeit an den Schnittstellen und Lücken dazwischen. Datenschutz-Folgenabschätzung nach Art. 35 DSGVO und AI-Act-Dokumentation gehören in einen Prozess. US-Cloud-KI bringt über den CLOUD Act zusätzliche Transferrisiken.

Zwei europäische Regelwerke greifen 2026 ineinander wie kaum zwei andere: die seit 2018 etablierte Datenschutz-Grundverordnung (DSGVO) und die junge KI-Verordnung, der EU AI Act. Wer im Mittelstand ein KI-System einsetzt, das personenbezogene Daten verarbeitet, unterliegt beiden gleichzeitig. Und das ist mehr als eine juristische Fußnote: Beide Regime verlangen Dokumentation, Risikobewertung und Nachweisbarkeit – mit erheblichen Ueberschneidungen, aber eben nicht deckungsgleich.

Die verbreitete Reaktion – zwei getrennte Projekte, ein Datenschutz-Team hier, ein KI-Governance-Team dort – ist teuer und fehleranfällig. Sie erzeugt doppelte Arbeit an den Schnittstellen und Lücken dazwischen. Dieser Artikel zeigt, warum sich DSGVO-Folgenabschätzung und AI-Act-Dokumentation nur gemeinsam sauber umsetzen lassen, und liefert eine kombinierte Roadmap mit rund zwölf konkreten Punkten – von der KI-Inventur bis zum wiederkehrenden Review.

Wichtige Terminkorrektur: Die Hochrisiko-Pflichten des AI Act (Annex III) wurden durch den „Digital Omnibus on AI" verschoben – sie greifen nicht mehr ab dem 2. August 2026, sondern erst ab dem 2. Dezember 2027 (Annex-I-Hochrisiko: verschoben auf 2. August 2028). Die GPAI-Pflichten für KI-Basismodelle gelten unverändert seit August 2025 fort. Ein „2026-Fahrplan" bleibt richtig – aber als Vorbereitung, mit der Dringlichkeit auf Ende 2027 geeicht, nicht als Panik-Deadline.

Warum beide Regelwerke zusammengehören

Der EU AI Act ersetzt die DSGVO nicht – er ergänzt sie. In den Erwägungsgründen stellt die Verordnung ausdrücklich klar, dass das Datenschutzrecht der Union unberührt bleibt. Für jedes KI-System, das personenbezogene Daten verarbeitet, gilt die DSGVO also weiterhin als zentraler Maßstab: Rechtsgrundlage nach Art. 6 (und Art. 9 bei besonderen Kategorien), Zweckbindung, Datenminimierung, Betroffenenrechte. Der AI Act legt eine zweite Ebene darüber – Produktsicherheits- und Governance-Anforderungen, gestaffelt nach Risikoklasse.

Bei einem hochriskanten KI-System (Annex III, etwa in Personalauswahl, Kreditvergabe oder kritischer Infrastruktur) treffen beide Pflichtenkreise aufeinander. Die DSGVO verlangt bei voraussichtlich hohem Risiko für die Rechte Betroffener eine Datenschutz-Folgenabschätzung (DPIA) nach Art. 35. Der AI Act verlangt zusätzlich ein eigenes Risikomanagement-System und eine technische Dokumentation. Diese laufen parallel und überlappen sich nur teilweise.

Genau hier liegt der entscheidende Punkt, der in der Praxis oft falsch verstanden wird: Eine DPIA ersetzt nicht das Risikomanagement-System des AI Act. Die DPIA kann Bausteine der AI-Act-Compliance abdecken – die Analyse von Verarbeitungsrisiken, die Dokumentation der Datenverarbeitung – aber sie tritt nicht an die Stelle der technischen Dokumentation, des kontinuierlichen Risikomanagements, der Protokollierungspflichten und der Konformitätsbewertung. Beide Instrumente laufen nebeneinander; ein Dokument befriedigt nicht beide Regime.

  • AI Act lässt DSGVO unberührt: Datenschutzrecht bleibt der zentrale Maßstab für personenbezogene Daten.
  • Hochrisiko-KI = doppelte Pflicht: DPIA nach Art. 35 und AI-Act-Dokumentation plus Risikomanagement-System.
  • Paralleles Risikomanagement nötig: Die Folgenabschätzung deckt Teile ab, ersetzt aber das kontinuierliche AI-Act-System nicht.
  • Getrennte Projekte erzeugen Lücken: An den Schnittstellen entstehen Doppelarbeit und blinde Flecken.

Die Konsequenz: Wer beide Regelwerke getrennt bearbeitet, führt dieselbe Risikoanalyse zweimal in unterschiedlichen Vokabularen durch – und riskiert trotzdem, dass keine der beiden Dokumentationen vollständig ist. Ein integrierter Ansatz nutzt die Schnittmenge als gemeinsames Fundament.

Die 12-Punkte-Roadmap

Die folgende Roadmap ist bewusst als praxisnahe Best-Practice-Checkliste angelegt – die Zahl „zwölf" steht in keiner Verordnung, sie ist ein sinnvoll geschnittener Fahrplan, der die Anforderungen beider Regime an den richtigen Stellen zusammenführt. Jeder Punkt bedient entweder die DSGVO, den AI Act oder beide zugleich.

# Maßnahme Bedient
1 KI-Inventur & Bestandsaufnahme DSGVO + AI Act
2 Risikoklasse nach AI Act bestimmen AI Act
3 Transfer-Impact-Assessment (TIA) DSGVO (Kap. V)
4 Auftragsverarbeitungsvertrag (AVV) DSGVO (Art. 28)
5 Transparenzhinweise & Kennzeichnung DSGVO + AI Act
6 Menschliche Aufsicht (Human Oversight) AI Act + Art. 22 DSGVO
7 Logging & Protokollierung DSGVO + AI Act
8 Schulung & KI-Kompetenz AI Act (Art. 4)
9 Löschkonzept & Aufbewahrung DSGVO (Art. 5, 17)
10 Marken- & Urheberrecht (Trainingsdaten, Output) Ergänzend
11 Incident-Response & Meldewege DSGVO + AI Act
12 Regelmäßiges Review & Re-Assessment DSGVO + AI Act

Die ersten beiden Punkte bilden das Fundament: Ohne eine vollständige LLM- und KI-Inventur weiß niemand, welche Systeme überhaupt in den Anwendungsbereich fallen. Erst danach lassen sich Risikoklasse (Punkt 2) und Transferrisiken (Punkt 3) belastbar bestimmen. Die Punkte 5 bis 8 sind operativ – sie müssen im Alltag gelebt werden, nicht nur dokumentiert. Punkt 12, das Review, schließt den Kreis: KI-Systeme, Datenflüsse und Rechtslage ändern sich, die Dokumentation muss mitwachsen.

Die Rolle der DPIA

Die Datenschutz-Folgenabschätzung ist das Scharnier zwischen beiden Regimen. Nach Art. 35 DSGVO ist sie Pflicht, wenn eine Verarbeitung – insbesondere unter Einsatz neuer Technologien – voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Bei systematischer, umfangreicher Verarbeitung durch KI-Systeme ist diese Schwelle regelmäßig erreicht.

Der Reiz der DPIA im Doppel-Compliance-Kontext: Ihre Struktur – Beschreibung der Verarbeitung, Bewertung von Notwendigkeit und Verhältnismäßigkeit, Risikoanalyse, Abhilfemaßnahmen – deckt sich in weiten Teilen mit der Risikodokumentation, die der AI Act verlangt. Wer die DPIA sorgfältig erstellt, liefert eine belastbare Grundlage für die technische AI-Act-Dokumentation und muss die Risikoanalyse nicht doppelt aufsetzen.

Praxisbeispiel: DPIA als gemeinsames Fundament
Ein Personaldienstleister setzt ein KI-gestütztes Vorauswahl-Tool für Bewerbungen ein – ein klassischer Annex-III-Hochrisikofall. Statt zwei getrennte Analysen zu fahren, erstellt das Unternehmen eine DPIA, die von vornherein die AI-Act-Anforderungen mitdenkt: Sie beschreibt die Verarbeitung, bewertet Diskriminierungsrisiken, dokumentiert die menschliche Letztentscheidung nach Art. 22 DSGVO und verweist auf die technische Dokumentation des Systems. Die DPIA wird so zum Ausgangsdokument, aus dem das AI-Act-Risikomanagement-System abgeleitet – aber nicht ersetzt – wird. Ergebnis: eine Risikoanalyse, zwei bediente Regime, klare Verzahnung.

Wichtig bleibt die Grenze: Auch die beste DPIA schafft keine Rechtsgrundlage. Wer personenbezogene Daten mit KI verarbeitet, braucht weiterhin eine tragfähige Rechtsgrundlage nach Art. 6 bzw. Art. 9 DSGVO – die Folgenabschätzung bewertet Risiken, sie legitimiert die Verarbeitung nicht. Und sie ersetzt, wie oben ausgeführt, nicht das eigenständige Risikomanagement-System des AI Act.

  • Pflicht bei systematischer Verarbeitung: KI-gestützte, umfangreiche Verarbeitung erreicht die Art.-35-Schwelle regelmäßig.
  • Grundlage der AI-Act-Risikodokumentation: Die DPIA-Struktur speist die technische Dokumentation.
  • Verzahnung statt Ersetzung: DPIA und AI-Act-Risikomanagement laufen parallel, ergänzen sich.
  • Rechtsgrundlage bleibt erforderlich: Art. 6/9 DSGVO sind unabhängig von der Folgenabschätzung nachzuweisen.

Das Drittland-Transferproblem

Sobald ein KI-System über eine US-Cloud betrieben wird – und das ist bei den meisten kommerziellen LLM-APIs der Fall – öffnet sich die nächste Baustelle: der Drittlandtransfer nach Kapitel V der DSGVO. Personenbezogene Daten, die an einen US-Anbieter fließen, verlassen den EU-Rechtsraum. Das ist nicht per se verboten, aber streng reguliert.

Nach dem Schrems-II-Urteil des EuGH reicht der bloße Rückgriff auf Standardvertragsklauseln (SCC) nicht mehr aus. Verantwortliche müssen ein Transfer-Impact-Assessment (TIA) durchführen und prüfen, ob im Empfängerland ein der EU gleichwertiges Schutzniveau besteht – und gegebenenfalls Zusatzmaßnahmen ergreifen, etwa Verschlüsselung, bei der der Anbieter keinen Zugriff auf die Schlüssel hat.

Der Kern des Problems ist der US CLOUD Act: Er verpflichtet US-Unternehmen, auf behördliche Anordnung Daten herauszugeben – unabhängig davon, wo auf der Welt diese Daten gespeichert sind. Ein US-Anbieter, der seine Server in einem EU-Rechenzentrum betreibt, unterliegt trotzdem dem CLOUD Act. Der viel beworbene „EU-Serverstandort" wird dadurch datenschutzrechtlich unterlaufen: Physische Lage in der EU schützt nicht vor extraterritorialem US-Zugriff, solange der Betreiber US-kontrolliert ist.

Die einzige strukturelle Lösung: On-Premise umgeht die gesamte Transferkette. Wenn das KI-System vollständig im eigenen Rechenzentrum läuft, gibt es keinen Drittlandtransfer, kein TIA für den LLM-Betrieb und keinen CLOUD-Act-Angriffspunkt. Die Datenschutzfrage wird nicht mit Verträgen entschärft, sondern technisch aufgelöst.

  • US-Cloud-LLMs erfordern SCC und TIA: Standardvertragsklauseln plus dokumentierte Risikoprüfung sind Pflicht.
  • Schrems-II-Zusatzmaßnahmen: Verschlüsselung und organisatorische Kontrollen als Ergänzung nötig.
  • CLOUD Act unterläuft EU-Serverstandort: Physische Lage schützt nicht vor US-Zugriff bei US-kontrolliertem Betreiber.
  • On-Premise umgeht die Transferkette: Kein Transfer, kein CLOUD-Act-Risiko – die Frage entfällt strukturell.

Weitere Regulierungen im Blick

DSGVO und AI Act sind die zwei prominentesten, aber nicht die einzigen Regelwerke mit Datenhandhabungspflichten. Wer Compliance ganzheitlich denkt, hat mindestens zwei weitere im Blick: DORA (Digital Operational Resilience Act, seit Januar 2025 in Kraft) für den Finanzsektor und NIS2 (Umsetzungsfrist Oktober 2024, mit Audit-Meilensteinen 2026) für die Cybersicherheit kritischer und wichtiger Einrichtungen.

Beide stellen Anforderungen an die Handhabung, Resilienz und Nachvollziehbarkeit von Daten und IT-Dienstleistern – und beide spielen unmittelbar mit dem AI Act zusammen, sobald KI-Systeme Teil der betroffenen Prozesse sind. DORA verlangt etwa ein striktes Management von IKT-Drittdienstleistern, worunter Cloud-KI-Anbieter fallen. NIS2 fordert Risikomanagement und Meldepflichten bei Sicherheitsvorfällen, die sich mit den Incident-Response-Anforderungen aus DSGVO und AI Act überschneiden.

Der rote Faden durch all diese Regelwerke ist Datensouveränität: die Kontrolle darüber, wo Daten liegen, wer darauf zugreifen kann und unter welcher Jurisdiktion. Genau diese Kontrolle lässt sich mit US-kontrollierter Cloud-Infrastruktur nur eingeschränkt herstellen. Wer Modell-Dokumentation, Inferenz und Output im eigenen Perimeter hält, erfüllt die gemeinsame Grundanforderung all dieser Regime an einem einzigen Punkt – der eigenen Infrastruktur.

  • DORA und NIS2 als Datenhandhabungspflichten: Resilienz, Drittdienstleister-Management, Meldepflichten.
  • Zusammenspiel mit dem AI Act: Ueberlappende Risikomanagement- und Incident-Anforderungen.
  • Datensouveränität als roter Faden: Kontrolle über Ort, Zugriff und Jurisdiktion der Daten.
  • Inferenz und Output im eigenen Perimeter: Ein Kontrollpunkt für mehrere Regelwerke.

Warum On-Premise die stärkste Position ist

Führt man die Argumente aus den vorangegangenen Abschnitten zusammen, ergibt sich ein klares Bild: Der On-Premise-Betrieb eines vollständig selbst gehosteten LLM ist die datenschutzrechtlich stärkste Ausgangsposition, die ein Unternehmen einnehmen kann. Der Grund ist einfach: Die Daten verlassen das eigene Netzwerk nie. Damit entfällt der gesamte Komplex des Drittlandtransfers – und mit ihm CLOUD Act, TIA für den Modellbetrieb und die Schrems-II-Unsicherheit.

Der Vorteil geht über die Transferfrage hinaus. Governance, Policy-Enforcement und Audit-Logs liegen im eigenen Stack. Wer Guardrails definieren, Zugriffe protokollieren und die Nachvollziehbarkeit jeder Inferenz sicherstellen will, kann das im eigenen Perimeter lückenlos tun – ohne auf die Zusagen eines externen Anbieters angewiesen zu sein. Techniken wie Differential Privacy oder Federated Learning lassen sich gezielt einsetzen, wo sensible Daten geschützt werden müssen, ohne die Kontrolle abzugeben.

Praxisbeispiel: Vom Cloud-Pilot zur On-Premise-Produktion
Ein mittelständischer Maschinenbauer startete seinen KI-Assistenten als Cloud-Pilot – und stellte bei der DPIA fest, dass Konstruktionsdaten und Kundenkorrespondenz über einen US-Anbieter liefen. Das TIA fiel negativ aus, die Zusatzmaßnahmen waren aufwendig, der CLOUD Act blieb ein Restrisiko. Die Entscheidung: Umzug auf ein On-Premise-LLM im eigenen Rechenzentrum. Danach entfiel die gesamte Kapitel-V-Prüfung für den Modellbetrieb. Die DPIA blieb dennoch erforderlich – aber sie wurde deutlich kürzer, weil der größte Risikoblock, der Auslandstransfer, komplett wegfiel.

Ein Missverständnis gilt es auszuräumen: On-Premise ist kein Compliance-Freifahrtschein. Auch beim selbst gehosteten Modell bleiben Rechtsgrundlage (Art. 6/9), Datenschutz-Folgenabschätzung (Art. 35, wo die Schwelle erreicht ist) und technisch-organisatorische Sicherheitskontrollen (Art. 32) Pflicht. On-Premise entfernt den schwersten Brocken – den Drittlandtransfer – aber nicht die Grundpflichten. Es ist die stärkste Position, nicht die Abwesenheit von Pflichten.

  • Daten verlassen das Netzwerk nie: Kein Drittlandtransfer, keine CLOUD-Act-Exposition.
  • Governance im eigenen Stack: Policy-Enforcement, Guardrails und Audit-Logs vollständig unter eigener Kontrolle.
  • Kein Drittlandtransfer: Der komplexeste DSGVO-Block entfällt strukturell.
  • DPIA und Sicherheit bleiben Pflicht: Rechtsgrundlage, Folgenabschätzung und Art.-32-Kontrollen weiterhin erforderlich.

Umsetzung in 90 Tagen

Doppel-Compliance klingt nach Großprojekt – lässt sich aber in einem strukturierten 90-Tage-Fahrplan angehen. Der Schlüssel ist die richtige Reihenfolge: erst Ueberblick schaffen, dann dokumentieren, dann technisch absichern, dann verankern.

Phase Fokus Roadmap-Punkte
Woche 1–2 Inventur & Klassifizierung aller KI-Systeme 1, 2
Woche 3–6 DPIA, TIA, AVV & technische Dokumentation 3, 4, 5, 9, 10
Woche 7–10 Technische Kontrollen, Logging, Human Oversight 6, 7, 11
Woche 11–12 Schulung, Review-Prozess etablieren 8, 12

In den ersten beiden Wochen geht es ausschließlich um Sichtbarkeit: Welche KI-Systeme sind im Einsatz, welche verarbeiten personenbezogene Daten, welche fallen in die Hochrisiko-Klasse? Diese Bestandsaufnahme entscheidet über alles Weitere. In Woche 3 bis 6 entsteht das dokumentarische Rückgrat – die DPIA als Fundament, TIA und AVV für verbleibende externe Dienstleister, das Löschkonzept für die Aufbewahrungsfristen.

Woche 7 bis 10 macht die Compliance operativ: Logging und Protokollierung werden technisch scharf geschaltet, die menschliche Aufsicht wird in die Prozesse eingebaut, Meldewege für Vorfälle werden definiert. Die letzten beiden Wochen verankern das Ganze in der Organisation – durch Schulung, die auch die KI-Kompetenzpflicht (Art. 4 AI Act) bedient, und durch einen festen Review-Rhythmus, der die Dokumentation lebendig hält. Wer diesen Fahrplan sauber abarbeitet, ist deutlich vor dem verschobenen Hochrisiko-Stichtag im Dezember 2027 aufgestellt – und hat die DSGVO-Pflichten, die schon heute gelten, gleich miterledigt.

Für den strukturierten Einstieg empfiehlt sich unsere EU-AI-Act-Checkliste als Ausgangspunkt. Und wer die Umsetzung nicht allein stemmen will: Unsere Beratung begleitet Mittelständler von der Inventur bis zum produktiven On-Premise-Betrieb.

Häufig gestellte Fragen zur Doppel-Compliance

Muss ich DSGVO und AI Act getrennt umsetzen?

Nein, und Sie sollten es nicht. Datenschutz-Folgenabschätzung nach Art. 35 DSGVO und AI-Act-Dokumentation gehören zusammen gedacht – ein kombinierter Fahrplan vermeidet doppelte Arbeit und Lücken.

Was umfasst die kombinierte Roadmap?

Rund 12 Punkte: KI-Inventur, Risikoklasse, Transfer-Impact-Assessment, AVV, Transparenzhinweise, menschliche Aufsicht, Logging, Schulung, Löschkonzept, Marken-/Urheberrecht, Incident-Response und regelmäßiges Review.

Warum ist On-Premise datenschutzrechtlich besser?

Bei einem vollständig selbst gehosteten LLM verlassen die Daten das eigene Netzwerk nie. Das umgeht Drittlandtransfer und CLOUD Act, ersetzt aber nicht Rechtsgrundlage, DPIA und Sicherheitskontrollen.

Welche weiteren Regeln spielen mit?

Neben DSGVO und AI Act stellen DORA und NIS2 Datenhandhabungspflichten, die sich mit US-kontrollierter Cloud-Infrastruktur nur schwer erfüllen lassen.

DSGVO und AI Act gemeinsam meistern

Wir begleiten Ihren Mittelstand durch die Doppel-Compliance – von der KI-Inventur über DPIA und TIA bis zum DSGVO-konformen On-Premise-Betrieb. Kostenlose Erstberatung.