Viimase aasta jooksul on sõna „agent“ ilmunud peaaegu iga AI-toote kirjeldusse. Copilotil on agendid, Claude’il on agendid, ChatGPT-l on agendid. Ettevõtte juhil on raske aru saada, mis on muutunud: kas see on sama vestlusaken uue nimega või midagi tõeliselt teistsugust?
Erinevus on põhimõtteline ja see ei puuduta terminoloogiat, vaid vastutust. Assistent, kes vastab valesti, põhjustab ebamugavust: inimene loeb vastuse, märkab vea ja parandab selle. Agent, kes ülesandest valesti aru saab, võib saata kliendile e-kirja, luua raamatupidamissüsteemis arve või sulgeda kasutajatoe pöördumise. Seetõttu vajavad agendid teistsugust ülesehitust, teistsuguseid piiranguid ja teistsugust järelevalvet.
Selles artiklis selgitame erinevust, kirjeldame, millised kontrollid on hädavajalikud, ja toome stsenaariumid, mis töötavad juba meie toetatavates ettevõtetes – mitte katsetustes, vaid igapäevatöös.
Assistent vastab, agent tegutseb
Assistent on vestlus. Te esitate küsimuse või annate teksti ja see vastab. See võib olla väga hea: võtta kokku leping, kirjutada e-kirja mustand, selgitada Exceli valemit. Kuid tulemus jääb vestlusaknasse ja selle üle, mida sellega edasi teha, otsustab inimene. Assistendil ei ole juurdepääsu teie süsteemidele või on ainult lugemisõigus.
Agendil on eesmärk ja tööriistad. Talle antakse ülesanne, näiteks „töötle see kliendipäring“, ja juurdepääs süsteemidele: CRM, raamatupidamine, e-post, kalender, dokumendid. Ta otsustab ise, millised sammud on vajalikud: lugeda e-kiri, kontrollida klienti CRM-is, leida hinnakiri, koostada vastus, luua süsteemis kirje. Seejärel täidab ta need sammud üksteise järel, kontrollib tulemust ja vajaduse korral muudab plaani.
Lühidalt: assistent on tööriist inimese käes, agent on töötaja kindlate kohustuste ja juurdepääsuõigustega. Ja nagu töötaja, vajab ka agent ametijuhendit, juurdepääsupoliitikat ja järelevalvet.
Piirangud: mida agent tohib ja mida mitte
Esimene reegel, mida iga agendi puhul rakendame: tal on ainult see juurdepääs, mida ülesanne nõuab, ja mitte midagi enamat. Sissetulevaid päringuid töötlev agent peab lugema postkasti ja kirjutama CRM-i. Tal ei ole õigust kirjeid kustutada, hindu muuta ega ettevõtte välistele adressaatidele e-kirju saata, kui see ei ole tema ülesanne.
Tehniliselt lahendatakse see tööriistade kirjelduste ja juurdepääsuvõtmetega: iga agendi tööriist on eraldi kirjeldatud funktsioon selgete õigustega, enamasti MCP (Model Context Protocol) serveri kaudu, mis ise piirab, milliseid toiminguid see lubab. Agent ei saa uut toimingut „välja mõelda“, ta valib ainult nende hulgast, mis talle on antud.
Teine reegel: agendil on selged peatumistingimused. Kui päring ei vasta ühelegi tuntud stsenaariumile, kui klienti süsteemist ei leita või kui summa ületab kehtestatud piiri, peatub agent ja annab asja üle inimesele, selle asemel et püüda seda „kuidagi lahendada“. Hea agent on selline, kes ütleb sageli „ei tea, annan üle“, mitte selline, kes leiab alati vastuse.
Logid ja inimese kinnitus
Iga agendi tegevus tuleb jäädvustada: mida ta luges, millise otsuse ta tegi ja miks, millist tööriista ta kasutas ja mis oli tulemus. Ilma selleta ei saa vigu uurida ega audiitorile tõestada, mis juhtus. NIS2 ja DORA nõuete kontekstis ei ole see valikuline: kliendiandmetega töötav automatiseeritud protsess peab jätma jälje.
Inimese kinnitus (human-in-the-loop) on teine kiht. Praktikas rakendame kolme taset:
- Agent tegutseb iseseisvalt: tegevused on tagasipööratavad ja väikese riskiga, näiteks päringu kategoriseerimine või mustandi koostamine.
- Agent valmistab ette, inimene kinnitab: tegevus on pöördumatu või väljapoole nähtav, näiteks e-kiri kliendile, arve või tellimus tarnijale.
- Agent ainult soovitab: tundlikud valdkonnad, kus otsuse teeb inimene ning agent annab teavet ja soovituse.
Alustada tuleks teisest ja kolmandast tasemest. Esimene tase tekib siis, kui logid näitavad mitme kuu jooksul, et agent teeb konkreetses ülesandes vähem vigu kui inimene. See on mõõdetav otsus, mitte usuasi.
Stsenaariumid, mis juba töötavad
Allpool on viis stsenaariumi meie praktikast. Ükski neist ei ole futuristlik; kõik tuginevad platvormidele, mis on täna kättesaadavad.
Sissetulevate päringute töötlemine
Ettevõte saab päringuid ühisesse postkasti ja veebivormi kaudu. Agent loeb iga päringu, määrab selle tüübi (hinnapäring, tehniline küsimus, kaebus, rämpspost), kontrollib CRM-ist, kas saatja on olemasolev klient, koostab teadmusbaasi põhjal vastuse mustandi ja määrab selle vastutavale töötajale. Hommikul näeb töötaja mitte 40 e-kirja, vaid 40 sorteeritud päringut koos mustanditega. Ta vaatab need üle, parandab ja saadab. Töötlemisaeg väheneb tundidest minutitele.
Sissetulevate arvete registreerimine
Tarnijate arved saabuvad e-postiga PDF-failidena. Agent loeb andmed välja, võrdleb neid süsteemis oleva ostutellimusega, kontrollib tarnija andmeid ja loob raamatupidamissüsteemis kirje staatusega „ootab kinnitust“. Kui summa või andmed tellimusega ei klapi, peatub agent ja märgib lahknevuse. Raamatupidaja kinnitab ühe toiminguga või uurib lahknevust. Andmete kontrollimine on siin ka turvameede: võltsitud arvega pettus tuvastatakse kohe.
Esimese liini kasutajatugi
Töötaja kirjutab IT-kasutajatoele: „VPN ei tööta“. Agent kontrollib, kas kasutajakonto on aktiivne, kas on teada rikkeid ja kas seade vastab nõuetele, ning pakub tuntud lahenduse või teeb lubatud toimingu ise, näiteks lähtestab parooli pärast isiku tuvastamist. Kui see ei aita, läheb pöördumine kõigi kogutud andmetega insenerile. See ei asenda IT-hoolduse meeskonda, kuid võimaldab tal tegeleda päris probleemidega korduvate küsimuste asemel.
Kohtumise ettevalmistus ja järeltöö
Enne kliendiga kohtumist kogub agent kokku viimased e-kirjad, CRM-i avatud pakkumised, tasumata arved ja eelmise kohtumise märkmed ning koostab ühelehelise kokkuvõtte. Pärast kohtumist koostab ta salvestise või märkmete põhjal tegevuste nimekirja, määrab ülesanded ja loob CRM-i kirje. Inimene ainult vaatab üle ja kinnitab. Juhile, kellel on päevas viis kohtumist, tähendab see igale neist ettevalmistunult minekut.
Lepingu läbivaatus ettevõtte reeglite alusel
Juriidiline osakond või hankeosakond saab tarnija lepingu. Agent võrdleb seda ettevõtte tüüptingimustega, märgib kõrvalekalded, näiteks vastutuse piiramise, maksetingimused ja andmekaitseklauslid, ning koostab märkuste nimekirja. Otsuse teeb inimene, kuid ta ei loe enam 60 lehekülge, otsides, mis on muutunud.
Millisele platvormile ehitada
Agente saab ehitada kõigil kolmel põhiplatvormil ja valik sõltub sellest, kus teie andmed ja protsessid asuvad.
Kui ettevõte töötab Microsoft 365 keskkonnas, on loomulik tee Copilot Studio agendid: need näevad SharePointi, Teamsi ja Outlooki ning ühenduvad teiste süsteemidega Power Automate’i kaudu. Selliseid agente kirjeldame lehel Microsoft 365 Copilot agendid. Kui vajate keerukamat loogikat, pikkade dokumentide töötlemist või agenti, mis töötab teie enda taristus, vaatame Claude’i agente koos Agent SDK ja MCP-ga. Kui ettevõte kasutab juba OpenAI ökosüsteemi või vajab laiemat tööriistakomplekti, on kolmas valik ChatGPT agendid koos Agents SDK-ga.
Praktikas ehitame integratsioonid MCP kaudu, et agenti saaks ühelt platvormilt teisele viia, muutmata ühendusi teie süsteemidega.
Kust alustada
Agentide juurutamine ei ole suur projekt, kui alustada õigesti: ühe protsessiga, mitte „AI-transformatsiooniga“.
- Valige üks protsess, mis kordub iga päev, millel on selged reeglid ja mille vead on tagasipööratavad. Hea esimene kandidaat on sissetulevate päringute sorteerimine.
- Kirjeldage see nii, nagu kirjeldaksite uuele töötajale: milline teave saabub, milliseid otsuseid tehakse, millal pöörduda juhi poole.
- Seadke agendi juurdepääs vajalikule miinimumile ja määrake iga tegevuse jaoks kinnitustase.
- Käitage seda 4–6 nädalat paralleelselt inimesega: agent valmistab ette, inimene kontrollib. Logid näitavad täpsust.
- Alles seejärel laiendage agendi iseseisvust või liikuge teise protsessi juurde.
Kui soovite, et kujundaksime ja juurutaksime esimese agendi koos teiega, alustame protsessi kirjeldusest ja riskihindamisest, mitte platvormi valikust. Platvorm on viimane küsimus, mitte esimene.
