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 DI įrankį, jūs jau esate dirbtinio intelekto (DI) diegiantysis subjektas pagal ES DI aktą (angl. AI Act) ir privalote užtikrinti darbuotojų DI raštingumą 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į, taikomas nuo 2025-02-02. Tai reiškia, kad kiekvienas darbuotojas, naudojantis kodo DI įrankį, turi suprasti, kaip įrankis veikia, kokios jo galimybės ir ribos, kokia rizika kyla ir kada DI rezultatu negalima pasitikėti aklai.

Laiko juosta, kurią verta žinoti:

Data	Kas įsigalioja	Aktualu kodo DI įrankiams
2025-02-02	DI raštingumas (4 str.) ir draudžiamos praktikos	Privaloma apmokyti programuotojus jau dabar
2025-08-02	Bendrosios paskirties DI (GPAI) taisyklės	Liečia įrankių tiekėjus, ne jus tiesiogiai
2026-08-02	Dauguma likusių prievolių	Skaidrumo ir rizikos valdymo reikalavimai

Kitaip tariant, jei laukiate „kol viskas įsigalios" – jau pavėlavote, nes raštingumo prievolė galioja daugiau nei metus. 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.

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ų.
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ą.
• 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 įmonei privalomi?

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:

• 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.
• Darbuotojų DI vadovas – praktiškos taisyklės programuotojui kasdieniam darbui.
• DI raštingumo mokymai su žinių patikra ir pažymėjimais – 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ą €290 kainą, pritaikytą jūsų įmonės atsakymams – nuo politikos iki mokymų su pažymėjimais (žr. pagrindinį puslapį). Jei pirma norite tik apmokyti komandą, yra ir nemokami DI raštingumo mokymai.

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ė užtikrinti DI raštingumą galioja nuo pirmo naudotojo.

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 „didelės rizikos" DI sistemos tiekėju? Paprastai ne. Naudodami įrankį savo darbui esate diegiantysis subjektas. Didelės 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.

Daugiau praktinių straipsnių apie ES DI akto atitiktį rasite visų straipsnių sąraše. Oficialų reglamento tekstą galima rasti ES teisės portale eur-lex.europa.eu (Reglamentas (ES) 2024/1689).