DSGVO trifft KI-Verordnung: Die Doppel-Compliance-Roadmap 2026 fuer den Mittelstand

Zwei europaeische 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 Fussnote: 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 fehleranfaellig. Sie erzeugt doppelte Arbeit an den Schnittstellen und Luecken dazwischen. Dieser Artikel zeigt, warum sich DSGVO-Folgenabschaetzung und AI-Act-Dokumentation nur gemeinsam sauber umsetzen lassen, und liefert eine kombinierte Roadmap mit rund zwoelf konkreten Punkten – von der KI-Inventur bis zum wiederkehrenden Review.

Warum beide Regelwerke zusammengehoeren

Der EU AI Act ersetzt die DSGVO nicht – er ergaenzt sie. In den Erwaegungsgruenden stellt die Verordnung ausdruecklich klar, dass das Datenschutzrecht der Union unberuehrt bleibt. Fuer jedes KI-System, das personenbezogene Daten verarbeitet, gilt die DSGVO also weiterhin als zentraler Massstab: Rechtsgrundlage nach Art. 6 (und Art. 9 bei besonderen Kategorien), Zweckbindung, Datenminimierung, Betroffenenrechte. Der AI Act legt eine zweite Ebene darueber – 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 fuer die Rechte Betroffener eine Datenschutz-Folgenabschaetzung (DPIA) nach Art. 35. Der AI Act verlangt zusaetzlich ein eigenes Risikomanagement-System und eine technische Dokumentation. Diese laufen parallel und ueberlappen 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 Konformitaetsbewertung. Beide Instrumente laufen nebeneinander; ein Dokument befriedigt nicht beide Regime.

• AI Act laesst DSGVO unberuehrt: Datenschutzrecht bleibt der zentrale Massstab fuer personenbezogene Daten.
• Hochrisiko-KI = doppelte Pflicht: DPIA nach Art. 35 und AI-Act-Dokumentation plus Risikomanagement-System.
• Paralleles Risikomanagement noetig: Die Folgenabschaetzung deckt Teile ab, ersetzt aber das kontinuierliche AI-Act-System nicht.
• Getrennte Projekte erzeugen Luecken: An den Schnittstellen entstehen Doppelarbeit und blinde Flecken.

Die Konsequenz: Wer beide Regelwerke getrennt bearbeitet, fuehrt dieselbe Risikoanalyse zweimal in unterschiedlichen Vokabularen durch – und riskiert trotzdem, dass keine der beiden Dokumentationen vollstaendig 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 „zwoelf" steht in keiner Verordnung, sie ist ein sinnvoll geschnittener Fahrplan, der die Anforderungen beider Regime an den richtigen Stellen zusammenfuehrt. Jeder Punkt bedient entweder die DSGVO, den AI Act oder beide zugleich.

#	Massnahme	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	Loeschkonzept & Aufbewahrung	DSGVO (Art. 5, 17)
10	Marken- & Urheberrecht (Trainingsdaten, Output)	Ergaenzend
11	Incident-Response & Meldewege	DSGVO + AI Act
12	Regelmaessiges Review & Re-Assessment	DSGVO + AI Act

Die ersten beiden Punkte bilden das Fundament: Ohne eine vollstaendige LLM- und KI-Inventur weiss niemand, welche Systeme ueberhaupt 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 muessen im Alltag gelebt werden, nicht nur dokumentiert. Punkt 12, das Review, schliesst den Kreis: KI-Systeme, Datenfluesse und Rechtslage aendern sich, die Dokumentation muss mitwachsen.

Die Rolle der DPIA

Die Datenschutz-Folgenabschaetzung 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 fuer die Rechte und Freiheiten natuerlicher Personen mit sich bringt. Bei systematischer, umfangreicher Verarbeitung durch KI-Systeme ist diese Schwelle regelmaessig erreicht.

Der Reiz der DPIA im Doppel-Compliance-Kontext: Ihre Struktur – Beschreibung der Verarbeitung, Bewertung von Notwendigkeit und Verhaeltnismaessigkeit, Risikoanalyse, Abhilfemassnahmen – deckt sich in weiten Teilen mit der Risikodokumentation, die der AI Act verlangt. Wer die DPIA sorgfaeltig erstellt, liefert eine belastbare Grundlage fuer die technische AI-Act-Dokumentation und muss die Risikoanalyse nicht doppelt aufsetzen.

Wichtig bleibt die Grenze: Auch die beste DPIA schafft keine Rechtsgrundlage. Wer personenbezogene Daten mit KI verarbeitet, braucht weiterhin eine tragfaehige Rechtsgrundlage nach Art. 6 bzw. Art. 9 DSGVO – die Folgenabschaetzung bewertet Risiken, sie legitimiert die Verarbeitung nicht. Und sie ersetzt, wie oben ausgefuehrt, nicht das eigenstaendige Risikomanagement-System des AI Act.

• Pflicht bei systematischer Verarbeitung: KI-gestuetzte, umfangreiche Verarbeitung erreicht die Art.-35-Schwelle regelmaessig.
• Grundlage der AI-Act-Risikodokumentation: Die DPIA-Struktur speist die technische Dokumentation.
• Verzahnung statt Ersetzung: DPIA und AI-Act-Risikomanagement laufen parallel, ergaenzen sich.
• Rechtsgrundlage bleibt erforderlich: Art. 6/9 DSGVO sind unabhaengig von der Folgenabschaetzung nachzuweisen.

Das Drittland-Transferproblem

Sobald ein KI-System ueber eine US-Cloud betrieben wird – und das ist bei den meisten kommerziellen LLM-APIs der Fall – oeffnet sich die naechste Baustelle: der Drittlandtransfer nach Kapitel V der DSGVO. Personenbezogene Daten, die an einen US-Anbieter fliessen, verlassen den EU-Rechtsraum. Das ist nicht per se verboten, aber streng reguliert.

Nach dem Schrems-II-Urteil des EuGH reicht der blosse Rueckgriff auf Standardvertragsklauseln (SCC) nicht mehr aus. Verantwortliche muessen ein Transfer-Impact-Assessment (TIA) durchfuehren und pruefen, ob im Empfaengerland ein der EU gleichwertiges Schutzniveau besteht – und gegebenenfalls Zusatzmassnahmen ergreifen, etwa Verschluesselung, bei der der Anbieter keinen Zugriff auf die Schluessel hat.

Der Kern des Problems ist der US CLOUD Act: Er verpflichtet US-Unternehmen, auf behoerdliche Anordnung Daten herauszugeben – unabhaengig 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 schuetzt nicht vor extraterritorialem US-Zugriff, solange der Betreiber US-kontrolliert ist.

• US-Cloud-LLMs erfordern SCC und TIA: Standardvertragsklauseln plus dokumentierte Risikopruefung sind Pflicht.
• Schrems-II-Zusatzmassnahmen: Verschluesselung und organisatorische Kontrollen als Ergaenzung noetig.
• CLOUD Act unterlaeuft EU-Serverstandort: Physische Lage schuetzt nicht vor US-Zugriff bei US-kontrolliertem Betreiber.
• On-Premise umgeht die Transferkette: Kein Transfer, kein CLOUD-Act-Risiko – die Frage entfaellt 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) fuer den Finanzsektor und NIS2 (Umsetzungsfrist Oktober 2024, mit Audit-Meilensteinen 2026) fuer 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 Sicherheitsvorfaellen, die sich mit den Incident-Response-Anforderungen aus DSGVO und AI Act ueberschneiden.

Der rote Faden durch all diese Regelwerke ist Datensouveraenitaet: die Kontrolle darueber, wo Daten liegen, wer darauf zugreifen kann und unter welcher Jurisdiktion. Genau diese Kontrolle laesst sich mit US-kontrollierter Cloud-Infrastruktur nur eingeschraenkt herstellen. Wer Modell-Dokumentation, Inferenz und Output im eigenen Perimeter haelt, erfuellt 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.
• Datensouveraenitaet als roter Faden: Kontrolle ueber Ort, Zugriff und Jurisdiktion der Daten.
• Inferenz und Output im eigenen Perimeter: Ein Kontrollpunkt fuer mehrere Regelwerke.

Warum On-Premise die staerkste Position ist

Fuehrt man die Argumente aus den vorangegangenen Abschnitten zusammen, ergibt sich ein klares Bild: Der On-Premise-Betrieb eines vollstaendig selbst gehosteten LLM ist die datenschutzrechtlich staerkste Ausgangsposition, die ein Unternehmen einnehmen kann. Der Grund ist einfach: Die Daten verlassen das eigene Netzwerk nie. Damit entfaellt der gesamte Komplex des Drittlandtransfers – und mit ihm CLOUD Act, TIA fuer den Modellbetrieb und die Schrems-II-Unsicherheit.

Der Vorteil geht ueber 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 lueckenlos 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 geschuetzt werden muessen, ohne die Kontrolle abzugeben.

Ein Missverstaendnis gilt es auszuraeumen: On-Premise ist kein Compliance-Freifahrtschein. Auch beim selbst gehosteten Modell bleiben Rechtsgrundlage (Art. 6/9), Datenschutz-Folgenabschaetzung (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 staerkste 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 vollstaendig unter eigener Kontrolle.
• Kein Drittlandtransfer: Der komplexeste DSGVO-Block entfaellt strukturell.
• DPIA und Sicherheit bleiben Pflicht: Rechtsgrundlage, Folgenabschaetzung und Art.-32-Kontrollen weiterhin erforderlich.

Umsetzung in 90 Tagen

Doppel-Compliance klingt nach Grossprojekt – laesst sich aber in einem strukturierten 90-Tage-Fahrplan angehen. Der Schluessel 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 ausschliesslich um Sichtbarkeit: Welche KI-Systeme sind im Einsatz, welche verarbeiten personenbezogene Daten, welche fallen in die Hochrisiko-Klasse? Diese Bestandsaufnahme entscheidet ueber alles Weitere. In Woche 3 bis 6 entsteht das dokumentarische Rueckgrat – die DPIA als Fundament, TIA und AVV fuer verbleibende externe Dienstleister, das Loeschkonzept fuer 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 fuer Vorfaelle 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 haelt. 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.

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

Haeufig gestellte Fragen zur Doppel-Compliance

Muss ich DSGVO und AI Act getrennt umsetzen?

Nein, und Sie sollten es nicht. Datenschutz-Folgenabschaetzung nach Art. 35 DSGVO und AI-Act-Dokumentation gehoeren zusammen gedacht – ein kombinierter Fahrplan vermeidet doppelte Arbeit und Luecken.

Was umfasst die kombinierte Roadmap?

Rund 12 Punkte: KI-Inventur, Risikoklasse, Transfer-Impact-Assessment, AVV, Transparenzhinweise, menschliche Aufsicht, Logging, Schulung, Loeschkonzept, Marken-/Urheberrecht, Incident-Response und regelmaessiges Review.

Warum ist On-Premise datenschutzrechtlich besser?

Bei einem vollstaendig 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 erfuellen lassen.