AI agenti v poslovnem procesu: kaj smejo in kaj ne

Kaj je AI agent v poslovnem procesu#

AI agent v poslovnem procesu je programska komponenta, ki na podlagi navodil, podatkov in dovoljenih dostopov do vaših sistemov samostojno izvede del naloge. Prebere dokument, poišče ustrezen podatek, pripravi predlog odgovora ali sproži naslednji korak v delovnem toku. Od klasične avtomatizacije se razlikuje po tem, da se znotraj vnaprej določenih meja tudi odloča, ne le izvaja fiksnega zaporedja korakov. Za direktorja ali vodjo oddelka je to pomembna razlika, saj pomeni, da mora biti pred uvedbo jasno zapisano, kaj agent sme oceniti sam in kje se mora ustaviti.

V praksi agent pogosto deluje znotraj več sistemov naenkrat. Z uporabo semantičnega iskanja (RAG) poišče relevantne vire v interni dokumentaciji, iz dokumentov ekstrahira podatke in jih prek API-ja vnese v CRM ali ERP sistem. Meje delovanja - kateri viri so dostopni, katera dejanja sme sprožiti sam in kje potrebuje potrditev - se določijo skupaj z naročnikom, preden agent dobi dostop do produkcijskih podatkov. Ta korak je enako pomemben kot sam razvoj agenta, saj brez jasno zapisanih meja tveganje nosi celotna organizacija, ne le tehnična ekipa.

Za odločevalca to pomeni, da uvedba AI agenta ni le izbira orodja, temveč projekt, ki zahteva enako pripravo kot integracija novega informacijskega sistema. Treba je opredeliti, kateri oddelki so vpleteni, kateri obstoječi sistemi se povezujejo prek API-jev in kdo znotraj organizacije potrjuje izjeme. Šele ko so ta vprašanja odgovorjena, ima smisel govoriti o tehnični zasnovi agenta. Brez te priprave se projekt pogosto zaustavi na pol poti, ko se izkaže, da meje odgovornosti niso bile jasne od začetka.

Primer takega projekta je Kwizmo, kjer razvijamo AI programsko rešitev za uporabo umetne inteligence nad internimi podatki, dokumentacijo in poslovnimi procesi naročnika. Vključuje AI agente, semantično iskanje, obdelavo dokumentov, integracije z obstoječimi sistemi in avtomatizacijo delov procesa, ki so prej zahtevali ročno delo. Projekt kaže, da agent ni ločena aplikacija, temveč sloj, ki se vgradi med obstoječe sisteme in ljudi, ki jih uporabljajo.

Kje se AI agenti danes uporabljajo v podjetjih#

Podjetja z več oddelki najpogosteje uvajajo agente tam, kjer se enaka opravila ponavljajo na velikih količinah dokumentov ali podatkov in kjer je jasno, kaj je vhod in kaj mora biti izhod. Tak proces je dovolj predvidljiv, da ga je mogoče opisati s pravili, hkrati pa dovolj obsežen, da ročno delo predstavlja opazno breme za zaposlene. Preden se podjetje odloči za agenta, je smiselno popisati, kje v procesu nastaja največ ponavljajočega se dela in kje se najpogosteje pojavljajo napake zaradi preobremenjenosti ljudi.

Izbira področja je odvisna tudi od tega, kako zanesljivi so obstoječi podatki. Agent, ki ekstrahira podatke iz slabo strukturiranih dokumentov ali nepopolnih baz, bo v začetni fazi zahteval več nadzora in popravkov kot agent, ki dela na urejenih, standardiziranih virih. Zato pred uvedbo pregledamo stanje podatkov in arhitekturo obstoječih sistemov, saj to neposredno vpliva na to, koliko samostojnosti lahko agentu zaupamo že v prvi fazi in kje bo potreben daljši čas učenja in nadzora.

Za naročnika to pomeni, da izbira področja ni odvisna le od tega, kje bi agent prinesel največ koristi, temveč tudi od tega, kje je tveganje napake najmanjše. Proces z jasnimi pravili in nizkim tveganjem je boljši kandidat za prvo uvedbo kot proces, kjer vsaka napaka takoj vpliva na stranko ali na finančno poročanje. Postopna uvedba, ki začne na manj tveganem procesu, omogoča, da se pravila in nadzor preizkusijo, preden se agent razširi na bolj občutljiva področja.

• obdelava dokumentov in ekstrakcija podatkov iz pogodb, računov in naročil
• semantično iskanje po interni dokumentaciji in bazah znanja
• podpora uporabnikom pri ponavljajočih se vprašanjih in zahtevkih
• napovedna analitika in priporočilni sistemi za odločanje
• podpora pri odločanju (decision-support) na podlagi internih podatkov
• avtomatizacija delovnih tokov med oddelki in obstoječimi sistemi

Kaj AI agent sme delati#

Preden agent dobi dostop do vaših sistemov, mora projektna ekipa skupaj z naročnikom pisno opredeliti obseg njegovih pooblastil. Ta obseg določa, katere podatke agent sme brati, katera dejanja sme izvesti samostojno in kje mora počakati na potrditev človeka. Jasno zapisan obseg ni formalnost, temveč osnova, na kateri kasneje temelji tako testiranje kot presoja odgovornosti, če pride do napake ali spora glede tega, kaj se je zgodilo znotraj procesa.

Znotraj tako opredeljenega obsega agent lahko bistveno pospeši del procesa, ki je prej zahteval ročno pregledovanje dokumentov ali iskanje po več sistemih hkrati. Ker dela znotraj jasno postavljenih pravil, je njegovo delovanje mogoče preveriti in ponoviti, kar je pogoj za to, da ga sploh lahko uvedemo v okolje, kjer napaka nosi poslovne ali pravne posledice. Prav ta preverljivost je razlog, da obseg pooblastil ni nekaj, kar se doda kasneje, temveč je del zasnove agenta od prvega dne.

Za naročnika je koristno, da obseg pooblastil ni statičen. Ko agent v praksi dokaže zanesljivo delovanje na določenem koraku procesa, je mogoče njegova pooblastila postopno razširiti - vedno na podlagi dogovora med naročnikom in izvajalcem, ne samodejno. Tak postopen pristop zmanjša tveganje in hkrati zaposlenim, ki proces nadzorujejo, da čas, da zgradijo zaupanje v to, kako se agent obnaša v resničnih, ne le testnih, situacijah.

• brati in analizirati dokumente ter podatke znotraj odobrenih virov
• pripraviti predlog odgovora, poročila ali odločitve za pregled človeka
• iskati in povezovati informacije iz več sistemov s semantičnim iskanjem
• vnašati in posodabljati podatke v sistemih, za katere ima odobren dostop prek API-ja
• sprožiti naslednji korak v delovnem toku znotraj vnaprej določenih pravil
• opozoriti pristojno osebo, kadar naleti na izjemo ali negotov primer

Kaj AI agent ne sme delati#

Enako pomembno kot opredeliti, kaj agent sme delati, je zapisati, kaj mu ni dovoljeno. Meje niso namenjene omejevanju koristnosti agenta, temveč zaščiti podjetja pred posledicami napačne ali nepooblaščene odločitve. V regulirani panogi ali pri procesih, ki vplivajo na stranke, zaposlene ali finančno poročanje, je ta razmejitev pogosto tudi pogoj, da lahko sistem sploh gre v produkcijo, saj revizija in nadzor zahtevata jasen zapis, kdo ali kaj je sprejel posamezno odločitev.

V praksi to pomeni, da agent, tudi kadar samostojno pripravi predlog, ne podpiše pogodbe, ne odobri plačila in ne sprejme kadrovske odločitve namesto pristojne osebe. Njegova vloga je pripraviti podlago - zbrati podatke, jih urediti in predlagati - odločitev pa ostane pri človeku, ki nosi odgovornost zanjo. Ta razmejitev je še posebej pomembna v javnem sektorju in reguliranih panogah, kjer mora biti vsaka odločitev sledljiva do osebe, ki jo je sprejela.

Za naročnika je pomembno, da se te meje zapišejo v dokumentacijo projekta, ne le dogovorijo ustno. Dokumentacija je del primopredaje in omogoča, da tudi po menjavi zaposlenih ali izvajalca ostane jasno, kaj je agent pooblaščen delati. Brez tega zapisa se meje sčasoma zabrišejo, zlasti ko agent v praksi deluje zanesljivo in ga je mika pooblastiti za več, kot je bilo prvotno dogovorjeno.

• samostojno spreminjati podatke zunaj odobrenega obsega ali sistemov
• sprejemati končnih odločitev s pravnimi, finančnimi ali kadrovskimi posledicami brez potrditve človeka
• dostopati do podatkov, za katere nima izrecno dodeljene pravice
• obiti obstoječih varnostnih in odobritvenih postopkov v organizaciji
• delovati v produkcijskem okolju brez predhodnega testiranja v ločenem testnem okolju
• spreminjati lastno konfiguracijo ali obseg pooblastil brez vednosti naročnika

Podatki, dostopi in varnost pri AI agentih#

Vsak AI agent, ki bere ali zapisuje podatke v vašem sistemu, je hkrati varnostno vprašanje. Preden agent dobi dostop, je treba določiti, kateri podatki so mu vidni, kdo lahko ta dostop spremeni in kako se beleži vsako njegovo dejanje. Pri projektih, ki jih izvajamo, so razvojno, testno in produkcijsko okolje ločena, v testnem okolju pa se ne uporabljajo pravi osebni podatki, kar zmanjša tveganje, da bi napaka v zgodnji fazi razvoja razkrila občutljive podatke strank ali zaposlenih.

Znotraj Epixa in specialistične partnerske mreže so na voljo profili za varnostno arhitekturo, upravljanje dostopov, utrjevanje infrastrukture in odziv na incidente, standardi kot je ISO 27001 pa so del delivery strukture, znotraj katere projekte izvajamo. Ti profili in standardi niso certifikat družbe Epix Group d.o.o. same, temveč del širše mreže, iz katere sestavimo projektno ekipo glede na zahtevnost in panogo naročnika - na primer, kadar gre za javni sektor, bančništvo ali drugo regulirano okolje, kjer so zahteve glede varnosti in sledljivosti strožje.

Za naročnika to pomeni, da vprašanje varnosti ni nekaj, kar se reši po uvedbi agenta, temveč mora biti del zasnove od začetka. Kdo ima dostop do katerih podatkov, kako se ta dostop nadzoruje in kaj se zgodi, če agent naleti na podatek, do katerega nima pravice - vse to mora biti opredeljeno, preden agent prvič zažene v produkcijskem okolju.

• ločena razvojna, testna in produkcijska okolja
• v testnem okolju se ne uporabljajo pravi osebni podatki
• dostopi in gesla so del uradne primopredaje naročniku ob zaključku projekta
• izvorna koda in podatki ostanejo last naročnika
• vsaka sprememba gre skozi pregled in testiranje pred objavo v produkcijo

Vpliv na zaposlene in spremembo procesov#

Uvedba AI agenta spremeni delo zaposlenih, ki so prej ta opravila izvajali ročno. Del njihovega časa se preusmeri od izvajanja k nadzoru - pregledujejo predloge, ki jih pripravi agent, potrjujejo izjeme in skrbijo, da agent ostaja znotraj dogovorjenega obsega. Ta sprememba vloge je enako pomembna kot tehnična uvedba sama, saj brez jasne razlage, zakaj se proces spreminja in kaj se od zaposlenih pričakuje po uvedbi, projekt naleti na odpor, tudi če je tehnično dobro izveden.

Vodja projekta na strani naročnika ima pri tem ključno vlogo, saj mora usklajevati pričakovanja med oddelki, ki proces uporabljajo, in izvajalcem, ki agenta gradi. Pri večjih projektih zato določimo projektnega vodjo, jasne odgovornosti ekip, roke in način komunikacije in poročanja, tako da je vsak korak spremembe sledljiv in da imajo zaposleni, ki proces izvajajo, jasen kanal, prek katerega lahko sporočijo, kje agent ne deluje pričakovano.

Za direktorja ali vodjo oddelka to pomeni, da je treba pred uvedbo odgovoriti na vprašanje, kdo bo agenta nadzoroval po uvedbi, ne le kdo ga bo razvil. Če ta odgovornost ni jasno dodeljena, se nadzor izgubi takoj, ko projekt preide iz faze uvajanja v vsakdanjo rabo, agent pa v praksi ostane brez dejanskega nadzora, čeprav je bil na začetku skrbno omejen.

Testiranje in prevzem pred produkcijo#

Preden agent začne delovati na resničnih podatkih, gre skozi testne scenarije, ki preverijo, ali se drži dogovorjenega obsega pooblastil. Testiranje vključuje ročno in avtomatizirano testiranje, testiranje v okviru sprotnega razvoja (CI/CD) ter prevzemno testiranje po vnaprej dogovorjenih merilih, ki jih potrdi naročnik. Šele ko so ta merila izpolnjena, se agent premakne iz testnega v produkcijsko okolje, kjer dela na pravih podatkih in v realnih delovnih tokovih.

Pri projektih, kjer je tveganje napake večje - na primer v reguliranih panogah ali pri procesih, ki neposredno vplivajo na stranke - je smiselno vključiti neodvisen QA, ločen od razvojne ekipe, ki je agenta zgradila. Neodvisna presoja zmanjša tveganje, da bi se napaka, ki jo je spregledala razvojna ekipa, prenesla naprej v produkcijo. Odločitev o tem, ali je neodvisen QA potreben, je del načrtovanja projekta, ne naknadna dopolnitev.

Za naročnika je prevzemno testiranje priložnost, da preveri, ali agent v praksi deluje tako, kot je bilo dogovorjeno na začetku projekta - ne le tehnično, temveč tudi z vidika tega, kako zaposleni proces dejansko izvajajo. Merila za prevzem se zato pripravijo skupaj z ljudmi, ki bodo z agentom delali, ne le s tehnično ekipo.

Vzdrževanje in odgovornost po uvedbi#

Po uvedbi agenta se odgovornost ne konča. Lahko prevzamemo nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj agenta, ko se proces v podjetju spremeni ali razširi na nova področja. Obseg te podpore se določi po projektu in je zapisan v pogodbi o podpori, tako da naročnik natančno ve, kaj je vključeno in kdo je odgovoren, če agent preneha delovati pričakovano.

Ta razvrstitev v razrede pomaga ločiti med dogodkom, ki zahteva takojšnjo obravnavo, in zahtevo za izboljšavo, ki jo je smiselno vključiti v naslednjo redno objavo. Odzivni časi znotraj posameznega razreda se dogovorijo v pogodbi o podpori glede na kritičnost procesa, v katerega je agent vgrajen - podpora agentu, ki pripravlja interna poročila, ima drugačne zahteve kot podpora agentu, ki je del procesa, viden strankam.

Za naročnika je pomembno, da se ta razvrstitev dogovori pred uvedbo agenta v produkcijo, ne šele, ko se pojavi prva napaka. Jasno dogovorjeni razredi podpore omogočajo, da vodja IT ali vodja oddelka že vnaprej ve, koga obvestiti in kaj lahko pričakuje, ko agent v resničnem delovnem okolju naleti na nepredvideno situacijo.

• razred 1 - izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• razred 2 - motnja: sistem deluje, posamezna funkcija ne, obravnava po dogovorjeni prednosti
• razred 3 - napaka: manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• razred 4 - zahteva: sprememba ali nadgradnja, obseg ocenimo in termin uskladimo z naročnikom

Kako izbrati izvajalca za AI agente#

Pri izbiri izvajalca za AI agenta v poslovnem procesu ne gre le za tehnično znanje o umetni inteligenci, temveč za sposobnost sestaviti projektno ekipo, ki pokrije celoten obseg dela - od analize procesa in arhitekture do integracij, varnosti, testiranja in podpore po uvedbi. Projekt lahko prevzamemo v celoti ali kot posamezen sklop, prevzamemo pa lahko tudi obstoječ ali nedokončan sistem, potem ko pregledamo izvorno kodo, arhitekturo, infrastrukturo in podatke, na katerih temelji.

Znotraj Epixa in njegove specialistične partnerske mreže so na voljo profili s certifikati na področju oblačnih storitev, varnosti in vodenja projektov, standardi, kot so ISO 9001, ISO 20000/20001, ISO 27001 in ISO 27701, pa so del delivery strukture, znotraj katere sestavimo ekipo za posamezen projekt. Ti certifikati in standardi veljajo za Epix in njegovo partnersko mrežo, ne za posameznega zaposlenega ali za družbo Epix Group d.o.o. samo, zato jih pri izbiri izvajalca vedno preverite v tem kontekstu.

Za naročnika je smiselno vprašati, kako izvajalec sestavi ekipo za vaš specifičen projekt, kdo bo projektni vodja in kako je urejena primopredaja - dokumentacija, dostopi in gesla morajo biti del uradnega zaključka projekta, izvorna koda in podatki pa ostanejo vaša last, ne glede na to, ali podporo po uvedbi nadaljuje isti izvajalec.

• senior inženirji in solution architecti za zasnovo agenta in njegovih meja
• AI strokovnjaki za modeliranje, semantično iskanje in obdelavo dokumentov
• DevOps in cloud inženirji za infrastrukturo, v kateri agent deluje
• strokovnjaki za kibernetsko varnost za dostope in nadzor
• QA in test automation inženirji za neodvisno testiranje pred uvedbo
• projektni vodje za usklajevanje med oddelki naročnika in izvajalcem

Cena in obseg projekta#

Cene uvedbe AI agenta ne objavljamo vnaprej, ker je odvisna od obsega funkcionalnosti, števila uporabniških vlog in tega, koliko obstoječih sistemov je treba povezati prek API-jev. Prav tako vpliva, ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega, kakšna je količina in stanje podatkov, ki jih je treba pripraviti, in kakšne so zahteve glede varnosti, revizijske sledi in skladnosti, zlasti v javnem sektorju in reguliranih panogah.

Na obseg vpliva tudi, koliko samostojnosti bo agent imel na začetku - agent, ki le pripravlja predloge za pregled človeka, zahteva drugačen obseg testiranja in nadzora kot agent, ki samostojno sproža korake v delovnem toku. Več kot je dejanj, ki jih agent sme izvesti sam, temeljitejše mora biti testiranje pred uvedbo in jasneje morajo biti zapisane meje njegovega delovanja.

Cena se zato določi šele po pregledu vaših zahtev, obsega in tehnične zahtevnosti projekta. Pred tem predlagamo krajšo analizo, ki obseg razčleni na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno - to naročniku omogoča, da se odloča po delih projekta, ne da bi moral vnaprej odobriti celoten proračun, preden je obseg dela sploh jasno opredeljen.

• obseg funkcionalnosti in število uporabniških vlog
• koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji
• ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega
• zahteve glede varnosti, revizijske sledi in skladnosti
• obseg AI dela - kje so podatki, kakšna natančnost je zahtevana in katera dejanja agent sme izvajati sam
• raven podpore po uvedbi in dogovorjeni odzivni razredi