De ce sunt anulate proiectele de IA agentică și ce face bine un proiect-pilot de opt săptămâni

Un client cere o rambursare, iar agentul găsește comanda în CRM, verifică politica de retur și redactează un răspuns în mai puțin de un minut. Apoi se blochează, pentru că aprobarea rambursării trebuie obținută într-un sistem financiar la care nu a fost conectat, iar adresa clientului nu coincide în două baze de date. Astfel de lacune ies rareori la iveală într-o demonstrație, însă ele determină cât costă operarea unui agent și dacă cineva poate avea încredere în el. Asta înseamnă că riscul mai mare al IA agentice ține de mediul de afaceri în care este introdus agentul, nu de model.

Gartner estimează că peste 40% dintre proiectele de IA agentică vor fi anulate până la sfârșitul anului 2027, invocând creșterea costurilor, valoarea neclară pentru afacere și controalele slabe asupra riscurilor. Privită cu atenție, această prognoză se referă la modul în care proiectele sunt aprobate pe baza unei demonstrații, fără o imagine clară a costurilor actuale ale activității sau a persoanei responsabile de rezultat.

Întrebarea pe care aș adresa-o oricărei echipe de conducere este dacă firma poate susține utilizarea zilnică a acestui agent, la un cost și cu un nivel de risc pe care și le poate asuma. Pentru a răspunde, trebuie analizat atent ceea ce numesc munca rămasă după automatizare, adică tot ce trebuie să facă oamenii după ce agentul și-a încheiat partea. Un proiect-pilot de opt săptămâni este o metodă practică de a măsura această muncă înainte de a se angaja într-o implementare la scară largă.

Problemele pe care agentul le moștenește de la companie

Rareori un agent lucrează singur, deoarece chiar și o sarcină aparent simplă implică datele clienților, câteva aplicații de business și, de obicei, o etapă de aprobare, iar fiecare conexiune limitează ce poate vedea și face agentul. Dacă datele sunt neconcordante sau nu este clar cine aprobă, agentul moștenește confuzia odată cu sarcina.

Cazurile obișnuite rareori sunt problema; excepțiile sunt, pentru că acolo se acumulează costurile operaționale, iar tocmai acestea sunt evitate într-o demonstrație. Cercetarea Deloitte din 2026 a arătat că doar 5% dintre organizații își consideră procesele de afaceri foarte bine pregătite pentru agenții IA. Acest procent spune mai mult decât orice evaluare comparativă a unui model, pentru că sugerează că IA este pregătită cu mult înaintea majorității proceselor.

Calculul rentabilității trebuie să includă munca rămasă după automatizare

Măsurarea vitezei cu care un agent produce un rezultat este cea mai simplă cale de a-i supraestima valoarea, deoarece contează cât efort presupune finalizarea sarcinii. Să presupunem că unui angajat îi ia 20 de minute să proceseze o solicitare, iar agentul reduce la două minute timpul necesar pentru prima versiune. La prima vedere, economia este de 18 minute, până când cineva petrece 15 minute verificând rezultatul și corectând erorile. O economie de trei minute oferă un câștig modest, odată ce costul de operare a agentului este trecut în cealaltă parte a balanței.

Analiza realizată de McKinsey asupra unui agent de servicii pentru clienți din domeniul bancar arată același tipar la scară largă: tokenurile au reprezentat 20–25% din costurile operaționale variabile, iar supravegherea umană, 70–75%. Așadar, cea mai mare parte a costurilor se situa în afara modelului. Dacă nu se stabilește o valoare de referință înainte ca cineva să scrie cod, proiectul-pilot poate înregistra progrese tehnice considerabile, fără să pună la încercare justificarea investiției. Cel puțin, responsabilul din cadrul companiei trebuie să aibă un răspuns clar la fiecare dintre următoarele întrebări:

• Volum: cât de des se desfășoară procesul și câte persoane participă la el.
• Timpul de finalizare: cât durează întreaga sarcină, inclusiv verificările și corecturile.
• Acuratețe: cât de des apar erori sau este nevoie să se refacă munca.
• Costul per sarcină: cât costă în prezent finalizarea cu succes a unei sarcini.
• Impactul asupra afacerii: ce s-ar schimba pentru clienți, angajați sau companie în urma unei îmbunătățiri reale.

Agentul trebuie să-și câștige locul în fluxul de lucru

Adoptarea este de obicei încadrată la managementul schimbării, deși, din experiența mea, ea se decide mult mai devreme, în funcție de locul agentului în fluxul de lucru. O companie globală de servicii profesionale construise agenți pentru activități de asistență și conformitate, iar agentul de asistență putea extrage informații din mai multe sisteme interne. Totuși, pentru a-l folosi, oamenii trebuiau să deschidă o aplicație separată și, în mare parte, nu se oboseau să facă asta. După ce același flux de lucru a fost mutat pe platforma de asistență deja existentă, agentul a apărut în tichetul la care lucrau deja angajații. Un agent de verificare a conformității a fost integrat în Salesforce în același fel, astfel încât să ruleze de fiecare dată când era creat un caz.

Agenții nu s-au schimbat; s-a schimbat locul lor în fluxul de lucru. Angajații aveau deja un motiv să deschidă un tichet sau să creeze un caz, așa că integrarea agentului în acel moment nu le cerea niciun efort suplimentar. Prin urmare, amplasarea agentului este o decizie de arhitectură la fel de mult ca una legată de adoptare, deoarece agentul are nevoie de contextul în care se desfășoară activitatea, iar rezultatul său trebuie să alimenteze etapa următoare fără ca cineva să-l copieze manual.

Autonomia schimbă ecuația securității

Un agent care poate doar să citească informații implică un anumit tip de risc, iar unul care poate modifica înregistrări sau le poate trimite e-mailuri clienților implică un cu totul alt tip de risc. Prin urmare, controalele trebuie să țină seama de ceea ce are efectiv permisiunea să facă. Permisiunile excesive și scurgerea datelor sensibile sunt riscuri bine cunoscute, dar injectarea de prompturi merită cea mai mare atenție: instrucțiuni ascunse într-un document sau într-un e-mail, pe care agentul le preia în timp ce își îndeplinește o sarcină perfect legitimă.

Îndrumările Gartner din mai 2026 privind guvernanța agenților împart autonomia în patru niveluri, oferind o modalitate practică de a stabili cât de stricte trebuie să fie măsurile de control:

1. Observare: agentul preia informații și identifică tipare, având acces doar pentru citire.
2. Recomandare: agentul recomandă o acțiune, iar un angajat ia decizia.
3. Acțiune cu aprobare: agentul pregătește sau inițiază o acțiune, pe care o persoană trebuie să o autorizeze înainte de executare.
4. Acțiune autonomă: agentul execută singur acțiunile aprobate, în limitele stabilite, fiind monitorizat, iar excepțiile sunt escaladate.

La fiecare nivel, agentul are nevoie de o identitate proprie, de permisiuni limitate la sarcina sa și de o evidență a fiecărei acțiuni pe care o întreprinde. Organizațiile au nevoie și de reguli privind modul de gestionare și păstrare a datelor, de claritate cu privire la ce ajunge la furnizorii externi de modele și de o persoană cu autoritatea de a suspenda agentul și de a-i revoca accesul de îndată ce ceva pare în neregulă.

Fiecare dintre aceste măsuri de control generează costuri recurente, deoarece permisiunile mai largi, monitorizarea suplimentară și aprobările frecvente se adună în timp. Prin urmare, nivelul potrivit de autonomie este atât o decizie economică, cât și una de securitate și se situează acolo unde agentul oferă un rezultat valoros, la un nivel de risc pe care compania îl poate accepta.

Alegeți un proces care justifică utilizarea unui agent

Multe echipe încep cu tehnologia și caută apoi o problemă pe care să o rezolve, deși un punct de plecare mai bun este un proces ale cărui costuri sau întârzieri sunt deja evidente pentru cei care îl desfășoară.

O companie globală care oferă acces la o rețea de experți, cu care am colaborat, se încadra în această descriere: echipa sa potrivea solicitările pentru sondaje cu experți folosind trei sisteme care nu comunicau între ele și verifica manual profilurile, participarea anterioară și conformitatea pentru fiecare potrivire. Am construit un agent care combina căutarea semantică cu istoricul participării și regulile de conformitate, iar după implementarea în producție, tichetele privind nepotrivirile au scăzut cu 80%, acuratețea potrivirilor a crescut cu 40%, iar echipa și-a recâștigat 22% din capacitatea de lucru.

Proiectul a reușit deoarece problema era bine definită: informațiile erau dispersate, trebuiau reunite manual, iar calitatea potrivirilor putea fi măsurată înainte și după. O problemă bine definită ajută și la stabilirea faptului că un proces chiar are nevoie de un agent. De regulă, automatizarea convențională este mai ieftină pentru activitățile guvernate de reguli fixe, iar un asistent AI este adesea potrivit pentru activitățile care constau în principal în găsirea și rezumarea informațiilor. Agenții își justifică însă costul și riscul suplimentar atunci când sarcina presupune analizarea contextului, alegerea dintre acțiuni permise și înlănțuirea mai multor pași pentru a obține un rezultat.

Un proiect-pilot de opt săptămâni, cu puncte de decizie clare

Întregul proiect-pilot se bazează pe o singură întrebare comercială: poate acest agent să îmbunătățească suficient procesul pentru a justifica operarea lui la scară largă? Opt săptămâni oferă suficient timp pentru a testa argumentul economic, tehnologia și capacitatea organizației de a gestiona ceea ce construiește.

Săptămânile 1–2: stabiliți ce trebuie îmbunătățit

Începeți prin a documenta procesul în forma sa actuală, de la volumul de lucru și timpul de finalizare până la ratele de eroare, refacerea sarcinilor și costuri. Notați sistemele implicate, persoana responsabilă de fiecare etapă și excepțiile care necesită intervenția unui om, apoi asigurați-vă că responsabilul de business și echipa tehnică sunt de acord asupra singurului rezultat pe care agentul trebuie să îl îmbunătățească. Punct de decizie: continuați când problema, valorile de referință, responsabilul și indicatorii de succes sunt clare.

Săptămâna 3: definiți limitele agentului

În această etapă se stabilesc limitele agentului: identitatea, permisiunile, accesul la date, instrumentele aprobate și gradul de autonomie. Testați-l în raport cu atacurile prin injectarea prompturilor, accesul neautorizat, expunerea datelor sensibile și utilizarea necorespunzătoare a instrumentelor. Instituiți proceduri de jurnalizare și de răspuns la incidente, precum și o modalitate de a suspenda agentul sau de a-i revoca accesul. Punct de decizie: continuați după ce măsurile de control și pașii de intervenție au fost testate efectiv și toată lumea știe ce are voie să facă agentul.

Săptămânile 4–6: testați situațiile care compromit demonstrația

Acum încredințați-i sarcini realiste, inclusiv înregistrări incomplete, informații contradictorii, solicitări neobișnuite și eventuale defecțiuni ale sistemului. Urmăriți câte sarcini finalizează, cât de precis este și câtă muncă de corectare trebuie să facă oamenii, apoi calculați costul real al unei sarcini finalizate cu succes, incluzând utilizarea modelelor, integrările, monitorizarea și verificarea. Punct de decizie: treceți la testarea în condiții reale când agentul atinge pragurile convenite, iar echipa îi înțelege atât costurile de operare, cât și modurile de eșec.

Săptămânile 7–8: puneți-l la dispoziția utilizatorilor reali

Puneți-l la dispoziția unui grup restrâns de angajați și folosiți-l pentru o parte controlată din activitatea reală, păstrând procesul vechi pentru tot ceea ce agentul nu poate gestiona. Urmăriți dacă oamenii îl folosesc efectiv, dacă le reduce efortul și dacă au încredere în rezultatele sale.

La final, comparați rezultatele cu valorile de referință din prima săptămână și analizați productivitatea, acuratețea, gradul de adoptare, frecvența intervențiilor oamenilor, costul total de operare și eventualele riscuri de securitate încă nerezolvate. Apoi decideți dacă extindeți utilizarea, remediați anumite probleme și testați din nou sau opriți proiectul. Un proiect-pilot care arată că agentul este prea scump sau prea puțin fiabil pentru sarcina respectivă și-a îndeplinit totuși rolul, deoarece a prevenit o investiție mult mai mare, bazată pe presupuneri.

Măsurați rezultatele, apoi decideți câtă autonomie să acordați

Numărul de sarcini procesate de un agent spune foarte puțin, deoarece un sistem poate prelucra mii de solicitări, dar angajații să fie nevoiți în continuare să verifice, să corecteze sau să finalizeze majoritatea dintre ele. Costul per sarcină finalizată cu succes, analizat împreună cu precizia și rata excepțiilor, oferă o imagine mult mai clară asupra îmbunătățirii procesului de la un capăt la altul.

Aceiași indicatori justifică și acordarea unei mai mari libertăți agentului. Un agent care gestionează în mod fiabil solicitările de rutină în limitele convenite poate primi încrederea de a acționa autonom în aceste cazuri, în timp ce deciziile unui agent care se confruntă în continuare cu situații ambigue trebuie aprobate de o persoană, iar permisiunile revizuite pe măsură ce se acumulează dovezi.

Extindeți implementarea când compania poate susține agentul

Mai devreme sau mai târziu, un agent care funcționează bine pentru o echipă va trebui să gestioneze activitățile altor departamente, aplicații și fluxuri de aprobare. Extinderea implementării presupune responsabilități clar definite, controale de acces consecvente și un mod de gestionare a excepțiilor, precum și un buget pentru a menține agentul la zi pe măsură ce procesele din jurul lui se schimbă.

Decizia fundamentală în toate acestea este câtă responsabilitate este organizația pregătită să delege, iar aceasta trebuie să se bazeze pe dovezi din activitatea reală, nu pe o demonstrație reușită. La finalul celor opt săptămâni, conducerea ar trebui să știe ce poate gestiona agentul, în ce situații este încă nevoie de intervenția oamenilor și cât va costa operarea lui. Companiile care vor obține un avantaj cu ajutorul inteligenței artificiale agentice vor fi cele care, încă din prima săptămână, își planifică activitatea de după automatizare și alocă bugete agenților pentru sarcinile pe care aceștia le finalizează efectiv.