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

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 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.

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. Verbotene Praktiken (Art. 5) und die Pflicht zur KI-Kompetenz (Art. 4) gelten.
• 2. August 2025. Governance-Regeln und Pflichten für Anbieter von GPAI-Modellen gelten, mit Übergangsregeln für ältere Modelle.
• 2. August 2026. Die Pflichten aus Artikel 50 gelten für bestimmte KI-Interaktionen sowie erzeugte oder manipulierte Inhalte.
• 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, das ein Drittmodell integriert, kann Betreiber dieses Modells und Anbieter seines eigenen KI-Systems sein, je nachdem, was es entwickelt und auf den Markt bringt. Die Rollen sind getrennt zu bewerten. 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.