Persoonlijke informatie van Australische burgers in de staat Nieuw-Zuid-Wales is uitgelekt door ongeautoriseerd gebruik van ChatGPT. Dat meldde Tweakers vorige week. Dat riep vele vragen op: is dat wel een datalek, waar zijn de gegevens dan beland? En waarom is dit anders dan wanneer je iets naar een clouddienst uploadt?
Het persbericht van de betreffende overheidsdienst legt uit:
The breach occurred when a former contractor of the RA uploaded data containing personal information to an unsecured AI tool which was not authorised by the department. There is no evidence that any information has been made public (…).Oké, dus een externe partij had een Excelbestand met persoonsgegevens geupload naar ChatGPT. Dat is (in ieder geval in Europa) een datalek in de zin van de AVG, omdat de data in strijd met de beveiligingsmaatregelen bij een ongeautoriseerde derde terecht kwam, namelijk OpenAI.
De achterliggende zorg is natuurlijk dat OpenAI haar taalmodel gaat bijtrainen op de geuploade data. Maar dat daardoor gegevens op straat komen te liggen is niet waarschijnlijk. ChatGPT is immers geen zoekmachine die zo’n Excelsheet lekker als bronbestand aanroept. Dat bijtrainen gaat over statistische patronen herkennen, niet over feitendatabanken bijwerken.
Om die reden zou ik wel durven twisten over of het bij zo’n upload “niet waarschijnlijk is dat de inbreuk in verband met persoonsgegevens een risico inhoudt voor de rechten en vrijheden van natuurlijke personen”, oftewel niet meldingsplichtig. Uit niets blijkt dat OpenAI meer doet dan bijtrainen met je data (en de Terms of Use beperken haar rechten ook tot dat).
Hoe zit dat dan bij uploads naar andere clouddiensten? Ook daar begint het bij de vraag of die dienst geautoriseerd is. Zo niet, dan heb je volgens de definitie een datalek. Alleen zie je daar eerder clausules dat men de bestanden zelf mag herpubliceren, hergebruiken en delen met andere partijen. Dan komt de broninformatie dus elders terecht, buiten de macht en het zicht van betrokkenen.
Arnoud
Is niet alreeds een datalek het enkele feit dat de ‘former contractor’ een niet-geauthoriseerde verwerking heeft gedaan?
Of zelfs het feit dat die contractor ‘former’ was, en de data blijkbaar nog steeds had?
Het kan natuurlijk zo zijn dat die contractor op dat moment wel gewoon een subverwerker was en toegang mocht hebben tot het bestand. Dan is het uploaden naar chatgpt zonder toestemming wel een datalek, maar het hebben van het bestand niet.
Als dit een voormalige partner is die het bestand in chatgpt gegooid heeft dan zijn het eigenlijk 2 datalekken, maar dan lijkt het me onwaarschijnlijk dat je er achter komt…
De analyse vanuit AVG c.s. is steeds een methodisch beperkte omdat vooral vanuit bescherming van gegevens wordt geredeneerd. De feitelijke bescherming moet gaan over de persoonlijke levenssfeer, dat gaat ook over betrouwbaarheid en gerechtvaardigd vertrouwen. Om inzicht te geven in gebruik van gegevens door de overheid, zou toch op zijn minst de aansluiting op verantwoordelijkheid vanuit (formeel juridische) bevoegdheid moeten worden gehanteerd. Dat voorkomt verwarring als zouden verwerkingen opgedeeld kunnen worden in werkprocessen met verantwoordelijkheid bij onderdelen die niet als bestuursorgaan te herkennen zijn. Dat laatste is relevant want de discussie wordt steeds lastiger als rechtsverhoudingen (met maatregelen en waarborgen) met derden een rol gaan spelen terwijl de overeenkomsten niet door de verantwoordelijke bestuursorganen zijn aangegaan.
Het gebruik van AI-systemen waarbij het onderliggende model kan bijleren van de vertrouwelijke data vormt altijd een datalek en schending van de geheimhouding als dit zonder toestemming van de verwerkingsverantwoordelijke c.q. data-eigenaar gedaan wordt door een wederpartij. Elk AI-model dat bijgetraind wordt leert immers de samenhang van de trainingsdata kennen en zal dus (zeker als daar unieke kenmerken in zitten zoals persoon x met adres y heeft ziekte z) die data desgevraagd opdienen aan andere gebruikers van het AI-systeem dat het AI-model in kwestie gebruikt. Hieromtrent dient meer bewustwording te komen. @Arnoud: je lijkt dit risico structureel te ontkennen of als nogal theoretisch af te doen. Vermoedelijk zien de meeste juristen dit toch echt anders! In je boek AI and Algorithms vind ik hier (te) weinig over terug. Maar het raakt wel de Membership Inference attack (p.85)dat je zelf ook noemt als risico voor significante privacy-inbreuken. Zeker als bekend is geworden dat een bepaalde dataset werd geüpload naar een trainbare AI (zoals in de casus in dit blog), neemt het risico op succesvol kunnen doen aan membership inference toch nog verder toe?
Voor mij is het vrij fundamenteel dat ML-systemen niet “leren” in de zin van “aha, hier staat dat Arnouds telefoonnummer 020-6631941 is” zodat ze bij iedere vraag dat nummer op kunnen lepelen. Ze leren patronen, zoals “Arnoud/telefoon/020/6631/194” maar komen ook andere Arnouden tegen met patronen “Arnoud/mobiel/06/1234” en stellen dan antwoorden samen zoals “Arnouds directe mobiele nummer is 06-6631790”.
Nou Arnoud, dan ga je wat leren vandaag (no pun intended). Je zegt dat een LLM patronen leert, maar we weten niet hoe dat precies gebeurt. Een LLM heeft een zeer ingewikkelde architectuur van een groot aantal aan elkaar gekoppelde blokken waarvan we alleen globaal weten wat ze doen (zoals een self-supervision block). Elk blok heeft een aantal parameters (model weights). De ‘kennis’ van een LLM is vervat in 10^10 tot 10^12 van die parameters.
Je kunt een LLM laten bijleren door het stukje bij beetje data te voeren, de output van de LLM te vergelijken met de data zelf, en daarna de parameters aan te passen. Een kort voorbeeld op basis van de eerste zin van deze post: je geeft de LLM de tekst “Nou Arnoud, dan”, en vervolgens voorspelt de LLM dat daarna het woord “ga” komt met een kans van 30% of “mag” met een kans van 70%. Als je dan verklapt dat “ga” het juiste woord is, worden de parameters iets bijgesteld zodat de kans van 30% omhoog gaat.
Een LLM slaat uitdrukkelijk niet expliciet de kans op dat “Nou Arnoud, dan” wordt gevolgd door het woord “ga”. In dat geval zou het onmogelijk zijn om de brondata terug te halen. Wat wel gebeurt is dat de brondata wordt vervat in miljarden of biljoenen parameters die we niet kunnen interpreteren, en waarbij we geen idee hebben wat ze precies voorstellen.
Er zijn zogeheten data extraction aanvallen waarbij een LLM in een bepaalde context wordt geplaatst waarin hij delen van de brondata letterlijk oplepelt, zoals bijvoorbeeld is gedemonstreerd in dit artikel (Figure 1, 2 en 3 geven het idee goed weer). De LLM zal best fouten maken en hij zal niet elke zin van de brondata kunnen oplepelen, maar feit is dat delen van de brondata zijn vervat in de parameters op een manier die we niet begrijpen en niet kunnen controleren. Als een nieuwe methode wordt ontdekt om een aanval uit te voeren, wordt die vaak aan de voorkant gepatcht zodat je een bepaalde query niet meer mag draaien. De LLM blijft fundamenteel hetzelfde. Zodra er een nieuwe aanval wordt ontdekt of de parameters uitlekken, ligt de brondata dus alsnog (deels) op straat.
Ik weet dat data extraction attacks bestaan. De aanvallen van Su et al. zijn volgens mij ook gebruikt in de NYT-rechtszaak om aan te tonen dat LLM’s kopieermachines zijn. Maar de prompts komen vaak neer op de beginzin of -alinea geven en dan vragen om de rest, en gezien NYT artikelen best vaak voorkomen in internet-datasets, vind ik het niet gek dat daar dan de artikelen goeddeels mee terugkomen.
Ik zie het niet als bewijs van het algemene geval dat als je vraagt om een persoonsgegeven, je brondata terugkrijgt. Membership inference attacks werken algemeen niet best op de grote LLMs (Dual et al).
De werkwijze van LLMs is categorisch niet dat ze stukjes trainingsdata zoeken bij een query maar dat ze op basis van patronen nieuwe teksten samenstellen.
Uiteraard kunnen er altijd toekomstige aanvallen komen waarmee brondata gelekt kan worden. Dit is echter per definitie geen argument dat de beveiliging nú inadequaat is of dat iedere opname in een LLM een datalek is, de stelling waar J2CV mee kwam.
Bedrijfsvertrouwelijke gegevens horen niet in AI-modellen thuis omdat er altijd een kans bestaat dat specifieke vertrouwelijke info later aan andere gebruikers opgediend wordt (indicatief hierbij: zijn er aanbieders van trainbare AI-systemen die garanderen dat dit niet zal gebeuren?). Elk gebruik van een trainbaar AI-model door een partij die de geheimhouding van de vertrouwelijke info in kwestie zou moeten waarborgen is in die situaties dus een schending van de geheimhouding en dus ook een ongeoorloofde verstrekking (aan het AI-model en de exploitant daarvan) van persoonsgegevens als er persoonsgegevens deel van uitmaken. En dus een inbreuk in verband met persoonsgegevens (datalek) in de zin van de AVG. Volgens mij mag juridisch gezien aangenomen worden dat er een schending/datalek is zodra de gegevens aan het trainbare AI-model verstrekt worden omdat hierdoor direct de kans bestaat dat er op enig later moment (delen van die)gegevens voor derden beschikbaar komen. Het lijkt mij gelet op de onvoorspelbaarheid van wat er wanneer kan gebeuren althans nogal misplaatst om af te wachten tot dat lekken van de data naar een derde feitelijk plaats vindt en pas dan tot een datalek te concluderen. T.a.v. persoonsgegevens geldt dat zowel verwerkingsverantwoordelijke als verwerker de risico’s omtrent ongeoorloofde verstrekking dienen te beoordelen en maatregelen te treffen (overweging 83 AVG). Hierbij past het dat beide opdrachtgever en leverancier begrijpen dat de vertrouwelijke data in kwestie niet zo maar in alle AI-systemen gestopt mag worden, maar dat er zorgvuldig gekeken wordt welke AI-systemen zich wel en niet voor lenen. Omdat nog niet iedereen dit vanzelfsprekend vindt en er nog geen jurisprudentie hieromtrent is (toch?), lijkt het nodig dat opdrachtgevers hun contracten op dit punt aanscherpen. Dit is althans wat ik (op mijn werk) adviseer (en nu hier publiekelijk ook om dit te laten challengen).
Het zou ideaal zijn als dit soort risico’s echt niet zouden bestaan en iedereen lekker alles in AI-systemen mag steken om te voordelen daarvan te kunnen benutten. En misschien valt het technisch gezien inderdaad wel mee allemaal en is de kans normaliter echt heel klein dat trainingsdata naar derden lekt. Maar kansrekening is geen onderdeel van de AVG en dit technische verweer van Arnoud overtuigt daarom niet. Juridisch gezien wijst alles er vooralsnog op dat het als verwerker van andermans vertrouwelijke data verstandig is om op te letten wat je met welke AI-systemen doet als je de kans op gedoe, schadeclaims en verbeuren van contractuele boetes wilt voorkomen.
Ik ben sowieso benieuwd of de AVG ook geldt voor fictieve personen. 🙂 Als software ontwikkelaar heb ik namelijk een lange lijst van voornamen, achternamen en geboortedatums (en nog veel meer) van fictieve personen om als testdata te gebruiken. Deze data lijkt zeer realistisch te zijn en in sommige gevallen zitten er socialemediaaccounts (is dat een woord?) aan vast om als alternatieve login methodes te dienen. (OpenID en zo.)
Maar kan dat wel volgens de AVG? De data is namelijk best realistisch.
Ik had iets dergelijks. Voor het testen van medische archiefsoftware had ik een simulator geschreven, die op basis van de top 100 meest voorkomende (Engelse) voor- en achternamen fictieve personen genereerde. Zo’n beetje elk van de namen die er uitkwam bestond echt, en erger, was online terug te vinden in de Amerikaanse database van gedetineerden.
Wilde ik dit soort dingen voorkomen, dan moest ik juist gaan werken met “namen” gaan werken die uit rare tekenreeksten bestonden, dus geen “John Smith”, maar “Xrewrev GQuered” oid. En misschien is dat wel beter, omdat je daarmee gelijk doorhebt dat het om test data gaat (al mis je dan weer dingen die fout gaan in specifieke echt voorkomende namen, zoals O’neil–met een quote–of Ænæs–met de AE ligatuur, en dan liefst nog met een accentje erop)