Kan man egentlig slette en person fra en RAG-pipeline?

Der kommer en indsigtsanmodning. Du sletter kildedokumentet og lukker sagen. Personen findes stadig fire andre steder, og et af dem kan du ikke nå.

Måneden starter, når mailen lander

Artikel 12, stk. 3 giver dig en måned til at besvare en indsigtsanmodning, med mulighed for forlængelse med yderligere to måneder, hvis anmodningen er kompleks. Artikel 15 siger, at du skal oplyse personen om, hvad du opbevarer om vedkommende. Artikel 17 siger, at du under nærmere angivne omstændigheder skal slette det.

Intet af det var skrevet med retrieval-augmented generation for øje, og intet af det tager hensyn til det.

Den arbejdsgang, de fleste organisationer har, er den, de byggede i 2018. Søg i filområderne, søg i mailarkivet, eksportér det, du finder, slet det, der kvalificerer sig, skriv brevet. Det var aldrig behageligt, men det var håndterbart, for der var én kopi af sandheden, og kopierne af kopierne var i det mindste i filsystemer, man kunne opregne.

Så koblede nogen en RAG-pipeline til de samme filområder. Antallet af steder, en person findes, gik fra ét til fem, og kun tre af dem indgår i nogens sletteprocedure.

De fem steder, og hvilke du kan nå

1. Kildedokumenterne. CV'et, mailtråden, kontrakten, supportsagen. Det er det, din eksisterende proces håndterer, og den håndterer det tilstrækkeligt. Håndterbart.

2. Vektorindekset. Det er det, der bliver glemt, og det er ikke en lille forglemmelse.

Når du indlæser et dokument, deler du det op og indlejrer hver del som en vektor. Den vektor er ikke en pointer til dokumentet — den er en tabsbehæftet, men semantisk tro repræsentation af selve teksten, der ligger i et separat datalager med sin egen livscyklus. Slet kildefilen, og vektoren bliver liggende, klar til at blive hentet frem, for intet i en naiv indlæsningspipeline forplanter sletningen baglæns.

Folk antager, at en vektor er anonym, fordi den er en liste af decimaltal. Det er den ikke. Embedding inversion er et aktivt forskningsområde og virker godt nok til at rekonstruere væsentlige dele af kildeteksten alene ud fra vektoren. Behandl embeddings af personoplysninger som personoplysninger, for enhver ærlig læsning af artikel 4, stk. 1 siger, at det er, hvad de er.

Håndterbart, men kun hvis du har bygget det ind fra starten. Du skal have stabile dokument-ID'er, der føres med ind i vektorlageret som metadata, og en sletningssti, der forgrener sig fra kilde til indeks. At bygge det ind bagefter i en pipeline, der blev sat op som et proof of concept, er virkelig smertefuldt, og de fleste RAG-implementeringer i produktion i dag blev sat op som proofs of concept.

3. Samtalelogs. Hver eneste prompt og hvert eneste svar, gemt til fejlsøgning, evaluering og misbrugsdetektion. Hvis en medarbejder spurgte assistenten om en kunde og fik et sammensat svar med den kundes oplysninger, ligger kundens personoplysninger nu i et loglager, som din indsigtsanmodningsproces næsten helt sikkert aldrig har gennemsøgt.

Håndterbart, og mest et spørgsmål om at anerkende, at loglageret findes, og give det en opbevaringsregel.

4. Caches, backups, replikaer. Prompt-caches, retrieval-caches, det natlige snapshot af vektordatabasen, læsereplikaen. At slette originalen og lade kopierne stå er ikke sletning. Det er sletning fra det ene sted, du tilfældigvis kiggede.

Håndterbart med indsats, og det er her, jeg ville koncentrere indsatsen, for det er den fejl, der er lettest at påvise for en tilsynsmyndighed og sværest at bortforklare.

5. Modelvægte. Hvis du finjusterede på personoplysninger — en LoRA-adapter over ti års supportsager, for eksempel — er personen nu spredt ud over parametre på en måde, ingen kan lokalisere eller fjerne.

Ikke håndterbart. Der findes ingen sletningsfunktion. Machine unlearning er et aktivt forskningsfelt, de publicerede teknikker er tilnærmelsesvise, og ingen af dem vil give dig en garanti, du ville ønske at give skriftligt til en tilsynsmyndighed.

EDPB kiggede på det beslægtede spørgsmål i udtalelse 28/2024 og gav ingen nogen generel undtagelse. Om en model kan anses for anonym, er en konkret vurdering fra sag til sag, og den afhænger af, om personoplysninger kan udtrækkes, eller en registreret kan udpeges — hvilket, i lyset af hvad membership inference- og extraction-angreb viser, ikke er en sikker standardantagelse.

Den praktiske konsekvens er kontant: finjustér ikke på personoplysninger. Ikke fordi det er forbudt, men fordi du skaber en forpligtelse, du ikke har nogen mekanisme til at indfri. Hold personoplysninger i retrieval-laget, hvor sletning er et teknisk problem snarere end et uløst forskningsproblem. RAG er den regelkonforme arkitektur næsten ved et tilfælde, forudsat at du har koblet sletningsstien til.

Det artikel 15 beder om, som alle glemmer

Sletningsdelen får al opmærksomheden. Adgangsdelen er i det stille sværere.

En indsigtsanmodning beder dig oplyse, hvilke personoplysninger du opbevarer om personen, og hvor de stammer fra. Hvis din pipeline indlæste en række SharePoint-sites, fordi ordentlig afgrænsning ville tage tre uger, kan du ikke besvare det spørgsmål. Ikke "det tager lidt tid at svare" — du kan strukturelt set ikke, for du vidste aldrig, hvad der kom ind.

Det er den samme fejl som artikel 5, stk. 2, der kommer gennem en anden dør og med en navngiven person hæftet på.

At skrive en procedure, der kan tåle eftersyn

Den version, der holder, er kortere og mere ærlig end den version, de fleste organisationer har:

• Opregn lagrene. Kildesystemer, vektorindeks, samtalelogs, caches, backups. Navngivet, med en ejer, hver med en opbevaringsregel. Er det ikke på listen, bliver det ikke gennemsøgt.

• Forplant efter ID, ikke efter navn. Sletning forgrener sig ud fra en stabil dokumentidentifikator. Matchning på en persons navn på tværs af fem systemer fejler på stavemåde, på giftermål, og på det faktum, at folk deler navne.

• Log sletningen, ikke dataene. Identifikator, begrundelse, godkender, tidsstempler pr. lager. Nok til at bevise handlingen uden at beholde det, du slettede.

• Angiv, hvad du ikke slettede, og hvorfor. Data underlagt en lovbestemt opbevaringspligt, og — hvis du finjusterede, før du vidste bedre — modellen. Tilsynsmyndigheder reagerer betydeligt bedre på en dokumenteret begrænsning end på en, der bliver opdaget.

• Kør det igen. En sletning, der lykkes én gang og i stilhed brydes af den næste pipeline-ændring, er værre end ingen sletning, for du har et certifikat, der siger noget andet.

Genvejen

Hvert eneste punkt ovenfor er lettere i forhold til, hvor lidt du indlæste.

De organisationer, der vil håndtere dette godt, er ikke dem med det mest sofistikerede sletteværktøj. Det er dem, der klassificerede deres ustrukturerede data først, slettede det, der ikke havde noget lovligt formål, og først derefter rettede en retrieval-pipeline mod det, der var tilbage.

De besvarer indsigtsanmodninger mod et korpus, de kan beskrive. Alle andre besvarer dem mod et korpus, de håber, de kan beskrive.

Hvis du vil vide, hvad der egentlig ligger i dine ustrukturerede data, kører vi en gratis gennemgang.

Pas på derude.

/A