Per pastaruosius metus žodis „agentas“ atsirado beveik kiekvieno AI produkto aprašyme. Copilot turi agentus, Claude turi agentus, ChatGPT turi agentus. Įmonės vadovui iš to sunku suprasti, kas pasikeitė: ar tai tas pats pokalbių langas su nauju pavadinimu, ar iš tikrųjų kažkas kita.
Skirtumas yra esminis, ir jis svarbus ne dėl terminologijos, o dėl atsakomybės. Asistentas, kuris neteisingai atsakė, sukelia nepatogumą – žmogus perskaito, pastebi klaidą, pataiso. Agentas, kuris neteisingai suprato užduotį, gali išsiųsti laišką klientui, sukurti sąskaitą apskaitoje ar uždaryti helpdesk užklausą. Todėl agentams reikia kitokio dizaino, kitokių ribų ir kitokios priežiūros.
Šiame straipsnyje paaiškiname skirtumą, aprašome, kokios kontrolės priemonės būtinos, ir pateikiame scenarijus, kurie mūsų praktikoje jau veikia Lietuvos įmonėse – ne eksperimentuose, o kasdieniame darbe.
Asistentas atsako, agentas veikia
Asistentas yra pokalbis. Jūs užduodate klausimą ar duodate tekstą, jis atsako. Jis gali būti labai geras: apibendrinti sutartį, parašyti laiško juodraštį, paaiškinti Excel formulę. Bet rezultatas lieka pokalbio lange, o kas su juo daryti – sprendžia žmogus. Asistentas neturi prieigos prie jūsų sistemų, arba turi tik skaitymo prieigą.
Agentas turi tikslą ir įrankius. Jam duodama užduotis – „apdorok šią kliento užklausą“ – ir prieiga prie sistemų: CRM, apskaitos, pašto, kalendoriaus, dokumentų. Jis pats sprendžia, kokių žingsnių reikia: perskaityti laišką, patikrinti klientą CRM, surasti kainoraštį, parengti atsakymą, sukurti įrašą sistemoje. Tada atlieka tuos žingsnius vieną po kito, tikrindamas rezultatą ir, jei reikia, keisdamas planą.
Trumpai: asistentas yra įrankis žmogaus rankose, agentas yra darbuotojas su aprašytomis pareigomis ir prieigomis. Ir kaip darbuotojui, jam reikia pareigybės aprašo, prieigų tvarkos ir priežiūros.
Ribos: ką agentas gali ir ko negali
Pirma taisyklė, kurią taikome kiekvienam agentui: jis turi tik tas prieigas, kurių reikia užduočiai, ir nė vienos daugiau. Agentas, kuris apdoroja gaunamas užklausas, turi skaityti paštą ir rašyti į CRM. Jis neturi teisės trinti įrašų, keisti kainų ar siųsti laiškų už įmonės ribų, jei tai nėra jo užduotis.
Tai techniškai sprendžiama per įrankių aprašus ir prieigų raktus: kiekvienas agento įrankis yra atskirai aprašyta funkcija su aiškiomis teisėmis, dažniausiai per MCP (Model Context Protocol) serverį, kuris pats riboja, kokias operacijas leidžia. Agentas negali „sugalvoti“ naujos operacijos – jis renkasi tik iš to, kas jam duota.
Antra taisyklė: agentas turi aiškias sustojimo sąlygas. Jei užklausa neatitinka nė vieno žinomo scenarijaus, jei klientas nerastas sistemoje, jei suma viršija nustatytą ribą – agentas sustoja ir perduoda žmogui, užuot bandęs „kaip nors išspręsti“. Geras agentas yra tas, kuris dažnai sako „nežinau, perduodu“, o ne tas, kuris visada randa atsakymą.
Žurnalai ir žmogaus patvirtinimas
Kiekvienas agento veiksmas turi būti užfiksuotas: ką perskaitė, kokį sprendimą priėmė ir kodėl, kokį įrankį iškvietė, koks buvo rezultatas. Be to neįmanoma nei tirti klaidų, nei įrodyti auditoriui, kas įvyko. TIS2 ir DORA reikalavimų kontekste tai nėra pasirinkimas – automatizuotas procesas, kuris veikia su klientų duomenimis, turi turėti pėdsaką.
Žmogaus patvirtinimas (human-in-the-loop) yra antras sluoksnis. Praktikoje taikome tris lygius:
- Agentas veikia savarankiškai – veiksmai yra grįžtami ir mažos rizikos, pavyzdžiui, užklausos priskyrimas kategorijai ar juodraščio parengimas.
- Agentas parengia, žmogus patvirtina – veiksmas negrįžtamas arba matomas išorėje: laiškas klientui, sąskaita, užsakymas tiekėjui.
- Agentas tik siūlo – jautrios sritys, kur sprendimą priima žmogus, o agentas pateikia informaciją ir rekomendaciją.
Pradėti reikia nuo antro ir trečio lygių. Pirmas lygis atsiranda tada, kai per kelis mėnesius žurnalai parodo, kad agentas konkrečioje užduotyje klysta rečiau nei žmogus. Tai yra matuojamas sprendimas, o ne tikėjimo klausimas.
Scenarijai, kurie jau veikia
Žemiau – penki scenarijai iš mūsų praktikos. Nė vienas nėra futuristinis; visi remiasi dabar prieinamomis platformomis.
Gaunamų užklausų apdorojimas
Įmonė gauna užklausas į bendrą paštą ir per svetainės formą. Agentas perskaito kiekvieną, nustato tipą (kainos užklausa, techninis klausimas, skundas, spamas), patikrina, ar siuntėjas yra esamas klientas CRM, parengia atsakymo juodraštį pagal žinių bazę ir priskiria atsakingam darbuotojui. Darbuotojas ryte mato ne 40 laiškų, o 40 sutvarkytų užklausų su juodraščiais. Jis peržiūri, pataiso ir išsiunčia. Apdorojimo laikas iš valandų virsta minutėmis.
Gaunamų sąskaitų registravimas
Tiekėjų sąskaitos ateina paštu kaip PDF. Agentas ištraukia duomenis, sulygina su užsakymu sistemoje, patikrina tiekėjo rekvizitus ir sukuria įrašą apskaitoje su būsena „laukia patvirtinimo“. Jei suma ar rekvizitai nesutampa su užsakymu, agentas sustoja ir pažymi neatitikimą. Buhalteris patvirtina vienu veiksmu arba tiria neatitikimą. Rekvizitų tikrinimas čia yra ir saugumo priemonė – pakeistos sąskaitos sukčiavimo atvejai atpažįstami iš karto.
Pirmos linijos helpdesk
Darbuotojas rašo į IT pagalbą: „neveikia VPN“. Agentas patikrina, ar vartotojo paskyra aktyvi, ar nėra žinomų sutrikimų, ar įrenginys atitinka reikalavimus, ir pateikia žinomą sprendimą arba pats atlieka leistiną veiksmą – pavyzdžiui, atstato slaptažodį po tapatybės patvirtinimo. Jei nepadeda, užklausa su visa surinkta informacija keliauja inžinieriui. Tai nekeičia IT priežiūros komandos, bet leidžia jai dirbti su problemomis, o ne su pasikartojančiais klausimais.
Susitikimų parengimas ir sekimas
Prieš susitikimą su klientu agentas surenka: paskutinius laiškus, atvirus pasiūlymus CRM, neapmokėtas sąskaitas, praėjusio susitikimo užrašus – ir parengia vieno puslapio santrauką. Po susitikimo iš įrašo ar užrašų sukuria veiksmų sąrašą, priskiria užduotis ir sukuria CRM įrašą. Žmogus tik peržiūri ir patvirtina. Vadovui, kuris turi penkis susitikimus per dieną, tai reiškia, kad į kiekvieną ateina pasiruošęs.
Sutarčių peržiūra pagal įmonės taisykles
Teisės ar pirkimų skyrius gauna tiekėjo sutartį. Agentas palygina ją su įmonės standartinėmis sąlygomis, pažymi nukrypimus – atsakomybės ribojimą, mokėjimo terminus, duomenų apsaugos nuostatas – ir parengia pastabų sąrašą. Sprendimą priima žmogus, bet jis nebeskaito 60 puslapių ieškodamas, kas pasikeitė.
Kurioje platformoje kurti
Agentus galima kurti visose trijose pagrindinėse platformose, ir pasirinkimas priklauso nuo to, kur gyvena jūsų duomenys ir procesai.
Jei įmonė dirba Microsoft 365 aplinkoje, natūralus kelias yra Copilot Studio agentai: jie mato SharePoint, Teams, Outlook ir per Power Automate jungiasi prie kitų sistemų. Tokius agentus aprašome Microsoft 365 Copilot agentų puslapyje. Jei reikia sudėtingesnės logikos, ilgų dokumentų apdorojimo ar agento, kuris veikia jūsų infrastruktūroje, žiūrime į Claude agentus su Agent SDK ir MCP. Jei įmonė jau naudoja OpenAI ekosistemą arba reikia platesnio įrankių rinkinio, ChatGPT agentai su Agents SDK yra trečias variantas.
Praktiškai integracijas kuriame per MCP, kad agentą būtų galima perkelti iš vienos platformos į kitą nekeičiant ryšių su jūsų sistemomis.
Nuo ko pradėti
Agentų diegimas nėra didelis projektas, jei pradedama teisingai – nuo vieno proceso, ne nuo „AI transformacijos“.
- Išsirinkite vieną procesą, kuris kartojasi kasdien, turi aiškias taisykles ir kurio klaidos yra grįžtamos. Gaunamų užklausų rūšiavimas yra geras pirmas kandidatas.
- Aprašykite jį taip, kaip aprašytumėte naujam darbuotojui: kokia informacija ateina, kokie sprendimai priimami, kada kreipiamasi į vadovą.
- Nustatykite agento prieigas pagal minimalų poreikį ir patvirtinimo lygį kiekvienam veiksmui.
- Paleiskite lygiagrečiai su žmogumi 4–6 savaitėms: agentas rengia, žmogus tikrina. Žurnalai parodys tikslumą.
- Tik tada plėskite savarankiškumą ar pereikite prie antro proceso.
Jei norite, kad pirmą agentą suprojektuotume ir įdiegtume kartu, pradedame nuo proceso aprašymo ir rizikų įvertinimo, o ne nuo platformos pasirinkimo. Platforma yra paskutinis klausimas, ne pirmas.
