A magánélet az, ami megmarad, miután a rendszer megtanult felejteni.

A törléshez való jog nem egy „Törlés” gomb. A modern rendszerekben ez fegyelmezett kérdés a másolatokról, a származtatott adatokról, a bizonyítékokról, a...

A magánélet az, ami megmarad, miután a rendszer megtanult felejteni.

A felejtés nem a megjegyzés ellentéte

A papíralapú irat élete megnyugtatóan kézzelfogható. Megérkezik, valahová elteszik, lemásolják, ha van fénymásoló, végül pedig iratmegsemmisítőbe vagy levéltárba kerül. A nehéz rész talán az, hogy eldöntsük, meg kell-e semmisíteni, de maga a tárgy kényelmesen véges. A digitális nyilvántartás kevésbé udvarias. Tárolható sorként, mellékletként, keresési indexként, üzenet-előnézetként, biztonsági mentési blokkként, naplóbejegyzésként, modellbemenet jellemzőjeként, vektor egy beágyazási tárban, gyorsítótárazott válaszként vagy olyan értékként, amely egy másik szervezet rendszerébe vándorolt. Nem elég megkérdezni, hol él az eredeti. A hasznosabb kérdés az, hogy mi készült belőle, mi teszi még mindig lehetővé egy személy azonosítását, és milyen célt szolgál minden megmaradt nyom.

Ez a törléshez való jog gyakorlati méltósága. Gyakran a felejtéshez való jognak nevezik, ami szemléletes, de tökéletlen kifejezés. Az emberi felejtés véletlenszerű, részleges, és tele van kínos visszatérésekkel. A jogszerű törlési folyamatnak szándékosnak kell lennie. Különbséget kell tudnia tenni a törlendő nyilvántartás és a törvény által megőrzendő nyilvántartás között, a jogi védelemhez rendelkezésre álló vitatott követelés és a műszaki maradvány között, amely elkülöníthető a tervezett lejáratáig. Ellen kell állnia egy hasznos vállalati ösztönnek is: a törlés kezelésének képernyőállapotként, nem pedig rendszertulajdonságként.

Az általános adatvédelmi rendelet nem ígéri, hogy minden, egy személyhez kapcsolódó elem eltűnik kérésre. A 17. cikk meghatározza azokat az indokokat, amelyek alapján az adatkezelőnek indokolatlan késedelem nélkül törölnie kell a személyes adatokat, ideértve azt is, ha az adatokra már nincs szükség az összegyűjtésük vagy feldolgozásuk céljához, ha a hozzájárulást visszavonják, és nincs más jogalap, valamint ha a feldolgozás jogellenes volt. Ugyanez a cikk korlátokat is szab. A törlés nem alkalmazandó, ha a feldolgozás szükséges például a véleménynyilvánítás és a tájékozódás szabadsága, jogi kötelezettség, bizonyos körülmények között közérdekű feladatok, közegészségügyi okok, biztosítékokkal végzett archiválás, kutatás vagy statisztika, illetve jogi igények érvényesítése céljából. Ez nem kiskapu egy ígéretben. Ez a jog tényleges alakja.

A rendszertulajdonos kérdése tehát nem az, hogy „Tudunk-e adatot törölni?” Szinte minden rendszer tud törölni valamit. A kérdés az, hogy a szervezet meg tudja-e magyarázni egy adott kérelem és egy adott feldolgozási cél esetén, hogy milyen adatokkal rendelkezik, mi történt ezekkel az adatokkal, mit köteles vagy jogosult megőrizni, mely továbbító címzetteket kell tájékoztatni, és hogyan ellenőrizhető az elvégzett művelet. A különbség eljárásinak hangzik. A gyakorlatban építészeti. Az a termék, amely csak az információ hozzáadását ismeri, rájön, hogy a törlés sokkal drágább funkció.

Ez különösen éles az AI-rendszerek esetében, de nem korlátozódik az AI-ra. A keresés, az analitika, az ügyfélszolgálat, az identitáskezelés, a biztonsági megfigyelés és a dokumentumkezelés mind származékos adatokat hoz létre. A modell csak új neveket ad a problémának: tokenek, gradiensek, beágyazások, lekérési indexek, promptok és kimenetek. Egyik címke sem oldja fel az alapkérdést, hogy egy természetes személy azonosítható-e. Egy műszaki kifejezés sem válaszolja meg csendben a jogi kérdést. A beágyazás nem automatikusan anonim, mert nehezen olvasható. A napló nem automatikusan szükséges, mert hasznos. A biztonsági mentés nem automatikusan mentesül, mert kényelmetlen.

A felejtés utáni adatvédelem tehát nem üres lap. Ez az a maradék állapot, amely azután marad, hogy egy szervezet jogszerű, arányos és ellenőrizhető döntést hozott arról, hogy mit ne dolgozzon fel tovább. Ennek a maradék állapotnak a minősége sokkal többet mond el az embereknek egy rendszerről, mint amennyit a törlés gomb jelenléte valaha is elárul.

A jognak feltételei vannak, és ez erősebbé teszi

Az európai adatvédelmi jogot néha úgy szokták bemutatni, mintha egy univerzális piros gombot kínálna az egyénnek. Ez a kép egy diához elég rendezett, de ahhoz már túl pontatlan, hogy bajt okozzon. A 17. cikk az adatkezelés céljához, jogalapjához és körülményeihez kötődik. Jogot, az adatkezelőkre háruló kötelezettségeket és olyan kivételeket tartalmaz, amelyek más jogokat és közérdekeket védenek. A felelős válaszadás azzal kezdődik, hogy az adatkezelő szükség esetén megállapítja a kérelmező személyazonosságát, megérti az érintett adatokat és az adatkezelés célját, majd eldönti, hogy a 17. cikk valamely jogalapja és egy kivétel alkalmazható-e. A válasz lehet törlés. Lehet indokolt elutasítás egészben vagy részben. Lehet az adatkezelés korlátozása, amíg egy vita rendeződik. Az is lehet, hogy a kérelem olyan rendszerre mutat, amelyet a szervezet nem ellenőriz.

Ez nem ok arra, hogy az érintetti kérelemből egy kis akadálypályát csináljunk. A GDPR megköveteli az adatkezelőktől, hogy megkönnyítsék a jogok gyakorlását. A 12. cikk megköveteli, hogy a kérelem alapján tett intézkedésekről szóló tájékoztatás és kommunikáció tömör, átlátható, érthető és könnyen hozzáférhető legyen. Általában megköveteli, hogy az intézkedésről indokolatlan késedelem nélkül, de mindenképpen a kézhezvételtől számított egy hónapon belül tájékoztassák az érintettet. A határidő további két hónappal meghosszabbítható, ha szükséges, figyelembe véve a kérelmek összetettségét és számát, de az adatkezelőnek az első hónapon belül tájékoztatnia kell az érintettet a meghosszabbításról és annak okairól. Egy olyan rendszer, amely a harmadik hónapig nem képes azonosítani a saját adatáramlásait, nem eljárásjogi védelemre talált. Egy irányítási problémára talált.

Az Európai Adatvédelmi Testület kis- és középvállalkozásoknak szóló iránymutatása világosan megfogalmazza a gyakorlati szempontot: az emberek bizonyos körülmények között kérhetik adataik törlését, és a szervezeteknek eljárásokkal kell rendelkezniük a jogérvényesítési kérelmek megválaszolására. Az eljárás nem egy megosztott meghajtón tárolt jogi vélemény. Ez egy működő útvonal a kérelemtől a döntésen át a végrehajtásig. Tartalmazza azokat a szerepköröket, amelyek döntést hozhatnak, azokat az adattérképeket, amelyek lehetővé teszik a releváns adatkezelés átlátását, azokat a beszállítókat és címzetteket, akiket esetleg értesíteni kell, azokat a megőrzési ütemterveket, amelyek egy kivételt megmagyaráznak, és azokat a bizonyítékokat, amelyek lehetővé teszik egy későbbi felülvizsgáló számára, hogy megértse, mi történt.

A Bíróság segített láthatóvá tenni egy másik megkülönböztetést is. A linkeltetés megszüntetésére vonatkozó ítéletei a keresőmotorok által megjelenített találati listákra vonatkoznak, nem pedig arra, hogy a mögöttes publikációt törölni kell a forrásweboldalról. A Google Spain ügyben a Bíróság kimondta, hogy a keresőmotor üzemeltetője felelős lehet a harmadik felek által közzétett weboldalakon megjelenő személyes adatok kezeléséért, és hogy az érintett bizonyos körülmények között kérheti a nevére történő keresés eredményeként megjelenő találati listából a linkek eltávolítását. A későbbi ügyekben a Bíróság többek között az érzékeny adatokkal, a linkeltetés megszüntetésének területi hatályával és a pontatlan információkkal foglalkozott. Ezek az ügyek nem változtatnak minden nem kívánt tényt törlési igénnyé. Megmutatják, miért kell egy rendszernek megneveznie az érintett réteget: forráspublikáció, index, találati lista, gyorsítótár, kivonat vagy egy másik másolat.

Ez a rétegfegyelem a szervezeteken belül is fontos. Egy munkavállaló kérheti az adatkezelőtől egy olyan kapcsolattartási adat törlését, amelyre a toborzási célból már nincs szükség. Az adatkezelőnek külön megőrzési kötelezettséget kell értékelnie a bérszámfejtés vagy az egyenlő bánásmódra vonatkozó bizonyítékok tekintetében. Egy közintézmény törvényi feladat alapján kezelhet egy adatot, és az alkalmazandó jogot kell értékelnie, nem pedig a magánszektorbeli választ megismételnie. Egy kiadónak mérlegelnie kell a véleménynyilvánítás és a tájékozódás szabadságát. Az eredményt nem lehet pusztán adatbázis-szókincsből eldönteni.

Csábító lenne neheztelni a feltételekre, mert megakadályoznak egy egyszerű ígéretet. De éppen ezek teszik az ígéretet értelmessé. Egy jog, amely figyelmen kívül hagyja a jogi kötelezettségeket, más alapvető jogokat és a rendszerek közötti gyakorlati különbségeket, puszta rituálévá silányulna. Az európai megközelítés elszámoltatható döntést követel, nem színháziat. Ez több munkával jár. Ugyanakkor a megtagadást megtámadhatóvá, a törlést pedig hitelessé teszi.

A törlés a feldolgozási felületek felkutatásával kezdődik. Az ábra rendszertérkép, nem pedig állítás arról, hogy minden felület azonos jogi megítélés alá esik.

Egy rekord eltűnhet a képernyőről, miközben a rendszerben marad

A törlés leggyakoribb kudarca minden alkalmazásfejlesztő számára ismerős: eltávolítjuk az elemet a termék felületéről, az alapul szolgáló adatot a tárolóban hagyjuk, és feltételezzük, hogy a munka kész, mert az átlagos felhasználók már nem látják. Néha a lágy törlés pontosan a helyes működési tervezés. Megőrizhet egy rövid visszavonási időszakot, biztonságossá teheti a replikációt, vagy elkerülheti egy olyan kapcsolat megszakítását, amelyet rendezni kell. De a lágy törlés nem törlés csupán azért, mert a felület csendesebb lett. Használatát meghatározott célhoz, megőrzési időszakhoz, hozzáférés-vezérléshez és egy későbbi művelethez kell kötni, amely valóban megváltoztatja az adatállapotot.

A kemény törlésnek is megvannak a maga korlátai. Egy sor törlése után a keresési index akár a következő indexelési ciklusig megmaradhat. Egy objektumtárban lehet verziókezelés. Egy tartalomszolgáltató gyorsítótár a lejáratig vagy érvénytelenítésig őrizheti a választ. Egy üzenetsor tartalmazhat olyan eseményt, amelyet még nem dolgoztak fel. Egy adattárház már betölthetett egy pillanatképet. Egy szolgáltatás átadhatta az adatot egy feldolgozónak, alfeldolgozónak vagy címzettnek. A gyakorlati tanulság nem az, hogy a törlés lehetetlen. Hanem az, hogy a szervezetnek olyan leltárra van szüksége, amely kellő pontossággal megkülönbözteti ezeket a felületeket, és olyan szabályzatra, amely meghatározza, mi történik mindegyiken.

További különbség van a tartalom és a bizonyíték között. Egy ügyfélszolgálati jegy tartalmazhatja az ügyfél üzenetét. A rendszernek szüksége lehet arra, hogy nyilvántartsa: a jegy létezett, lezárult, és jóváhagyott szabály alapján törölték. Ha a teljes üzenetet örökre megőrizzük annak bizonyítására, hogy törölték, az apró bürokratikus remekmű, de nem adatvédelmi intézkedés. A jobb tervezés csak az elszámoltathatósághoz szükséges minimális bizonyítékot őrzi meg, elkülönítve attól a tartalomtól, amelynek már nincs célja. Ez a bizonyíték lehet egy kérelemazonosító, döntéstípus, befejezési időpont, alkalmazandó megőrzési kategória és az érintett rendszerek. A tervezés a szervezettől függ. Az elv nem: a bizonyíték nem teremtheti újra a felesleges személyes adatokat.

A biztonsági mentésekre ugyanez a világos megfogalmazás vonatkozik. A biztonsági mentés szükséges lehet a rendelkezésre álláshoz, a biztonsághoz vagy a katasztrófa-helyreállításhoz. Mégis feldolgozásnak minősül. A gyakorlati kérdés az, hogy a biztonsági mentés külön hozzáférhető-e, meddig állítható helyre, ki állíthatja helyre, beletartozik-e a szokásos törlési folyamatba, és hogyan akadályozható meg, hogy egy helyreállított környezet csendesen visszahozza azokat az adatokat, amelyeket időközben eltávolítottak az éles rendszerből. Egy ésszerű szabályzat támaszkodhat a biztonsági mentés meghatározott rotációs időszakára, ahelyett hogy minden történelmi biztonsági mentési blokkot egyenként módosítana. De a szabályzatnak ezt ki kell mondania, időközben védenie kell a hozzáférést, és gondoskodnia kell arról, hogy a helyreállítás a lehetőségek szerint a jelenlegi adatállapotot kövesse. Az, hogy „benne van a biztonsági mentésben”, problémát ír le. Nem válasz rá.

A naplók hasonlóak. A biztonsági és üzemeltetési naplók alapvető fontosságúak lehetnek. Ezek jelenthetik az egyetlen forrást a hozzáférésről, egy sikertelen hitelesítési kísérletről vagy egy éles környezeti változtatásról. Ugyanakkor azonosítókat, címeket, kérés-törzseket vagy tartalomtöredékeket is megőrizhetnek, amelyekre soha nem volt szükség a diagnosztikához. A jól megtervezett naplózás már a gyűjtéskor minimalizál, szükség esetén maszkol vagy pszeudonimizál, elkülöníti a érzékeny adatokat az esemény-metadatoktól, korlátozza a hozzáférést, és megőrzési ütemterveket alkalmaz. Megpróbálni minden érzékeny mezőt felderíteni egy törlési kérelem során lehetséges, de ez gyenge helyettesítője annak, ha már a tervezéskor eldöntjük, hogy a naplónak mit nem szabadott volna tartalmaznia.

Egy műszaki felelősnek nem kell azonnali, minden eszközre kiterjedő egységes törlést ígérnie ahhoz, hogy felelősségteljesen járjon el. Viszont tudnia kell megfogalmazni az életciklust: mi válik azonnal elérhetetlenné, mi törlődik a következő feldolgozási ciklusban, mi marad meg dokumentált megőrzési ütemterv szerint, mi marad védett a lejáratig, és mi történik, ha helyreállítási műveletre kerül sor. Ez az ismertetés konkrét vizsgálati alapot ad egy személynek, egy szabályozó hatóságnak és egy üzemeltetőnek. Egy zöld értesítési felugró ablak nagyon keveset ad nekik.

A származtatott adatok nem jelentenek kibúvót

A modern rendszerek gyakran átalakítják a személyes adatokat, mielőtt felhasználnák őket. Kinyernek egy dátumot egy dokumentumból, osztályoznak egy üzenetet, kiszámítanak egy pontszámot, következtetnek egy nyelvre, keresési indexet hoznak létre, összefoglalót készítenek, összekapcsolnak két fiókot, vagy szöveget és képeket vektorokká alakítanak hasonlósági kereséshez. Ezek az átalakítások hasznosak lehetnek. Azt is okozhatják, hogy egy szervezet úgy érzi, túllépett a személyes adatokon. Ez azonban nem feltétlenül történt meg.

A GDPR technológiailag semleges. Preambuluma kifejti, hogy azok a pszeudonimizált adatok, amelyek további információk segítségével egy természetes személyhez rendelhetők, egy azonosítható természetes személyre vonatkozó információnak tekintendők. Azt is kifejti, hogy az azonosíthatóság meghatározásakor figyelembe kell venni minden olyan eszközt, amelyet az adatkezelő vagy egy másik személy ésszerűen valószínűleg felhasznál, olyan tényezők alapján, mint a költség, az idő, a rendelkezésre álló technológia és a technológiai fejlődés. A kérdés nem az, hogy egy megjelenítési forma hasonlít-e egy névre egy táblázatban. Hanem az, hogy a tényleges kontextusban egy azonosított vagy azonosítható személyre vonatkozik-e.

Egy beágyazás (embedding) hasznosan kínos pontra világít rá. Egy lekérdezőrendszerben egy dokumentum darabokra osztható és numerikus vektorokként ábrázolható, hogy egy lekérdezés szemantikailag hasonló anyagot találjon. A vektor nem olvasható bekezdés. Mégis kapcsolódhat egy forrásdokumentumhoz, bérlőhöz, felhasználóhoz, hozzáférés-vezérléshez, metaadat-mezőhöz vagy lekérési kulcshoz. Lehetővé teheti, hogy a rendszer személyes anyagot válasszon ki egy lekérdezésre válaszul. A szervezet nem nevezheti anonimnak pusztán azért, mert egy ember nem tud egy mondatot rekonstruálni egy koordinátalistából. Fel kell mérnie a megjelenítési formát, a kapcsolódó adatokat, a kapcsolódás eszközeit és a feldolgozás célját.

Ugyanez vonatkozik egy származtatott pontszámra is. Egy kockázati pontszám, preferenciakategória vagy jogosultsági mutató kevesebb nyers részletet tartalmazhat, mint a forrásadat, mégis komoly hatással lehet az érintettre. Személyes adatnak minősülhet, ha egy azonosított vagy azonosítható személyre vonatkozik. A forrás törlése, miközben egy olyan pontszám megmarad, amely továbbra is befolyásol egy döntést, nem tiszta megoldás. Egyszerűen egy átláthatatlanabb formába helyezheti az érintettet. A rendszernek szabályra van szüksége a származtatott adatokra: melyek törlődnek a forrással együtt, melyeket számítanak újra, melyeket nem lehet tovább használni, melyeket kell külön kötelezettség alapján megőrizni, és ki dönt erről.

Nincs olyan egyetemes technikai teszt, amely minden származtatott adatot egyértelműen eldöntene. Egyes összesített statisztikák lehetnek anonimak. Egyesek továbbra is sebezhetők lehetnek a kiemeléssel vagy összekapcsolással szemben. Egyes modellparaméterek egy adott kontextusban nem feltétlenül tulajdoníthatók észszerűen egy személyhez. Mások kapcsolódhatnak tanítási adatokhoz, egy szűken meghatározott modellhez vagy olyan támadási felülethez, amely megváltoztatja az értékelést. A GDPR anonim adat fogalma nem díszcímke azokra az adatokra, amelyeket kényelmetlenné tettek az értelmezéshez. Az adatkezelőnek az azonosítás eszközein és kontextusán alapuló értékelést kell végeznie.

Ez a bizonytalanság nem ok arra, hogy minden származtatott adatot véglegesen mérgezőként írjunk le. Ez ok a származási nyilvántartás vezetésére. Egy csapatnak tudnia kell, hogy mely bemeneti gyűjteményeket használták egy jellemzőtárhoz, indexhez, tanítási futtatáshoz vagy jelentési táblához; mely verziókat állították elő egy származtatott adatból; mely rendszerek fogyasztják azokat; és milyen választ kell kiváltania a forrás változásának. A származási nyilvántartás egy kényelmetlen kérdést behatárolt mérnöki feladattá alakít. Enélkül minden jogi kérelem régészeti expedícióvá válik feladatneveken, tárolóhelyeken és valakinek a két téllel ezelőtti migrációról őrzött emlékein keresztül.

A gépi tanulás nehéz kérdést vet fel, nem varázslatos felmentést ad

A gépi tanulás azért teszi nehézzé a törlést, mert a tanítás nem iratkezelési művelet. Egy tanítási példa hosszú frissítési sorozaton keresztül, sok más példával együtt befolyásolhatja a paramétereket. Egy telepített modellt több környezetbe is átmásolhattak. Egy későbbi modell finomhangolva készülhetett egy korábbiból. Egy csapat használhat értékelési adatokat, promptokat, keresési gyűjteményeket és visszajelzési naplókat, amelyek mind különböző életciklust követnek. Ha egy személy adatai bekerültek egy ilyen rendszerbe, a szervezet nem felelhet felelősen vállrándítással a matematikára hivatkozva. Azt sem ígérheti őszintén, hogy egyetlen adatbázis-törlés minden lehetséges hatást eltávolít minden paraméterből.

Az első lépés a rendszerek szétválasztása. A keresési gyűjtemény nem tanított modell. Ha egy dokumentumot keresési forrásként használnak, a törlés magában foglalhatja a dokumentum, annak darabjai, metaadatai és indexbejegyzései eltávolítását vagy letiltását, majd annak ellenőrzését, hogy a keresés többé nem éri el. A promptnapló nem beágyazási tár. A finomhangolási adatkészlet nem biztonsági auditnyom. A modell-ellenőrzőpont nem aktuális forrásnyilvántartás. A helyes válasz felületenként eltérő lehet, de választ nem lehet tervezni, amíg a felületeket meg nem nevezték.

A tanítási adatok esetében a jogszerű és technikai elemzés döntést igényelhet arról, hogy az újratanítás, a csere, a korlátozás, a megőrzés vagy más intézkedés megfelelő-e. A gépi felejtés kutatása azért releváns, mert olyan módszereket vizsgál, amelyek csökkentik bizonyos adatok hatását anélkül, hogy a modellt a semmiből újratanítanák. Ez nem általános tanúsítvány arról, hogy egy rendszer elfelejtett. A módszereknek vannak feltételezéseik, modellosztályaik, adatfeltételeik és ellenőrzési korlátaik. Egy szervezet nem forgalmazhat kísérleti technikát a 17. cikk egyetemes megvalósításaként. Ugyanakkor nem is kell várnia egy tökéletes technikára, mielőtt jobb adatkezelési ellenőrzéseket tervezne.

A jobb ellenőrzések feljebb kezdődnek. Minimalizálja a gyűjtött adatokat. Különítse el a személyes adatokat a tanítási anyagtól, ahol a tervezett cél lehetővé teszi. Határozzon meg megőrzési időtartamot, mielőtt a felhalmozás érzelmileg költségessé tenné a kérdést. Vezessen verziózott nyilvántartást az adatkészletekről és tanítási futtatásokról. Tegye egyértelművé a beleegyezésen alapuló vagy más jogszerű feltételeket, ahol azok a releváns jogalapot képezik. Kerülje el, hogy egy éles promptarchívum csendben modellfejlesztési gyűjteménnyé váljon. Tartsa megkülönböztethetőnek az értékelési és támogatási anyagokat a tanítási adatoktól. Minél kevésbé támaszkodik egy rendszer ismeretlen származású adatokra, annál pontosabban tud válaszolni egy törlési kérdésre.

Az „influence” szónak is megvan a maga korlátja. Előfordulhat, hogy valaki aggódik amiatt, hogy egy szöveg egykor része volt egy tanító adathalmaznak. Egy műszaki csapat képes lehet megállapítani, hogy a forrásrekordot eltávolították egy aktuális korpuszból, de filozófiai értelemben nem tudja bizonyítani, hogy egy korábbi modell egyetlen paraméterében sem maradt semmilyen befolyásoló töredék. Az adatvédelmi jog nem válik könnyebbé, ha egy szervezet a konkrét leírást metafizikára cseréli. A kötelezettség az, hogy az adatkezelést, a jogalapokat és az intézkedéseket a jogszabályok szerint értékeljék. A szervezetnek ismertetnie kell következtetésének hatókörét, az általa lefedett rendszereket és a fennmaradó korlátokat. A pontosság kedvesebb, mint egy túlzó ígéret.

Az MI-t üzemeltetők számára a gyakorlati teher gyakran ugyanannyira a beszerzésre hárul, mint a mérnöki munkára. A szállítónak képesnek kell lennie elmagyarázni, hogy mit tesz a promptokkal, a feltöltött fájlokkal, a telemetriai adatokkal és az opcionális visszajelzésekkel; hogy ezek közül melyeket használja tanításhoz vagy szolgáltatásfejlesztéshez; milyen adatmegőrzési szabályozások léteznek; hogyan juthat az ügyfél a jogosultsági kérelmek megválaszolásához szükséges információkhoz; és mi történik megosztott, illetve dedikált környezetben. Egy szerződés, amely pusztán annyit mond, hogy „GDPR-kompatibilis”, nem szolgáltatja az adattörlési eljárás működtetéséhez szükséges információkat. Csupán egy jelzőt szolgáltatott.

A keresőmotorok hasznos leckét adnak a rétegekről

A Bíróság de-indexelésre vonatkozó esetjoga azért hasznos itt, mert szűkebb, mint a „felejtéshez való jog” népszerű kifejezése. Az ügyek arról szólnak, hogy a keresőmotornak milyen feltételek mellett kell eltávolítania a linkeket a névre szóló találatok közül. Nem hoznak létre egyszerű jogot a történelem forrásnál történő megváltoztatására. Ez a megkülönböztetés azt mutatja, hogy az adatvédelmi kérdések gyakran arról szólnak, hogyan teszik elérhetővé, kapcsolják össze és erősítik fel az információt, nem csak arról, hogy egy rekord egyáltalán létezett-e.

A Google Spain ügyben a Bíróság a keresőmotor találati listájában szereplő, harmadik fél által közzétett oldalakra mutató linkeket vizsgált. A döntés egyértelművé tette, hogy a keresőmotor tevékenysége személyes adatok kezelésének minősülhet, és bizonyos feltételek mellett az üzemeltető kötelezhető a linkek eltávolítására az adott személy nevére végzett keresés eredményei közül. A döntés nem az eredeti közleményeket közzétevő újságnak szólt. Egy rendszertulajdonos, aki belső tudásbázist kezel, tanulhat ebből: a keresési indexek, az előnézetek és a találati rangsorolás olyan feldolgozási rétegek, amelyeknek megvannak a maguk következményei.

A GC és mások ügy a kényes személyes adatokat tartalmazó weboldalakra mutató linkek eltávolítására irányuló kérelmeket vizsgálta. A Bíróság foglalkozott az érintett érdekek mérlegelésével és azokkal a kötelezettségekkel, amelyek a keresőmotor üzemeltetőjére hárulhatnak. A Google kontra CNIL ügy a területi hatályt vizsgálta, és az adott ügy körülményei között megállapította, hogy az uniós jog nem követeli meg a de-indexelést a keresőmotor világméretű összes változatában, ugyanakkor hatékony intézkedéseket követel meg annak megakadályozására vagy komoly megnehezítésére, hogy a tagállamokból hozzáférjenek az uniós változatokból eltávolított linkekhez. A TU és RE ügy egy állítólagosan pontatlan információra vonatkozó kérelemmel foglalkozott, és tisztázta a bizonyítási teher egyes elemeit, valamint az előnézeti képek kezelését. Ezek az ítéletek konkrét tényállásra épülő jogi döntések, nem pedig bevezetési ellenőrzőlisták. Együtt egy rendszerszintű szempontot világítanak meg: a link, a találati lista, a képelőnézet és az eredeti oldal nem feltétlenül ugyanazzal a jogorvoslattal rendelkezik.

Ez a szempont jól átvihető más területekre. Egy vállalati portál jogszerűen őrizhet egy forrásrekordot korlátozott célból, miközben a széles keresési felületen keresztül történő hozzáférés túlzó. Egy műszaki támogatási rendszernek szüksége lehet egy védett naplóbejegyzésre, miközben az automatikus kiegészítés előnézetének nem szabad egy korábbi ügyfél adatait egy nagyobb csoport elé tárnia. Egy dokumentum eltávolítható a visszakeresési korpuszból, miközben egy modell által generált összefoglaló egy másik tárolóban marad. A helyes válasz nem az, hogy minden réteget azonosnak nyilvánítunk. Hanem az, hogy megértsük, hogyan változtatja meg a réteg a kitettséget, a célt és a kockázatot.

Figyelmeztet egy népszerű rövidítésre is: arra, hogy a láthatóságot tekintjük az egyetlen adatvédelmi kérdésnek. Egy rekord technikailag rejtett lehet, mégis feldolgozható, lekérdezhető, profilozható, továbbítható vagy visszaállítható. Ezzel szemben egy szervezetnek szüksége lehet egy gondosan korlátozott rekordra annak bizonyításához, hogy megfelelően járt el, jogi igény védelméhez vagy jogszabályi kötelezettség teljesítéséhez. Az adatvédelem nem verseny, amelyben minden elképzelhető körülmények között a lehető legkevesebb adatot kell előállítani. Ez a cél, a szükségesség, az arányosság és az ellenőrzés fegyelme.

Ezért a törlési leltárnak tartalmaznia kell a visszakeresési és megjelenítési útvonalakat. Kérdezzük meg, mely indexek hordozzák a rekordot, mely gyorsítótárak szolgálják ki, mely exportok tartalmazzák, mely API-k adják vissza, mely származtatott mezőket használják rangsorolásra vagy ajánlásra, és mely biztonsági mentési visszaállítási útvonalak tehetik újra élővé. A lista nem lesz elegáns. Hasznosabb lesz, mint az elegancia.

A bemutatás különbözik az állítástól

Amikor egy rendszer azt állítja, hogy képes törölni az adatokat, két külön kérdés merül fel. Az első, hogy a tervezés rendelkezik-e legitim, dokumentált útvonallal ehhez. A második, hogy egy szervezet bizonyítani tudja-e, hogy az adott kérés esetén követték az útvonalat anélkül, hogy több személyes anyagot őriznének meg, mint amennyit a bemutatás megkövetel. Az első termékképesség. A második elszámoltathatóság.

A hasznos törlési nyilvántartás szándékosan szerény. Nem kell reprodukálnia egy személy teljes kérését, dokumentumait vagy fióktörténetét egy új megfelelőségi adatbázisban. Rögzíthet kérésazonosítót, adott esetben a személyazonosság-ellenőrzés eredményét, a kérés kategóriáját, az érintett rendszereket, a döntést és a jogi indoklást megfelelő szinten, az intézkedések dátumait, kivételeket vagy megőrzési okokat, a címzettek értesítését, ahol előírják, valamint az aszinkron törlés vagy a biztonsági mentés lejáratának állapotát. A pontos mezők az adatkezelőtől és a környezettől függenek. A lényeg az, hogy egy későbbi felülvizsgáló lássa az útvonalat anélkül, hogy az érzékeny tartalmat töredékekből rekonstruálná.

Az ellenőrzésnek illeszkednie kell az adatfelülethez. Egy élő alkalmazásrekord ellenőrizhető annak megerősítésével, hogy egy jogosult lekérdezés már nem adja vissza. Egy visszakereső rendszer tesztelhető az eredeti azonosítóval és a releváns lekérdezési mintákkal, miközben kerüljük a személyes tartalom újrateremtésére irányuló széles körű kísérleteket. Egy index jelentheti a törlési állapotát. Egy üzenetsor mutathatja a befejezettséget. Egy biztonsági mentési folyamat megmutathatja, hogy egy helyreállítási lemezkép a megőrzési szabálya szerint védett, és hogy a visszaállítás aktuális törlési naplót vagy azzal egyenértékű ellenőrzést alkalmaz. Az ellenőrzésnek nem kell metafizikai tagadást bizonyítania. Olyan bizonyítékot kell szolgáltatnia, amely arányos az állítással.

Van itt egy szerény csapda. Egy csapat építhet egy lenyűgöző irányítópultot, ahol minden jelzőlámpa zöld, de nincs stabil kapcsolat a tényleges munkával. Egy értelmes irányítópult megnevezi az adatfelületet, az intézkedést, az állapotot, a felelőst, a bizonyítékot és a következő felülvizsgálatot. Lehetővé teszi a „kérés elfogadva”, „élő rekord törölve”, „címzett értesítése függőben”, „biztonsági mentés lejáratra vár” és „jogi kötelezettség alapján megőrizve” állapotok megkülönböztetését. Ezek az állapotok különböző jelentéssel bírnak. Ha mindet töröltnek minősítjük, a bizonytalanság felhasználói felület-tervezési kérdéssé válik.

A bizonyítható törlés a változáskezeléstől is függ. Egy forrásrendszer lecserélhető, egy feldolgozó hozzáadható, egy indexformátum megváltozhat, egy új elemzési célpont bevezethető, vagy egy AI-szállító megőrzési szabályzata felülvizsgálható. Ha a törlési eljárást nem frissítik ezekkel a változásokkal, az eljárás fokozatosan egy olyan rendszert ír le, amely már nem létezik. Az eredmény minden üzemeltetési fegyelemből ismerős: egy gyönyörű üzemeltetési kézikönyv és egy valódi szolgáltatás, amelyek ellentétes irányba haladnak. A kis minta rendszeres tesztelése, beleértve a kényelmetlen rendszert is, általában többet árul el, mint egy nagy megfelelőségi dokumentum megrendelése, amelyet senki sem tud végrehajtani.

Egy közhatalmi szerv vagy szabályozott vállalkozás számára ez nem szűk adatvédelmi ügyosztályi kérdés. Az adatvédelmi tisztviselő irányt mutathat az értelmezésben, de a mérnöki csapat felel a felületekért és a törlési mechanizmusokért, a termékcsapat felel a célért és a felhasználói útvonalért, a beszerzés felel a szállítókkal szembeni tájékoztatási kötelezettségekért, a biztonsági csapat felel a hozzáférésért és a helyreállítási szabályozásokért, az üzemeltetés pedig a nyomás alatti végrehajtásért. Egyetlen tulajdonos sem tud egyedül átlátni minden rétegen. Egy gazdátlan réteget nem tesz biztonságossá az, hogy nehéz róla beszélni.

Egy védhető folyamat rögzíti a döntést és a végrehajtást anélkül, hogy egy második, felesleges életrajzot hozna létre az érintett személyről.

A megőrzés a törlés másik fele

Sok törlési probléma jóval a kérelem előtt kezdődik. Akkor kezdődik, amikor egy rendszerben egyáltalán nincs megőrzési döntés. Az adatok azért érkeznek, mert esetleg hasznosak lehetnek. A naplók azért válnak véglegessé, mert a tárolás olcsó. Az exportokat azért őrzik meg, mert egy jövőbeli audit esetleg kérheti őket. A tanító adatokat azért halmozzák, mert egy későbbi modellnek esetleg hasznára válhatnak. Minden döntés önmagában ártalmatlannak tűnik. Együtt egy nagy, rosszul megértett archívum tulajdonosává teszik a szervezetet, és minden törlési kérelmet drágábbá, bizonytalanabbá és vitatottabbá tesznek.

A GDPR tároláskorlátozás elve szerint a személyes adatokat olyan formában kell tárolni, amely az érintettek azonosítását csak az adatkezelés céljaihoz szükséges ideig teszi lehetővé, hosszabb tárolásra pedig csak közérdekű archiválás, tudományos vagy történelmi kutatási célból, illetve statisztikai célból kerülhet sor, megfelelő garanciák mellett. Az elv nem ír elő egyetlen naptárat minden szervezet számára. Célhoz kötött mérlegelést igényel. A megőrzési ütemtervnek ezért meg kell neveznie az adatkategóriákat, a célt, a jogalapot, a szokásos időtartamot, a kiváltó eseményt, a kivételt, a megsemmisítési intézkedést, a felelőst és a felülvizsgálati pontot. Az „amíg szükséges” elv. Csak akkor válik működési szabállyá, ha valaki meg tudja mondani, hogy mire nézve szükséges, meddig, és ki döntötte el.

Ez a struktúra azért hasznos a mesterséges intelligencia számára, mert megakadályozza, hogy egyetlen tág címke, például a tanító adat, több különböző dolgot rejtsen el. Egy nyers hozzájárulás, egy tisztított adatkészlet, egy jellemzőkészlet, egy modellverzió, egy prompt-előzmény, egy értékelési készlet és egy megfigyelési napló mind rendelkezhet eltérő céllal és megőrzési szempontokkal. Ha egyetlen határozatlan időtartamú kategóriába vonják össze őket, az mind az innovációt, mind az elszámoltathatóságot rontja. A szétválasztásuk nem garantál jogi választ, de lehetővé teszi azt.

A megőrzési döntéseknek is hasznára válik egy elutasítási feltétel. Mi miatt hagynánk abba ennek a megőrzését? Egy lezárt szerződés, egy rendezett vita, egy törvényes időszak vége, egy befejezett biztonsági vizsgálat, egy lecserélt modellverzió, egy helyreállítási időablak lejárta, vagy egy döntés, hogy nem folytatunk egy kutatási célt, mind valódi kiváltó ok lehet. A lényeg nem az, hogy mindenre automatizált törlési órát állítsunk be. Az, hogy elkerüljük azt a rendszert, amelyben az adatok megtartásának egyetlen feltétele, hogy még senkinek sem kellett magyarázatot adnia rájuk.

Van egy kis holland ösztön, amit érdemes megtartani: egy szekrény nem azért rendezett, mert ajtaja van. Azért rendezett, mert meg tudod találni a lényeges dolgot, tudod, miért van ott, és el tudod távolítani anélkül, hogy költöznöd kellene. Egy adatvagyon legalább ezt a szintet megérdemli. Az a megőrzési ütemterv, amely nem éli túl a rendszert üzemeltető emberekkel folytatott beszélgetést, nem ütemterv. Hanem időjárás-előrejelzés jogi prózában megfogalmazva.

Ez nem azt jelenti, hogy minden szervezetnek központosítania kell minden törlési döntést. A helyi csapatok gyakran jobban ismerik a saját folyamataikat. Azt jelenti, hogy a helyi szabályoknak közös fogalmakra, látható felelősségi körökre és eszkalációs útvonalra van szükségük. Ellenkező esetben az egyik csapat archívuma a másik csapat jogsértése lesz, és egy személy kérelme udvariasan elnevezett szolgáltatások útvesztőjén halad keresztül.

Mit mondhat egy őszinte mesterségesintelligencia-szolgáltató

Egy őszinte mesterségesintelligencia-szolgáltató nem állítja, hogy minden ügyféladat elpárolog, amikor egy kérelem megérkezik. Nem bújik a modellek nehézségei mögé sem. Leírja a szolgáltatás határait. Mit dolgoznak fel a következtetéshez. Mit őriznek meg a fiókadminisztrációhoz, biztonsághoz, támogatáshoz, számlázáshoz vagy visszaélés-megelőzéshez. Tárolják-e a felszólításokat és a kimeneteket. Használják-e őket képzésre, értékelésre vagy szolgáltatásfejlesztésre. Mely feldolgozók és régiók érintettek. Hogyan konfigurálhatják az ügyfelek a megőrzési időt. Milyen dokumentáció létezik az érintetti kérelmekhez. Mely műveletek azonnaliak, melyek aszinkronok, és melyek függenek külön jogi értékeléstől.

A vásárlók számára a beszerzési kérdések gyakorlatiasak. Kaphatunk-e egyértelmű adatfolyam-térképet? Azonosíthatjuk-e az adatkezelő és az adatfeldolgozó szerepét az érintett feldolgozásnál? Exportálhatjuk-e vagy törölhetjük-e az anyagot használható módon? Beletartoznak-e a visszakeresési indexek és a származtatott tárolók a dokumentált életciklusba? Mi történik a biztonsági mentésekkel? Hogyan kommunikálják az alvállalkozói feldolgozók változásait? Tud-e a szolgáltató segíteni nekünk az alkalmazandó határidőn belüli válaszadásban? A képzési és szolgáltatásfejlesztési felhasználások opt-in, opt-out, szerződésben kizárt vagy csak egy olyan oldalon leírt jellegűek-e, amely a vásárlás után megváltozhat? Mely technikai nyilvántartások állnak rendelkezésre a fellépés bizonyítására?

A válaszok változni fognak. Egy nagy, megosztott szolgáltatás nem mindig tud ugyanolyan szintű ellenőrzést biztosítani, mint egy dedikált környezet. Egy biztonsági napló nem mindig törölhető ugyanabban a pillanatban, mint egy fiókprofil. Egy törvényi kötelezettségen alapuló archívumot nem lehet úgy kezelni, mint egy fogyasztói beállítást. Ezek a különbségek nem feltétlenül hibák. A róluk való hallgatás az. A vásárló helyes válasza az, hogy a szolgáltatás dokumentált viselkedését hozzáigazítja a szervezet céljához, kötelezettségeihez és kockázatához. Egy termék alkalmatlan lehet egy rendkívül érzékeny feladatra, még akkor is, ha teljesen alkalmas egy alacsony kockázatú szövegtervező eszköznek.

A Dweve-nél a Trust Centre ugyanezt a szűk értelmezést alkalmazza a bizonyítékokra. Egy nyilvános oldal leírhatja az ellenőrzéseket és a dokumentációs határokat, de nem tanúsíthat minden ügyfél-telepítést, és nem döntheti el az ügyfél feldolgozásának jogalapját. Ez a határ számít. Egy platform támogathatja a megőrzési ellenőrzéseket, a nyilvántartásokat és a felülvizsgálható munkafolyamatokat. A szervezet, amely használja, továbbra is felelős a saját céljáért, adatválasztásaiért és azért a döntésért, hogy egy adott személynek válaszol. A jó termékszövegnek világosabbá kell tennie ezt a felelősséget, nem pedig csendben magára vállalnia.

A legértékesebb szolgáltatói nyilatkozat gyakran egy korlátozás. „Ez a nyilvántartás a védett biztonsági mentésekben marad a megadott rotációs időszak végéig.” „Ez a szolgáltatás nem használja a megadott ügyféltartalmat képzésre ezen feltételek mellett.” „Ezt az indexet aszinkron módon távolítjuk el, és az állapot itt ellenőrizhető.” „Ezt az állítást nem tudjuk megtenni egy harmadik féltől származó integrációra.” Ezek a mondatok kevésbé tűnhetnek varázslatosnak, mint egy egyetemes adatvédelmi ígéret. Lehetővé teszik a vásárló számára, hogy valódi folyamatot tervezzen.

Kérdések, amelyeket érdemes feltenni, mielőtt a kérelem megérkezik

Egy szervezetnek nem kell feltalálnia egy adatszivárgást, egy zaklatott személyt vagy egy hősies éjszakai incidenst ahhoz, hogy tesztelje a törlési tervét. Használhat egy egyértelműen jelölt hipotetikus kérelmet rendes munkaidőben. Tegyük fel, hogy valaki kéri az ügyfélkapcsolati rendszerben tárolt anyagok törlését. Melyik csapathoz érkezik a kérelem? Hogyan ellenőrzik a személyazonosságot anélkül, hogy szükségtelenül sok új adatot gyűjtenének? Mely célok relevánsak? Mely rendszerek tartalmaznak forrásadatokat, származtatott adatokat, indexeket, naplókat, gyorsítótárakat, exportokat és helyreállítási másolatokat? Mely feldolgozóknak kell utasítást vagy értesítést küldeni? Mely kivétel vagy megőrzési kötelezettség vonatkozik, ha egyáltalán van ilyen? Ki dönthet? Ki hajthatja végre? Hogyan magyarázza el a szervezet az eredményt?

Ezután jöjjenek a kínos technikai kérdések. Meg tudja-e találni egy üzemeltető a jelenlegi adatleltárt egy korábbi mérnök nélkül? Ellenőrizhető-e egy keresési index a forrástáblájától függetlenül? Megjelenik-e újra egy törölt azonosító egy visszaállítás után? Használnak-e a kötegelt feladatok régi pillanatképeket? Összekapcsolható-e egy beágyazás-tároló a dokumentumaival és a bérlővel? Rögzíti-e a megfigyelési folyamat alapértelmezés szerint a promptok tartalmát? Ugyanazok a megőrzési szabályok vonatkoznak-e az exportfájlokra, mint a forrásukra? A bizonyítékrögzítés létrehoz-e egy új halom érzékeny tartalmat? Ezek nem szélsőséges esetek, amelyeket csak azért adtak hozzá, hogy a szabályzat komolynak tűnjön. Ezek a másolatkészítéssel működő rendszerek hétköznapi következményei.

Végül jöjjön a kormányzási kérdés: mi késztetné a szervezetet arra, hogy megváltoztassa a válaszát? Egy új jogi kötelezettség, egy vitatott személyazonosság, egy folyamatban lévő jogi igény, egy megváltozott beszállítói megállapodás, egy sikertelen törlés-ellenőrzés, egy visszaállított biztonsági másolat, egy új modellfolyamat vagy egy hatósági döntés mind számíthat. Egy felülvizsgálati kiváltó ok nélküli folyamat egyszerűen egy kezdeti feltételezés, amelyet szabályzattá léptettek elő.

Egyik sem helyettesíti a jogi tanácsadást egy adott ügyben. A GDPR követelményei, a nemzeti jog, az ágazati kötelezettségek, a szerződések és a feldolgozás tényei mind számítanak. De a szervezeteknek nem kell jogvitába keveredniük ahhoz, hogy elkezdjék kialakítani az érthető válasz feltételeit. Elég jól kell ismerniük a rendszereiket ahhoz, hogy ne kínáljanak egyszerű ígéretet egy bonyolult valóságra.

A magánélet védelme a maradék minősége

A törlés mögött álló szándék nem az, hogy a múltat valószerűtlenné tegyék. Az a cél, hogy értelmes kontrollt adjanak az embereknek ott, ahol az adatokat már nem kell feldolgozni, ahol a hozzájárulást visszavonták, ahol a feldolgozás jogellenes, vagy ahol a 17. cikk más indoka érvényesül. Arra kéri az adatkezelőket, hogy a személyes adatokat célból tárolt dologként kezeljék, ne pedig határozatlan idejű bérletre kapott nyersanyagként. Arra kéri őket, hogy magyarázzák el a kivételeket, ne pedig ködösítésre használják azokat. Arra kéri a rendszereket, hogy elegendő származási adatot hordozzanak ahhoz, hogy a felejtés szándékos lehessen.

A digitális szolgáltatások esetében a csendes teszt az, ami megmarad. Miután egy rekordot eltávolítottak egy termékképernyőről, mi marad még életben? Miután egy dokumentum kikerül egy keresési korpuszból, milyen származtatott reprezentáció választja még ki? Miután egy fiókot töröltek, milyen naplót őriznek meg, milyen célból és meddig? Miután egy biztonsági másolatot visszaállítottak, mi akadályozza meg, hogy egy nyugdíjazott rekord visszatérjen? Miután egy modell megváltozik, milyen adatelőzmények vizsgálhatók? Miután egy kérelmet lezártak, tudja-e a szervezet megmutatni a munkáját anélkül, hogy újabb rejtett profilt építene?

Egy rendszer ritkán válaszol meg mindezekre a kérdésekre egyetlen művelettel és egyetlen időbélyeggel. Ez normális. Ami nem normális, az az, ha úgy teszünk, mintha a kérdések eltűnnének, mert az adatok nehezek, szétszórtak vagy nyereségesek. A magánélet védelme nem az a pillanat, amikor egy szolgáltatás megérti a törlési parancsot. Hanem az, ami megmarad, miután a rendszer megtanult céllal, határokkal és saját önmérsékletének rögzítésével felejteni.

Források