Agenți AI în producție: aprobări, jurnale și costuri sub control

Agenți AI în producție: aprobări, jurnale și costuri sunt cele trei lucruri pe care le pui la punct înainte ca un agent să lucreze în sistemele firmei. Aprobarea umană oprește acțiunile riscante înainte să se întâmple. Jurnalele îți arată după aceea ce a făcut agentul. Limitele de cheltuieli țin factura sub un plafon pe care îl alegi tu.

Un agent AI în producție este un model care lucrează cu datele și instrumentele reale ale firmei, nu într-un mediu de test. Agentul citește înregistrări, ia decizii și poate modifica date fără ca un om să urmărească fiecare pas. De aici vine și riscul, și câștigul de timp.

Acest ghid este partea a treia dintr-o serie despre agenți AI în practică. Prima parte arată cum construiești un prim agent fără cod. A doua parte arată cum scrii unul cu Claude Agent SDK, cu cod pentru un agent propriu. Partea de față pornește de la un agent care funcționează deja și răspunde la întrebarea următoare: cum îl lași să ruleze zi de zi, în siguranță și la un cost cunoscut.

Totul se sprijină pe un proces bine desenat. Dacă procesul nu e clar, niciun set de aprobări nu îl repară. Despre asta găsești mai multe în ghidul despre automatizarea proceselor cu AI, unde procesul vine înaintea modelului.

Regula de bază este simplă: agentul poate citi liber, dar acțiunile care schimbă ceva trec pe la un om. Anthropic scrie în cadrul său pentru agenți siguri și de încredere că oamenii trebuie să păstreze controlul asupra felului în care le sunt urmărite obiectivele. Asta contează mai ales înainte de deciziile cu miză mare.

Exemplul dat de Anthropic e ușor de ținut minte. Un utilizator poate decide că e mereu sigur ca agentul să îi citească calendarul. Același utilizator poate cere totuși aprobare înainte ca agentul să trimită o invitație.

Centrul de ajutor Claude împarte instrumentele în două tipuri:

• Instrumentele de citire (read tools) îi dau lui Claude acces la conținut, de exemplu la căsuța de e-mail sau la capturi de ecran.
• Instrumentele de scriere (write tools) îi permit să facă acțiuni în mediul tău, de exemplu să creeze o invitație în calendar, să șteargă un fișier, să ruleze o comandă sau să dea clic pe ecran.

Instrumentele de scriere poartă un risc mai mare, pentru că o acțiune greșită rămâne în sistem. O citire greșită produce cel mult un răspuns prost, pe care îl vezi. O scriere greșită poate trimite un e-mail unui client sau poate modifica o comandă. De aceea aprobarea se pune pe acțiuni, nu pe agent în întregime.

Pe planurile Team și Enterprise, proprietarul contului setează fiecare acțiune a unui conector pe Always allow, Needs approval sau Blocked. Setarea se aplică la nivelul întregii organizații. Utilizatorii nu o pot suprascrie, deci regula pe care o alegi tu e regula pentru toată echipa.

O împărțire de pornire pentru acțiunile unui agent arată așa:

Claude Cowork are și moduri proprii de aprobare, descrise în ghidul Use Claude Cowork safely. În modul „Automatically approve”, Claude verifică fiecare acțiune din punct de vedere al siguranței înainte să o ruleze. În modul „Skip all approvals”, nimic nu îi mai verifică acțiunile. Cowork cere oricum permisiunea explicită înainte să șteargă definitiv fișiere, în orice mod.

Două detalii merită știute înainte de producție. Computer use, adică lucrul direct pe ecranul tău, nu are un sandbox între Claude și ce e pe ecran și ocolește verificările de permisiuni ale celorlalte instrumente. Iar un atac de tip prompt injection reușește doar când agentul poate citi surse din afara zonei de încredere și poate face acțiuni care te pot compromite. Detaliile le găsești în ghidul nostru despre prompt injection în sistemele conectate la Zoho.

Jurnalele îți spun ce a făcut agentul, când și cu ce cost, iar disponibilitatea lor depinde de plan. Fără ele nu poți răspunde la întrebarea „cine a trimis mesajul ăsta clientului?”. Nici nu poți ști dacă aprobările funcționează.

OpenTelemetry este un standard deschis pentru trimiterea datelor de monitorizare către instrumentele tale de observabilitate. Pe planurile Team și Enterprise, după ce un administrator setează un endpoint, activitatea Claude Cowork poate fi trimisă prin OpenTelemetry. Fluxul conține promptul, apelurile de instrumente, deciziile de aprobare ale oamenilor, tokenii folosiți și costul estimat. Proprietarii pot trimite aceste evenimente și într-un SIEM, sistemul în care echipa IT adună jurnalele de securitate.

Jurnalele de audit sunt disponibile doar pe planul Enterprise. Conform paginii Access audit logs, un export acoperă 180 de zile. În plus, Cowork folosit pe mobil și pe web este capturat în Compliance API.

Diferența practică între planuri e aceasta. Pe Team ai fluxul OpenTelemetry, deci vezi activitatea agentului în timp real, dacă ai unde să o trimiți. Pe Enterprise ai în plus jurnalele de audit exportabile. Dacă agentul tău atinge date de clienți sau bani, ia în calcul de la început unde vor ajunge aceste date și cine le citește.

Costul unui agent depinde în primul rând de modelul ales, apoi de câți tokeni consumă fiecare sarcină. Un agent care rulează sute de sarcini pe zi poate costa de câteva ori mai mult pe un model scump decât pe unul ieftin. Prețurile de mai jos vin din pagina oficială cu modelele Claude, în dolari, fără taxe.

Anthropic recomandă să pornești cu Claude Opus 5.5 pentru majoritatea sarcinilor, dacă nu știi ce model să alegi. Potrivit anunțului Anthropic, Opus 5.5 costă cu 40% mai puțin decât Opus 5. Alte două pârghii sunt prompt caching, adică reutilizarea părții fixe a promptului, și procesarea în lot, care rulează sarcinile fără grabă, la preț redus.

Plafonul îl pui în Console. Conform documentației despre workspaces, firma își poate seta o limită lunară proprie, sub plafonul nivelului în care se află. Fiecare workspace poate primi propriile limite și alerte. Un agent pe workspace-ul lui înseamnă un buget separat și o alertă separată.

Mai e un cost ascuns: schimbarea modelului. Claude Haiku 4.5 va fi retras nu mai devreme de 15 octombrie 2026, deci un agent legat de el va trebui mutat. Ghidul despre migrarea la Claude Opus 5.5 și ce verifici înainte arată cum planifici o astfel de trecere.

Un set de teste este o listă fixă de sarcini pe care o rulezi pe agent înainte de lansare și după fiecare schimbare. Anthropic scrie în articolul despre evaluarea agenților AI că între 20 și 50 de sarcini simple, luate din eșecuri reale, sunt un început foarte bun. Nu ai nevoie de sute de cazuri ca să pornești.

Sursa cea mai bună pentru teste sunt greșelile pe care echipa ta le vede deja. Un tichet trimis la departamentul greșit e un test. Un e-mail la care clientul a primit un răspuns incomplet e alt test. Fiecare caz are o intrare clară și un rezultat așteptat pe care îl poți verifica.

Setul de teste îți arată și cât de des greșește agentul când rulează de mai multe ori. Același articol Anthropic dă un exemplu cu un agent care lucrează cu clienții. Dacă reușește în 75% din încercări, reușește de trei ori la rând doar în aproximativ 42% din cazuri.

Pentru un proprietar de firmă, cifra asta schimbă decizia. Un agent care pare bun într-o demonstrație poate greși des când vorbește cu zeci de clienți pe zi. Setul de teste îți spune dacă agentul e gata să lucreze singur sau dacă acțiunile lui trebuie să rămână pe „Needs approval”.

Să luăm un agent care citește tichetele noi din Zoho Desk, caută istoricul clientului în Zoho CRM și propune un răspuns. Firma folosește Claude pe planul Team, cu conectorii Zoho legați. Configurarea poate fi făcută în cinci pași.

1. Aprobările. Citirea tichetelor și a înregistrărilor din CRM stă pe Always allow. Salvarea răspunsului și schimbarea statusului stau pe Needs approval. Ștergerea sau unirea contactelor stă pe Blocked.
2. Jurnalele. Administratorul setează un endpoint OpenTelemetry. Echipa vede apoi fiecare apel de instrument, fiecare aprobare dată sau refuzată și costul estimat.
3. Costurile. Dacă agentul rulează prin API, el primește un workspace separat în Console, cu limită lunară și alertă.
4. Testele. Echipa strânge 30 de tichete din ultimele luni care au fost direcționate greșit sau au primit răspunsuri slabe și le rulează pe agent.
5. Revizia. După o lună, cineva citește jurnalele și decide ce acțiuni pot trece pe Always allow.

La Svennis, când livrăm un agent pe Claude legat de Zoho, pornim cu toate acțiunile de scriere pe Needs approval. Trecem o acțiune pe Always allow doar după ce jurnalele arată că oamenii au aprobat aceeași decizie, fără modificări, de fiecare dată.

Ordinea contează. Mai întâi dai încredere pe acțiunile cu risc mic, apoi extinzi. Un agent care pornește cu totul pe Always allow nu îți lasă nicio dovadă că merita încrederea asta.

Pentru o firmă din România, AI Act aduce două obligații relevante pentru agenți: măsuri de sprijin pentru alfabetizarea în AI a oamenilor și, dacă firma este furnizorul agentului, transparența față de cei care vorbesc cu el. Textul adnotat în română îl găsești în AI Act (Regulamentul UE 2024/1689).

Articolul 4, în forma modificată prin Regulamentul (UE) 2026/1744 și în vigoare de la 27 iulie 2026, le cere furnizorilor și celor care folosesc sisteme AI să sprijine alfabetizarea în AI a personalului. Regula nu impune un nivel garantat. Comisia Europeană precizează în întrebările frecvente despre alfabetizarea în AI că nu e nevoie de niciun certificat. O politică AI despre ce pot introduce angajații în Claude e un punct de pornire practic.

Articolul 50(1) privește sistemele care interacționează cu oameni și se aplică de la 2 august 2026. Obligația de transparență cade pe furnizorul sistemului, conform explicațiilor Comisiei despre Articolul 50. O firmă care își construiește propriul agent pentru clienți poate fi ea însăși furnizorul acelui sistem. Acesta e un punct de confirmat cu un avocat înainte de lansare.

Dacă lucrezi și cu clienți din Marea Britanie, AI Act se aplică în continuare firmei tale, ca firmă stabilită în UE, iar regulile britanice pentru AI le verifici separat. Pentru contextul legal românesc mai larg, vezi pagina despre cadrul legal AI în România.

Un agent AI e gata de producție când fiecare dintre cele șase puncte de mai jos are un răspuns scris. Lista poate fi folosită și ca ordine de zi pentru ședința în care decizi lansarea.

Proprietarul e punctul pe care firmele îl sar cel mai des. Ghidurile Anthropic arată că utilizatorul rămâne responsabil pentru acțiunile pe care Claude le face în numele lui. Asta include mesajele trimise și acțiunile sarcinilor programate, care rulează singure chiar și când calculatorul e oprit. Cineva din firmă trebuie să aibă numele pe agent.

Primul pas practic este să alegi un singur agent și să completezi lista de verificare pentru el. Nu porni cu trei agenți deodată. Un agent bine controlat îți dă modelul pe care îl copiezi pentru următorii.

Pașii, în ordine:

1. Numește proprietarul agentului și scrie ce procese atinge.
2. Împarte acțiunile în citire și scriere și setează-le pe Always allow, Needs approval sau Blocked.
3. Pornește jurnalele înainte de prima sarcină reală, nu după primul incident.
4. Pune agentul pe un workspace separat, cu limită lunară și alertă.
5. Strânge între 20 și 50 de cazuri reale pentru setul de teste.
6. Pune în calendar prima revizie, la o lună după lansare.

Dacă nu știi de unde să începi, evaluarea pregătirii companiei tale pentru AI îți arată ce procese sunt potrivite pentru un agent și ce lipsește încă din date și din organizare.