Kan man faktiskt radera någon från en RAG-pipeline?

En begäran om registerutdrag kommer in. Du raderar källdokumentet och stänger ärendet. Personen finns fortfarande kvar på fyra andra ställen, och ett av dem kommer du inte åt.

Månaden börjar när mejlet landar

Artikel 12(3) ger dig en månad att besvara en begäran om registerutdrag, med möjlighet till förlängning med ytterligare två månader om begäran är komplex. Artikel 15 säger att du måste berätta för personen vilka uppgifter du har om hen. Artikel 17 säger att du under vissa givna omständigheter måste radera dem.

Inget av detta skrevs med retrieval-augmented generation i åtanke, och inget av det bryr sig.

Det arbetsflöde de flesta organisationer har är det de byggde 2018. Sök i filresurserna, sök i mejlarkivet, exportera det du hittar, radera det som uppfyller kriterierna, skriv brevet. Det var aldrig bekvämt men det var hanterbart, för det fanns en enda sanningskälla och kopiorna av kopiorna fanns åtminstone i filsystem man kunde inventera.

Sedan kopplade någon en RAG-pipeline till samma filresurser. Antalet ställen en person existerar på gick från ett till fem, och bara tre av dem finns i någons raderingsrutin.

De fem platserna, och vilka du kan nå

1. Källdokumenten. CV:t, mejltråden, kontraktet, supportärendet. Det här är vad din befintliga process hanterar, och den hanterar det tillfredsställande. Hanterbart.

2. Vektorindexet. Det här är det som glöms bort, och det är inget litet förbiseende.

När du tar in ett dokument delar du upp det i bitar och embeddar varje bit som en vektor. Den vektorn är inte en pekare till dokumentet — den är en förlustbehäftad men semantiskt trogen representation av själva texten, och den ligger i en separat datalagringsplats med sin egen livscykel. Raderar du källfilen finns vektorn kvar, glatt hämtningsbar, eftersom inget i en naiv ingestionspipeline propagerar raderingen bakåt.

Folk antar att en vektor är anonym eftersom den är en lista med flyttal. Det är den inte. Embedding inversion är ett aktivt forskningsområde och fungerar tillräckligt väl för att rekonstruera betydande delar av källtexten från enbart vektorn. Behandla embeddingar av personuppgifter som personuppgifter, för vid varje ärlig läsning av artikel 4(1) är det precis vad de är.

Hanterbart, men bara om du byggde för det. Du behöver stabila dokument-ID:n som förs vidare in i vektorlagret som metadata, och en raderingsväg som förgrenar sig från källan till indexet. Att i efterhand bygga in detta i en pipeline som sattes upp som en proof of concept är genuint smärtsamt, och de flesta RAG-driftsättningar i produktion idag sattes upp just som proof of concept.

3. Konversationsloggar. Varje prompt och varje svar, sparade för felsökning, utvärdering och upptäckt av missbruk. Om en anställd frågade assistenten om en kund och fick ett syntetiserat svar som innehöll den kundens uppgifter, ligger nu kundens personuppgifter i en logglagringsplats som din process för begäran om registerutdrag nästan säkert aldrig har sökt igenom.

Hanterbart, och till stor del en fråga om att erkänna att logglagringsplatsen finns och ge den en lagringsregel.

4. Cachar, säkerhetskopior, repliker. Prompt-cachar, hämtningscachar, den nattliga ögonblicksbilden av vektordatabasen, läsrepliken. Att radera primärlagret och lämna kopiorna kvar är inte radering. Det är radering från den enda platsen du råkade titta på.

Hanterbart med ansträngning, och det är här jag skulle koncentrera ansträngningen, för det är det misslyckande som är lättast att demonstrera för en tillsynsmyndighet och svårast att förklara bort.

5. Modellvikter. Om du finjusterade på personuppgifter — en LoRA-adapter över tio års supportärenden, säg — är personen nu utspridd över parametrar på ett sätt som ingen kan lokalisera eller ta bort.

Inte hanterbart. Det finns ingen raderingsoperation. Machine unlearning är ett aktivt forskningsfält, de publicerade teknikerna är approximativa, och ingen av dem ger dig en försäkran du skulle vilja sätta i skrift till en tillsynsmyndighet.

EDPB tittade på den angränsande frågan i yttrande 28/2024 och gav ingen ett generellt undantag. Huruvida en modell kan anses vara anonym är en bedömning från fall till fall, och den hänger på om personuppgifter kan extraheras eller en registrerad person särskiljas — vilket, med tanke på vad membership inference- och extraktionsattacker visar, inte är ett säkert standardantagande.

Den praktiska konsekvensen är tydlig: finjustera inte på personuppgifter. Inte för att det är förbjudet, utan för att du skapar en skyldighet du inte har någon mekanism för att fullgöra. Håll personuppgifter i hämtningslagret, där radering är ett tekniskt problem snarare än ett olöst forskningsproblem. RAG är den regelenliga arkitekturen nästan av en slump, förutsatt att du kopplat in raderingsvägen.

Det artikel 15 kräver som alla glömmer

Raderingshalvan får all uppmärksamhet. Åtkomsthalvan är i det tysta svårare.

En begäran om registerutdrag ber dig ange vilka personuppgifter du har om personen och varifrån de kommer. Om din pipeline tog in en uppsättning SharePoint-webbplatser eftersom en ordentlig avgränsning skulle ta tre veckor, kan du inte besvara den frågan. Inte "det tar ett tag att svara" — du kan strukturellt sett inte, för du visste aldrig vad som togs in.

Det är samma misslyckande som artikel 5(2), fast det kommer genom en annan dörr och med en namngiven person kopplad till sig.

Att skriva en rutin som håller för granskning

Den version som håller är kortare och mer ärlig än den version de flesta organisationer har:

• Inventera lagringsplatserna. Källsystem, vektorindex, konversationsloggar, cachar, säkerhetskopior. Namngivna, med en ansvarig och en lagringsregel var. Står det inte på listan kommer det inte att sökas igenom.

• Propagera via ID, inte via namn. Radering förgrenar sig från en stabil dokumentidentifierare. Att matcha på en persons namn över fem system misslyckas på grund av stavning, giftermål, och det faktum att människor delar namn.

• Logga raderingen, inte uppgifterna. Identifierare, skäl, godkännare, tidsstämplar per lagringsplats. Tillräckligt för att bevisa handlingen utan att behålla det du raderade.

• Ange vad du inte raderade, och varför. Uppgifter som omfattas av en lagstadgad lagringsskyldighet, och — om du finjusterade innan du visste bättre — modellen. Tillsynsmyndigheter reagerar avsevärt bättre på en dokumenterad begränsning än på en upptäckt sådan.

• Kör om den. En radering som lyckas en gång och sedan tyst går sönder vid nästa pipelineändring är värre än ingen radering alls, för då har du ett intyg som säger något annat.

Genvägen

Varje punkt ovan blir lättare i proportion till hur lite du tog in från början.

De organisationer som kommer att hantera detta väl är inte de med de mest sofistikerade raderingsverktygen. Det är de som klassificerade sin ostrukturerade data först, raderade det som saknade lagligt ändamål, och först därefter riktade en hämtningspipeline mot det som blev kvar.

De besvarar begäranden om registerutdrag mot ett dataunderlag de kan beskriva. Alla andra besvarar dem mot ett dataunderlag de hoppas att de kan beskriva.

Vill du veta vad som faktiskt finns i din ostrukturerade data, kör vi en kostnadsfri genomgång.

Ta hand om er där ute.

/A