Prywatność to to, co zostaje, gdy system nauczy się zapominać.

Prawo do bycia zapomnianym to nie przycisk „usuń”. W nowoczesnych systemach to zdyscyplinowane pytanie o kopie, dane pochodne, dowody, wyjątki i o to, czy...

Prywatność to to, co zostaje, gdy system nauczy się zapominać.

Zapominanie nie jest przeciwieństwem pamiętania

Papierowy dokument ma uspokajająco widoczne życie. Pojawia się, jest gdzieś odkładany, kopiowany, jeśli ktoś ma kserokopiarkę, a w końcu trafia do niszczarki lub archiwum. Trudna może być decyzja, czy powinien zostać zniszczony, ale sam przedmiot jest posłusznie skończony. Cyfrowy zapis jest mniej uprzejmy. Może być przechowywany jako wiersz, załącznik, indeks wyszukiwania, podgląd wiadomości, blok kopii zapasowej, wpis audytowy, cecha w danych wejściowych modelu, wektor w magazynie osadzeń, buforowana odpowiedź lub wartość, która trafiła do systemu innej organizacji. Nie wystarczy zapytać, gdzie znajduje się oryginał. Bardziej użyteczne pytanie brzmi: co z niego powstało, co wciąż pozwala zidentyfikować osobę i jakiemu celowi służy każdy pozostały ślad.

Na tym polega praktyczna godność prawa do usunięcia danych. Często nazywa się je prawem do bycia zapomnianym, co jest wyrazistym, choć niedoskonałym określeniem. Ludzkie zapominanie jest przypadkowe, częściowe i pełne kłopotliwych powrotów. Zgodny z prawem proces usuwania powinien być zamierzony. Powinien umieć odróżnić rekord, który należy usunąć, od rekordu, który trzeba zachować, ponieważ wymaga tego prawo, spornego roszczenia, które musi pozostać dostępne na potrzeby obrony prawnej, oraz technicznych pozostałości, które można wyizolować do czasu ich planowanego wygaśnięcia. Powinien też opierać się użytecznemu instynktowi korporacyjnemu: traktowaniu usuwania jako stanu ekranu, a nie właściwości systemu.

Ogólne rozporządzenie o ochronie danych nie obiecuje, że każdy element związany z osobą zniknie na żądanie. Artykuł 17 określa podstawy, na których administrator musi usunąć dane osobowe bez zbędnej zwłoki, w tym gdy dane nie są już niezbędne do celów, w których zostały zebrane lub przetworzone, gdy wycofano zgodę i nie istnieje inna podstawa prawna oraz gdy przetwarzanie było niezgodne z prawem. Ten sam artykuł wyznacza granice. Usunięcie nie ma zastosowania, gdy przetwarzanie jest niezbędne, na przykład, do wyrażenia poglądów i informowania, wykonania obowiązku prawnego, zadań w interesie publicznym w niektórych okolicznościach, względów zdrowia publicznego, archiwizacji, badań lub statystyki z zachowaniem zabezpieczeń albo dochodzenia roszczeń. To nie jest luka w obietnicy. To rzeczywisty kształt tego prawa.

Pytanie dla właściciela systemu nie brzmi więc: „Czy możemy usunąć dane?”. Niemal każdy system może coś usunąć. Pytanie brzmi, czy organizacja potrafi wyjaśnić, w odniesieniu do konkretnego żądania i konkretnego celu przetwarzania, jakie dane posiada, co się z nimi stało, co jest zobowiązana lub uprawniona zachować, których odbiorców dalszych należy poinformować i jak można sprawdzić wykonaną czynność. Różnica brzmi proceduralnie. W praktyce ma charakter architektoniczny. Produkt, który umie tylko dodawać informacje, odkryje, że usuwanie jest znacznie droższą funkcją.

Jest to szczególnie wyraźne w przypadku systemów AI, ale nie ogranicza się do nich. Wyszukiwanie, analityka, obsługa klienta, tożsamość, monitorowanie bezpieczeństwa i zarządzanie dokumentami tworzą pochodne. Model jedynie nadaje problemowi nowe nazwy: tokeny, gradienty, osadzenia, indeksy wyszukiwania, prompty i wyniki. Żadna z tych etykiet nie rozwiewa podstawowego pytania, czy osoba fizyczna pozostaje możliwa do zidentyfikowania. Termin techniczny nie odpowiada też po cichu na pytanie prawne. Osadzenie nie jest automatycznie anonimowe, ponieważ trudno je odczytać. Log nie jest automatycznie niezbędny, ponieważ jest użyteczny. Kopia zapasowa nie jest automatycznie zwolniona z obowiązku, ponieważ jest niewygodna.

Prywatność po zapomnieniu nie jest zatem czystą kartą. To stan szczątkowy, który pozostaje po tym, jak organizacja podjęła zgodną z prawem, proporcjonalną i możliwą do zweryfikowania decyzję o tym, czego nie należy już przetwarzać. Jakość tego stanu szczątkowego mówi ludziom o systemie znacznie więcej niż obecność przycisku usuwania.

Prawo ma warunki, a to czyni je silniejszym

Europejskie prawo ochrony danych bywa opisywane tak, jakby dawało każdej osobie uniwersalny czerwony przycisk. Taki obraz dobrze sprawdza się na slajdzie, ale jest na tyle błędny, że może przysporzyć problemów. Artykuł 17 jest powiązany z celem, podstawą prawną i okolicznościami przetwarzania. Zawiera prawo, obowiązki administratorów oraz wyjątki chroniące inne prawa i interesy publiczne. Odpowiedzialne podejście zaczyna się od ustalenia tożsamości osoby składającej żądanie, jeśli jest to konieczne, zrozumienia danych i celu przetwarzania, których dotyczy sprawa, oraz oceny, czy ma zastosowanie przesłanka z artykułu 17 i wyjątek. Odpowiedzią może być usunięcie danych. Może nią być uzasadniona odmowa w całości lub w części. Może nią być ograniczenie przetwarzania do czasu rozstrzygnięcia sporu. Może też być żądanie, które dotyczy systemu, nad którym organizacja nie sprawuje kontroli.

To nie powód, by zamieniać żądanie osoby, której dane dotyczą, w tor przeszkód. RODO wymaga od administratorów ułatwiania wykonywania praw. Artykuł 12 wymaga, aby informacje i komunikaty dotyczące działań podjętych w związku z żądaniem były zwięzłe, przejrzyste, zrozumiałe i łatwo dostępne. Co do zasady wymaga też informacji o podjętych działaniach bez zbędnej zwłoki, a w każdym razie w ciągu miesiąca od otrzymania żądania. Termin ten można przedłużyć o kolejne dwa miesiące, jeśli jest to konieczne ze względu na skomplikowany charakter żądania lub liczbę żądań, ale administrator musi poinformować osobę o przedłużeniu i jego przyczynach w ciągu pierwszego miesiąca. System, który nie potrafi zidentyfikować własnych przepływów danych aż do trzeciego miesiąca, nie znalazł proceduralnej obrony. Znalazł problem z zarządzaniem.

Wytyczne Europejskiej Rady Ochrony Danych dla małych i średnich przedsiębiorstw ujmują tę kwestię operacyjnie wprost: osoby mogą żądać usunięcia danych w szczególnych okolicznościach, a organizacje powinny mieć procedury odpowiadania na żądania dotyczące praw. Procedura to nie opinia prawna przechowywana na wspólnym dysku. To działająca ścieżka od żądania do decyzji i wykonania. Obejmuje role uprawnione do podejmowania decyzji, mapy danych pozwalające zobaczyć istotne przetwarzanie, dostawców i odbiorców, których może trzeba powiadomić, harmonogramy retencji wyjaśniające wyjątek oraz dowody pozwalające późniejszemu recenzentowi zrozumieć, co zostało zrobione.

Trybunał Sprawiedliwości pomógł dostrzec jeszcze jedną różnicę. Jego orzeczenia dotyczące deindeksacji odnoszą się do prezentowania linków przez wyszukiwarki, a nie do nakazu usunięcia pierwotnej publikacji ze strony źródłowej. W sprawie Google Spain Trybunał uznał, że operator wyszukiwarki może ponosić odpowiedzialność za przetwarzanie danych osobowych pojawiających się na stronach internetowych opublikowanych przez osoby trzecie oraz że osoba, której dane dotyczą, może w określonych okolicznościach żądać usunięcia linków z listy wyników wyświetlanej po wyszukaniu jej nazwiska. W późniejszych sprawach Trybunał zajmował się między innymi danymi wrażliwymi, zakresem terytorialnym deindeksacji i nieprawdziwymi informacjami. Te sprawy nie zamieniają każdego niechcianego faktu w roszczenie o usunięcie. Pokazują, dlaczego system musi wskazać warstwę, której dotyczy problem: publikację źródłową, indeks, listę wyników, pamięć podręczną, wyciąg lub inną kopię.

Ta dyscyplina warstw ma znaczenie także wewnątrz organizacji. Pracownik może zwrócić się do administratora o usunięcie rekordu kontaktowego, który nie jest już potrzebny do celów rekrutacji. Administrator może musieć ocenić odrębny obowiązek przechowywania danych dotyczących wynagrodzeń lub dowodów równego traktowania. Podmiot publiczny może przetwarzać rekord w ramach zadania ustawowego i musi ocenić właściwe przepisy, a nie powtarzać odpowiedź z sektora prywatnego. Wydawca może musieć rozważyć wolność wypowiedzi i informacji. Wyniku nie da się ustalić wyłącznie słownikiem baz danych.

Łatwo jest mieć pretensje do tych warunków, bo uniemożliwiają prostą obietnicę. Ale to one nadają obietnicy sens. Prawo, które ignoruje obowiązki prawne, inne prawa podstawowe i praktyczną różnicę między systemami, zamieniłoby się w rytuał. Europejskie podejście wymaga decyzji, za którą można ponosić odpowiedzialność, a nie teatralnego gestu. To wymaga więcej pracy. Dzięki temu odmowa może być zaskarżona, a usunięcie danych wiarygodne.

Usuwanie danych zaczyna się od zlokalizowania powierzchni przetwarzania. Diagram jest mapą systemów, a nie twierdzeniem, że każda powierzchnia ma takie samo traktowanie prawne.

Rekord może zniknąć z ekranu i pozostać w systemie

Najprostsza porażka usuwania jest znana każdemu, kto budował aplikację: usuń element z interfejsu produktu, zostaw podstawowe dane w magazynie i uznaj, że zadanie jest wykonane, bo zwykli użytkownicy już go nie widzą. Czasem miękkie usunięcie jest dokładnie właściwym rozwiązaniem operacyjnym. Może zapewnić krótki okres na cofnięcie, uczynić replikację bezpieczną albo uniknąć zerwania relacji, którą trzeba rozwiązać. Ale miękkie usunięcie nie jest wymazaniem tylko dlatego, że interfejs stał się cichszy. Jego zastosowanie musi być powiązane z określonym celem, okresem przechowywania, kontrolą dostępu i późniejszym działaniem, które faktycznie zmienia stan danych.

Twarde usuwanie ma swoje ograniczenia. Usunięcie wiersza może pozostawić indeks wyszukiwania do następnego cyklu indeksowania. Magazyn obiektów może mieć wersjonowanie. Pamięć podręczna dostarczania treści może przechowywać odpowiedź do wygaśnięcia lub unieważnienia. Kolejka komunikatów może zawierać zdarzenie, które nie zostało jeszcze przetworzone. Magazyn danych mógł pobrać migawkę. Usługa mogła przekazać dane procesorowi, podprocesorowi lub odbiorcy. Praktyczny wniosek nie jest taki, że usuwanie jest niemożliwe. Jest taki, że organizacja potrzebuje inwentaryzacji o wystarczającej dokładności, aby odróżnić te powierzchnie, oraz polityki, która określa, co dzieje się na każdej z nich.

Istnieje dalsze rozróżnienie między treścią a dowodem. Bilet obsługi klienta może zawierać wiadomość osoby. System może potrzebować zapisu, że bilet istniał, został rozwiązany i usunięty zgodnie z zatwierdzoną zasadą. Przechowywanie całej wiadomości na zawsze, aby udowodnić, że została usunięta, to małe arcydzieło biurokracji, ale nie kontrola prywatności. Lepszy projekt zachowuje tylko minimalny dowód potrzebny do rozliczalności, oddzielony od treści, która nie ma już celu. Taki dowód może obejmować identyfikator żądania, typ decyzji, czas zakończenia, obowiązującą kategorię przechowywania i systemy, do których dotarto. Projekt zależy od organizacji. Zasada nie: dowód nie powinien odtwarzać niepotrzebnych danych osobowych.

Kopie zapasowe zasługują na ten sam prosty język. Kopia zapasowa może być konieczna do dostępności, bezpieczeństwa lub odzyskiwania po awarii. Nadal jest przetwarzaniem. Praktyczne pytanie brzmi, czy kopia zapasowa jest osobno dostępna, jak długo pozostaje możliwa do przywrócenia, kto może ją przywrócić, czy jest objęta normalnym procesem usuwania oraz jak zapobiec temu, aby przywrócone środowisko po cichu ponownie wprowadzało dane, które zostały już usunięte z systemu produkcyjnego. Rozsądna polityka może opierać się na zdefiniowanym okresie rotacji kopii zapasowej zamiast modyfikowania każdego historycznego bloku kopii osobno. Ale polityka musi to jasno określać, chronić dostęp w międzyczasie i zapewniać, aby przywracanie odbywało się zgodnie z aktualnym stanem danych, gdzie to możliwe. „To jest w kopii zapasowej” opisuje problem. Nie jest na niego odpowiedzią.

Logi są podobne. Logi bezpieczeństwa i logi operacyjne mogą być niezbędne. Mogą stanowić jedyne źródło informacji o dostępie, nieudanej próbie uwierzytelnienia czy zmianie produkcyjnej. Mogą również przechowywać identyfikatory, adresy, treści żądań lub fragmenty treści, które nigdy nie były potrzebne do diagnozy. Dobry projekt logowania minimalizuje zbieranie danych, stosuje redakcję lub pseudonimizację tam, gdzie to właściwe, oddziela wrażliwe ładunki od metadanych zdarzeń, ogranicza dostęp i stosuje harmonogramy przechowywania. Próba wykrycia każdego wrażliwego pola podczas żądania usunięcia danych jest możliwa, ale to słaby substytut decyzji podjętej na etapie projektowania, co log powinien był zawierać, a czego nigdy nie powinien.

Właściciel techniczny nie musi obiecywać natychmiastowego, jednolitego wymazania danych na każdym urządzeniu, aby działać odpowiedzialnie. Musi natomiast być w stanie określić cykl życia danych: co staje się niedostępne natychmiast, co jest usuwane w następnym przebiegu przetwarzania, co pozostaje zgodnie z udokumentowanym harmonogramem przechowywania, co pozostaje chronione do czasu wygaśnięcia, oraz co się stanie, jeśli nastąpi operacja odzyskiwania. Taki opis daje osobie, organowi regulacyjnemu i operatorowi coś konkretnego do zbadania. Zielone powiadomienie toast daje im bardzo niewiele.

Dane pochodne nie są furtką ucieczki

Nowoczesne systemy często przekształcają dane osobowe przed ich użyciem. Wyodrębniają datę z dokumentu, klasyfikują wiadomość, obliczają wynik, wnioskują o języku, tworzą indeks wyszukiwania, generują streszczenie, łączą dwa konta lub zamieniają tekst i obrazy na wektory używane do wyszukiwania podobieństw. Te przekształcenia mogą być przydatne. Mogą też sprawić, że organizacja poczuje, że wykroczyła poza dane osobowe. Niekoniecznie tak jest.

RODO jest technologicznie neutralne. Motywy rozporządzenia wyjaśniają, że dane pseudonimizowane, które można przypisać osobie fizycznej za pomocą dodatkowych informacji, należy uważać za informacje o możliwej do zidentyfikowania osobie fizycznej. Wyjaśniają również, że przy ocenie możliwości identyfikacji należy uwzględnić wszystkie środki, które mogą być w sposób racjonalnie prawdopodobny użyte przez administratora lub inną osobę, biorąc pod uwagę takie czynniki, jak koszt, czas, dostępna technologia i rozwój technologiczny. Pytanie nie brzmi, czy reprezentacja wygląda jak nazwisko w arkuszu kalkulacyjnym. Pytanie brzmi, czy odnosi się do zidentyfikowanej lub możliwej do zidentyfikowania osoby w rzeczywistym kontekście.

Embedding uwidacznia ten problem w niewygodny sposób. W systemie wyszukiwania dokument może być podzielony na fragmenty i przedstawiony jako wektory liczbowe, aby zapytanie mogło znaleźć semantycznie podobny materiał. Wektor nie jest czytelnym akapitem. Może jednak być powiązany z dokumentem źródłowym, dzierżawcą, użytkownikiem, kontrolą dostępu, polem metadanych lub kluczem wyszukiwania. Może umożliwić systemowi wybór materiałów osobowych w odpowiedzi na zapytanie. Organizacja nie może nazwać go anonimowym tylko dlatego, że człowiek nie jest w stanie zrekonstruować zdania, patrząc na listę współrzędnych. Musi ocenić reprezentację, powiązane dane, środki łączenia i cel przetwarzania.

To samo dotyczy wyniku pochodnego. Wynik ryzyka, kategoria preferencji lub wskaźnik kwalifikowalności może zawierać mniej szczegółów niż dane źródłowe, a mimo to mieć poważne skutki dla osoby. Może stanowić dane osobowe, jeśli odnosi się do zidentyfikowanej lub możliwej do zidentyfikowania osoby. Usunięcie źródła przy jednoczesnym zachowaniu wyniku, który nadal wpływa na decyzję, nie jest czystym rozwiązaniem. Może po prostu przenieść osobę do bardziej nieprzejrzystej formy. System potrzebuje reguły dla danych pochodnych: które są usuwane wraz ze źródłem, które są przeliczane, których nie można już używać, które muszą być przechowywane na mocy odrębnego obowiązku, i kto o tym decyduje.

Nie istnieje uniwersalny test techniczny, który rozstrzyga los każdego pochodnego zbioru danych. Niektóre statystyki zagregowane mogą być anonimowe. Inne mogą nadal być podatne na wyodrębnienie pojedynczych osób lub powiązanie z nimi. Niektóre parametry modelu mogą nie być w danym kontekście racjonalnie przypisywalne do konkretnej osoby. Inne mogą być związane z danymi treningowymi, wąsko zakrojonym modelem lub powierzchnią ataku, która zmienia ocenę. Pojęcie informacji anonimowej w RODO nie jest dekoracyjną etykietą dla danych, które uczyniono trudnymi do interpretacji. Administrator musi przeprowadzić ocenę opartą na środkach i kontekście identyfikacji.

Ta niepewność nie jest powodem, by opisywać każdy zbiór pochodny jako trwale toksyczny. Jest natomiast powodem, by prowadzić linię pochodzenia danych. Zespół powinien wiedzieć, które zbiory wejściowe wykorzystano do stworzenia feature store, indeksu, przebiegu trenowania lub tabeli raportowej; które wersje zbioru pochodnego powstały; które systemy je konsumują; oraz jaką reakcję musi wywołać zmiana w źródle. Linia pochodzenia zamienia niewygodne pytanie w ograniczone zadanie inżynieryjne. Bez niej każde żądanie dotyczące praw staje się wyprawą archeologiczną przez nazwy zadań, zasobniki danych i czyjąś pamięć o migracji sprzed dwóch zim.

Uczenie maszynowe dodaje trudne pytanie, a nie magiczne zwolnienie

Uczenie maszynowe utrudnia usuwanie danych, ponieważ trenowanie nie jest operacją archiwizacyjną. Przykład treningowy może wpływać na parametry poprzez długą sekwencję aktualizacji, wraz z wieloma innymi przykładami. Wdrożony model mógł zostać skopiowany do kilku środowisk. Późniejszy model mógł zostać dostrojony na bazie wcześniejszego. Zespół może korzystać z danych ewaluacyjnych, promptów, korpusów do wyszukiwania i logów opinii, które podlegają różnym cyklom życia. Jeśli dane osoby trafiły do takiego systemu, organizacja nie może odpowiedzialnie odpowiedzieć wzruszeniem ramion na temat matematyki. Nie może też uczciwie obiecać, że usunięcie z jednej bazy danych usunie cały możliwy wpływ na każdy parametr.

Pierwszym krokiem jest rozdzielenie systemów. Korpus do wyszukiwania to nie wytrenowany model. Jeśli dokument jest używany jako źródło do wyszukiwania, usunięcie może obejmować usunięcie lub wyłączenie dokumentu, jego fragmentów, metadanych i wpisów indeksu, a następnie sprawdzenie, czy wyszukiwanie już do niego nie dociera. Log promptów to nie magazyn embeddingów. Zbiór danych do dostrajania to nie dziennik audytu bezpieczeństwa. Punkt kontrolny modelu to nie bieżący rekord źródłowy. Właściwa reakcja może być inna dla każdej z tych powierzchni, ale nie można jej zaprojektować, dopóki powierzchnie nie zostaną nazwane.

W przypadku danych treningowych analiza prawna i techniczna może wymagać decyzji, czy właściwe jest ponowne trenowanie, zastąpienie, ograniczenie, przechowywanie lub inny środek. Badania nad wymazywaniem z modeli są istotne, ponieważ badają metody zmniejszania wpływu konkretnych danych bez ponownego trenowania modelu od podstaw. Nie są jednak ogólnym certyfikatem, że system zapomniał. Metody mają założenia, klasy modeli, warunki dotyczące danych i ograniczenia weryfikacji. Organizacja nie powinna reklamować eksperymentalnej techniki jako uniwersalnego wdrożenia art. 17. Nie powinna też czekać na idealną technikę, zanim zaprojektuje lepsze mechanizmy kontroli danych.

Lepsze mechanizmy kontroli zaczynają się wcześniej. Minimalizuj zbierane dane. Oddzielaj dane osobowe od materiału treningowego tam, gdzie pozwala na to zamierzony cel. Ustal okres przechowywania, zanim gromadzenie danych uczyni to pytanie kosztownym emocjonalnie. Prowadź wersjonowane rejestry zbiorów danych i przebiegów trenowania. Wyraźnie określ warunki wyrażenia zgody lub inne podstawy prawne, gdy są one istotną podstawą. Nie pozwól, aby produkcyjne archiwum promptów po cichu stało się korpusem do tworzenia modeli. Utrzymuj dane ewaluacyjne i pomocnicze odróżnialne od danych treningowych. Im mniej system polega na nieznanym pochodzeniu danych, tym precyzyjniej może odpowiedzieć na pytanie o usunięcie.

Istnieje również ograniczenie słowa „wpływ”. Osoba może obawiać się, że tekst był kiedyś częścią zbioru treningowego. Zespół techniczny może być w stanie ustalić, że rekord źródłowy został usunięty z bieżącego korpusu, ale nie może udowodnić, w szerokim sensie filozoficznym, że żaden fragment wpływu nie pozostał w żadnym parametrze historycznego modelu. Prawo ochrony danych osobowych nie staje się łatwiejsze, gdy organizacja zastępuje konkretny opis metafizyką. Obowiązkiem jest ocena przetwarzania, podstaw prawnych i środków zgodnie z prawem. Organizacja powinna wyjaśnić zakres swojego wniosku, systemy, których dotyczy, oraz pozostałe ograniczenia. Precyzja jest lepsza niż przesadna obietnica.

Dla podmiotów wdrażających sztuczną inteligencję praktyczne obciążenie często leży w równym stopniu po stronie zamówień, co inżynierii. Dostawca powinien być w stanie wyjaśnić, co robi z promptami, przesłanymi plikami, telemetrią i opcjonalnymi opiniami; które z nich są wykorzystywane do trenowania lub ulepszania usług; jakie istnieją mechanizmy kontroli retencji; w jaki sposób klient może uzyskać informacje potrzebne do odpowiedzi na żądania dotyczące praw; oraz co dzieje się w środowisku współdzielonym w porównaniu z dedykowanym. Umowa, która jedynie stwierdza „zgodność z RODO”, nie dostarczyła informacji potrzebnych do przeprowadzenia procesu usuwania danych. Dostarczyła jedynie przymiotnik.

Wyszukiwarki uczą przydatnej lekcji o warstwach

Orzecznictwo Trybunału Sprawiedliwości dotyczące deindeksacji jest tutaj przydatne właśnie dlatego, że jest węższe niż popularne sformułowanie „prawo do bycia zapomnianym”. Sprawy te dotyczą tego, czy i na jakich warunkach wyszukiwarka musi usunąć linki z wyników wyszukiwania według nazwiska. Nie tworzą one prostej władzy zmieniania historii u jej źródła. To rozróżnienie pokazuje, że pytania o prywatność często dotyczą tego, w jaki sposób informacje są udostępniane, łączone i wzmacniane, a nie tylko tego, czy rekord kiedyś istniał.

W sprawie Google Spain Trybunał rozważył linki na liście wyników wyszukiwarki prowadzące do stron opublikowanych przez stronę trzecią. Decyzja wyjaśniła, że działalność wyszukiwarki może stanowić przetwarzanie danych osobowych oraz że w określonych warunkach operator może być zobowiązany do usunięcia linków z wyników wyświetlanych po wyszukiwaniu według nazwiska osoby. Decyzja nie była nakazem skierowanym do gazety, która opublikowała pierwotne ogłoszenia. Właściciel systemu patrzący na wewnętrzną bazę wiedzy może się z tego nauczyć: indeksy wyszukiwania, podglądy i ranking wyników to warstwy przetwarzania, które mają własne konsekwencje.

Sprawa GC i inni dotyczyła żądań usunięcia linków do stron internetowych zawierających wrażliwe dane osobowe. Trybunał odniósł się do przeprowadzanego wyważenia oraz obowiązków, które mogą powstać po stronie operatora wyszukiwarki. Sprawa Google przeciwko CNIL dotyczyła zakresu terytorialnego i w okolicznościach tej sprawy Trybunał orzekł, że prawo UE nie wymaga deindeksacji we wszystkich wersjach wyszukiwarki na całym świecie, jednocześnie wymagając skutecznych środków zapobiegających lub poważnie utrudniających dostęp z państw członkowskich do linków usuniętych z wersji UE. Sprawy TU i RE dotyczyły żądania związanego z rzekomo nieprawdziwymi informacjami i wyjaśniły elementy ciężaru dowodu oraz sposób traktowania obrazów podglądowych. Te wyroki to decyzje prawne zależne od konkretnych okoliczności faktycznych, a nie lista kontrolna wdrożenia. Razem tworzą one punkt dotyczący systemów: link, lista wyników, podgląd obrazu i oryginalna strona nie mają automatycznie tego samego środka zaradczego.

Ta myśl dobrze się przenosi. Portal korporacyjny może zgodnie z prawem przechowywać rekord źródłowy w ograniczonym celu, podczas gdy dostęp przez szeroką powierzchnię wyszukiwania jest nadmierny. System wsparcia technicznego może potrzebować chronionego wpisu audytowego, podczas gdy jego podgląd autouzupełniania nie powinien ujawniać danych byłego klienta dużej grupie osób. Dokument może zostać usunięty z korpusu wyszukiwania, podczas gdy wygenerowane przez model streszczenie pozostaje w innym magazynie. Właściwą reakcją nie jest deklarowanie, że każda warstwa jest identyczna. Należy zrozumieć, w jaki sposób warstwa zmienia ekspozycję, cel i ryzyko.

Przestrzega też przed popularnym skrótem myślowym: zakładaniem, że widoczność to jedyny problem prywatności. Rekord może być technicznie ukryty, a mimo to przetwarzany, odpytywany, profilowany, przekazywany lub przywracany. Z drugiej strony organizacja może potrzebować starannie ograniczonego rekordu, aby udowodnić, że właściwie zareagowała, chronić roszczenie prawne lub spełnić obowiązek ustawowy. Prywatność to nie konkurs na wytworzenie jak najmniejszej ilości danych w każdych okolicznościach. To dyscyplina celu, konieczności, proporcjonalności i kontroli.

Dlatego inwentaryzacja usuwania powinna obejmować ścieżki wyszukiwania i prezentacji. Należy ustalić, które indeksy zawierają rekord, które pamięci podręczne go obsługują, które eksporty go obejmują, które API go zwracają, które pola pochodne są używane do rankingu lub rekomendacji oraz które ścieżki przywracania z kopii zapasowej mogą go ponownie uaktywnić. Lista nie będzie elegancka. Będzie bardziej użyteczna niż elegancja.

Demonstracja różni się od deklaracji

Gdy system twierdzi, że potrafi wymazać dane, pojawiają się dwa odrębne pytania. Pierwsze dotyczy tego, czy projekt ma uzasadnioną, udokumentowaną drogę do tego. Drugie dotyczy tego, czy organizacja potrafi wykazać, że droga ta została zastosowana w przypadku konkretnego żądania, bez przechowywania większej ilości danych osobowych, niż wymaga tego demonstracja. Pierwsze to możliwość produktu. Drugie to odpowiedzialność.

Użyteczny zapis usunięcia jest celowo skromny. Nie musi odtwarzać całego żądania osoby, dokumentów ani historii konta w nowej bazie danych zgodności. Może zawierać odniesienie do żądania, wynik weryfikacji tożsamości, jeśli ma to zastosowanie, kategorię żądania, właściwe systemy, decyzję i uzasadnienie prawne na odpowiednim poziomie, daty działań, wyjątki lub podstawy przechowywania, powiadomienia odbiorców, jeśli są wymagane, oraz status asynchronicznego usuwania lub wygaśnięcia kopii zapasowych. Dokładne pola zależą od administratora i kontekstu. Najważniejsze jest to, aby późniejszy recenzent mógł zobaczyć ścieżkę bez odtwarzania wrażliwych treści z fragmentów.

Weryfikacja powinna odpowiadać powierzchni danych. Rekord w działającej aplikacji można sprawdzić, potwierdzając, że autoryzowane wyszukiwanie już go nie zwraca. System wyszukiwania można przetestować za pomocą oryginalnego identyfikatora i odpowiednich wzorców zapytań, unikając szeroko zakrojonych prób odtworzenia treści osobistych. Indeks może zgłosić swój stan usunięcia. Kolejka może pokazać zakończenie. Proces tworzenia kopii zapasowych może wykazać, że obraz odzyskiwania jest chroniony zgodnie z zasadą przechowywania, a przywracanie stosuje aktualny rejestr usunięć lub równoważną kontrolę. Weryfikacja nie musi udowadniać metafizycznej negacji. Musi dostarczyć dowodów proporcjonalnych do składanego twierdzenia.

Jest tu pewna subtelna pułapka. Zespół może zbudować imponujący pulpit nawigacyjny z wszystkimi zielonymi wskaźnikami i bez stabilnego związku z rzeczywistą pracą. Znaczący pulpit nawigacyjny określa powierzchnię danych, działanie, stan, właściciela, dowody i termin kolejnego przeglądu. Pozwala odróżnić „żądanie przyjęte”, „rekord na żywo usunięty”, „oczekujące powiadomienie odbiorcy”, „kopia zapasowa oczekująca na wygaśnięcie” i „przechowywane zgodnie z obowiązkiem prawnym”. Te stany mają różne znaczenia. Sprowadzenie ich do „usunięto” zamienia niepewność w projekt interfejsu użytkownika.

Możliwe do wykazania usuwanie zależy również od zarządzania zmianami. System źródłowy może zostać zastąpiony, dodany procesor, zmieniony format indeksu, wprowadzony nowy cel analityczny lub zmieniona polityka przechowywania dostawcy AI. Jeśli procedura usuwania nie zostanie zaktualizowana wraz z tymi zmianami, stopniowo zacznie opisywać system, który już nie istnieje. Rezultat jest znany z każdej dyscypliny operacyjnej: piękny podręcznik i prawdziwa usługa oddalające się od siebie. Regularne testowanie małej próbki ścieżki, w tym niewygodnego systemu, zwykle ujawnia więcej niż zamawianie obszernego dokumentu zapewniającego, którego nikt nie jest w stanie wykonać.

Dla organu publicznego lub podmiotu regulowanego to nie jest wąski problem biura ochrony danych. Inspektor ochrony danych może kierować interpretacją, ale to inżynieria odpowiada za interfejsy i mechanikę usuwania, produkt za cel i ścieżkę użytkownika, zaopatrzenie za obowiązki informacyjne nałożone na dostawców, bezpieczeństwo za kontrolę dostępu i przywracania, a operacje za realizację pod presją. Jedna osoba odpowiedzialna nie może sama sprawdzić każdej warstwy. Warstwa, za którą nikt nie odpowiada, nie staje się bezpieczna tylko dlatego, że trudno o niej rozmawiać.

Proces, który da się obronić, rejestruje decyzję i jej wykonanie, nie tworząc przy tym drugiej, zbędnej biografii osoby.

Retencja to druga połowa usuwania

Wiele problemów z usuwaniem zaczyna się na długo przed złożeniem wniosku. Zaczynają się, gdy system w ogóle nie ma decyzji o retencji. Dane trafiają do systemu, bo mogą się przydać. Logi stają się trwałe, bo przechowywanie jest tanie. Eksporty są trzymane, bo przyszły audyt może o nie zapytać. Dane treningowe są gromadzone, bo późniejszy model może na nich skorzystać. Każda decyzja z osobna wydaje się nieszkodliwa. Razem zamieniają organizację we właściciela dużego, słabo rozumianego archiwum i sprawiają, że każdy wniosek o usunięcie staje się droższy, bardziej niepewny i bardziej sporny.

Zasada ograniczenia przechowywania z RODO mówi, że dane osobowe powinny być przechowywane w formie umożliwiającej identyfikację osób, których dotyczą, nie dłużej niż jest to niezbędne do celów, w których są przetwarzane, z dopuszczeniem dłuższego przechowywania do celów archiwalnych w interesie publicznym, do celów badań naukowych lub historycznych albo do celów statystycznych, jeśli zastosowano odpowiednie zabezpieczenia. Zasada ta nie narzuca jednego kalendarza każdej organizacji. Wymaga oceny powiązanej z celem. Harmonogram retencji powinien zatem określać kategorie danych, cel, podstawę prawną, standardowy okres, zdarzenie wyzwalające, wyjątek, sposób usunięcia, osobę odpowiedzialną i punkt przeglądu. „Tak długo, jak to konieczne” to zasada. Staje się regułą operacyjną dopiero wtedy, gdy ktoś potrafi powiedzieć, konieczne do czego, do kiedy i kto o tym zdecydował.

Taka struktura jest pomocna w przypadku sztucznej inteligencji, bo zapobiega ukrywaniu kilku różnych rzeczy pod jedną szeroką etykietą, taką jak dane treningowe. Surowy wkład, oczyszczony zbiór danych, zestaw cech, wersja modelu, historia promptów, zestaw ewaluacyjny i log monitorowania mogą mieć różne cele i różne wymagania dotyczące retencji. Połączenie ich w jeden nieokreślony zbiór pogarsza zarówno innowacyjność, jak i rozliczalność. Rozdzielenie ich nie gwarantuje odpowiedzi prawnej, ale ją umożliwia.

Decyzje o retencji zyskują też na warunku odmowy. Co sprawiłoby, że przestalibyśmy to przechowywać? Zakończona umowa, rozstrzygnięty spór, koniec okresu ustawowego, zakończone dochodzenie w sprawie bezpieczeństwa, zastąpiona wersja modelu, upływ okna przywracania albo decyzja o nierozwijaniu celu badawczego mogą być realnymi wyzwalaczami. Nie chodzi o zautomatyzowanie zegara usuwania dla wszystkiego. Chodzi o uniknięcie systemu, w którym jedynym warunkiem przechowywania danych jest to, że nikt jeszcze nie musiał ich wyjaśniać.

Jest tu pewien mały holenderski instynkt, który warto zachować: szafa nie jest zorganizowana dlatego, że ma drzwi. Jest zorganizowana, bo można znaleźć właściwą rzecz, wiedzieć, po co tam jest, i wyjąć ją bez przeprowadzki. Zasoby danych zasługują co najmniej na taki standard. Harmonogram retencji, który nie przetrwa rozmowy z ludźmi obsługującymi system, nie jest harmonogramem. To prognoza pogody napisana prawniczą prozą.

Nie oznacza to, że każda organizacja musi centralizować każdą decyzję o usunięciu danych. Zespoły lokalne często lepiej rozumieją swoje procesy. Chodzi o to, aby zasady lokalne opierały się na wspólnych pojęciach, widocznej odpowiedzialności i ścieżce eskalacji. W przeciwnym razie archiwum jednego zespołu staje się naruszeniem innego, a prośba osoby trafia do labiryntu uprzejmie nazwanych usług.

Co może powiedzieć uczciwy dostawca AI

Uczciwy dostawca AI nie twierdzi, że wszystkie dane klientów znikają, gdy wpłynie prośba. Nie chowa się też za trudnością modeli. Opisuje granicę usługi. Co jest przetwarzane na potrzeby wnioskowania. Co jest przechowywane do celów administrowania kontem, bezpieczeństwa, wsparcia, rozliczeń lub zapobiegania nadużyciom. Czy zapytania i odpowiedzi są przechowywane. Czy są wykorzystywane do szkolenia, oceny lub ulepszania usługi. Którzy podmioty przetwarzające i regiony są zaangażowani. Jak klienci mogą skonfigurować okres przechowywania. Jaka dokumentacja istnieje w przypadku próśb osób, których dane dotyczą. Które działania są natychmiastowe, które asynchroniczne, a które zależą od odrębnej oceny prawnej.

Dla kupujących pytania zakupowe są praktyczne. Czy możemy uzyskać jasną mapę przepływu danych? Czy możemy określić role administratora i podmiotu przetwarzającego dla danego przetwarzania? Czy możemy wyeksportować lub usunąć materiały w użyteczny sposób? Czy indeksy wyszukiwania i magazyny pochodne są objęte udokumentowanym cyklem życia? Co dzieje się z kopiami zapasowymi? Jak komunikowane są zmiany dotyczące podwykonawców? Czy dostawca może pomóc nam odpowiedzieć na prośbę w obowiązującym terminie? Czy wykorzystanie do szkolenia i ulepszania usługi jest opcjonalne, wymaga rezygnacji, jest wyłączone z umowy, czy opisane tylko na stronie, która może się zmienić po zakupie? Jakie zapisy techniczne są dostępne, aby potwierdzić działanie?

Odpowiedzi będą się różnić. Duża usługa współdzielona nie zawsze może zaoferować taką samą kontrolę jak środowisko dedykowane. Dziennik bezpieczeństwa nie zawsze może zostać usunięty w tym samym momencie co profil konta. Archiwum ustawowe nie może być traktowane jak preferencja konsumencka. Te różnice niekoniecznie są porażkami. Milczenie na ich temat już tak. Właściwą reakcją kupującego jest dopasowanie udokumentowanego zachowania usługi do celu, obowiązków i ryzyka organizacji. Produkt może być nieodpowiedni do zadania o wysokim stopniu wrażliwości, nawet jeśli jest w pełni odpowiedni jako narzędzie do tworzenia szkiców o niskim ryzyku.

W Dweve nasze Centrum Zaufania przyjmuje tak samo wąskie podejście do dowodów. Publiczna strona może opisywać mechanizmy kontroli i granice dokumentacji, ale nie może certyfikować każdego wdrożenia klienta ani decydować o podstawie prawnej przetwarzania przez klienta. Ta granica ma znaczenie. Platforma może wspierać mechanizmy kontroli przechowywania, zapisy i możliwe do przeglądu procesy. Organizacja, która z niej korzysta, nadal odpowiada za swój cel, swoje decyzje dotyczące danych i decyzję o odpowiedzi konkretnej osobie. Dobra proza produktowa powinna tę odpowiedzialność wyjaśniać, a nie po cichu ją przejmować.

Najcenniejsze oświadczenie dostawcy to często ograniczenie. „Ten zapis pozostanie w chronionych kopiach zapasowych do końca określonego okresu rotacji.” „Ta usługa nie wykorzystuje określonych treści klienta do szkolenia na tych warunkach.” „Ten indeks jest usuwany asynchronicznie, a status można sprawdzić tutaj.” „Nie możemy złożyć takiego oświadczenia w przypadku integracji zewnętrznej.” Te zdania mogą wydawać się mniej magiczne niż uniwersalna obietnica prywatności. Pozwalają kupującemu zaprojektować realny proces.

Pytania, które warto zadać, zanim wpłynie prośba

Organizacja nie musi wymyślać naruszenia, osoby w kryzysie ani heroicznego nocnego incydentu, aby przetestować swój projekt usuwania danych. Może wykorzystać wyraźnie oznaczony hipotetyczny wniosek w zwykłych godzinach pracy. Załóżmy, że osoba prosi o usunięcie materiału przechowywanego w systemie dostępnym dla klientów. Który zespół otrzymuje wniosek? Jak weryfikowana jest tożsamość bez zbierania nadmiernych nowych informacji? Które cele są istotne? Które systemy zawierają dane źródłowe, pochodne, indeksy, logi, pamięci podręczne, eksporty i kopie odzyskiwania? Którzy procesorzy potrzebują instrukcji lub powiadomienia? Jaki wyjątek lub obowiązek retencji, jeśli w ogóle, ma zastosowanie? Kto może podjąć decyzję? Kto może ją wykonać? Jak organizacja wyjaśni wynik?

Następnie zadaj niewygodne pytania techniczne. Czy operator może znaleźć bieżący inwentarz danych bez byłego inżyniera? Czy indeks wyszukiwania można sprawdzić niezależnie od jego tabeli źródłowej? Czy usunięty identyfikator pojawia się ponownie po przywróceniu? Czy zadania wsadowe korzystają ze starych migawek? Czy magazyn osadzeń można powiązać z jego dokumentami i dzierżawcą? Czy potok monitorujący domyślnie przechwytuje treść promptów? Czy pliki eksportu podlegają tym samym zasadom retencji co ich źródło? Czy zapis dowodowy tworzy nowy stos wrażliwych treści? To nie są przypadki brzegowe dodane, aby polityka wyglądała na poważną. To zwykłe konsekwencje systemów, które tworzą kopie, aby działać.

Na koniec zadaj pytanie o zarządzanie: co sprawiłoby, że organizacja zmieniłaby swoją odpowiedź? Nowy obowiązek prawny, zakwestionowana tożsamość, otwarte roszczenie prawne, zmieniona umowa z dostawcą, nieudana weryfikacja usunięcia, przywrócona kopia zapasowa, nowy potok modelu lub decyzja organu nadzorczego mogą mieć znaczenie. Proces bez wyzwalacza przeglądu to po prostu wstępne przypuszczenie, które awansowano do rangi polityki.

Żadne z powyższych nie zastępuje porady prawnej w konkretnej sprawie. Wymogi RODO, prawo krajowe, obowiązki sektorowe, umowy i fakty dotyczące przetwarzania mają znaczenie. Ale organizacje nie potrzebują sporu prawnego, aby zacząć projektować warunki dla zrozumiałej odpowiedzi. Muszą znać swoje systemy na tyle dobrze, aby przestać oferować prostą obietnicę wobec skomplikowanej rzeczywistości.

Prywatność to jakość pozostałości

Ambicją stojącą za usuwaniem nie jest uczynienie przeszłości nieprawdziwą. Chodzi o zapewnienie ludziom rzeczywistej kontroli tam, gdzie dane nie muszą już być przetwarzane, gdzie wycofano zgodę, gdzie przetwarzanie jest niezgodne z prawem lub gdzie ma zastosowanie inna podstawa z artykułu 17. Wymaga od administratorów traktowania danych osobowych jako czegoś przechowywanego w określonym celu, a nie jako surowca z nieograniczonym prawem pobytu. Wymaga wyjaśniania wyjątków zamiast używania ich jako maszyny do zamgławiania. Wymaga, aby systemy niosły wystarczającą linię pochodzenia, aby zapominanie mogło być celowe.

W przypadku usług cyfrowych cichym testem jest to, co pozostaje. Po usunięciu rekordu z ekranu produktu, co wciąż jest aktywne? Po opuszczeniu korpusu wyszukiwania przez dokument, jaka pochodna reprezentacja wciąż go wybiera? Po usunięciu konta, jaki log jest przechowywany, w jakim celu i jak długo? Po przywróceniu kopii zapasowej, co zapobiega powrotowi wycofanego rekordu? Po zmianie modelu, jaka historia danych może być zbadana? Po zamknięciu wniosku, czy organizacja może wykazać swoją pracę bez budowania kolejnego ukrytego profilu?

System rzadko odpowie na wszystkie te pytania jednym działaniem i jednym znacznikiem czasu. To normalne. Nienormalne jest udawanie, że pytania znikają, ponieważ dane są trudne, rozproszone lub dochodowe. Prywatność to nie moment, w którym usługa poznaje polecenie usunięcia. To to, co pozostaje po tym, jak system nauczył się zapominać z celem, granicą i zapisem własnej powściągliwości.

Źródła