Kodėl agentinį AI lengva įsidiegti, sunku palikti

Finansų komandai reikia pakeisti vieną taisyklę. Sąskaitų ginčus virš 5 000 € sulaikyti, papildyti tiekėjo istorija, sudėtingesnius atvejus nukreipti vadovo peržiūrai.

Atrodytų - dviejų valandų darbas. Integracijos veikia. Duomenys juda. Agentas dirba jau šešis mėnesius.

Bet tada prasideda tikrasis darbas. Viena taisyklės dalis - užklausos šablone. Kita - paslėptoje pakartojimų grandinėje. Likusi - vizualiniame redaktoriuje, be jokios versijų kontrolės. Tai, kas turėjo užtrukti pusdienį, virsta savaite darbo.

Būtent šią akimirką technologijų vadovai pradeda atpažinti vis dažniau. Tiekėjas nevaldo jūsų duomenų. Sutartis – atnaujinama. Integracijos - dokumentuotos. Ir vis dėlto pats darbo procesas - tai, kaip darbas iš tikrųjų atliekamas - persikėlė į kitą sistemą.

Tai visai kitokia situacija, nei ta, prie kurios pripratome SaaS pasaulyje. Ir gerokai pavojingesnė, nes paliečia tą verslo dalį, kurią atstatyti sunkiausia: sprendimų logiką, pagal kurią viskas ir vyksta.

Rinka juda greitai

Agentinio DI diegimas plinta greičiau, nei spėja susiformuoti jo valdymo principai. Remiantis Deloitte 2026 metų dirbtinio intelekto įmonėse apžvalga (opens in new tab), 74% įmonių per artimiausius dvejus metus naudos agentinį DI bent vidutiniškai, tačiau tik 21% turi subrendusį šių agentų valdymo modelį. MIT Sloan aiškiai įvardija esminį iššūkį: agentinės sistemos planuoja ir vykdo daugiaetapius procesus, tad elgiasi ne kaip įprastos funkcijos, bet kaip operaciniai sluoksniai.

Skirtumas esminis. Funkciją pakanka peržiūrėti. Operaciniam sluoksniui reikia valdymo.

Dauguma verslo platformų - Copilot, Agentforce ar šių metų naujokai - orientuojasi į greitą naudą. Iš anksto paruoštos integracijos, mažai kodo reikalaujančios priemonės, prižiūrimas procesų valdymas. Paprastiems vidaus asistentams ir mažos rizikos automatizacijai tai veikia puikiai.

Bėda prasideda, kai darbo procesai tampa sudėtingesni. Demo versijoje matote aiškų kūrimo įrankį. Tik nematote paslėptos tiekėjo sintaksės, paslėptų būsenų, išskirtinių kelių ir verslo logikos, kuri vis giliau paskęsta tiekėjo sistemoje vos tik imama spręsti tikrus klausimus.

Kodėl įstrigti darbo procese pavojingiau nei SaaS

Klasikinis SaaS įkalina jūsų duomenis, integracijas ir vartotojų įpročius. Skaudu, bet sprendžiama. Galima eksportuoti įrašus, atstatyti integracijas, perkvalifikuoti komandą ir judėti toliau.

Agentinis DI įkalina jūsų veiklos modelį.

Šį skirtumą technologijų vadovai turi pamatyti. Įprastos migracijos metu keičiasi programa. Agentų migracijos metu keičiasi pati darbo kalba. Verslo taisyklės vis dar egzistuoja, tik jos išsibarsčiusios po užklausų šablonus, paslėptą būseną, tiekėjo apibrėžtas abstrakcijas ir vartotojo sąsajoje paslėptus nustatymus. Darbo procesas tampa pačiu produktu - o kalbą, kuria jis parašytas, valdo tiekėjas.

Tokių produktų kaip Copilot ir Agentforce pranašumas slypi ne sutartyje, o darbo proceso kalboje.

Tai geriausiai pasimato keičiant sistemas. Komandos žymi integracijas, skaičiuoja API, vertina migraciją kaip duomenų projektą. Tai klaidinga perspektyva. Migracija tampa ne eksportu, o vertimu. Jūs neperkeliat įrašus iš programos į programą - jūs perrašote elgseną iš vienos uždaros kalbos į kitą. Patvirtinimų ribos, eskalavimo taisyklės, išimtinių atvejų valdymas, papildoma logika ir vertintojų eilės - visa tai nėra „konfigūracija". Tai institucinės žinios, užkoduotos tiekėjo sintakse.

Panašią dinamiką aptarėme straipsnyje Individualūs programiniai sprendimai ar SaaS: kada verta keisti įrankį (opens in new tab), bet agentinis DI kelia kartelę dar aukščiau. SaaS keičia įrankius. Agentinis DI keičia požiūrį į pačią darbo esmę.

3 ženklai, kad jūsų darbo procesas jau įstrigęs

Jei norite įvertinti dabartinę situaciją, pirmiausia pasidomėkite šiais trimis aspektais.

1. Jūsų komanda darbo procesą apibūdina platformos, o ne verslo terminais.

Pirmasis įspėjamasis signalas - kalba. Kai operacijų specialistai vadina sąskaitų peržiūrą „kortelėmis", „agento žingsniais", „Copilot veiksmais", niekas nebegali pakartoti taisyklės įprasta kalba be sąsajos vaizdo.

Gali atrodyti smulkmena, bet iš tiesų, kai platformos kalba perima procesą, platforma jau nebe įgyvendina darbo procesą - ji jį apibrėžia.

2. Nėra kaip testuoti ar versijuoti elgsenos.

Jei užklausos, būsenos, teisių keitimo ir išimčių tvarkymas aprašyti vartotojo skydeliuose, o ne programų saugyklose, peržiūrose ar testuose - kontrolė mažesnė nei atrodo.

Turite logus, turite patvirtinimo ekranus. Bet negalite palyginti taisyklės pakeitimo, atkartoti klaidos ar peržiūrėti užklausos atnaujinimo prieš išleidimą. Kai agentinės sistemos plečiasi į patvirtinimus, pinigų srautus, komandų paskirstymą ir vadovų ataskaitas, testavimas tampa būtinybe. Programinė įranga, kuri veikia už jus, reikalauja tos pačios disciplinos kaip ir bet kuri kita produkcinė sistema.

3. Migracijos planai apima tik duomenis, ne procesų logiką.

Kai planuojate perėjimą į kitą platformą - vertinate API ir eksportavimo formatus. Tačiau retai aptariamos maršrutų taisyklės, atsarginiai keliai, pasitikėjimo ribos ar eskalavimo logika. Būtent tai ir trunka ilgiausiai sukurti, ir būtent tai dažniausiai būna giliai paslėpta tiekėjo sistemoje.

Jei negalite paaiškinti proceso be sąsajos grafikos - jūs jo nebevaldote.

Kur yra riba

Platformos veikia. Mes jas naudojame. Jei komandai reikia Slack boto, bilieto kūrimo asistento ar paprasto vidinio copilot - Copilot ar Agentforce tai įdiegia per dieną. Tai puikus pasirinkimas.

Tačiau kai DI sistema pradeda formuoti pelningumą, atitiktį, verslo srautus ar tarpkomandinius sprendimus, architektūra turi keistis. Tuomet klausimas - ne kaip greitai paleisti, o ką iš tiesų turėsite po pusmečio.

Būtent čia individualūs DI sprendimai įgauna prasmę - ne dėl filosofijos, o dėl struktūros. Mes kuriame agentines sistemas, kur aiškiai atskiriame modelio prieigą, darbo eigą, verslo logiką, stebėseną ir sąsają. Procesų taisyklės - kode ar išskirtinai konfigūracijoje. Būsenų perdavimas aiškus. Užklausos ir politikos turi versijas. Sprendimai - užregistruoti. Komponentai sukurti taip, kad būtų galima juos pakeisti.

Tai ne teorija, o praktinis dizaino sprendimas, leidžiantis procesui likti matomam, testuojamam ir perkėliamam.

Kaip tai atrodo praktikoje

Visa ši argumentacija - koncepcinė: procesų priklausomybė blogesnė nei sutartinė priklausomybė, individualūs sprendimai suteikia jums kontrolę, o savininkystė tampa tikrai svarbi, kai darbo procesas paliečia verslo pagrindą. Bet svarbiausia - kaip tai veikia praktikoje.

Esame sukūrę tris sistemas, remdamiesi šiais principais. Visi trys projektai pradėti viduje - norėjome juos išbandyti patys prieš siūlydami klientams.

MYGOM DI Sąskaitų Automatizavimo Sistema (opens in new tab) – praktiškiausias pavyzdys. DI automatiškai nuskaito sąskaitas iš el. pašto ir PDF, sutikrina su banko išrašais 95% tikslumu, neleidžia dublikatų, seka prenumeratas. Kiekvienas sustabdytas dublikatas sutaupo vidutiniškai 2 000+ USD, o sąskaitų apdorojimo laikas sutrumpėjo 40%. Šią sistemą dabar diegiame finansų ir operacijų komandoms su panašiomis problemomis. Taisyklės, kurios apibrėžia, kas yra dublikatas, kaip sprendžiamos išimtys, kokios prenumeratos reikalauja dėmesio - visa tai mūsų pačių kode. Jei kliento politika keičiasi - keičiame tik ją, o ne bandome apeiti tiekėjo logiką.

Mygom Verslo Duomenų Analitikos Platforma (opens in new tab) - mūsų agentinė verslo analizės platforma. Ji jungiasi prie atlyginimų, laiko sekimo, sąskaitų ir projektų sistemų, leidžia kiekvienam komandos nariui užduoti verslo klausimus paprasta kalba. Kurie projektai pelningi? Kas gali greit perdegti? Kurie klientai nustoja naudotis paslaugomis? Sistema nuolat pateikia atsakymus, fiksuoja anomalijas, prognozuoja pelno scenarijus, o kiekvienas procesas yra patikrinamas, testuojamas ir keičiamas. Rezultatai: 3 kartus greitesnės įžvalgos, 30% mažiau viršvalandžių, 25% mažiau „scope creep". Skaičiai labai svarbūs, bet svarbiausia - visa analizės logika priklauso mums.

DI įrankis, rašantis pasiūlymus (opens in new tab) generuoja komercinius pasiūlymus, technines specifikacijas, viešųjų pirkimų dokumentus, remdamasis mūsų kainodara ir ankstesniais laimėtais pasiūlymais. Tai, kas užtrukdavo pusę dienos, tapo 30-60 minučių pokalbiu. Mes valdome užklausų tekstus, struktūrą, kainodaros logiką - kiekvieną detalę.

Visose trijose sistemose agentai atlieka darbą mūsų vardu, bet veikia sistemoje, kurią galime pakeisti patys.

Ką tai reiškia jums

Jei svarstote agentinės DI platformos diegimą arba ją jau naudojate, verta atlikti keletą žingsnių prieš atėjus momentui, kai pakeitimas tampa beveik neįmanomas.

1. Įvertinkite, kas bus perkelta į tiekėjo rankas. Prieš įsipareigodami, sudarykite sąrašą visų verslo taisyklių, patvirtinimo ribų, eskalavimo kelių ir išimčių valdymo, kurie gyvens platformoje. Jei tame sąraše yra dalykų, apibrėžiančių, kaip veikia jūsų verslas - kainodaros logika, atitikties taisyklės, klientų prioritetizavimas, finansinė kontrolė - būtent šie procesai turi išlikti perkeliami.

2. Padarykite „paaiškink be sąsajos" testą. Paprašykite komandos paaiškinti darbo procesą verslo kalba, neminint jokių platformos kortelių ar agentų šablonų. Jei taip negali - platforma jau formuoja komandos mąstyseną apie procesą. Tai pirmas priklausomybės ženklas, kuris laikui bėgant tik stiprės.

3. Atskirkite, kurie procesai yra bendriniai, o kurie konkurenciniai. Slack botas, kuris suranda dokumentus, - bendrinis. Finansų komandų patvirtinimo logika - konkurencinis pranašumas. Platformos puikiai tinka pirmajai kategorijai. Individualūs sprendimai - antrajai. Dauguma komandų viską meta į platformas, nes demo įspūdis stiprus - tikroji kaina paaiškėja vėliau, kai procesas tampa kritinis.

Trečias punktas - geriausia pradžios vieta. Susirašykite dabartinius ir planuojamus agentinius DI procesus į dvi skiltis: bendriniai ir konkurenciniai pranašumai. Savininkystė būtina būtent konkurenciniame stulpelyje.

Kai būsite pasiruošę aptarti, kaip tai atrodo jūsų komandai - kurias sritis verta palikti platformoje, ką kurti patiems ir kaip abu modelius išlaikyti nepriklausomus - susisiekite (opens in new tab). Aptarsime jūsų situaciją.

Dažniausias klausimas - kaina

Įprastas atsakas - kaina. Individualios sistemos laikomos sunkiomis ir brangiomis. Mažiems ar laikiniems darbo procesams toks nerimas pagrįstas. Tokiu atveju platforma paprastai laimi.

Tačiau kai procesas tampa esmine verslo dalimi, bendros išlaidos nebėra tik licencijos kaina. Jos apima migraciją, derinimo laiką, našumo reguliavimą, atitikties bei patikros kaštus ir platformos pokyčių „išvyniojimą" vėliau. Dauguma komandų lygina švarią platformos demo su individualaus sprendimo sąmata. Nelygina - kiek iš tikrųjų kainuos viską perrašyti, kai procesas tampa kritiškai svarbus verslui.

Rinka natūraliai dalinsis į dvi kryptis. Bendriniai asistentai liks platformose - bendros užduotys, kuriose diferenciacija nereikalinga, o perkėlimas nesvarbus. Darbo procesai, kurie formuoja veiklos pranašumą, judės link nuosavų, modulinių sistemų, kurias inžinierių komandos gali patikrinti, testuoti ir keisti. Pranašumą turės tos komandos, kurios išlaikė kontrolę, o ne tos, kurios diegė greičiausiai.

Tai tas pats pasirinkimas, kurį aptarėme straipsnyje DI įgyvendinimas realybėje - kas iš tiesų veikia (opens in new tab) - svarbu ne greitis, o kas valdo tą dalį sistemos, kuri apibrėžia jūsų veiklos logiką.

Esmė

Jei procesas veikia su pinigais, atitiktimi, našumu ar sprendimais, laikykite jį pagrindine architektūros dalimi. Neslėpkite jo tiekėjo sistemoje ir nevadinkite to lankstumu.

Tikras lankstumas - kai galite keisti modelius, tiekėjus ar tobulinti eigą neperrašant viso verslo. Tai įmanoma tik tada, jei logika yra ten, kur ją kontroliuojate patys.

Prieš priimdami sprendimą dėl kito agentinio DI, užduokite sau klausimą: jei reikėtų perkelti modelį, tiekėją ar valdymo sluoksnį kitą ketvirtį - ką tektų perkurti? Sąžiningas atsakymas parodo, ar jūs tikrai valdote procesą.

Mes kuriame sprendimus jūsų verslui - sprendimus, kuriuos valdote patys.

Jei norite pasitarti, kurie procesai turi likti perkeliamais, o ką patikėti platformai, susisiekite su mumis (opens in new tab).