Copilot ir kiti kodo DI įrankiai: ką privalo žinoti įmonė

Jei jūsų įmonėje programuotojai naudoja „GitHub Copilot“, „Cursor“, „Tabnine“ ar bet kurį kitą kodo dirbtinio intelekto (DI) įrankį, jūs jau esate DI diegiantysis subjektas pagal ES DI aktą (angl. AI Act) ir privalote imtis darbuotojų DI raštingumo ugdymo priemonių bei tvarkyti šių įrankių naudojimą. Tai galioja net ir tada, jei įmonėje dirba vos vienas programuotojas. Kodo DI įrankiai nėra išimtis iš reguliavimo - priešingai, jie kelia specifinių rizikų, kurių „ChatGPT“ pokalbiams būdingos taisyklės iki galo neapima.

Smulkiai Lietuvos įmonei, leidžiančiai darbuotojams generuoti kodą su DI, reikia žinoti tris dalykus: kokios prievolės kyla, kokia rizika slypi intelektinės nuosavybės ir saugumo srityse, ir kokius dokumentus reikia turėti. Jei domina platesnis programinės įrangos kūrimo įmonių vaizdas, atskirai skaitykite kaip ES DI aktas taikomas IT įmonėms.

Ar Copilot įmonėje patenka į ES DI akto taikymo sritį?

Taip. „GitHub Copilot“ ir panašūs kodo asistentai yra bendrosios paskirties DI modeliais pagrįstos sistemos, todėl jie patenka į ES DI akto (Reglamentas (ES) 2024/1689) taikymo sritį. Tačiau svarbiausia suprasti, kokiame vaidmenyje atsiduria jūsų įmonė: jūs esate ne DI tiekėjas (gamintojas), o diegiantysis subjektas (angl. deployer) - tas, kuris naudoja DI savo profesinėje veikloje.

Diegiančiajam subjektui pagrindinė prievolė, jau galiojanti, yra DI raštingumas pagal 4 straipsnį. Nuo 2025 m. vasario 2 d. šis straipsnis reikalauja, kad diegiantysis subjektas imtųsi priemonių, padedančias ugdyti darbuotojų ir susijusių asmenų DI raštingumą, atsižvelgiant į jų žinias, patirtį, apmokymą, naudojimo kontekstą ir paveiktus asmenis. Tai neprivalo garantuoti tam tikro ar pakankamo individualaus lygio. Praktiškai tai reiškia, kad net jei jūsų komandą sudaro du programuotojai, naudojantys „Copilot“ kasdien, įmonė jau turi prievolę, kurios neįvykdymas gali tapti problema audito ar kliento patikros metu. Kodo DI įrankiai šiuo požiūriu nesiskiria nuo jokios kitos DI sistemos - jiems galioja tos pačios bazinės taisyklės.

Laiko juosta, kurią verta žinoti:

Kitaip tariant, jei laukiate „kol viskas įsigalios“ - jau pavėlavote, nes raštingumo prievolė galioja daugiau nei metus.

Kuo kodo DI įrankiai skiriasi nuo paprasto „ChatGPT"?

Daugelis įmonių kodo DI įrankius vertina taip pat, kaip pokalbių botą. Tai klaida. Kodo asistentai turi keletą specifinių ypatumų, dėl kurių jiems reikia atskirų taisyklių, nei aprašyta straipsnyje apie ChatGPT naudojimą įmonėje:

• Jie mato jūsų kodų bazę. Kad pasiūlytų tinkamą kodą, įrankis dažnai siunčia į serverį aplinkinį kontekstą - gretimas eilutes, failo turinį, kartais visą projektą. Tai gali būti komercinė paslaptis ar kliento intelektinė nuosavybė.
• Jie generuoja veikiantį produktą, ne juodraštį. „ChatGPT“ tekstą žmogus dar perskaito ir perrašo. DI sugeneruotas kodas neretai patenka į produkciją beveik nepakeistas, todėl klaidos ir saugumo spragos plinta tiesiai į veikiančią sistemą.
• Jie kelia licencijavimo riziką. Modelis apmokytas iš viešo kodo, įskaitant kodą su griežtomis (pvz., GPL) licencijomis. Sugeneruotas fragmentas teoriškai gali atkartoti licencijuotą kodą.
• Jie integruojami giliai. Įrankis veikia tiesiogiai redaktoriuje (IDE), todėl jį naudoja praktiškai be sąmoningo apsisprendimo - „autopilotu“.

Kokios pagrindinės rizikos naudojant kodo DI įmonėje?

Praktiškai smulkiai įmonei aktualios keturios rizikos. Verta jas surašyti ir kiekvienai turėti aiškų atsakymą:

1. Konfidencialių duomenų nutekėjimas. Jei programuotojas dirba su kliento sistema, į DI serverį gali patekti klientui priklausantis kodas, API raktai, slaptažodžiai ar asmens duomenys. Tai liečia ir BDAR reikalavimus DI kontekste, jei kode yra realių asmens duomenų. Įmonėse dažniausiai draudžiami ne visi DI įrankiai, o tik tie, kuriems nėra gautas leidimas ar nėra įvertinti saugumo priemonių - reikia kiekvieną atvejį vertinti atskirai.

2. Saugumo spragos sugeneruotame kode. Tyrimai rodo, kad nemaža dalis DI sugeneruoto kodo turi pažeidžiamumų (pvz., SQL injekcijų, nesaugaus duomenų tvarkymo). Be peržiūros toks kodas tampa atviru langu užpuolikui.

3. Intelektinės nuosavybės ir licencijų rizika. Sugeneruotas fragmentas gali būti panašus į licencijuotą atvirojo kodo kūrinį, o tai sukelia teisinį neapibrėžtumą dėl jūsų produkto nuosavybės.

4. Per didelis pasitikėjimas (automation bias). Programuotojas, ypač jaunesnis, gali priimti DI pasiūlymą nesuprasdamas, ką jis daro. Tai ir yra ta vieta, kur DI raštingumas tampa ne formalumu, o realiu saugikliu.

Šios rizikos nėra teorinės. Smulkioje įmonėje vienas neapgalvotai į DI įrankį įklijuotas konfigūracijos failas su prisijungimo duomenimis arba viena nepatikrinta, bet pažeidžiama autentifikacijos funkcija gali kainuoti brangiau nei metinė visų DI įrankių licencija. Esmė ta, kad atsakomybė už pasekmes lieka įmonei, o ne DI tiekėjui - todėl rizikos valdymas turi būti įmonės, ne įrankio, rankose.

Kaip įmonei suvaldyti kodo DI įrankius praktiškai?

Mikroįmonei nereikia korporacinio dydžio politikų. Reikia kelių aiškių, vykdomų taisyklių, kurias supranta kiekvienas programuotojas. Štai minimalus rinkinys:

• Nustatykite, ką galima ir ko negalima paduoti DI. Pvz.: jokių kliento gamybinių paslapčių, jokių slaptažodžių ar .env failų, jokių realių asmens duomenų. Naudokite įrankių „verslo“ planus, kurie nemoko modelio iš jūsų kodo, ir įjunkite atitinkamus privatumo nustatymus.
• Įveskite privalomą žmogaus peržiūrą. DI sugeneruotas kodas keliauja per kodo peržiūrą lygiai taip pat, kaip žmogaus rašytas. Atsakomybė už kodą lieka žmogui, ne įrankiui.
• Apmokykite komandą. DI raštingumo mokymai turi apimti konkrečiai kodo įrankių riziką, ne tik bendrą „kas yra DI“. Programuotojas turi mokėti atpažinti, kada DI „haliucinuoja“ arba siūlo nesaugų sprendimą. Svarbu: ES DI aktas nereikalauja konkrečios mokymų trukmės, sertifikatų, išorinio mokymų vedėjo ar audito, ar atskiro už DI atsakingo asmens. Tai rekomenduojami, bet ne privalomi veiksmai.
• Inventorizuokite įrankius. Kiekvieną naudojamą kodo DI įrankį įtraukite į DI įrankių registrą kartu su paskirtimi, atsakingu asmeniu ir rizikos vertinimu.
• Tikrinkite licencijų atitiktį. Naudokite įrankio nustatymus, blokuojančius siūlymus, sutampančius su viešu kodu, jei tokia funkcija yra.

Svarbu, kad šios taisyklės būtų ne abstrakčios, o pritaikytos jūsų realiam darbo srautui. Pavyzdžiui, jei dirbate su finansų sektoriaus klientu, taisyklė „jokių realių duomenų DI įrankyje“ turi būti susieta su konkrečiu reikalavimu naudoti tik išgalvotus (sintetinius) testinius duomenis. Jei kuriate produktą, kurį parduosite, licencijų klausimas tampa kritinis - verta įsivesti taisyklę, kad bet koks didesnis DI sugeneruotas blokas pažymimas peržiūrai dėl galimo sutapimo su atvirojo kodo kūriniais. Geras orientyras: jei negalėtumėte ramiai paaiškinti klientui ar auditoriui, kaip atsirado konkreti kodo dalis, vadinasi, procesui trūksta kontrolės.

Kokie dokumentai padeda įmonei organizuoti DI naudojimą?

Net ir maža programavimo įmonė turėtų turėti tą patį atitikties dokumentų rinkinį, kaip ir bet kuris kitas DI diegiantysis subjektas. Skirtumas tik tas, kad turinys pritaikomas kodo įrankių specifikai. ES DI aktas nereikalauja, kad dokumentai būtų sudaryti tam tikra forma ar turėtų konkretų turinį - tai rekomenduojama, bet ne privaloma.

• DI naudojimo politika - kur aprašyta, kaip leidžiama naudoti kodo asistentus, kokie duomenys draudžiami, kaip vyksta peržiūra.
• DI įrankių registras - su visais naudojamais kodo įrankiais ir jų rizikos kategorijomis.
• Atitikties įrašas pagal 4 straipsnį - įrodymas, kad darbuotojai apmokyti (pvz., mokymų protokolai, pažymėjimai).
• Darbuotojų DI vadovas - praktiškos taisyklės programuotojui kasdieniam darbui.
• DI raštingumo mokymai su žinių patikra - kad turėtumėte dokumentuotą įrodymą, jog komanda išmano riziką.

Šių dokumentų nereikia rašyti nuo nulio. nebedirbam.lt automatiškai parengia visą šį rinkinį už fiksuotą €149 + PVM (€299) kainą, pritaikytą jūsų įmonės atsakymams - nuo politikos iki mokymų su pažymėjimais (žr. pagrindinį puslapį). Jei pirmiausia norite išbandyti mokymus patys, yra ir nemokami DI raštingumo mokymai. Nemokamas kelias skirtas vienam prisijungusiam dalyviui; komandos mokymai įtraukti į mokamą dokumentų paketą.

Svarbu pabrėžti: šie dokumentai ir mokymai yra praktinės priemonės, bet jie negarantuoja teisinės atitikties ES DI aktui.

Dažniausiai užduodami klausimai

Ar reikia dokumentų, jei DI naudoja tik vienas programuotojas? Taip. ES DI akto 4 straipsnis netaiko išimties pagal įmonės dydį - prievolė imtis proporcingų DI raštingumo priemonių gali būti taikoma ir vieno asmens įmonei.

Ar galiu tiesiog uždrausti kodo DI įrankius ir nieko nedaryti? Galite, bet praktiškai tai sunkiai įvykdoma - programuotojai ras būdą juos naudoti asmeniškai, ir tai virs nekontroliuojamu, dokumentais nepadengtu naudojimu. Apie tokią „šešėlinio DI“ problemą verta žinoti dar prieš ją uždraudžiant.

Ar kodo DI įrankis paverčia mane „aukštos rizikos“ DI sistemos tiekėju? Paprastai ne. Naudodami įrankį savo darbui esate diegiantysis subjektas. Aukštos rizikos tiekėjo prievolės kyla tik tuo atveju, jei patys kuriate ir tiekiate DI sistemą tam tikroms reguliuojamoms sritims - tai aptarta straipsnyje apie DI aktą IT įmonėms.

Ar ES DI aktas reikalauja, kad turėtume sertifikatus, specialų dokumentų rinkinį, fiksotą apmokymo trukmę, išorinį auditorių ar atskirą DI atsakovą? Ne, aktas nereikalauja konkrečios mokymų trukmės, sertifikatų, išorinio mokymų vedėjo, audito ar atskiro už DI atsakingo asmens. Tai gali būti naudinga, bet nėra privaloma.

Daugiau praktinių straipsnių apie ES DI akto atitiktį rasite visų straipsnių sąraše.

---

Šio straipsnio teisinė bazė: ES DI akto 4 straipsnis ir ES DI reguliavimo rėmiai.