Kaskart, kai įvedate tekstą į ChatGPT, įkeliate dokumentą į DI analizės platformą ar leidžiate AI pagalbininkui skaityti jūsų el. paštą, jūs perduodate duomenis. Kartais tai yra nekaltas klausimas apie orą. Kartais tai yra klientų sąrašas, konfidenciali sutartis, medicininis aprašymas ar finansinė ataskaita.
Ir čia kyla klausimas, kurį daugelis užduoda per vėlai: kas nutinka su tais duomenimis po to, kai paspaudžiate „Siųsti”?
Atsakymas nėra paprastas „saugu” arba „nesaugu”. Jis priklauso nuo to, kokį įrankį naudojate, kokius duomenis siunčiate, kaip sukonfigūruotos nuostatos ir kokioje jurisdikcijoje veikiate. Šiame straipsnyje išnarstysite kiekvieną šių klausimų iki galo.
Kas nutinka su jūsų duomenimis, kai juos įvedate į DI įrankį
Daugelis žmonių mano, kad DI įrankis yra kaip skaičiuotuvas: įvedate duomenis, gaunate rezultatą, ir viskas. Tikrovė sudėtingesnė.
Duomenų kelionė nuo jūsų ekrano iki serverio
Kai rašote žinutę ChatGPT, Gemini, Claude ar bet kuriam kitam debesų pagrindu veikiančiam DI įrankiui, vyksta šie procesai:
1. Perdavimas. Jūsų tekstas keliauja internetu nuo jūsų įrenginio iki įrankio tiekėjo serverių. Dauguma rimtų tiekėjų naudoja TLS šifravimą perdavimo metu, tai reiškia, kad duomenys kelionėje yra apsaugoti nuo perėmimo.
2. Apdorojimas. Serveryje jūsų užklausa apdorojama DI modelio. Modelis „perskaito” jūsų tekstą, sugeneruoja atsakymą ir grąžina jį jums.
3. Saugojimas. Čia prasideda svarbiausia dalis. Ar jūsų pokalbis išsaugomas? Kiek laiko? Kas prie jo turi prieigą? Ar jis naudojamas modelio treniravimui?
Kiekvienas iš šių etapų turi savo rizikas, ir kiekviename etape skirtingi tiekėjai elgiasi skirtingai.
Treniravimo duomenų klausimas
Tai yra bene dažniausiai keliamas ir labiausiai nesuprastas klausimas. Ar DI įrankis „mokosi” iš mano duomenų?
Trumpas atsakymas: Priklauso nuo tiekėjo ir jūsų pasirinkto plano.
Ilgas atsakymas:
Kalbos modeliai treniruojami dviem etapais. Pirmasis yra pradinis treniravimas, kai modelis apdoroja milžinišką teksto korpusą (knygos, svetainės, straipsniai). Šis etapas vyksta prieš modeliui patenkant į rinką ir jūsų individualūs duomenys jame nedalyvauja.
Antrasis etapas yra tobulinimas (fine-tuning) ir grįžtamojo ryšio mokymasis. Čia kai kurie tiekėjai gali naudoti vartotojų pokalbius modelio kokybei gerinti. Ir būtent čia kyla rizika.
OpenAI (ChatGPT) politika:
- Nemokama versija ir ChatGPT Plus: pagal numatytąsias nuostatas jūsų pokalbiai gali būti naudojami modelio tobulinimui. Galite tai išjungti nustatymuose (Settings → Data Controls → Improve the model for everyone).
- ChatGPT Team, Enterprise ir API: duomenys pagal numatytuosius nustatymus nenaudojami treniravimui.
- Pokalbiai saugomi serveriuose 30 dienų net ir po išjungimo, siekiant stebėti piktnaudžiavimą.
Google (Gemini) politika:
- Nemokama Gemini versija: pokalbiai gali būti peržiūrimi žmonių ir naudojami tobulinimui. Duomenys saugomi iki 3 metų.
- Google Workspace su Gemini Enterprise: griežtesnės sąlygos, duomenys nenaudojami treniravimui.
- Galite valdyti per „Gemini Apps Activity” nustatymus.
Anthropic (Claude) politika:
- Nemokama ir Pro versija: pagal numatytąsias nuostatas duomenys gali būti naudojami. Galite atsisakyti.
- API ir verslo planai: duomenys nenaudojami treniravimui.
Microsoft (Copilot) politika:
- Asmeninė versija: duomenys gali būti naudojami.
- Microsoft 365 Copilot (verslo): duomenys lieka jūsų organizacijos ribose ir nenaudojami modelio treniravimui.
Pagrindinė taisyklė: Nemokamos versijos beveik visada turi platesnes duomenų naudojimo teises. Mokamos verslo versijos paprastai siūlo griežtesnę apsaugą.
Konkrečios rizikos pagal duomenų tipą
Ne visi duomenys yra vienodai jautrūs. Rizika priklauso nuo to, ką tiksliai siunčiate.
Asmeniniai duomenys (BDAR kontekstas)
Pagal Bendrąjį duomenų apsaugos reglamentą (BDAR/GDPR), asmeniniai duomenys yra bet kokia informacija, susijusi su identifikuojamu fiziniu asmeniu. Tai apima:
- Vardą, pavardę, el. pašto adresą
- Asmens kodą, paso numerį
- IP adresą, buvimo vietos duomenis
- Sveikatos informaciją
- Finansinius duomenis
- Biometrinius duomenis (veido atvaizdą, pirštų atspaudus, balsą)
Rizika: Jei įvedate kliento vardą, el. paštą ir pirkimų istoriją į DI įrankį, kad sugeneruotumėte personalizuotą pasiūlymą, jūs perduodate asmeninius duomenis trečiajai šaliai. Pagal BDAR, tam reikia teisinio pagrindo (sutikimo, teisėto intereso ir pan.) ir tinkamų apsaugos priemonių.
Realus scenarijus: Personalo specialistė įveda kandidato CV į ChatGPT ir prašo parašyti vertinimą. CV yra pilna asmeninių duomenų: vardas, gimimo data, adresas, darbo patirtis, išsilavinimas. Visi šie duomenys dabar yra OpenAI serveriuose. Jei naudojama nemokama versija, jie gali būti panaudoti modelio treniravimui. Kandidatas apie tai nežino ir sutikimo nedavė.
Komercinės paslaptys ir konfidenciali verslo informacija
Tai galbūt didžiausia rizikos zona, nes padariniai gali būti tiesioginiai ir finansiškai skausmingi.
Kas priskiriama komercinėms paslaptims:
- Produktų formulės ir specifikacijos
- Kainodaros strategijos
- Klientų sąrašai ir kontaktai
- Nepublikuoti finansiniai duomenys
- Programinio kodo fragmentai
- Vidiniai strateginiai dokumentai
- Derybų pozicijos ir sąlygos
- Būsimų produktų planai
Realūs incidentai:
Samsung atvejis (2023 m.): Samsung inžinieriai įvedė konfidencialų programinį kodą į ChatGPT, prašydami pagalbos su derinimo problemomis. Trys atskiri incidentai per trumpą laiką. Rezultatas: Samsung uždraudė darbuotojams naudoti generatyvinius DI įrankius darbo įrenginiuose.
Panašūs atvejai fiksuoti advokatų kontoroje, kai teisininkas įvedė klientų bylos detales į DI įrankį, ir farmacijos bendrovėje, kur tyrėjas pasidalijo nepublikuotais laboratoriniais rezultatais.
Kodėl tai pavojinga: Net jei tiekėjas teigia, kad duomenys nenaudojami treniravimui, pats faktas, kad konfidenciali informacija atsidūrė trečiosios šalies serveryje, gali:
- Pažeisti konfidencialumo sutartis su klientais ar partneriais
- Sukelti teisinę atsakomybę pagal komercinių paslapčių apsaugos įstatymus
- Pakenkti konkurenciniam pranašumui, jei duomenys būtų nutekinti dėl saugumo pažeidimo
Sveikatos duomenys
Sveikatos duomenys turi ypatingą teisinę apsaugą tiek pagal BDAR (priskiriami „specialių kategorijų duomenims”), tiek pagal nacionalinius sveikatos duomenų apsaugos įstatymus.
Rizikos scenarijai:
- Gydytojas įveda paciento simptomus ir tyrimų rezultatus, prašydamas diagnostinės pagalbos
- Psichoterapeutas kopijuoja sesijos užrašus, prašydamas pagalbos su ataskaita
- Pacientas pats aprašo savo simptomus DI pokalbių robotui
Kiekvienu atveju sveikatos duomenys patenka į trečiosios šalies serverius, dažniausiai JAV jurisdikcijoje, kur apsaugos standartai gali skirtis nuo europinių.
Finansiniai duomenys
Banko sąskaitų numeriai, mokėjimo kortelių duomenys, pajamų deklaracijos, investicijų portfeliai, įmonių finansinės ataskaitos.
Rizikos scenarijai:
- Buhalteris įveda finansinius duomenis, prašydamas pagalbos su mokesčių skaičiavimais
- Verslininkas kopijuoja banko išrašą, prašydamas išlaidų analizės
- Finansų analitikas įveda nepublikuotus įmonės finansinius rezultatus, prašydamas prognozės
Vaikų duomenys
Pagal BDAR ir daugelį nacionalinių įstatymų, vaikų duomenys turi ypatingą apsaugą. Mokytojas, įvedantis mokinio vardą ir pažymius į DI įrankį, kad sugeneruotų atsiliepimą, potencialiai pažeidžia šias taisykles.
Teisinė aplinka: ką sako įstatymai
BDAR (Europos Sąjunga)
BDAR yra griežčiausias duomenų apsaugos reglamentas pasaulyje ir jis tiesiogiai taikomas DI įrankių naudojimui.
Pagrindiniai BDAR reikalavimai, susiję su DI:
1. Teisinis pagrindas duomenų tvarkymui. Prieš perduodant asmeninius duomenis DI įrankiui, reikia turėti teisinį pagrindą. Tai gali būti:
- Duomenų subjekto sutikimas
- Sutarties vykdymas
- Teisėtas interesas (reikia atlikti balanso testą)
- Teisinė prievolė
2. Duomenų perdavimas už ES ribų. Dauguma DI įrankių serveriai yra JAV. Duomenų perdavimas už ES ribų reikalauja papildomų apsaugos priemonių: standartinių sutarčių sąlygų (SCC), privalomų įmonės taisyklių ar adekvatumo sprendimo.
3. Duomenų minimizavimas. Pagal BDAR principą, turėtumėte perduoti tik tuos duomenis, kurie būtini konkrečiam tikslui. Jei prašote DI parašyti el. laišką klientui, nereikia įvesti jo asmens kodo ar gimimo datos.
4. Informavimo pareiga. Jei tvarkote kitų žmonių asmeninius duomenis per DI įrankius, privalote informuoti tuos žmones apie tokį duomenų tvarkymą.
5. Poveikio duomenų apsaugai vertinimas (PDAV). Didelio masto ar sisteminis asmeninių duomenų tvarkymas per DI gali reikalauti formalaus PDAV atlikimo.
Italijos precedentas: 2023 m. Italijos duomenų apsaugos institucija laikinai užblokavo ChatGPT dėl BDAR pažeidimų, nurodydama nepakankamą informavimą apie duomenų tvarkymą ir teisinio pagrindo trūkumą. OpenAI turėjo atlikti pakeitimus, kad galėtų tęsti veiklą Italijoje.
ES DI aktas (AI Act)
ES DI aktas, įsigaliojęs 2024 m. ir laipsniškai taikomas nuo 2025 m., nustato papildomus reikalavimus DI sistemoms:
- Skaidrumo reikalavimai. DI sistemos turi aiškiai informuoti vartotojus, kad jie bendrauja su DI.
- Didelės rizikos DI sistemos. DI naudojimas sveikatos priežiūroje, švietrime, teisėsaugoje ir kitose jautriose srityse turi atitikti griežtesnius reikalavimus.
- Bendrosios paskirties DI modeliai. Dideli kalbos modeliai (GPT, Gemini, Claude) turi atitikti skaidrumo reikalavimus dėl treniravimo duomenų.
Sektoriniai reikalavimai
Finansų sektorius: Bankai ir draudimo bendrovės turi laikytis papildomų reguliavimų (DORA reglamentas ES, finansinių paslaugų reguliuotojai). DI naudojimas klientų duomenims tvarkyti gali reikalauti reguliuotojo patvirtinimo.
Sveikatos sektorius: Medicininių duomenų tvarkymas per DI turi atitikti ne tik BDAR, bet ir nacionalinius sveikatos duomenų apsaugos įstatymus.
Viešasis sektorius: Valstybės institucijos turi laikytis griežtesnių duomenų tvarkymo standartų ir dažnai privalo naudoti tik patvirtintus IT sprendimus.
Realios grėsmės: kas gali nutikti
1. Duomenų nutekėjimas per saugumo pažeidimą
DI tiekėjai, kaip ir bet kuri technologijų bendrovė, gali tapti kibernetinių atakų taikiniu.
Realus atvejis: 2023 m. kovo mėnesį OpenAI patyrė klaidą, dėl kurios kai kurie ChatGPT Plus vartotojai galėjo matyti kitų vartotojų pokalbių istoriją, vardus, el. pašto adresus ir net mokėjimo kortelių paskutiniuosius skaitmenis. Klaida buvo ištaisyta per kelias valandas, bet parodė, kad net didžiausi tiekėjai nėra apsaugoti nuo incidentų.
2. Duomenų panaudojimas treniravimui ir „atsiminimas”
Jei jūsų duomenys panaudojami modelio treniravimui, jie teoriškai gali „iškylti” kito vartotojo pokalbyje. DI modeliai kartais reprodukuoja treniravimo duomenų fragmentus, ypač jei tie duomenys buvo labai specifiniai arba pasikartojantys.
Tyrimas: Carnegie Mellon universiteto ir Google DeepMind tyrėjai 2023 m. parodė, kad galima priversti kalbos modelius „atkurti” treniravimo duomenis, naudojant specialias užklausas. Tai reiškia, kad treniravimui panaudoti duomenys nėra visiškai apsaugoti.
3. Vidinių naudotojų piktnaudžiavimas
DI tiekėjų darbuotojai teoriškai gali turėti prieigą prie vartotojų pokalbių. Nors tiekėjai teigia, kad prieiga ribojama ir audituojama, tai lieka pasitikėjimo klausimas.
4. Teisiniai ginčai ir teismų nurodymai
Jei DI tiekėjas gauna teismo nurodymą atskleisti vartotojo duomenis, jis privalo paklusti. Tai reiškia, kad jūsų pokalbiai gali tapti teismo proceso dalimi, net jei jie nebuvo naudojami treniravimui.
5. Trečiųjų šalių prieiga per API ir integraciją
Daugelis DI įrankių veikia ne izoliuotai, o integruojasi su kitomis platformomis: CRM sistemomis, el. paštu, dokumentų valdymo sistemomis. Kiekviena integracija sukuria papildomą duomenų perdavimo tašką ir papildomą riziką.
Pavyzdys: DI pagalbininkas, integruotas su jūsų el. pašto paskyra, skaito visus laiškus, kad galėtų siūlyti atsakymus. Kiekvienas laiškas, su visa jame esančia informacija (klientų duomenys, konfidencialios derybos, asmeniniai pokalbiai), keliauja per DI tiekėjo serverius.
Apsaugos priemonės: ką galite padaryti
Asmeninis lygmuo
1. Prieš rašydami, pagalvokite: „Ar norėčiau, kad tai būtų viešai?”
Tai paprasčiausia ir efektyviausia taisyklė. Prieš įvesdami bet kokią informaciją į DI įrankį, paklauskite savęs: jei ši informacija ryt pasirodytų viešame internete, ar tai sukeltų problemų? Jei atsakymas „taip”, nespauskite „Siųsti” arba pašalinkite jautrią informaciją.
2. Anonimizuokite duomenis
Prieš įvesdami duomenis, pakeiskite identifikuojančią informaciją bendriniais terminais:
- Vietoj „Jonas Jonaitis, gimęs 1985-03-15, gyvenantis Vilniuje, Gedimino pr. 25″ rašykite „klientas, vyras, 40 metų, gyvena didmiestyje”
- Vietoj tikro įmonės pavadinimo naudokite „Įmonė A”
- Vietoj tikslių finansinių skaičių naudokite apytikslius arba proporcijas
3. Išjunkite modelio treniravimo funkciją
Kiekvieno pagrindinio DI įrankio nustatymuose yra galimybė atsisakyti duomenų naudojimo treniravimui:
- ChatGPT: Settings → Data Controls → „Improve the model for everyone” → išjunkite
- Gemini: Google paskyros nustatymai → Gemini Apps Activity → pristabdykite
- Claude: Nustatymuose galite atsisakyti duomenų naudojimo
4. Naudokite atskirą paskyrą darbui
Jei naudojate DI ir asmeniniams, ir profesiniams tikslams, turėkite atskiras paskyras. Tai padeda atskirti darbo duomenis nuo asmeninių ir sumažina netyčinio informacijos pasidalinimo riziką.
5. Reguliariai valykite pokalbių istoriją
Daugelis DI įrankių saugo pokalbių istoriją. Reguliariai ją trinkite, ypač jei pokalbiuose buvo jautrių duomenų. Bet atminkite: ištrinimas iš jūsų paskyros nereiškia, kad duomenys iškart ištrinami iš tiekėjo serverių.
6. Naudokite API, o ne vartotojo sąsają
Jei esate techniškai pajėgus, API (programavimo sąsaja) naudojimas paprastai siūlo griežtesnes privatumo sąlygas nei vartotojo sąsaja. Dauguma tiekėjų per API gautų duomenų nenaudoja treniravimui.
Organizacinis lygmuo
1. Sukurkite DI naudojimo politiką
Kiekviena organizacija, kurios darbuotojai naudoja DI įrankius, turėtų turėti aiškią politiką. Ji turėtų apimti:
Leidžiami naudojimo atvejai:
- Kokio tipo užduotims leidžiama naudoti DI (teksto redagavimas, idėjų generavimas, kodo pagalba)
- Kokie DI įrankiai patvirtinti naudojimui
- Kokiu planu/versija leidžiama naudotis
Draudžiami veiksmai:
- Kokių duomenų negalima įvesti į jokį DI įrankį (klientų asmeniniai duomenys, komercinės paslaptys, nepublikuoti finansiniai duomenys)
- Kokios situacijos reikalauja papildomo patvirtinimo
Atsakomybės: kas organizacijoje atsakingas už DI politikos priežiūrą ir incidentų valdymą.
2. Pasirinkite verslo lygio DI sprendimus
Verslo versijos paprastai siūlo:
| Funkcija | Nemokama/asmeninė versija | Verslo versija |
|---|---|---|
| Duomenų naudojimas treniravimui | Dažnai taip (pagal nutylėjimą) | Paprastai ne |
| Duomenų šifravimas ramybės būsenoje | Bazinis | Pažangus (dažnai klientų valdomas raktas) |
| Prieigos kontrolė | Individuali paskyra | SSO, rolių valdymas, audito žurnalai |
| Duomenų rezidencija | Tiekėjo nuožiūra | Galima pasirinkti regioną (ES) |
| Sutarties sąlygos | Standartinės paslaugų sąlygos | Individuali sutartis su BDAR priedais |
| Atitikties sertifikatai | Ribotas | SOC 2, ISO 27001, BDAR atitiktis |
3. Atlikite poveikio duomenų apsaugai vertinimą (PDAV)
Prieš diegiant DI įrankį organizacijoje, ypač jei jis tvarkys asmeninius duomenis, atlikite PDAV. Jis turėtų apimti:
- Kokio tipo duomenys bus tvarkomi
- Kokiu teisiniu pagrindu
- Kokie rizikos veiksniai egzistuoja
- Kokios apsaugos priemonės taikomos
- Ar buvo konsultuotasi su duomenų apsaugos pareigūnu
4. Įdiekite techninę apsaugą
- DLP (Data Loss Prevention) sistemos. Stebėkite ir blokuokite jautrių duomenų perdavimą į DI platformas.
- Tinklo stebėjimas. Stebėkite, kokioms DI platformoms darbuotojai siunčia duomenis.
- Vietiniai DI sprendimai. Jautrioms užduotims apsvarstykite atviro kodo modelius, veikiančius jūsų pačių serveriuose (Llama, Mistral ir pan.). Duomenys niekada neišeina iš jūsų infrastruktūros.
- Prieigos kontrolė. Ribokite, kurie darbuotojai turi prieigą prie kurių DI įrankių, pagal jų darbo pobūdį ir duomenų jautrumą.
5. Apmokykite darbuotojus
Technologinės priemonės neveikia be žmonių supratimo. Darbuotojai turėtų žinoti:
- Kodėl duomenų apsauga svarbi (ne tik „nes taip liepia politika”, o konkrečios pasekmės)
- Kaip atpažinti jautrius duomenis
- Kaip anonimizuoti informaciją prieš siunčiant DI įrankiui
- Ką daryti, jei netyčia pasidalino jautriais duomenimis
- Kokius DI įrankius leidžiama naudoti ir kokiomis sąlygomis
Mokymai turėtų būti reguliarūs (ne vienkartiniai), su konkrečiais pavyzdžiais iš jų darbo srities ir praktiniais scenarijais.
DI tiekėjų saugumo palyginimas
OpenAI (ChatGPT)
Saugumo priemonės:
- SOC 2 Type II sertifikatas
- Duomenų šifravimas perdavimo metu (TLS 1.2+) ir ramybės būsenoje (AES-256)
- Enterprise versijoje: duomenys nenaudojami treniravimui, SSO, SCIM, audito žurnalai
- Duomenų tvarkymo papildymas (DPA) su standartinėmis sutarčių sąlygomis ES duomenims
Silpnosios vietos:
- Nemokama versija pagal nutylėjimą naudoja duomenis treniravimui
- Pokalbių istorija saugoma ir gali būti peržiūrima žmogaus peržiūrėtojų
- Duomenų serveriai daugiausia JAV
Google (Gemini)
Saugumo priemonės:
- Google Cloud infrastruktūra su pažangiu šifravimu
- ISO 27001, SOC 2/3 sertifikatai
- Workspace versijoje: duomenys nenaudojami treniravimui, ES duomenų rezidencijos galimybė
- Integracija su Google saugumo ekosistema
Silpnosios vietos:
- Nemokama versija: pokalbiai gali būti peržiūrimi žmonių ir saugomi iki 3 metų
- Kompleksinė privatumo politika, susijusi su visa Google ekosistema
- Duomenų naudojimas reklamai (nemokamoje versijoje)
Anthropic (Claude)
Saugumo priemonės:
- SOC 2 Type II sertifikatas
- Enterprise versijoje: duomenys nenaudojami treniravimui
- Akcentuojamas „atsakingo DI” požiūris
- 90 dienų duomenų saugojimo politika (ne Enterprise)
Silpnosios vietos:
- Mažesnė infrastruktūra nei Google ar Microsoft
- Mažiau regioninių duomenų rezidencijos pasirinkimų
Microsoft (Copilot)
Saugumo priemonės:
- Microsoft 365 Copilot: duomenys lieka organizacijos Microsoft 365 ribose
- Azure AI: galimybė pasirinkti ES duomenų centrą
- Integracija su Microsoft saugumo ekosistema (Entra ID, Purview)
- BDAR atitikties įrankiai integruoti
Silpnosios vietos:
- Asmeninė Copilot versija turi mažiau apsaugos
- Kompleksinis licencijavimas gali sukelti painiavą dėl to, kurios funkcijos kokiame plane veikia
Vietiniai (on-premise) ir atviro kodo sprendimai
Privalumai:
- Duomenys niekada neišeina iš jūsų infrastruktūros
- Pilna kontrolė dėl duomenų saugojimo ir naudojimo
- Nėra priklausomybės nuo trečiosios šalies privatumo politikos
- Galimybė pritaikyti modelį savo reikmėms su savo duomenimis saugioje aplinkoje
Trūkumai:
- Reikalauja techninės kompetencijos diegimui ir palaikymui
- Mažesni modeliai gali būti mažiau pajėgūs nei komerciniai
- Aparatūros kaštai (GPU serveriai)
- Atnaujinimai ir saugumo pataisos jūsų atsakomybė
Populiarūs atviro kodo modeliai: Llama (Meta), Mistral, Gemma (Google), Phi (Microsoft). Juos galima paleisti ant savo serverių naudojant įrankius kaip Ollama, vLLM ar Text Generation Inference.
Specifiniai scenarijai ir rekomendacijos
Scenarijus 1: Mažas verslas naudoja DI rinkodarai
Situacija: 5 darbuotojų marketingo agentūra naudoja ChatGPT turinio kūrimui klientams.
Rizikos:
- Klientų prekės ženklų informacija patenka į DI įrankį
- Rinkodaros strategijos ir kampanijų planai, kurie gali būti konfidencialūs
- Klientų duomenys (el. pašto sąrašai, segmentų aprašymai)
Rekomendacijos:
- Naudokite ChatGPT Team arba Business planą
- Niekada neįveskite klientų kontaktinių duomenų
- Vietoj tikrų klientų pavadinimų naudokite kodinius pavadinimus
- Įtraukite DI naudojimo sąlygas į sutartis su klientais
- Sukurkite vidinę trumpą politiką (1–2 puslapiai), ką galima ir ko negalima įvesti
Scenarijus 2: Programuotojas naudoja DI kodo pagalbai
Situacija: Programuotojas naudoja GitHub Copilot ar ChatGPT kodo rašymui ir derinimui.
Rizikos:
- Programinis kodas gali būti komercinė paslaptis
- API raktai, slaptažodžiai, prisijungimo duomenys gali atsitiktinai patekti į kopiją
- Klientų duomenų bazių struktūros ir duomenys
Rekomendacijos:
- Niekada nekopijuokite kodo fragmentų su tikrais API raktais ar slaptažodžiais
- Naudokite kodo fragmentus su netikrais duomenimis
- Jei dirbate su jautriu kodu, apsvarstykite vietinį DI sprendimą (pvz., Ollama su CodeLlama)
- Naudokite GitHub Copilot Business planą, kuris nesiūlo kodo treniravimui
- Peržiūrėkite savo organizacijos programinės įrangos licencijavimo politiką
Scenarijus 3: Švietimo įstaiga
Situacija: Universitetas leidžia dėstytojams naudoti DI administraciniams tikslams.
Rizikos:
- Studentų asmeniniai duomenys (vardai, pažymiai, akademinė istorija)
- Nepilnamečių duomenys (jei taikoma)
- Akademinių darbų turinys, kuris priklauso studentams
Rekomendacijos:
- Naudokite tik institucijos patvirtintus DI įrankius su verslo sutartimis
- Niekada neįveskite studentų vardų ar identifikuojančios informacijos
- Sukurkite aiškias gaires dėstytojams ir administracijai
- Informuokite studentus apie DI naudojimą jų duomenų tvarkymo kontekste
- Atlikite PDAV prieš diegiant DI sistemą plačiu mastu
Scenarijus 4: Sveikatos priežiūros specialistas
Situacija: Gydytojas nori naudoti DI klinikinio sprendimo palaikymui.
Rizikos:
- Pacientų sveikatos duomenys yra ypatingos kategorijos duomenys pagal BDAR
- Teisinė atsakomybė už duomenų nutekėjimą yra ypač didelė
- Pacientų pasitikėjimas gali būti pažeistas
Rekomendacijos:
- Niekada neįveskite paciento identifikuojančios informacijos į bendrosios paskirties DI įrankius
- Naudokite tik sveikatos sektoriui skirtus, sertifikuotus DI sprendimus
- Vietiniai (on-premise) sprendimai yra stipriai rekomenduojami
- Konsultuokitės su teisininku ir duomenų apsaugos pareigūnu prieš diegimą
- Jei naudojate bendrosios paskirties DI klinikiniam mokymui ar tyrimui, naudokite tik pilnai anonimizuotus duomenis
Scenarijus 5: Teisininkas
Situacija: Advokatas naudoja DI dokumentų analizei ir teisės aktų tyrimui.
Rizikos:
- Advokato ir kliento konfidencialumo privilegija gali būti pažeista
- Bylos strategija ir detalės tampa prieinamos trečiajai šaliai
- Profesinė etika gali būti pažeista
Rekomendacijos:
- Niekada neįveskite kliento identifikuojančių duomenų ar bylų detalių
- Naudokite DI tik bendriesiems teisiniams klausimams, ne konkrečioms byloms
- Jei reikia DI pagalbos su konkrečia byla, pilnai anonimizuokite visą informaciją
- Informuokite klientą ir gaukite sutikimą, jei ketinate naudoti DI bet kokia forma jo byloje
- Apsvarstykite teisės sektoriui skirtus DI sprendimus su atitinkamais saugumo sertifikatais
Atsakymai į dažniausiai užduodamus klausimus
Ar ChatGPT gali „prisiminti” mano duomenis ir parodyti juos kitam vartotojui?
Tiesiogiai, ne. ChatGPT nesaugo jūsų pokalbio konteksto, kuris būtų prieinamas kitiems vartotojams. Bet jei jūsų duomenys buvo panaudoti modelio treniravimui, egzistuoja teorinė tikimybė, kad modelis gali reprodukuoti panašią informaciją kitam vartotojui. Praktikoje ši tikimybė maža, bet ne nulinė, ypač jei informacija buvo labai specifinė ir unikali.
Ar ištrynus pokalbį duomenys tikrai dingsta?
Iš jūsų paskyros, taip. Iš tiekėjo serverių, ne iš karto. OpenAI teigia, kad ištrintų pokalbių duomenys gali būti saugomi iki 30 dienų prieš galutinį ištrynimą. Kitų tiekėjų politika gali skirtis. Atsarginės kopijos gali saugoti duomenis ilgiau.
Ar DI įrankis gali skaityti mano failus kompiuteryje?
Tik tuos, kuriuos jūs aktyviai jam pateikiate (įkeliate). Standartinis debesų DI įrankis neturi prieigos prie jūsų kompiuterio failų sistemos. Išimtis: jei naudojate integruotą DI pagalbininką (pvz., Microsoft Copilot, integruotą su Microsoft 365), jis gali turėti prieigą prie jūsų organizacijos dokumentų pagal nustatytas teises.
Ar VPN apsaugo mano duomenis naudojant DI?
VPN šifruoja jūsų interneto ryšį ir slepia IP adresą, bet neapsaugo jūsų duomenų turinio. Kai tekstas pasiekia DI tiekėjo serverį, VPN nebeturi jokios reikšmės. VPN apsaugo nuo tinklo lygio šnipinėjimo, bet ne nuo duomenų tvarkymo tiekėjo pusėje.
Ar nemokamos DI versijos yra nesaugios?
„Nesaugios” yra per stiprus žodis. Teisingiau sakyti, kad nemokamos versijos siūlo mažiau kontrolės ir platesnes duomenų naudojimo teises. Jos tinka nekonfidencialiems tikslams: mokymui, kūrybiniams projektams, bendriems klausimams. Jos netinka darbui su jautriais duomenimis.
Ar galiu reikalauti, kad DI tiekėjas ištrintų visus mano duomenis?
Pagal BDAR, taip. Turite teisę prašyti ištrinti savo asmeninius duomenis (teisė būti pamirštam). Kiekvienas pagrindinis tiekėjas turi procedūrą šiam prašymui pateikti. Praktikoje tai gali apimti paskyros ir visos pokalbių istorijos ištrynimą. Duomenys, jau panaudoti modelio treniravimui, negali būti „atimti” iš modelio, nes modelis „neatsimena” konkrečių treniravimo pavyzdžių tiesiogine prasme. Tai yra viena iš sudėtingiausių BDAR ir DI sankirtų.
Ateities perspektyvos
Kas keisis artimiausiais metais
Griežtesnis reguliavimas. ES DI aktas jau įsigaliojo ir laipsniškai taikomas. Tikėtina, kad atsiras papildomų gairių dėl DI ir duomenų apsaugos sankirtų. Nacionalinės duomenų apsaugos institucijos aktyviau tikrins DI tiekėjus.
Konfidencialus skaičiavimas (Confidential Computing). Technologijos, leidžiančios DI modeliams apdoroti duomenis šifruotoje aplinkoje, kur net tiekėjas negali matyti apdorojamų duomenų. Microsoft Azure, Google Cloud ir AWS jau siūlo tokias paslaugas, ir jų taikymas DI srityje plečiasi.
Federuotas mokymasis (Federated Learning). DI modeliai treniruojami vartotojų įrenginiuose, o centriniam serveriui siunčiami tik modelio atnaujinimai, ne patys duomenys. Apple jau naudoja šią technologiją kai kurioms „Siri” funkcijoms.
Standartizuotos DI privatumo žymės. Panašiai kaip maisto produktų etiketės nurodo sudedamąsias dalis, DI įrankiai gali būti privalomi turėti standartizuotą „privatumo etiketę”: kokius duomenis renka, kaip naudoja, kur saugo, kiek laiko.
Vietinis DI tampa prieinamesnis. Mažesni, efektyvesni modeliai ir galingesnė aparatūra reiškia, kad vis daugiau DI užduočių bus galima atlikti lokaliai, niekada nesiunčiant duomenų į debesį. „Apple Intelligence” jau demonstruoja šią tendenciją: paprastos užduotys apdorojamos įrenginyje, sudėtingesnės siunčiamos į debesį per šifruotą „Private Cloud Compute” infrastruktūrą.
Kas liks nepakitę
Nepriklausomai nuo technologijų tobulėjimo, pagrindiniai duomenų apsaugos principai išliks:
- Minimalumo principas: dalinkitės tik tais duomenimis, kurie būtini
- Tikslo apribojimas: naudokite duomenis tik tam tikslui, kuriam jie surinkti
- Skaidrumas: žmonės turi žinoti, kaip tvarkomi jų duomenys
- Atskaitomybė: organizacijos turi gebėti įrodyti, kad laikosi taisyklių
Praktinis kontrolinis sąrašas
Prieš naudojant DI įrankį
- [ ] Ar žinote, koks tiekėjo duomenų naudojimo modelis (ar duomenys naudojami treniravimui)?
- [ ] Ar išjungėte duomenų naudojimo treniravimui funkciją (jei taikoma)?
- [ ] Ar naudojate tinkamą plano versiją duomenų jautrumui (verslo planą, jei dirbate su konfidencialiais duomenimis)?
- [ ] Ar jūsų organizacija turi DI naudojimo politiką?
Prieš kiekvieną pokalbį su DI
- [ ] Ar pašalinote visus nereikalingus asmeninius duomenis?
- [ ] Ar pakeitėte tikrus vardus, pavadinimus ir identifikatorius bendriniais terminais?
- [ ] Ar neįvedėte slaptažodžių, API raktų ar finansinių duomenų?
- [ ] Ar klausiate savęs: „Ar norėčiau, kad tai būtų viešai?”
Organizacijos lygmeniu
- [ ] Ar turite dokumentuotą DI naudojimo politiką?
- [ ] Ar darbuotojai apmokyti saugiai naudoti DI įrankius?
- [ ] Ar atliktas poveikio duomenų apsaugai vertinimas (PDAV)?
- [ ] Ar pasirašytos duomenų tvarkymo sutartys su DI tiekėjais?
- [ ] Ar turite incidentų valdymo planą DI duomenų nutekėjimo atveju?
- [ ] Ar reguliariai peržiūrite ir atnaujinate DI politiką?
Duomenų dalinimasis su DI įrankiais nėra savaime pavojingas ir nėra savaime saugus. Tai priklauso nuo jūsų sprendimų: kokį įrankį pasirenkate, kaip jį konfigūruojate, kokius duomenis siunčiate ir kokias apsaugos priemones taikote. Mąstykite apie DI įrankį kaip apie labai protingą, bet ne visiškai patikimą kolegą: dalinkitės tuo, ką reikia, bet laikykite prie savęs tai, kas konfidencialu. Ir visada žinokite, kur yra „išjungimo” mygtukas.