Propose-then-act: arhitectura de aprobare pentru automatizări B2B peste 10k EUR
În aprilie 2026 un client dintr-un tender de 180.000 EUR a acceptat un preț greșit pentru că bot-ul de RPA a apăsat „Trimite" înainte ca cineva să verifice cursul de schimb din ziua ofertei. Diferența: 11.400 EUR.
Propose-then-act: arhitectura de aprobare pentru automatizări B2B peste 10k EUR
În aprilie 2026 un client dintr-un tender de 180.000 EUR a acceptat un preț greșit pentru că bot-ul de RPA a apăsat „Trimite” înainte ca cineva să verifice cursul de schimb din ziua ofertei. Diferența: 11.400 EUR. Un singur click, o singură dimineață.
Pentru procese unde greșeala depășește 10.000 EUR, arhitectura „act-then-log” (agentul execută, omul verifică ex-post) este contraindicată. Alternativa se numește propose-then-act: agentul construiește acțiunea completă, o serializează într-un obiect propunere, iar execuția reală trece printr-un gate uman sau printr-un al doilea agent cu politici diferite. E o schimbare de topologie, nu de model.
De ce contează gate-ul, nu inteligența agentului
GDPR Art. 22 interzice deciziile pur automate cu efect juridic sau similar semnificativ asupra persoanei (Regulation (EU) 2016/679, Art. 22). EU AI Act clasifică sistemele care iau decizii cu impact economic ridicat ca „high-risk” și impune supraveghere umană efectivă prin Art. 14 (Regulation (EU) 2024/1689). ENISA, în cadrul său pentru securitatea AI, notează că agenții LLM manifestă failure modes distincte față de RPA clasic, în special pe tool use nesupervizat (ENISA — Multilayer Framework for Good Cybersecurity Practices for AI).
Din perspectivă inginerească, un gate rezolvă trei probleme simultan: revizuire prin al patrulea ochi, log auditable în format uniform, punct unic de întrerupere dacă se detectează un incident. NIST AI RMF recomandă separarea explicită între funcțiile „measure” și „manage” tocmai pentru a permite acest gate (NIST AI Risk Management Framework 1.0).
Cum arată în producție
proposal:
id: prop_2026_04_12_a7f3
agent: procurement_bot_v2
action: submit_bid
amount_eur: 87420.00
fx_rate_used: 4.9782 # BNR ref 2026-04-12
requires_approval: true
approver_role: procurement_lead
ttl_seconds: 900
risk_flags: [amount_gt_10k, fx_recent_swing]Propunerea trăiește într-o coadă cu TTL. Approver-ul primește un diff față de ultima ofertă acceptată, cu highlight pe câmpurile care declanșează risk_flags. Dacă TTL-ul expiră fără decizie, propunerea moare — nu se execută implicit. Semnătura dublă (agent + approver) intră în log alături de hash-ul propunerii, condiție impusă și de NIS2 pentru operatori esențiali (Directive (EU) 2022/2555, Art. 21).
Poziția noastră
În proiectele IRIS pe orchestrare de agenți am renunțat la ideea că „un agent mai deștept elimină nevoia de aprobare”. Un LLM mai capabil produce propuneri mai bune, dar nu elimină categoria de risc — o mută. Gate-ul rămâne, doar că se rulează pe propuneri mai rar respinse. Pentru clienți din sectorul reglementat, cuplăm arhitectura cu controalele Lexnomia pentru NIS2, astfel încât fiecare aprobare devine dovadă audit-ready cu retention configurabil. Praguri sub 10k tolerează act-then-log; peste 10k, nu. Dacă evaluezi un flux propriu, începe de la pillar-ul IRIS și cere-ne o hartă a punctelor unde gate-ul se impune.