Im März 2025 ist im Rah­men des „Sup­port Pool of Experts“-Programms ein ca. 100-sei­ti­ger Bericht zu daten­schutz­recht­li­chen Risi­ken beim Ein­satz gro­sser Sprach­mo­del­le (LLMs) und zu Sicher­heits­mass­nah­men erschie­nen („AI Pri­va­cy Risks & Miti­ga­ti­ons – Lar­ge Lan­guage Models (LLMs)“). Das Pro­gramm dient der Unter­stüt­zung der Auf­sichts­be­hör­den bei kom­ple­xen Fäl­len, mit dem Ziel, ohne Ver­bind­lich­keit zur Anwen­dung der DSGVO beizutragen.

Der Bericht ana­ly­siert nach einer aus­führ­li­chen EIn­füh­rung auch in tech­ni­sche Aspek­te und in Agen­tic AI die daten­schutz­recht­li­chen Her­aus­for­de­run­gen im Zusam­men­hang mit der Ent­wick­lung, dem Betrieb und der Ein­bin­dung von LLMs in KI-Systeme.

Risi­ken

Er ori­en­tiert sich bei der Risi­ko­ana­ly­se am Lebens­zy­klus eines LLM-Systems:

1. Risi­ken in der Trainingsphase:

  • Unkon­trol­lier­te Daten­quel­len: LLMs wer­den häu­fig mit gro­ssen Daten­sät­zen trai­niert, die u.a. aus Web­s­cra­ping stam­men kön­nen. Sie kön­nen unbe­ab­sich­tigt per­so­nen­be­zo­ge­ne oder sen­si­ble Infor­ma­tio­nen enthalten.
  • Inhalt­li­che Memo­rie­rung: Das Modell kann sich per­so­nen­be­zo­ge­ne Inhal­te „ein­prä­gen“ und spä­ter reproduzieren.
  • Man­gel­haf­te Anony­mi­sie­rung: Auch wenn Daten vor­ver­ar­bei­tet wer­den, reicht die Anony­mi­sie­rung nicht immer aus.
  • Rechts­un­si­cher­heit: Der recht­li­che Sta­tus von Trai­nings­da­ten (z. B. Ein­wil­li­gung, Zweck­bin­dung) ist u.U. ungeklärt.

2. Risi­ken bei der Modellanwendung:

  • Leaka­ge: Out­puts kön­nen je nach­dem direkt oder indi­rekt auf rea­le Per­so­nen oder Trai­nings­in­hal­te verweisen.
  • Rekon­stru­ier­bar­keit: Bestimm­te Ein­ga­ben kön­nen dazu füh­ren, dass das Modell Trai­nings­mu­ster oder Quell­tex­te teil­wei­se wiedergibt.
  • RAGs: Wenn Daten­quel­len (z. B. ein RAG) bei Prompts und der Ant­wort her­an­ge­zo­gen wer­den, kön­nen u.U. sen­si­ble Inhal­te offen­ge­legt werden.

3. Risi­ken durch Feedbacks:

  • Unkla­re Daten­flüs­se: Feed­backs von Nut­zern (z. B. Kor­rek­tu­ren und Bewer­tun­gen) kön­nen gespei­chert und erneut bear­bei­tet wer­den, u.a. ohne Einwilligung/unzulässigerweise.
  • Pro­fil­bil­dung: Kon­ti­nu­ier­li­che Inter­ak­tio­nen mit einem System kön­nen nut­zer­be­zo­ge­ne Ver­hal­tens­mu­ster speichern.
  • Feh­len­de Zweck­bin­dung: Rück­mel­de­da­ten wer­den oft nicht getrennt ver­ar­bei­tet und mit ande­ren Daten­sät­zen vermischt.

4. Syste­mi­sche Risi­ken in Agenten-Architekturen:

  • Auto­no­mie: LLMs in agen­ti­schen Syste­men kön­nen u.U. eigen­stän­dig Ent­schei­dun­gen mit poten­ti­el­len Aus­wir­kun­gen auf Betrof­fe­ne fällen.
  • Intrans­pa­renz: Der Ablauf der Ent­schei­dungs­fin­dung ist tech­nisch kom­plex und für Aussen­ste­hen­de u.U. nicht nachvollziehbar.
  • Risi­ko­po­ten­zie­rung: Je mehr exter­ne Tools und Daten­quel­len inte­griert sind, desto schwe­rer las­sen sich Daten­flüs­se kontrollieren.

Mass­nah­men

Als Risi­ko­min­de­rungs­mass­nah­men nennt das Doku­ment bspw.:

1. Design und Konzeption:

  • Daten­mi­ni­mie­rung: Ver­zicht auf unnö­ti­ge per­so­nen­be­zo­ge­ne Daten­quel­len im Trai­ning, ins­be­son­de­re kei­ne Ver­wen­dung von Roh­da­ten aus nicht vali­dier­ten offe­nen Quellen.
  • Pri­va­cy by Design: Inte­gra­ti­on von Daten­schutz­prin­zi­pi­en in Archi­tek­tur und System­pla­nung, z. B. durch modu­la­re Daten­tren­nung oder ein­ge­schränk­te Kontextfenster.
  • Tech­ni­sche Schutz­mass­nah­men: Ein­bau von Dif­fe­ren­ti­al Pri­va­cy oder Ähnlichem.

2. Trai­nings- und Datenaufbereitung:

  • Daten­aus­wahl: Nut­zung geprüf­ter, mög­lichst anony­mi­sier­ter oder pseud­ony­mi­sier­ter Trai­nings­da­ten; bevor­zugt syn­the­ti­sche oder agg­re­gier­te Quellen.
  • Fil­ter: Ein­satz auto­ma­ti­sier­ter Erken­nungs- und Aus­schluss­me­cha­nis­men für sen­si­ble Inhal­te (z. B. per­sön­li­che Iden­ti­fi­ka­to­ren, Gesund­heits­da­ten, Finanzinformationen).
  • Anony­mi­tät: Vali­die­rung, ob Trai­nings­da­ten den Kri­te­ri­en der Irrever­si­bi­li­tät im Sin­ne der Opi­ni­on 28/2024 entsprechen.

3. Betrieb und Anwendung:

  • Zugriffs- und Rol­len­kon­zep­te: Imple­men­tie­rung dif­fe­ren­zier­ter Zugriffs­be­schrän­kun­gen für Admins, Ent­wick­ler und Endnutzer.
  • Out­put-Kon­trol­le: Ver­wen­dung von Out­put-Fil­tern, Prompt-Fire­walls und toxi­zi­täts­ba­sier­ten Black­lists zur Ver­hin­de­rung der Aus­ga­be schäd­li­cher oder iden­ti­fi­zie­ren­der Inhalte.
  • Token-Level-Schutz: Ein­satz seman­ti­scher Token­fil­te­rung zur Detek­ti­on und Mas­kie­rung sen­si­ti­ver Inhal­te vor Aus­lie­fe­rung an den Nutzer.
  • RAG-Schutz: Bei Retrie­val-Aug­men­ted Gene­ra­ti­on (RAG): Zugriffs­be­schrän­kun­gen, Pro­to­kol­lie­rung von Abfra­gen, Vali­die­rung der ver­wen­de­ten Daten.

4. Feed­back und Verbesserung:

  • Tren­nung: Tech­ni­sche Tren­nung zwi­schen ope­ra­ti­ver Nut­zung und Trainingsdaten.
  • Con­sent Manage­ment: Trans­pa­ren­te Gestal­tung von Feed­back, Kenn­zeich­nung frei­wil­li­ger Rück­mel­dun­gen, doku­men­tier­te Einwilligungen.
  • Lösch­pro­zes­se: Imple­men­tie­rung rever­si­bler Feed­back­spei­che­rung mit Opti­on auf Wider­ruf und Löschung.

5. Moni­to­ring, Rest­ri­si­ko­ana­ly­se und Governance:

  • Risi­ko­re­view: Regel­mä­ssi­ge tech­ni­sche und orga­ni­sa­to­ri­sche Über­prü­fun­gen, ins­be­son­de­re bei System­up­dates, Archi­tek­tur­än­de­run­gen oder Modellaustausch.
  • Rest­ri­si­koklas­si­fi­ka­ti­on: Syste­ma­ti­sche Bewer­tung akzep­tier­ter Rest­ri­si­ken, gestützt auf nach­voll­zieh­ba­re Schwe­re- und Eintrittswahrscheinlichkeiten.
  • Doku­men­ta­ti­on und Trans­pa­renz: Füh­rung eines Risi­ko­re­gi­sters, Pro­to­kol­lie­rung daten­schutz­re­le­van­ter Ent­schei­dun­gen, Offen­le­gung gegen­über Aufsichtsbehörden.