Salt la conținutul principal
FromNine
Meniu

IA și date

Agenți IA și automatizare care acționează în limitele stabilite de dumneavoastră.

Automatizăm lucrul în mai mulți pași cu agenți și fluxuri de lucru care folosesc instrumente cu permisiuni limitate, se opresc pentru aprobare înaintea acțiunilor cu consecințe și lasă un istoric pe care auditorii îl pot reconstitui pas cu pas.

Pentru centrele de servicii partajate și echipele operaționale care rulează același proces pentru entități din mai multe țări și în mai multe sisteme.

Solicitați o discuțieAsistență pentru clienți
Agenți IA și automatizare: straturile capabilitățiiPatru straturi suprapuse în adâncime. De sus în jos: fluxul de lucru care păstrează starea, pașii agentului din interiorul lui, gateway-ul de instrumente cu permisiunile sale și punctul de aprobare dinaintea acțiunilor asupra sistemelor dumneavoastră.01Flux de lucru și stare02Pașii agentului03Gateway de instrumente și permisiuni04Aprobare, apoi acțiune
  1. 01Gradul potrivit de autonomie pentru fiecare pas, de la flux fix la agent supravegheat
  2. 02Instrumente cu privilegii minime, în spatele unui gateway, cu limite pentru fiecare acțiune
  3. 03Fiecare pas, apel de instrument și aprobare înregistrat, reconstituibil și exportabil

01 Probleme

De ce ezită programele de automatizare

  1. 01

    Nimeni nu poate spune ce are voie să facă agentul

    Rulează sub un cont de serviciu cu drepturi largi. Echipele de risc și de securitate nu aprobă, și nu ar trebui să fie puse să ghicească.

  2. 02

    Rata de automatizare arată bine, excepțiile se adună

    Cazurile simple trec. Restul ajung fără context într-o căsuță de e-mail comună, iar echipa care le tratează are acum mai mult de lucru decât înainte.

  3. 03

    Când ceva merge prost, nimeni nu poate reconstitui de ce

    Nu există nicio înregistrare a datelor pe care le-a văzut agentul, a instrumentului pe care l-a apelat sau a persoanei care a aprobat pasul. Auditul intern întreabă și nu primește răspuns.

  4. 04

    Roboții se strică ori de câte ori se schimbă un ecran

    Roboți care citesc ecranele duc lucrări critice. Fiecare actualizare a aplicației înseamnă un weekend de reparații.

02 Ce livrăm

Ce livrăm

  1. 01 Autonomie stabilită pentru fiecare pas

    Pentru fiecare pas alegem cea mai simplă variantă care funcționează: un flux de lucru determinist, un singur apel de model, un agent care folosește instrumente sau o orchestrare în mai mulți pași. Uneori răspunsul corect este că un agent nu este instrumentul potrivit.

    Ce facem

    • Parcurgerea procesului cu oamenii care fac munca
    • Decizia de autonomie pas cu pas, cu riscul fiecărui pas
    • Modelul fluxului ca mașină de stări sau în BPMN
    • Criterii pentru a trece un pas la mai multă sau mai puțină autonomie

    Ce primiți

    • Harta autonomiei procesului
    • Modelul fluxului de lucru, sub controlul versiunilor
    • Decizia documentată pentru fiecare pas al agentului

  2. 02 Permisiuni pentru instrumente și privilegii minime

    Agenții apelează instrumente, niciodată direct sistemele. Un gateway de instrumente aplică permisiunile, listele de operațiuni permise și limitele de tranzacție, iar fiecare instrument rulează sub propria identitate de serviciu.

    Ce facem

    • Catalog de instrumente, cu instrumentele de citire separate de cele de scriere
    • Identități de serviciu cu permisiuni limitate pentru fiecare instrument
    • Limite de tranzacție și de frecvență pentru fiecare tip de acțiune
    • Execuție izolată pentru cod și pentru lucrul cu fișiere

    Ce primiți

    • Gateway de instrumente cu politica definită prin configurare
    • Matrice de permisiuni aprobată de echipa de securitate
    • Suită de teste pentru aplicarea politicii

  3. 03 Proiectarea aprobării umane

    Praguri de aprobare, rutare în funcție de nivelul de încredere și principiul celor patru ochi pentru acțiunile cu consecințe. Deciziile despre persoane păstrează un om în proces, în conformitate cu articolul 22 din RGPD și cu dreptul la intervenție umană.

    Ce facem

    • Clasificarea acțiunilor după consecințe
    • Praguri de aprobare și reguli de escaladare
    • Interfață pentru cei care verifică, cu contextul necesar pentru decizie
    • Garanții pentru deciziile care privesc persoane fizice

    Ce primiți

    • Politică de aprobare pentru fiecare tip de acțiune
    • Flux de verificare în instrumentele pe care echipele le folosesc deja
    • Harta escaladărilor, cu echipele responsabile

  4. 04 Trasabilitate și audit

    O înregistrare completă a datelor de intrare, a contextului regăsit, a rezultatelor modelului, a apelurilor de instrumente și a aprobărilor, astfel încât orice rulare să poată fi reconstituită și exportată pentru auditul intern sau pentru o autoritate de supraveghere.

    Ce facem

    • Proiectarea jurnalului de evenimente, cu reguli de păstrare
    • Reluarea rulărilor pe aceleași date de intrare
    • Formate de export pentru audit, convenite cu auditul intern
    • Dashboarduri pentru ratele de excepții și de aprobare

    Ce primiți

    • Depozit pentru jurnalul de audit
    • Instrumente de reluare a rulărilor
    • Dashboarduri operaționale

  5. 05 Tratarea erorilor

    Agenții vor da greș. Proiectăm astfel încât eșecul să fie sigur: acțiuni idempotente, compensare și revenire, limite de timp, escaladare către echipa responsabilă și un buton de oprire pe care cineva are dreptul să îl folosească.

    Ce facem

    • Chei de idempotență pentru fiecare acțiune de scriere
    • Pași de compensare pentru modificările care ating mai multe sisteme
    • Limite de timp și bugete de reîncercare
    • Buton de oprire pentru fiecare agent și fiecare instrument

    Ce primiți

    • Analiza modurilor de defectare
    • Ghid operațional cu procedura de oprire
    • Teste de haos pentru traseele critice

  6. 06 Agenți alături de automatizarea existentă

    Process mining arată fluxul așa cum rulează în realitate. Automatizarea robotică a proceselor (RPA) rămâne acolo unde există doar un ecran legacy și trece pe API-uri imediat ce acestea apar. Măsurăm rata de excepții, nu doar rata de automatizare.

    Ce facem

    • Process mining pe jurnalele de evenimente
    • Inventarul roboților existenți și al istoricului lor de erori
    • Alternative prin API pentru automatizările fragile de ecran
    • Analiza excepțiilor după cauză

    Ce primiți

    • Analiza fluxului actual
    • Plan de migrare de la ecrane la API-uri
    • Valoare de referință și țintă pentru timpul de tratare a excepțiilor

03 Arhitectură

O arhitectură de referință ilustrativă

Orchestratorul deține starea lucrului. Pașii agentului se află în interiorul lui și pot ajunge la sistemele dumneavoastră doar prin gateway-ul de instrumente, care verifică permisiunile și limitele la fiecare apel. Instrumentele de citire trec direct; instrumentele de scriere se opresc la un punct de aprobare atunci când acțiunea are consecințe.

Totul lasă o urmă în jurnalul de audit. Butonul de oprire și limitele de timp stau pe orchestrator, iar excepțiile ajung la echipa responsabilă, cu întregul context al rulării.

Straturile din diagramă

Preluare
Un dosar nou, un mesaj sau un eveniment pornește o rulare cu un identificator de corelare.
Orchestrare
Starea fluxului de lucru, pașii agentului, compensarea și butonul de oprire.
Limita de permisiuni
Gateway de instrumente, instrumente de citire, punct de aprobare și instrumente de scriere.
Sisteme
CRM, ERP și gestionarea dosarelor, accesate doar prin instrumente.
Urmă
Jurnalul de audit și echipa care tratează escaladările.
Exemplu ilustrativ

  1. Preluare

    • Declanșator: dosar, mesaj, eveniment

  2. Orchestrare

    • Orchestrator și stare
    • Pasul agentului
    • Buton de oprire și limite de timp
    • Compensare și revenire

  3. Limita de permisiuni

    • Gateway de instrumente
    • Instrumente de citire
    • Punct de aprobare
    • Instrumente de scriere

  4. Sisteme

    • CRM, ERP, gestionarea dosarelor

  5. Urmă

    • Jurnal de audit: fiecare pas, apel și aprobare, cu reluare și export
    • Echipa responsabilă de excepții
Agentul în interiorul unei limite de permisiuni

Arhitectură ilustrativă, nu sistemul unui client.

Citiți diagrama ca text

Traseul principal pornește de la un declanșator, trece prin orchestrator și printr-un pas al agentului până la gateway-ul de instrumente, apoi printr-un punct de aprobare unde decide un om, apoi la un instrument de scriere și, în final, la sistemele de business.

Gateway-ul permite și instrumente de citire care interoghează direct sistemele de business. Un buton de oprire controlează orchestratorul, pașii de compensare pot anula acțiunile agentului, iar orchestratorul escaladează către echipa responsabilă.

Aprobările și acțiunile de scriere sunt înregistrate într-un jurnal de audit care permite reluarea și exportul. Gateway-ul, instrumentele de citire, punctul de aprobare și instrumentele de scriere formează împreună limita de permisiuni.

04 Aspecte și limite

Aspecte de inginerie și limite

  • Autonomia se câștigă pas cu pas

    Cum procedăm

    Pașii pornesc sub supraveghere. Extindem autonomia doar atunci când jurnalele arată că pasul se comportă în limitele convenite pe un volum semnificativ de cazuri.

    Limite și dependențe

    Unii pași nu ar trebui să fie niciodată autonomi, indiferent ce arată cifrele. Este o decizie de business și vă vom cere să o luați explicit.

  • Agenții sunt la fel de siguri ca instrumentele lor

    Cum procedăm

    Instrumentele de scriere sunt înguste și parametrizate: „emite o factură de stornare până la o limită”, niciodată „apelează ERP-ul”.

    Limite și dependențe

    Acolo unde un sistem nu are un model fin de permisiuni, compensăm în gateway. Asta adaugă muncă, iar unele sisteme nu pot fi făcute suficient de sigure pentru acces de scriere.

    Rezultatele IA pot fi greșite. De aceea acțiunile cu consecințe se opresc la un om, iar cazurile incerte sunt redirecționate, nu ghicite.

  • Injectarea de prompturi este un risc operațional

    Cum procedăm

    Conținutul din e-mailuri, documente și pagini web este tratat ca nesigur. Nu poate schimba instrucțiunile agentului și nu îi poate extinde permisiunile, iar testele adversariale verifică acest lucru.

    Limite și dependențe

    Nicio măsură nu elimină complet riscul. Proiectul pornește de la ideea că o încercare va reuși într-o zi și limitează ce poate atinge.

  • Excepțiile fac parte din produs

    Cum procedăm

    Fiecare excepție sosește cu contextul rulării, un motiv și un pas următor propus, în coada unei echipe care răspunde de ea.

    Limite și dependențe

    Dacă nimeni nu răspunde de coada de excepții, automatizarea mută munca în loc să o elimine. Nu intrăm în producție fără un responsabil numit.

05 Cum lucrăm

Cum lucrăm

Pornim de la procesul așa cum rulează, nu așa cum este desenat, și extindem autonomia pas cu pas.

  1. 01

    Vedem fluxul real

    Process mining și observarea directă arată volumele, variantele și locurile în care se pierde timp.

    RezultatAnaliza fluxului actual

  2. 02

    Stabilim autonomia fiecărui pas

    Flux de lucru, apel de model sau agent, cu consecința unei acțiuni greșite notată pentru fiecare pas.

    RezultatHarta autonomiei și matricea de permisiuni

  3. 03

    Rulăm în paralel, fără efect

    Sistemul propune, oamenii acționează. Comparăm propunerile lui cu deciziile lor pe cazuri reale.

    RezultatRaportul rulării în paralel

  4. 04

    Intrăm în producție cu aprobări

    Acțiunile cu consecințe așteaptă aprobarea; pragurile sunt revizuite pe baza dovezilor, nu a impresiilor.

    RezultatPolitica de aprobare și dashboarduri

06 Control uman

Unde controlul rămâne la oameni

Agenții acționează în limitele permisiunilor stabilite de dumneavoastră, cer aprobare înaintea acțiunilor cu consecințe și înregistrează fiecare pas.

  • Aprobare înaintea consecințelor

    Plățile, deciziile despre persoane și modificările datelor de bază așteaptă un om, cu contextul necesar pentru o decizie rapidă.

  • Patru ochi acolo unde contează

    Peste pragurile convenite aprobă două persoane. Pragul este o setare controlată de responsabilul de risc, nu cod.

  • Un buton de oprire pe care cineva îl poate folosi

    Fiecare agent și fiecare instrument pot fi opriți de un rol stabilit, fără o nouă implementare, iar procedura este exersată.

  • Verificare umană pentru deciziile despre persoane

    Acolo unde un rezultat afectează o persoană, un om îl verifică, iar persoana respectivă poate cere această verificare.

  • Escaladare către echipa responsabilă

    Rulările incerte sau eșuate ajung la o echipă care răspunde de ele, niciodată într-o căsuță de e-mail pe care nu o citește nimeni.

07 Exemplu

Un exemplu ilustrativ

Exemplu ilustrativ

Excepții la facturile furnizorilor într-o companie de distribuție

01Situația
Un distribuitor de materiale de construcții, cu depozite în mai multe județe, primește zilnic facturi de la furnizori. Facturile care nu se potrivesc cu comanda așteaptă zile întregi într-o coadă, în timp ce echipa financiară îi caută pe achizitori prin e-mail.
02Ce am construi
Un agent adună comanda, recepția și condițiile contractuale, redactează o propunere de rezolvare și un mesaj către achizitor și propune înregistrarea contabilă prin instrumente ERP cu permisiuni limitate.
03Unde decid oamenii
Înregistrările peste un prag stabilit de directorul financiar au nevoie de două aprobări. Nimic din ce atinge datele bancare ale unui furnizor nu este automatizat.
04Ce am măsura
Numărul de zile în care o excepție rămâne deschisă, ponderea propunerilor acceptate fără modificări și timpul petrecut pe fiecare excepție.

08 Pe sectoare

În sectorul dumneavoastră

  • Servicii financiare

    Daune, integrarea clienților noi și excepții de plată tratate de agenți cu limite de tranzacție, aprobare după principiul celor patru ochi și exporturi pentru audit într-un format convenit cu funcția de audit.

  • Sector public și administrație

    Pregătirea dosarelor în care agentul adună informații și redactează, iar funcționarul public decide, cu fiecare pas înregistrat pentru verificări și pentru soluționarea contestațiilor.

  • Producție și industrie

    Modificări de comenzi, urmărirea furnizorilor și cereri de service între ERP și e-mail, cu aprobări în punctele care angajează bani sau capacitate.

România

Automatizare pentru mai multe entități și autorități

Centrele de servicii partajate din România deservesc adesea entități din mai multe state membre și automatizează un singur proces sub mai multe seturi de așteptări. Regulamentul IA și dreptul la intervenție umană din RGPD se aplică peste tot; felul în care autoritățile de supraveghere sau reprezentanții salariaților privesc deciziile automatizate diferă însă de la o țară la alta, la fel ca regulile de aprobare din interiorul grupului. În România, ANSPDCP supraveghează prelucrarea datelor personale, iar pentru Regulamentul IA un memorandum al Guvernului a propus ANCOM ca autoritate de supraveghere a pieței (stadiul în toamna anului 2026).

Păstrăm o singură orchestrare și un singur jurnal de audit și facem configurabile, pentru fiecare entitate, pragurile de aprobare, limbile și căile de escaladare. Responsabilul de risc din fiecare țară vede și aprobă setările care se aplică angajaților și clienților de care răspunde.

Întrebări despre agenți IA și automatizare

Cum alegeți între un agent și un flux de lucru obișnuit?

Dacă pașii sunt cunoscuți și datele de intrare sunt structurate, un flux de lucru este mai ieftin, mai rapid și mai ușor de auditat. Agenții își justifică locul acolo unde datele de intrare variază, traseul depinde de ce se găsește pe parcurs, iar un om poate verifica rezultatul. Majoritatea sistemelor din producție le combină pe amândouă.

Ce împiedică un agent să facă ceva ce nu ar trebui?

Poate acționa doar prin instrumente, fiecare instrument rulează sub propria identitate cu permisiuni limitate, iar gateway-ul aplică limitele la fiecare apel. Acțiunile de scriere cu consecințe se opresc pentru aprobare. Conținutul nesigur nu poate schimba aceste reguli.

Folosim deja RPA. Renunțăm la el?

Nu. Roboții care lucrează pe ecrane legacy continuă să funcționeze acolo unde nu există un API. Adăugăm agenți pentru pașii care cer judecată, folosim process mining pentru a găsi roboții fragili și îi înlocuim cu integrări prin API pe măsură ce sistemele din spate o permit.

Cum măsurați succesul?

Prin timpul de procesare, rata de excepții, munca refăcută și timpul pe care oamenii îl petrec cu excepțiile, comparate cu o valoare de referință măsurată înainte de lansare. Rata de automatizare singură ascunde prea multe.

Pot auditul intern sau o autoritate de supraveghere să verifice ce s-a întâmplat?

Da. Fiecare rulare poate fi reconstituită din jurnal: date de intrare, context regăsit, rezultatele modelului, apeluri de instrumente și aprobări. Formatele de export se convin cu funcția de audit înainte de lansare.

Aduceți procesul care vă ține echipa cel mai ocupată

Stabilim unde ajută un agent, unde ajunge un flux de lucru și unde trebuie să decidă un om, înainte să construim ceva.

Solicitați o discuțieAsistență pentru clienți