Privatliv er det, der er tilbage, efter at systemet har lært at glemme

Retten til at blive slettet er ikke en knap mærket "slet". I moderne systemer er det et disciplineret spørgsmål om kopier, afledte data, beviser,...

Privatliv er det, der er tilbage, efter at systemet har lært at glemme

At glemme er ikke det modsatte af at huske

En papirjournal har et betryggende synligt liv. Den ankommer, bliver lagt et sted, bliver kopieret, hvis nogen har en kopimaskine, og ender til sidst i en makulator eller et arkiv. Den svære del kan være at beslutte, om den skal destrueres, men selve objektet er på behagelig vis begrænset. En digital registrering er mindre høflig. Den kan være gemt som en række, en vedhæftning, et søgeindeks, en meddelelsesforhåndsvisning, en backup-blok, en revisionspost, en funktion i et modelinput, en vektor i et embedding-lager, et cachelagret svar eller en værdi, der er rejst ind i en anden organisations system. Det er ikke nok at spørge, hvor originalen lever. Det mere nyttige spørgsmål er, hvad der er lavet af den, hvad der stadig gør det muligt at identificere en person, og hvilket formål hvert tilbageværende spor tjener.

Det er den praktiske værdighed i retten til sletning. Den kaldes ofte retten til at blive glemt, hvilket er en levende formulering, men en ufuldkommen en. Menneskelig glemsel er tilfældig, delvis og fuld af pinlige tilbagevenden. En lovlig sletningsproces bør være bevidst. Den bør kunne skelne mellem en registrering, der skal fjernes, og en registrering, der skal bevares, fordi loven kræver det, et omtvistet krav, der skal forblive tilgængeligt for et juridisk forsvar, og en teknisk rest, der kan isoleres indtil dens planlagte udløb. Den bør også modstå en nyttig virksomhedsinstinkt: at behandle sletning som en skærmtilstand snarere end en systemegenskab.

Forordningen om databeskyttelse (GDPR) lover ikke, at alle elementer knyttet til en person forsvinder på anmodning. Artikel 17 fastsætter grunde, hvorpå en dataansvarlig skal slette personoplysninger uden unødig forsinkelse, herunder hvor oplysningerne ikke længere er nødvendige til de formål, hvortil de blev indsamlet eller behandlet, hvor samtykke er trukket tilbage, og der ikke er noget andet retsgrundlag, og hvor behandlingen har været ulovlig. Samme artikel sætter grænser. Sletning finder ikke anvendelse, hvor behandling er nødvendig, for eksempel for ytrings- og informationsfrihed, en retlig forpligtelse, opgaver i samfundets interesse under visse omstændigheder, folkesundhedsmæssige hensyn, arkivering, forskning eller statistik underlagt garantier eller retskrav. Det er ikke et smuthul i et løfte. Det er rettens faktiske form.

Så spørgsmålet for en systemejer er ikke: "Kan vi slette data?" Næsten ethvert system kan slette noget. Spørgsmålet er, om organisationen kan forklare, for en bestemt anmodning og et bestemt behandlingsformål, hvilke data den har, hvad der er sket med disse data, hvad den er forpligtet til eller berettiget til at beholde, hvilke downstream-modtagere der skal informeres, og hvordan den gennemførte handling kan kontrolleres. Forskellen lyder proceduremæssig. I praksis er den arkitektonisk. Et produkt, der kun ved, hvordan man tilføjer information, vil opdage, at sletning er en meget dyrere funktion.

Dette er især skarpt for AI-systemer, men det er ikke begrænset til AI. Søgning, analyser, kundesupport, identitet, sikkerhedsovervågning og dokumentstyring producerer alle afledte elementer. En model giver blot problemet nye navne: tokens, gradienter, embeddings, hentningsindekser, prompter og output. Ingen af disse etiketter opløser det underliggende spørgsmål om, hvorvidt en fysisk person forbliver identificerbar. Et teknisk udtryk besvarer heller ikke stille det juridiske spørgsmål. Et embedding er ikke automatisk anonymt, fordi det er svært at læse. En log er ikke automatisk nødvendig, fordi den er nyttig. En backup er ikke automatisk undtaget, fordi den er ubelejlig.

Privatliv efter glemsel er derfor ikke en blank side. Det er den resterende tilstand, der forbliver, efter at en organisation har truffet en lovlig, proportional og verificerbar beslutning om, hvad der ikke længere skal behandles. Kvaliteten af den resterende tilstand fortæller folk langt mere om et system end tilstedeværelsen af en sletteknap nogensinde vil.

Retten har betingelser, og det gør den stærkere

Europæisk databeskyttelsesret beskrives til tider, som om den giver den enkelte en universel nødknap. Det billede er pænt nok til en præsentation og forkert nok til at skabe problemer. Artikel 17 er knyttet til formålet, det retlige grundlag og omstændighederne for behandlingen. Den indeholder en rettighed, forpligtelser for dataansvarlige og undtagelser, der beskytter andre rettigheder og offentlige interesser. Et ansvarligt svar begynder med at fastslå anmoderens identitet, hvor det er nødvendigt, forstå de data og det behandlingsformål, der er tale om, og vurdere, om et grundlag i artikel 17 og en undtagelse finder anvendelse. Svaret kan være sletning. Det kan være et begrundet afslag helt eller delvist. Det kan være begrænsning af behandlingen, mens en tvist løses. Det kan også være en anmodning, der peger på et system, som organisationen ikke kontrollerer.

Dette er ikke en grund til at gøre en registrerets anmodning til en lille forhindringsbane. GDPR kræver, at dataansvarlige letter udøvelsen af rettigheder. Artikel 12 kræver, at oplysninger og meddelelser om foranstaltninger, der er truffet i forbindelse med en anmodning, er kortfattede, gennemsigtige, forståelige og let tilgængelige. Den kræver generelt, at oplysninger om foranstaltninger gives uden unødig forsinkelse og under alle omstændigheder senest en måned efter modtagelsen. Fristen kan forlænges med yderligere to måneder, hvor det er nødvendigt under hensyntagen til kompleksiteten og antallet af anmodninger, men den dataansvarlige skal underrette personen om forlængelsen og begrundelsen herfor inden for den første måned. Et system, der ikke kan identificere sine egne dataflow før i tredje måned, har ikke fundet et proceduremæssigt forsvar. Det har fundet et styringsproblem.

Det Europæiske Databeskyttelsesråds vejledning til små og mellemstore virksomheder gør det operationelle punkt klart: Personer kan anmode om sletning under særlige omstændigheder, og organisationer bør have procedurer for at håndtere anmodninger om rettigheder. En procedure er ikke en juridisk vurdering gemt på et fælles drev. Det er en arbejdsgang fra anmodning til beslutning til gennemførelse. Den omfatter de roller, der har beføjelse til at træffe en beslutning, de datakort, der giver dem mulighed for at se relevant behandling, de leverandører og modtagere, der eventuelt skal underrettes, de opbevaringsfrister, der forklarer en undtagelse, og den dokumentation, der gør det muligt for en senere kontrollør at forstå, hvad der blev gjort.

Domstolen har bidraget til at gøre en anden sondring synlig. Dens domme om afindeksering vedrører præsentationen af links i søgemaskiner, ikke en instruks om at slette den underliggende offentliggørelse fra kildewebstedet. I Google Spain fastslog Domstolen, at en operatør af en søgemaskine kan være ansvarlig for behandling af personoplysninger, der fremgår af websteder, som tredjeparter har offentliggjort, og at en registreret under visse omstændigheder kan anmode om fjernelse af links fra en resultatliste, der vises efter en søgning på personens navn. I senere sager behandlede Domstolen blandt andet følsomme data, det territoriale anvendelsesområde for afindeksering og urigtige oplysninger. Disse sager gør ikke enhver uønsket kendsgerning til et krav om sletning. De viser, hvorfor et system skal navngive det lag, der er på spil: kildeoffentliggørelse, indeks, resultatliste, cache, uddrag eller en anden kopi.

Den lagdisciplin gælder også internt i organisationer. En medarbejder kan anmode en dataansvarlig om at slette en kontaktoplysning, der ikke længere er nødvendig til et rekrutteringsformål. Den dataansvarlige kan være nødt til at vurdere en separat opbevaringspligt for løn- eller ligebehandlingsdokumentation. Et offentligt organ kan behandle en registrering under en lovbestemt opgave og skal vurdere den gældende lovgivning frem for at gentage et svar fra den private sektor. En udgiver kan være nødt til at afveje ytrings- og informationsfriheden. Resultatet kan ikke afgøres alene ud fra database-terminologi.

Det er fristende at ærgre sig over betingelserne, fordi de forhindrer et enkelt løfte. Men de gør løftet meningsfuldt. En ret, der ignorerer juridiske forpligtelser, andre grundlæggende rettigheder og den praktiske forskel mellem systemer, ville kollapse til et ritual. Den europæiske tilgang kræver en ansvarlig beslutning, ikke en teatralsk en. Det kræver mere arbejde. Det gør også et afslag muligt at anfægte og en sletning troværdig.

Sletning begynder med at lokalisere behandlingsfladerne. Diagrammet er et systemkort, ikke en påstand om, at hver flade har samme juridiske behandling.

En registrering kan forsvinde fra skærmen og forblive i systemet

Den letteste sletningsfejl er velkendt for enhver, der har bygget en applikation: fjern et element fra produktgrænsefladen, lad de underliggende data blive i et lager, og antag, at opgaven er løst, fordi almindelige brugere ikke længere kan se det. Nogle gange er en blød sletning præcis det rigtige operationelle design. Det kan bevare en kort fortrydelsesperiode, gøre replikering sikker eller undgå at bryde en relation, der skal løses. Men blød sletning er ikke sletning, blot fordi grænsefladen er blevet mere stille. Dens brug skal være forbundet med et defineret formål, en opbevaringsperiode, adgangskontrol og en senere handling, der faktisk ændrer datatilstanden.

Hård sletning har sine egne begrænsninger. Sletning af en række kan efterlade et søgeindeks indtil næste indekseringscyklus. Et objektlager kan have versionsstyring. En cache til indholdslevering kan indeholde et svar indtil udløb eller invalidering. En meddelelseskø kan indeholde en hændelse, der endnu ikke er behandlet. Et datavarehus kan have indlæst et øjebliksbillede. En tjeneste kan have overført dataene til en processor, en underprocessor eller en modtager. Den praktiske lektion er ikke, at sletning er umulig. Det er, at en organisation har brug for et inventar med tilstrækkelig præcision til at skelne disse flader og en politik, der angiver, hvad der sker på hver enkelt.

Der er en yderligere sondring mellem indhold og bevis. En kundeservicebillet kan indeholde en persons besked. Et system kan have brug for en registrering af, at en billet eksisterede, blev løst og blev slettet under en godkendt regel. At beholde hele beskeden for evigt for at bevise, at den blev slettet, er et lille bureaukratisk mesterværk, men ikke en privatlivskontrol. Et bedre design bevarer kun det minimale bevis, der er nødvendigt for ansvarlighed, adskilt fra det indhold, der ikke længere har et formål. Det bevis kan være en anmodningsidentifikator, beslutningstype, fuldførelsestidspunkt, gældende opbevaringskategori og de berørte systemer. Designet afhænger af organisationen. Princippet gør ikke: bevis bør ikke genskabe de unødvendige personoplysninger.

Backups fortjener det samme klare sprog. En backup kan være nødvendig for tilgængelighed, sikkerhed eller katastrofegendannelse. Det er stadig behandling. Det praktiske spørgsmål er, om backup'en er separat tilgængelig, hvor længe den forbliver gendanbar, hvem der kan gendanne den, om den er inkluderet i den normale sletningsproces, og hvordan et gendannet miljø forhindres i stille at genindføre data, der siden er blevet fjernet fra det aktive system. En rimelig politik kan stole på backup'ens definerede rotationsperiode frem for at ændre hver historisk backup-blok individuelt. Men en politik skal sige det, beskytte adgangen i mellemtiden og sikre, at gendannelse følger den aktuelle datatilstand, hvor det er muligt. 'Det er i backup' beskriver et problem. Det er ikke et svar på det.

Logs ligner hinanden. Sikkerheds- og driftslogs kan være afgørende. De kan være den eneste kilde til oplysninger om en adgang, et mislykket godkendelsesforsøg eller en produktionsændring. De kan også indeholde identifikatorer, adresser, anmodningsindhold eller fragmenter af indhold, som aldrig var nødvendige for diagnosticering. God logdesign minimerer ved indsamling, redigerer eller pseudonymiserer, hvor det er passende, adskiller følsomme data fra hændelsesmetadata, begrænser adgang og anvender opbevaringsplaner. At forsøge at finde alle følsomme felter under en anmodning om sletning er muligt, men det er en dårlig erstatning for at beslutte på designtidspunktet, hvad loggen aldrig skulle have indeholdt.

En teknisk ejer behøver ikke at love en øjeblikkelig, ensartet sletning på alle enheder for at handle ansvarligt. De skal dog kunne redegøre for livscyklussen: hvad der bliver utilgængeligt med det samme, hvad der fjernes i næste behandlingskørsel, hvad der bevares under en dokumenteret opbevaringsplan, hvad der forbliver beskyttet indtil udløb, og hvad der sker, hvis en gendannelsesoperation finder sted. Den redegørelse giver en person, en tilsynsmyndighed og en operatør noget konkret at undersøge. En grøn toastmeddelelse giver dem meget lidt.

Afledte data er ikke en smutvej

Moderne systemer transformerer ofte personoplysninger, før de bruger dem. De udtrækker en dato fra et dokument, klassificerer en besked, beregner en score, udleder et sprog, opretter et søgeindeks, producerer et resumé, forbinder to konti eller omdanner tekst og billeder til vektorer, der bruges til lighedssøgning. Disse transformationer kan være nyttige. De kan også få en organisation til at føle, at den er kommet ud over personoplysninger. Det er ikke nødvendigvis tilfældet.

GDPR er teknologineutral. Betragtningerne forklarer, at pseudonymiserede oplysninger, der kan henføres til en fysisk person ved hjælp af yderligere oplysninger, bør betragtes som oplysninger om en identificerbar fysisk person. De forklarer også, at identificerbarhed skal tage højde for alle midler, der med rimelighed kan forventes at blive brugt, af den dataansvarlige eller en anden person, under hensyntagen til faktorer som omkostninger, tid, tilgængelig teknologi og teknologisk udvikling. Spørgsmålet er ikke, om en repræsentation ligner et navn i et regneark. Det er, om den vedrører en identificeret eller identificerbar person i den faktiske kontekst.

En embedding gør dette punkt på en nyttig måde akavet. I et hentesystem kan et dokument opdeles i bidder og repræsenteres som numeriske vektorer, så en forespørgsel kan finde semantisk lignende materiale. Vektoren er ikke et læsbart afsnit. Den kan dog være knyttet til et kildedokument, en lejer, en bruger, adgangskontrol, et metadatafelt eller en hentenøgle. Den kan gøre det muligt for systemet at vælge personligt materiale som svar på en forespørgsel. Organisationen kan ikke kalde den anonym, blot fordi et menneske ikke kan rekonstruere en sætning ved at se på en koordinatliste. Den skal vurdere repræsentationen, de tilknyttede data, koblingsmidlerne og behandlingsformålet.

Det samme gælder for en afledt score. En risikoscore, præferencekategori eller berettigelsesindikator kan indeholde mindre rå detaljer end kildedataene og stadig have alvorlige konsekvenser for personen. Det kan være personoplysninger, hvis det vedrører en identificeret eller identificerbar person. At slette kilden, mens man beholder en score, der fortsat former en beslutning, er ikke et rent svar. Det kan blot flytte personen ind i en mere uigennemsigtig form. Systemet har brug for en regel for afledte data: hvilke der slettes med kilden, hvilke der genberegnes, hvilke der ikke længere må bruges, hvilke der skal bevares under en separat forpligtelse, og hvem der beslutter.

Der findes ingen universel teknisk test, der afgør alle afledte data. Nogle aggregerede statistikker kan være anonyme. Nogle kan fortsat være sårbare over for udskillelse eller sammenkædning. Nogle modelparametre kan ikke med rimelighed tilskrives en enkeltperson i en given kontekst. Andre kan være forbundet med træningsdata, en snævert afgrænset model eller en angrebsflade, der ændrer vurderingen. GDPR’s begreb om anonyme oplysninger er ikke en dekorativ etiket for data, der er gjort besværlige at fortolke. Den dataansvarlige skal foretage en vurdering, der er forankret i midlerne til og konteksten for identifikation.

Den usikkerhed er ikke en grund til at beskrive alle afledte data som permanent problematiske. Den er en grund til at føre oprindelsesregistrering. Et team bør vide, hvilke inputkollektioner der blev brugt til en feature store, et indeks, en træningskørsel eller en rapporteringstabel; hvilke versioner af et afledt produkt der blev produceret; hvilke systemer der forbruger dem; og hvilken reaktion en ændring i kilden skal udløse. Oprindelsesregistrering gør et ubehageligt spørgsmål til en afgrænset ingeniøropgave. Uden den bliver hver anmodning om rettigheder en arkæologisk ekspedition gennem jobnavne, storage buckets og nogens erindring om en migrering for to vintre siden.

Machine learning tilføjer et vanskeligt spørgsmål, ikke en magisk fritagelse

Machine learning gør sletning vanskelig, fordi træning ikke er en arkiveringsoperation. Et træningseksempel kan påvirke parametre gennem en lang sekvens af opdateringer sammen med mange andre eksempler. En udrullet model kan være kopieret til flere miljøer. En senere model kan være finjusteret fra en tidligere. Et team kan bruge evalueringsdata, prompts, retrieval-korpora og feedback-logfiler, der hver følger forskellige livscyklusser. Hvis en persons data er kommet ind i et sådant system, kan en organisation ikke ansvarligt svare med et skuldertræk om matematik. Den kan heller ikke ærligt love, at en enkelt databasesletning fjerner al mulig indflydelse fra hver parameter.

Det første skridt er at adskille systemerne. Et retrieval-korpus er ikke en trænet model. Hvis et dokument bruges som kilde til retrieval, kan sletning indebære at fjerne eller deaktivere dokumentet, dets chunks, metadata og indeksposter og derefter kontrollere, at retrieval ikke længere når det. En prompt-log er ikke en embedding-store. Et finjusteringsdatasæt er ikke et sikkerhedsrevisionsspor. Et modelcheckpoint er ikke en aktuel kildepost. Den korrekte reaktion kan være forskellig for hver overflade, men en reaktion kan ikke designes, før overfladerne er navngivet.

For træningsdata kan den lovlige og tekniske analyse kræve en beslutning om, hvorvidt genoptræning, erstatning, begrænsning, opbevaring eller en anden foranstaltning er passende. Forskning i machine unlearning er relevant, fordi den undersøger metoder til at reducere indflydelsen fra bestemte data uden at genoptræne en model fra bunden. Det er ikke et generelt certifikat for, at et system har glemt. Metoder har antagelser, modelklasser, databetingelser og verifikationsbegrænsninger. En organisation bør ikke markedsføre en eksperimentel teknik som en universel implementering af artikel 17. Den bør heller ikke vente på en perfekt teknik, før den designer bedre datakontroller.

Bedre kontroller begynder upstream. Minimer de indsamlede data. Adskil personoplysninger fra træningsmateriale, hvor det tilsigtede formål tillader det. Fastsæt en opbevaringsperiode, før akkumulering gør spørgsmålet følelsesmæssigt dyrt. Behold versionsregistrerede optegnelser over datasæt og træningskørsler. Gør opt-in eller andre lovlige betingelser eksplicitte, hvor de er det relevante grundlag. Undgå, at et produktionspromptarkiv stille og roligt bliver et korpus til modeludvikling. Hold evaluerings- og supportmateriale adskilt fra træningsdata. Jo mindre et system er afhængigt af ukendt oprindelse, desto mere præcist kan det besvare et sletningsspørgsmål.

Der er også en grænse for ordet ’indflydelse’. En person kan være bekymret for, at en tekst engang var en del af et træningssæt. Et teknisk team kan muligvis fastslå, at kildeoptegnelsen blev fjernet fra et aktuelt korpus, men ikke bevise, i bred filosofisk forstand, at intet spor af indflydelse er tilbage i nogen parameter i en historisk model. Privatlivsretten bliver ikke lettere, når en organisation erstatter en konkret beskrivelse med metafysik. Forpligtelsen er at vurdere behandlingen, grundlaget og foranstaltningerne i henhold til loven. Organisationen bør forklare rækkevidden af sin konklusion, de systemer, den dækker, og den resterende begrænsning. Præcision er venligere end et overdrevet løfte.

For AI-udbydere ligger den praktiske byrde ofte lige så meget hos indkøb som hos teknik. En leverandør bør kunne forklare, hvad den gør med prompts, uploadede filer, telemetri og valgfri feedback; hvilke af disse der bruges til træning eller serviceforbedring; hvilke opbevaringskontroller der findes; hvordan en kunde kan få oplysninger, der er nødvendige for at besvare rettighedsanmodninger; og hvad der sker i et delt versus et dedikeret miljø. En kontrakt, der blot siger ’GDPR-kompatibel’, har ikke leveret de oplysninger, der er nødvendige for at drive en sletningsproces. Den har leveret et adjektiv.

Søgemaskiner lærer os en nyttig lektion om lag

EU-Domstolens retspraksis om afindeksering er nyttig her netop, fordi den er snævrere end det populære udtryk ’retten til at blive glemt’. Sagerne handler om, hvorvidt og under hvilke betingelser en søgemaskine skal fjerne links fra navnebaserede resultater. De skaber ikke en simpel magt til at ændre historien ved dens kilde. Denne sondring viser, at privatlivsspørgsmål ofte handler om, hvordan oplysninger gøres tilgængelige, forbindes og forstærkes, ikke kun om, hvorvidt en optegnelse engang eksisterede.

I Google Spain overvejede Domstolen links i en søgemaskines resultatliste til sider offentliggjort af en tredjepart. Afgørelsen gjorde det klart, at en søgemaskines aktivitet kan udgøre behandling af personoplysninger, og at operatøren under særlige betingelser kan være forpligtet til at fjerne links fra resultater, der vises efter en søgning på en persons navn. Afgørelsen var ikke en ordre til avisen, der offentliggjorde de oprindelige meddelelser. En systemejer, der ser på en intern vidensbase, kan lære af dette: søgeindekser, forhåndsvisninger og resultatrangering er behandlingslag med deres egne konsekvenser.

GC m.fl. behandlede anmodninger om at fjerne links til websider med følsomme personoplysninger. Domstolen behandlede den afvejning, der er involveret, og de forpligtelser, der kan opstå for en søgemaskineoperatør. Google mod CNIL behandlede territorialt anvendelsesområde og fastslog under omstændighederne i den sag, at EU-retten ikke krævede afindeksering på alle versioner af en søgemaskine på verdensplan, mens den krævede effektive foranstaltninger til at forhindre eller seriøst afskrække adgang fra medlemsstater til links, der er fjernet fra EU-versioner. TU og RE vedrørte en anmodning om angiveligt unøjagtige oplysninger og præciserede elementer af bevisbyrden og behandlingen af forhåndsvisningsbilleder. Disse domme er faktaspecifikke juridiske afgørelser, ikke en implementeringsliste. Tilsammen udgør de et systemisk punkt: linket, resultatlisten, billedforhåndsvisningen og den oprindelige side har ikke automatisk samme retsmiddel.

Det punkt gælder også andre steder. En virksomhedsportal kan lovligt opbevare en kildeoptegnelse til et begrænset formål, mens adgang gennem en bred søgeflade er uforholdsmæssig. Et teknisk supportsystem kan have brug for en beskyttet revisionspost, mens dens autocomplete-forhåndsvisning ikke bør vise en tidligere kundes oplysninger til en stor gruppe. Et dokument kan blive fjernet fra et hentningskorpus, mens et modelgenereret resumé forbliver i et andet lager. Det rigtige svar er ikke at erklære hvert lag identisk. Det er at forstå, hvordan laget ændrer eksponering, formål og risiko.

Den advarer også mod en populær genvej: at antage, at synlighed er det eneste privatlivsproblem. En registrering kan være teknisk skjult og stadig blive behandlet, forespurgt, profileret, overført eller gendannet. Omvendt kan en organisation have brug for en nøje afgrænset registrering for at kunne dokumentere, at den reagerede korrekt, beskytte et retskrav eller opfylde en lovbestemt pligt. Privatliv er ikke en konkurrence om at producere færrest mulige data under alle tænkelige omstændigheder. Det er en disciplin med formål, nødvendighed, proportionalitet og kontrol.

Derfor bør en sletningsoversigt omfatte hentnings- og præsentationsveje. Spørg, hvilke indekser der bærer registreringen, hvilke caches der serverer den, hvilke eksporteringer der inkluderer den, hvilke API'er der returnerer den, hvilke afledte felter der bruges til at rangere eller anbefale, og hvilke gendannelsesveje i sikkerhedskopier der kan gøre den levende igen. Listen bliver ikke elegant. Den bliver mere nyttig end elegance.

Demonstration er forskellig fra påstand

Når et system hævder, at det kan slette data, er der to separate spørgsmål. Det første er, om designet har en legitim, dokumenteret vej til at gøre det. Det andet er, om en organisation kan demonstrere, at vejen blev fulgt for en bestemt anmodning uden at bevare mere personligt materiale, end demonstrationen kræver. Det første er en produktkapacitet. Det andet er ansvarlighed.

En nyttig sletningsregistrering er bevidst beskeden. Den behøver ikke at gengive en persons hele anmodning, dokumenter eller kontohistorik i en ny compliance-database. Den kan registrere en anmodningsreference, resultatet af identitetsverifikationen, hvor det er relevant, anmodningskategorien, relevante systemer, beslutningen og den juridiske begrundelse på et passende niveau, handlingsdatoer, undtagelser eller opbevaringsgrunde, meddelelser til modtagere, hvor det kræves, og status for asynkron sletning eller udløb af sikkerhedskopier. De præcise felter afhænger af den dataansvarlige og konteksten. Det vigtige er, at en senere revisor kan se vejen uden at rekonstruere det følsomme indhold fra fragmenter.

Verifikation bør matche dataoverfladen. En live applikationsregistrering kan kontrolleres ved at bekræfte, at et autoriseret opslag ikke længere returnerer den. Et hentningssystem kan testes med den oprindelige identifikator og relevante forespørgselsmønstre, mens man undgår brede forsøg på at genskabe personligt indhold. Et indeks kan rapportere sin sletningstilstand. En kø kan vise fuldførelse. En sikkerhedskopiproces kan vise, at et gendannelsesbillede er beskyttet under sin opbevaringsregel, og at gendannelse anvender en aktuel sletningslog eller tilsvarende kontrol. Verifikationen behøver ikke at bevise en metafysisk negation. Den skal levere beviser, der står mål med den påstand, der fremsættes.

Der er en beskeden fælde her. Et team kan bygge et imponerende dashboard med alle grønne lys og uden nogen stabil relation til arbejdet. Et meningsfuldt dashboard navngiver dataoverfladen, handlingen, tilstanden, ejeren, beviset og den næste gennemgang. Det gør det muligt at skelne mellem "anmodning accepteret", "live registrering slettet", "meddelelse til modtager afventer", "sikkerhedskopi afventer udløb" og "opbevaret under juridisk forpligtelse". Disse tilstande har forskellige betydninger. At kollapse dem til "slettet" forvandler usikkerhed til user-interface-design.

Dokumenterbar sletning afhænger også af ændringsstyring. Et kildesystem kan blive erstattet, en processor tilføjet, et indeksformat ændret, en ny analysedestination introduceret, eller en AI-leverandørs opbevaringspolitik revideret. Hvis sletningsproceduren ikke opdateres med disse ændringer, beskriver proceduren gradvist et system, der ikke længere eksisterer. Resultatet er velkendt fra enhver operationel disciplin: en smuk runbook og en reel service, der bevæger sig i modsatte retninger. At teste en lille stikprøve af vejen regelmæssigt, inklusive det akavede system, er normalt mere afslørende end at bestille et stort assurance-dokument, som ingen kan udføre.

For en offentlig myndighed eller en reguleret virksomhed er dette ikke et snævert anliggende for privatlivskontoret. Databeskyttelsesrådgiveren kan vejlede om fortolkningen, men engineering ejer grænseflader og sletningsmekanik, produkt ejer formålet og brugerforløbet, indkøb ejer informationsforpligtelserne over for leverandører, sikkerhed ejer adgangs- og gendannelseskontroller, og drift ejer udførelsen under pres. En enkelt ejer kan ikke inspicere hvert lag alene. Et lag uden ejer bliver ikke sikkert af at være svært at tale om.

En forsvarlig proces registrerer sin beslutning og sin udførelse uden at skabe en anden, unødvendig biografi om personen.

Opbevaring er den anden halvdel af sletning

Mange sletningsproblemer begynder længe før en anmodning. De begynder, når et system slet ikke har en opbevaringsbeslutning. Data ankommer, fordi de måske kan blive nyttige. Logfiler bliver permanente, fordi lagring er billig. Eksporter bevares, fordi en fremtidig revision måske vil spørge til dem. Træningsdata akkumuleres, fordi en senere model måske kan få gavn af dem. Hver beslutning virker harmløs isoleret set. Tilsammen gør de organisationen til ejer af et stort, dårligt forstået arkiv og gør enhver sletningsanmodning dyrere, mere usikker og mere omstridt.

GDPR's princip om opbevaringsbegrænsning siger, at personoplysninger bør opbevares i en form, der gør det muligt at identificere de registrerede i ikke længere tid, end det er nødvendigt til de formål, hvortil de behandles, med mulighed for længere opbevaring til arkivering i offentlighedens interesse, videnskabelige eller historiske forskningsformål eller statistiske formål, hvor der findes passende garantier. Princippet foreskriver ikke én kalender for alle organisationer. Det kræver en vurdering knyttet til formålet. En opbevaringsplan bør derfor angive datakategorier, formål, retsgrundlag, normal periode, udløsende begivenhed, undtagelse, bortskaffelseshandling, ejer og revisionstidspunkt. "Så længe det er nødvendigt" er et princip. Det bliver kun til en operationel regel, når nogen kan sige nødvendigt for hvad, indtil hvornår, og besluttet af hvem.

Den struktur er nyttig for AI, fordi den forhindrer, at én bred etiket, såsom træningsdata, skjuler flere forskellige ting. Et råbidrag, et renset datasæt, et featuresæt, en modelversion, en prompthistorik, et evalueringssæt og en overvågningslog kan hver især have forskellige formål og opbevaringshensyn. At kombinere dem i én enkelt ubestemt beholder gør både innovation og ansvarlighed værre. At adskille dem garanterer ikke et juridisk svar, men det gør et muligt.

Opbevaringsbeslutninger har også gavn af en nægtelsesbetingelse. Hvad ville få os til at stoppe med at opbevare dette? En afsluttet kontrakt, en løst tvist, udløbet af en lovbestemt periode, en afsluttet sikkerhedsundersøgelse, en erstattet modelversion, udløbet af et gendannelsesvindue eller en beslutning om ikke at forfølge et forskningsformål kan alle være reelle udløsere. Pointen er ikke at automatisere en sletningsur for alting. Det er at undgå et system, hvor den eneste betingelse for at beholde data er, at ingen endnu er blevet bedt om at forklare dem.

Der er en lille hollandsk instinkt værd at bevare her: et skab er ikke organiseret, fordi det har en dør. Det er organiseret, fordi du kan finde den relevante ting, vide hvorfor den er der, og fjerne den uden at flytte. En dataejendom fortjener mindst den standard. En opbevaringsplan, der ikke kan overleve en samtale med de mennesker, der driver systemet, er ikke en plan. Det er en vejrudsigt skrevet i juridisk prosa.

Det betyder ikke, at enhver organisation skal centralisere alle sletningsbeslutninger. Lokale teams forstår ofte deres processer bedre. Det betyder, at lokale regler har brug for fælles begreber, synligt ejerskab og en vej til eskalering. Ellers er det ene teams arkiv det andet teams brud på reglerne, og en persons anmodning sendes gennem en labyrint af pænt navngivne tjenester.

Hvad en ærlig AI-leverandør kan sige

En ærlig AI-leverandør påstår ikke, at alle kundedata fordamper, når en anmodning ankommer. Den gemmer sig heller ikke bag modellernes kompleksitet. Den beskriver tjenestens grænse. Hvad der behandles til inferens. Hvad der gemmes til kontoadministration, sikkerhed, support, fakturering eller forebyggelse af misbrug. Om prompts og output gemmes. Om de bruges til træning, evaluering eller serviceforbedring. Hvilke behandlere og regioner der er involveret. Hvordan kunder kan konfigurere opbevaring. Hvilken dokumentation der findes for registreredes anmodninger. Hvilke handlinger der er øjeblikkelige, hvilke der er asynkrone, og hvilke der afhænger af en separat juridisk vurdering.

For købere er indkøbsspørgsmålene praktiske. Kan vi få et klart dataflowkort? Kan vi identificere rollerne som dataansvarlig og databehandler for den relevante behandling? Kan vi eksportere eller slette materiale på en brugbar måde? Er søgeindekser og afledte lagre inkluderet i den dokumenterede livscyklus? Hvad sker der med sikkerhedskopier? Hvordan kommunikeres ændringer i underbehandlere? Kan leverandøren hjælpe os med at svare på en anmodning inden for den gældende tidsramme? Er brug til træning og serviceforbedring opt-in, opt-out, aftalt ud, eller kun beskrevet på en side, der kan ændres efter købet? Hvilke tekniske registreringer er tilgængelige for at bevise handling?

Svarene vil variere. En stor delt tjeneste kan ikke altid tilbyde samme kontrol som et dedikeret miljø. En sikkerhedslog kan ikke altid slettes på samme tidspunkt som en kontoprofil. Et lovbestemt arkiv kan ikke behandles som en forbrugerpræference. Disse forskelle er ikke nødvendigvis fejl. Tavshed om dem er. Den rigtige køberreaktion er at matche tjenestens dokumenterede adfærd med organisationens formål, forpligtelser og risiko. Et produkt kan være uegnet til en yderst følsom opgave, selv når det er fuldt egnet til et lavrisiko-udkastværktøj.

Hos Dweve tager vores Trust Centre samme snævre syn på dokumentation. En offentlig side kan beskrive kontroller og dokumentationsgrænser, men den kan ikke certificere enhver kundedrift eller fastlægge det lovlige grundlag for en kundes behandling. Den grænse betyder noget. En platform kan understøtte opbevaringskontroller, registreringer og gennemsigtige arbejdsgange. Organisationen, der bruger den, ejer stadig sit formål, sine dataval og beslutningen om at svare en bestemt person. God produkttale bør gøre det ansvar tydeligere, ikke stille og roligt arve det.

Den mest værdifulde leverandørerklæring er ofte en begrænsning. ’Denne registrering forbliver i beskyttede sikkerhedskopier, indtil den angivne rotationsperiode udløber.’ ’Denne tjeneste bruger ikke det angivne kundeindhold til træning under disse vilkår.’ ’Dette indeks fjernes asynkront, og status kan tjekkes her.’ ’Vi kan ikke fremsætte denne påstand for en tredjepartsintegration.’ Disse sætninger kan virke mindre magiske end et universelt privatlivsløfte. De lader en køber designe en reel proces.

Spørgsmål værd at stille, før anmodningen ankommer

En organisation behøver ikke at opfinde et databrud, en presset person eller en heroisk sen nattens hændelse for at teste sit sletningsdesign. Den kan bruge en tydeligt mærket hypotetisk anmodning i almindelig arbejdstid. Antag, at en person beder om sletning af materiale, der ligger i et kundevendt system. Hvilket team modtager anmodningen? Hvordan kontrolleres identiteten uden at indsamle unødvendige nye oplysninger? Hvilke formål er relevante? Hvilke systemer indeholder kildedata, afledninger, indekser, logfiler, caches, eksporter og gendannelseskopier? Hvilke databehandlere skal have en instruks eller en meddelelse? Hvilken undtagelse eller opbevaringspligt, hvis nogen, finder anvendelse? Hvem kan beslutte? Hvem kan udføre? Hvordan vil organisationen forklare resultatet?

Stil derefter de akavede tekniske spørgsmål. Kan en operatør finde den aktuelle datafortegnelse uden en tidligere ingeniør? Kan et søgeindeks kontrolleres uafhængigt af sin kildetabel? Dukker en slettet identifikator op igen efter en gendannelse? Bruger batchjob gamle snapshots? Kan et embedding-lager knyttes til sine dokumenter og sin lejer? Indfanger en overvågningspipeline promptindhold som standard? Er eksportfiler underlagt de samme opbevaringsregler som deres kilde? Skaber bevisregistreringen en ny bunke følsomt indhold? Det er ikke kanttilfælde, der er tilføjet for at få en politik til at se seriøs ud. Det er almindelige konsekvenser af systemer, der laver kopier for at fungere.

Stil til sidst styringsspørgsmålet: hvad skulle der til for, at organisationen ændrer sit svar? En ny juridisk forpligtelse, en anfægtet identitet, et verserende retskrav, en ændret leverandøraftale, en fejlet sletningsverifikation, en gendannet sikkerhedskopi, en ny modelpipeline eller en tilsynsmyndigheds afgørelse kan hver især have betydning. En proces uden en gennemgangsudløser er blot et indledende gæt, der er ophøjet til politik.

Intet af dette erstatter juridisk rådgivning i en konkret sag. GDPR-kravene, national lovgivning, sektorspecifikke forpligtelser, kontrakter og de faktiske omstændigheder for behandlingen har alle betydning. Men organisationer behøver ikke en juridisk tvist for at begynde at konstruere betingelserne for et forståeligt svar. De skal kende deres systemer godt nok til at holde op med at love noget enkelt for en kompliceret virkelighed.

Privatliv er kvaliteten af det, der bliver tilbage

Ambitionen bag sletning er ikke at gøre fortiden uvirkelig. Det er at give mennesker meningsfuld kontrol, hvor data ikke længere skal behandles, hvor samtykke er trukket tilbage, hvor behandlingen er ulovlig, eller hvor et andet grundlag i artikel 17 finder anvendelse. Det kræver, at dataansvarlige behandler personoplysninger som noget, der opbevares til et formål, ikke som råmateriale med ubegrænset leje. Det kræver, at de forklarer undtagelser i stedet for at bruge dem som en tågemaskine. Det kræver, at systemer bærer tilstrækkelig herkomst, så sletning kan være bevidst.

For digitale tjenester er den stille test det, der er tilbage. Når en registrering er fjernet fra en produktskærm, hvad er så stadig aktivt? Når et dokument forlader et søgekorpus, hvilken afledt repræsentation vælger det så stadig? Når en konto er slettet, hvilken log opbevares så, til hvilket formål og hvor længe? Når en sikkerhedskopi er gendannet, hvad forhindrer så en pensioneret registrering i at vende tilbage? Når en model ændres, hvilken datahistorik kan så inspiceres? Når en anmodning er afsluttet, kan organisationen så vise sit arbejde uden at opbygge endnu en skjult profil?

Et system vil sjældent besvare alle disse spørgsmål med én handling og ét tidsstempel. Det er normalt. Det, der ikke er normalt, er at lade som om, spørgsmålene forsvinder, fordi dataene er vanskelige, distribuerede eller indbringende. Privatliv er ikke det øjeblik, hvor en tjeneste lærer en sletningskommando. Det er det, der er tilbage, efter at systemet har lært at glemme med et formål, en grænse og en registrering af sin egen tilbageholdenhed.

Kilder