Kai prieš kelerius metus pradėjome diegti mašininio mokymosi sprendimus klientų aptarnavimo sistemose, teisininkai mums iškart uždavė klausimą – o kur duomenys keliauja treniruojant modelį? Tuomet supratome, kad tarp AI kūrėjų ir duomenų apsaugos specialistų egzistuoja gana didelis atotrūkis. Vieni galvoja apie tikslumą, greitį, algoritmus, kiti – apie teisėtus pagrindus, sutikimus ir teises į duomenų ištrynimą. Šiandien ta praraja pamažu nyksta, bet klausimų vis dar daugiau nei atsakymų.
Kodėl AI ir GDPR iš viso susikerta
Dirbtinis intelektas be duomenų neegzistuoja – tai gana banalu pasakyti, bet tenka priminti nuolat. Kiekvienas modelis, ar tai būtų paprastas rekomendacijų variklis, ar didelė kalbos modelio architektūra, reikalauja treniruotės duomenų. Ir jei tie duomenys apima bent minimalią asmens informaciją – vardą, IP adresą, elgesio istoriją, balso įrašą ar veido atvaizdą – GDPR įsijungia automatiškai, nepriklausomai nuo to, ar sistema vadinama „AI“, ar tiesiog „algoritmu“.
Problema ta, kad GDPR buvo rašytas 2016 metais, kai apie generatyvinius modelius mažai kas galvojo. Reglamentas orientuotas į konkrečius duomenų tvarkymo veiksmus – rinkimą, saugojimą, perdavimą. O AI modeliai dažnai veikia kitaip: duomenys „ištirpsta“ modelio parametruose, tampa sunkiai atsekami, bet vis tiek gali būti išgaunami atgal (pavyzdžiui, per vadinamąsias membership inference atakas). Tai reiškia, kad net jei manote, jog duomenys „anonimizuoti“ ir saugūs, teisiškai jie gali būti vertinami kaip asmens duomenys, jei juos įmanoma priskirti konkrečiam asmeniui bent teoriškai.
Teisėtas pagrindas – ne formalumas, o architektūros klausimas
Vienas dažniausių klaidingų įsitikinimų – kad pakanka parašyti privatumo politikoje sakinį „naudojame duomenis AI mokymui“ ir viskas sutvarkyta. Realybėje reikia aiškiai apsibrėžti teisinį pagrindą pagal GDPR 6 straipsnį: sutikimas, teisėtas interesas, sutarties vykdymas ar teisinė pareiga. Kiekvienas iš jų turi skirtingas pasekmes technine prasme.
Jei renkatės sutikimą, turite užtikrinti mechanizmą, leidžiantį jį atšaukti – o tai reiškia, kad jūsų sistema turi mokėti „pamiršti“ konkretaus vartotojo duomenis, net jei jie jau panaudoti modelio treniravimui. Techniškai tai vienas sudėtingiausių iššūkių – modelio negalima tiesiog „iškirpti“ vieno žmogaus indėlio be pertreniravimo arba specialių machine unlearning technikų, kurios dar toli gražu nėra brandžios pramonės standartu.
Jei renkatės teisėtą interesą, turite atlikti balansavimo testą (angl. Legitimate Interest Assessment) ir dokumentuoti, kodėl jūsų interesas nusveria vartotojo privatumo lūkesčius. Priežiūros institucijos, tarp jų ir Lietuvos VDAI, vis dažniau prašo parodyti šį dokumentą realiuose patikrinimuose, ne tik teoriškai.
Duomenų minimizavimas praktikoje: kai mažiau tikrai yra daugiau
IT komandose įprasta mąstyti „daugiau duomenų – geresnis modelis“. GDPR principas – priešingas: rinkite tik tiek, kiek būtinai reikia konkrečiam tikslui. Šis konfliktas realiai egzistuoja kiekviename projekte, kur dalyvauja duomenų mokslininkai ir juristai.
Praktiškai tai reiškia keletą konkrečių žingsnių:
- Prieš pradedant treniruotę, atlikti duomenų auditą – kokie laukai realiai naudojami modelio tikslumui, o kokie tiesiog „pravertė“ istoriškai.
- Naudoti pseudonimizavimą kur įmanoma – pakeisti tiesioginius identifikatorius (vardą, el. paštą) atsitiktiniais raktais, saugant susiejimo lentelę atskirai, su griežtesne prieigos kontrole.
- Taikyti federuotą mokymąsi (federated learning), kai modelis treniruojamas lokaliai prie duomenų šaltinio, o į centrinį serverį siunčiami tik apibendrinti parametrų atnaujinimai, ne patys duomenys.
- Apsvarstyti diferencinę privatumo (differential privacy) apsaugą – triukšmo pridėjimą duomenims taip, kad pavieno įrašo įtaka rezultatui taptų statistiškai nereikšminga.
Šie metodai nėra magiška lazdelė – jie mažina modelio tikslumą tam tikru procentu, ir čia jau prasideda derybos tarp produkto komandos ir duomenų apsaugos pareigūno. Bet realybė tokia: geriau turėti 2 procentais prastesnį modelį su tvirtu teisiniu pagrindu, nei puikų modelį, kuris po metų sukels baudą, siekiančią iki 4% metinės apyvartos.
Automatizuoti sprendimai ir teisė į paaiškinimą
GDPR 22 straipsnis kalba apie teisę nebūti pavaldiems vien automatizuotam sprendimui, kuris turi teisines ar panašiai reikšmingas pasekmes. Tai aktualu paskolų vertinimo sistemoms, personalo atrankos algoritmams, draudimo rizikos skaičiavimui. Jei jūsų AI sistema priima galutinį sprendimą be žmogaus įsikišimo, privalote suteikti galimybę žmogui ginčyti tą sprendimą ir gauti prasmingą paaiškinimą apie logiką.
Čia iškyla klasikinis „juodosios dėžės“ klausimas. Sudėtingi neuroniniai tinklai, ypač gilaus mokymosi modeliai, natūraliai nesugeba paaiškinti savo sprendimų taip, kaip tai daro paprastas sprendimų medis. Todėl vis daugiau organizacijų diegia paaiškinamojo AI (Explainable AI, XAI) sluoksnius – SHAP, LIME ir panašius įrankius, kurie leidžia bent apytiksliai parodyti, kurie požymiai labiausiai lėmė konkretų sprendimą.
Praktinis patarimas: jei kuriate sistemą, kuri gali turėti reikšmingą poveikį žmogui, projektuokite ją iškart su „žmogus grandinėje“ (human-in-the-loop) principu. Tai ne tik teisiškai saugiau, bet ir techniškai protingiau – žmogaus peržiūra dažnai atskleidžia edge case’us, kurių modelis niekada nebūtų pastebėjęs.
DPIA didelio masto AI projektams – ne popierizmas, o rizikos žemėlapis
Poveikio duomenų apsaugai vertinimas (DPIA) tampa privalomas, kai tvarkymas gali kelti didelę riziką fizinių asmenų teisėms – o dauguma didelio masto AI projektų būtent tokie ir yra. Klaida, kurią matau dažnai: DPIA rašomas po to, kai sistema jau įdiegta, kaip formalus dokumentas, reikalingas auditui. Teisingas požiūris – DPIA turi būti gyvas dokumentas, atnaujinamas kiekvieną kartą, kai keičiasi modelio architektūra, duomenų šaltiniai ar naudojimo atvejai.
Konkreti rekomendacija komandoms: integruokite DPIA klausimyną tiesiai į projektų valdymo procesą, pavyzdžiui, kaip privalomą žingsnį prieš perkeliant modelį iš staging į produkciją. Tai paverčia teisinį reikalavimą techniniu checkpoint’u, kurį inžinieriai natūraliai priima kaip dar vieną kokybės vartų (quality gate) tipą, panašiai kaip saugumo skenavimą ar kodo peržiūrą.
Trečiųjų šalių modeliai ir tiekimo grandinės rizika
Vis rečiau organizacijos treniruoja modelius nuo nulio – dažniau naudojami išoriniai API, pavyzdžiui, didelių kalbos modelių tiekėjų sprendimai. Čia GDPR atsakomybė nedingsta, ji tiesiog persikelia į duomenų tvarkymo sutarčių lygį. Būtina turėti duomenų tvarkymo sutartį (DPA) su kiekvienu AI paslaugų tiekėju, aiškiai apibrėžiančią, kur fiziškai saugomi duomenys, ar jie naudojami tolesniam modelio treniravimui, ir kokios yra pertekimo per trečiąsias šalis sąlygos.
Realus pavyzdys iš praktikos: daugelis populiarių AI API pagal nutylėjimą naudoja užklausų duomenis modelio tobulinimui, nebent aiškiai išjungiate šią funkciją nustatymuose arba pasirenkate verslo/enterprise planą su kitokiomis sąlygomis. Jei jūsų komanda siunčia klientų duomenis per tokį API neatlikus šio patikrinimo, jūs galite netyčia pažeisti GDPR, net nesuprasdami, kad tai vyksta – nes techniškai atrodo, kad tiesiog kviečiate funkciją, o teisiškai tai yra duomenų perdavimas trečiajai šaliai.
Taip pat svarbu patikrinti, kur geografiškai vyksta duomenų tvarkymas. Jei tiekėjas serverius laiko JAV ar kitur už EEE ribų, reikalingas tinkamas perdavimo mechanizmas – standartinės sutartinės sąlygos (SCC) arba adekvatumo sprendimas. Po Schrems II sprendimo šis klausimas tapo dar jautresnis, ir vien sutarties pasirašymas nebūtinai reiškia realų atitikimą – reikia įvertinti ir faktinę apsaugą praktikoje.
Kai algoritmas diskriminuoja: šalutinis GDPR ir etikos susikirtimas
Nors tiesiogiai tai nėra GDPR straipsnis, duomenų apsaugos ir diskriminacijos vengimo temos glaudžiai susijusios. Modeliai, treniruoti ant istorinių duomenų, linkę atkartoti praeities šališkumus – jei įmonė istoriškai rečiau įdarbindavo tam tikros grupės žmones, modelis „išmoks“ tą patį elgesį, net jei jautrūs požymiai (rasė, lytis) formaliai pašalinti iš duomenų rinkinio, nes proxy kintamieji (pavyzdžiui, pašto kodas ar mokykla) gali netiesiogiai koduoti tą pačią informaciją.
GDPR 9 straipsnis specialiai reglamentuoja specialių kategorijų duomenų (sveikatos, religijos, seksualinės orientacijos) tvarkymą, ir jei jūsų modelis netiesiogiai išveda tokią informaciją, net jos tiesiogiai nerinkdamas, situacija tampa teisiškai pilkoji zona. Rekomenduoju reguliariai atlikti bias auditą naudojant įrankius kaip Fairlearn ar AI Fairness 360, ir dokumentuoti rezultatus kaip DPIA dalį.
Vietoj griežtos formulės – keli patarimai, kuriuos verta prisisegti prie darbastalio
Baigiant norisi ne tiek apibendrinti, kiek palikti kelias praktines gaires, kurios realiai padeda, kai reikia priimti sprendimą greitai ir be teisininko po ranka kiekvienam žingsniui.
Pirma – jei abejojate, ar duomenys yra asmeniniai, elkitės taip, tarsi jie būtų. Pigiau iš karto taikyti apsaugos priemones, nei po metų aiškintis su priežiūros institucija. Antra – įtraukite duomenų apsaugos pareigūną į projektą nuo pat idėjos stadijos, ne tada, kai modelis jau veikia produkcijoje. „Privacy by design“ nėra gražus šūkis konferencijoms, tai realiai sutaupo mėnesius perdarinėjimo darbo. Trečia – dokumentuokite viską, ką darote su duomenimis, net jei atrodo akivaizdu. Kai ateis auditas (o jis ateis, ypač jei dirbate su jautriais sektoriais kaip finansai ar sveikata), turėsite ką parodyti.
Ketvirta – neignoruokite mažų projektų. Vidinis chatbot’as, sukurtas per savaitgalį testuoti idėją, gali greitai tapti gamybine sistema, apdorojančia tūkstančius klientų užklausų, ir tuomet niekas neprisimena, kokie duomenys buvo naudoti prototipe. Penkta – sekite reguliavimo raidą. ES AI aktas (AI Act) jau pradeda veikti lygiagrečiai su GDPR, ir abu reglamentai vienas kitą papildo bei kartais susikerta – ypač ties didelės rizikos AI sistemų apibrėžimu. Tai, kas šiandien atrodo pilka zona, po metų gali tapti aiškiai apibrėžtu pareigos reikalavimu su konkrečiais terminais.
Galiausiai – nebijokite eksperimentuoti su privatumą tausojančiomis technologijomis. Sintetiniai duomenys, homomorfinis šifravimas, federuotas mokymasis – tai ne akademinės egzotikos, o realūs įrankiai, kuriuos jau naudoja bankai ir sveikatos priežiūros įstaigos. Investicija į šias technologijas šiandien reiškia mažiau galvos skausmo rytoj, kai reguliavimas neišvengiamai griežtės, o vartotojų jautrumas savo duomenims tik augs.
