Un program de 90 de zile poate transforma o idee vagă despre agenți AI într-o decizie de business bazată pe dovezi. Nu poate însă garanta că orice proces va fi automatizat, că integrarea va fi simplă sau că sistemul va fi pregătit pentru extindere. Pentru un IMM, rezultatul sănătos al perioadei poate fi lansarea controlată, restrângerea cazului de utilizare, reproiectarea soluției sau chiar oprirea ei.
Acest articol propune un cadru practic pentru primele 90 de zile. Calendarul este un scenariu de lucru, nu un standard oficial și nici o promisiune de implementare. Durata reală depinde de date, integrări, furnizori, cerințe contractuale și nivelul de risc. În domenii reglementate sau pentru sisteme clasificate drept „cu risc ridicat”, analiza juridică, evaluarea și aprobările pot dura mai mult.
Un agent AI nu este doar un chatbot. În sens operațional, este un sistem care primește un obiectiv, interpretează contextul, alege pași și poate folosi instrumente precum CRM-ul, e-mailul, baza de cunoștințe sau aplicația de facturare.
Un sistem agentic măsurabil are cel puțin șapte componente:
„Măsurabil” nu înseamnă doar că numărăm apelurile API sau conversațiile. Înseamnă că putem răspunde la întrebări de business: câte rezultate corecte au fost obținute, cât timp uman s-a economisit, cât a costat un rezultat acceptat, ce erori au apărut și dacă riscul rezidual este acceptabil.
Nu porniți cronometru doar pentru că există un abonament la un model AI. Înainte de proiect, confirmați cinci condiții.
„Echipa pierde timp” este o observație, nu un caz de utilizare. Un caz mai bun este: „angajații verifică manual cererile primite, caută date în două aplicații și pregătesc un răspuns pentru aprobare”. Procesul trebuie descris suficient de concret încât aceeași echipă să poată recunoaște o execuție corectă și una greșită.
Proprietarul de proces stabilește ce înseamnă rezultat bun, validează excepțiile și poate opri pilotul. Furnizorul tehnic nu poate prelua această responsabilitate de business.
Măsurați situația curentă înainte de automatizare: volum, timp de procesare, cost, rată de corecție, întârzieri, reclamații și incidente. Dacă nu aveți date istorice, prima etapă trebuie să includă observarea manuală a unui eșantion reprezentativ.
Verificați cine deține datele, ce informații personale sau confidențiale apar, unde sunt procesate, cât sunt păstrate și dacă furnizorii le folosesc pentru antrenare. Stabiliți cine poate aproba accesul la fiecare instrument.
Un prim pilot potrivit este frecvent, repetabil, suficient de valoros și reversibil. Evitați să începeți cu decizii greu de contestat, plăți mari, concedieri, evaluări medicale sau juridice și acțiuni care nu pot fi anulate. Pentru idei de procese și criterii de selecție, consultați și 7 procese în care un agent AI poate produce rezultate măsurabile.
Dacă lipsesc proprietarul, datele sau baza de comparație, obiectivul realist al celor 90 de zile este descoperirea și pregătirea, nu producția.
Prima etapă produce o fișă de proiect de o pagină și o hartă a procesului actual.
Fișa ar trebui să includă:
Desenați apoi fluxul real, inclusiv excepțiile. Observați câteva cazuri de la început la sfârșit și discutați cu oamenii care le rezolvă. Procedurile scrise omit adesea scurtături, verificări informale și situații rare care contează tocmai când un sistem începe să acționeze.
În această etapă se stabilește și alternativa minimă. Uneori problema poate fi rezolvată mai sigur printr-o regulă, un formular mai bun, o integrare obișnuită sau un asistent care propune un răspuns fără să acționeze. Agentul trebuie comparat cu aceste opțiuni, nu doar cu munca manuală.
Poarta de decizie 1: continuați numai dacă procesul este suficient de clar, rezultatul poate fi verificat, datele sunt accesibile și riscul poate fi limitat.
Acum definiți arhitectura minimă. Pentru primul pilot, reduceți numărul de instrumente și privilegiile. Dacă agentul trebuie doar să consulte stocul și să pregătească un răspuns, nu îi oferiți și dreptul de a modifica prețuri sau de a emite rambursări.
Pentru fiecare instrument, notați:
Folosiți principiul privilegiului minim și separați citirea de scriere. Conturile dedicate, listele de permisiuni, limitele de rată și credențialele cu durată scurtă reduc impactul unei erori. Pentru modelul complet de control, vedeți Permisiuni, identitate și audit pentru agenți AI.
Construiți un set de cazuri înainte să optimizați instrucțiunile. Includeți:
Atacurile prin instrucțiuni ascunse în e-mailuri, documente sau pagini web sunt un risc practic pentru agenții care citesc date neverificate și folosesc instrumente. Cercetarea AgentDojo, publicată la NeurIPS 2024, evaluează acest tip de interacțiune prin 97 de sarcini și 629 de teste de securitate. Concluzia utilă pentru un IMM nu este că există un test universal, ci că succesul pe cazuri obișnuite nu dovedește rezistența la conținut adversarial.
Stabiliți pragurile înainte de a vedea rezultatele. De exemplu:
Valorile de mai sus sunt doar exemple. Pragurile reale se stabilesc după costul erorii, baza de comparație și toleranța la risc.
Poarta de decizie 2: nu construiți pilotul până când permisiunile, cazurile de test, pragurile și proprietarul fiecărei decizii nu sunt explicite.
Implementați cel mai mic flux care poate demonstra sau infirma ipoteza. Folosiți un mediu de test separat, date mascate sau sintetice acolo unde este posibil și instrumente simulate pentru acțiuni cu impact.
În această perioadă, echipa trebuie să poată vedea atât rezultatul final, cât și traseul relevant: ce date a consultat agentul, ce instrument a apelat, ce reguli s-au aplicat, unde a cerut ajutor și de ce a eșuat. Traseul nu trebuie să expună inutil date personale și nici să fie confundat cu explicația internă a modelului. Scopul lui este auditul operațional.
Comparați trei variante:
Dacă prima sau a doua variantă oferă aproape aceeași valoare cu mai puțin risc și cost, alegerea mai simplă este de obicei mai bună.
Nu adăugați funcții noi la fiecare demonstrație. Blocați temporar versiunea modelului, instrucțiunile și configurația instrumentelor, apoi înregistrați orice schimbare. Altfel, nu veți ști dacă o îmbunătățire sau o degradare vine din produs, date ori model.
Poarta de decizie 3: prototipul trece mai departe numai dacă îndeplinește pragurile minime în mediul izolat și niciun eșec critic nu rămâne fără control compensatoriu.
Evaluarea offline folosește cazuri istorice, sintetice și construite special pentru erori. Nu măsurați doar răspunsul final. Verificați și dacă agentul a folosit instrumentul potrivit, în ordinea permisă, cu argumentele corecte și fără pași interziși.
Această separare între rezultat și traiectorie este importantă. Un rezultat aparent corect poate ascunde o sursă nepermisă, o dublă înregistrare sau o scurtătură imposibil de acceptat în producție. Ghidul tehnic Demystifying evals for AI agents, publicat de Anthropic la 9 ianuarie 2026, recomandă combinarea evaluării rezultatului, a traseului și a analizelor umane. Este o recomandare de furnizor, nu o normă legală, dar distincția este utilă indiferent de model.
După testele offline, folosiți modul paralel sau „shadow mode”. Agentul primește cazuri reale și produce o recomandare, dar nu modifică sistemele și nu comunică direct cu clientul. Operatorul rezolvă cazul prin fluxul normal, iar evaluatorul compară rezultatele.
Înregistrați:
Un scor mediu bun poate ascunde o categorie care eșuează constant. Segmentați rezultatele după tipul cazului și urmăriți separat evenimentele rare cu impact mare.
Poarta de decizie 4: pilotul cu efect real începe numai dacă datele din modul paralel confirmă pragurile, echipa poate interveni și mecanismul de oprire a fost testat.
În această etapă, agentul poate acționa asupra unui eșantion mic, cu limite clare. De exemplu, un singur tip de solicitare, un grup intern, o categorie de produs sau un plafon valoric redus.
Folosiți controale precum:
Idempotența înseamnă că repetarea aceleiași cereri nu produce de două ori efectul de business. Este esențială când o conexiune expiră și agentul nu știe dacă prima încercare a reușit.
Stabiliți dinainte cine poate opri pilotul și ce se întâmplă după oprire. Oprirea nu trebuie să depindă de același model sau serviciu care a eșuat.
Revizuiți zilnic incidentele și cazurile respinse în prima săptămână. Reduceți frecvența numai după ce comportamentul devine stabil. Nu modificați simultan modelul, instrucțiunile, sursele de date și drepturile de acces, deoarece veți pierde cauza schimbării.
Poarta de decizie 5: pilotul continuă numai dacă valoarea observată rămâne pozitivă după includerea timpului de revizuire și dacă incidentele sunt în limitele convenite.
Ultima etapă nu este o demonstrație festivă, ci o comparație cu punctul de plecare.
Includeți costul modelului, al infrastructurii, integrărilor, licențelor, evaluării, revizuirii umane, incidentelor și mentenanței. Pentru metodologia completă, folosiți Cât valorează un agent AI: cost total, KPI și randamentul investiției.
O formulă operațională utilă este:
Cost pe rezultat acceptat = costul total al perioadei / numărul rezultatelor acceptate
Comparați-l cu procesul anterior, dar păstrați separat calitatea și riscul. Un cost mai mic nu justifică o rată inacceptabilă de erori sau o expunere juridică mai mare.
Oprirea este un rezultat valid al pilotului. A evitat extinderea unei soluții care nu produce valoare.
Dacă extindeți, documentați:
Nu este necesar un departament mare, dar rolurile trebuie să fie vizibile. Aceeași persoană poate ocupa mai multe roluri, fără ca responsabilitatea să dispară.
În firmele mici, conflictul de roluri merită compensat. Persoana care construiește fluxul nu ar trebui să fie singura care îl declară sigur și profitabil.
NIST AI Risk Management Framework este voluntar și organizează activitatea în patru funcții: Govern, Map, Measure și Manage. Pentru un pilot, traducerea practică este simplă: stabiliți responsabilitățile, înțelegeți contextul și riscurile, măsurați comportamentul, apoi administrați riscul pe durata exploatării. Profilul NIST pentru inteligența artificială generativă, publicat la 26 iulie 2024, completează cadrul cu riscuri specifice sistemelor generative. Aceste documente sunt ghiduri, nu certificări și nu înlocuiesc obligațiile legale.
În Uniunea Europeană, Regulamentul privind inteligența artificială, Regulamentul (UE) 2024/1689, a intrat în vigoare la 1 august 2024 și a devenit, în general, aplicabil la 2 august 2026, cu excepții și calendare specifice. Obligațiile privind alfabetizarea în domeniul AI se aplică din 2 februarie 2025. La data redactării, o firmă trebuie să verifice rolul său în lanț, scopul concret, categoria de risc și legislația conexă, inclusiv protecția datelor, drepturile consumatorilor, dreptul muncii și regulile sectoriale. Clasificarea nu trebuie dedusă doar din eticheta comercială a produsului.
Pentru instruirea echipei, combinați teoria cu procedura internă: ce instrumente sunt aprobate, ce date nu se introduc, cum se verifică un rezultat, cine aprobă o acțiune și cum se raportează un incident. Alfabetizarea AI nu este bifarea unui curs generic.
Un tablou de bord compact ar trebui să separe patru dimensiuni.
„Zero incidente observate” nu înseamnă „risc zero”. Raportați și acoperirea testelor, volumul eșantionat și categoriile care nu au fost încă întâlnite.
Agentul amplifică ambiguitatea. Clarificați mai întâi regulile și proprietatea deciziei.
Produsul trebuie ales după cerințe, date, integrări și risc. Pentru criterii, consultați Cum alegi o platformă AI pentru compania ta.
O demonstrație este selectată. Un pilot include cazuri obișnuite, nereușite și incomode.
Pragurile stabilite după ce ați văzut scorurile favorizează confirmarea ipotezei. Definiți-le înainte și păstrați un set de cazuri nefolosit la reglaj.
Începeți cu citire, simulare și aprobare umană. Extindeți drepturile doar pe baza dovezilor.
Numărul de mesaje, pași sau tokeni nu este un rezultat de business. Măsurați rezultate acceptate, timp, cost, calitate și risc.
Modelele, prețurile, instrumentele și datele se schimbă. Orice schimbare materială trebuie înregistrată și poate cere reevaluare.
Indiferent de decizia de extindere, proiectul ar trebui să lase în urmă:
Aceasta este diferența dintre un experiment și o capabilitate operațională. Experimentul arată că agentul poate produce un rezultat. Capabilitatea arată când îl produce, cu ce cost, în ce limite și cine răspunde când nu îl produce.
Un plan bun nu începe cu numele modelului, ci cu procesul, pragurile și responsabilitatea. Dacă vrei să alegem cazul potrivit, să definim evaluarea și să construim un pilot controlat pentru compania ta, discută cu echipa i8.
