Pasakote agentui: „Atsakyk į klientų laiškus ir suderink susitikimus.“ Po valandos jis išsiunčia žinutę ne tam klientui.
Arba užduotis skamba taip: „Surask man bilietą iki 400 eurų ir nupirk.“ Agentas randa pasiūlymą, tačiau neteisingai supranta datą ir sumoka 370 eurų už skrydį kitai savaitei.
Anksčiau tokie scenarijai labiau priminė demonstraciją. Dabar technologinė jų dalis jau reali.
„Microsoft Copilot Studio“ dokumentacijoje tiesiai nurodoma, kad agentui galima suteikti įrankį siųsti laiškus per „Outlook“, keisti duomenis ir vykdyti kitus veiksmus. Autonominiai agentai gali būti paleidžiami įvykių ir atlikti užduotis nelaukdami kiekvieno naujo žmogaus nurodymo.
Mokėjimų pasaulyje riba peržengta dar aiškiau. 2026 m. birželį „Worldline“, ING ir „Mastercard“ paskelbė apie realioje produkcinėje aplinkoje Europoje atliktą DI agento inicijuotą ir autentifikuotą mokėjimą. „Visa“ ir „Mastercard“ tuo pat metu kuria atskirą infrastruktūrą agentų atliekamiems pirkimams.
Technologinis klausimas „ar agentas gali?“ todėl po truputį keičiamas kitu: kas nutinka, kai jis gali, bet padaro ne tai, ko norėjome?
Esmė
Esmė
DI agentai jau gali siųsti laiškus ir inicijuoti mokėjimus. Tačiau klaidos atveju atsakomybė niekur nedingsta – ji tenka žmonėms ir įmonėms.
- DI pats už žalą neatsakys AI sistema nėra fizinis ar juridinis asmuo. Ginčo atveju ieškoma žmogaus ar organizacijos, kuri sistemą sukūrė, pateikė, valdė, jai suteikė teises arba turėjo kontroliuoti riziką.
- Mokėjimuose svarbiausias klausimas – ar buvo jūsų sutikimas Pagal dabar galiojančias ES mokėjimų taisykles operacija laikoma autorizuota tik tada, kai mokėtojas davė sutikimą. DI agentų atveju sudėtingiausia tampa nustatyti, ką tiksliai žmogus buvo leidęs agentui padaryti.
- „Agentas suklydo“ įmonei nėra universalus pasiteisinimas Jei įmonė leidžia savo agentui savarankiškai siųsti klientams laiškus, tvarkyti duomenis ar vykdyti procesus, teisinės pasekmės paprastai neišnyksta vien todėl, kad konkretų veiksmą sugeneravo programinė sistema.
- ES dar neturi vieno „AI atsakomybės įstatymo“ AI aktas pirmiausia reguliuoja sistemų saugumą ir naudojimą, o specialiai civilinei AI atsakomybei skirta direktyva buvo atsiimta. Todėl žalą šiandien tenka dalyti pagal mokėjimų, sutarčių, duomenų apsaugos, produktų atsakomybės ir nacionalinės civilinės teisės taisykles.
Pirmoji taisyklė: DI agentas į teismą pats neis
Kasdienėje kalboje sakome, kad agentas „nusprendė“, „nupirko“ ar „parašė“. Teisiškai tai gali klaidinti.
DI sistema neturi savo banko sąskaitos, turto, civilinės atsakomybės draudimo ar juridinio asmens statuso vien todėl, kad geba veikti autonomiškai.
Europos Parlamentas dar ankstesnėse diskusijose apie civilinę AI atsakomybę aiškiai atmetė mintį, kad AI sistemai būtina suteikti atskirą teisinę asmenybę. Žala galiausiai siejama su žmonėmis ir organizacijomis, kurios sistemą kuria, pateikia, kontroliuoja ar naudoja.
Tai reiškia, kad frazė „čia ne mes, čia AI“ teisiškai nėra stebuklingas atsakomybės išjungimo mygtukas.
Neteisingas laiškas gali būti daugiau nei juokinga klaida
Lengviausias scenarijus – agentas klientui parašo nesąmonę. Įmonė atsiprašo, žmogus laišką ignoruoja ir istorija baigiasi.
Tačiau laiškas gali turėti ir realių teisinių pasekmių.
Agentas gali išsiųsti konfidencialią informaciją ne tam gavėjui. Pažadėti klientui nuolaidą. Patvirtinti užsakymą. Atšaukti rezervaciją. Per klaidą pateikti pasiūlymą, kurio įmonė nenorėjo teikti.
Lietuvos Civilinis kodeksas klasikinį atstovavimą sieja su fiziniais arba juridiniais asmenimis. DI programa nėra atskiras tokio tipo atstovas.
Tačiau įmonė gali naudoti automatizuotą sistemą savo valiai išreikšti ir komunikacijai vykdyti. Kilus ginčui nebūtinai užteks pasakyti, kad „agentas viršijo instrukciją“. Teisiškai gali būti svarbu, kokias teises įmonė sistemai suteikė, kaip jos veikla buvo pateikta trečiajam asmeniui, ar klaida buvo akivaizdi ir kokių saugiklių buvo galima pagrįstai tikėtis.
Kitaip tariant, kuo savarankiškesnį darbuotojo vaidmenį suteikiame programinei sistemai, tuo svarbesnis tampa klausimas, kas nustatė jos įgaliojimų ribas.
Jei agentas išsiuntė duomenis ne tam žmogui, atsiranda GDPR
Šioje vietoje atsakomybės grandinė dar aiškesnė.
Jeigu įmonės DI agentas klientų asmens duomenis išsiunčia neteisingam gavėjui, tai gali būti asmens duomenų saugumo pažeidimas.
Pagal BDAR 33 straipsnį pareiga įvertinti pažeidimą ir, kai reikia, apie jį pranešti priežiūros institucijai tenka duomenų valdytojui. Kai pažeidimas gali kelti riziką žmonių teisėms ir laisvėms, pranešimas, kai įmanoma, turi būti pateiktas per 72 valandas.
Reglamente nėra išimties „nebent laišką išsiuntė AI“.
Agentas tokiu atveju yra technologija, per kurią įvyko incidentas. Teisinės duomenų valdytojo pareigos lieka organizacijai.
Mokėjimuose svarbiausias žodis – „sutikimas“
Pinigų atveju situacija dar įdomesnė.
Dabar galiojanti ES Antroji mokėjimo paslaugų direktyva PSD2 nustato labai aiškų principą. Jos 64 straipsnyje numatyta, kad mokėjimo operacija laikoma autorizuota tik tuo atveju, jei mokėtojas davė sutikimą ją įvykdyti.
Jei tokio sutikimo nėra, operacija laikoma neautorizuota.
Pagal tos pačios direktyvos 73 straipsnį neautorizuotos operacijos atveju mokėjimo paslaugų teikėjas iš esmės turi grąžinti sumą nedelsdamas ir paprastai ne vėliau kaip iki kitos darbo dienos pabaigos, nors egzistuoja išimtys, susijusios su sukčiavimu ir vartotojo tyčiniu ar dideliu neatsargumu.
Su DI agentais iškyla naujas klausimas: ką reiškia „daviau sutikimą“?
„Nupirk bilietą iki 400 eurų“ – kiek tai platus leidimas?
Įsivaizduokime, kad agentui suteikiate leidimą:
„Nupirk skrydį į Romą spalio 15 dieną iki 400 eurų.“
Jis nupirka teisingą skrydį už 350 eurų. Čia problema nedidelė – agentas įvykdė jūsų nurodytą ketinimą.
Dabar pakeiskime vieną detalę. Agentas suklysta skaitydamas datą ir už 350 eurų nuperka skrydį spalio 25 dieną.
Banko požiūriu mokėjimo duomenys gali atrodyti visiškai teisėti. Naudotas jūsų agentui suteiktas mokėjimo įgaliojimas, pardavėjas tikras, suma neviršijo limito.
Tačiau jūs nenorėjote būtent šio pirkimo.
Čia atsiranda teisinė pilkoji zona, kurios dabartinės mokėjimų taisyklės buvo kuriamos ne DI agentams spręsti. Reikėtų nustatyti, ar vartotojo duotas sutikimas apėmė konkrečią operaciją ir kaip mokėjimo paslaugos sutartyje apibrėžtas agentui suteiktas leidimas.
Vien faktas, kad DI padarė loginę klaidą, automatiškai nereiškia, kad bankas mokėjimą privalės laikyti neautorizuotu.
Todėl mokėjimų bendrovės kuria ne „robotui kortelę“, o įrodymą apie žmogaus valią
Naujos agentinių mokėjimų sistemos kuriamos būtent aplink šią problemą.
„Mastercard Agent Pay“ savo architektūroje pabrėžia verifiable intent – galimybę įrodyti autentifikuotą vartotojo ketinimą ir aiškų sutikimą prieš agentui atliekant veiksmą.
„Visa Intelligent Commerce“ panašiai kalba apie vartotojo suteikiamus leidimus, mokėjimo kredencialų apsaugą ir kontrolę.
Praktiškai tai gali reikšti labai konkrečias ribas:
ne daugiau kaip 100 eurų vienam pirkimui;
ne daugiau kaip 500 eurų per mėnesį;
tik tam tikros kategorijos prekėms;
tik patvirtintiems pardavėjams;
pirmą kartą mokant naujam gavėjui – būtinas žmogaus patvirtinimas;
viršijus nustatytą sumą – agentas sustoja ir klausia.
Kuo tiksliau sistema gali parodyti, ką žmogus iš anksto leido, tuo lengviau vėliau nustatyti, ar agentas veikė pagal įgaliojimą, ar jį peržengė.
Keturi scenarijai – keturi skirtingi atsakymai
| Kas nutiko? | Kur pirmiausia krypsta atsakomybės klausimas? |
|---|---|
| Agentas pagal aiškiai nustatytas taisykles nupirko būtent tai, ką vartotojas jam leido | Į vartotoją ar įmonę, suteikusią leidimą – tai gali būti normaliai autorizuotas veiksmas |
| Agentas viršijo nustatytą 100 € limitą ir išleido 1 000 € | Į mokėjimo autorizavimo mechanizmą, agento platformą ir leidimų vykdymo sistemą – svarbu, kodėl techninis limitas nesuveikė |
| Trečiasis asmuo perėmė agento mokėjimo kredencialus ir sumokėjo be vartotojo sutikimo | Į neautorizuotų mokėjimų taisykles, banką ar kitą mokėjimo paslaugų teikėją bei saugumo grandinę |
| Agentas dėl modelio klaidos pasirinko netinkamą, bet techniškai leistiną prekę | Sudėtingiausias atvejis – lemia vartotojo suteikto įgaliojimo ribos, platformos sąlygos, sistemos konstrukcija ir nacionalinė sutarčių bei žalos atlyginimo teisė |
O jeigu problema yra pačioje DI sistemoje?
Tarkime, įmonė aiškiai nustatė: agentui draudžiama atlikti mokėjimus virš 500 eurų.
Programinė sistema turi techninį saugiklį. Tačiau dėl jos defekto agentas vis tiek perveda 5 000 eurų.
Tokiu atveju atsakomybės grandinė gali pasislinkti nuo naudotojo link programinės įrangos tiekėjo ar kito technologijos grandinės dalyvio.
ES jau priėmė naują Atsakomybės už gaminius direktyvą, kurioje aiškiai nustatyta, kad programinė įranga, įskaitant AI sistemas, gali būti laikoma produktu, o jos kūrėjas – gamintoju.
Naujasis režimas bus taikomas produktams, pateiktiems rinkai arba pradėtiems naudoti nuo 2026 m. gruodžio 9 dienos.
Tačiau yra labai svarbi riba: ši direktyva nėra universalus būdas atgauti bet kokį AI prarastą pinigą. Ji apima tam tikrą žalą, pavyzdžiui, žalą asmeniui, turtui ir kai kuriais atvejais duomenų sunaikinimą ar sugadinimą. Vien grynasis ekonominis nuostolis savaime į jos kompensuojamos žalos kategorijas nepatenka.
Tad jei agentas tiesiog blogai nupirko akcijų ir prarado 10 tūkst. eurų, atsakymo reikės ieškoti kitose sutartinės ar deliktinės atsakomybės taisyklėse.
AI aktas neatsako į paprastą klausimą „kas sumokės?“
2026 m. rugpjūtį didelė dalis ES AI akto nuostatų jau pradėta taikyti ir vykdyti.
Tačiau AI aktą lengva suprasti neteisingai. Tai pirmiausia reguliavimo, saugos, skaidrumo ir rizikos valdymo teisės aktas. Jis nustato, ką tam tikrų AI sistemų teikėjai ir naudotojai privalo daryti.
Jis nėra bendras civilinės atsakomybės kodeksas, kuriame būtų parašyta: „jeigu agentas padaro klaidą, 70 proc. sumoka kūrėjas, 30 proc. vartotojas“.
Be to, dalies didelės rizikos sistemų reikalavimų taikymas po 2026 m. priimto „AI Omnibus“ buvo nukeltas iki 2027–2028 metų.
Įprastas biuro agentas, siunčiantis laiškus ar perkeliantis susitikimus, vien dėl šių funkcijų apskritai nebūtinai patenka į AI akto didelės rizikos kategoriją.
ES bandė sukurti specialią AI atsakomybės direktyvą – ir jos atsisakė
Dar 2022 m. Europos Komisija pasiūlė vadinamąją AI Liability Directive, kuri turėjo palengvinti nukentėjusiems žmonėms įrodinėti žalą, sukeltą AI sistemų.
Tačiau ši iniciatyva netapo įstatymu.
EUR-Lex procedūros duomenimis, Komisija pasiūlymą oficialiai atsiėmė 2025 m. spalio 6 dieną.
Tai paliko šiandienos modelį: AI nėra atskira atsakomybės sala. Kiekvienas incidentas patenka į jau egzistuojančių teisės sričių kombinaciją.
Kas tada atsako praktiškai?
Patogiausia apie tai galvoti kaip apie keturių sluoksnių grandinę.
Naudotojas arba įmonė. Kas agentui suteikė prieigą prie el. pašto, CRM, banko ar pirkimų sistemos? Kokias ribas nustatė? Ar buvo protinga tokį veiksmą leisti be žmogaus patvirtinimo?
Agento platformos ar programinės įrangos tiekėjas. Ar sistema veikė taip, kaip buvo žadėta? Ar suveikė nustatyti limitai? Ar nebuvo programinio defekto arba klaidinančio produkto dizaino?
Mokėjimo paslaugų teikėjas. Ar konkreti operacija buvo tinkamai autorizuota ir autentifikuota? Ar tai buvo tikras vartotojo sutikimas, ar neteisėtas mokėjimas?
Trečioji šalis. Gal agentą apgavo sukčius, kenkėjiškas tinklalapis arba vadinamoji prompt injection ataka? Tada į grandinę gali įsitraukti ir nusikaltėlis, pardavėjas ar kita paslauga.
Kartais atsakingas bus vienas subjektas. Kartais nuostoliai ir atsakomybė gali būti dalijama tarp kelių grandinės dalyvių.
Didžiausia rizika – ne tai, kad AI gali klysti
Mes jau žinome, kad generatyviniai modeliai gali suklysti.
Naujas pavojus atsiranda tada, kai klaidingas atsakymas automatiškai paverčiamas veiksmu.
Jei pokalbių robotas parašo neteisingą IBAN, žmogus dar gali jį pastebėti.
Jei agentas pats nukopijuoja IBAN, atidaro mokėjimų sistemą, inicijuoja pavedimą ir gauna techninį leidimą, kelias nuo modelio klaidos iki realaus nuostolio sutrumpėja nuo kelių žmogaus sprendimų iki kelių API užklausų.
„Microsoft“ savo agentų priežiūros dokumentacijoje dėl to atskirai perspėja apie prompt injection atakas ir pabrėžia, kad net žmogaus patvirtinimo mechanizmo negalima laikyti absoliučiu saugikliu.
Todėl agentui nereikėtų duoti „visų raktų“
Praktiškai geriausia agentų atsakomybės politika prasideda dar prieš teisininkams įsitraukiant.
| Rizikinga konfigūracija | Saugesnė konfigūracija |
|---|---|
| Agentas gali siųsti laišką bet kam | Naujiems arba išoriniams gavėjams reikalingas patvirtinimas |
| Agentas turi pilną prieigą prie pagrindinės banko sąskaitos | Atskiras mokėjimo instrumentas su mažu limitu |
| „Nupirk, ką manai esant geriausia“ | Aiški produkto, sumos, pardavėjo ir datos specifikacija |
| Vienas bendras administratoriaus prisijungimas | Atskira agento tapatybė ir tik būtinos teisės |
| Nėra veiksmų istorijos | Išsamūs audito žurnalai: kas inicijavo, ką agentas nusprendė ir kokį veiksmą atliko |
| Kiekvienas veiksmas atliekamas automatiškai | Didelės rizikos veiksmams paliekamas žmogaus patvirtinimas |
Tai klasikinis mažiausių privilegijų principas, tik dabar jis taikomas ne darbuotojo paskyrai, o programai, gebančiai pačiai priimti tarpinius sprendimus.
Ateities ginčuose svarbiausias klausimas greičiausiai bus: kas turėjo kontrolę?
DI agentų autonomija sukuria įspūdį, kad tarp žmogaus ir rezultato atsirado naujas nepriklausomas veikėjas.
Teisė kol kas į tai žiūri kitaip.
Kažkas pasirinko agentą. Kažkas prijungė „Outlook“. Kažkas suteikė mokėjimo kredencialą. Kažkas nustatė 500 eurų limitą – arba jo nenustatė. Kažkas sukūrė programą, kuri turėjo to limito laikytis.
Todėl po klaidos klausimas greičiausiai skambės ne „kodėl AI taip nusprendė?“, o „kas kontroliavo riziką ir kurioje grandinės vietoje kontrolė nesuveikė?“
Kol agentai tik rašė tekstą, jų klaidos daugiausia kainavo laiką ir reputaciją.
Kai jie gauna teisę paspausti „Send“ ir „Pay“, tas pats neteisingas modelio atsakymas gali tapti sutartimi, duomenų incidentu arba tikrais pinigais.
Ir būtent todėl svarbiausia agentų eros funkcija gali būti ne dar didesnė autonomija, o labai tiksliai apibrėžta teisė sustoti prieš padarant tai, ko jau nebegalima atšaukti.
Komentarai