AI ja isikuandmed: mida tohib logida, mida mitte

Kust isikuandmed AI-logisse jõuavad

AI-rakenduses võib isikuandmeid olla neljas kohas: kasutaja sisendis, otsingu või teadmistebaasi allikates, mudeli väljundis ning logis. Vestlus, mis algab küsimusega „koosta vastus kliendile“, võib sisaldada nime, tellimuse numbrit, tervisemuret või töötaja hinnangut. Kui süsteem salvestab kogu vestluse veaotsingu tarbeks, jäävad need andmed logisse ka pärast seda, kui töö on tehtud.

GDPR ehk isikuandmete kaitse üldmäärus käsitleb isikuandmetena igasugust teavet tuvastatud või tuvastatava inimese kohta. Nimi ei ole ainus tunnus: konto ID, e-post, IP-aadress, tellimuse number või kordumatu tekst võib eraldi või koos teiste andmetega inimese tuvastada. Pseudonüümne ID vähendab otsest nähtavust, kuid andmed jäävad isikuandmeteks, kui ettevõttel on võti või muud võimalused need inimese kontoga siduda.

Andmekaitse Inspektsioon rõhutab oma tehisaru juhendis, et AI määrus ei asenda GDPR-i. Kui AI-süsteem töötleb isikuandmeid, kehtivad mõlemad õigusaktid kõrvuti. Seega ei anna kõrge riskiga süsteemi dokumentatsioon või tarnija kinnitus automaatselt õigust koguda sisendit ega hoida seda tähtajatult.

Enne logimise kavandamist kirjelda, millist probleemi logi lahendab: turvaintsidendi uurimine, kvaliteedi hindamine, kasutaja päringule vastamine või arve arvutamine. Kui eesmärk on „igaks juhuks“, pole andmete kogumine piisavalt piiritletud. AI konsultatsiooni lehel on kirjeldatud, kuidas töövoog, riskid ja mõõdik kokku leppida; seo andmekaitseotsused sama töövoo kaardistusega.

Enne logimist määra alus ja eesmärk

GDPR-i artikkel 6 nõuab töötlemiseks õiguslikku alust. Tööriista olemasolu või teenuse kasutustingimus ei ole ise õiguslik alus. Sõltuvalt eesmärgist võib alus olla lepingu täitmine, seadusest tulenev kohustus, õigustatud huvi või mõni muu artiklis 6 nimetatud alus. Sama süsteemi eri toimingutel võib olla eri eesmärk: päringule vastamine, pettuse uurimine ja mudeli treenimine ei ole üks ja sama töötlemine.

Kui ettevõte tugineb õigustatud huvile, tuleb huvi enne töötlemist sõnastada ning kaaluda seda inimese õiguste ja huvide suhtes. AKI õigustatud huvi juhend selgitab, et analüüs vajab põhjendamist ja vastutust. Kirjuta üles, miks logi vajalik on, kas sama eesmärk saavutatakse vähemate andmetega, kes võib logi lugeda ja kuidas inimene saab töötlemisele vastu vaielda.

Töösuhe lisab võimutasakaalu küsimuse. Tööandja võib soovida hinnata, kas töötaja kasutab AI-tööriista õigesti, kuid töötaja ei saa alati jälgimisest vabalt keelduda. AKI töösuhete juhend hoiatab, et töötaja nõusolek ei pruugi sellises olukorras olla vabatahtlik. Juhendis öeldakse, et õigustatud huvi alusel töötlemisel peab olema enne andmetöötlust korrektselt läbi viidud ja kirjalikult dokumenteeritud analüüs.

Praktiliselt tähendab see, et töötajale tuleb selgitada, milliseid logisid tööandja süsteem kogub, mis eesmärgil, kes neid näeb, kui kaua neid hoitakse ja kuidas töötaja saab enda andmetega tutvuda. Ära nimeta tööriista „turvaseireks“, kui tegelik eesmärk on mõõta töötajate tootlikkust. Eesmärk peab vastama päris kasutusele.

Mida logi sisaldab ja mida välja jätta

Hea logi aitab juhtumit taastada, kuid ei kopeeri iga inimese vestlust. Salvesta kõigepealt sündmus ja tehniline kontekst: mis toimus, mis süsteemi versioon töötas, kas vastus anti või suunati inimesele, kas tekkis viga ja kui kaua päring kestis. Päringu täistekst või vastuse koopia võib olla vajalik mõne kindla vea uurimiseks, kuid see vajab eraldi eesmärki, piiratud ligipääsu ja lühikest säilitustähtaega.

Tabel ei ole universaalne luba ega keeld. Näiteks teenuse väärkasutuse uurimisel võib IP-aadress olla lühiajaliselt vajalik, samas kui sisemise otsingu kvaliteedikontroll ei pruugi seda vajada. Pane iga välja juurde eesmärk, õiguslik alus, ligipääs, säilitusaeg ja kustutamise meetod. Kui neile küsimustele vastust pole, ära lisa välja logiskeemi.

Kui tahad hinnata väljundi kvaliteeti, saad tihti salvestada inimese valiku „vastuvõetud / parandatud / tagasi lükatud“ ning veakategooria. Nii saad arvutada parandamise osakaalu ilma kogu isikliku vestluse koopiata. Kui teksti näide on hädavajalik, eralda hindamisandmestik operatiivsest logiteenusest, eemalda tuvastajad ja määra sellele piiratud kasutusõigus.

Töötajate vestlused ja töökoha jälgimine

Tööandja võib hallata oma töövahendite kasutamist, kuid see ei tähenda piiramatut õigust koguda kõike, mida töötaja AI-tööriista sisestab. Erista tööandja hallatav süsteem töötaja isiklikust kontost; ära kogu isikliku teenuse vestlusi lihtsalt seetõttu, et töötaja kasutas tööarvutit. Määra jälgimise eesmärk, andmed, säilitusaeg ja ligipääsuõigused ning teavita töötajat enne kogumise algust.

Kui töötaja kasutab ettevõtte assistenti kliendipäringu mustandi koostamiseks, võib süsteem vajada tööülesande ja väljundi staatust, mitte töötaja kogu vestlusajalugu. Kui eesmärk on turvaintsidendi uurimine, piira juurdepääs kindla juhtumiga ning salvesta, kes logi avas. Ära kasuta samu logisid hiljem salaja töötajate tulemuslikkuse hindamiseks, kui algne eesmärk ega teavitus seda ei katnud.

AI määruse artikli 26 lõige 7 nõuab kõrge riskiga süsteemi töökohal kasutamise eel, et tööandjast kasutuselevõtja teavitaks töötajate esindajaid ja mõjutatud töötajaid. See kohustus seostub kõrge riskiga süsteemiga, mitte iga tavalise töövahendiga. Samas jäävad GDPR-i läbipaistvuse, eesmärgipärasuse ja andmete minimaalsuse nõuded kehtima ka muu töökoha AI puhul.

Veel üks konkreetne piir: AI määruse artikli 5 lõike 1 punkt f keelab emotsioonide tuletamise AI abil töökohal ja haridusasutustes, välja arvatud meditsiinilisel või ohutuse eesmärgil. Näiteks töötajate videokoosolekute näoilmete järgi „kaasatuse skoori“ arvutamine ei ole tavaline analüütika, mille võiks lihtsalt logimispoliitikasse lisada. Enne sellise funktsiooni ostmist kontrolli keeldu ja eesmärgi erandit spetsialistiga.

Säilitusaeg: GDPR ja kõrge riskiga logid

Tehisintellekti määruse III lisa süsteemidele kehtivad III peatüki kõrge riskiga nõuded alates 2. detsembrist 2027; I lisa A jao toodetega seotud süsteemidele alates 2. augustist 2028. I lisa B jao toodetega seotud artikli 6 lõike 1 süsteemidele kohaldub artikli 2 lõike 2 erikord: üksnes artikli 6 lõige 1, artikkel 60a ja artiklid 102–112, artiklid 57–59 ainult seal nimetatud juhtudel. Seetõttu ei rakendu III peatüki logi- ega põhiõiguste mõjuhinnangu kohustused sellisele süsteemile automaatselt AI määruse alusel; kontrolli seotud tooteõiguse nõudeid. Vaata kehtiva koondteksti artikleid 2 ja 113.

Kui kõrge riskiga süsteemi nõuded konkreetsel juhul kohalduvad, näevad AI määruse artikkel 12 ette automaatse logimise võimekuse, et jälgida riske ja toimimist. Artikli 19 järgi peab pakkuja tema kontrolli all olevaid automaatselt loodud logisid säilitama eesmärgile sobiva aja, vähemalt kuus kuud, kui kohaldatav liidu või riigisisene õigus ei sätesta teisiti; finantsasutustele kehtivad lisatingimused. Artikli 26 lõige 6 näeb kasutuselevõtjale ette sama minimaalse tähtaja tema kontrolli all olevate logide kohta.

Kuue kuu nõue ei tähenda, et logisse peab panema vestluste sisu. Erista tehnilised sündmused isikuandmetest. Säilita nõutud perioodil vajalik jälg, kuid kasuta võimalusel pseudonüümseid tunnuseid, kustuta sisu varem ning piira tuvastamise võimalust. Kui GDPR-i kohaldatav nõue ja AI määruse logikohustus näivad vastuolus, ära lahenda seda omal käel „säilitame igaks juhuks kauem“ põhimõttega. Kaasa andmekaitsespetsialist või õigusnõustaja ja pane lahendus kirja.

Määra ka kustutamise tegelik ulatus. Kui operatiivsest andmebaasist kustutatud vestlus jääb analüütikasse, eksportfaili või varukoopiasse, ei ole kustutustöövoog lõpuni kirjeldatud. Dokumenteeri, millal varukoopiad üle kirjutatakse ja kas taastamisel rakendatakse kustutuste nimekirja uuesti.

Juurdepääs, parandamine ja kustutamine

GDPR-i artiklid 15–17 annavad inimesele õiguse saada teavet tema isikuandmete töötlemise kohta, andmetega tutvuda, nõuda ebaõigete andmete parandamist ning teatud juhtudel andmete kustutamist. AI-süsteemi omanik peaks suutma päringu siduda kasutaja konto või juhtumi viitega, otsida selle inimese andmed peamistest salvestuskohtadest ning vastata kehtiva menetlustähtaja jooksul.

Ehita päringu käsitlemine andmevoo põhjal, mitte ühe logitabeli järgi. Kaardista rakenduse andmebaas, vektorindeks, veaseire, analüütika, kasutajatoe tööriist ja teenusepakkuja. Kui prompt või dokument on otsinguindeksis, tuleb hinnata, kas inimene on sealt tuvastatav ja kas selle kustutamine on vajalik. Ära eelda, et vektoriks teisendamine muudab teksti anonüümseks. Kui vektor on konkreetse inimese päringuga seostatav, käsitle seda sama andmevoo osana ja järgi vastavat kaitset.

Kustutamistaotluse korral kontrolli esmalt, kas andmeid peab mõne teise kohustuse tõttu säilitama. Kui õiguslik erand kehtib, piira kasutust ja selgita inimesele tulemust; kui mitte, kustuta aktiivsetest süsteemidest ning määra varukoopiate ja väliste teenuste käsitlus. GDPR-i kustutamisõigus ei ole tingimusteta: ettevõte peab suutma põhjendada, miks ta andmeid jätkuvalt säilitab.

Lihtsaim tehniline abinõu on andmete eristamine: kasutaja tunnus ja vestluse sisu eri tabelites, ligipääs võtmele eraldi, lühike vaikimisi säilitusaeg ning dokumenteeritud kustutusprotsess. Kui kasutajatunnus jääb tekstiga samasse välja, muutub iga logi jagamine ja eemaldamine raskemaks.

Millal on vaja mõjuhinnangut

GDPR-i artikli 35 järgi tuleb enne töötlemist hinnata andmekaitsealast mõju, kui kavandatud töötlus põhjustab tõenäoliselt suure riski inimeste õigustele ja vabadustele. Tüüpilised riskimärgid on ulatuslik tundlike andmete töötlemine, inimeste süstemaatiline jälgimine või otsused, millel on inimesele märkimisväärne mõju. Täpne kohustus sõltub töötlemise eesmärgist, ulatusest, kontekstist ja kasutatavast tehnoloogiast.

AI määruse artikli 27 põhiõiguste mõjuhinnang on teine kohustus, mille ulatus ei ole sama mis GDPR-i andmekaitsealane mõjuhinnang. AI määruse artikkel 27 puudutab enne kõrge riskiga süsteemi kasutuselevõttu avaliku sektori asutusi, avalikke teenuseid osutavaid eraõiguslikke üksusi ning teatud III lisa punktide 5(b) ja 5(c) süsteemide kasutuselevõtjaid, kindlate eranditega. See hõlmab näiteks füüsiliste isikute krediidivõimelisuse hindamist ja elu- või tervisekindlustuse riski hindamist ning hinnastamist.

Ära tee mõjuhinnangut ainult mallina. Kaasa inimene, kes tunneb tegelikku töövoogu, ja inimesed, keda süsteem mõjutab. Kirjelda, mis juhtub valesti läinud väljundiga, kas inimene saab otsust vaidlustada, kui kaua andmeid hoitakse ja kuidas teenusepakkuja süsteemiga seotud andmeid kasutab.

Andmeleke ja 72 tunni reegel

AI-rakenduse andmeleke võib juhtuda siis, kui töötaja lisab välisesse teenusesse kliendi terviseandmed, ligipääsuta kasutaja näeb vestlusi, süsteem saadab päringu vale kliendiettevõtte kontole või logiteenus jätab täisteksti avalikult kättesaadavaks. Pane intsidentide plaani kirja, kes tuvastab juhtumi, kes hindab andmesubjekte ja milline teenusepakkuja kontakt aitab logid säilitada.

GDPR-i artikkel 33 nõuab, et vastutav töötleja teataks isikuandmetega seotud rikkumisest järelevalveasutusele põhjendamatu viivituseta ja võimaluse korral 72 tunni jooksul pärast rikkumisest teada saamist, välja arvatud juhul, kui rikkumine ei kujuta tõenäoliselt ohtu inimese õigustele ja vabadustele. AKI rikkumisteate juhis toob sama 72 tunni tähtaja. Mõne rikkumise puhul tuleb teavitada ka mõjutatud inimesi; otsus sõltub konkreetse juhtumi riskist.

Säilita tehniline tõendus, kuid ära kopeeri juhtumi uurimise tarbeks põhjendamatult kõigi kasutajate vestlusi. Peata lekkeallikas, piira ligipääs, märgi mõjutatud andmeliigid ja ajavahemik ning kasuta varasemaid logisid ulatuse leidmiseks. Kui kasutajad pole logides eristatavad või sisu on segunenud, võib intsidendi ulatuse hindamine võtta kauem kui lekke parandamine.

Enne AI-funktsiooni kasutuselevõttu

Kontrolli kuut asja enne, kui pärisandmed hakkavad liikuma:

• Kirjuta eraldi eesmärk iga töötluse jaoks: vastuse koostamine, kvaliteedikontroll, turvalisus ja mudeli treenimine.
• Vali õiguslik alus ning dokumenteeri õigustatud huvi analüüs, kui tuginete sellele alusele.
• Võta sisendist välja andmed, mida mudel ülesande lahendamiseks ei vaja; eelista sünteetilisi või anonüümitud testnäiteid.
• Kontrolli, kas tarnija kasutab sisendit treeninguks, kus seda hoitakse, kes sellele ligi pääseb ja kuidas andmeid kustutatakse.
• Koosta logiskeem, kus iga väli on seotud eesmärgi, ligipääsu ja säilitustähtajaga.
• Teavita inimesi arusaadavalt, määra kustutamise ja ligipääsupäringu omanik ning kirjuta rikkumise käsitlus läbi.

AKI tehisaru kasutusele võtja juhend soovitab enne kasutamist kontrollida õiguslikku alust, minimaalsust, säilitusaega, andmete asukohta, teenusepakkuja juurdepääsu, mõjuhinnangu vajadust ja seda, kas sisendit kasutatakse mudeli edasiseks treenimiseks. Need küsimused sobivad toote lähteülesandesse sama hästi kui tehnilised nõuded. Andmevoo ja vastutaja kaardistamiseks enne käivitamist vaata ka AI konsultatsiooni lehte.

See on praktiline ülevaade, mitte õigusnõu. Kui AI hindab töötajaid, kasutab eriliiki andmeid, teeb inimese jaoks olulise otsuse või logib laiaulatuslikult käitumist, küsi konkreetse andmevoo kohta AKI-lt, andmekaitsespetsialistilt või õigusnõustajalt enne kasutuse laiendamist.