Teil 21: Das Auskunftsrecht bei grossen Sprachmodellen

Hier klicken für eine grössere Fassung.

Diese Assoziationen und Affinitäten können mit bestimmten Methoden zwar teilweise sichtbar gemacht werden (siehe beispielsweise hier die Forschungsergebnisse von Anthropic), aber es sind Assoziationen und Affinitäten einzelner Bruchstücke von Sprache und jedenfalls zum heutigen Zeitpunkt weder geeignet, Auskunft darüber zu geben, was ein Sprachmodell an personenbezogenen Daten sich im Training "gemerkt" hat, noch was es genau an personenbezogenen Daten enthält oder produzieren wird, wenn es mit einem bestimmten Input in der einen oder anderen Weise angestossen wird. Das mag sich in Zukunft ändern, aber im Moment helfen uns diese Methoden zur vernünftigen Beantwortung von Auskunftsersuchen nicht weiter.

Das sehen derzeit, soweit ersichtlich, auch die Datenschutzbehörden so. So schreibt die französische CNIL in einem Beitrag, dass es heute für einen Verantwortlich noch nicht möglich erscheint, jene Gewichte (d.h. der Zahlen) eines Modells zu identifizieren, die sich auf eine bestimmte Person beziehen. Sie weist aber (zutreffend) auch darauf hin, dass sich dies mit laufenden Forschungserkenntnissen in Zukunft ändern kann. An dieser Stelle sei freilich darauf hingewiesen, dass die Vorstellung, einzelne Gewichte in einem Modell würden sich auf eine bestimmte Person beziehen und es daher genüge, die betreffenden Zahlen zu identifizieren, um einer betroffenen Person beispielsweise Auskunft über ihre Daten im Modell zu erteilen oder "ihre" Daten zu löschen, ein Irrglaube ist. Erzeugt ein grosses Sprachmodell aus seinem "Wissen" Angaben über eine Person, dann sind daran unzählige Gewichte beteiligt; es ist das Zusammenspiel der Gewichte, das zum jeweiligen Output führt. Eine betroffene Person könnte mit diesen Zahlen auch überhaupt nichts anfangen. Es ist zudem wie im Blog-Beitrag Nr. 19 bereits gezeigt nicht so, dass ein personenbezogenes Datum automatisch als solches im Modell landet, nur weil es im Trainingsdatensatz enthalten worden ist. Training heisst, dass die Trainingsdaten die Gewichte des Modells justieren helfen, nicht dass sie einfach kopiert werden. Ins Modell wandern letztlich nur aggregierte Informationen, was aber nichtsdestotrotz personenbezogene Daten sein können, wenn beispielsweise eine bestimmte über eine bestimmte Person in den Trainingsdaten sehr häufig vorkommt – wie eben der Geburtstag von Donald Trump. Unsere Illustration zeigt dies. 

Den Überlegungsfehler, den die CNIL und auch andere machen, ist, dass sie sich auf einzelne Gewichte fokussieren und damit den Wald vor lauter Bäumen nicht sehen. Es ist wie bei einer JPEG-Datei, die das Bild eines Textes enthält: Wer die Pixel-Daten anschaut, kann darin keine Buchstaben erkennen. Es kann nicht einmal ganz genau gesagt werden, welcher Pixel genau noch zur Abbildung eines Buchstabens gehört. Trotzdem sind Buchstaben und der Text da. Wer das aus den Pixeln zusammengesetzte Bild aus der Distanz anschaut, erkennt sie sofort. Die Information ist also auf einer Meta-Ebene gespeichert. Bei einem Sprachmodell ist das auch so, nur sind die Informationen dort nicht auf eine, sondern vieler solcher Ebenen verstreut gespeichert, die durch das Modell zuerst zu einem Output zusammengefügt werden müssen. Weil wir das im Einzelnen heute kaum nachvollziehen können, fällt es uns auch so schwer, dieses Konzept zu verstehen und in den Datenschutz einzuordnen.

Erst wenn es in Zukunft dereinst gelingt, das Zusammenspiel der Gewichte in Bezug auf die zu einer bestimmten Person bestehenden Assoziationen und Affinitäten für solche Personen sinnvoll sichtbar zu machen, kann der direkte Zugriff auf das Innere eines Sprachmodells für die datenschutzrechtliche Auskunftserteilung in Frage kommen – und selbst dann gibt es diesbezüglich noch Vorbehalte, wie noch erläutert wird. Immerhin gibt es vielversprechende Forschungsarbeiten und Ansätze, die mindestens zur Beeinflussung von Sprachmodellen in genau diese Richtung gehen (dazu mehr in einem späteren Blog-Beitrag).

Die Sache mit dem Auskunftsrecht

Trotzdem machen betroffene Personen geltend, dass die DSGVO und das DSG mit den darin definierten Betroffenenrechten auch für grosse Sprachmodelle gilt und daher von Stellen, die für diese verantwortlich sind, zu beachten sind. Das ist richtig, jedenfalls soweit diese Sprachmodelle personenbezogene Daten dieser Personen enthalten. Eines der wichtigsten Betroffenenrechte ist dabei das Auskunftsrecht.

Zuständig für die Erfüllung des Auskunftsrechts ist die verantwortliche Stelle, und das können bei einem grossen Sprachmodell gleich verschiedene Stellen sein. Zu denken ist etwa an jene Organisation, die es auf dem Markt anbietet (zum Beispiel im Rahmen einer Serie von Cloud-Diensten), an den SaaS-Provider, der basierend auf einem Sprachmodell einen KI-Service (z.B. einen Chatbot wie "ChatGPT" oder "Copilot") betreibt, aber auch an das Unternehmen, welches es lokal bei sich für interne Anwendungen unterhält.

Wichtig ist im Einklang mit unseren Ausführungen in Blog-Beitrag Nr. 19, dass auch dann, wenn alle dasselbe Modell nutzen, die Frage, ob aus Sicht der jeweiligen Stelle überhaupt personenbezogene Daten vorliegen, unterschiedlich beantwortet werden kann und muss. Das ist der "relative" Ansatz. Während ein Unternehmen wie OpenAI in ihrer Funktion als Anbieterin von "ChatGPT" mit ihrem GPT-4o-Modell zweifellos personenbezogene Daten verarbeitet und auch diesbezüglich den Zweck und die Mittel bestimmt, tut dies ein Unternehmen, welches dasselbe GPT-Modell für eine nicht personenbezogene Industrie-Anwendung nutzt, vermutlich nicht (jedenfalls nicht, was personenbezogene Daten aus dem Modell selbst betrifft). Kommen in dieser Anwendung keine personenbezogenen Daten vor, wird es nicht einmal als verantwortliche Stelle gelten und die DSGVO bzw. das DSG keine Anwendung finden. Wird es mit einem Auskunftsersuchen konfrontiert, braucht es sich um sein GPT-4o-Modell (wo es die verantwortliche Stelle wäre) jedenfalls diesbezüglich kaum Gedanken zu machen. Wenn wiederum der Betreiber einer Website diverse Modelle zum Download bereithält, sie dort aber weder von ihm noch anderen benutzt werden, enthalten sie aus seiner Sicht in der dortigen Kopie ebenfalls keine personenbezogenen Daten und die Speicherung des LLM durch ihn ist keine Datenverarbeitung im Sinne der DSGVO. Zu einer solchen kommt es womöglich erst später, wenn das LLM in einer bestimmten Form genutzt wird, was jedoch ein separater Vorgang darstellt, der daher auch separat beurteilt werden muss.

Daraus ergibt sich bereits eine erste Erkenntnis für die Praxis: Wer ein Auskunftsersuchen erhält und selbst ein Sprachmodell lokal bei sich oder in der Cloud betreibt, wird die Antwort darauf nicht abstrakt für dieses Modell geben müssen, sondern in Bezug auf seine Anwendungen, die es vernünftigerweise für die Generierung von Inhalten mit personenbezogenen Daten verwenden, die aus dem Modell selbst stammen. Soweit personenbezogene Angaben Eingang in ein Sprachmodell gefunden haben, liegen sie dort nur in pseudonymisierter Form vor, und solange nicht vernünftigerweise mit einem Prompt gerechnet werden muss, der sie aus dem Modell extrahiert, gibt es sie für den Verantwortlichen nicht, weil ihm der Schlüssel zur Aufhebung der Pseudonymisierung fehlt.

Auskunft erteilen über ein Sprachmodell

Das Auskunftsrecht dient dazu, die Einhaltung des Datenschutzes durch den Verantwortlichen zu überprüfen und weitere Betroffenenrechte geltend zu machen. Insofern ist es richtig, dass auch dieses dem relativen Ansatz unterliegt wie schon der Begriff des personenbezogenen Datums selbst: Die Auskunft eines Verantwortlichen A in Bezug auf ein bestimmtes Sprachmodell kann beim selben Sprachmodell sachlogisch anders ausfallen als die Auskunft eines Verantwortlichen B. Dies liegt daran, dass die personenbezogenen Daten, die A und B aufgrund ihrer Verwendung des Sprachmodells aus diesem "herausziehen" ebenfalls unterschiedlich sein können, was wiederum daran liegt, dass grosse Sprachmodelle keine Wissensdatenbank, sondern Textgenerierungssysteme sind, die Faktenwissen und damit vereinzelt eben auch personenbezogene Daten nur indirekt enthalten. Das haben wir schon ausführlich in unseren früheren Blog-Beiträgen beschrieben.

Wenn also ein Verantwortlicher Auskunft erteilen muss, welche personenbezogenen Daten sein Sprachmodell in seinem Fall enthält, so müsste er konsequenterweise das Sprachmodell zur Erfüllung des Auskunftsanspruchs so einsetzen, wie er es in seinen Anwendungsfällen in Bezug auf die betroffene Person auch einsetzt, um passende personenbezogene Daten der betroffenen Person zu generieren, und zwar nicht irgendwelche, sondern jene, die im Modell bereits gespeichert sind (ansonsten gibt es nicht Auskunft über die personenbezogenen Daten in seinem Modell, sondern über jene, die im Rahmen seiner Anwendung entstehen können; potenziell in der Zukunft entstehende Personendaten unterliegen jedoch nicht der Auskunftspflicht). Wenn ein Unternehmen beispielsweise ein grosses Sprachmodell zur Übersetzung von Texten einsetzt, wäre die Auskunft in Bezug auf diese Lösung, dass das Sprachmodell gar keine personenbezogenen Daten enthält: Zwar werden viele Texte, die mit generativer KI übersetzt werden, auch personenbezogene Daten enthalten, wodurch auch im Output solche Daten enthalten sein werden. Sie stammen aber vom Input, nicht aus dem Modell. Wir sind damit am vorhin erwähnten Punkt, wo im Rahmen einer Auskunft keine personenbezogenen Daten mitgeteilt werden müssen.

Dasselbe gilt für alle Anwendungen, bei welchen grosse Sprachmodelle lediglich zur Umformung, Zusammenfassung oder sonstigen Bearbeitungen bereits im Input vorgegebener personenbezogener Daten benutzt werden. Das macht auch Sinn so: Sie sollen für den Output schliesslich keine neuen Fakten erfinden. Dasselbe gilt übrigens auch überall dort, wo ein KI-System der Benutzerin oder dem Benutzer zwar neue Informationen liefert, diese aber im Sinne eines Retrieval-Augmented Generation (RAG) aus anderen Informationsquellen als dem LLM stammen. So gesehen werden die meisten Unternehmen sich wegen dem Auskunftsrecht keine Sorge in Bezug auf die von ihnen verwendeten Sprachmodelle machen müssen, weil die meisten Unternehmen grosse Sprachmodelle nur zur Verarbeitung von personenbezogenen Daten verwenden werden, die sie dem Modell füttern und vom Modell nicht verlangen, dass es basierend auf seinem Wissen selbst personenbezogene Daten erzeugt. Ebenso vom Auskunftsrecht in Bezug auf das Modell nicht erfasst sind alle personenbezogenen Daten, welche das Modell selbst erfindet: Sie kommen erst im Output vor.

Schon eher sollten Unternehmen auf der Hut sein, was die Benutzung von Sprachmodellen sonst an personenbezogenen Daten generiert, z.B. wenn sie den gesamten Input und Output einer KI-Lösung (z.B. eines Chatbots) protokollieren. Diese Protokolle unterliegen typischerweise ebenfalls dem Auskunftsrecht. Es gibt sicher bald erste Fälle, in denen betroffene Personen von Unternehmen Auskunft darüber verlangen, über was sich Mitarbeitende diese Personen betreffend mit dem internen Chatbot unterhalten haben. Peinlichkeiten sind vorprogrammiert; immerhin kann die Auskunft womöglich über eine Interessenabwägung zum Schutz der Mitarbeitenden verweigert oder eingeschränkt werden.

Das Modell erzeugt die Auskunft gleich selbst

Etwas schwieriger werden Unternehmen Auskunftsersuchen zurückweisen können, welche Sprachmodelle auch für die Erzeugung von personenbezogenen Daten verwenden und wo gewisse dieser Daten tatsächlich auch im Modell enthalten sein können. Wie im Blog-Beitrag Nr. 19 gezeigt, werden das zwar vergleichsweise wenig Personen sein, bei denen dies tatsächlich der Fall ist. Wir haben den prominenten Datenschutzaktivisten Max Schrems als ein Beispiel dafür genannt; er war es möglicherweise auch, der zur Durchsetzung eines datenschutzrechtlichen Auskunftsrechts Beschwerde gegen OpenAI bei der österreichischen Datenschutzaufsicht eingereicht hat. OpenAI hat bisher offenbar den Standpunkt vertreten, dass sie über den Inhalt ihrer Modelle keine Auskunft zu erteilen hat, wohl mit der Begründung, dass es sich beim Inhalt eines Modells gar nicht um personenbezogene Daten handelt. Wie wir im besagten Blog-Beitrag erläutert haben, sind wir der Ansicht, dass dies in dieser Absolutheit nicht zutrifft. Damit ist aber noch nicht gesagt, wie die Auskunft über die in einem Sprachmodell enthaltenen personenbezogenen Daten zu erfolgen hat.

Die Antwort auf diese Frage ergibt sich aus dem Gesetz: Auskunft ist über diejenigen Daten zu erteilen, die der Verantwortliche über die betreffende Person verarbeitet (Art. 15 DSGVO, Art. 25 CH DSG). Im Falle eines Sprachmodells erfolgt diese Verarbeitung jeweils über das einzige Interface, über welches ein grosses Sprachmodell zur Nutzbarmachung des darin enthaltenen Wissens verfügt, nämlich über sein API (Application Programming Interface): Dem Sprachmodell wird über das API ein Input (z.B. in Form eines Prompts) vorgelegt und zurück kommt der basierend darauf generierte Output. Darum muss folgerichtig auch die Auskunft nur (aber immerhin) unter Verwendung dieser Schnittstelle erzeugt werden. Eine andere Analyse des Inhalts eines Sprachmodells (wie die oben beschriebene Methode von Anthropic) ist daher rechtlich nicht erforderlich, weil daraus, falls überhaupt, nicht jene personenbezogenen Daten resultieren würden, die der Verantwortliche sonst verarbeitet; nur über diese Daten muss der Verantwortliche jedoch Auskunft erteilen, nicht irgendwelche anderen Personendaten die er gar nie als solche verarbeitet.

Welche Fragen dem Modell stellen?

Somit stellt sich als nächstes die Frage, welchen Input (bzw. Prompt) der Verantwortliche seinem Modell zur Generierung der Antwort auf das Auskunftsersuchens vorzulegen hat. Hier bieten sich insbesondere folgende vier Möglichkeiten an:

• Variante 1: Dem Modell werden eine Reihe von Standardprompts vorgelegt (z.B. "Was weisst Du über [Name]?" oder "500 Wörter zu [Name]"). Sinnvollerweise sind diese Prompts auf den Anwendungskontext des Verantwortlichen abgestimmt. Sie sollten auch nicht zu kurze Texte produzieren, ausser, es geht der betroffenen Person um spezifische Angaben.
• Variante 2: Der Verantwortliche protokolliert im täglichen Betrieb seine Prompts und damit erzeugten Outputs. Liegt ein Auskunftsersuchen vor, sucht er jene bisher erfolgten Prompts und generierten Outputs heraus, welche personenbezogene Daten der betroffenen Person erkennbar enthalten und liefert der betroffenen Personen diese Inputs und Outputs. Sind nur die Inputs gespeichert worden, können diese dem Sprachmodell vorgelegt werden. Variante 2 hat den Vorteil, dass die betroffene Person erfährt, welche personenbezogenen Daten einer betroffenen Person tatsächlich aus dem Modell "gezogen" und verarbeitet wurden.
• Variante 3: Der Verantwortliche überlässt es der betroffenen Person, den Prompt (oder eine Mehrzahl von Prompts) zu formulieren, mit welchem er dann das Sprachmodell zur Generierung eines personenbezogenen Outputs veranlasst. Dieser Output wird als Antwort auf das Auskunftsersuchen geliefert.
• Variante 4: Der Verantwortliche teilt der betroffenen Person mit, welche der sie betreffenden personenbezogenen Daten sich in den Trainingsdaten befunden haben, die für die Herstellung des grossen Sprachmodells benutzt worden sind, oder mindestens Angaben zu den dazu verwendeten Quellen. Der EU AI Act unterstützt dies, indem er von Anbietern von Allzweck-Sprachmodellen im Rahmen ihrer Informationspflichten nach Art. 53 Absatz 1 verlangt, dass sie über die für das Training verwendeten Daten informieren, "einschließlich der Art und Herkunft der Daten und der Aufbereitungsmethoden (zum Beispiel Bereinigung, Filterung usw.), der Zahl der Datenpunkte, ihres Umfangs und ihrer Hauptmerkmale; gegebenenfalls die Art und Weise, wie die Daten erlangt und ausgewählt wurden, sowie alle anderen Maßnahmen zur Feststellung, ob Datenquellen ungeeignet sind, und Methoden zur Erkennung ermittelbarer Verzerrungen".

Rechtlich kommt Variante 2 dem Sinn und Zweck des Auskunftsrechts insofern am nächsten, als damit Auskunft über jene Personendaten gegeben wird, die vom betreffenden Verantwortlichen tatsächlich im Zusammenhang mit dem Sprachmodell verarbeitet worden sind. Allerdings gibt es keine Auskunft darüber, was im Sprachmodell enthalten ist und vom Verantwortlichen künftig extrahiert werden könnte. Trotzdem kann eine betroffene Person darüber grundsätzlich Auskunft verlangen, weil auch die Verarbeitung ihrer Daten im Rahmen der Protokollierung der Auskunftspflicht unterliegt.

Variante 3 wiederum hat den Charme, dass die betroffene Person selbst über ihr Auskunftsrecht bestimmt, birgt aber das Risiko, dass ein Prompt benutzt wird, der überhaupt nicht zu der Art und Weise passt, in welcher der Verantwortliche sein Sprachmodell sonst benutzt. Die Folge könnte sein, dass ein hochproblematischer Output erzeugt wird, der dann weitere Ansprüche generiert, obwohl ein solcher Output im normalen Lauf der Dinge vom Verantwortlichen nie generiert worden wäre. Oder es geschieht genau das Umgekehrte: Die Auskunft ergibt zwar personenbezogene Daten, aber sie sind weitaus weniger problematisch als das, was der Verantwortliche sonst mit dem Modell anstellt.

Variante 4 erteilt zwar keine Auskunft auf die personenbezogenen Daten, die ein Sprachmodell enthält, aber sie kann, je nach Fall, eine betroffene Person allenfalls dahingehend beruhigen, dass über sie im Training keine oder nicht ohne Weiteres identifizierbare Daten enthalten waren, und ihr andererseits ein besseres Verständnis darüber geben, wo und wie ihre Daten allenfalls Eingang ins Modell gefunden haben. Der Nachteil dabei ist, dass wenn tatsächlich Daten von ihr in den Trainingsinhalten enthalten waren, sie möglicherweise schlussfolgern wird, dass ihre Daten somit auch im Modell selbst enthalten sind, was in den meisten Fällen nicht der Fall sein wird aus den von uns schon anderweitig erläuterten Eigenheiten grosser Sprachmodelle und ihres Trainings. Variante 4 hat umgekehrt den Vorteil, dass es bei unter dem AI Act regulierten Modellen einfach sein wird, an die erforderlichen Angaben zu gelangen – im besten Fall über einen Link des Modell-Lieferanten, welcher der betroffenen Person mitgeteilt werden kann. Für eine erste Antwort auf ein Auskunftsersuchen hin wird eine solche Information in den meisten Fällen vermutlich auch reichen.

Genügt dies nicht, erscheint nach dem Gesagten jedoch Variante 1 dort am sinnvollsten, wo die gewählten Prompts dem entsprechen, was beim Verantwortlichen an Prompts typischerweise verwendet wird, soweit ein Personenbezug überhaupt in Frage steht. Das gilt jedenfalls dort, wo ein Sprachmodell nicht für generische Abfragen eingesetzt wird, weil solche Abfragen auch innerhalb eines Unternehmens häufig ein ebenso breites Spektrum aufweisen können, wie dies auch ein öffentlicher Chatbot oder dergleichen tut. In solchen Fällen erscheint Variante 3 passender. Ein Verantwortlicher könnte aber auch im Sinne einer stufenweisen Auskunft der betroffenen Person erklären, dass ein interner Chatbot auf Basis derselben Modelle eingesetzt wird, wie sie auch bekannte Dienste wie "ChatGPT" nutzen und der Person vorschlagen, in einem ersten Schritt selbst zu prüfen, was sich daraus extrahieren lässt (weil ihr dies schneller und flexibler Antworten beschert, als wenn der Verantwortliche dies selbst mit einer Serie von Musterprompts tun würde). Es sind mit anderen Worten viele verschiedene Wege möglich, um eine Auskunft zu erteilen. Den einen "richtigen" Weg gibt es (noch) nicht; auch wir können hier lediglich erste Ansätze zur Bewältigung des Themas liefern.  

Die Möglichkeit von Halluzinationen …

Allen drei Modell-Output-Varianten gemeinsam ist, dass damit nur jeweils eine oder wenige von unzähligen möglichen Reaktionen des Modells ausgelöst werden und daher keinerlei Gewissheit besteht, ob und zu welchem Grad die im Modell enthaltenen personenbezogenen Daten extrahiert werden konnten. Das ist nach der hier vertretenen Ansicht zwar letztlich hinzunehmen, weil es in der Natur eines grossen Sprachmodells begründet ist. Es ist auch insofern sachgerecht, als der jeweils Verantwortliche im Rahmen seiner Verarbeitung nie alle möglichen Reaktionen des Modells auszulösen vermag. Es entbindet den Verantwortlichen bei Variante 1 aber nicht von der Sorgfaltspflicht bei der Formulierung möglichst realitätsnaher Prompts zur Erzeugung der Antwort für etwaige Auskunftsersuchen.

Umgekehrt können die auf diese Weise generierten Outputs ohne Weiteres auch Halluzinationen enthalten, d.h. Angaben, die als personenbezogene Daten mangels besserer Alternativen erscheinen, aber erfunden sind, weil sie im Modell gar nicht wirklich als solche vorkommen und daher typischerweise auch inhaltlich falsch sind. Auseinandersetzungen mit der betroffenen Person sind so vorprogrammiert, weil der Verantwortliche für personenbezogene Daten zur Rechenschaft gezogen wird, die sich gar nicht im Modell befinden und so vom Verantwortlichen womöglich auch nie verarbeitet worden wären. Auch dies ist unbefriedigend, aber ebenfalls insoweit hinzunehmen, als dem Verantwortlichen in solchen Situationen immer noch die Möglichkeit offensteht, mit zielgerichteteren Prompts zu zeigen, dass ein bestimmter personenbezogener Output vom Modell erfunden worden ist. Der Ball liegt in diesen Fällen aber richtigerweise beim Verantwortlichen. Er wird dabei wohl auch darlegen müssen, wie er sicherstellt, dass in seiner Praxis solche erfundenen Inhalte nicht fälschlicherweise für Tatsachen gehalten werden.

Was aber kann ein Verantwortlicher tun, damit sein Modell bei der Produktion von Outputs für Auskunftsersuchen möglichst keine personenbezogenen Inhalte erfindet?

Die theoretische Antwort wäre, dass er sein Modell so programmieren bzw. ausrichten müsste, dass es bei Abfragen für die Zwecke von Auskunftsersuchen nur jene Inhalte für den Output berücksichtigt, die in Bezug auf die betroffene Person eine besonders hohe Wahrscheinlichkeit aufweisen. Dies klingt allerdings einfacher als es ist. Der Einsatz einer Konfidenzschwelle, wie sie bei RAG-Implementationen teilweise zum Einsatz kommt und hier nahe liegen würde, wird in Bezug auf im Modell selbst enthaltenen Informationen zum Beispiel eher nicht zum Erfolg führen. Denn generiert das Modell einen Output, spielt es für dieses bei der Selektion des jeweils nächsten Tokens bzw. Wortes grundsätzlich keine Rolle, weshalb es eine hohe Wahrscheinlichkeit aufweist – ob aufgrund einer Assoziation zur betroffenen Person oder aus anderen, nicht personenbezogenen Gründen. Diese anderen Gründe können sich aus dem Prompt ergeben. Eine hohe Wahrscheinlichkeit mag zwar Faktenwissen des Modells indizieren, aber nicht notwendigerweise in Bezug auf die betroffene Person.

Wird ein Sprachmodell beispielsweise gebeten, die Geschichte von Hänsel und Gretel so zu formulieren, als wäre Donald Trump die böse Hexe, wird es einen solchen Text abliefern (hier am Beispiel von GPT-4o):

… Hungrig und müde stolperten sie durch den Wald, bis sie auf ein erstaunliches Haus stiessen. Es war aus Lebkuchen, Süssigkeiten und Kuchen gebaut. Die Kinder konnten ihren Augen kaum trauen und begannen hungrig, an den Wänden des Hauses zu knabbern. Plötzlich öffnete sich die Tür, und heraus trat niemand Geringeres als Donald Trump, in einem luxuriösen Anzug und mit einem breiten Grinsen im Gesicht.

"Na, wen haben wir denn hier?" fragte Trump mit seiner charakteristischen Stimme. "Kommt rein, kommt rein! Hier gibt es viel zu essen, und ihr könnt euch ausruhen."

Hänsel und Gretel, zu hungrig und erschöpft, um zu widerstehen, folgten ihm ins Haus. Doch kaum waren sie drinnen, zeigte Trump sein wahres Gesicht. Er sperrte Hänsel in einen Käfig und zwang Gretel, für ihn zu arbeiten. "Ich werde Hänsel mästen und dann... nun ja, das werdet ihr schon sehen," sagte er mit einem diabolischen Lächeln. …

Weil das Modell die Geschichte sehr genau kennt, dominiert das Märchen den Output und nicht etwaige personenbezogene Daten, die das Modell zu Donald Trump zweifellos auch hat. Der Output bleibt ein Märchen, auch wenn es mit hoher Konfidenz erzählt wird. Dabei greift das Modell dort, wo es von der Hexe sprechen würde, durchaus auf Wissen zurück, welches es stark mit Herrn Trump assoziiert, etwa wenn es von seinem "luxuriösen Anzug" oder "breiten Grinsen" spricht. Auch wenn das Modell selbst keinerlei Assoziation zwischen Hänsel und Gretel und Donald Trump haben wird, wird es auch diesen Output mit hoher Wahrscheinlichkeit generieren. Sie ergibt sich denn auch nicht aus dem Modell, sondern aus dem Prompt, der dem Modell als Input vorgelegt worden ist.

… und wie sie erkannt werden können

Wer einen Prompt für ein Auskunftsersuchen formuliert und Halluzinationen vermeiden möchte, muss daher in einem ersten Schritt darauf achten, dass dieser möglichst frei von störenden "Einflüssen" ist, welche im Modell bei der Generierung des Outputs nicht personenbezogene Assoziationen wecken können. Eine sinnvolle Formulierung wäre also beispielsweise "50 Wörter zu Anzügen von Donald Trump", um dem Modell seine stärksten Assoziationen zwischen Donald Trump und dem Thema Anzüge zu entlocken, oder eben ein Prompt wie "Geburtstag von Max Schrems". Fremdassoziationen können allerdings nie ganz verhindert werden, weil die Generierung des Outputs nicht nur den (ursprünglichen) Input berücksichtigt, sondern auch den im Prozess bereits generierten Text. Dieser kann das Modell wiederum auf Abwege bringen.

Es ist daher noch ein zweiter Schritt nötig, um Halluzinationen zu erkennen. Hierbei kann sich ein Verantwortlicher eine Eigenschaft zunutze machen: Sie sind in der Regel nicht konstant. Werden Prompts und Parameter wie die Temperatur variiert, variiert auch der halluzinierte Inhalt eines Outputs. Auf diese Weise kann er erkannt werden. In der Praxis heisst dies für einen Verantwortlichen, dass er seinem Modell lediglich die Fragestellung (z.B. der Geburtstag von Max Schrems; siehe unser letzter Beitrag in Blog Nr. 19) in verschiedener Weise vorlegen und die verschiedenen damit erstellten Outputs vergleichen muss: Was trotz unterschiedlicher Prompts und (in begrenztem Rahmen variierender) Temperatur an Informationen in allen Outputs gleich bleibt, ist mutmasslich als entsprechende Assoziation oder Affinität im Modell gespeichert und wiederspiegelt daher das mutmassliche Faktenwissen des Modells.

Wir haben hierzu unseren GPT-API-Client "VGPT" (er ist als Open Source hier kostenlos zu beziehen) um ein Werkzeug erweitert, mit welchem diese Prozedur experimentell angewandt werden kann. Im nachfolgenden Beispiel erzeugt das Modell GPT-4o sechs Texte zur Frage "500 Wörter zu Max Schrems" und erkennt korrekterweise, dass ihm das Geburtsdatum von Herrn Schrems "unbekannt" ist, weil es in den sechs von ihm generierten Texten teils unterschiedlich angegeben wird:

Verschiedene Tests mit dem Werkzeug zeigen, dass es abhängig vom jeweiligen Prompt widersprüchliche Antworten je zuverlässiger erkennt, je kürzer die Antworten sind. Auch zeigt sich, dass unterschiedliche Schreibweisen eines Namens zu unterschiedlichen Ergebnissen kommen können. Wird GPT-4o nach dem Geburtstag von Maximilian Schrems gefragt, ist sich das Modell deutlich sicherer, dass es sich um den 11. Oktober 1987 handeln muss, als wenn der Name Max Schrems geprüft wird. Absolut sicher ist es sich aber dennoch nicht: Werden die Frage-Iterationen z.B. auf 7 Variationen erhöht und jene für die Temperatur auf 3 pro Frage, werden also insgesamt 21 Abfragen getätigt, dann kommt es immerhin zu zwei Abweichungen und einer Antwort nur mit Monat und Jahr.

Die Temperatur lassen wir nur zwischen 0 und 1 variieren. Denn je höher die Temperatur ist desto mehr gleicht die Wahrscheinlichkeitsverteilung über das Vokabular von Tokens einer uniformen, also einheitlichen, Distribution. In diesem Fall würde auch das beste Sprachmodell zufällige Tokens generieren. Somit wird eine Information in einem grossen Sprachmodell immer als "unsicher" bewertet werden müssen, wenn die Temperatur einfach genug hoch angesetzt wird.

Diese Unterschiede zeigen, dass das Modell GPT-4o die beiden Namensvariationen nicht als logische Einheit betrachtet, sondern die Kombinationen "Max" und "Schrems" und sowie "Maximilian" und "Schrems" jeweils ihre eigenen Assoziationen und Affinitäten im Modell aufweisen und damit auch gesondertes Faktenwissen. Darum ist es wichtig, bei Abfragen zur Beantwortung eines Auskunftsersuchens nicht nur die Fragestellung zu variieren, sondern auch zu erwartende unterschiedliche Schreibweisen eines Namens zu verwenden. Das wiederum spricht für Variante 3: Formuliert die betroffene Person die Abfrage, ist auch sie dafür verantwortlich, die Abfrage hinreichend breit zu formulieren.

Die Frage, wann sich ein LLM seiner Antwort auf eine bestimmte Frage hin "sicher" ist bzw. ob und wie es seine Konfidenz zum Ausdruck bringen kann, ist übrigens Gegenstand diverser Forschungsarbeiten, auch hier in der Schweiz. Hier stehen wir allerdings noch am Anfang (vgl. etwa hier und hier). Eine der bisherigen Erkenntnisse ist, dass es nicht sehr zielführend ist, das Modell direkt nach seiner Konfidenz zu fragen. Es wird diese Frage erfahrungsgemäss zu selbstbewusst und mitunter auch ohne ernsthafte Prüfung beantworten, was nicht wirklich überrascht. Wir haben daher für unser Prüfung der hohen Wahrscheinlichkeit einer Assoziation zwischen verschiedenen Informationsbruchstücken bewusst eine andere Vorgehensweise gewählt, die nach unserer Erfahrung bessere Ergebnisse liefert.

Welche Anforderungen der Datenschutz wiederum an die Richtigkeit von Outputs von grossen Sprachmodellen stellt und wie personenbezogene Daten korrigiert werden können, erläutern wir in einem separaten Blog-Beitrag. Das Auskunftsrecht tangiert dies an sich nicht, da ein Verantwortlicher auch über etwaige falsche, bei sich verarbeitete personenbezogene Daten Auskunft erteilen muss.

Identifikation der betroffenen Personen

Eine weitere Herausforderung, die sich bei Auskunftsersuchen in Bezug auf grosse Sprachmodelle stellen kann, ist die Frage der Identifikation der betroffenen Person und die Zuordnung zu den Daten im Modell. Denn Anspruch hat die um Auskunft ersuchende Person nur auf solche Daten, die im konkreten Kontext tatsächlich sie betreffen.

Dieses Problem ist nicht neu. Denn häufig haben Unternehmen Daten über Personen gespeichert, die nicht zwingend nur einer einzigen Person auf der Welt zugeordnet werden können (z.B. mehrere Personen mit demselben Namen, Beruf und Wohnort; so gibt es neben dem Autor dieser Zeilen noch einen zweiten David Rosenthal, der Jurist ist und in Zürich lebt), obwohl sie sich nur auf eine einzige Person beziehen. Während es gewisse Lehrmeinungen gibt, die in diesem Fall davon ausgehen, dass in einem solchen Fall gar keine personenbezogenen Daten vorliegen, greift dies nach der hier vertretenen Ansicht zu kurz: Es kann nicht darauf ankommen, wem Daten zugeordnet werden könnten, sondern wem sie in der betreffenden Anwendung zugeordnet werden. Sonst liesse sich der Datenschutz durch bewusst ungenaue Personendaten oder das Argument, der Personenbezug sei nur zu 95% gewiss, beliebig unterlaufen.

Die praktische Lösung ist, dass wenn eine Datensammlung Informationen (z.B. eine Transaktion) über jemanden enthält, der einzig als Juristen namens David Rosenthal in Zürich identifiziert ist, grundsätzlich beide Rosenthals Auskunft über diese Information verlangen können, weil sie sich auf beide beziehen können. Soweit aber klar ist, dass sich die Information nur auf einen der beiden beziehen kann, wird anhand weiterer Angaben wie z.B. die Quelle der Daten oder den Kontext geklärt werden müssen, auf wen sie sich im konkreten Kontext bezieht, um durch die Auskunftserteilung nicht personenbezogene Daten des anderen preiszugeben. Dies kann bedeuten, dass zurückgefragt werden muss, um zu ermitteln, ob es sich beim Anfrager um den richtigen David Rosenthal handelt (z.B. indem nach möglichen Transaktionen oder Aufenthaltsorte gefragt wird, die der richtige kennen müsste und den Bezug klären können).

Dies kann auch auf grosse Sprachmodelle übertragen werden. Wird GPT-4o nach David Rosenthal gefragt, nennt er einen US-amerikanischen Filmregisseur und Drehbuchautor, und nicht den Juristen, der diesen Blog verfasst hat. Der Verantwortliche müsste somit klären, ob diese Antwort im Kontext seiner Anwendung auf den David Rosenthal bezieht, der die Anfrage gestellt hat (z.B. durch Rückfrage nach dem Beruf, der in den Antworten als weiteres, identifizierendes Element auftaucht). Bei diesem Beispiel käme heraus, dass kein Bezug besteht. Auch eine Einschränkung der Anfrage auf "Zürich", "Schweiz", "Jurist" oder "Datenschutz" führt nicht zum Ziel. Entsprechend ist eine negative Auskunft zu erteilen. Das Modell kennt zwar etliche David Rosenthals, aber offenkundig nicht den Autor dieser Zeilen. Dabei ist im Hinterkopf zu behalten, dass sowieso nur über jene Outputs Auskunft zu erteilen ist, mit denen in der konkreten Anwendung vernünftigerweise zu rechnen ist. Die negative Auskunft wird also der absolute Regelfall sein.

Eine weitere Konstellation kann aufgrund der Art und Weise wie Sprachmodelle funktionieren sein, dass personenbezogene Daten zweier Personen mit denselben identifizierenden Angaben vermischt werden, d.h. sich im Output, der sich augenscheinlich auf eine Person bezieht, aber auch Angaben über eine andere Person enthält, die sich gewissermassen eingeschlichen haben, weil das Modell nicht unterscheidet. Ein Beispiel könnte ein Output zu George H. W. Bush, dem 41. Präsidenten der Vereinigten Staaten sein, in welchem sich Angaben über seinen Sohn finden, George W. Bush, den 43. Präsidenten der Vereinigten Staaten. In diesem Falle sind beide Personen des öffentlichen Lebens, weshalb ein Modell wie GPT-4o sie beide kennt. Auch dies bereitet in der Praxis aber nicht wirklich Probleme: Wenn in einem Output über Bush Senior diesem fälschlicherweise Informationen zu Bush Junior zugerechnet werden und keine Halluzination (siehe oben) vorliegt, dann werden es in Bezug auf das Modell personenbezogene Daten von Bush Senior sein, die aber eben falsch sind. Es bestünde grundsätzlich ein Anspruch auf Berichtigung. Diese Fälle kommen in der Praxis auch in anderen Bereichen immer wieder vor, etwa wenn Kreditauskunfteien eine schlechte Zahlungserfahrung einer Person einer gleichnamigen, aber anderen Person zuordnen.

Praxisempfehlungen

Für die Praxis empfehlen wir somit, dass ein Verantwortlicher, welcher ein Auskunftsersuchen erhält, das sich auf von ihm eingesetzte grosse Sprachmodelle bezieht, folgende Punkte prüft bzw. folgende Schritte unternimmt:

1. Werden Sprachmodelle im Unternehmen überhaupt dazu verwendet, Outputs zu generieren, in denen vernünftigerweise mit personenbezogenen Daten gerechnet werden muss, die aus den Modellen selbst stammen und nicht von etwaigen Prompts, RAG-Datenbanken oder anderem Input? Wenn nein, braucht über die Modelle keine Auskunft erteilt zu werden. Damit werden die meisten Anwendungsfälle mit Ausnahme generischer Chatbots and KI-Assistenten wegfallen.
2. Werden Modelle zur Erzeugung von darin enthaltenen personenbezogenen Daten benutzt, ist zu prüfen, ob die Modelle mit beliebigen, kaum vorhersagbaren Prompts eingesetzt werden (wie z.B. bei generischen internen Chatbots) oder vielmehr fallspezifische, jeweils vergleichbare Prompts zum Einsatz kommen (wie z.B. strukturierte Inhalte oder computergenerierte Prompts). Hierbei sind nur jene Prompts bzw. Inputs zu berücksichtigen, welche das Sprachmodell vernünftigerweise veranlassen, personenbezogene Daten aus seinem eigenen Wissen zu erzeugen.
3. Je nach Ergebnis aus Schritt 2 ist ein geeigneter Ansatz zu wählen, wie die Antwort auf das Auskunftsgesuch generiert werden kann, damit sie der betroffenen Person das beste Verständnis vermittelt, welche personenbezogenen Daten das jeweilige Modell in den jeweiligen Anwendungen des Verantwortlichen wahrscheinlich erzeugen wird. Der Verantwortliche kann entweder den Output verwenden, den das Sprachmodell auf von ihm selbst entworfene Prompts mit dem Namen oder anderen passenden Identifikatoren der betroffenen Person generiert (z.B. "500 Wörter über [Name]") oder er lässt die betroffene Person selbst passende Prompts formulieren. Möglich ist auch eine Kombination der beiden Vorgehensweisen; womöglich entwickeln sich in Zukunft noch weitere Varianten. Klar ist aber auch, dass es heute nicht möglich ist, sämtliche personenbezogene Daten, die in einem Modell stecken, aus diesem zu extrahieren. Entsprechend offen sollte die Auskunftserteilung formuliert sein, um hier keinen falschen Eindruck zu erwecken. Die betroffene Person sollte wissen, dass eine solche Auskunftserteilung lediglich eine Art Annäherung darstellt. Weil freilich in der Praxis auch nicht alle personenbezogenen Daten abgerufen werden, wird dies akzeptiert werden.
4. Sind die Prompts zur Erzeugung der Antwort auf das Auskunftsersuchen formuliert, werden sie dem Modell vorgelegt. Dies erfolgt vorzugsweise in verschiedenen Variationen und mit wechselnder Temperatur (wo diese eingestellt werden kann), damit anhand von Unterschieden im Output ermittelt werden kann, welche der personenbezogenen Angaben durchgängig identisch auftauchen und damit mutmasslich keine Halluzinationen sind und welche Angaben variieren, weil das Modell sie gewissermassen zur Lückenfüllung spontan erfunden hat. Was das Modell an personenbezogenen Daten erfindet, ist sachlogisch nicht im Modell als personenbezogenes Datum enthalten und unterliegt daher auch nicht dem Auskunftsrecht, soweit es sich auf das Modell selbst bezieht. Klarerweise zufällige Angaben können und sollten aus dem Output vor einer Auskunftserteilung entfernt werden. Zur Vermeidung von Missverständnissen ist dies allerdings zu dokumentieren und begründen.

Welche Wahrscheinlichkeit vorliegen muss, damit eine Zuordnung zwischen einer bestimmten Person (im Modell repräsentiert durch bestimmte Kombinationen von Informationen) und weiteren Angaben als "klar" gelten kann und somit ein Personenbezug besteht bzw. die betroffene Person bestimmbar wird, ist nicht festgelegt. Eine Assoziation ist nicht einfach da oder nicht da, sondern sie ist graduell. Übertragen bedeutet dies, dass auch ein Modell sich ob eines Personenbezugs unterschiedlich sicher sein kann. Dies schliesst ihn jedoch nicht aus, da wir solche Wahrscheinlichkeiten in sehr vielen Fällen kennen und akzeptieren; auch unser Hirn funktioniert so.

Zu berücksichtigen ist bei der Formulierung passender Abfragen ferner, dass sie nicht oder nicht unbedingt bi-direktional funktionieren: Dass der Prompt A zum Output B führt, bedeutet nicht, dass der Prompt B den Output A erzeugt. Das unterscheidet ein Sprachmodell ebenfalls von einer klassischen Datenbank. Die Verwendung klassischer Identifikatoren für die Formulierung von Abfragen wie etwa den Namen kombiniert mit weiteren Attributen und eingrenzenden Informationen kann in der Praxis helfen. Ist die Abfrage zu generisch, wird es am konkreten Personenbezug fehlen. Bei diesem ist überdies daran zu denken, dass er sich letztlich aus dem ableitet, was im Training gesehen wurde. Wenn das Modell von Donald Trump spricht, meint es den ehemaligen US-Präsidenten und nicht den Onkologen, den es in den USA mit diesem Namen ebenfalls gibt. Er dürfte in den Trainingsdaten kaum vorgekommen sein.

Schliesslich erinnern wir daran, dass alle erwähnten Methoden immer nur eine approximative Auskunft über Informationen eines Sprachmodells zu einem bestimmten "Thema" liefern können, selbst wenn diese in den Gewichten des Modells gespeichert ist.

Nach unserer Erfahrung werden die vier obigen Schritte kaum je durchgespielt werden müssen, und sei es nur schon, weil betroffene Personen heute noch keine solchen Auskünfte erwarten. Das Auskunftsrecht besteht zwar grundsätzlich auf alle personenbezogenen Daten, die ein Verantwortlicher verarbeitet, in der Praxis erfolgen schon aus Gründen der Praktikabilität und des gesunden Menschenverstands in einem ersten Schritt nur jene Daten zu liefern, die betroffene Personen typischerweise interessieren – vor allem bei generischen Auskunftsersuchen. Es kann dann in weiteren Schritten die Auskunftserteilung immer noch ausgeweitet werden. Diese stufenweise Vorgehensweise ist im Allgemeinen akzeptiert. Angaben über potenziell von einem Sprachmodell erzeugte Personendaten werden daher normalerweise nicht zu einer ersten Auskunft gehören. Will eine Person mehr zur Verarbeitung ihrer Daten mit KI wissen, wird sie in den meisten Fällen bereits mit allgemeinen Angaben zu den verwendeten Modellen befriedigt sein, vor allem, wenn es sich dabei um breit verwendete und bekannte Modelle handelt. Auf die vorstehend beschriebenen Varianten (und womöglich noch weitere Formen der Auskunft) wird es daher nur in den seltensten Fällen wirklich ankommen. Ausnahmen bilden natürlich Unternehmen wie OpenAI, welche ihre Modelle in öffentlich zugänglichen SaaS-Services einer Vielzahl von Benutzerinnen und Benutzern anbieten – und entsprechend häufiger auch mit Auskunftsersuchen spezifisch bezüglich der von ihnen verwendeten Sprachmodelle konfrontiert sein werden.

David Rosenthal

PS. Vielen Dank an Imanol Schlag vom ETH AI Center für den Review des Beitrags in technischer Hinsicht und für die wertvollen Inputs.

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.