52% dintre companii spun că au agenți AI în producție. Doar 5% dintre liderii de inginerie care rulează acei agenți își pun problema dacă aceștia apelează instrumentele corecte. Diferența asta îți spune cam tot ce trebuie să știi despre unde e de fapt industria.
Cifrele vin din două surse credibile. Studiul ROI al Google Cloud din septembrie 2025 a chestionat 3.466 de lideri seniori din 24 de țări și a constatat că peste jumătate au pus agenți în producție. Sondajul Cleanlab din august 2025, pe 95 de lideri de inginerie cu agenți live în producție, a constatat că aproape nimeni nu se concentrează pe acuratețea apelării instrumentelor, singura capabilitate care separă un agent util de un chatbot cu pași în plus.
Concluzii cheie
- 52% dintre companii raportează agenți AI în producție, dar doar 5% urmăresc acuratețea apelării instrumentelor (Google Cloud 2025; Cleanlab 2025).
- Doar 16% dintre organizații rulează agenți care acoperă mai multe echipe sau sisteme; majoritatea sunt asistenți cu o singură funcție, etichetați drept "agent".
- Integrarea cu sistemele existente, nu calitatea modelului, e provocarea numărul unu (46%); observabilitatea e principala îmbunătățire planificată (63%).
- 70% dintre companiile reglementate își reconstruiesc stiva de agenți la fiecare trei luni sau mai des, ceea ce face din stabilitate o excepție.
- Agentul Klarna a economisit, conform relatărilor, 60 de milioane de dolari, apoi compania a renunțat la suportul exclusiv AI în 2025: agenții fără o cale de escaladare către un om eșuează în public.
De ce există o prăpastie între "pus în producție" și "fiabil"?
Pentru că în "pus în producție" intră orice. Când Google Cloud raportează că 52% dintre companii au agenți puși în producție, cifra aia include și un bot de suport care răspunde la FAQ-uri, și un flux de lucru în mai mulți pași care procesează tranzacții financiare. Nu sunt același lucru.
Raportul 2026 State of AI Agents detaliază: 57% dintre organizații rulează fluxuri de agenți cu mai mulți pași, dar doar 16% au agenți care acoperă mai multe echipe sau sisteme. Restul sunt asistenți cu o singură funcție, etichetați drept "agent". Și deși 80% raportează un ROI măsurabil, majoritatea câștigurilor vin din automatizarea unor sarcini repetitive de care s-ar putea ocupa un webhook bine configurat. Problemele grele, cele care cer unui agent să raționeze asupra contextului, să aleagă instrumentul corect și să acționeze în siguranță în limite reglementate, rămân în mare parte nerezolvate.
De ce se strică majoritatea agenților în producție?
Trei tipare apar în fiecare sondaj despre AI în companii publicat în ultimul an.
- Stiva nu stă pe loc. 70% dintre companiile reglementate își reconstruiesc stiva de agenți AI la fiecare trei luni sau mai des, conform Cleanlab. Asta nu e iterație, e instabilitate. Un respondent a descris o migrare de la LangChain la Azure în două luni, apoi a luat în calcul revenirea.
- Integrarea e adevărata problemă grea. 46% dintre respondenți menționează integrarea cu sistemele existente drept provocarea lor principală. Nu calitatea modelului, nu prompturile. Blocajul e să conectezi un LLM la un CRM, un API intern sau un sistem de conformitate într-un mod sigur, auditabil și fiabil.
- Nimeni nu vede ce se întâmplă. Mai puțin de una din trei echipe e mulțumită de observabilitatea și guardrail-urile ei, iar 63% plănuiesc să rezolve asta în perioada următoare. Dacă nu poți urmări ce a făcut agentul tău, de ce și dacă a fost corect, ai un prototip cu utilizatori, nu un sistem de producție.
Cum arată un agent de nivel de producție?
Arată ca o problemă de inginerie rezolvată cu inginerie, nu cu prompturi. La Systemartis construim agenți pentru medii în care o greșeală are consecințe reale, în banking reglementat, telecom la scară mare și e-commerce de volum mare. Când construim servere MCP pentru arhitecturi agentice, patru cerințe sunt nenegociabile:
- Scheme de instrumente validate. Fiecare acțiune pe care o poate executa agentul e definită printr-un contract API strict. Dacă schema nu o permite, nu se întâmplă.
- Limite ale datelor. Agentul ajunge la date sensibile doar prin endpointuri MCP controlate, cu propagare corectă a autentificării. Niciun acces brut la baza de date, nicio autoritate ambientală.
- Puncte cu om în buclă. Acțiunile care modifică starea cer confirmare explicită. Colectarea datelor e automatizată; deciziile nu.
- Urme de audit. Fiecare apel de instrument, fiecare răspuns, fiecare punct de decizie e logat. În industriile reglementate, "a făcut-o AI-ul" nu e o explicație acceptabilă.
Le-am aplicat când am construit un agent de logistică pentru un client de e-commerce. Interoghează API-uri de curierat și informează proactiv clienții pe WhatsApp și Telegram, gestionând în jur de 40% din tichetele "unde e comanda mea?" care înainte cereau un om. Funcționează pentru că autoritatea lui e delimitată precis: poate citi statusul livrării și trimite actualizări pe bază de șabloane. Nu poate modifica comenzi, emite refunduri sau atinge ceva în afara acelui scop. Diferența dintre asta și un demo nu ține de sofisticare. Ține de disciplină.
Care e lecția de la Klarna?
Că un agent fără limite va da la un moment dat peste un caz pe care nu-l poate gestiona, iar eșecul va fi public. AI-ul Klarna a gestionat două treimi din întrebările clienților pentru 150 de milioane de utilizatori, echivalentul a 853 de angajați cu normă întreagă, și a scăzut timpul de rezolvare de la 11 minute la sub 2, economisind, conform relatărilor, 60 de milioane de dolari.
Apoi, în mai 2025, CEO-ul Klarna a recunoscut că firma mersese prea departe cu serviciul exclusiv AI și a anunțat revenirea la un suport hibrid, om și AI. Lecția nu e că agenții eșuează. E că un agent fără cale de escaladare către un om transformă un caz extrem într-un titlu de ziar. Klarna a putut absorbi asta. Majoritatea companiilor nu pot.
Cum construiești agenți care supraviețuiesc contactului cu realitatea?
Pornește de la modul de eșec, nu de la calea fericită. Organizațiile care scot valoare reală au câteva trăsături comune care n-au nimic de-a face cu alegerea modelului:
- Întreabă ce se întâmplă când agentul apelează instrumentul greșit sau își depășește autoritatea, înainte să-l pună în producție.
- Tratează MCP ca pe un tipar arhitectural, nu ca pe un buzzword: un server care impune ce poate cere și face agentul, astfel încât agentul să nu vorbească niciodată direct cu baza de date.
- Măsoară fiabilitatea, nu doar capabilitatea. Capabilitatea e "poate agentul să îndeplinească această sarcină?". Fiabilitatea e "o face corect aproape de fiecare dată, și ce se întâmplă în restul cazurilor?".
- Construiesc anticipând churn-ul trimestrial, pentru că un cuplaj strâns cu un singur framework sau furnizor e o vulnerabilitate când majoritatea stivelor sunt reconstruite la fiecare trei luni.
Companiile care vor conduce nu vor fi cele care pun în producție cei mai mulți agenți. Vor fi cele care pun în producție agenți care funcționează când contează.