Vai al contenuto principale
FromNine
Menu

IA e dati

Agenti IA aziendali e automazione che operano entro i limiti da Lei stabiliti

Automatizziamo attività articolate in più passaggi con agenti e flussi di lavoro che usano strumenti dal perimetro definito, si fermano per l’approvazione prima delle azioni rilevanti e lasciano una traccia che i Suoi auditor possono ripercorrere.

Per centri servizi, back office e uffici amministrativi che gestiscono pratiche ripetitive su più sistemi e non vogliono perdere il controllo delle decisioni.

Parliamo del Suo progettoScopra il nostro approccio
Agenti IA e automazione: lo stack delle competenzeQuattro livelli sovrapposti in profondità. Dall’alto verso il basso: il flusso di lavoro che mantiene lo stato, i passaggi dell’agente al suo interno, il gateway degli strumenti con i relativi permessi e il punto di approvazione prima che le azioni raggiungano i Suoi sistemi.01Flusso di lavoro e stato02Passaggi dell’agente03Gateway degli strumenti e perimetri04Prima l’approvazione, poi l’azione
  1. 01Il giusto grado di autonomia per ogni passaggio, dal flusso fisso all’agente supervisionato
  2. 02Strumenti a privilegio minimo dietro un gateway, con limiti per ciascuna azione
  3. 03Ogni passaggio, chiamata e approvazione registrati, ripercorribili ed esportabili

01 Problemi

Perché i programmi di automazione si bloccano

  1. 01

    Nessuno sa dire che cosa l’agente sia autorizzato a fare

    Gira con un’utenza di servizio dai permessi ampi. Le funzioni di risk management e sicurezza non danno il via libera, e non dovrebbero dover tirare a indovinare.

  2. 02

    Il tasso di automazione è buono, ma le eccezioni si accumulano

    I casi semplici scorrono. Il resto finisce in una casella condivisa senza contesto, e il team che lo gestisce è più carico di prima.

  3. 03

    Quando qualcosa va storto, nessuno sa ricostruire il perché

    Non c’è traccia dei dati che l’agente ha visto, dello strumento che ha chiamato o di chi ha approvato il passaggio. L’internal audit chiede, e una risposta non c’è.

  4. 04

    I bot si rompono a ogni cambio di schermata

    Robot che leggono le schermate reggono attività critiche. Ogni aggiornamento applicativo significa un fine settimana di riparazioni.

02 Ambiti di intervento

Che cosa realizziamo

  1. 01 Autonomia progettata passaggio per passaggio

    Per ogni passaggio scegliamo la soluzione più semplice che funziona: un flusso deterministico, una singola chiamata al modello, un agente che usa strumenti o un’orchestrazione in più fasi. A volte la risposta onesta è che un agente è lo strumento sbagliato.

    Che cosa facciamo

    • Analisi del processo insieme a chi svolge il lavoro
    • Decisione sull’autonomia passaggio per passaggio, con il rischio di ciascuno
    • Modello del flusso come macchina a stati o in BPMN
    • Criteri per aumentare o ridurre l’autonomia di un passaggio

    Che cosa riceve

    • Mappa dell’autonomia del processo
    • Modello del flusso sotto controllo di versione
    • Registro delle decisioni per ogni passaggio affidato a un agente

  2. 02 Permessi degli strumenti e privilegio minimo

    Gli agenti chiamano strumenti, mai direttamente i sistemi. Un gateway degli strumenti applica perimetri, liste di autorizzazione e limiti per transazione, e ogni strumento opera con una propria identità di servizio.

    Che cosa facciamo

    • Catalogo degli strumenti con lettura e scrittura separate
    • Identità di servizio con perimetro definito per ogni strumento
    • Limiti per transazione e di frequenza per tipo di azione
    • Esecuzione in sandbox per codice e gestione dei file

    Che cosa riceve

    • Gateway degli strumenti con policy gestite come configurazione
    • Matrice dei permessi approvata dalla sicurezza
    • Suite di test sull’applicazione delle policy

  3. 03 Progettazione human-in-the-loop

    Soglie di approvazione, instradamento in base alla confidenza e principio dei quattro occhi per le azioni rilevanti. Le decisioni che riguardano le persone mantengono una persona nel ciclo, in linea con l’articolo 22 del GDPR e il diritto all’intervento umano.

    Che cosa facciamo

    • Classificazione delle azioni in base alle conseguenze
    • Soglie di approvazione e regole di escalation
    • Interfaccia per i revisori con il contesto necessario a decidere
    • Tutele per le decisioni che riguardano singole persone

    Che cosa riceve

    • Policy di approvazione per tipo di azione
    • Flusso di revisione negli strumenti che i Suoi team già usano
    • Mappa di escalation con team designati

  4. 04 Tracciabilità e audit

    Una registrazione completa di input, contesto recuperato, output del modello, chiamate agli strumenti e approvazioni, così che ogni esecuzione possa essere ripercorsa ed esportata per l’internal audit o un’autorità di vigilanza.

    Che cosa facciamo

    • Progettazione del log degli eventi con regole di conservazione
    • Riesecuzione delle elaborazioni su input fissati
    • Formati di esportazione concordati con l’internal audit
    • Dashboard sui tassi di eccezione e di approvazione

    Che cosa riceve

    • Archivio dell’audit trail
    • Strumenti di riesecuzione
    • Dashboard operative

  5. 05 Gestione degli errori

    Gli agenti sbaglieranno. Progettiamo in modo che l’errore resti sotto controllo: azioni idempotenti, compensazione e rollback, timeout, escalation a un team designato e un kill switch che qualcuno è autorizzato ad azionare.

    Che cosa facciamo

    • Chiavi di idempotenza su ogni azione di scrittura
    • Passaggi di compensazione per modifiche su più sistemi
    • Timeout e budget di tentativi
    • Kill switch per ogni agente e per ogni strumento

    Che cosa riceve

    • Analisi delle modalità di guasto
    • Runbook con la procedura di arresto
    • Test di chaos engineering sui percorsi critici

  6. 06 Agenti accanto all’automazione esistente

    Il process mining mostra il flusso come funziona davvero. La robotic process automation resta dove esiste solo una schermata legacy e passa alle API non appena queste sono disponibili. Misuriamo il tasso di eccezione, non solo il tasso di automazione.

    Che cosa facciamo

    • Process mining sui log degli eventi
    • Censimento dei robot esistenti e del loro storico di malfunzionamenti
    • Alternative via API per le automazioni fragili basate su schermate
    • Analisi delle eccezioni per causa

    Che cosa riceve

    • Analisi del flusso attuale
    • Piano di migrazione dalle schermate alle API
    • Valore di partenza e obiettivo per il tempo di gestione delle eccezioni

03 Architettura

Un’architettura di riferimento illustrativa

L’orchestratore detiene lo stato del lavoro. I passaggi dell’agente si trovano al suo interno e possono raggiungere i Suoi sistemi solo attraverso il gateway degli strumenti, che verifica perimetro e limiti a ogni chiamata. Gli strumenti di lettura passano; quelli di scrittura si fermano a un punto di approvazione quando l’azione è rilevante.

Tutto lascia una registrazione nell’audit trail. Kill switch e timeout agiscono sull’orchestratore, e le eccezioni arrivano a un team designato con il contesto completo dell’esecuzione.

Livelli del diagramma

Ingresso
Una nuova pratica, un messaggio o un evento avvia un’esecuzione con un identificativo di correlazione.
Orchestrazione
Stato del flusso, passaggi dell’agente, compensazione e kill switch.
Perimetro dei permessi
Gateway degli strumenti, strumenti di lettura, punto di approvazione e strumenti di scrittura.
Sistemi
CRM, ERP e gestione delle pratiche, raggiungibili solo tramite strumenti.
Tracciabilità
L’audit trail e il team che gestisce le escalation.
Esempio illustrativo

  1. Ingresso

    • Avvio: pratica, messaggio, evento

  2. Orchestrazione

    • Orchestratore e stato
    • Passaggio dell’agente
    • Kill switch e timeout
    • Compensazione e rollback

  3. Perimetro dei permessi

    • Gateway degli strumenti
    • Strumenti di lettura
    • Punto di approvazione
    • Strumenti di scrittura

  4. Sistemi

    • CRM, ERP, gestione pratiche

  5. Tracciabilità

    • Audit trail: ogni passaggio, chiamata e approvazione, con riesecuzione ed esportazione
    • Team designato per le eccezioni
L’agente dentro un perimetro di permessi

Architettura illustrativa, non un sistema di un cliente.

Leggere il diagramma in forma testuale

Il percorso principale va da un evento di avvio, attraverso l’orchestratore e un passaggio dell’agente, al gateway degli strumenti, poi a un punto di approvazione dove decide una persona, quindi a uno strumento di scrittura e infine ai sistemi aziendali.

Il gateway consente anche strumenti di lettura che interrogano direttamente i sistemi aziendali. Un kill switch controlla l’orchestratore, passaggi di compensazione possono annullare le azioni dell’agente e l’orchestratore effettua l’escalation verso un team designato.

Approvazioni e azioni di scrittura sono registrate in un audit trail che consente riesecuzione ed esportazione. Gateway, strumenti di lettura, punto di approvazione e strumenti di scrittura formano insieme il perimetro dei permessi.

04 Considerazioni e limiti

Scelte progettuali e limiti

  • L’autonomia si guadagna passaggio per passaggio

    Come lo affrontiamo

    I passaggi partono supervisionati. Ampliamo l’autonomia solo quando i log dimostrano che il passaggio rispetta i limiti concordati su un volume significativo di casi.

    Limiti e dipendenze

    Alcuni passaggi non dovrebbero mai essere autonomi, qualunque cosa dicano i numeri. È una decisione di business, e Le chiederemo di prenderla in modo esplicito.

  • Un agente è sicuro quanto i suoi strumenti

    Come lo affrontiamo

    Gli strumenti di scrittura sono circoscritti e parametrizzati: «emettere una nota di credito fino a un importo massimo», mai «chiamare l’ERP».

    Limiti e dipendenze

    Quando un sistema non dispone di un modello di permessi granulare, compensiamo nel gateway. Questo richiede lavoro aggiuntivo, e alcuni sistemi non possono essere resi abbastanza sicuri per l’accesso in scrittura.

    L’output dell’IA può essere sbagliato. Per questo le azioni rilevanti si fermano in attesa di una persona e i casi incerti vengono instradati, non indovinati.

  • La prompt injection è un rischio operativo

    Come lo affrontiamo

    I contenuti di email, documenti e pagine web sono trattati come non attendibili. Non possono modificare le istruzioni dell’agente né ampliarne i permessi, e i test di red teaming lo verificano.

    Limiti e dipendenze

    Nessuna contromisura elimina del tutto il rischio. Il progetto presuppone che un tentativo prima o poi riesca e limita ciò che può raggiungere.

  • Le eccezioni fanno parte del prodotto

    Come lo affrontiamo

    Ogni eccezione arriva con il contesto dell’esecuzione, una motivazione e un passo successivo suggerito, nella coda di un team che ne è responsabile.

    Limiti e dipendenze

    Se nessuno è responsabile della coda delle eccezioni, l’automazione sposta il lavoro invece di eliminarlo. Non andiamo in produzione senza un responsabile designato.

05 Come lavoriamo

Come lavoriamo

Partiamo dal processo come funziona davvero, non come è disegnato, e conquistiamo l’autonomia un passaggio alla volta.

  1. 01

    Osservare il flusso reale

    Process mining e affiancamento mostrano volumi, varianti e punti in cui si perde tempo.

    RisultatoAnalisi del flusso attuale

  2. 02

    Decidere l’autonomia di ogni passaggio

    Flusso di lavoro, chiamata al modello o agente, con le conseguenze di un’azione errata messe per iscritto per ciascun passaggio.

    RisultatoMappa dell’autonomia e matrice dei permessi

  3. 03

    Operare in modalità ombra

    Il sistema propone, le persone agiscono. Confrontiamo le sue proposte con le loro decisioni su casi reali.

    RisultatoReport dell’esercizio in modalità ombra

  4. 04

    Andare in produzione con le approvazioni

    Le azioni rilevanti attendono l’approvazione; le soglie vengono riviste sulla base delle evidenze, non delle impressioni.

    RisultatoPolicy di approvazione e dashboard

06 Controllo umano

Dove il controllo resta alle persone

Gli agenti operano entro i permessi da Lei definiti, chiedono l’approvazione prima delle azioni rilevanti e registrano ogni passaggio.

  • Approvazione prima delle conseguenze

    Pagamenti, decisioni su singole persone e modifiche ai dati anagrafici attendono una persona, con il contesto necessario per decidere rapidamente.

  • Quattro occhi dove serve

    Oltre le soglie concordate approvano due persone. La soglia è un parametro controllato dal Suo responsabile del rischio, non una riga di codice.

  • Un kill switch che qualcuno può usare

    Ogni agente e ogni strumento possono essere fermati da un ruolo designato, senza un nuovo rilascio, e la procedura viene provata.

  • Revisione umana per le decisioni sulle persone

    Quando un esito riguarda un individuo, una persona lo esamina e l’interessato può chiedere tale revisione.

  • Escalation a un team designato

    Le esecuzioni incerte o non riuscite vanno a un team che ne è responsabile, mai a una casella di posta che nessuno presidia.

07 Esempio

Un esempio illustrativo

Esempio illustrativo

Anomalie sulle fatture passive in un centro servizi amministrativo

01Situazione
Il centro servizi amministrativo di un gruppo riceve dallo SDI le fatture passive di più società; quelle che non corrispondono all’ordine restano ferme per giorni mentre il personale insegue i buyer via email.
02Che cosa realizzeremmo
Un agente raccoglie ordine, entrata merci e condizioni contrattuali, propone una soluzione e un messaggio al buyer e prepara la registrazione tramite strumenti ERP con permessi limitati.
03Dove decidono le persone
Le registrazioni oltre una soglia per società richiedono due approvazioni; tutto ciò che tocca l’IBAN di un fornitore non viene mai automatizzato.
04Che cosa misureremmo
Giorni di apertura di un’anomalia, quota di proposte accettate senza modifiche, tempo dedicato a ogni anomalia.

08 Settori

Nel Suo settore

  • Servizi finanziari

    Sinistri, onboarding ed eccezioni di pagamento gestiti da agenti con limiti per transazione, approvazione a quattro occhi ed esportazioni di audit in un formato concordato con la Sua funzione di audit.

  • Pubblica Amministrazione

    Istruttoria delle pratiche in cui l’agente raccoglie e redige, mentre decide il funzionario, con ogni passaggio registrato per il riesame e per i ricorsi.

  • Manifattura e industria

    Modifiche agli ordini, solleciti ai fornitori e richieste di assistenza tra ERP ed email, con approvazioni nei punti che impegnano denaro o capacità produttiva.

Italia

Automazione con la persona al centro

Il GDPR tutela il diritto a un intervento umano nelle decisioni automatizzate e il Regolamento europeo sull’IA prescrive la sorveglianza umana dei sistemi ad alto rischio. La Legge 132/2025 aggiunge regole italiane: nella PA l’IA resta di supporto e la decisione spetta al funzionario, e nel lavoro il datore deve informare le persone quando usa sistemi di IA che le riguardano.

Per questo gli agenti che progettiamo propongono e preparano, ma soglie di approvazione, escalation e registri si configurano con chi risponde del processo, e i casi delicati sono affidati a una persona.

Domande su agenti IA e automazione

Come decidete tra un agente e un normale flusso di lavoro?

Se i passaggi sono noti e gli input strutturati, un flusso di lavoro è più economico, più veloce e più facile da verificare. Gli agenti si giustificano dove gli input variano, il percorso dipende da ciò che emerge e una persona può controllare l’esito. La maggior parte dei sistemi in produzione combina entrambi.

Che cosa impedisce a un agente di fare ciò che non dovrebbe?

Può agire solo tramite strumenti, ogni strumento opera con una propria identità dal perimetro definito e il gateway applica limiti a ogni chiamata. Le azioni di scrittura rilevanti si fermano per l’approvazione. I contenuti non attendibili non possono modificare queste regole.

Usiamo già la RPA. Dobbiamo abbandonarla?

No. I robot sulle schermate legacy continuano a funzionare dove non esiste un’API. Aggiungiamo agenti per i passaggi che richiedono valutazione, usiamo il process mining per individuare i robot fragili e li sostituiamo con integrazioni via API man mano che i sistemi sottostanti lo consentono.

Come misurate il successo?

In base al tempo di attraversamento, al tasso di eccezione, alle rilavorazioni e al tempo che le persone dedicano alle eccezioni, rispetto a una baseline rilevata prima del go-live. Il solo tasso di automazione nasconde troppo.

L’internal audit o un’autorità di vigilanza possono verificare che cosa è successo?

Sì. Ogni esecuzione può essere ripercorsa a partire dal suo log: input, contesto recuperato, output del modello, chiamate agli strumenti e approvazioni. I formati di esportazione vengono concordati con la Sua funzione di audit prima del go-live.

Porti il processo che impegna di più il Suo team

Individueremo insieme dove serve un agente, dove basta un flusso di lavoro e dove deve decidere una persona, prima di sviluppare qualsiasi cosa e con il Suo team IT al tavolo.

Parliamo del Suo progettoScoprire il nostro approccio