Teil 19: Sprachmodelle mit und ohne personenbezogene Daten

Vor allem die Unternehmen, die KI im Grunde nur als Verwender für ihre eigenen Zwecke zum Einsatz bringen, können etwas aufatmen: Die meisten Rechtstreitigkeiten, zu denen Sprachmodelle bisher geführt haben, betreffen primär jene, die solche Modelle trainieren oder als SaaS-Angebote auf dem freien Markt anbieten und für ein breites Publikum zugänglich sind. Auch zeichnet sich die Abgrenzung zwischen Erstellung und Verwendung im Sinne einer gewissen rechtlichen "Brandmauer" in der Diskussion immer stärker ab. Das ist insofern eine gute Nachricht, als die Risiken für die Verwender von KI sich damit immer stärker reduzieren. Zwar wird es sicherlich zu aufsehenerregenden Urteilen und womöglich auch Bussen für Datenschutzverletzungen durch die grossen Namen im KI-Markt kommen, aber am grundsätzlich wachsenden Einsatz und der Verbreitung solcher Techniken werden sie nach unserer Prognose nichts ändern.

Begriffsbestimmung – der relative Ansatz

Das bringt uns zur Kernfrage der vorliegenden Diskussion: Enthält ein grosses Sprachmodell personenbezogene Daten? Beantworten möchten wir diese Frage auf der Basis von Sprachmodellen der Transformer-Technik, wie wir sie in unserem Blog-Beitrag Nr. 17 beschrieben haben, dessen Lektüre für ein besseres Verständnis wir hier voraussetzen.

Um diese Frage zu beantworten, müssen wir uns der Begriffsdefinition des personenbezogenen Datums erinnern. Hierbei stützen wir uns nicht auf die Ansichten einiger europäischer Datenschutzbehörden, da sie unseres Erachtens keine Stütze im geltenden Recht finden: Weder führt eine Singularisierung automatisch zur Identifikation (sie ist nur ein Teilelement der Identifizierung), noch genügt es, dass eine Identifikation durch eine beliebige Person vorgenommen werden kann und nicht nur jene mit Zugang zu den Daten (bekannt als der sog. absolute oder objektive Ansatz).

Stattdessen sollte auf das Begriffsverständnis des EuGH, namentlich in "Breyer" (C‑582/14) und zuletzt in "VIN" (C-319/22), abgestellt werden, sowie jenes des Schweizer Bundesgerichts für das Datenschutzgesetz (DSG), dies seit "Logistep" (BGE 136 II 508): Ob ein personenbezogenes Datum vorliegt, kann immer nur aus der Warte derjenigen Stellen beurteilt werden, die Zugang zur betreffenden Information haben. Wenn die Personen, auf die sich eine Information bezieht, für diese Stellen identifizierbar sind, dann handelt es sich für sie um personenbezogene Daten und sonst eben nicht. Dies ist als sog. relativer Ansatz bekannt. Die Identifizierbarkeit muss für den Verantwortlichen selbst nicht gegeben sein; gibt er Informationen weiter, die für ihn zwar keine personenbezogenen Daten sind, wohl aber für die Empfänger, sind trotzdem personenbezogene Daten weitergegeben worden und er hat den Datenschutz einzuhalten (so ist auch der Verweis auf die Dritten in Rz. 45 des Entscheids C-319/22 zu verstehen).

Dabei sind die Personen nur und erst dann identifizierbar, wenn die dafür nötigen Mittel nach "allgemeinem Ermessen wahrscheinlich genutzt werden" ("means reasonably likely to be used"), um den Wortlaut von Erwägungsgrund 26 der DSGVO zu zitieren. Weil also eine gewisse Wahrscheinlichkeit erforderlich ist, genügt eine theoretische Möglichkeit der Identifizierung (wie sie diverse EU-Datenschutzbehörden beispielsweise in den "Google Analytics"-Entscheiden fälschlicherweise angenommen haben) nicht. Das Schweizer Bundesgericht hat dies schon Jahre zuvor für das DSG mit folgender Formel festgehalten (BGE 136 II 508, E. 3.2 ff.): Es genügt nicht, dass eine Identifizierung mit gewissem Aufwand objektiv möglich ist (objektive Komponente). Relevant ist auch, welches Interesse daran besteht, den zur Identifizierung nötigen Aufwand zu betreiben (subjektive Komponente). 

Das Interesse an der Identifikation

Dies scheint auf den ersten Blick nicht ganz deckungsgleich zu sein mit der jüngsten "VIN"-Rechtsprechung des EuGH. Demnach kommt es nur darauf an, ob die Stelle mit Zugang zu den Daten über Identifikationsmittel verfügt, die "vernünftigerweise … eingesetzt werden könnten" (C-319/22, Rz. 45, auf Englisch "means reasonably likely to be used") und als jemand gelten kann, "der bei vernünftiger Betrachtung über Mittel verfügt", die eine Identifikation ermöglichen (Rz. 46, auf Englisch "who reasonably has means enabling (identification)"), nicht aber, ob die Stelle diese Mittel auch einsetzt. Da jedoch eine objektivierte Betrachtung nach dem Massstab der Vernunft erforderlich ist, wird die Differenz in der Praxis gering bis irrelevant sein.

Auch wenn der EuGH in "VIN" nicht definiert hat, was er unter "vernünftigerweise" ("reasonably") versteht, so ist doch nach allgemeinem Sprach- und Sachverständnis klar, dass dabei das Interesse an der Identifikation entscheidend sein wird, da jedenfalls bei einer objektivierten Betrachtung (wie sie auch die DSGVO verlangt) eben dieses Interesse entscheidet, welchen Aufwand eine Stelle dafür betreibt. Wer kein Interesse an einer Identifikation hat, betreibt dafür – vernünftigerweise – auch keinen Aufwand, weil der Nutzen den Aufwand nicht rechtfertigt. Das schliesst zwar nicht aus, dass eine Stelle trotzdem an Angaben zur Identifikation einer betroffenen Person gelangen könnte. Trifft sie jedoch wirksame Abwehrmassnahmen, etwa indem sie diese Angaben löscht oder nur so verarbeitet, dass sie nicht zur Identifizierung genutzt werden können, wird dies bei der Frage berücksichtigt werden müssen, über welche Identifikationsmittel sie "vernünftigerweise" ("reasonably") verfügt. Es macht einen Unterschied, ob jemand eine Information in einer für die Identifikation verwendbaren Form verfügt oder ob er die Information zwar hat, sie aber praktischerweise nicht zur Identifikation einsetzen kann. Wenn sich die Information zur Identifikation irgendwo in einem grossen, ungeordneten Stapel an Unterlagen befindet, aber der Besitzer des Stapels keine Ahnung hat wo, wird sie nur dann vernünftigerweise zur Identifizierung gereichen, wenn sein Interesse daran gross ist, weil er nur dann den ganzen Stapel durchsuchen wird. Somit sind wir auch unter der DSGVO im Einklang mit der Formel des Schweizer Bundesgerichts, wonach es nicht nur auf das objektive Vorhandensein von Mitteln ankommt, sondern auch das subjektive Interesse zählt, sich die Mittel zu beschaffen und sie einzusetzen. 

Der "motivated intruder test" der UK-Aufsichtsbehörde ICO stellt analog bei der Frage, ob Daten für niemanden mehr personenbezogene Daten darstellen, also anonym sind, auf das Interesse an der Identifikation ab: Er fragt danach, ob ein "motivierter Angreifer" ohne Vorwissen mit legalen Mitteln und durchschnittlichen Fähigkeiten in der Lage wäre, die Personen zu identifizieren. Es setzt Interesse zwar voraus, aber das Ausmass des Interesses, diese Mittel zu beschaffen und einzusetzen, muss für jeden Einzelfall bestimmt werden. Hier zählen unter anderem Kriterien wie die Attraktivität der Daten. Haben Personen mit Zusatzwissen oder besonderen Fähigkeiten typischerweise kein Interesse am Einsatz dieser Mittel, kann dies gemäss ICO ebenfalls berücksichtigt werden.

Die Definition des personenbezogenen Datums ist also unter der DSGVO und dem DSG im Prinzip dieselbe. Sie hat zur Folge, dass die Frage, ob eine bestimmte Information ein personenbezogenes Datum darstellt, sich erstens nicht absolut und pauschal, sondern immer nur relativ in Bezug zu jenen Stellen beantworten lässt, die einen Zugang dazu haben, und für diese zweitens beurteilt werden muss, ob ihnen Identifikationsmittel in relevanter Weise zur Verfügung stehen, was wiederum von ihrem Interesse an einer Identifikation abhängt, das den Aufwand bestimmt, den sie für die Beschaffung und den Einsatz dieser Identifikationsmittel objektiv betreiben werden.

Anwendung auf grosse Sprachmodelle

Diese Erkenntnisse zum Begriff des personenbezogenen Datums lassen sich auf grosse Sprachmodelle anwenden und liefern entsprechende Antworten.

Einigkeit dürfte zunächst darüber herrschen, dass derjenige, der in das Innere eines grossen Sprachmodells blickt, darin keine personenbezogenen Daten sehen wird. Es enthält lediglich ein Wörterbuch der Tokens (also Wörter oder Wortstücke) und vor allem Zahlen. Wer also eine Datei mit einem LLM in die Finger bekommt und nicht weiss, wie er es zum Laufen bringt und auch kein Interesse daran hat, der hat keine personenbezogenen Daten (was nicht heisst, dass er nicht solche weitergeben kann, wenn er die Datei jemandem gibt, der dieses Wissen und Interesse hat).

Zwar gibt es mittlerweile Methoden, den "Wissens"-Inhalt eines LLMs auf andere Wege als durch seinen normalen Gebrauch zu ermitteln (siehe beispielsweise hier die Forschungsergebnisse von Anthropic), doch spielen diese beim praktischen Einsatz von LLM bisher keine Rolle. Wer beim Einsatz eines LLMs solche Methoden zum Blick ins Innere eines Sprachmodells nicht einsetzt, muss sich für die Frage, ob er mit seiner Anwendung dem Datenschutz untersteht, auch nicht an den Erkenntnissen messen lassen, die damit möglich wären. 

Ob ein grosses Sprachmodell Personendaten enthält, muss nach dem relativen Ansatz einzig aus der Sicht des Verwenders und derjenigen beurteilt werden, die Zugang zum Output haben. Denn nur sie erstellen den Input und können den daraus generierten Output allenfalls die betroffenen Personen identifizieren. Daher kann es auch nur auf die Art und Weise ankommen, mit welchen sie das betreffende Sprachmodell verwenden. Das wird typischerweise über die Eingabe eines Prompts, d.h. die Formulierung des Inputs sein. 

Ist von ihnen vernünftigerweise nicht mit einem Input zu rechnen, der einen Output mit Bezug auf bestimmte Personen generiert, oder haben jene mit Zugang zum Output vernünftigerweise nicht die Mittel, diese Personen zu identifizieren, dann führt die Verwendung des Sprachmodells in ihren Händen auch nicht zu personenbezogenen Daten und die Vorgaben des Datenschutz greifen in diesem Fall nicht. Ob das Modell unter anderen Umständen in der Lage wäre, personenbezogene Daten zu produzieren, spielt dann keine Rolle.  

Doch selbst wenn mit personenbezogenen Daten im Output zu rechnen ist (und daher der Umgang mit dem Output dem Datenschutz untersteht), sagt dies noch nichts darüber aus, ob solche Daten auch im Modell selbst enthalten sind. Diesbezüglich sind weitere Überlegungen nötig.

Faktenwissen durch Assoziierung im Trainingsmaterial

Zunächst gilt: Eine Maschine muss nicht personenbezogene Daten enthalten, um solche zu erzeugen. Ein Computerprogramm, dass Kombinationen von Vor- und Nachnamen nach dem Zufallsprinzip erfindet und damit einen Text mit einem erfundenen Datum als Geburtstag ausgibt, generiert personenbezogene Daten, jedenfalls wenn die Empfänger davon ausgehen, dass sich die Information tatsächlich auf eine natürliche Person bezieht. Wissen die Empfänger hingegen, dass es die Person nicht gibt, fehlt es bereits an einer betroffenen Person – und ohne eine solche gibt es auch keine personenbezogenen Daten.

Bei Sprachmodellen verhält es sich ähnlich, nur sind sie nicht von Menschenhand programmiert und viel komplexer. Der Output, den ein LLM erzeugt, ist als solcher ebenfalls nicht Teil des Modells selbst, sondern nur das Ergebnis seiner Verwendung – so wie der eben genannte Zufallsgenerator auch nicht Konserven der fertigen Texte enthält, die er ausgibt, sondern sie jedes Mal aus einem Vorrat an für sich nicht personenbezogenen Bausteinen neu erstellt, basierend auf einem Verständnis, wie Sprache funktioniert und welche Begriffe wie zusammenpassen. Ein LLM beinhaltet von seiner Bestimmung her Sprach- und nicht Faktenwissen. Trotzdem beinhaltet das Wissen darüber, wie Sätze erzeugt werden und wie Wörter und Sätze zu bestimmten Themen typischerweise lauten oder wie sie zusammenpassen, zwangsläufig auch das im Sprachwissen verkörperte Faktenwissen. Es ist im LLM als Assoziationen und Affinitäten mehr oder weniger diffus enthalten. Wird es mit dem richtigen Input getriggert, kann es sich im Output manifestieren, wenn die Wahrscheinlichkeiten stimmen. 

Wir müssen uns allerdings bewusst sein, dass ein LLM keine Datenbank ist, in welcher Fakten gespeichert sind, die sich zielsicher abrufen lassen, solange der richtige Abfragebefehl erfolgt. Ein LLM ist "nur" eine Textgenerierungsmaschine, die einen bestimmten Input gewissermassen zu vervollständigen versucht ("autocomplete") und hierbei Erfahrungswerte aus dem Training benutzt. Wer ein gängiges LLM fragt, wann Donald Trump geboren ist, wird die Antwort "Am 14. Juni 1946" enthalten. Wer fragt, wer am 14. Juni 1946 geboren wurde, wird die Antwort "Donald Trump" erhalten. Wer hingegen fragt, wer im Juni 1946 geboren wurde, wird je nach Modell mal Trump als Antwort erhalten, mal andere Personen, die nicht im Juni 1946 geboren wurden (aber dann Geburtstag hatten), mal andere, die tatsächlich im Juni 1946 geboren wurden. Die Modelle haben das Datum 14. Juni 1946, das Wort "Geburtstag" oder "geboren" und den Namen Donald Trump im Training sehr häufig miteinander assoziiert gesehen und gehen daher davon aus, dass diese Paarung in einem Text höchstwahrscheinlich zusammenpasst, d.h. sie eine gewisse Affinität zueinander aufweisen und daher die wahrscheinlichste Antwort auf den Prompt bilden. Mehr "wissen" die Modelle aber nicht. Insbesondere enthalten sie keine Tabelle, in welcher die Geburtstage von Promis nachgeschlagen werden können. Erst die richtige Kombination aus Input und den Zahlen im Modell (sowie gewisse weitere Parameter) ergibt den Output. Alles für sich alleine ergibt gar nichts, das dem nahe kommt.

Ein Sprachmodell enthält personenbezogene Daten …

Die praktische Schwierigkeit besteht für den Verwender eines LLM (und damit auch den Datenschutz) darin, dass er in aller Regel nicht weiss, welche Teile des Outputs Faktenwissen darstellt und was erfunden ist, weil ein LLM selbst ebenfalls nicht zwischen Fakt und Fiktion unterscheidet, sondern nur zwischen mehr oder weniger wahrscheinlichen Reaktionen auf den jeweiligen Input.

Ob ein System selbst Outputs mit sehr tiefen Wahrscheinlichkeiten ausgibt (und damit eher "halluziniert"), ob eine von ihm verwendete Assoziation aufgrund des Trainingsmaterials für das LLM zwar naheliegt (und daher aus seiner Sicht ein "guter" Output generiert wird), sie aber sachlich falsch ist (weil bereits das Trainingsmaterial falsch war), oder das System erkennt, dass es keine zuverlässige Antwort geben kann und es darum keine Antwort erzeugt, hängt von seinem initialen Training und seiner sonstigen "Programmierung" (wie etwa das sog. Alignment oder den System Prompt) ab.

Es gibt heute zwar Möglichkeiten, die Assoziationen und Affinitäten, die in einem LLM konserviert sind, sichtbar zu machen (siehe die oben zitierte Forschungsarbeit von Anthropic - sie sprechen von den sog. Features eines Modells). Ein LLM kann jedoch nicht wissen, ob seine Antwort sachlich richtig ist, weil es nicht in diesen Kategorien "denkt". Dass es seine Antwort trotzdem oft so formuliert, als verkünde es gesicherte Fakten, ist eine der wesentlichen Ursachen für die Probleme, die wir heute mit dem Einsatz von Sprachmodellen haben. Wir lassen uns durch selbstbewusste Formulierungen, die wie aus dem Munde eines Menschen klingen, sehr leicht täuschen.

Doch auch wenn Sprachmodelle technisch gesehen nicht zur Speicherung von Faktenwissen über einzelne, identifizierbare natürliche Personen und damit personenbezogene Daten angelegt sind, kann eine solche wie im Beispiel von Donald Trump gezeigt vorkommen. Selbst die Assoziation zwischen Trump, Geburtstag und 14. Juni 1946 wird in den jeweiligen Modellen nicht 100% sein, aber das ist letztlich auch nicht erforderlich. Es ist klar, dass diese Information und damit ein personenbezogenes Datum in den betreffenden Modellen irgendwie "drin" steckt. Darum ist die Aussage, dass die grossen Sprachmodelle keine personenbezogenen Daten enthalten, in dieser Pauschalität nicht richtig.

… aber nicht alle, die es im Training gesehen hat

Umgekehrt ist es auch unzutreffend anzunehmen, dass die grossen Sprachmodelle alle personenbezogenen Daten enthalten, die sie im Training "gesehen" haben. Das ist schon alleine mengenmässig nicht möglich: GPT3 braucht zum Beispiel 350 Gigabytes an Speicherplatz. Im Training gefüttert wurde es aber rund 45 Terabytes an Daten. Zwar umschreiben KI-Forscher das Training von Sprachmodellen gerne als ein "Komprimieren" der Trainingsinhalte, so dass sie ins Modell passen. Das kann aus der Sicht des Datenschutzes irrigerweise zur Annahme verleiten, dass der ursprüngliche Informationsgehalt und damit auch der Personenbezug erhalten bleibt. Das ist normalerweise nicht der Fall; im Falle von GPT3 fand also rein rechnerisch eine Komprimierung um das 128fache statt, wobei der Fokus auf dem Erhalt von Sprachwissen, nicht Faktenwissen lag.

Diesen Verdichtungsvorgang "überleben" grundsätzlich nur Informationen (z.B. Bezüge zwischen Wörtern mit gemeinsamen Bedeutungen), die entsprechend häufig in gleicher Weise vorkommen oder ggf. entsprechend speziell sind, um zu einer festen Assoziation bzw. Affinität zu werden. Anders ausgedrückt: Die Kompression ist sehr, sehr "lossy", d.h. es gehen die meisten Details verloren. Wieviel sich ein Sprachmodell ganz genau merkt, weiss auch die Wissenschaft nicht. Selbst wenn eine Information diesen Trainingsvorgang überlebt, ist nicht klar, in welcher Form und es ist auch nicht klar, ob der Inhalt richtig ist – etwa aufgrund von Fehlern im Trainingsmaterial oder weil die Assoziierung oder Affinität aufgrund anderer Umstände fehlerhaft erfolgte. Das Modell selbst kann nicht zwischen richtig und falsch, sondern nur zwischen mehr oder weniger starken Assoziationen und Affinitäten zwischen den einzelnen Elementen von Sprache unterscheiden, was in einer Wahrscheinlichkeitsverteilung resultiert, wenn das Modell gebeten wird, das nächste Wort für einen begonnenen Satz zu berechnen.

Nach dem Gesagten wird klar, warum es aus datenschutzrechtlicher Sicht für die Beurteilung eines Sprachmodells nicht wirklich entscheidend ist, ob im Trainingsmaterial ein bestimmtes Personendatum vorgekommen ist. Wenn überhaupt, wäre eine Relevanz nur dann gegeben, wenn gezeigt werden kann, dass die betreffende Information im Modell als solche als relevante Assoziation und Affinität überlebt hat, was vor allem von der Häufigkeit seines Vorkommens abhängt. Umgekehrt kann aus dem Umstand, dass ein bestimmtes Personendatum im Trainingsmaterial nicht vorgekommen ist, nicht geschlossen werden, dass der Trainingsvorgang im Modell keine personenbezogene Assoziation oder Affinität geschaffen hat, also beispielsweise zufälligerweise annimmt, dass zwischen einem Namen, dem Geburtstag und einem bestimmten Datum ein klarer Zusammenhang besteht: Wird eine Person in öffentlichen Texten stets zusammen mit einer anderen Person aufgeführt, kann dies zu einer wechselseitigen Assoziation von Attributen der beiden Personen führen. Der Beruf, Titel oder Wohnort der einen wird der anderen zugerechnet und umgekehrt.

In der Literatur wird immer wieder auf Studien und Methoden verwiesen (siehe für LLM z.B. hier und der dazu gehörende Blog-Beitrag hier), mit denen es gelingt festzustellen, ob bestimmte Informationen – auch personenbezogene Daten – für das Training eines Modells verwendet worden sind (die Rede ist meist von sog. Membership Inference Attacks). Es wird hervorgehoben, dass diese Angriffsmethoden eine Gefahr für den Datenschutz darstellen, weil damit Trainingsinhalte extrahiert werden können. Dies verkennt, dass bei den betreffenden Modellen die Trainingsinhalte sich beim passenden Input auch ohne "Angriff" im Output wiederfinden können, weil sie im Training vom Modell hinreichend häufig "gesehen" worden sind; es ist das Phänomen der "Memorization", d.h. das Modell merkt sich einen bestimmten Inhalt aus dem Training, wie etwa das Geburtsdatum von Donald Trump. Datenschutzrechtlich sind entsprechende personenbezogene Daten somit so oder so im Modell enthalten. Es geht somit um die Vertraulichkeit der Trainingsinhalte und nicht um die Datenschutzkonformität eines Modells im Allgemeinen. Sind die Trainingsinhalte nicht vertraulich (bzw. müssen sie nicht anonym bleiben), spielt die Möglichkeit solcher Angriffe keine Rolle. Was dies für das Training oder Fine-Tuning von Modellen bedeutet, werden wir in einem separaten Blog-Beitrag erläutern.

Ein Modell enthält nicht einfach das, was es erzeugt

Nach diesen Erläuterungen wollen wir nun die Frage beantworten, ob ein grosses Sprachmodell alle von ihm im Output erzeugten personenbezogenen Daten selbst ebenfalls enthält.

Die Antwort darauf ist "Nicht unbedingt". Verwenden wir dazu den Geburtstag einer anderen Person des öffentlichen Lebens, nämlich des Datenschutzaktivisten Max Schrems. Das ist kein Zufall, denn seine Organisation hat eine datenschutzrechtliche Beschwerde gegen OpenAI eingereicht, weil ihr Service "ChatGPT" angeblich das Geburtsdatum einer prominenten Person (Max Schrems?) falsch ausgegeben hat. In der Tat: Wird das OpenAI-Modell "GPT-4o" von OpenAI mit dem Input "Wann hat Max Schrems Geburtstag?" gefüttert, so gibt es bei einer Temperatur von 0.0 den 9. Oktober 1987 an, bei 0.5 den 14. Oktober 1987 und bei 1.0 den 3. Oktober 1987.

Diese Outputs zeigen, dass das Modell das Geburtsjahr und den Geburtsmonat von "Max Schrems" nach allgemeinem Verständnis zu "kennen" scheint (ob richtigerweise lassen wir hier offen), beim Tag aber "rät". Die Variationen im Tag indizieren, dass das Modell bezüglich "Max Schrems" keine Assoziation zu einem bestimmten Tag hat, die deutlich stärker wäre als jene zu anderen Tagen. Die Temperatur wirkt sich als Parameter auf die Wahrscheinlichkeitsverteilung der möglichen Antworten (hier betreffend die Tage im Oktober 1987) vor allem dann aus, wenn diese eher gleichmässig ist, also eben keine Zahl besonders wahrscheinlich ist. In der Praxis können solche "geratenen" Informationen auch durch leichte Variationen bei der Fragestellung ermittelt werden. So ergibt die leicht geänderte Frage "Was ist das Geburtsdatum von Max Schrems?" bei GPT-4o bei gleichbleibender Temperatur den 11. Oktober 1987, d.h. abermals ein anderes Datum. 

Fehlt dem Modell eine solche klare Assoziation, können wir folglich auch nicht den Schluss ziehen, dass die betreffende Information im Modell enthalten ist. Sie ist es in solchen Fällen normalerweise gerade nicht, d.h. genauso wenig, wie auch der eingangs zitierte Zufallsgenerator nicht die personenbezogenen Daten enthält, die er erzeugt. Dass das Modell trotzdem so tut, als wisse es, worüber es spricht, ist nicht das Ergebnis seines Wissens, sondern seiner Natur (wir werden separat erörtern, was das datenschutzrechtlich bedeutet). Während also bei "Donald Trump" im Modell die Bausteine für die Generierung eines Datums als Antwort auf die Frage nach seinem Geburtstag offenkundig so nahe beieinander liegen, dass sie im Output regelmässig vorkommen, hat es bei "Max Schrems" für den Tag keinen solchen Baustein in der Nähe, weshalb das Modell in der weiteren Umgebung zu "Max Schrems" und seinem Geburtstag nach einer Zahl suchen muss, bildlich gesprochen.  

Es zeigt eine Schwäche vieler heutiger Anwendungen von Sprachmodellen auf: Sie sind darauf getrimmt, immer eine Antwort zu liefern, auch wenn sie hierfür Antworten ausgeben müssen, die nicht sehr wahrscheinlich sind. In solchen Fällen füllen sie die Lücken in ihrem "Wissen" gewissermassen durch das Erfinden der entsprechenden Information. Die Informationen sind vielleicht nicht völlig aus der Luft gegriffen, aber was wir als gesicherte Basis bezeichnen würden, haben sie nicht. Solches Verhalten mag je nach Anwendung wünschenswert oder zumindest unproblematisch sein, hingegen ein Problem darstellen, wo Fakten erwartet oder deren Vorliegen angenommen werden. 

Eine mögliche Lösung ist der Einsatz von sog. Konfidenzschwellen, d.h. die Systeme werden so programmiert, dass sie entweder nur dann eine Antwort produzieren, wenn sich die Systeme ihrer vergleichsweise sicher sind. Oder aber sie geben an, wie sicher sie sich der einzelnen Aussagen sind. Im Falle deterministischer KI – also Systeme, die auf das Erkennen bzw. Klassifizieren bestimmter Dinge spezialisiert sind – wird mit solchen Werten standardmässig gearbeitet. Im Bereich generativer KI ist dies hingegen noch nicht sehr verbreitet. Wir sind der Ansicht, es sollte vermehrt mit solchen Angaben gearbeitet werden. Ein Chatbot kann etwa so programmiert werden, dass er nur dann eine Antwort liefert, wenn er sich ihrer vergleichsweise sicher ist. Wie hoch die Wahrscheinlichkeit sein muss, damit etwas als (vermeintlicher) Fakt gilt, statt (mutmasslicher) Fiktion, ist allerdings nicht klar.

Zudem steht auch diese Wahrscheinlichkeit nur im Verhältnis zum Trainingsmaterial: Kommt das Geburtsdatum von Max Schrems aus unserem Schulbeispiel in den Trainingsdaten genügend häufig falsch vor, wird das LLM es mit hoher Sicherheit nennen und damit trotzdem falsch liegen. An der datenschutzrechtlichen Qualifikation als personenbezogenes Datum ändert dies natürlich nichts; auch falsche Informationen können personenbezogene Daten sein (ob solche Information auch datenschutzrechtlich tatsächlich "unrichtig" sind, werden wir in einem späteren Blog-Beitrag behandeln).

Es kommt noch eine weitere Komplikation hinzu: Wird das Modell nicht nach dem Geburtstag von "Max Schrems", sondern  von "Maximilian Schrems" gefragt, wird jedenfalls GPT-4o auf Deutsch mit relativ hoher Wahrscheinlichkeit den 11. Oktober 1987 ausgeben. Bei diesem Namen ist die Assoziation zur "11" wesentlich stärker bei dessen Kurzform, und es kann durchaus geschlossen werden, dass dieses Datum tatsächlich im Modell enthalten ist, z.B. weil die Trainingsinhalte mit dem langen Namen von Herrn Schrems dieses Datum so nannten oder sonst einen besonderen Bezug zur Zahl "11" im Kontext von "Geburtstag" herstellten. Das Modell kann diese Dinge nicht ohne Weiteres unterscheiden. Für das Modell sind die Namen "Max Schrems" und "Maximilian Schrems" zwar stark miteinander assoziiert, aber bezüglich des Geburtsdatums führen sie zu unterschiedlich klaren Ergebnissen. Darum wird es sowohl beim Auskunfts- wie auch Berichtigungsrecht wichtig sein, mit solchen Unterschieden zu arbeiten.

Ein Punkt ist schliesslich noch zu beachten: Selbstverständlich kann nicht jeder Teil des Outputs, den ein Modell im Zusammenhang mit der Nennung einer bestimmten Person mit hoher Wahrscheinlichkeit generiert, als im Modell gespeichertes personenbezogenes Datum dieser Person gelten. Die hohe Wahrscheinlichkeit oder Zuversicht muss sich auf eine durch das Vorkommen der betroffenen Person (bzw. deren Identifikatoren wie Name, Telefonnummer oder E-Mail-Adresse) ausgelösten Information beziehen. Nur dann ist sie ein Indiz dafür, dass eine faktische Information und eine bestimmte natürliche Person (bzw. deren Identifikatoren) im Modell miteinander genügend nahe beieinander bzw. assoziiert sind, als dass sie als personenbezogenes Datum des Modells gelten können. Hat ein Modell den Auftrag, eine Kindergeschichte zu generieren, in welcher Donald Trump die Hauptrolle spielt, werden nur wenige Informationen im Output aus der Sicht des Modells eine engere Assoziierung zu ihm aufweisen, auch wenn das Modell den ganzen Output mit hoher Zuversicht produziert und der gesamte Output - die Kindergeschichte mit Trump - als personenbezogenes Datum von ihm erscheint. Um eine solche personenbezogene Assoziierung innerhalb des Modells zu ermitteln, wird das Modell somit in gewisser Weise "getriggert" werden müssen, um Einflüsse anderer Elemente im Output möglichst zu eliminieren. Wir werden uns diesem Thema in unserem Blog-Beitrag zum Auskunftsrecht bei Sprachmodellen näher widmen.

Der relative Ansatz beim Einsatz von Sprachmodellen

Mit dem Gesagten ist die Analyse, ob ein Sprachmodell personenbezogene Daten enthält, noch nicht abgeschlossen. Berücksichtigt werden auch, wie wahrscheinlich es überhaupt zu Input kommt, der personenbezogene Daten im Modell abzurufen vermag. Das ergibt sich aus dem relativen Ansatz und dem Umstand, dass der Input eines der "Mittel" ist, das es zur Identifizierung der im Modell allenfalls enthaltenen personenbezogenen Daten einer Person zwingend braucht. Gibt es einen Tresor voller personenbezogener Daten, aber hat keiner mit Zugang zum Tresor den Schlüssel, liegen für diese Stellen auch keine personenbezogenen Daten vor bzw. sie haben im Umgang mit dem Tresor keine Datenschutzpflichten (abgesehen möglicherweise von der Pflicht, ihn keiner unberechtigten Person mit Schlüssel zugänglich zu machen). Bei einem grossen Sprachmodell übernimmt, wie gezeigt, der Input des Verwenders die Funktion dieses Schlüssels. Ergo liegen in Bezug auf das Sprachmodell keine personenbezogenen Daten vor, solange nicht vernünftigerweise mit einem Input gerechnet werden muss, der im Modell enthaltene personenbezogene Daten aus diesem in Form von Output zu extrahieren vermag.

An diesem Punkt können wir auf die obige Erkenntnis zurückgreifen, dass für die Beantwortung der Frage, ob "vernünftigerweise" bzw. nach "allgemeinem Ermessen wahrscheinlich" mit solchem Input gerechnet werden muss (und auch der Möglichkeit der Identifizierung der betroffenen Person) nicht nur die objektive Möglichkeit der Verwender des Modells zählt, sondern auch deren subjektives Interesse, solchen Input zu formulieren. Das macht in der Praxis einen grossen Unterschied, denn rein objektiv kann jeder Verwender eines Modells im Prinzip jeden Input erzeugen - er braucht ihn ja nur einzutippen. In der Praxis tun wird er das aber nur, wenn ein hinreichendes Interesse daran besteht.

Wer also ein Sprachmodell in kontrollierter Umgebung mit Prompts einsetzt, die nach allgemeinem Ermessen wahrscheinlich nicht zur Generierung von personenbezogenen Daten führt, weil er daran gar kein Interesse hat (weil es z.B. nicht zu seinem Use Case passt), muss sich weder bezüglich des Sprachmodells noch des Outputs betreffend Datenschutz Gedanken machen. Daran würde sich auch dann nichts ändern, wenn ein Input zufälligerweise trotzdem zu einem Output führt, der als personenbezogenes Datum betrachtet werden könnte, weil der Verwender des Modells dieses erstens nicht ohne Weiteres als solches anerkennen würde (wie beim Geburtstags-Zufallsgenerator) und zweitens nur der Einsatz von Mitteln zur Identifizierung (wozu hier auch der Prompt zählt), die nach allgemeinem Ermessen wahrscheinlich zu personenbezogenen Daten führen. Das setzt eine gewisse Vorhersagbarkeit voraus, die hier gerade nicht gegeben ist.

Ähnlich wird es sich jenem Unternehmen verhalten, das zwar Sprachmodelle zur Erzeugung von Inhalten mit personenbezogenen Daten benutzt, diese Daten aber nicht aus dem Modell selbst stammen, sondern aus dem Input, sei es aus dem Prompt des Benutzers oder der Benutzerin oder beigezogenen weiteren Datenquellen im Rahmen einer Anwendung mit Retrieval-Augmented Generation (RAG). In diesen Fällen dient das Sprachmodell lediglich zur Verarbeitung von Sprache und es ist gerade nicht Sinn und Zweck seiner Verwendung, den Output um Faktenwissen bzw. personenbezogene Daten aus dem Modell zu ergänzen.

Umgekehrt hat ein Anbieter wie OpenAI, der sein LLM einer beliebigen Zahl von Personen zur Verfügung stellt, auch mit einer entsprechenden Vielfalt an Prompts zu rechnen und muss daher davon ausgehen, dass damit entsprechend viele personenbezogene Daten aus dem Modell selbst generiert werden. Ob er mit beliebigen Prompts rechnen muss, ist bisher nicht geklärt. Konsequenterweise wird das Kriterium der "nach allgemeinem Ermessen wahrscheinlich" verfügbaren Mittel zur Identifizierung einer Person aber selbst bei breit genutzten Chatbots wie "ChatGPT" oder "Copilot" nicht jeden beliebigen Prompt umfassen. So wird ein solcher Anbieter zwar davon ausgehen müssen, dass seine Benutzerinnen und Benutzer den Chatbot zu Personen des öffentlichen Lebens befragen werden. Wenn wir den Standard "nach allgemeinem Ermessen wahrscheinlich" ernst nehmen, werden sie aber nicht damit rechnen müssen, dass die Benutzer damit Faktenwissen zu beliebigen anderen Personen abfragen. Konsequenterweise könnten sie sich auf den Standpunkt stellen, dass ihre Modelle keine personenbezogenen Daten zu diesen anderen Personen enthalten - natürlich nur, bis gezeigt wird, dass es doch zu solchen Prompts kommt. Für solche Anbieter stellen vorliegenden Erkenntnisse daher nur beschränkt eine Erleichterung dar. 

Max Schrems ist eine öffentliche Person. Wenn er sich also darüber beschwert, dass sein Geburtsdatum in ChatGPT falsch enthalten ist, wäre das Modell in der Tat auf diesen Vorwurf hin zu prüfen. Dabei würde, wie gezeigt, bei GPT-4o vermutlich herauskommen, dass das Geburtsdatum von "Max Schrems" als solches gar nicht wirklich enthalten ist, weil es diesbezüglich an einer klaren Assoziierung im Modell fehlt. Eine solche besteht offenkundig nur bezüglich Geburtsmonat und Geburtsjahr.

Davon zu trennen ist, wie erwähnt, der Output, den der Chatbot auf die Frage nach dem Geburtsdatum von Max Schrems hin generieren würde. Hierbei wird es sich nach dem Gesagten in jedem Fall um personenbezogene Daten handeln, weil mit einer solchen Frage bei einem öffentlichen Chatbot wie "ChatGPT" und "Copilot" zu rechnen ist, auch wenn der Betreiber des Chatbots sie selbst nicht stellen würde. Es genügt, dass seine Benutzerinnen und Benutzer es tun und sein System ihnen entsprechende Daten bekannt gibt. Ob diese datenschutzrechtlich bei inkorrektem Geburtsdatum von Herrn Schrems tatsächlich als falsch zu gelten haben, werden wir in einem separaten Blog-Beitrag erörtern.

Zusammenfassend kann somit ein bestimmter Output ein personenbezogenes Datum sein, das unterliegende grosse Sprachmodell dieses jedoch nicht enthalten.

Schlussfolgerungen für grosse Sprachmodelle

Um zu ermitteln, ob und welche personenbezogenen Daten ein Sprachmodell  nach DSGVO und DSG enthält, sind somit zusammenfassend folgende Schritte gedanklich vorzunehmen:

1. Wer formuliert im konkreten Fall den Input für das verwendete grosse Sprachmodell und wer hat Zugang zu dessen Output?
2. Ist es nach "allgemeinem Ermessen wahrscheinlich" bzw. muss "vernünftigerweise" damit gerechnet werden, dass (i) diese Personen das Sprachmodell mit Inputs nutzen, welche das Modell Outputs mit personenbezogenen Daten erzeugen lässt, die nicht aus dem Input selbst stammen, und (ii) jene mit Zugang zu solchen Outputs die davon betroffenen Personen identifizieren können. Wird diese Wahrscheinlichkeit beurteilt, müssen die Interessen dieser Personen, einen entsprechenden Input zu verfassen oder die betroffenen Personen zu identifizieren berücksichtigt werden, nicht nur ihre objektive Fähigkeit, dies zu tun.
3. Soweit das Modell solche Outputs mit personenbezogenen Daten zu einer bestimmten Person generiert, variieren diese, wenn der Input zu dieser Person und die Temperatur ebenfalls variiert wird oder bleiben sie inhaltlich immer gleich? In letzterem Falle deutet dies darauf hin, dass sie tatsächlich im Modell mit einer starken Assoziation bzw. Affinität zu betroffenen Person enthalten sind und es sich bei den betreffenden Daten daher nicht bloss um "Lückenfüller" mangels besserer Alternativen handelt. Dann sind sie mutmasslich im Modell als personenbezogene Daten enthalten und im Output nicht nur zufällig oder aus anderen Gründen, die nichts mit der betroffenen Person zu tun haben, enthalten. 

Da die Wahrscheinlichkeiten in Schritt 2 und 3 kumulativ gelten, ist normalerweise die Gesamtwahrscheinlichkeit des Vorhandenseins von personenbezogenen Daten bestimmter Personen im Modell selbst entsprechend gering. Sie ergibt sich aus der Multiplikation der beiden Einzelwahrscheinlichkeiten. Die vorstehenden Prüfschritte können beispielsweise für eine datenschutzrechtliche Risikobeurteilung benutzt werden, wenn ein Unternehmen den Einsatz eines Sprachmodells plant und darlegen will, dass die in einem Modell allenfalls enthaltenen personenbezogenen Daten für das Unternehmen kein Risiko darstellen, weil es nicht zu deren Abruf kommt.

Umgekehrt wird für die Geltendmachung von datenschutzrechtlichen Ansprüchen gegen ein Sprachmodell wegen darin enthaltenen personenbezogenen Daten eine betroffene Person oder Aufsichtsbehörde zeigen müssen, dass vom im konkreten Fall ins Auge gefassten Anwenderpublikum des Sprachmodells (Schritt 1) nach allgemeinem Ermessen wahrscheinlich ein Input verwendet wird, der aus Sicht seiner Verwender personenbezogene Daten zu ihr im Output generiert (Schritt 2) und die streitgegenständliche Information in Bezug auf die betroffene Person nicht erfunden ist, sondern aus dem Modell stammt (Schritt 3).   

In den weiteren Blogs werden wir erläutern, welche Auswirkungen dies auf die Frage hat, wie betroffene Personen Auskunft über die über sie in einem Modell verarbeiteten personenbezogenen Daten erhalten können und wie es sich mit der Richtigkeit von Outputs bzw. deren Korrekturmöglichkeiten verhält.

David Rosenthal

PS. Vielen Dank an Imanol Schlag vom ETH AI Center der Review des Beitrags in technischer Hinsicht.  

Einige Worte zur These "LLM enthalten keine personenbezogenen Daten" Fast zeitgleich zu unserem Blog-Beitrag hat die Hamburgische Datenschutzbehörde ein Diskussionspapier publiziert, in welchem sie zum Ergebnis kommt, dass grosse Sprachmodelle per se keine personenbezogenen Daten enthalten und daher diesbezüglich auch keine Betroffenenrechte gelten. Zum selben Zeitpunkt ist von Flemming Moos in Computer & Recht ein Beitrag erschienen, der dieselbe Haltung vertritt. Die dänische Datenschutzaufsicht hat bereits einen ähnlichen Standpunkt vertreten. Eine etwas differenzierte Sicht beschreibt Marvin Bartels in einem Beitrag. Es ist erfreulich, dass mit solchen Beiträgen eine Diskussion stattfindet, die auch die technischen Eigenheiten von grossen Sprachmodellen aufgreift. Die von der Hamburger Behörde vertretene Position greift allerdings in verschiedener Hinsicht zu kurz und überzeugt nicht: Das Papier der Behörde fokussiert sich auf einzelne Trainingsdokumente statt auf die insgesamt in einem LLM gespeicherten Informationen. Sie argumentiert, es sei nicht möglich, einzelne Trainingsdokumente (mit personenbezogenen Daten) aus dem LLM zu extrahieren, weil ein LLM nur aus aggregierten Informationen über diese besteht. Darum könnten auch keine personenbezogenen Daten im Modell sein. Damit übersieht sie, dass personenbezogene Informationen in die aggregierten Informationen übernommen sein können, wenn sie genügend häufig in den Trainingsdokumenten vorkommen. Es trifft (wie wir auch schreiben) zu, dass dies bei den meisten Informationen nicht der Fall ist, aber es kommt vor. Der in unserem Blog diskutierte Geburtstag von Donald Trump ist ein Beispiel; er kann über das API von GPT-4o direkt aus dem LLM extrahiert werden (ohne Verwendung von ChatGPT oder Copilot). Diese Memorisierung von personenbezogenen Daten (nicht einzelnen Trainingsdaten) kommt vor. Sie setzt voraus, dass eine bestimmte Information in einer grösseren Zahl von Trainingsdaten vorhanden ist, was vor allem bei Personen des öffentlichen Lebens zutrifft, oder jenen, die selbst viel publizieren. Daher sind primär sie betroffen. Die Gegenthese beschäftigt sich nur mit den einzelnen Tokens statt die gesamte Funktion des Modells zu betrachten. So sehen wir den Wald vor lauter Bäumen nicht mehr. Ein LLM stellt Bezüge nicht nur über Vektoren im Embedding-Raum her, sondern ebenso über non-lineare Funktionen (neuronale Netze) und Funktionen wie den Attention-Mechanismus. Auf diese Weise werden Informationen über zahlreiche Ebenen gespeichert. Das Papier der Behörde betrachtet nur eine. Für einen Laien klingen die Begründungen der Gegenthese so zwar überzeugend, greifen aber viel zu kurz (wir empfehlen hier die Lektüre unseres Blog-Beitrag Nr. 17, welcher erläutert, was in einem LLM vor sich geht). Es wird argumentiert, man könne einem einzelnen Token und dessen Embedding keine Einzelinformationen über natürliche Personen entnehmen. Das ist natürlich richtig, aber nicht der Punkt: Nur weil eine Information nicht aus einzelnen Elementen für sich herauslesbar ist, sondern sich nur aus dem Verbund der Teile ergibt und wir heute nicht genau verstehen, wo und wie sie überall gespeichert ist und wie das Modell sie abruft, hört diese Information nicht auf zu existieren. Auch wir Menschen haben Wissen, auch wenn wir nicht genau verstehen, wo einzelne Informationen wie in unserem Gehirn gespeichert sind. Nur, weil etwas eine Black-Box ist, bedeutet dies nicht, dass dieses Ding keine personenbezogenen Daten speichern kann. Nehmen wir wieder den Geburtstag von Donald Trump als Beleg. GPT-4o liefert diese (zweifellos personenbezogene) Information zuverlässig, wenn es gefragt wird; besondere Tricks sind nicht erforderlich. Die Notwendigkeit eines technischen Prozesses, um gespeicherte Informationen für uns Menschen lesbar zu machen, schliesst das Vorhandensein solcher Informationen ebenfalls nicht aus, und zwar auch dann nicht, wenn sie in den gespeicherten Daten nur auf einer Meta-Ebene abgelegt sind. Die in einer JPEG-Bilderdatei mit einem gescannten Lebenslauf einer Person gespeicherten Zahlen sind ein Beispiel. In der Datei selbst sind nur die Daten der Pixel vorhanden. Niemand wird in diesen Daten personenbezogene Daten erkennen können. Es ist erst notwendig, dass ein Bildbetrachterprogramm diese Daten in Pixel umsetzt und aus den Pixeln ein Bild generiert, damit wir den Text und damit auch die personenbezogenen Daten lesen können. So verhält es sich auch mit einem Sprachmodell, mit dem Unterschied, dass das Zusammensetzen der Informationen als eine Art Schlüssel den Prompt erfordert und der Vorgang sehr viel komplexer ist. Auch diese Meta-Ebene berücksichtigt die Gegenthese nicht. Es wird argumentiert, ein LLM enthalte deshalb keine personenbezogenen Daten, weil es sich nicht um eine Wiedergabe von Trainingsdaten handle, sondern ein LLM Inhalte neu generiere. Darauf kann es aber nicht ankommen. Eine Graph-Datenbank, um ein Beispiel zu nennen, muss die Ergebnisse, die sie auf eine Abfrage hin liefert, auch aus verschiedensten Teilen zusammensetzen, weil sie Informationen in Form von miteinander vernetzten Informationsbruchstücken gespeichert hat. Die Antwort auf die Abfrage wird zwar neu erstellt, basiert jedoch auf Einzelinformationen, die in der Datenbank gespeichert sind, dass deren Wissen bildet. Warum solches Wissen nicht ein personenbezogenes Datum sein können soll, nur weil das, was in die Datenbank gefüttert wurde, nicht in derselben Form ausgegeben wird, ist für uns nicht ersichtlich. Es wird die Ansicht vertreten, dass, nur weil die in einem LLM gespeicherten Informationen mehr oder weniger wahrscheinlich Informationen sind, die sich auf eine bestimmte Person beziehen, es keine personenbezogenen Daten sein können. Das überzeugt nicht. Ist die Wahrscheinlichkeit genügend hoch, dass die Kombination aus einem bestimmten Input ("Wann hat Donald Trump Geburtstag?") und den im Modell enthaltenen Informationen der Output "Donald Trump hat am 14. Juni 1946 Geburtstag" resultiert, was hier selbst bei variierendem Input und variierender Temperatur der Fall ist, dann muss diese Information im Modell enthalten sein. Woanders kann sie nicht herkommen. Ab welchem Grad der Wahrscheinlichkeit eine Information zur hinreichenden Gewissheit wird, ist eine Diskussion, die hier nur beschränkt weiterführt. Im Falle von GPT-4o genügt es, dass "Donald Trump" und "Geburtstag" untrennbar mit dem 14. Juni 1946 verknüpft sind. Das ist auch überall sonst im Datenschutz (und restlichen Leben) so: Überwacht ein Arbeitgeber die Aktivitäten der Geräte seiner Mitarbeitenden anhand deren IP-Adresse, käme auch niemand auf die Idee, diese nicht als personenbezogene Daten eben dieser Mitarbeitenden zu betrachten, auch wenn es nicht ausgeschlossen ist, dass der Computer eines Mitarbeitenden ausnahmsweise von einer anderen Person verwendet wird. Nur weil es lediglich höchstwahrscheinlich ist, dass sich die Log-Einträge mit der IP-Adresse auf den Mitarbeitenden beziehen, fällt ihr Personenbezug nicht weg. Selbst das Beweismass von Fakten vor Gericht verlangt keine absolute Gewissheit. Da können für den Datenschutz keine höheren Standards gelten und tun es auch nicht. So ist auch die Aussage, ein personenbezogenes Datum, bei dem nicht für jedermann hundertprozentig und absolut klar ist, auf wen es sich bezieht, sei kein solches, jedenfalls im vorliegenden Kontext nicht stichhaltig. Mit diesem Argument wird versucht zu begründen, dass bei einem LLM nie ganz klar sei, auf welche Person sich eine Information beziehe. Doch: Wird eine Information vom Empfänger der Information einer bestimmten Person zugeordnet, genügt dies aus Sicht des Datenschutzes. Dass es womöglich noch andere (z.B. gleichnamige) Personen gibt, ändert daran nichts. Es zeigt aber, dass es, wie von uns oben vertreten, wichtig ist, von wem ein LLM verwendet wird und wer Zugang zum Output hat, und zu verstehen, wie diese den Output auffassen. Der Empfängerhorizont ist im Datenschutz entscheidend: Darum bezieht sich das vorstehend zitierte Geburtsdatum von Donald Trump auf den US-Politiker mit diesem Namen – und nicht auf den gleichnamigen Onkologen, den es in den USA ebenfalls gibt. Wenn uns ein Sprachmodell mit Klarheit sagt, wann Donald Trump Geburtstag hat, dann ordnen wir diese Information dem US-Politiker zu, auch wenn wir uns nicht absolut sicher sein können, dass sich diese Information tatsächlich auf ihn bezieht. Sie wird damit zu seinem personenbezogenen Datum. Sehen wir auf einem Überwachungsvideo eine Person und sind wir der Ansicht, es handle sich um eine bestimmte Person, dann verarbeiten wir personenbezogenen Daten eben dieser Person, und zwar auch dann, wenn wir uns irren. Wir haben auch den Eindruck, dass es Missverständnisse gibt, was zum Modell wie GPT-4o gehört und was zu den Anwendungen wie ChatGPT, welche ein Modell nutzen. Alle von uns genannten Beispiele stammen nicht von ChatGPT, sondern werden direkt vom GPT-4o-Modell von OpenAI erzeugt; das API gehört gemäss EU AI Act noch zum Modell. Das Modell ist nämlich nicht nur die Sammlung der Modell-Parameter (wie die Gewichte oder die Parameter der neuronalen Netze), sondern beinhaltet auch das System, welches diese mit dem Prompt kombiniert und ihn verarbeitet, um einen Output zu erzeugen. Dafür braucht es ChatGPT nicht. Zu sagen, die personenbezogenen Daten seien in ChatGPT gespeichert und nicht im Modell ist daher schlicht falsch. ChatGPT kontrolliert und verarbeitet lediglich den Input und den vom Modell erzeugten Output. Die diversen Stellungnahmen widmen sich den diversen Methoden von Privacy-Attacken auf LLM zur Extraktion von personenbezogenen Daten als vermeintliches Gegenargument zu ihren Thesen und argumentieren, dass diese nicht relevant sind, weil zu aufwändig oder zu kompliziert. Auch dies geht an der Sache vorbei, denn es braucht keine Privacy Attacke, um personenbezogene Daten aus dem Modell zu extrahieren. Ein simpler Prompt genügt, wie gezeigt und wie jeder aus der Erfahrung weiss. Die Argumente sind auch deshalb irrelevant, weil die Privacy Attacken (wie auch von uns erläutert) darauf abzielen, personenbezogene Daten aus dem Training ersichtlich zu machen. Das ist höchstens beim Training (inkl. Fine Tuning) mit vertraulichen Daten das Problem, aber davon sprechen wir hier nicht. Wir sprechen darüber, ob personenbezogene Daten im Modell selbst abgebildet sind, ganz gleich, wie sie entstanden sind. Es ist, wie wir schreiben, zum Beispiel denkbar, dass ein Training personenbezogene Daten in einem LLM erzeugt, die falsch sind und als solche in den Trainingsdokumenten gerade nicht vorgekommen sind. Es spielt also überhaupt keine Rolle, wie erlaubt oder aufwändig solche Angriffe sind. Sie sind nicht der entscheidende Faktor. Entscheidend ist nur, ob es zum Prompt kommt, der die personenbezogenen Daten aus dem Modell abruft. Diese Frage kann nur aus der Perspektive desjenigen beantwortet werden, dem ein Modell zur Verfügung steht bzw. der es nutzt oder es bereitstellt. So wird dasselbe Modell im Anwendungsfall A, B und C keine personenbezogenen Daten enthalten, im Anwendungsfall D jedoch schon, weil dort (und nur dort) mit entsprechenden Prompts zu rechnen ist. Diese Differenzierung ergibt sich unmittelbar aus dem relativen Ansatz, den der EuGH in "VIN" wieder bestätigt hat. Auch diese Unterscheidung machen die Stellungnahmen nicht, obwohl sie angesichts der Rechtsprechung essenziell ist. Die Gegenthese stellt schliesslich nur darauf ab, ob die Inhalte eines LLM eine bestimmte Person identifizieren, aber sie prüft nicht, ob sie mit zusätzlichen Mitteln identifizierbar wird. Im Hamburger Papier wird im Wesentlichen argumentiert, man sehe den Zahlen und den Tokens die Person nicht an, und weil es am notwendigen Identifier fehle, scheide ein Personenbezug von vornherein aus. Das ist abermals zu kurz gegriffen: Wurde eine personenbezogene Information im Training genügend oft gesehen, kann sie mit dem richtigen Prompt lesbar gemacht werden. Der Prompt wird so zum Mittel der Identifikation. Er ist im übertragenen Sinn die Schablone, die auf das Modell gelegt wird, und dafür sorgt, dass die entsprechenden Tokens in der richtigen Reihenfolge "aufleuchten" und im vormaligen Zahlensalat plötzlich eine lesbare Information erkennbar wird, die dann in den Output überführt werden kann. Sind die getriggerten Assoziationen genügend stark, werden sie auch bei unterschiedlich formulierten Prompts derselben Fragestellung immer zum selben Ergebnis führen. So kann eine Information, die im Prompt nicht schon enthalten ist, mit dessen Hilfe aus dem Modell abgerufen werden – wie eben beispielsweise das Geburtsdatum von Donald Trump. Wir haben ein experimentelles Tool entwickelt, mit welchem mit den GPT-Modellen Tests auf solche starken Assoziationen durchgeführt werden können. Wir werden es in unserem Beitrag über das Auskunftsrecht bei LLMs vorstellen. Zu sagen, es gäbe in einem LLM nichts, das mindestens funktional einem Identifier entspricht, ist aus diesen Gründen zu kurz gegriffen. Die Natur eines LLM bringt es zwar mit sich, dass dies nicht einfach eine Zahl oder ein Wort ist, sondern letztlich ein komplexes Muster, das sich aus einer Kombination zahlenreicher Assoziationen ergibt, die ein LLM speichert. Wir Menschen können es möglicherweise nicht erkennen, aber das kann keine Rolle spielen, wenn das Modell dies für uns tut, wenn wir ihm mit dem Prompt den nötigen Trigger liefern und es daraufhin die betreffenden Informationen für uns lesbar macht, indem es sie in den Output kopiert. Wollen wir der Technik von LLMs gerecht werden, müssen wir hier über unsere bisherigen Vorstellungen – etwa zur Frage, was ein "Identifier" ist – auf die neue Welt anwenden, was wie gezeigt ohne Weiteres geht. Es spricht nichts dagegen, dass dieser Identifier ein multidimensionales Muster ist, das wir selbst womöglich gar noch nicht richtig verstehen. Das steht auch nicht im Widerspruch zur Rechtsprechung. Die DSGVO verlangt zur Herstellung des Bezugs und einer Information nicht einmal zwingend eine Kennung. Sie spricht in Art. 4 Ziff. 1 ausdrücklich davon, dass die Kennung nur eine von mehreren Möglichkeiten für diese Zuordnung ist. Wesentlich ist nur die Zuordnung. Auch darum greift die Gegenthese zu kurz. Zusammenfassend zeigen diese Ausführungen, dass die Aussage, ein Sprachmodell kann aus Prinzip keine personenbezogenen Daten im Sinne der DSGVO enthalten, nicht belastbar ist. Es ist aus unserer Sicht stattdessen ein differenzierter Ansatz erforderlich, der, wie in unserem Beitrag gezeigt, den jeweiligen Anwendungsfall berücksichtigt, den Kreis derjenigen, die ein LLM verwenden, und vor allem die Prompts, die benutzt werden, weil sie das Mittel sind, mit denen Informationen im Modell zu personenbezogenen Daten werden können – und die betroffenen Personen identifizieren. Darum ist auch relevant, wie wahrscheinlich es ist, dass in einem bestimmten Use Case solche Prompts zur Anwendung kommen. Auch wir kommen zum Schluss, dass in vielen, wenn nicht sogar den meisten Anwendungen die verwendeten Sprachmodelle keine personenbezogenen Daten enthalten. Die Möglichkeit aber pauschal zu negieren, tut der Sache keinen Gefallen. Wir können schlicht nicht ignorieren, dass beispielsweise GPT-4o "weiss", wann etwa Donald Trump geboren worden ist und es uns auch sagt. Wir können höchstens sagen, dass vernünftigerweise niemand das Modell danach fragen wird - jedenfalls in den meisten Use Cases. Und genau das ist unser Punkt. Mehr dazu in unserem Beitrag oben. Im Falle der DSGVO kann dies so formuliert werden: Mit dem Training eines Modells werden jene personenbezogenen Daten, die genügend häufig in verschiedenen Teilen der Trainingsdaten vorkommen, als aggregierte Informationen im Modell abgelegt. Sie können als pseudonymisierte Daten im Sinne von Art. 4 Ziff. 4 DSGVO betrachtet werden, da es ohne Zusatzinformationen nicht möglich ist, den Personenbezug herzustellen. Solange ein Modell gespeichert oder sonst verarbeitet wird und vernünftigerweise nicht damit gerechnet werden muss, dass das Modell in Betrieb genommen und mit einem Prompt versorgt wird, der diese Informationen aus dem Modell holt, liegen keine personenbezogenen Daten vor. Es verhält sich wie mit einer verschlüsselten Datei, für welche der Schlüssel nicht vorliegt. Wird jedoch ein solcher Prompt eingegeben, so stellt dieser das Mittel dar, mit welchem die im Modell über eine betroffene Person enthaltenen Informationen aktiviert, also sichtbar werden und sie damit die Person, auf welche sich diese Informationen beziehen, identifizieren. Für uns lesbar werden diese Informationen, indem das Modell gestützt darauf einen Output generiert. Die primäre Herausforderung besteht darin zu erkennen, wo ein wirklicher Bezug besteht, da das Modell auch ohne Bezug einen Output generieren wird – aber eben mit erfundenen bzw. wenig wahrscheinlichen Daten. Muss ein Verantwortlicher in einem Anwendungsfall vernünftigerweise mit solchen Prompts rechnen, so enthält das LLM in seinem Fall entsprechende personenbezogenen Daten. Er muss sich folglich bei seinem Einsatz des LLM um die Einhaltung der Vorgaben der DSGVO bemühen – einschliesslich der Beantwortung von etwaigen Auskunftsersuchen.   Siehe dazu auch unsere Illustration hier. Eine weitere Kritik zum Hamburger Papier hat David Vasella in seinem Blog datenrecht.ch verfasst. Er kommt zum Schluss: "Insgesamt wirken die Ausführungen aber ergebnisgeleitet. Eine solche Abgeklärtheit sucht man bei Behörden sonst jedenfalls oft umsonst – Pate der Thesen war vielleicht auch die Furcht, dass LLMs andernfalls faktisch verboten sein könnten." 18./22. Juli 2024 23. Juli 2024: Siehe die technischen Überlegungen und das Experiment von Christian Bennefeld hier.

Dieser Beitrag ist Teil einer Serie über den verantwortungsvollen Einsatz von KI im Unternehmen: Teil 1: KI am Arbeitsplatz: Die drei wichtigsten Punkte für Mitarbeitende Teil 2: Gängige KI-Tools: Wie steht es um den Datenschutz? Teil 3: KI: 11 Grundsätze – und eine Weisung für Mitarbeitende Teil 4: So beurteilen Sie Risiken von kleinen und grossen KI-Projekten Teil 5: KI-Governance im Unternehmen – wer ist verantwortlich? Teil 6: Die andere Seite der Medaille: Wo wir KI vor Angreifern schützen müssen Teil 7: Der EU AI Act – und was er für die meisten Unternehmen bedeutet  Teil 8: KI im Finanzinstitut – Chancen und Herausforderungen Teil 9: KI im Marketing: 4 wettbewerbsrechtliche Fallstricke Teil 10: Urheberrecht und KI: Verantwortlichkeit von Anbietern und Nutzern  Teil 11: Fair Play mit KI: Wie Sportorganisationen Athletendaten nutzen dürfen Teil 12: Datenfutter für KI: So gelingt die Kommerzialisierung von Datensätzen Teil 13: KI im Personalwesen  Teil 14: Urheberrecht und KI: Schutzmassnahmen in der Praxis Teil 15: Worauf rechtlich beim Einsatz von KI-Providern zu achten ist Teil 16: Wie Unternehmen beim Einsatz von KI Transparenz gewährleisten können  Teil 17: Was in einem KI-Modell steckt und wie es funktioniert Teil 18: Die wichtigsten Compliance-Vorgaben für KI Teil 19: Sprachmodelle mit und ohne personenbezogene Daten Teil 20: Risiko-basierter Ansatz: Nicht alle KI-Anwendungen bergen hohe Risiken Teil 21: Das Auskunftsrecht bei grossen Sprachmodellen Teil 22: Leitsätze für den Einsatz künstlicher Intelligenz in Finanzinstituten (FINMA) ... wird fortgesetzt

Wir unterstützen Sie bei allen Fragen zu Recht und Ethik beim Einsatz von künstlicher Intelligenz. Wir reden nicht nur über KI, sondern setzen sie auch selbst ein. Weitere Hilfsmittel und Publikationen von uns zum Thema finden Sie hier.