Shadow AI: kai darbuotojai naudoja ChatGPT be įmonės taisyklių

Įsivaizduokite: mažos įmonės darbuotojas turi atsakyti dešimčiai klientų. Kad sutaupytų laiko, jis nukopijuoja visus laiškus į asmeninę DI paskyrą ir paprašo parengti atsakymus. Per kelias minutes darbas atrodo atliktas. Bet ar vadovas žino, kokia informacija buvo perduota, kokios paskyros taisyklės taikomos ir ar DI atsakymus kas nors patikrino?

Tai hipotetinis pavyzdys, ne tikra ROILEAKAI kliento istorija. Jis rodo problemą, kuri dažnai slepiasi po patogiu įrankiu: darbuotojai pasitelkia DI, tačiau įmonė neturi aiškių jo naudojimo taisyklių.

Kas yra Shadow AI?

Shadow AI – organizacijoje naudojami DI įrankiai, programėlės, naršyklės plėtiniai ar agentai, apie kuriuos atsakingi asmenys nežino arba kurių naudojimas nėra tinkamai patvirtintas ir valdomas. Tai artima „Shadow IT“ sąvokai, tačiau susiję būtent su dirbtiniu intelektu. [1]

Pats DI naudojimas nėra blogybė. Neprižiūrimas naudojimas sukuria akląją zoną: sunku atsakyti, kas pasiekia informaciją, kokiomis sąlygomis ji tvarkoma ir kas atsako už galutinį rezultatą.

Penkios kasdienės situacijos

Šie pavyzdžiai yra iliustraciniai – ne konkretūs nustatyti incidentai.

1. Klientų aptarnavimas. Darbuotojas įkelia klientų laiškus su vardais, telefonais ir užsakymų informacija, kad DI parašytų atsakymą.
2. Buhalterija. Į DI įrankį įkeliamas atlyginimų ar sąskaitų failas, nors darbuotojas gali užduoti klausimą be identifikuojančių duomenų.
3. Pardavimai. Komanda siunčia DI potencialių klientų sąrašą, kuriame yra asmens kontaktinė informacija ir konfidencialūs komentarai.
4. Programavimas. Į viešą pokalbį nukopijuojamas kodo fragmentas su API raktu ar vidinio serverio konfigūracija.
5. Rinkodara. DI sugeneruotas reklaminis teiginys publikuojamas nepatikrinus fakto ar klientui duoto pažado.

Rizika skiriasi: viešo reklaminio teksto redagavimas nėra tas pats, kas darbuotojų medicininių duomenų, prisijungimų ar asmens dokumentų kopijų perdavimas trečiajai šaliai.

Kokios pagrindinės rizikos?

1. Duomenys gali patekti į neįvertintą paslaugą

Naudojant išorinį DI paslaugų teikėją reikia suprasti, kokie duomenys perduodami, ar jie saugomi, kiek laiko, kam pasiekiami ir kokios kontrolės siūlomos. Vieno visiems įrankiams galiojančio atsakymo nėra: skiriasi produktas, planas, nustatymai ir sutartinės sąlygos. Pavyzdžiui, „OpenAI“ nurodo, kad jos verslo produktų ir API įvestys bei išvestys pagal numatytuosius nustatymus nėra naudojamos modeliams mokyti; tai nereiškia, jog kiekvienas įrankis turi tokias pačias sąlygas ar kad duomenys fiziškai lieka tik įmonės viduje. [4]

2. Nepatikrinti atsakymai gali tapti klaidingais sprendimais

DI gali pateikti įtikinamą, bet neteisingą informaciją. NCSC tarp generatyviojo DI rizikų mini klaidingus faktus ir kitas saugumo problemas. [5] Todėl kainas, teisines išvadas, technines instrukcijas ir klientams siunčiamus pažadus būtina patikrinti žmogui.

3. Neaiški atsakomybė

Jei darbuotojas naudoja savo paskyrą darbo informacijai apdoroti, įmonei gali būti sunku atkurti sprendimų kelią, pritaikyti saugos taisykles ar reaguoti į incidentą. Geriau iš anksto susitarti, kokiais įrankiais ir kokioms užduotims galima naudotis.

4. Asmens duomenų ir sutarčių klausimai

BDAR nereiškia, kad bet koks DI įrankio naudojimas su asmens duomenimis automatiškai yra pažeidimas. Tačiau organizacija turi įvertinti tvarkymo tikslą, teisinį pagrindą, duomenų būtinumą ir saugumo priemones. Lietuvos VDAI pateikia septynių pradinių žingsnių metodiką organizacijoms, planuojančioms naudoti DI sistemas su asmens duomenimis. [2] EDPB pabrėžia, kad DI modelių duomenų apsaugos klausimai vertinami pagal aplinkybes. [3]

Ką galima daryti saugiau jau šiandien? 7 žingsniai

1. Susirašykite įrankius. Per trumpą komandų aptarimą paprašykite žmonių nurodyti, kokiais DI įrankiais jie naudojasi, kokioms užduotims ir ar siunčia failus. Tikslas – suprasti darbo praktiką, ne bausti.

2. Atskirkite duomenų kategorijas. Bent pradžiai naudokite tris lygius: vieša informacija; vidinė verslo informacija; jautrūs ar ribojami duomenys (pvz., kliento asmens duomenys, sutartys, prieigos raktai). Pastarieji neturi būti keliami nepatvirtintiems įrankiams.

3. Patvirtinkite leistinus naudojimo atvejus. Pavyzdžiui, viešo teksto struktūros tobulinimas ir anonimizuotos idėjos gali būti leistini; klientų duomenų analizė – tik po atskiro įvertinimo.

4. Įvertinkite pasirinkto įrankio sąlygas. Patikrinkite privatumo politiką, duomenų naudojimą modelių mokymui, saugojimo terminus, prieigos valdymą, dalijimosi galimybes ir sutartinius aspektus. Vertinkite konkretų produktą bei planą.

5. Mažinkite perduodamus duomenis. Jei DI reikia pagalbos su laiško tonu, pašalinkite vardą, telefoną, sutarties numerį ir kitą nereikalingą informaciją. Atkreipkite dėmesį, kad vien vardų pašalinimas ne visada reiškia tikrą anonimiškumą.

6. Nustatykite žmogaus patikrą. Viešai skelbiami faktai, siūlomos kainos, teisinės formuluotės, saugos rekomendacijos ir klientų komunikacija turi turėti aiškų patvirtinantį žmogų.

7. Susitarkite, ką daryti suklydus. Jei netyčia įkeltas netinkamas failas, darbuotojas turi žinoti, kam nedelsiant pranešti, kokią informaciją pateikti ir kas sprendžia dėl tolesnių veiksmų.

Greitas 10 minučių startas vadovui

• 3 min.: paklauskite, kokie DI įrankiai jau naudojami.
• 3 min.: įvardykite duomenis, kurių negalima siųsti be patvirtinimo.
• 2 min.: paskirkite žmogų, kuris vertins naujus įrankius ar neaiškius atvejus.
• 2 min.: sutarkite, kad svarbūs DI rezultatai visada tikrinami prieš siunčiant klientui.

Tai nėra pilnas rizikos vertinimas, bet naudingas pradžios pokalbis.

Ar užtenka įsigyti „verslo“ DI paskyrą?

Ne. Verslo planas gali suteikti papildomų valdymo ar duomenų apsaugos priemonių, tačiau įmonė vis tiek turi pasirinkti tinkamus nustatymus, apmokyti žmones ir apsispręsti, kuriuos duomenis leidžiama naudoti. Vien API integracija taip pat negarantuoja, kad duomenys niekur neiškeliaus. Reikia vertinti visą darbo grandinę – įskaitant paslaugos teikėją, žurnalus, duomenų saugojimą ir prieigos teises. [4][6]

Dažniausi klausimai

Ar darbuotojams reikia visiškai uždrausti ChatGPT? Nebūtinai. Aiškios leistinos užduotys, įrankių pasirinkimas ir duomenų taisyklės dažnai yra naudingesnis startas nei bendras draudimas.

Ar galima į DI įkelti klientų sąrašą? Tik įvertinus, ar tai būtina, kokia teisėta tvarkymo priežastis, kokie saugikliai ir paslaugos sąlygos. Jei tokio vertinimo nėra, geriau nekelti.

Ar duomenys automatiškai tampa vieši? Ne. Duomenų naudojimą ir prieinamumą lemia konkreti paslauga, jos nustatymai, sutartys bei dalijimosi funkcijos. Tačiau „nevieša“ savaime nereiškia „be jokios rizikos“.

Ar DI automatiškai pažeidžia BDAR? Ne. Atitiktis priklauso nuo konkretaus asmens duomenų tvarkymo. Jei kyla neaiškumų, reikalingas duomenų apsaugos specialisto vertinimas. [2][3]

Praktinis kitas žingsnis

Pradėkite nuo vieno darbo proceso: kur dabar naudojamas DI, kokie duomenys perduodami ir kur žmogus patikrina rezultatą. Jei reikia pagalbos sutvarkant techninę proceso pusę – pavyzdžiui, formų, automatizuotų pranešimų ar duomenų srautų logiką – susipažinkite su ROILEAKAI DI automatizavimo paslauga.