Când agentul cumpără pentru noi: bugete, plăți și limite de autonomie

27.09.2026

# Când agentul cumpără pentru noi: bugete, plăți și limite de autonomie

Un agent AI poate compara oferte, poate completa un coș și, în anumite integrări, poate iniția pași din procesul de plată. Pentru o firmă mică sau mijlocie, întrebarea utilă nu este dacă agentul „știe să cumpere”, ci ce decizii îi putem delega, în ce limite și cine verifică rezultatul. O comandă greșită poate însemna o dublă plată, un abonament nedorit, o livrare la altă adresă sau un furnizor neaprobat.

Acest articol privește firma în rol de cumpărător. Pentru perspectiva magazinului care vinde către agenți, vedeți articolul despre vânzarea de software ca serviciu (SaaS) către agenți AI. Pentru controlul accesului și jurnalizarea acțiunilor, consultați articolul despre permisiuni și audit. Exemplele de bugete și praguri de mai jos sunt scenarii de lucru, nu recomandări universale sau plafoane prevăzute de lege.

Ce poate face astăzi un agent și unde începe răspunderea firmei

În septembrie 2026 există specificații și programe pentru tranzacții asistate de agenți, dar disponibilitatea lor depinde de furnizor, țară, comerciant, procesator și contract. De exemplu, specificația Agentic Payment Protocol (AP2) a Google distinge mandatul pentru conținutul comenzii de mandatul pentru plată. Documentația Visa Intelligent Commerce descrie instrucțiuni autentificate ale utilizatorului, credențiale de plată limitate și controale pentru comerciant și sumă. Aceste descrieri arată direcția tehnică, nu că orice IMM din România poate activa mâine toate funcțiile.

Și produsele se schimbă. În actualizarea sa din 24 martie 2026, OpenAI a explicat că versiunea inițială de Instant Checkout nu oferea flexibilitatea dorită și că pune accentul pe descoperirea produselor și pe experiențele de checkout ale comercianților. Prin checkout înțelegem pașii finali ai cumpărării, în care sunt confirmate coșul, livrarea și metoda de plată. Așadar, înaintea unui proiect, verificați fluxul efectiv disponibil la furnizorul ales, nu doar numele protocolului din prezentări.

Pentru a decide ce automatizăm, separăm patru etape:

Cercetare și recomandare. Agentul caută produse, compară prețuri, disponibilitate, termene și condiții. Nu creează încă obligații comerciale.
Pregătirea comenzii. Agentul completează o cerere internă, un coș sau o comandă de achiziție. O cerere internă nu este neapărat o comandă acceptată de furnizor.
Plasarea comenzii și plata. Furnizorul poate accepta comanda, iar banca sau procesatorul poate autoriza ori încasa plata. Acceptarea comenzii și confirmarea plății sunt stări diferite.
Recepție și reconciliere. Firma verifică bunurile ori serviciile primite, factura, suma finală și eventualele retururi. „Plătit” nu înseamnă automat „livrat corect”.

O autonomie bună pentru etapa 1 nu justifică automat autonomie pentru etapa 3. Riscul crește când acțiunea produce cheltuieli sau obligații greu de desfăcut.

O scară practică de autonomie

Următoarea scară este un instrument editorial pentru proiectare, nu un standard juridic:

Nivelul 0, informare: agentul oferă opțiuni și argumente; omul face restul.
Nivelul 1, pregătire: agentul construiește cererea și coșul; omul verifică și trimite.
Nivelul 2, execuție aprobată: omul aprobă un conținut precis al comenzii; sistemul o transmite, apoi cere plata prin fluxul acceptat de bancă sau procesator.
Nivelul 3, reaprovizionare limitată: agentul poate comanda repetitiv numai articole preaprobate, de la furnizori preaprobați, în limite automate de valoare și frecvență. Excepțiile merg la om.
Nivelul 4, cumpărare și plată delegată în limite: agentul poate finaliza o tranzacție printr-o integrare de plată care aplică instrucțiuni și limite verificabile. Acest nivel cere o implementare compatibilă, verificări de securitate și acordul instituțiilor implicate; nu rezultă doar din instalarea unui model AI.

Pentru majoritatea IMM-urilor, un pilot la nivelurile 1 sau 2 oferă date despre calitatea recomandărilor și a operațiunilor, păstrând aprobarea umană pentru fiecare achiziție. Studiul academic τ-bench arată de ce trebuie testată respectarea regulilor pe cazuri concrete: agenții evaluați au avut rezultate inegale la sarcini cu instrumente și politici de domeniu. Rezultatul este despre scenariile benchmarkului, adică ale setului de teste standardizate, nu o rată de eroare valabilă pentru toate sistemele comerciale.

Bugetul trebuie aplicat de sistem, nu doar scris în prompt

Instrucțiunea trimisă modelului, numită prompt, poate include „nu cheltui peste 300 lei”. Aceasta poate ghida agentul, dar controlul real trebuie să existe într-o componentă separată care verifică tranzacția înainte de plasarea comenzii sau plății. Agentul propune; sistemul de achiziții decide dacă propunerea încape în politica firmei. Aceasta este o alegere de arhitectură susținută și de riscurile observate în cercetările despre respectarea politicilor de către agenți și în ghidul OWASP pentru securitatea agenților AI.

Politica poate cuprinde, după caz:

furnizori validați, identitatea lor contractuală și conturile sau domeniile oficiale;
categorii, articole și variante permise, inclusiv interdicții pentru abonamente noi ori reînnoire automată;
plafon pe comandă, pe utilizator, pe departament și pe perioadă, plus reguli pentru tranzacții repetate și pentru împărțirea aceleiași achiziții în comenzi mai mici;
prețul total acceptabil, în moneda aprobată, cu taxe, transport și costuri suplimentare cunoscute la checkout;
adresa de livrare, termenul maxim, condițiile de retur și valabilitatea aprobării;
persoana care aprobă, pragurile de escaladare și cine poate schimba politica.

Politica trebuie verificată pe date structurate primite din coș sau ofertă, nu pe rezumatul liber al agentului. În plus, bugetul se rezervă când comanda este în curs, pentru ca două sesiuni simultane să nu cheltuie fiecare aceeași sumă disponibilă. După un rezultat confirmat, rezervarea se transformă în cheltuială înregistrată sau se eliberează, după caz. Dacă rezultatul este necunoscut, rezervarea rămâne până la clarificare, pentru a evita cheltuirea din nou a aceleiași sume. Aceste reguli sunt recomandări de proiectare, nu funcții pe care toate platformele le oferă implicit.

Scenariu ipotetic: un birou alocă 2.000 lei pe lună consumabilelor, permite maximum 300 lei pe comandă și acceptă doar produse dintr-un catalog și furnizori validați. Agentul găsește articole de 280 lei, dar transportul ridică totalul la 315 lei. Comanda nu trece automat, chiar dacă prețul produselor este sub prag. Dacă, după aprobare, se schimbă cantitatea, furnizorul, adresa sau totalul, sistemul cere o verificare nouă. Nici împărțirea aceleiași achiziții în două comenzi nu trebuie să ocolească pragul de aprobare. Cifrele sunt doar pentru ilustrarea mecanismului.

Aprobarea trebuie legată de comanda exactă

Un buton „Aprobă achiziția” este ambiguu dacă între aprobare și plată coșul se poate modifica. Persoana care aprobă ar trebui să vadă cel puțin comerciantul, articolele și cantitățile, costul total și moneda, livrarea, eventualele costuri recurente și termenul până la care aprobarea este valabilă. Sistemul păstrează versiunea aprobată și o compară cu versiunea transmisă. O schimbare relevantă oprește tranzacția sau trimite cererea din nou la aprobare.

Principiul apare și în AP2, unde mandatul de plată este legat de un checkout definit. Este util să distingem mandatul comercial, adică permisiunea firmei de a cumpăra în anumite condiții, de autentificarea plății, realizată în cadrul serviciului de plată. O aprobare internă nu înlocuiește autentificarea cerută de banca sau procesatorul de plăți.

În UE, Directiva PSD2 și Regulamentul delegat (UE) 2018/389 stabilesc cadrul pentru autentificarea strictă a clienților în situațiile prevăzute de lege. Aceasta folosește cel puțin două elemente independente, din categorii precum ceva ce utilizatorul știe, ceva ce deține și o caracteristică biometrică. Când se aplică autentificarea strictă pentru o plată electronică la distanță, articolul 5 din regulament cere legarea codului de suma și beneficiarul acceptate, iar schimbarea acestora îl invalidează. Există excepții în condiții definite, inclusiv pentru anumite procese corporative securizate, însă nu trebuie presupus că orice plată între firme (B2B) este scutită. Fluxul concret se validează cu prestatorul de servicii de plată și, la nevoie, cu consilierii juridici ai firmei.

Datele de card și autentificarea nu trebuie puse în conversația agentului

Un agent care primește prin chat numărul cardului, codul de securitate sau coduri de autentificare creează un risc inutil. Opțiunea mai sigură este o integrare de plată printr-un prestator autorizat, cu credențiale limitate sau tokenuri. Un token de plată este o reprezentare folosită în fluxul de plată în locul datelor brute ale cardului; valoarea sa depinde de scopul și restricțiile stabilite de furnizor. Visa descrie tokenuri specifice agentului și verificări ale instrucțiunii înainte de emiterea credențialelor, iar OpenAI descrie în specificația sa o cerere de plată delegată cu plafon și expirare. Sunt modele tehnice, nu garanții că orice procesator sau comerciant le acceptă.

Înainte de integrare, întrebați prestatorul: cine deține datele sensibile, ce permisiuni are tokenul, ce comerciant și plafon poate folosi, când expiră, cum se revocă, cum se tratează contestările și ce se întâmplă dacă plata reușește dar confirmarea comenzii întârzie. Controlați separat identitatea angajatului care cere achiziția și identitatea aplicației care apelează API-ul, interfața prin care sistemele software schimbă date și execută operațiuni.

Ce poate merge greșit, chiar cu un buget corect

Instrucțiuni ascunse în surse externe. O pagină de produs, un PDF de ofertă sau un e-mail de la furnizor poate conține text care încearcă să schimbe comportamentul agentului. Aceasta este o injecție de prompt indirectă: datele citite de agent sunt tratate greșit drept instrucțiuni. AgentDojo a studiat atacuri de acest tip în medii cu instrumente. Soluția practică este să tratăm ofertele ca date neverificate și să nu le permitem să modifice politica, conturile ori aprobările.

Oferte care nu mai sunt valabile. Prețul, stocul, transportul sau cursul se pot schimba între comparație și checkout. Verificați din nou coșul final. Dacă totalul sau un termen esențial diferă de versiunea aprobată, cereți o decizie nouă.

Comenzi duplicate. O conexiune întreruptă poate determina agentul să retrimită cererea fără să știe că prima a reușit. Folosiți un identificator unic al cererii și mecanisme de idempotență, adică repetarea aceleiași solicitări nu produce o a doua achiziție. Documentația Stripe explică principiul pentru cererile sale API. Cheia trebuie reutilizată pentru aceeași operațiune, iar integrarea trebuie să respecte perioada de păstrare și regulile prestatorului. Protecția unei cereri de plată nu elimină automat duplicatele din sistemul de comenzi. Verificați apoi independent starea comenzii și a plății; un răspuns lipsă nu este dovadă de eșec.

Costuri care continuă după prima plată. Un abonament SaaS poate avea reînnoire automată, tarif pe utilizator sau consum variabil. Un plafon pe prima tranzacție nu limitează neapărat cheltuielile viitoare. Un asemenea contract cere o regulă separată pentru durata abonamentului, modificări, reziliere și titularul contului.

Date personale și comerciale expuse. Numele angajaților, adresele de livrare și facturile pot ajunge la servicii externe. Comitetul european pentru protecția datelor explică pentru firme mici principiul minimizării datelor. Transmiteți agentului și furnizorilor doar datele necesare scopului, stabiliți retenția și verificați contractele și accesul.

Cine oprește agentul și cine rezolvă o achiziție problematică

Înainte de lansare, desemnați un responsabil de achiziții și un înlocuitor. Ei trebuie să poată suspenda comenzile noi și să ceară revocarea credențialelor delegate. Dacă verificarea bugetului sau a aprobării nu funcționează, sistemul oprește execuția și trimite cazul unui om. Acest comportament este numit fail closed: lipsa unei verificări valide blochează acțiunea. OWASP recomandă explicit această regulă pentru operațiunile cu impact ridicat.

Oprirea agentului nu anulează automat o comandă deja acceptată sau o plată deja executată. Pentru acestea trebuie verificată situația la furnizor și la prestatorul de plată, apoi urmat fluxul aplicabil de anulare, retur ori rambursare. În pilot, stabiliți clar cine preia fiecare excepție și până când trebuie clarificată.

Recomandăm ca procesul să urmărească achiziția până la închidere:

Comanda: ce a acceptat furnizorul, ce identificator are și dacă există livrări parțiale.
Plata: ce sumă este doar autorizată sau rezervată și ce sumă a fost efectiv încasată, conform stărilor prestatorului.
Recepția: ce s-a primit și dacă articolele, cantitățile și serviciile corespund comenzii.
Factura și ajustările: dacă documentele și sumele coincid, iar eventualele rambursări sunt confirmate efectiv.

Această corelare se numește reconciliere. Un mesaj al agentului precum „am rezolvat returul” nu este suficient pentru a închide cazul. Păstrați confirmările furnizorului și ale prestatorului de plată, legate de aceeași achiziție. De exemplu, documentația Stripe despre urmărirea plăților descrie verificarea rezultatului pe baza notificărilor trimise către server. Pentru o firmă cumpărătoare, datele disponibile pot proveni și din platforma de achiziții, portalul băncii sau confirmările furnizorului.

Trei exemple, trei niveluri de control

Consumabile recurente, cu specificații stabile. Agentul poate compara ofertele dintr-un catalog intern și pregăti o reaprovizionare. După un pilot cu aprobare umană, firma poate evalua comenzi automate la furnizori validați, cu plafon agregat și verificare la recepție. Excepțiile de preț, stoc sau livrare merg la om.

Licențe software. Agentul poate propune planuri și simula costul pentru numărul estimat de utilizatori, dar trebuie verificate drepturile de utilizare, accesul la date, durata contractului și costurile recurente. De regulă, aprobarea implică și responsabilul IT sau persoana care administrează bugetul, nu doar solicitantul.

Echipament sau serviciu cu condiții negociate. Agentul poate aduna specificații și compara oferte, însă diferențele de garanție, service, integrare și termene contractuale pot cântări mai mult decât prețul afișat. Aici este prudent să păstrăm decizia și angajamentul comercial la oameni.

Acestea sunt scenarii de proiectare, nu afirmații că un anumit comerciant sau procesator oferă astăzi automatizarea descrisă.

Un pilot măsurabil pentru un IMM

Alegeți un singur proces îngust. De exemplu, consumabile cu catalog stabil și furnizori cunoscuți. Notați cine solicită, aprobă, plătește și confirmă recepția în procesul actual.
Rulați mai întâi fără cumpărare. Agentul pregătește recomandări și coșuri de probă. Comparați prețul total, disponibilitatea, specificațiile și timpul de lucru cu achizițiile făcute de oameni.
Scrieți politica în sistem. Definiți furnizorii, articolele, plafoanele, excepțiile, aprobatorii și comportamentul la erori. Testați coșuri modificate, prețuri peste plafon, concurența între două cereri și mesaje malițioase din pagini.
Activați o etapă cu aprobare. Păstrați aprobarea legată de coșul final și folosiți fluxul de plată convenit cu prestatorul. Înregistrați propunerea, verificările, aprobarea, comanda, plata și rezultatul fără a copia în jurnale date sensibile inutile.
Măsurați și extindeți numai pe dovezi. Urmăriți timpul economisit net de revizuire, prețul total, comenzile greșite sau duplicate, excepțiile, retururile și gradul de respectare a politicii. Chiar dacă într-un pilot nu observați achiziții neautorizate, asta nu dovedește că riscul este zero. Revizuiți controalele când se schimbă furnizorul, modelul, instrumentele sau politica.

La final, firma trebuie să poată răspunde simplu: cine a cerut achiziția, cine a aprobat ce variantă, ce regulă a permis-o, ce sumă s-a plătit și ce s-a primit? Dacă răspunsul necesită reconstruirea conversației agentului, procesul încă nu este suficient de controlat.

Concluzie

Agenții pot reduce munca repetitivă din achiziții, mai ales la căutare, comparație și pregătirea comenzilor. Autonomia de cumpărare se acordă treptat, în funcție de risc și de ce pot verifica sistemele, furnizorii și prestatorii de plată. Bugetul, aprobarea și reconcilierea trebuie să rămână reguli executabile și înregistrări clare, nu simple intenții formulate în limbaj natural.