8 din 10 companii trimit agenți AI în producție fără controalele de bază. Poarta de go-live e cea care lipsește.

Demo-ul a mers impecabil. Agentul a citit cererea, a căutat în documente, a formulat răspunsul, a trimis emailul. Sala a aplaudat. Cineva a spus „hai să-l punem pe live săptămâna viitoare”.

Întrebarea pe care nu a pus-o nimeni în sală: ce poate face agentul ăsta luni dimineață, la 9:14, când primește o cerere pe care nu a văzut-o nimeni în timpul testelor?

Nu este o întrebare retorică. Este singura întrebare care separă un demo de un sistem de producție. Și, conform datelor din 2026, este o întrebare la care majoritatea organizațiilor nu au răspuns înainte de go-live.

Cifrele: decalajul dintre încredere și realitate

Raportul State of AI Agent Security 2026 a măsurat exact acest moment — ce există în companie înainte ca un agent să primească acces la sisteme reale.

Tradus: o parte semnificativă din flota de agenți ajunge de rutină în producție fără controale adecvate. Și mai relevant este ce se află, concret, în acele controale. Întrebate ce au în loc înainte ca un agent să intre pe live, organizațiile au răspuns astfel — niciun control nu este folosit nici măcar de 40% dintre ele:

• O persoană nominalizată, responsabilă de comportamentul agentului — 37,8%
• Review de securitate din partea IT sau a CISO — 35%
• Un plan pentru modul în care agentul procesează date sensibile — 33%
• Controale de acces la date specifice acelui agent — 32%
• Scop definit al ceea ce agentul are voie să acceseze — 30,5%

Citiți ultima linie încă o dată. Mai puțin de o treime dintre organizații au definit explicit, înainte de go-live, ce are voie să acceseze agentul.

Raportul numește fenomenul „decalajul dintre încredere și realitate, care se lărgește”: flotele de agenți s-au dublat aproximativ din decembrie 2025, încrederea în securitate a crescut, dar acoperirea de monitorizare, structurile de responsabilitate și controalele de pre-deployment aproape că nu s-au mișcat.

Costul se vede deja. Raportul IBM Cost of a Data Breach 2026 arată că aproximativ una din cinci organizații a raportat o breșă a modelelor sau aplicațiilor sale AI — iar 92% dintre acestea nu aveau controale de acces AI adecvate.

Diferența dintre „merge în demo” și „gata de producție”

Un agent este gata de producție când trei lucruri sunt adevărate simultan: permisiunile sunt limitate la minimul necesar, un om îl poate opri în mijlocul unei acțiuni, și fiecare acțiune este logată undeva unde chiar se uită cineva. Dacă oricare dintre cele trei lipsește, agentul nu e gata. Indiferent cât de bine a mers demo-ul.

Un agent demo-ready gestionează scenariile pe care i le-ai arătat în timpul testelor. Un agent production-ready are permisiuni documentate, un kill switch care funcționează și monitorizare care l-ar prinde făcând ceva în afara scopului — inclusiv în scenarii la care nu s-a gândit nimeni să le testeze.

Un agent care trece un demo poate, în producție, să trimită emailul greșit clientului greșit sau să apeleze un API până consumă bugetul pe o lună. Nu pentru că e prost construit, ci pentru că realitatea conține cazuri pe care testarea nu le-a atins.

Poarta de go-live: ce trebuie să fie adevărat înainte

Nu este un document de politici. Este o listă de condiții tehnice verificabile, trecute înainte ca agentul să primească drept de scriere.

1. Scopul este definit tehnic, nu declarativ. Nu „agentul nu ar trebui să acceseze sistemul HR”, ci: conexiunea către sistemul HR nu există în configurația agentului. Diferența dintre o regulă și o arhitectură este diferența dintre o speranță și o garanție.
2. Permisiuni la nivel de agent, nu la nivel de echipă. Fiecare agent are propria identitate și propriul set de credențiale, revocabile independent. Nu un cont de serviciu comun folosit de trei automatizări.
3. Kill switch testat — inclusiv la mijlocul unei acțiuni. Întrebarea corectă nu este „avem un buton de oprire?”, ci „butonul funcționează dacă agentul este în mijlocul unui apel către un sistem extern?” Acestea sunt două lucruri diferite.
4. Cale de retragere definită. Când agentul eșuează, ce se întâmplă? Dacă răspunsul este un mesaj de eroare fără pas următor, sistemul are o lacună structurală. Calea de fallback se definește înainte de lansare, nu după primul incident.
5. Lansare în etape, nu dintr-o dată. Agentul rulează mai întâi pe trafic real, dar cu acțiunile scrise doar într-un log — fără efecte. Apoi primește o fracțiune mică din cereri, în timp ce fluxul vechi rulează în paralel. Extinderea vine după dovezi, nu după entuziasm.
6. Un nume pe listă. O persoană responsabilă de comportamentul agentului, identificată înainte de go-live. Nu „echipa IT”. Un om.
7. Loguri pe care cineva chiar le citește. Un audit trail pe care nu îl deschide nimeni nu este un control. Este o arhivă.

De ce contează ordinea

Guvernanța adăugată pe un sistem deja aflat în producție costă cu un ordin de mărime mai mult decât guvernanța construită înainte de scalare. Iar în mediile reglementate, retrofitting-ul întârzie producția cu luni.

Motivul este simplu: controalele de acces, identitatea per agent și logarea nu sunt funcționalități care se adaugă la final. Sunt decizii de arhitectură. Schimbarea lor după ce agentul rulează înseamnă reconstruirea straturilor de sub el.

Contextul face întrebarea urgentă. Microsoft a început în octombrie lansarea Work IQ, care conectează Copilot și agenții autonomi direct la date de business live din Dynamics 365 și Power Platform — iar recomandarea explicită din materialele de lansare este să proiectezi permisiunile agentului și indicatorii de succes înainte de a-l activa pe date de producție.

Cum construim noi

La Visual AI Labs, poarta de go-live nu este un pas de proces pe care îl facem dacă avem timp. Este parte din arhitectură, de la prima linie de cod.

• Limite de acces tehnice. Dacă agentul nu are nevoie de un sistem, conexiunea nu există — nu este doar interzisă într-un document.
• Identitate distinctă per agent. Separată, revocabilă independent, cu permisiuni limitate la minimul necesar pentru sarcina lui.
• Kill switch testat pe scenarii reale, cunoscut de cel puțin doi oameni din organizația ta.
• Audit trails complete, cu fiecare acțiune logată înainte de execuție — ce a accesat, ce a decis, ce a executat, când.
• Escaladare definită înainte de lansare, nu improvizată după primul caz pe care agentul nu l-a putut gestiona.
• Lansare în etape, cu rulare în paralel și extindere pe bază de dovezi.

Date în UE, conformitate GDPR și AI Act proiectată din start, cod menținabil pe termen lung. Livrăm rapid — fără să înlocuim sistemele care funcționează deja la tine.

Dacă ai un agent care urmează să intre în producție

Întrebarea nu este dacă sistemul tău este sigur. Este dacă poți răspunde, acum, la trei lucruri: ce are voie agentul să acceseze, cine îl poate opri și unde se uită cineva la ce a făcut.

Dacă oricare răspuns este „ar trebui să verific”, merită o discuție înainte de go-live, nu după. Scrie-ne pe pagina de contact cu o descriere scurtă a agentului și a sistemelor la care ar urma să aibă acces. Îți răspundem cu o evaluare sinceră a ce am verifica primii.

Scrie-ne pe pagina de contact →

Surse verificate: Gravitee — The State of AI Agent Security 2026 (aprilie 2026); IBM — Cost of a Data Breach Report 2026; AI Agent Store — AI Agents News, săptămâna 13 oct. 2026 (Microsoft Work IQ); Superblocks — AI Agent Deployment Best Practices 2026; AY — AI Agent Production-Readiness Audit Checklist (2026).