DSFA für ein internes LLM: wann Artikel 35 DSGVO eine Datenschutz-Folgenabschätzung für KI verlangt

DSFA für ein internes LLM: wann Artikel 35 DSGVO greift

Ein interner LLM-Assistent, der personenbezogene Daten von Beschäftigten, Kunden oder anderen Personen in großem Umfang verarbeitet, erfüllt oft die Kriterien, die eine Datenschutz-Folgenabschätzung (DSFA) nach Artikel 35 DSGVO erfordern, erst recht, wenn er zur Bewertung von Personen eingesetzt wird. Artikel 35 Absatz 1 verlangt sie vor einer Verarbeitung, die voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat, und nennt dabei ausdrücklich die Verwendung neuer Technologien. Der Datenschutzleitfaden des Europäischen Datenschutzausschusses (EDSA) für kleine Unternehmen nennt neun Kriterien und sagt, dass eine Verarbeitung, die zwei davon erfüllt, in den meisten Fällen einer DSFA unterzogen werden sollte. Ein unternehmensweiter Assistent mit Retrieval über Personal-, Kunden- oder Fallakten kann mehrere davon erfüllen.

Die meisten Fakten, auf denen eine DSFA beruht, kommen aus der IT: was wohin fließt, wo das Modell läuft, wie lange Prompts und Logs aufbewahrt werden, wer welches Dokument lesen darf und welche Lieferanten die Daten erreichen können. Dieser Leitfaden führt diese Angaben für eine Plattform mit 500 bis 2.000 Nutzern auf. Ob eine DSFA erforderlich ist und zu welchem Ergebnis sie kommt, ist eine Bewertung für den Verantwortlichen, seinen Datenschutzbeauftragten und seine Rechtsabteilung.

Was Artikel 35 DSGVO verlangt

Artikel 35 Absatz 1 verpflichtet den Verantwortlichen, die Abschätzung vor der Verarbeitung durchzuführen, und fügt hinzu, dass eine einzige Abschätzung mehrere ähnliche Verarbeitungsvorgänge mit ähnlich hohen Risiken abdecken kann. Nach Artikel 35 Absatz 2 holt der Verantwortliche den Rat des Datenschutzbeauftragten ein, sofern ein solcher benannt wurde. Artikel 35 Absatz 3 nennt drei Fälle, in denen eine DSFA insbesondere erforderlich ist. Buchstabe a erfasst eine systematische und umfassende Bewertung persönlicher Aspekte natürlicher Personen, die sich auf automatisierte Verarbeitung einschließlich Profiling gründet, wenn darauf beruhende Entscheidungen Rechtswirkung entfalten oder die Personen in ähnlich erheblicher Weise betreffen. Buchstabe b erfasst die umfangreiche Verarbeitung besonderer Kategorien von Daten nach Artikel 9 Absatz 1 oder von Daten über strafrechtliche Verurteilungen, Buchstabe c die umfangreiche Überwachung öffentlich zugänglicher Bereiche.

Artikel 35 Absatz 7 legt den Mindestinhalt fest: eine systematische Beschreibung der geplanten Verarbeitungsvorgänge und der Zwecke der Verarbeitung, eine Bewertung der Notwendigkeit und Verhältnismäßigkeit, eine Bewertung der Risiken für die Rechte und Freiheiten der betroffenen Personen sowie die zur Bewältigung der Risiken geplanten Abhilfemaßnahmen, einschließlich Garantien, Sicherheitsvorkehrungen und Verfahren. Nach Artikel 35 Absatz 9 holt der Verantwortliche gegebenenfalls den Standpunkt der betroffenen Personen oder ihrer Vertreter ein. Artikel 35 Absatz 11 verlangt erforderlichenfalls eine Überprüfung, zumindest wenn sich das mit den Verarbeitungsvorgängen verbundene Risiko ändert.

EDSA-Kriterien und die Stellungnahme des EDSA zu KI-Modellen

Der Datenschutzleitfaden des EDSA für kleine Unternehmen nennt die neun Kriterien: Bewertung oder Scoring; automatisierte Entscheidungsfindung mit Rechtswirkung oder ähnlich erheblicher Wirkung; systematische Überwachung; sensible Daten oder Daten höchstpersönlicher Natur; in großem Umfang verarbeitete Daten; Abgleich oder Zusammenführung von Datensätzen; Daten zu schutzbedürftigen Betroffenen; innovative Nutzung oder Anwendung neuer technologischer oder organisatorischer Lösungen; und Verarbeitungen, die Personen daran hindern, ein Recht auszuüben oder eine Dienstleistung oder einen Vertrag in Anspruch zu nehmen. Laut dem Leitfaden des EDSA sollten „Verarbeitungsvorgänge, die zwei der folgenden Kriterien erfüllen, in den meisten Fällen einer DSFA unterzogen werden“, und er verweist auf die Leitlinien der Artikel-29-Datenschutzgruppe zur DSFA (WP248 rev.01). Der EDSA hat sie am 25. Mai 2018 bestätigt, in der am 4. Oktober 2017 überarbeiteten und angenommenen Fassung.

In seiner Stellungnahme 28/2024, angenommen am 17. Dezember 2024, nennt der EDSA Datenschutz-Folgenabschätzungen „ein wichtiges Element der Rechenschaftspflicht“, wenn eine Verarbeitung im Zusammenhang mit KI-Modellen voraussichtlich ein hohes Risiko zur Folge hat, und zwar in einer Liste von Bestimmungen, die die Stellungnahme nicht untersucht. Laut der Stellungnahme des EDSA können „KI-Modelle, die mit personenbezogenen Daten trainiert wurden, nicht in allen Fällen als anonym angesehen werden“; mit Personal- oder Kundendatensätzen feinabgestimmte Gewichte sind daher ein weiterer Speicher im Datenfluss. Nach ihrer Zusammenfassung sollten die Aufsichtsbehörden berücksichtigen, ob der Verantwortliche, der ein Modell einsetzt, „eine angemessene Bewertung vorgenommen hat“, um festzustellen, dass das Modell nicht durch unrechtmäßige Verarbeitung personenbezogener Daten entwickelt wurde. Der Modellnachweis im Abschnitt zu den Lieferanten unten stützt diese Bewertung.

Die umfangreiche Verarbeitung von Gesundheitsdaten fällt unter Artikel 35 Absatz 3 Buchstabe b; unser Leitfaden zum privaten LLM im Krankenhaus behandelt diesen Fall.

Was die IT für jeden Teil der DSFA liefert

Auf einer LLM-Plattform erreichen der Prompt und jede hochgeladene Datei das Gateway und den Modellserver. Das Retrieval ergänzt Passagen aus dem Vektorindex, der Textabschnitte und ihre Embeddings speichert. Die Antwort geht zurück an das Frontend, das die Unterhaltung in seiner Datenbank hält. Das Gateway-Log kann Prompts und Antworten vollständig enthalten, und Backups kopieren all das. Der KV-Cache im GPU-Speicher hält den Kontext, solange eine Anfrage läuft, mit Prefix Caching auch länger.

Verordnung (EU) 2016/679, Artikel 5, 17, 30, 32 und 35, auf eur-lex.europa.eu mit Stand Oktober 2026; die rechte Spalte ist unser Beispiel für die Angaben.

Artikel 30 Absatz 1 Buchstabe f verlangt im Verzeichnis von Verarbeitungstätigkeiten „wenn möglich, die vorgesehenen Fristen für die Löschung der verschiedenen Datenkategorien“; legen Sie daher für jeden Speicher eine Frist fest: Chatverlauf, Gateway-Log, Vektorindex und Backups. Ein Löschantrag nach Artikel 17 kann die Daten in allen davon betreffen, daher sollte der Index die Löschung nach Quelldokument unterstützen und die Logs die Löschung nach Nutzer-ID. Gelöschte Daten verschwinden aus den Backups erst, wenn die Backups ablaufen. Unser Leitfaden zu ISO/IEC 42001 und KI-Governance für ein privates LLM beschreibt das Register der Anwendungsfälle und das Query-Log, aus denen die ersten Zeilen gespeist werden.

Unsere Leistung Private AI/ML baut die Plattform mit Query-Log sowie Daten- und Berechtigungsverwaltung, sodass Security und Legal sehen, wer worauf zugreift. Schicken Sie uns die Anwendungsfälle und die Daten, die jeder davon erreichen würde, über das Formular unten.

Beispiel: ein Assistent für 1.500 Beschäftigte

Nehmen Sie die Plattform aus unserem Governance-Leitfaden: 1.500 Beschäftigte, zwei GPU-Server on-premise, drei Open-Weight-Modelle hinter einem Gateway und sechs freigegebene Anwendungsfälle. Die Tabelle zeigt fünf davon (ohne den Code-Assistenten) und eine geplante Nutzung, jeweils mit den zu prüfenden EDSA-Kriterien.

Kriterien aus dem Datenschutzleitfaden des EDSA für kleine Unternehmen; Anwendungsfälle aus unserem Leitfaden zur KI-Governance; die Zuordnung ist unser Beispiel, keine rechtliche Einstufung.

Artikel 35 Absatz 1 erlaubt eine einzige Abschätzung für mehrere ähnliche Vorgänge, daher könnten die ersten drei Nutzungen eine gemeinsame erhalten, wenn der Verantwortliche nach Beratung durch den Datenschutzbeauftragten feststellt, dass sie ähnlich hohe Risiken aufweisen. Im HR-FAQ beschreiben Beschäftigte ihre eigene Situation, daher sind eine kürzere Aufbewahrungsfrist und weniger Leser der Logs für diese Nutzung Maßnahmen, die abzuwägen sind. Das Sichten von Bewerbungen wäre ein neuer Zweck mit eigener Abschätzung und ist zudem in Anhang III Nummer 4 Buchstabe a der KI-Verordnung aufgeführt, für Systeme, die dazu bestimmt sind, „Bewerbungen zu sichten oder zu filtern und Bewerber zu bewerten“.

Risiken und Maßnahmen auf der LLM-Plattform

Artikel 32 Absatz 1 verlangt „geeignete technische und organisatorische Maßnahmen“, die unter anderem „die Pseudonymisierung und Verschlüsselung personenbezogener Daten“ einschließen, sowie eine regelmäßige Überprüfung ihrer Wirksamkeit.

Verordnung (EU) 2016/679, Artikel 5, 32 und 44, auf eur-lex.europa.eu mit Stand Oktober 2026; die Maßnahmen sind unsere Beispiele.

Unser Leitfaden zu Prompt Injection und LLM-Sicherheit behandelt die Tests und die Prüfung vor dem Go-live, auf denen diese Maßnahmen beruhen.

Das Engineering durch unseren Engineering-Partner Vixen.UNO umfasst den Schutz vor Prompt Injection, die Zugriffsrechte und die Protokollierung von Anfragen und Antworten. Beschreiben Sie Ihre Quellen, Nutzer und die heutige Protokollierung im Formular unten.

Lieferanten, Hosting und Herkunft des Modells

Läuft ein Open-Weight-Modell auf den eigenen Servern des Unternehmens, erreichen die Prompts den Herausgeber des Modells nicht. Die DSFA führt die Lieferanten auf, die die Daten erreichen können, etwa einen Hosting-Anbieter, einen Engineering-Partner mit administrativem Zugriff und jede öffentliche API, die für bestimmte Aufgaben freigeschaltet ist. Nach Artikel 28 Absatz 1 arbeitet der Verantwortliche „nur mit Auftragsverarbeitern, die hinreichend Garantien“ bieten, und nach Artikel 28 Absatz 3 Buchstabe f unterstützt der Auftragsverarbeiter den Verantwortlichen bei der Einhaltung „der in den Artikeln 32 bis 36 genannten Pflichten“, zu denen die DSFA gehört. Was dieser Vertrag enthalten muss, behandelt unser Leitfaden zu DSGVO beim Cloud-Hosting, AVV nach Artikel 28 und Subauftragsverarbeitern.

Führen Sie für jedes Modell einen Nachweis, der die Bewertung des einsetzenden Verantwortlichen stützt: den Herausgeber und die Herkunft der Gewichte, die beim Import geprüfte Prüfsumme, die Model Card und die Lizenz sowie welche Version welchen Anwendungsfall beantwortet hat.

Wie die Betreiberpflichten des AI Act mit der DSFA zusammenhängen

Für Hochrisiko-KI-Systeme verlangt Artikel 26 Absatz 9 der KI-Verordnung von Betreibern, die vom Anbieter nach Artikel 13 bereitgestellten Informationen zu verwenden, um ihrer Pflicht zur Durchführung einer Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO nachzukommen. Nach Artikel 26 Absatz 6 bewahren sie die automatisch erzeugten Protokolle, soweit diese ihrer Kontrolle unterliegen, mindestens sechs Monate auf, sofern geltendes Unionsrecht oder nationales Recht, insbesondere das Datenschutzrecht der Union, nichts anderes vorsieht; die Aufbewahrungsfrist in der DSFA und die Protokollfrist nach dem AI Act sind daher gemeinsam festzulegen.

Artikel 27 Absatz 1 verlangt vor dem Einsatz eines Hochrisiko-Systems nach Artikel 6 Absatz 2 eine Grundrechte-Folgenabschätzung; ausgenommen ist kritische Infrastruktur (Anhang III Nummer 2). Sie gilt für Betreiber, die Einrichtungen des öffentlichen Rechts oder private Einrichtungen sind, die öffentliche Dienste erbringen, sowie für Betreiber der Systeme zur Kreditwürdigkeitsprüfung und für Lebens- und Krankenversicherungen nach Anhang III Nummer 5 Buchstaben b und c. Nach Artikel 27 Absatz 4 kann eine solche Abschätzung auf die einschlägigen Abschnitte der Datenschutz-Folgenabschätzung verweisen. Nach Artikel 113 in der durch die Verordnung (EU) 2026/1744 geänderten Fassung gelten diese Vorschriften für Verwendungen nach Anhang III ab dem 2. Dezember 2027. Entwürfe, Suche und Zusammenfassungen sind keine Zwecke nach Anhang III; unser Beitrag zu den Pflichten nach dem AI Act für Unternehmen, die LLMs betreiben legt dar, was für sie heute gilt.

Vorherige Konsultation, Überprüfung und Freigabe

Artikel 36 Absatz 1 verpflichtet den Verantwortlichen, die Aufsichtsbehörde zu konsultieren, wenn aus einer Datenschutz-Folgenabschätzung nach Artikel 35 hervorgeht, dass die Verarbeitung ein hohes Risiko zur Folge hätte, sofern der Verantwortliche keine Maßnahmen zur Eindämmung des Risikos trifft. Artikel 39 Absatz 1 Buchstabe c überträgt dem Datenschutzbeauftragten die Aufgabe, auf Anfrage im Zusammenhang mit der DSFA zu beraten und ihre Durchführung zu überwachen. Die IT verantwortet den technischen Anhang und hält ihn über den Change-Prozess aktuell.

1. Jeder Änderungsantrag nennt den Anwendungsfall, das Modell, den Konnektor oder die Aufbewahrungseinstellung, die er betrifft.
2. Der Plattformverantwortliche hält fest, ob sich Datenkategorien, Empfänger, Modell oder Speicherung ändern.
3. Wenn ja, überprüft der Verantwortliche die DSFA mit dem Rat des Datenschutzbeauftragten, da Artikel 35 Absatz 11 eine Überprüfung vorsieht, wenn sich das Risiko ändert.
4. DSFA und Register der Anwendungsfälle werden aktualisiert, bevor die Änderung live geht.

Was wir tun

Unsere Leistung Private AI/ML baut private LLM-Plattformen on-premise oder auf dedizierter Hardware in einem Tier-3-Rechenzentrum in Litauen, mit Engineering von unserem Engineering-Partner Vixen.UNO. Sie umfasst den Schutz vor Prompt Injection, die Daten- und Berechtigungsverwaltung und die Protokollierung von Anfragen und Antworten. Nichts geht an öffentliche Dienste, solange Sie es nicht ausdrücklich freigeben. Wir liefern den technischen Teil und schulen Ihr Team für den Betrieb der Plattform. Ein Auftragsverarbeitungsvertrag ist auf Anfrage erhältlich, mit Subauftragsverarbeitern namentlich im Vertrag, wie unsere Seite Sicherheit & Compliance darlegt.

FAQ