Yksityisyys on sitä, mikä jää jäljelle, kun järjestelmä on oppinut unohtamaan.
Unohtaminen ei ole muistamisen vastakohta
Paperiarkistolla on lohdullisen näkyvä elämä. Se saapuu, se pannaan jonnekin, siitä otetaan kopio jos jollakulla on kopiokone, ja lopulta se päätyy silppuriin tai arkistoon. Vaikea osuus voi olla päättäminen siitä, pitäisikö se tuhota, mutta itse esine on soveliaasti rajallinen. Digitaalinen tallenne on vähemmän kohtelias. Se voidaan tallentaa rivinä, liitteenä, hakemistona, viestin esikatseluna, varmuuskopiolohkona, auditointimerkintänä, ominaisuutena mallin syötteessä, vektorina upotusvarastossa, välimuistivastauksena tai arvona, joka on kulkeutunut toisen organisaation järjestelmään. Ei riitä, että kysytään, missä alkuperäinen sijaitsee. Hyödyllisempi kysymys on, mitä siitä on tehty, mikä yhä mahdollistaa henkilön tunnistamisen ja mitä tarkoitusta kukin jäljelle jäävä jälki palvelee.
Tämä on käytännöllinen arvokkuus oikeudessa tietojen poistamiseen. Sitä kutsutaan usein oikeudeksi tulla unohdetuksi, mikä on elävä ilmaus mutta epätäydellinen. Ihmisen unohtaminen on sattumanvaraista, osittaista ja täynnä kiusallisia paluita. Lainmukaisen poistoprosessin pitäisi olla harkittu. Sen pitäisi kyetä erottamaan tallenne, joka on poistettava, tallenteesta, joka on säilytettävä, koska laki sitä vaatii, riidanalaisesta väitteestä, jonka on pysyttävä saatavilla oikeudellista puolustusta varten, ja teknisestä jäänteestä, joka voidaan eristää sen suunniteltuun vanhenemiseen asti. Sen pitäisi myös vastustaa hyödyllistä yritysvaistoa: poistamisen kohtelemista näyttötilana järjestelmäominaisuuden sijaan.
Yleinen tietosuoja-asetus ei lupaa, että jokainen henkilöön liittyvä tieto katoaa pyynnöstä. Artiklassa 17 vahvistetaan perusteet, joilla rekisterinpitäjän on poistettava henkilötiedot aiheetta viivyttämättä, mukaan lukien silloin, kun tiedot eivät ole enää tarpeen niitä varten tarkoitukseen, jota varten ne kerättiin tai joita varten niitä käsiteltiin, kun suostumus peruutetaan eikä muuta oikeusperustaa ole, ja kun käsittely on ollut lainvastaista. Sama artikla asettaa rajoja. Poistamista ei sovelleta, kun käsittely on tarpeen esimerkiksi sananvapauden ja tiedonsaannin, lakisääteisen velvoitteen, yleistä etua koskevien tehtävien tietyissä olosuhteissa, kansanterveyteen liittyvien syiden, arkistoinnin, tutkimuksen tai tilastojen tiettyjen suojatoimien alaisena taikka oikeusvaateiden vuoksi. Tämä ei ole porsaanreikä lupauksessa. Se on oikeuden todellinen muoto.
Järjestelmän omistajan kysymys ei siis ole: ’Voimmeko poistaa tietoja?’ Lähes mikä tahansa järjestelmä voi poistaa jotakin. Kysymys on siitä, voiko organisaatio selittää tietyn pyynnön ja tietyn käsittelytarkoituksen osalta, mitä tietoja se hallussaan pitää, mitä näille tiedoille on tapahtunut, mitä sen on velvollisuus tai oikeus säilyttää, mille vastaanottajille alavirrassa on ilmoitettava ja miten suoritettu toimenpide voidaan tarkistaa. Ero kuulostaa menettelylliseltä. Käytännössä se on arkkitehtoninen. Tuote, joka osaa vain lisätä tietoa, huomaa, että poistaminen on paljon kalliimpi ominaisuus.
Tämä on erityisen terävää tekoälyjärjestelmille, mutta se ei rajoitu tekoälyyn. Haku, analytiikka, asiakastuki, identiteetti, turvallisuuden seuranta ja asiakirjahallinta tuottavat kaikki johdannaisia. Malli antaa ongelmalle vain uusia nimiä: tunnukset, gradientit, upotukset, hakemistot, kehotteet ja tulosteet. Mikään näistä nimistä ei poista taustalla olevaa kysymystä siitä, pysyykö luonnollinen henkilö tunnistettavissa. Eikä tekninen termi hiljaa vastaa oikeudelliseen kysymykseen. Upotus ei ole automaattisesti anonyymi, koska sitä on vaikea lukea. Loki ei ole automaattisesti tarpeellinen, koska se on hyödyllinen. Varmuuskopio ei ole automaattisesti vapautettu, koska se on hankala.
Yksityisyys unohtamisen jälkeen ei siis ole tyhjä sivu. Se on jäännöstila, joka jää jäljelle, kun organisaatio on tehnyt lainmukaisen, oikeasuhteisen ja todennettavissa olevan päätöksen siitä, mitä ei enää pitäisi käsitellä. Tuon jäännöstilan laatu kertoo ihmisille järjestelmästä paljon enemmän kuin poistopainikkeen olemassaolo koskaan kertoo.
Oikeudella on ehtoja, ja se tekee siitä vahvemman
Eurooppalaista tietosuojalainsäädäntöä kuvataan joskus niin kuin se tarjoaisi yksilölle yleisen hätäpysäyttimen. Tämä mielikuva on riittävän siisti diaan, mutta riittävän väärä aiheuttaakseen ongelmia. Artikla 17 liittyy käsittelyn tarkoitukseen, oikeusperusteeseen ja olosuhteisiin. Se sisältää oikeuden, rekisterinpitäjien velvollisuuksia sekä poikkeuksia, jotka suojaavat muita oikeuksia ja yleisiä etuja. Vastuullinen toiminta alkaa pyynnön esittäjän henkilöllisyyden selvittämisestä silloin, kun se on tarpeen, käsiteltävänä olevan tiedon ja käsittelytarkoituksen ymmärtämisestä sekä sen arvioimisesta, soveltuvatko artiklan 17 peruste ja jokin poikkeus. Vastaus voi olla tietojen poistaminen. Se voi olla perusteltu kieltäytyminen kokonaan tai osittain. Se voi olla käsittelyn rajoittaminen riidan ratkaisun ajaksi. Se voi myös olla pyyntö, joka kohdistuu järjestelmään, jota organisaatio ei hallitse.
Tämä ei ole syy muuttaa rekisteröidyn pyyntöä pieneksi esteradaksi. GDPR edellyttää, että rekisterinpitäjät helpottavat oikeuksien käyttämistä. Artikla 12 edellyttää, että pyyntöön liittyvistä toimista annettavat tiedot ja viestintä ovat ytimekkäitä, läpinäkyviä, ymmärrettäviä ja helposti saatavilla. Se edellyttää yleensä, että tiedot toimista annetaan ilman aiheetonta viivytystä ja joka tapauksessa kuukauden kuluessa pyynnön vastaanottamisesta. Määräaikaa voidaan jatkaa enintään kahdella kuukaudella, jos se on tarpeen pyyntöjen monimutkaisuuden ja lukumäärän vuoksi, mutta rekisterinpitäjän on ilmoitettava henkilölle jatkosta ja sen syistä ensimmäisen kuukauden kuluessa. Järjestelmä, joka ei pysty tunnistamaan omia tietovirtojaan ennen kolmatta kuukautta, ei ole löytänyt menettelyllistä puolustusta. Se on löytänyt hallinnollisen ongelman.
Euroopan tietosuojaneuvoston ohjeistus pienille ja keskisuurille yrityksille ilmaisee toiminnallisen näkökohdan selvästi: ihmiset voivat pyytää tietojen poistamista tietyissä olosuhteissa, ja organisaatioilla tulisi olla menettelyt oikeuspyyntöihin vastaamiseksi. Menettely ei ole jaetulle asemalle tallennettu lakimieslausunto. Se on toimiva reitti pyynnöstä päätökseen ja toimeenpanoon. Siihen kuuluvat roolit, joilla on oikeus tehdä päätös, tietokartat, joiden avulla asiaankuuluva käsittely nähdään, toimittajat ja vastaanottajat, joille voi olla tarpeen ilmoittaa, säilytysaikataulut, jotka selittävät poikkeuksen, sekä todisteet, joiden avulla myöhempi arvioija voi ymmärtää, mitä on tehty.
Unionin tuomioistuin on auttanut tekemään näkyväksi toisen erottelun. Sen tuomiot poistamisesta hakutuloksista koskevat linkkien esittämistä hakukoneissa, eivätkä ne ole kehotus poistaa taustalla olevaa julkaisua lähdeverkkosivustolta. Google Spain -asiassa tuomioistuin katsoi, että hakukoneen ylläpitäjä voi olla vastuussa kolmansien osapuolten julkaisemilla verkkosivuilla olevien henkilötietojen käsittelystä ja että rekisteröity voi tietyissä olosuhteissa pyytää linkkien poistamista hakutuloslistasta, joka näytetään henkilön nimeä koskevan haun jälkeen. Myöhemmissä asioissa tuomioistuin käsitteli muun muassa arkaluonteisia tietoja, poistamisen alueellista soveltamisalaa ja virheellisiä tietoja. Nämä asiat eivät tee jokaisesta ei-toivotusta tosiasiasta poistamisvaatimusta. Ne osoittavat, miksi järjestelmän on nimettävä kyseessä oleva taso: lähdejulkaisu, hakemisto, tuloslista, välimuisti, poiminta tai muu kopio.
Tämä tasodiscipliini on tärkeää myös organisaatioiden sisällä. Työntekijä voi pyytää rekisterinpitäjää poistamaan yhteystietotietueen, jota ei enää tarvita rekrytointitarkoitukseen. Rekisterinpitäjän on ehkä arvioitava erillistä säilytysvelvollisuutta palkanmaksua tai yhdenvertaisuustodisteita koskevien tietojen osalta. Julkinen elin voi käsitellä tietuetta lakisääteisen tehtävän perusteella, jolloin sen on arvioitava sovellettavaa lakia sen sijaan, että se toistaisi yksityisen sektorin vastauksen. Julkaisija voi joutua punnitsemaan sananvapautta ja tiedonsaantioikeutta. Lopputulosta ei voi ratkaista pelkästään tietokantasanojen avulla.
On houkuttelevaa paheksua ehtoja, koska ne estävät yksinkertaisen lupauksen. Mutta ne tekevät lupauksesta merkityksellisen. Oikeus, joka sivuuttaa lakisääteiset velvoitteet, muut perusoikeudet ja järjestelmien välisen käytännön eron, typistyisi rituaaliksi. Eurooppalainen lähestymistapa edellyttää vastuullista päätöstä, ei teatraalista sellaista. Se vaatii enemmän työtä. Se myös tekee kieltäytymisestä haastettavissa olevan ja poistosta uskottavan.
Tietue voi kadota näytöltä ja silti pysyä järjestelmässä
Helpoin poiston epäonnistuminen on tuttu jokaiselle, joka on rakentanut sovelluksen: poista kohde tuotteen käyttöliittymästä, jätä taustalla oleva data tietovarastoon ja oleta, että työ on tehty, koska tavalliset käyttäjät eivät enää näe sitä. Joskus pehmeä poisto on juuri oikea toiminnallinen ratkaisu. Se voi säilyttää lyhyen kumoamisjakson, tehdä replikoinnista turvallista tai välttää sellaisen suhteen katkeamisen, joka on ratkaistava. Mutta pehmeä poisto ei ole poistamista pelkästään siksi, että käyttöliittymä on hiljentynyt. Sen käytön on liityttävä määriteltyyn tarkoitukseen, säilytysaikaan, käyttöoikeuksiin ja myöhempään toimenpiteeseen, joka todella muuttaa datan tilaa.
Kovalla poistollakin on rajansa. Rivin poistaminen voi jättää hakemiston hakemistoon seuraavaan indeksointijaksoon asti. Oliovarastossa voi olla versiointi. Sisällönjakeluverkko voi pitää vastausta välimuistissa, kunnes se vanhenee tai mitätöidään. Viestijono voi sisältää tapahtuman, jota ei ole vielä käsitelty. Tietovarasto on voinut nielaista tilannekuvan. Palvelu on voinut siirtää datan käsittelijälle, alakäsittelijälle tai vastaanottajalle. Käytännön opetus ei ole se, että poistaminen on mahdotonta. Se on se, että organisaatio tarvitsee inventaarion, joka erottaa nämä pinnat riittävällä tarkkuudella, ja käytännön, joka kertoo, mitä kullakin pinnalla tapahtuu.
Sisällön ja todisteen välillä on myös ero. Asiakaspalvelutiketti voi sisältää henkilön viestin. Järjestelmä voi tarvita tietueen siitä, että tiketti on ollut olemassa, se on käsitelty ja se on poistettu hyväksytyn säännön mukaisesti. Koko viestin säilyttäminen ikuisesti todistaakseen, että se on poistettu, on pieni byrokraattinen mestariteos, mutta ei tietosuojakeino. Parempi suunnittelu säilyttää vain sen vähimmäistodisteen, jota vastuullisuus edellyttää, erillään sisällöstä, jolla ei enää ole tarkoitusta. Tämä todiste voi olla pyynnön tunniste, päätöksen tyyppi, valmistumisaika, sovellettava säilytysluokka ja tavoitetut järjestelmät. Suunnittelu riippuu organisaatiosta. Periaate ei riipu: todiste ei saa luoda uudelleen tarpeetonta henkilötietoa.
Varmuuskopiot ansaitsevat saman selkeän kielen. Varmuuskopio voi olla tarpeen saatavuuden, tietoturvan tai katastrofipalautuksen kannalta. Se on silti käsittelyä. Käytännön kysymys on, onko varmuuskopio erikseen käytettävissä, kuinka kauan se on palautettavissa, kuka sen voi palauttaa, sisältyykö se normaaliin poistoprosessiin ja miten palautettu ympäristö estetään hiljaa tuomasta takaisin dataa, joka on sittemmin poistettu tuotantojärjestelmästä. Kohtuullinen käytäntö voi luottaa varmuuskopion määriteltyyn kiertojaksoon sen sijaan, että jokaista historiallista varmuuskopiolohkoa muokattaisiin erikseen. Mutta käytännön on sanottava tämä ääneen, suojattava pääsy sillä välin ja varmistettava, että palautus noudattaa nykyistä datan tilaa aina kun mahdollista. "Se on varmuuskopiossa" kuvaa ongelman. Se ei ole vastaus siihen.
Lokit ovat samankaltaisia. Turvallisuus- ja käyttölokit voivat olla välttämättömiä. Ne voivat olla ainoa lähde, josta selviää pääsy, epäonnistunut todennusyritys tai tuotantomuutos. Ne voivat myös säilyttää tunnisteita, osoitteita, pyynnön sisältöä tai sisällön osia, joita ei koskaan tarvittu diagnosointiin. Hyvä lokisuunnittelu minimoi keräyksen yhteydessä, poistaa tai pseudonymisoi tietoja tarvittaessa, erottaa arkaluonteiset sisällöt tapahtuman metatiedoista, rajoittaa pääsyä ja soveltaa säilytysaikatauluja. Kaikkien arkaluonteisten kenttien selvittäminen poistopyynnön yhteydessä on mahdollista, mutta se on huono korvike sille, että suunnitteluvaiheessa päätetään, mitä lokin ei olisi koskaan pitänyt sisältää.
Teknisen omistajan ei tarvitse luvata välitöntä ja yhtenäistä pyyhkimistä kaikista laitteista toimiakseen vastuullisesti. Hänen on kuitenkin kyettävä kertomaan elinkaari: mikä muuttuu välittömästi saavuttamattomaksi, mikä poistetaan seuraavassa käsittelyajossa, mikä säilyy dokumentoidun säilytysaikataulun mukaisesti, mikä pysyy suojattuna voimassaolon päättymiseen asti ja mitä tapahtuu, jos palautustoimenpide suoritetaan. Tämä kuvaus antaa henkilölle, viranomaiselle ja käyttäjälle jotain konkreettista tarkasteltavaa. Vihreä ilmoitusponnahdusikkuna antaa heille hyvin vähän.
Johdetut tiedot eivät ole porsaanreikä
Nykyaikaiset järjestelmät muuntavat usein henkilötietoja ennen kuin käyttävät niitä. Ne poimivat päivämäärän asiakirjasta, luokittelevat viestin, laskevat pistemäärän, päättelevät kielen, luovat hakemiston, tuottavat yhteenvedon, yhdistävät kaksi tiliä tai muuttavat tekstiä ja kuvia vektoreiksi samankaltaisuushakua varten. Nämä muunnokset voivat olla hyödyllisiä. Ne voivat myös saada organisaation tuntemaan, että se on siirtynyt henkilötietojen ulkopuolelle. Näin ei välttämättä ole.
GDPR on teknologianeutraali. Sen johdanto-osat selittävät, että pseudonymisoituja tietoja, jotka voitaisiin yhdistää luonnolliseen henkilöön lisätietojen avulla, on pidettävä tunnistettavissa olevaa luonnollista henkilöä koskevina tietoina. Ne selittävät myös, että tunnistettavuudessa on otettava huomioon kaikki keinot, joita rekisterinpitäjä tai joku muu todennäköisesti käyttää, ottaen huomioon muun muassa kustannukset, aika, käytettävissä oleva teknologia ja teknologinen kehitys. Kysymys ei ole siitä, näyttääkö esitys nimen kaltaiselta taulukkolaskennassa. Kysymys on siitä, liittyykö se tunnistettuun tai tunnistettavissa olevaan henkilöön todellisessa asiayhteydessä.
Upotus tekee tästä kohdasta hyödyllisen hankalan. Hakujärjestelmässä asiakirja voidaan jakaa osiin ja esittää numeerisina vektoreina, jotta kysely voi löytää semanttisesti samankaltaista sisältöä. Vektori ei ole luettava kappale. Se voidaan kuitenkin yhdistää lähdeasiakirjaan, vuokraajaan, käyttäjään, käyttöoikeuksiin, metatietokenttään tai hakukenttään. Se voi mahdollistaa henkilökohtaisen sisällön valitsemisen kyselyn vastauksena. Organisaatio ei voi kutsua sitä anonyymiksi vain siksi, että ihminen ei voi rekonstruoida lausetta katsomalla koordinaattilistaa. Sen on arvioitava esitys, siihen liittyvät tiedot, yhdistämiskeinot ja käsittelyn tarkoitus.
Sama koskee johdettua pistemäärää. Riskipistemäärä, mieltymysluokka tai kelpoisuusindikaattori voi sisältää vähemmän yksityiskohtia kuin lähdetiedot ja silti aiheuttaa vakavia vaikutuksia henkilölle. Se voi olla henkilötietoa, jos se liittyy tunnistettuun tai tunnistettavissa olevaan henkilöön. Lähdetietojen poistaminen ja pistemäärän säilyttäminen, joka edelleen vaikuttaa päätöksiin, ei ole puhdas ratkaisu. Se voi yksinkertaisesti siirtää henkilön läpinäkymättömämpään muotoon. Järjestelmä tarvitsee säännön johdetuille tiedoille: mitkä poistetaan lähdetietojen kanssa, mitkä lasketaan uudelleen, mitä ei voi enää käyttää, mitkä on säilytettävä erillisen velvoitteen mukaisesti ja kuka päättää.
Ei ole olemassa yleispätevää teknistä testiä, joka ratkaisisi jokaisen johdannaisen kohdalla. Jotkin aggregoidut tilastot voivat olla anonymisoituja. Jotkin voivat silti olla alttiita yksilöimiselle tai yhdistämiselle. Jotkin malliparametrit eivät välttämättä ole kohtuudella yhdistettävissä yksilöön tietyssä asiayhteydessä. Toiset voivat liittyä koulutusaineistoon, suppeasti rajattuun malliin tai hyökkäyspintaan, joka muuttaa arviointia. GDPR:n käsite anonymisoidusta tiedosta ei ole koristeellinen nimike datalle, jonka tulkitseminen on tehty hankalaksi. Rekisterinpitäjän on tehtävä arvio, joka perustuu tunnistamisen keinoihin ja asiayhteyteen.
Tämä epävarmuus ei ole syy kuvata jokaista johdannaista pysyvästi ongelmallisena. Se on syy ylläpitää alkuperäketjua. Tiimin tulisi tietää, mitä syöteaineistoja on käytetty ominaisuusvarastoon, indeksiin, koulutusajoon tai raportointitaulukkoon; mitä johdannaisversioita on tuotettu; mitkä järjestelmät kuluttavat niitä; ja minkä vastatoimen lähdemuutoksen on laukaistava. Alkuperäketju muuttaa epämiellyttävän kysymyksen rajatuksi teknisiksi tehtäväksi. Ilman sitä jokaisesta tietopyynnöstä tulee arkeologinen kaivaus työnimien, tallennustilojen ja jonkun muistikuvan kautta kahden talven takaisesta migraatiosta.
Koneoppiminen tuo vaikean kysymyksen, ei taianomaista poikkeusta
Koneoppiminen tekee poistamisesta vaikeaa, koska kouluttaminen ei ole arkistointitoimenpide. Koulutusesimerkki voi vaikuttaa parametreihin pitkän päivityssarjan kautta yhdessä monien muiden esimerkkien kanssa. Käyttöönotettu malli on voitu kopioida useisiin ympäristöihin. Myöhempi malli on voitu hienosäätää aiemmasta mallista. Tiimi voi käyttää arviointidataa, kehotteita, hakukorpuksia ja palautelokeja, joilla kullakin on erilainen elinkaari. Jos henkilön tietoja on päätynyt tällaiseen järjestelmään, organisaatio ei voi vastuullisesti vastata olankohautuksella matematiikkaan vedoten. Se ei myöskään voi rehellisesti luvata, että yksi tietokantapoisto poistaa kaiken mahdollisen vaikutuksen jokaisesta parametrista.
Ensimmäinen askel on erottaa järjestelmät toisistaan. Hakukorpus ei ole koulutettu malli. Jos asiakirjaa käytetään haun lähteenä, poistaminen voi tarkoittaa asiakirjan, sen osien, metadatan ja indeksimerkintöjen poistamista tai käytöstä poistamista ja sen jälkeen sen varmistamista, ettei haku enää tavoita sitä. Kehoteloki ei ole upotusvarasto. Hienosäätöaineisto ei ole tietoturvan auditointijälki. Mallin tarkistuspiste ei ole ajantasainen lähdetietue. Oikea vastaus voi olla erilainen kullakin pinnalla, mutta vastausta ei voi suunnitella ennen kuin pinnat on nimetty.
Koulutusdatan osalta lainmukainen ja tekninen analyysi voi edellyttää päätöstä siitä, onko uudelleenkoulutus, korvaaminen, rajoittaminen, säilyttäminen vai jokin muu toimenpide asianmukainen. Tutkimus koneoppimisen unohtamisesta on merkityksellistä, koska se tutkii menetelmiä tiettyjen tietojen vaikutuksen vähentämiseksi ilman mallin uudelleenkouluttamista alusta alkaen. Se ei ole yleinen todistus siitä, että järjestelmä on unohtanut. Menetelmillä on oletuksia, malliluokkia, tietoehtoja ja varmennusrajoitteita. Organisaation ei tulisi markkinoida kokeellista tekniikkaa artiklan 17 yleisenä toteutuksena. Sen ei myöskään tulisi odottaa täydellistä tekniikkaa ennen kuin se suunnittelee parempia tietosuojakeinoja.
Paremmat keinot alkavat alkupäästä. Minimoi kerätty data. Erota henkilötiedot koulutusmateriaalista, kun tarkoitettu käyttötarkoitus sen sallii. Aseta säilytysaika ennen kuin kertyminen tekee kysymyksestä tunnepitoisesti kalliin. Pidä versioituja tietueita aineistoista ja koulutusajoista. Tee suostumukseen perustuvista tai muista lainmukaisista ehdoista selkeitä silloin, kun ne ovat asianmukainen peruste. Vältä sitä, että tuotannon kehotearkisto muuttuu hiljaa mallin kehitysaineistoksi. Pidä arviointi- ja tukimateriaali erotettavissa koulutusdatasta. Mitä vähemmän järjestelmä luottaa tuntemattomaan alkuperään, sitä tarkemmin se voi vastata poistokysymykseen.
Myös sanalla ’vaikutus’ on rajansa. Henkilö voi olla huolissaan siitä, että teksti on joskus kuulunut koulutusaineistoon. Tekninen tiimi voi pystyä osoittamaan, että lähdetietue on poistettu nykyisestä korpuksesta, mutta ei pystyä laajassa filosofisessa mielessä todistamaan, ettei mihinkään historiallisen mallin parametriin jäänyt minkäänlaista vaikutuksen fragmenttia. Tietosuojalainsäädäntö ei helpotu, kun organisaatio korvaa konkreettisen kuvauksen metafysiikalla. Velvollisuus on arvioida käsittely, perusteet ja toimenpiteet lain mukaisesti. Organisaation tulee selittää päätelmänsä laajuus, kattamansa järjestelmät ja jäljellä oleva rajoitus. Tarkkuus on armollisempaa kuin ylenpalttinen lupaus.
TeKOÄn käyttöönottajille käytännön taakka kuuluu usein yhtä lailla hankintaan kuin tekniikkaan. Toimittajan tulisi pystyä kertomaan, mitä se tekee kehotteille, ladatuille tiedostoille, telemetrialle ja vapaaehtoiselle palautteelle; mitä näistä käytetään koulutukseen tai palvelun parantamiseen; mitä säilytyshallintakeinoja on olemassa; miten asiakas saa tiedot, joita tarvitaan tietopyyntöihin vastaamiseen; ja mitä tapahtuu jaetussa verrattuna erilliseen ympäristöön. Sopimus, joka vain toteaa ’GDPR-yhteensopiva’, ei ole antanut tietoja, joita tarvitaan poistoprosessin toteuttamiseen. Se on antanut adjektiivin.
Hakukoneet opettavat hyödyllisen opetuksen kerroksista
Unionin tuomioistuimen oikeuskäytäntö de-indeksoinnista on hyödyllinen juuri siksi, että se on suppeampi kuin suosittu ilmaus ’oikeus tulla unohdetuksi’. Tapaukset koskevat sitä, onko hakukoneen poistettava linkkejä nimipohjaisista hakutuloksista ja millä edellytyksillä. Ne eivät luo yksinkertaista valtaa muuttaa historiaa sen lähteellä. Tämä erottelu osoittaa, että tietosuojakysymyksissä on usein kyse siitä, miten tieto tehdään saataville, yhdistetään ja vahvistetaan, ei vain siitä, onko tietue joskus ollut olemassa.
Google Spain -tapauksessa tuomioistuin käsitteli linkkejä hakukoneen tuloslistassa kolmannen osapuolen julkaisemiin sivuihin. Päätös teki selväksi, että hakukoneen toiminta voi muodostaa henkilötietojen käsittelyä ja että tietyin edellytyksin operaattori voidaan velvoittaa poistamaan linkkejä hakutuloksista, jotka näytetään henkilön nimellä tehdyn haun jälkeen. Päätös ei ollut määräys alkuperäiset ilmoitukset julkaisseelle sanomalehdelle. Sisäistä tietokantaa hallinnoiva järjestelmän omistaja voi oppia tästä: hakemistot, esikatselut ja hakutulosten järjestys ovat käsittelykerroksia, joilla on omat seurauksensa.
GC and Others -tapauksessa käsiteltiin pyyntöjä poistaa linkkejä verkkosivuille, jotka sisälsivät arkaluonteisia henkilötietoja. Tuomioistuin käsitteli vaadittavaa punnintaa ja velvollisuuksia, joita hakukoneen operaattorille voi syntyä. Google v CNIL -tapauksessa käsiteltiin alueellista soveltamisalaa, ja tuomioistuin katsoi kyseisen tapauksen olosuhteissa, että EU-lainsäädäntö ei edellyttänyt de-indeksointia hakukoneen kaikista versioista maailmanlaajuisesti, mutta edellytti tehokkaita toimenpiteitä estämään tai vakavasti vaikeuttamaan jäsenvaltioista pääsyä linkkeihin, jotka on poistettu EU-versioista. TU and RE -tapauksessa käsiteltiin pyyntöä, joka liittyi väitetysti virheelliseen tietoon, ja siinä selvennettiin näyttötaakkaan ja esikatselukuvien käsittelyyn liittyviä seikkoja. Nämä tuomiot ovat tapauskohtaisia oikeudellisia ratkaisuja, eivät käyttöönottotarkistuslista. Yhdessä ne välittävät järjestelmätason näkökulman: linkillä, tuloslistalla, kuvan esikatselulla ja alkuperäisellä sivulla ei automaattisesti ole samaa oikeussuojakeinoa.
Tämä näkökulma kantaa hyvin. Yritysportaali voi säilyttää lähdetietueen laillisesti rajattuun tarkoitukseen, kun taas pääsy laajan hakupinnan kautta on liiallista. Teknisen tuen järjestelmä voi tarvita suojatun auditointimerkinnän, mutta sen automaattinen täydennysesikatselu ei saisi tuoda entisen asiakkaan tietoja suuren ryhmän nähtäville. Asiakirja voidaan poistaa hakukorpuksesta, kun taas mallin tuottama yhteenveto voi jäädä eri säilöön. Oikea vastaus ei ole julistaa jokaista kerrosta samanlaiseksi. Se on ymmärtää, miten kerros muuttaa altistumista, tarkoitusta ja riskiä.
Siinä varoitetaan myös suositusta oikotiestä: oletuksesta, että näkyvyys on ainoa yksityisyyskysymys. Tietue voi olla teknisesti piilotettu ja silti sitä voidaan käsitellä, kysellä, profiloida, siirtää tai palauttaa. Toisaalta organisaatio voi tarvita huolellisesti rajatun tietueen osoittaakseen toimineensa asianmukaisesti, suojatakseen oikeudellista vaatimusta tai täyttääkseen lakisääteisen velvoitteen. Yksityisyys ei ole kilpailu siitä, kuka tuottaa vähiten dataa kaikissa kuviteltavissa tilanteissa. Se on tarkoituksen, välttämättömyyden, oikeasuhteisuuden ja hallinnan kurinalaisuutta.
Siksi poistoinventaarioon tulisi sisällyttää hakupolut ja esittämispolut. Kysy, mitkä indeksit sisältävät tietueen, mitkä välimuistit palvelevat sitä, mitkä viennit sisältävät sen, mitkä rajapinnat palauttavat sen, mitä johdettuja kenttiä käytetään luokitteluun tai suosituksiin ja mitkä varmuuskopion palautuspolut voivat herättää sen henkiin. Luettelo ei ole tyylikäs. Se on tyylikkyyttä hyödyllisempi.
Demonstraatio on eri asia kuin väite
Kun järjestelmä väittää voivansa poistaa dataa, kysymyksiä on kaksi erillistä. Ensimmäinen on, onko suunnittelussa laillinen, dokumentoitu reitti tähän. Toinen on, voiko organisaatio osoittaa, että reittiä noudatettiin tietyn pyynnön kohdalla säilyttämättä enempää henkilökohtaista materiaalia kuin osoittaminen vaatii. Ensimmäinen on tuotteen ominaisuus. Toinen on vastuuvelvollisuus.
Hyödyllinen poistotietue on tarkoituksella vaatimaton. Sen ei tarvitse toisintaa henkilön koko pyyntöä, asiakirjoja tai tilitietoja uuteen vaatimustenmukaisuustietokantaan. Se voi kirjata pyyntöviitteen, henkilöllisyyden varmistuksen tuloksen tarvittaessa, pyyntöluokan, sovellettavat järjestelmät, päätöksen ja oikeudellisen perustelun asianmukaisella tasolla, toimintapäivät, poikkeukset tai säilytysperusteet, vastaanottajille lähetetyt ilmoitukset tarvittaessa sekä asynkronisen poiston tai varmuuskopion vanhenemisen tilan. Tarkat kentät riippuvat rekisterinpitäjästä ja asiayhteydestä. Olennaista on, että myöhempi tarkastelija voi nähdä polun ilman, että arkaluonteista sisältöä täytyy rekonstruoida palasista.
Varmennuksen tulisi vastata datan pintaa. Sovelluksen reaaliaikainen tietue voidaan tarkistaa varmistamalla, ettei valtuutettu haku enää palauta sitä. Hakujärjestelmää voidaan testata alkuperäisellä tunnisteella ja asiaankuuluvilla hakumalleilla, samalla kun vältetään laajoja yrityksiä luoda henkilökohtaista sisältöä uudelleen. Indeksi voi raportoida poistotilansa. Jono voi näyttää valmistumisen. Varmuuskopioprosessi voi osoittaa, että palautuskuva on suojattu sen säilytyssäännön mukaisesti ja että palautus soveltaa ajantasaista poistokirjanpitoa tai vastaavaa hallintakeinoa. Varmennuksen ei tarvitse todistaa metafyysistä negatiivia. Sen on tarjottava näyttöä, joka on oikeassa suhteessa esitettyyn väitteeseen.
Tässä on pieni ansa. Tiimi voi rakentaa vaikuttavan kojelaudan, jossa kaikki valot ovat vihreinä mutta jolla ei ole vakaata yhteyttä työhön. Merkityksellinen kojelauta nimeää datan pinnan, toimenpiteen, tilan, omistajan, näytön ja seuraavan tarkistuksen. Sen avulla voidaan erottaa toisistaan "pyyntö hyväksytty", "reaaliaikainen tietue poistettu", "vastaanottajan ilmoitus odottaa", "varmuuskopio odottaa vanhenemista" ja "säilytetty lakisääteisen velvoitteen nojalla". Näillä tiloilla on erilaiset merkitykset. Niiden yhdistäminen poistetuksi muuttaa epävarmuuden käyttöliittymäsuunnitteluksi.
Osoitettavissa oleva poisto riippuu myös muutostenhallinnasta. Lähdejärjestelmä voidaan korvata, käsittelijä lisätä, indeksimuotoa muuttaa, uusi analytiikkakohde ottaa käyttöön tai tekoälytoimittajan säilytyskäytäntöä tarkistaa. Jos poistomenettelyä ei päivitetä näiden muutosten mukaisesti, menettely kuvaa vähitellen järjestelmää, jota ei enää ole olemassa. Tulos on tuttu mistä tahansa operatiivisesta kurinalaisuudesta: kaunis toimintaohje ja todellinen palvelu liikkuvat vastakkaisiin suuntiin. Pienen otoksen testaaminen polusta säännöllisesti, myös hankalan järjestelmän osalta, on yleensä paljastavampaa kuin suuren varmistusasiakirjan tilaaminen, jota kukaan ei voi toteuttaa.
Julkishallinnon viranomaiselle tai säännellylle yritykselle tämä ei ole kapea tietosuojatoimiston huolenaihe. Tietosuojavastaava voi ohjata tulkintaa, mutta tekniikka omistaa rajapinnat ja poistomekaniikan, tuote omistaa tarkoituksen ja käyttäjäpolun, hankinta omistaa toimittajille asetetut tiedonantovelvoitteet, tietoturva omistaa pääsynhallinnan ja palautuksen hallinnan, ja operatiivinen toiminta omistaa toteutuksen paineen alla. Yksikään omistaja ei yksin voi tarkastaa jokaista kerrosta. Omistamaton kerros ei muutu turvalliseksi sillä, että siitä on vaikea keskustella.
Säilytys on poiston toinen puoli
Monet poisto-ongelmat alkavat kauan ennen pyyntöä. Ne alkavat, kun järjestelmällä ei ole lainkaan säilytyspäätöstä. Tietoja kerätään, koska niistä saattaa olla hyötyä. Lokit muuttuvat pysyviksi, koska tallennustila on halpaa. Vientitiedostot säilytetään, koska tuleva auditointi saattaa kysyä niitä. Harjoitusaineistoa kerätään, koska myöhempi malli saattaisi hyötyä siitä. Jokainen päätös vaikuttaa erikseen harmittomalta. Yhdessä ne muuttavat organisaation suuren ja huonosti ymmärretyn arkiston omistajaksi ja tekevät jokaisesta poistopyynnöstä kalliimman, epävarmemman ja kiistanalaisemman.
GDPR:n säilytysrajoitusperiaate edellyttää, että henkilötietoja säilytetään muodossa, josta rekisteröity on tunnistettavissa, ainoastaan niin kauan kuin on tarpeen niitä tarkoituksia varten, joita varten ne käsitellään, ja että pidempi säilytys on mahdollista yleistä etua koskevaa arkistointia, tieteellistä tai historiallista tutkimusta taikka tilastollisia tarkoituksia varten, jos asianmukaiset suojatoimet ovat käytössä. Periaate ei määrää yhtä aikataulua jokaiselle organisaatiolle. Se edellyttää tarkoitukseen sidottua harkintaa. Säilytysaikataulun tulisi siksi nimetä tietoluokat, tarkoitus, oikeusperusta, normaali ajanjakso, laukaiseva tapahtuma, poikkeus, hävittämistoimenpide, omistaja ja tarkistusajankohta. ”Niin kauan kuin tarpeen” on periaate. Siitä tulee operatiivinen sääntö vasta, kun joku voi sanoa, mihin tarkoitukseen, mihin asti ja kenen päätöksellä.
Tämä rakenne on hyödyllinen tekoälylle, koska se estää yhden laajan nimikkeen, kuten harjoitusaineisto, peittämästä useita eri asioita. Raaka tuotos, puhdistettu aineisto, piirrejoukko, malliversio, kehotehistoria, arviointijoukko ja seurantaloki voivat kaikki olla eri tarkoituksissa ja eri säilytysnäkökohdilla. Niiden yhdistäminen yhteen rajoittamattomaan säilytysluokkaan heikentää sekä innovaatiota että vastuullisuutta. Niiden erottaminen ei takaa lainopillista vastausta, mutta se tekee sellaisen mahdolliseksi.
Säilytyspäätökset hyötyvät myös kieltäytymisehdosta. Mikä saisi meidät lopettamaan tämän säilyttämisen? Päättynyt sopimus, ratkaistu riita, lakisääteisen ajanjakson päättyminen, valmistunut tietoturvatutkinta, korvattu malliversio, palautusikkunan umpeutuminen tai päätös olla jatkamatta tutkimustarkoitusta voivat kaikki olla todellisia laukaisevia tekijöitä. Tarkoitus ei ole automatisoida poistokelloa kaikelle. Tarkoitus on välttää järjestelmä, jossa ainoa ehto tietojen säilyttämiselle on, ettei kukaan ole vielä vaatinut niiden selittämistä.
Tässä on pieni hollantilainen vaisto, joka kannattaa säilyttää: kaappi ei ole järjestyksessä siksi, että siinä on ovi. Se on järjestyksessä, koska löydät tarvitsemasi, tiedät miksi se on siellä ja voit poistaa sen muuttamatta pois. Tietovaranto ansaitsee vähintään tämän tason. Säilytysaikataulu, joka ei kestä keskustelua järjestelmää käyttävien ihmisten kanssa, ei ole aikataulu. Se on sääennuste, joka on kirjoitettu juridisella kielellä.
Tämä ei tarkoita, että jokaisen organisaation on keskitettävä kaikki poistopäätökset. Paikalliset tiimit ymmärtävät usein prosessinsa paremmin. Se tarkoittaa, että paikalliset säännöt tarvitsevat yhteisiä käsitteitä, näkyvän omistajuuden ja reitin eskalaatiolle. Muuten yhden tiimin arkisto on toisen tiimin tietosuojaloukkaus, ja henkilön pyyntö ohjataan kohteliaasti nimettyjen palveluiden sokkelon läpi.
Mitä rehellinen tekoälytoimittaja voi sanoa
Rehellinen tekoälytoimittaja ei väitä, että kaikki asiakastiedot haihtuvat, kun pyyntö saapuu. Se ei myöskään piiloudu mallien vaikeuden taakse. Se kuvailee palvelun rajat. Mitä käsitellään päättelyä varten. Mitä säilytetään tilinhallintaa, tietoturvaa, tukea, laskutusta tai väärinkäytösten estämistä varten. Tallennetaanko kehotteet ja tulosteet. Käytetäänkö niitä koulutukseen, arviointiin tai palvelun parantamiseen. Mitkä käsittelijät ja alueet ovat mukana. Miten asiakkaat voivat määrittää säilytyksen. Mitä dokumentaatiota rekisteröidyn pyynnöistä on olemassa. Mitkä toimet ovat välittömiä, mitkä asynkronisia ja mitkä riippuvat erillisestä oikeudellisesta arvioinnista.
Ostajalle hankintakysymykset ovat käytännöllisiä. Saammeko selkeän tietovirran kuvauksen? Voimmeko tunnistaa rekisterinpitäjän ja käsittelijän roolit kyseisessä käsittelyssä? Voimmeko viedä tai poistaa aineiston käyttökelpoisessa muodossa? Sisältyvätkö hakemistot ja johdetut tallenteet dokumentoituun elinkaareen? Mitä varmuuskopioille tapahtuu? Miten alakäsittelijöiden muutoksista ilmoitetaan? Voiko toimittaja auttaa meitä vastaamaan pyyntöön sovellettavan aikataulun puitteissa? Ovatko koulutus- ja palvelunparannuskäytöt opt-in, opt-out, sopimuksella rajattuja vai kuvattu vain sivulla, joka voi muuttua oston jälkeen? Mitkä tekniset tallenteet ovat saatavilla toiminnan todistamiseksi?
Vastaukset vaihtelevat. Suuri jaettu palvelu ei voi aina tarjota samaa hallintaa kuin erillinen ympäristö. Tietoturvalokia ei voi aina poistaa samalla hetkellä kuin tiliprofiili. Lakisääteistä arkistoa ei voi käsitellä kuin kuluttajan asetusta. Nämä erot eivät välttämättä ole puutteita. Vaitiolo niistä on. Oikea ostajan vastaus on sovittaa palvelun dokumentoitu käyttäytyminen organisaation tarkoitukseen, velvoitteisiin ja riskiin. Tuote voi olla sopimaton erittäin arkaluonteiseen tehtävään, vaikka se olisi täysin sopiva matalan riskin luonnostelutyökaluksi.
Dweven Trust Centre ottaa saman suppean näkemyksen todisteista. Julkinen sivu voi kuvata hallintakeinoja ja dokumentaation rajoja, mutta se ei voi sertifioida jokaista asiakkaan käyttöönottoa eikä päättää lainmukaista perustetta asiakkaan käsittelylle. Tämä raja on tärkeä. Alusta voi tukea säilytyksen hallintaa, tallenteita ja tarkistettavia työnkulkuja. Sitä käyttävä organisaatio omistaa silti tarkoituksensa, datavalintansa ja päätöksen vastata tietylle henkilölle. Hyvän tuotetekstin tulisi tehdä tästä vastuusta selvempää, ei hiljaa periä sitä.
Arvokkain toimittajan lausunto on usein rajaus. ”Tämä tallenne säilyy suojatuissa varmuuskopioissa, kunnes ilmoitettu kiertoaika päättyy.” ”Tämä palvelu ei käytä määritettyä asiakassisältöä koulutukseen näiden ehtojen mukaisesti.” ”Tämä hakemisto poistetaan asynkronisesti, ja tila voidaan tarkistaa täältä.” ”Emme voi antaa tätä vakuutusta kolmannen osapuolen integraatiosta.” Nämä lauseet voivat vaikuttaa vähemmän maagisilta kuin yleinen yksityisyyslupaus. Ne antavat ostajalle mahdollisuuden suunnitella todellisen prosessin.
Kysymyksiä, joita kannattaa kysyä ennen kuin pyyntö saapuu
Organisaation ei tarvitse keksiä tietomurtoa, ahdistunutta henkilöä tai sankarillista yövuorotapausta testatakseen poistojen suunnitteluaan. Se voi käyttää selkeästi merkittyä hypoteettista pyyntöä tavallisen työajan puitteissa. Oletetaan, että henkilö pyytää asiakasrajapinnassa olevan aineiston poistamista. Mikä tiimi vastaanottaa pyynnön? Miten henkilöllisyys varmistetaan keräämättä tarpeettomasti uutta tietoa? Mitkä käyttötarkoitukset ovat olennaisia? Mitkä järjestelmät sisältävät lähdedataa, johdannaisia, indeksejä, lokitietoja, välimuisteja, vientitiedostoja ja palautuskopioita? Mitkä käsittelijät tarvitsevat ohjeistuksen tai ilmoituksen? Mikä poikkeus tai säilytysvelvollisuus soveltuu, jos mikään? Kuka voi päättää? Kuka voi toteuttaa? Miten organisaatio selittää lopputuloksen?
Sitten on kysyttävä hankalat tekniset kysymykset. Pystyykö operaattori löytämään ajantasaisen tietovaraston ilman entistä insinööriä? Voiko hakemistoa tarkistaa riippumattomasti sen lähdetaulukosta? Ilmestyykö poistettu tunniste uudelleen palautuksen jälkeen? Käyttävätkö eräajot vanhoja tilannekuvia? Voidaanko upotusvarasto yhdistää sen dokumentteihin ja vuokralaiseen? Tallentaako valvontaputki kehotteiden sisällöt oletuksena? Koskevatko vientitiedostoja samat säilytyssäännöt kuin niiden lähdettä? Luoko todisteaineisto uuden pinon arkaluonteista sisältöä? Nämä eivät ole reunatapauksia, jotka on lisätty saamaan käytäntö näyttämään vakavalta. Ne ovat tavallisia seurauksia järjestelmistä, jotka tekevät kopioita toimiakseen.
Lopuksi on kysyttävä hallintokysymys: mikä saisi organisaation muuttamaan vastaustaan? Uusi lakisääteinen velvoite, kiistetty henkilöllisyys, vireillä oleva oikeusvaatimus, muuttunut toimittajajärjestely, epäonnistunut poiston varmennus, palautettu varmuuskopio, uusi malliputki tai sääntelyviranomaisen päätös voivat kukin olla merkityksellisiä. Prosessi, jossa ei ole tarkistuslaukaisinta, on yksinkertaisesti alkuperäinen arvaus, joka on ylennetty käytännöksi.
Mikään tästä ei korvaa oikeudellista neuvontaa yksittäisessä tapauksessa. GDPR:n vaatimukset, kansallinen lainsäädäntö, toimialakohtaiset velvoitteet, sopimukset ja käsittelyn tosiasiat ovat kaikki merkityksellisiä. Mutta organisaatioiden ei tarvitse odottaa oikeusriitaa aloittaakseen edellytysten rakentamisen ymmärrettävälle vastaukselle. Niiden on tunnettava järjestelmänsä riittävän hyvin lopettaakseen yksinkertaisen lupauksen tarjoamisen monimutkaisesta todellisuudesta.
Yksityisyys on jäännöksen laatu
Poistamisen taustalla oleva tavoite ei ole tehdä menneestä epätodellista. Tavoitteena on antaa ihmisille todellista hallintaa silloin, kun tietoja ei enää tarvitse käsitellä, kun suostumus on peruutettu, kun käsittely on lainvastaista tai kun jokin muu 17 artiklan peruste soveltuu. Se edellyttää rekisterinpitäjiltä, että henkilötietoja kohdellaan jotakin tarkoitusta varten säilytettävänä aineistona, ei raaka-aineena, jolle on myönnetty rajaton vuokra-aika. Se edellyttää, että poikkeukset selitetään sen sijaan, että niitä käytetään sumutusvälineenä. Se edellyttää järjestelmiltä riittävää alkuperäketjua, jotta unohtaminen voi olla tarkoituksellista.
Digitaalisten palvelujen hiljainen testi on se, mitä jää jäljelle. Kun tietue on poistettu tuotenäkymästä, mikä on edelleen aktiivista? Kun dokumentti poistuu hakukokoelmasta, mikä johdannaisesitys valitsee sen edelleen? Kun tili on poistettu, mitä lokitietoa säilytetään, mihin tarkoitukseen ja kuinka kauan? Kun varmuuskopio on palautettu, mikä estää käytöstä poistetun tietueen palaamisen? Kun malli on muuttunut, mitä tietohistoriaa voidaan tarkastella? Kun pyyntö on suljettu, voiko organisaatio osoittaa työnsä rakentamatta toista piiloprofiilia?
Järjestelmä vastaa harvoin kaikkiin näihin kysymyksiin yhdellä toimella ja yhdellä aikaleimalla. Se on normaalia. Epänormaalia on teeskennellä, että kysymykset katoavat, koska tiedot ovat hankalia, hajautettuja tai tuottavia. Yksityisyys ei ole hetki, jolloin palvelu oppii poistokomennon. Se on se, mitä jää jäljelle, kun järjestelmä on oppinut unohtamaan tarkoituksen, rajan ja oman pidättyvyytensä kirjauksen kanssa.
Lähteet
- Asetus (EU) 2016/679, yleinen tietosuoja-asetus, EUR-Lex. Asetuksen 5, 12, 17 ja 19 artiklaa sekä johdanto-osan 5, 26, 30 ja 66 kappaletta käytettiin lähteinä säilytyksen rajoittamisen, rekisteröidyn oikeuksia koskevien pyyntöjen käsittelyn, tietojen poistamisen, vastaanottajille ilmoittamisen, tunnistettavuuden ja julkisten tietojen ilmoittamisen osalta.
- Vastaaminen yksilöiden pyyntöihin, Euroopan tietosuojaneuvosto. PK-yritysopasta käytettiin lähteenä rekisteröidyn oikeuksia koskevien pyyntöjen käytännön käsittelyssä.
- Suuntaviivat 5/2019 unohdetun oikeuden kriteereistä hakukoneissa, Euroopan tietosuojaneuvosto. Suuntaviivoja käytettiin lähteenä erottelussa, joka koskee linkin poistamista hakutuloksista ja lähdesisällön poistamista.
- Google Spain ja Google, asia C-131/12, Euroopan unionin tuomioistuin.
- GC ja muut, asia C-136/17, Euroopan unionin tuomioistuin.
- Google vastaan CNIL, asia C-507/17, Euroopan unionin tuomioistuin.
- TU ja RE vastaan Google, asia C-460/20, Euroopan unionin tuomioistuin.
- Dweven luottamuskeskus, luettu 5. elokuuta 2026. Julkista rajanvetoa alustan todisteiden ja asiakkaan käyttöönottoon liittyvien vastuiden välillä käytettiin lähteenä lyhyessä Dweve-viittauksessa.