Personenbezogene Daten in Prompts nutzen? Eine Lösungsskizze

Die datenschutzkonforme Nutzung generativer KI-Modelle an Hochschulen ist derzeit ein heiß diskutiertes Thema. Während die Nutzung von Open Source-Modellen mangels einer bestehenden Infrastruktur nicht kurzfristig umsetzbar scheint, sind bereits Lösungen im Gespräch, die die Weitergabe von persönlichen Daten der Hochschulangehörigen an kommerzielle Anbieter vermeiden. Aber was passiert mit möglicherweise personenbezogenen Daten, die in Prompts eingegeben werden und so an kommerzielle Anbieter gelangen? Für dieses Problem möchte ich hier einen Lösungsvorschlag skizzieren.

Für die Bereitstellung DSGVO-konformer Zugänge zu großen Sprachmodellen werden im Hochschulbereich derzeit vor allem zwei Lösungen diskutiert:

1. Der Aufbau einer digital-souveränen Infrastruktur auf Basis eines Open Source-LLMs: Während kleinere Modelle wie Vicuna (7B) oder LlaMA 2 (7B) dabei auf einigermaßen performanter aktueller Hardware sogar lokal auf dem eigenen Rechner lauffähig sind, ist das für größere Modelle wie Smaug (72 Mrd. Parameter) derzeit nicht der Fall. Gleichzeitig liegt mit Smaug ein offenes Modell vor, das in Benchmarks sogar bessere Ergebnisse als GPT 3.5 oder Gemini erzielt.
2. Der Zugriff auf kommerzielle Sprachmodelle über APIs, wie sie etwa von OpenAI bereitgestellt werden: Da der Zugriff nicht direkt über OpenAI erfolgt, sondern Hochschulangehörige über ein von der Hochschule oder einem Hochschulverbund bereitgestelltes Interface auf die Sprachmodelle zugreifen, findet kein Abfluss von Nutzerdaten an die in der Regel US-amerikanischen LLM-Anbieter statt.

Königsweg Open Source

Während eine digital-souveräne Open Source-Lösung sicherlich den Königsweg für die Lösung des Datenschutzproblems darstellt, ist er kurzfristig mit einigen Hürden versehen: Die Machbarkeit in Bezug auf Hardwareanforderungen einer ausreichend performanten Infrastruktur, die gleichzeitige Anfragen tausender Studierender bewältigen kann, muss zunächst noch geprüft werden. Für die Bereitstellung notwendiger Ressourcen benötigte es ein Commitment der Landes- und Bundespolitik. Schließlich müsste eine solche Infrastruktur aufgebaut und – angesichts der Entwicklungen im Bereich der generativen KI keine triviale Aufgabe – up-to-date gehalten werden.

Eine eigene Infrastruktur böte aber den enormen Vorteil, dass exakt nachvollziehbar bleibt, wo die eigenen Daten verarbeitet werden. Zu diesen gehören nicht nur die persönlichen Daten der hochschulangehörigen Nutzer, sondern auch die mittels Prompts an das Sprachmodell zur Verarbeitung gegebenen, ggf. ebenfalls personenbezogenen, Daten.

Während eine solche Lösung wünschenswert ist und ihre Machbarkeit in jedem Fall geprüft werden sollte, ist sie kurzfristig voraussichtlich nicht realisierbar. Aus diesem Grund liebäugeln viele Hochschulen derzeit mit der zweiten oben genannten Option.

Pragmatische (Brücken-)Lösung: Nutzung kommerzieller APIs

APIs (Application Programming Interfaces) sind von Softwareanbietern bereitgestellte Schnittstellen, um mit anderer Software zu interagieren. Als Programmierer kann ich mit den von OpenAI bereitgestellten APIs etwa die Funktionalität der Sprach- und Bildgeneratoren in meine eigenen Programme integrieren. So können Hochschulen eigene Benutzeroberflächen bauen, die dann wiederum mit den APIs kommerzieller Anbieter „sprechen“. Der Vorteil: Die Hochschulangehörigen sprechen nur mit dem Hochschul-Interface. Der kommerzielle Anbieter erhält so keinen Zugriff auf die Nutzerdaten und kann die Anfragen auch nicht einzelnen Nutzern zuordnen.

Ein weiterer Vorteil: Da viele Anbieter APIs bereitstellen, ließe sich eine Vielzahl von konkurrierenden KI-Modellen parallel über das eigene Interface anbieten. Hochschulangehörige könnten so etwa ausprobieren, ob GPT4-Turbo, Gemini 1.5 oder Claude Opus für ihre Aufgaben am geeignetsten ist. Gleichzeitig würde man eine gewisse Unabhängigkeit von einem einzelnen Anbieter erreichen.

Die meisten Anbieter von KI-Modellen lassen sich die Nutzung ihrer APIs nach Volumen bezahlen, dabei wird in der Regel pro Millionen Tokens (ein Token entspricht meist etwas weniger als einem Wort) abgerechnet. Auffällig ist, dass die jeweils aktuellsten Modelle dabei oft um ein Vielfaches teurer sind als die Vorversionen. So berechnet OpenAI für GPT4-Turbo derzeit 10 USD / 30 USD (Output/Input) pro 1 Mio. Tokens, während es für GPT3.5-Turbo 0,50 USD / 1,50 USD sind.

Für eine Kostenkontrolle ließe über das Hochschulinterface ein Nutzermanagement mit Guthabensystem bereitstellen – idealerweise gekoppelt an den Single-Sign-On der jeweiligen Hochschule. So könnte jeder Hochschulangehörige selbst entscheiden, ob für die aktuelle Aufgabe ein guthabenintensiver GPT4-Zugriff nötig ist, oder ob GPT3.5 bereits ausreichend gute Ergebnisse liefert. Die Gesamtkosten wären so gedeckelt. Auch ein Zukauf weiteren Guthabens durch die Nutzer je nach Bedarf wäre denkbar.

Schön und gut – aber wie umgehen mit personenbezogenen Daten in Prompts?

Während die Nutzerdaten beim oben skizzierten Weg vor dem Zugriff durch kommerzielle Anbieter geschützt sind, gilt dies nicht für möglicherweise personenbezogene Daten, die in Prompts eingeben werden. Diese gelangen weiterhin via API zu den Servern der Anbieter, wo sie weiterverarbeitet werden. Auch durch Nutzungsbedingungen, die die Nutzung personenbezogener Daten in Prompts untersagen, lässt sich dieses Problem vermutlich nicht vollends lösen, da eine Kontrolle nicht nur schwierig ist, sondern ein solches Verbot auch einige (sinnvolle) Anwendungsszenarien der Sprachmodelle verbieten würde.

Eine Lösung könnte in einer automatisierten lokalen Vorverarbeitung der Prompts sein, bevor diese an die APIs weitergereicht werden. Wenn ein lokales System automatisiert personenbezogene Daten in den Prompts erkennt und anonymisiert/pseudonymisiert, wäre das Problem der personenbezogenen Daten in Prompts gelöst oder zumindest erheblich geschmälert. Eine Pseudonymisierung böte darüber hinaus den Vorteil, dass das lokale System ein temporäres Pseudonymglossar erstellen könnte, mithilfe dessen es die (ebenfalls pseudonymiserte) Antwort des LLMs zurückübersetzt. Im Idealfall würde der Endanwender von diesem Prozess so gar nichts bemerken; er könnte also guten Gewissens kommerzielle LLMs mit personenbezogenen Daten nutzen, ohne, dass diese beim LLM-Anbieter landen.

Und wie setzt man das um?

Für die automatisierte Erkennung von personenbezogenen Daten und die Erstellung eines Pseudonymglossars ließe sich sicherlich ein leichtgewichtiges Sprachmodell feintunen. Aber warum sich die Arbeit machen, wenn es bereits entsprechende Lösungen gibt?

Microsoft hat mit Presidio ein Open Source-Tool unter MIT-Lizenz veröffentlicht, das automatisiert Daten anonymisiert und sich für den vorliegenden Einsatzzweck anpassen lässt. Auch die Bereitstellung eines Pseudonymglossars wie oben skizziert sollte mit Presidio nicht allzu aufwendig sein.

Wer das Tool ausprobieren möchte, kann dies mit der bereitgestellten Demo tun. Hier zeigte sich in meinen Versuchen, dass Presidio recht zuverlässig personenbezogene Daten erkennt, wenngleich das ein oder andere falschnegative Datum im Text verblieb. Hier lassen sich mit Feintuning der Einstellungen sicherlich noch bessere Ergebnisse erzielen.