Pēdējā gada laikā vārds „aģents” ir parādījies gandrīz katra AI produkta aprakstā. Copilot ir aģenti, Claude ir aģenti, ChatGPT ir aģenti. Uzņēmuma vadītājam ir grūti saprast, kas mainījies: vai tas ir tas pats tērzēšanas logs ar jaunu nosaukumu, vai tomēr kaut kas principiāli cits?
Atšķirība ir būtiska, un tā svarīga nevis terminoloģijas, bet atbildības dēļ. Asistents, kas atbild nepareizi, rada neērtības: cilvēks izlasa atbildi, pamana kļūdu un izlabo to. Aģents, kas pārprot uzdevumu, var nosūtīt klientam e-pastu, izveidot rēķinu grāmatvedības sistēmā vai aizvērt palīdzības dienesta pieteikumu. Tāpēc aģentiem vajadzīga cita arhitektūra, citi ierobežojumi un cita uzraudzība.
Šajā rakstā mēs izskaidrojam atšķirību, aprakstām, kāda kontrole ir būtiska, un sniedzam scenārijus, kas jau darbojas uzņēmumos, kurus apkalpojam: nevis eksperimentos, bet ikdienas darbā.
Asistents atbild, aģents rīkojas
Asistents ir saruna. Jūs uzdodat jautājumu vai iesniedzat tekstu, un tas atbild. Tas var būt ļoti noderīgs: apkopot līgumu, uzrakstīt e-pasta melnrakstu, izskaidrot Excel formulu. Taču rezultāts paliek tērzēšanas logā, un par to, ko ar to darīt, lemj cilvēks. Asistentam nav piekļuves jūsu sistēmām vai ir tikai lasīšanas piekļuve.
Aģentam ir mērķis un rīki. Tam dod uzdevumu, piemēram, „apstrādāt šo klienta pieprasījumu”, un piekļuvi sistēmām: CRM, grāmatvedībai, e-pastam, kalendāram, dokumentiem. Tas pats izlemj, kādi soļi vajadzīgi: izlasīt e-pastu, pārbaudīt klientu CRM, atrast cenrādi, sagatavot atbildi, izveidot ierakstu sistēmā. Pēc tam tas šos soļus izpilda secīgi, pārbauda rezultātu un, ja vajag, maina plānu.
Īsi sakot: asistents ir rīks cilvēka rokās, aģents ir darbinieks ar noteiktiem pienākumiem un piekļuves tiesībām. Un tāpat kā darbiniekam, tam vajadzīgs amata apraksts, piekļuves politika un uzraudzība.
Ierobežojumi: ko aģents drīkst un ko nedrīkst
Pirmais noteikums, ko piemērojam katram aģentam: tam ir tikai tā piekļuve, ko prasa uzdevums, un nekas vairāk. Aģentam, kas apstrādā ienākošos pieprasījumus, jālasa pasts un jāraksta CRM. Tam nav tiesību dzēst ierakstus, mainīt cenas vai sūtīt e-pastus ārpus uzņēmuma, ja vien tas nav viņa uzdevums.
Tehniski tas tiek risināts ar rīku aprakstiem un piekļuves atslēgām: katrs aģenta rīks ir atsevišķi aprakstīta funkcija ar skaidrām tiesībām, visbiežāk caur MCP (Model Context Protocol) serveri, kas pats ierobežo, kuras darbības tiek atļautas. Aģents nevar „izdomāt” jaunu darbību; tas izvēlas tikai no tā, kas tam dots.
Otrais noteikums: aģentam ir skaidri apstāšanās nosacījumi. Ja pieprasījums neatbilst nevienam zināmam scenārijam, ja klients sistēmā nav atrasts, ja summa pārsniedz noteikto limitu, aģents apstājas un nodod lietu cilvēkam, nevis mēģina „kaut kā atrisināt”. Labs aģents ir tāds, kas bieži saka „nezinu, nododu tālāk”, nevis tāds, kas vienmēr atrod atbildi.
Žurnāli un cilvēka apstiprinājums
Katra aģenta darbība ir jāfiksē: ko tas izlasīja, kādu lēmumu pieņēma un kāpēc, kuru rīku izsauca, kāds bija rezultāts. Bez tā nav iespējams izmeklēt kļūdas vai pierādīt revidentam, kas noticis. NIS2 un DORA prasību kontekstā tas nav izvēles jautājums: automatizētam procesam, kas strādā ar klientu datiem, jāatstāj pēdas.
Cilvēka apstiprinājums (human-in-the-loop) ir otrais slānis. Praksē mēs izmantojam trīs līmeņus:
- Aģents rīkojas patstāvīgi: darbības ir atceļamas un zema riska, piemēram, pieprasījuma piešķiršana kategorijai vai melnraksta sagatavošana.
- Aģents sagatavo, cilvēks apstiprina: darbība ir neatgriezeniska vai ārēji redzama, piemēram, e-pasts klientam, rēķins vai pasūtījums piegādātājam.
- Aģents tikai iesaka: jutīgas jomas, kur lēmumu pieņem cilvēks, bet aģents sniedz informāciju un ieteikumu.
Jāsāk ar otro un trešo līmeni. Pirmais līmenis parādās tad, kad vairāku mēnešu laikā žurnāli rāda, ka konkrētā uzdevumā aģents kļūdās retāk nekā cilvēks. Tas ir izmērāms lēmums, nevis ticības jautājums.
Scenāriji, kas jau darbojas
Zemāk ir pieci scenāriji no mūsu prakses. Neviens no tiem nav futūristisks; visi balstās uz platformām, kas ir pieejamas jau šodien.
Ienākošo pieprasījumu apstrāde
Uzņēmums saņem pieprasījumus uz kopīgu pastkasti un caur tīmekļa vietnes veidlapu. Aģents izlasa katru, nosaka veidu (cenas pieprasījums, tehnisks jautājums, sūdzība, surogātpasts), pārbauda CRM, vai sūtītājs ir esošs klients, sagatavo atbildes melnrakstu no zināšanu bāzes un piešķir to atbildīgajam darbiniekam. No rīta darbinieks redz nevis 40 e-pastus, bet 40 sakārtotus pieprasījumus ar melnrakstiem. Viņš tos pārskata, izlabo un nosūta. Apstrādes laiks no stundām samazinās līdz minūtēm.
Ienākošo rēķinu reģistrēšana
Piegādātāju rēķini pienāk pa e-pastu kā PDF. Aģents izvelk datus, salīdzina tos ar pirkuma pasūtījumu sistēmā, pārbauda piegādātāja rekvizītus un izveido ierakstu grāmatvedības sistēmā ar statusu „gaida apstiprinājumu”. Ja summa vai rekvizīti neatbilst pasūtījumam, aģents apstājas un atzīmē neatbilstību. Grāmatvedis apstiprina ar vienu darbību vai izmeklē neatbilstību. Rekvizītu pārbaude šeit ir arī drošības pasākums: viltotu rēķinu krāpšana tiek atpazīta uzreiz.
Pirmās līnijas palīdzības dienests
Darbinieks raksta IT atbalstam: „VPN nedarbojas”. Aģents pārbauda, vai lietotāja konts ir aktīvs, vai ir zināmi pārtraukumi un vai ierīce atbilst prasībām, un sniedz zināmu risinājumu vai pats veic atļautu darbību, piemēram, atiestata paroli pēc identitātes pārbaudes. Ja tas nepalīdz, pieteikums ar visu savākto informāciju nonāk pie inženiera. Tas neaizstāj IT apkopes komandu, bet ļauj tai strādāt pie reālām problēmām, nevis atkārtotiem jautājumiem.
Sagatavošanās sapulcei un turpmākās darbības
Pirms sapulces ar klientu aģents savāc jaunākos e-pastus, atvērtos piedāvājumus CRM, neapmaksātos rēķinus un piezīmes no iepriekšējās sapulces un sagatavo vienas lappuses kopsavilkumu. Pēc sapulces tas no ieraksta vai piezīmēm izveido darbību sarakstu, sadala uzdevumus un izveido ierakstu CRM. Cilvēks tikai pārskata un apstiprina. Vadītājam, kuram dienā ir piecas sapulces, tas nozīmē ierasties katrā no tām sagatavotam.
Līgumu pārskatīšana pēc uzņēmuma noteikumiem
Juridiskā vai iepirkumu nodaļa saņem piegādātāja līgumu. Aģents salīdzina to ar uzņēmuma standarta noteikumiem, atzīmē atšķirības, piemēram, atbildības ierobežojumu, maksājumu noteikumus un datu aizsardzības klauzulas, un sagatavo komentāru sarakstu. Lēmumu pieņem cilvēks, taču viņam vairs nav jālasa 60 lappuses, meklējot, kas mainīts.
Uz kuras platformas veidot
Aģentus var veidot uz visām trim galvenajām platformām, un izvēle ir atkarīga no tā, kur atrodas jūsu dati un procesi.
Ja uzņēmums strādā Microsoft 365 vidē, dabisks ceļš ir Copilot Studio aģenti: tie redz SharePoint, Teams un Outlook un ar Power Automate palīdzību savienojas ar citām sistēmām. Šādus aģentus aprakstām lapā Microsoft 365 Copilot aģenti. Ja vajadzīga sarežģītāka loģika, garu dokumentu apstrāde vai aģents, kas darbojas jūsu pašu infrastruktūrā, izskatām Claude aģentus ar Agent SDK un MCP. Ja uzņēmums jau izmanto OpenAI ekosistēmu vai tam vajadzīgs plašāks rīku kopums, trešā iespēja ir ChatGPT aģenti ar Agents SDK.
Praksē integrācijas veidojam caur MCP, lai aģentu varētu pārnest no vienas platformas uz citu, nemainot savienojumus ar jūsu sistēmām.
No kā sākt
Aģentu ieviešana nav liels projekts, ja sākat pareizi: ar vienu procesu, nevis ar „AI transformāciju”.
- Izvēlieties vienu procesu, kas atkārtojas katru dienu, kam ir skaidri noteikumi un kura kļūdas ir atceļamas. Ienākošo pieprasījumu šķirošana ir labs pirmais kandidāts.
- Aprakstiet to tā, kā aprakstītu jaunam darbiniekam: kāda informācija pienāk, kādi lēmumi tiek pieņemti, kad vērsties pie vadītāja.
- Iestatiet aģenta piekļuvi uz nepieciešamo minimumu un katrai darbībai nosakiet apstiprinājuma līmeni.
- Darbiniet to paralēli ar cilvēku 4 līdz 6 nedēļas: aģents sagatavo, cilvēks pārbauda. Žurnāli parādīs precizitāti.
- Tikai tad paplašiniet tā autonomiju vai pārejiet uz otru procesu.
Ja vēlaties, lai mēs kopā ar jums izstrādātu un ieviestu pirmo aģentu, sākam ar procesa aprakstu un risku novērtēšanu, nevis ar platformas izvēli. Platforma ir pēdējais jautājums, nevis pirmais.
