DSGVO und EU AI Act für DACH-SaaS: ein aktueller Planungsrahmen

Zurück

Christof Jori

7 min Lesezeit · 26. Mai 2026
Zuletzt geprüft 11. November 2026

Weiter

Wenn du SaaS in der DACH-Region verkaufst und KI einsetzt, können sowohl die DSGVO als auch der EU AI Act gelten. Nicht jede Kontrolle gilt jedoch für jede Funktion. Beginne mit dem Anwendungsfall, der Verarbeitung personenbezogener Daten und deiner Rolle in der KI-Wertschöpfungskette. Nach dem aktuellen Umsetzungszeitplan der Europäischen Kommission gilt Artikel 50 zur Transparenz grundsätzlich seit dem 2. August 2026, die Anforderungen für Hochrisikosysteme nach Anhang III ab dem 2. Dezember 2027 und jene für in regulierte Produkte nach Anhang I eingebettete Hochrisikosysteme ab dem 2. August 2028. Recht und Governance bestätigen die Analyse; Produkt- und Entwicklungsteams erstellen die für das System relevanten Nachweise.

Für Schweizer Teams sind der nationale und der EU-Anwendungsbereich getrennt zu prüfen. In der Schweiz gelten das Datenschutzgesetz und einschlägige Branchenregeln. Nach Artikel 2 kann der EU AI Act auch gelten, wenn ein Schweizer Anbieter ein System oder ein KI-Modell für allgemeine Zwecke in der EU in Verkehr bringt oder wenn dort die Ausgabe eines KI-Systems eines Anbieters oder Betreibers aus einem Drittland verwendet wird. Der räumliche Anwendungsbereich der DSGVO richtet sich gesondert nach Artikel 3. Das Schweizer KMU-Portal erläutert die grenzüberschreitende Abgrenzung. Laut Oktober-Mitteilung des Bundesrats ist die Vernehmlassung zu den Schweizer KI-Maßnahmen für das Frühjahr 2027 vorgesehen.

Das ist eine technische Perspektive, keine Rechtsberatung. Wir haben für DACH-Kunden KI-Funktionen unter dem DSGVO-Regime ausgeliefert und laufende Projekte an den Zeitplan des AI Acts angepasst.

Welcher Durchsetzungszeitplan ist tatsächlich relevant?

Der AI Act gilt stufenweise. Die relevanten Termine hängen von Rolle und System ab:

• 2. Februar 2025. Die ursprünglichen Verbote (Artikel 5) und die Anforderungen an KI-Kompetenz (Artikel 4) wurden anwendbar.
• 2. August 2025. Governance-Regeln und Pflichten für Anbieter von GPAI-Modellen gelten, mit Übergangsregeln für ältere Modelle.
• 27. Juli 2026. Der Digital Omnibus zur KI trat in Kraft. Nach dem neuen Artikel 4 müssen Anbieter und Betreiber Maßnahmen zur Förderung der KI-Kompetenz ihrer Beschäftigten und anderer Personen ergreifen, die in ihrem Auftrag KI-Systeme betreiben oder nutzen. Ein bestimmtes individuelles Kompetenzniveau müssen sie nicht gewährleisten.
• 2. August 2026. Die Pflichten aus Artikel 50 gelten für bestimmte KI-Interaktionen sowie erzeugte oder manipulierte Inhalte.
• 2. Dezember 2026. Nach Artikel 111 Absatz 4 müssen Anbieter erfasster Systeme, die synthetische Inhalte erzeugen und vor dem 2. August 2026 in Verkehr gebracht wurden, bis zu diesem Datum die Kennzeichnungspflicht aus Artikel 50 Absatz 2 erfüllen.
• 2. Dezember 2027. Die Anforderungen für Hochrisikosysteme nach Anhang III beginnen nach dem Zeitplan des AI Omnibus zu gelten.
• 2. August 2028. Die Anforderungen für Hochrisiko-KI in regulierten Produkten nach Anhang I beginnen zu gelten.

Die DSGVO-Aufsicht hängt von Rechtsraum und Verarbeitungskontext ab. In Deutschland gibt es Aufsichtsbehörden des Bundes und der Länder; in Österreich die Datenschutzbehörde. Die Durchsetzung des AI Acts liegt hauptsächlich bei den zuständigen nationalen Marktüberwachungsbehörden, während das KI-Büro und der Europäische Datenschutzbeauftragte in festgelegten Bereichen zuständig sind. Bestimme die zuständige Behörde, statt anzunehmen, eine bestimmte Stelle prüfe jeden SDLC.

Ist meine KI-Funktion nach Anhang III hochriskant?

Anhang III erfasst bestimmte Anwendungen in Biometrie, kritischer Infrastruktur, Bildung, Beschäftigung, wesentlichen Diensten, Strafverfolgung, Migration, Justiz und demokratischen Prozessen. Der genaue Zweck und die Bedingungen sind entscheidend. Beispiele sind bestimmte Systeme zur Lebenslaufauswahl, Beschäftigtenüberwachung und Bonitätsprüfung. Allein die Branche oder der KI-Einsatz entscheidet die Einstufung aber nicht. Nutze den aktuellen Leitlinienentwurf der Kommission zu Hochrisikosystemen zusammen mit dem Gesetzestext und prüfe später veröffentlichte endgültige Leitlinien.

1. Erfüllt der beabsichtigte Zweck eine Kategorie und deren Bedingungen aus Anhang I oder III? Falls nicht, prüfe andere Pflichten aus AI Act und DSGVO, statt anzunehmen, nur Artikel 50 bleibe übrig.
2. Schließt Artikel 6 Absatz 3 ein System nach Anhang III aus, weil es kein erhebliches Risiko darstellt und eine aufgeführte Bedingung erfüllt? Für Profiling-Systeme gilt diese Ausnahme nicht. Dokumentiere die Bewertung und prüfe eine mögliche Registrierungspflicht.
3. Wenn das System hochriskant ist, ordne die Pflichten von Anbieter, Betreiber und weiteren Rollen zu. Das vollständige Kontrollset eines Anbieters liegt nicht automatisch bei jedem SaaS-Betreiber.

Welche Nachweise könnten Build- und Governance-Teams benötigen?

Es gibt keine universelle Liste aus neun Nachweisen in Verantwortung der Entwicklung. Anwendbarkeit und Verantwortlichkeit hängen von Rolle, Verarbeitung und Systemeinstufung ab. Eine praktische Nachweiskarte kann Folgendes enthalten:

1. Verzeichnisse von Verarbeitungstätigkeiten, wenn Artikel 30 DSGVO sie verlangt, gestützt durch gepflegte Datenfluss- und Systemaufzeichnungen.
2. Eine DSFA, wenn die Verarbeitung nach Artikel 35 DSGVO voraussichtlich ein hohes Risiko für die Rechte und Freiheiten von Menschen verursacht.
3. Technische Dokumentation nach Anhang IV, wenn das Unternehmen die entsprechende Pflicht als Anbieter eines Hochrisikosystems hat.
4. Protokollierung passend zur einschlägigen Rolle und zum System nach AI Act. Die Sechsmonatsregel aus Artikel 19 betrifft automatisch erzeugte Protokolle eines Hochrisikosystems, solange sie der Anbieter kontrolliert, sofern anderes Recht nichts anderes bestimmt.
5. Maßnahmen zur menschlichen Aufsicht für einschlägige Hochrisikosysteme, einschließlich kompetenter Personen, Befugnissen und nutzbarer Kontrollen.
6. Hinweise nach Artikel 50 oder maschinenlesbare Kennzeichnungen für die erfassten Interaktionen und Inhaltskategorien.
7. Material zu Trainingsinhalten und Urheberrechtsregeln für GPAI, wenn das Unternehmen tatsächlich Anbieter eines GPAI-Modells ist, nicht allein weil es Fine-Tuning nutzt.
8. Einen Ablauf für schwerwiegende Vorfälle bei Anbietern von Hochrisikosystemen, der die Fristen von zwei, zehn und fünfzehn Tagen aus Artikel 73 berücksichtigt.
9. Beobachtung nach dem Inverkehrbringen, wenn Anbieterpflichten sie verlangen, angemessen zum System und zu den benötigten Nachweisen.

Der konsolidierte AI Act auf EUR-Lex ist die maßgebliche Quelle für rollenspezifische Anforderungen.

Wie kann eine beispielhafte Verantwortungsmatrix aussehen?

Das folgende Beispiel dient der Koordination. Es ist weder eine gesetzliche Zuweisung noch eine vollständige Checkliste. Ein Unternehmen mit fünf Personen kann Rollen zusammenlegen, externe Beratung nutzen oder andere verantwortliche Personen benennen. Markiere zuerst jede Kontrolle als anwendbar oder nicht anwendbar.

"Compliance-Design beginnt bei der Architektur, nicht beim Launch. Wenn du nicht auf die Codezeile zeigen kannst, die den Nachweis erzeugt, ist der Nachweis Fiktion."

Wie greifen DSGVO und AI Act in der Praxis ineinander?

Die Regelwerke können sich überschneiden, aber jeder Auslöser muss separat geprüft werden:

• Trainingsdaten. Werden personenbezogene Daten verarbeitet, braucht die DSGVO eine Rechtsgrundlage und die Einhaltung ihrer weiteren Grundsätze. Die Anforderungen an Daten-Governance aus Artikel 10 AI Act gelten für einschlägige Hochrisikosysteme.
• Automatisierte Entscheidungen. Artikel 22 DSGVO betrifft Entscheidungen, die ausschließlich auf automatisierter Verarbeitung beruhen und rechtliche oder ähnlich erhebliche Wirkung haben. Schutzmaßnahmen für menschliches Eingreifen gelten in bestimmten Ausnahmefällen. Artikel 14 AI Act behandelt davon getrennt die Aufsicht bei Hochrisikosystemen.
• Transparenz. Artikel 13 und 14 DSGVO können Informationen zur Verarbeitung personenbezogener Daten verlangen; Artikel 50 AI Act erfasst bestimmte Interaktionen und Inhalte. Keines davon ist ein allgemeiner Hinweis für jede KI-Ausgabe.
• Aufzeichnungen. Verzeichnisse nach Artikel 30 DSGVO und technische Dokumentation nach Artikel 11 AI Act haben unterschiedliche Auslöser und verantwortliche Rollen. Gemeinsame Nachweise können Doppelarbeit reduzieren, ohne die rechtlichen Anforderungen zu vermischen.
• Risikobewertung. Eine DSFA nach DSGVO und das Risikomanagementsystem nach AI Act können Nachweise wiederverwenden, sind aber nicht austauschbar und müssen nicht immer ein einziges Dokument sein.

Nutze für die Zuordnung der Artikel 22, 30 und 35 den offiziellen DSGVO-Text auf EUR-Lex.

Was gilt für GPAI-Anbieter und Betreiber?

Ein DACH-SaaS-Unternehmen kann ein fremdes KI-System betreiben oder ein eigenes KI-System auf Basis eines fremden Modells anbieten. Für unterschiedliche Systeme kann es beide Rollen einnehmen. Die Rolle als Anbieter eines GPAI-Modells ist gesondert zu beurteilen. Fine-Tuning macht das Unternehmen nicht automatisch zum Anbieter eines neuen GPAI-Modells. Die Leitlinien der Kommission für GPAI-Anbieter besagen, dass erhebliche Änderungen diese Rolle verändern können, geringfügige Änderungen in der Regel aber nicht. Artikel 25 regelt separat, wann ein anderer Akteur Anbieterpflichten für ein KI-System übernimmt, etwa durch eine wesentliche Änderung oder einen geänderten beabsichtigten Zweck.

Wie sollten Build-Kosten geschätzt werden?

Es gibt keinen belastbaren universellen Prozentsatz für Nachrüstung oder Konzeption dieser Nachweise. Schätze anhand der anwendbaren Kontrollen, aktuellen Architektur, Datenherkunft, des Zugangs zu Modell und Anbieter, der Testlücken, des Dokumentationsstands, der Sicherheitskontrollen, des Prüfzyklus und externer Assurance. Frühe Einstufung kann Nacharbeit vermeiden, macht Compliance-Nachweise aber nicht kostenlos. Leite bei RAG-, Agenten- und MCP-Funktionen Transparenz, Protokollierung und menschliche Kontrolle aus der tatsächlichen Rolle und dem Anwendungsfall ab.

Andere Regelwerke können dieselbe Roadmap betreffen, doch ihre Geltungsdaten und ihr technischer Umfang müssen separat analysiert werden. Unser Überblick zu Stripe Billing und deutscher E-Rechnung behandelt die Abrechnungsanforderungen unabhängig davon.

Ein Datenschutzanbieter oder eine Pseudonymisierungsschicht kann Risiken und Datenflüsse verändern, beseitigt oder erhält aber nicht automatisch jede Pflicht eines Verantwortlichen. Lies, wie ein Pseudonymisierungs-Gateway den DSGVO-Anwendungsbereich verändert, und bewerte danach die konkrete Verarbeitung und die Rollen neu.