Automazioni costruite sui flussi di lavoro reali. Con le persone al comando.
La domanda utile non è dove aggiungere un agente AI, ma come dovrebbe funzionare il processo. Alcuni passaggi sono deterministici. Altri richiedono di interpretare documenti, email o testo libero. In altri ancora deve decidere una persona.
LEAF lavora con i tuoi team di business e IT per mappare il processo, automatizzare ciò che ha senso automatizzare e collegare modelli, strumenti e sistemi esistenti attraverso controlli espliciti, valutazione e revisione umana.
Perché Automazione AI
Molti processi si interrompono proprio dove le regole incontrano il linguaggio.
L'automazione tradizionale è estremamente efficace quando gli input sono strutturati e le regole sono note. I processi aziendali reali, però, comprendono spesso email, allegati, richieste scritte in linguaggio naturale, informazioni incomplete ed eccezioni difficili da esprimere con logica fissa.
I modelli linguistici rendono automatizzabili alcuni di questi passaggi perché possono interpretare, classificare, estrarre e redigere. Questo non significa che l'intero processo debba diventare probabilistico.
L'architettura deve mantenere prevedibile ciò che può esserlo e utilizzare i modelli soltanto dove l'interpretazione produce valore reale.
Non serve un agente per tutto
Usa il meccanismo meno complesso che risolve quel passaggio.
Deterministica dove le regole sono chiare. Modelli dove serve interpretazione. Persone dove conta la responsabilità.
01/ Regola
Logica deterministica
Passaggi tipici
- validare un campo
- applicare una soglia
- trasformare dati
- instradare in base a una condizione nota
- chiamare un endpoint fisso
Quando la regola può essere formulata con precisione, il codice deterministico è di solito la scelta più prevedibile, verificabile ed economica.
02/ Modello
Interpretazione dentro un workflow fisso
Passaggi tipici
- classificare una richiesta
- estrarre campi
- riassumere un documento
- redigere una risposta
- interpretare testo libero
Un modello linguistico gestisce un passaggio di interpretazione circoscritto, mentre il workflow che lo circonda resta esplicito.
03/ Agente
Scelta dinamica del percorso
Passaggi tipici
- scegliere uno strumento
- decidere quale fonte serve
- pianificare una sequenza limitata
- adattarsi a un caso variabile
Un agente AI è utile quando la sequenza corretta non può essere stabilita del tutto in anticipo, a condizione che strumenti e permessi disponibili restino delimitati.
04/ Persona
Responsabilità ed eccezioni
Passaggi tipici
- approvare un'azione con conseguenze
- risolvere un caso ambiguo
- correggere una raccomandazione
- gestire un'eccezione di policy
Alcuni passaggi restano alle persone perché responsabilità, incertezza o conseguenze rendono l'automazione inappropriata.
Una buona architettura di automazione è di solito una composizione di tutti e quattro, non una scelta tra l'uno e l'altro.
Anatomia di un'automazione
Un workflow di produzione è molto più di una chiamata a un modello.
Un caso seguito dall'inizio alla fine: ogni passaggio ha un tipo, un responsabile e una traccia.
Trigger Trigger
Un'email, un evento, l'invio di un modulo, una pianificazione, un messaggio, una modifica in un database o un'azione esplicita dell'utente avvia il workflow.
Regola Validazione
Gli input vengono controllati prima che sistemi a valle o modelli possano agire su di essi.
Modello Interpretazione
Dove serve, un modello classifica, estrae, riassume o ragiona su informazioni non strutturate.
Strumento Contesto
Le informazioni aziendali possono essere recuperate quando un passaggio richiede conoscenze che non sono contenute nell'input iniziale.
Agente Decisione
Regole deterministiche, output dei modelli o la pianificazione delimitata di un agente determinano il percorso successivo consentito.
Strumento Esecuzione degli strumenti
Strumenti espliciti interagiscono con API, database o applicazioni aziendali attraverso schemi definiti e perimetri di permesso.
Persona Revisione umana
Alcuni casi si fermano per una conferma, una correzione o un'escalation.
Sistema Esito
Il workflow aggiorna il sistema corretto, produce il documento richiesto o inoltra il caso.
Traccia Traccia
Input, decisioni, chiamate ai modelli, strumenti, errori e interventi umani vengono registrati per poterli esaminare in seguito.
Workflow fisso o agentico?
Il percorso dovrebbe variare solo quando l'attività lo richiede.
Workflow fisso
- A
- B
- C
- D
Quando usarlo
- la sequenza è nota
- le regole sono stabili
- la verificabilità è importante
- la variabilità è bassa
- contano latenza e costi prevedibili
Vantaggi
- più facile da testare
- più facile da correggere
- più facile da stimare
- più facile da governare
Workflow agentico
- Obiettivo
- Esamina il contesto
- Scegli uno strumento consentito
- Osserva il risultato
- Scegli il passo successivo
- ↺ si ripete entro il limite di passaggi
- Fermati
Quando usarlo
- il passo successivo dipende dal caso
- più strumenti possono essere validi
- la disponibilità delle informazioni varia
- serve davvero una pianificazione limitata
Richiede
- elenco di strumenti consentiti
- perimetri espliciti
- limiti al numero di passaggi
- timeout
- gestione degli errori
- osservabilità
- valutazione
- punti di approvazione dove servono
Le persone restano nel processo
I punti di revisione fanno parte dell'architettura.
La revisione umana non va aggiunta dopo che l'automazione ha fallito. Va progettata dentro il workflow, dove incertezza o conseguenze la giustificano.
Approvazione prima dell'azione
L'azione viene preparata automaticamente, ma una persona deve approvarla prima dell'esecuzione.
Revisione dei casi incerti
I casi fuori dall'intervallo atteso di confidenza o di validazione entrano in una coda di revisione.
Escalation delle eccezioni
Conflitti di policy, informazioni mancanti o casi non supportati vengono inoltrati a un responsabile designato, invece di essere improvvisati dal modello.
Correzione e valutazione
Le correzioni umane possono diventare dati di valutazione per le versioni future, senza che il comportamento in produzione cambi in autonomia.
Strumenti, non accesso illimitato
Un agente non dovrebbe ricevere più capacità di quelle necessarie all'attività.
I modelli non hanno bisogno di credenziali illimitate verso i sistemi aziendali. Hanno bisogno di strumenti espliciti che espongano la capacità minima necessaria al workflow.
Schema esplicito
Input e output sono definiti.
Perimetro di permesso
Lo strumento può eseguire solo le operazioni previste.
Validazione
Gli argomenti vengono controllati prima dell'esecuzione.
Gestione degli errori
I fallimenti seguono percorsi definiti invece di trasformarsi in tentativi ripetuti senza limiti.
Idempotenza dove serve
Le operazioni che possono essere ripetute dovrebbero evitare effetti duplicati indesiderati, dove il sistema sottostante lo consente.
Verificabilità
L'automazione registra quale strumento è stato chiamato, con quale contesto autorizzato e con quale esito.
getCustomer(id)letturalookupInventory(sku)letturacreateDraftReply(ticketId)bozzacreateSupportTicket(...)scritturaupdateCaseStatus(...)scritturapreparePurchaseOrder(...)scrittura · approvazione
Lavorare con i sistemi di riferimento
L'automazione deve collegarsi al processo, non creare un'azienda parallela.
ERP, CRM, ticketing, email, database, sistemi documentali e servizi interni contengono già lo stato dell'azienda. L'automazione dovrebbe leggere o aggiornare questi sistemi attraverso interfacce controllate, invece di creare un'altra fonte di verità scollegata.
API
Da preferire quando il sistema di origine espone interfacce stabili e supportate.
Database
Adatti a letture controllate o a operazioni progettate insieme al responsabile del sistema.
Eventi e code
Utili quando i workflow richiedono un'esecuzione asincrona o reagiscono a eventi dei sistemi.
File e documenti
Adatti quando il processo parte da moduli, report, allegati o documenti scambiati.
Piattaforme di integrazione
Middleware e piattaforme di integrazione esistenti possono restare parte dell'architettura, senza essere sostituiti inutilmente.
Quando il workflow ha bisogno di conoscenza
Esecuzione e retrieval risolvono problemi differenti.
Alcuni passaggi di un workflow richiedono informazioni che non sono contenute nella richiesta iniziale. Una pratica cliente può richiedere la policy pertinente. Un workflow tecnico può avere bisogno di un manuale. Un processo documentale può richiedere una clausola contrattuale.
In questi casi il retrieval può fornire al workflow un contesto fondato sulle fonti prima che un modello agisca.
Il retrieval non è il workflow. È una delle capacità che il workflow può richiamare quando serve conoscenza interna.
Scopri Dialogo con i sistemi aziendali- Passaggio del workflow
- Serve conoscenza interna
- Recupera un contesto fondato
- Il modello agisce
- Il workflow prosegue
Se viene eseguito, deve essere osservabile
Ogni esecuzione di produzione dovrebbe lasciare una traccia.
Un workflow che non si può esaminare non si può governare. La traccia registra lo stato osservabile dell'esecuzione: input, output, decisioni di instradamento, tool call e azioni delle persone. Non cerca di ricostruire il ragionamento interno di un modello.
- 09:41:12
Triggertrigger ricevuto - 09:41:12
Regolainput validato - 09:41:13
Modellomodel.classify → "invoice_exception" - 09:41:14
Strumentotool.get_order → success - 09:41:14
Regolaregola di policy → serve l'approvazione umana - 09:42:51
Personaapprovato dal revisore - 09:42:52
Strumentotool.update_case → success - 09:42:52
Tracciaesecuzione completata
- Input
- Che cosa è entrato nel workflow.
- Chiamate ai modelli
- Modello e versione, configurazione pertinente e output, dove la policy di logging lo consente.
- Tool call
- Quale operazione è stata tentata e con quale risultato.
- Decisioni osservabili
- Quale ramo ha scelto il workflow e, dove si può rappresentare, perché.
- Azioni delle persone
- Chi ha approvato, rifiutato o corretto un'operazione, secondo il modello di audit.
- Errori
- Errori, nuovi tentativi, timeout e percorsi di fallback.
- Esiti
- Che cosa è stato effettivamente scritto, prodotto o inoltrato.
La governance fa parte del workflow
Ogni percorso automatizzato deve avere un responsabile.
Responsabilità
Definire chi è responsabile del workflow dal punto di vista operativo e chi di ciascuna decisione con conseguenze.
Policy di approvazione
Stabilire quali azioni possono essere eseguite automaticamente e quali richiedono una revisione.
Versionamento
Modelli, prompt, workflow, schemi degli strumenti e configurazione pertinente dovrebbero avere versioni identificabili.
Gestione dei dati
Definire quali informazioni possono essere inviate a quali componenti e come vengono conservati i log.
Controllo delle modifiche
Le modifiche al comportamento in produzione dovrebbero passare da un processo di rilascio esplicito, proporzionato al rischio.
Audit trail
Le azioni automatiche e quelle delle persone dovrebbero restare verificabili secondo i requisiti di governance dell'organizzazione.
Testa il processo, non la demo
Un'automazione è utile solo se funziona l'intero workflow.
Un benchmark sui modelli non dice se un'automazione aziendale funziona. La valutazione deve coprire l'intero percorso, dall'input all'esito di business.
- Passaggio del modello
Qualità del singolo passaggio
Ogni passaggio affidato a un modello classifica, estrae o genera il risultato atteso sui casi rappresentativi?
- Percorso del workflow
Qualità del routing
Il workflow sceglie il percorso corretto per i casi normali e per le eccezioni?
- Chiamate agli strumenti
Correttezza degli strumenti
Vengono scelti gli strumenti giusti, con argomenti validi?
- Esito di business
Completamento del workflow
Il caso arriva all'esito di business corretto senza effetti collaterali indesiderati?
- Revisione
Intervento umano
Con quale frequenza i revisori correggono o rifiutano le decisioni automatiche?
- Dipendenze
Gestione degli errori
Che cosa succede quando un modello, un'API, un database o un sistema a valle non è disponibile o restituisce informazioni inattese?
- Versioni
Regressioni
Un nuovo modello, prompt, versione del workflow o connettore peggiora casi che prima funzionavano?
I cambiamenti in produzione devono essere prevedibili
Prima valuta. Poi rilascia.
La modifica di un prompt, l'aggiornamento di un modello o di uno strumento possono cambiare il comportamento in produzione anche quando il codice dell'applicazione resta invariato.
- Il comportamento in produzione non dovrebbe cambiare in autonomia.
- Il fine-tuning non è, per default, un miglioramento continuo automatico.
- Gli esiti di produzione revisionati possono diventare dati futuri di valutazione o di addestramento.
- Le nuove versioni vengono misurate rispetto alla baseline prima di essere promosse.
- Raccogli i casi
- Aggiorna workflow, modello o prompt
- Esegui la valutazione
- Confronta con la baseline
- Revisione
- Rilascio
- Monitoraggio
- Rollback se necessario
I casi monitorati alimentano il ciclo successivo
Lo stack segue il workflow
Ogni scelta dipende dal passaggio, non da un'impostazione predefinita.
Modelli
API commerciali o modelli open-weight ospitati privatamente possono essere scelti per ogni attività in base a qualità, lingua, latenza, costo, contesto, policy sui dati e risultati della valutazione.
Retrieval
Il retrieval sulle fonti aziendali si aggiunge solo dove un passaggio ha bisogno di conoscenza interna.
Servizi deterministici
Codice applicativo ordinario, regole e validazioni ovunque risolvano il problema in modo più affidabile.
Orchestrazione agentica
La pianificazione dinamica si introduce solo dove il percorso varia davvero.
Adattamento
Prompting, retrieval e progettazione del workflow andrebbero di norma valutati prima di introdurre il fine-tuning. Il fine-tuning è un'opzione quando le evidenze mostrano che risolve un limite reale.
Runtime
I componenti possono girare in cloud, cloud privato, on-premises o, per i carichi adatti, all'edge.
Componenti
Categorie, non una piattaforma fissa. Le tecnologie specifiche si scelgono per ogni incarico.
Modelli
- API di modelli commerciali
- modelli open-weight ospitati privatamente
- modelli specifici per il compito
Orchestrazione
- workflow engine
- servizi applicativi
- orchestrazione di agenti
- code di job
- elaborazione a eventi
Interfacce aziendali
- API REST
- GraphQL
- SQL
- flussi di eventi
- webhook
- interfacce a file
Conoscenza
- ricerca
- RAG
- retrieval documentale
- query strutturate
Identità e controllo
- SSO
- identità di servizio
- permessi basati sui ruoli
- workflow di approvazione
- log di audit
Deployment
- cloud
- cloud privato
- on-premises
- edge
Il deployment segue i vincoli
Il workflow non deve necessariamente vivere in un unico cloud.
Cloud
Servizi gestiti e API dei modelli dove i requisiti sui dati e operativi lo consentono.
Cloud privato
Ambienti dedicati quando confini di rete, di sicurezza o organizzativi richiedono un isolamento più forte.
On-premises
Modelli e orchestrazione possono girare su infrastruttura controllata dall'organizzazione quando i requisiti lo impongono.
Edge
Alcuni componenti del workflow o dell'inferenza possono essere eseguiti più vicino all'ambiente operativo quando latenza o connettività lo rendono utile.
Scopri Edge AIIl luogo del deployment non rende di per sé un sistema sicuro o conforme. La sicurezza dipende dall'intera architettura: identità, permessi, flussi di dati e controlli operativi.
Scopri AI confidenzialeDove si applica
Cerca attività ripetitive in cui l'interpretazione costa tempo.
Ricezione e smistamento
Leggere le richieste in arrivo, verificare le informazioni necessarie, classificare il caso e inoltrarlo al processo o al responsabile corretto.
Operazioni documentali
Estrarre informazioni, confrontare documenti, preparare output strutturati e inoltrare le eccezioni alla revisione.
Operazioni sui clienti
Raccogliere il contesto dell'account, preparare risposte, aggiornare le pratiche e coordinare le azioni tra CRM, ticketing e sistemi di comunicazione.
Processi di back office
Collegare documenti, database e sistemi aziendali nei processi amministrativi ripetitivi, mantenendo approvazioni esplicite.
IT e service operations
Classificare i ticket, recuperare il contesto, suggerire o eseguire le azioni consentite e fare escalation dei casi che richiedono un operatore.
Workflow supportati dalla conoscenza
Recuperare policy, manuali o record dentro un processo operativo più ampio, quando l'azione successiva dipende dalla conoscenza aziendale.
Schemi illustrativi, non descrizioni di progetti specifici presso clienti.
Inizia abbastanza in piccolo da poter misurare
La prima automazione dovrebbe essere circoscritta, frequente e osservabile.
I workflow candidati si valutano insieme alle persone che ne sono responsabili e li eseguono, con domande come queste.
Frequenza
Il processo si ripete abbastanza spesso da giustificare l'automazione?
Lavoro manuale
Oggi richiede una quantità significativa di lavoro ripetitivo?
Chiarezza del processo
Il workflow attuale si può davvero descrivere?
Disponibilità dei dati
Input e sistemi necessari sono accessibili?
Carico interpretativo
C'è un passaggio in cui i modelli aggiungono davvero valore?
Conseguenze
Che cosa succede quando l'automazione sbaglia?
Verificabilità
Gli esperti di dominio possono valutare se gli output sono corretti?
Sforzo di integrazione
I sistemi necessari possono esporre interfacce supportate?
La scelta delle priorità è una valutazione condivisa con il team del cliente, non una formula di punteggio fissa.
Il metodo LEAF
Scout. Connect. Unlock.
Advisory individua quali workflow meritano di essere automatizzati, Labs aggiunge l'ingegneria per il pilota e l'integrazione, Academy prepara i team che supervisioneranno il risultato e lavoreranno insieme a esso.
01/ Scout
Mappa il workflow prima di automatizzarlo
Lavoriamo con le persone che oggi eseguono il processo. Mappiamo input, decisioni, eccezioni, sistemi, responsabilità e punti critici. Individuiamo dove basta l'automazione deterministica, dove serve interpretazione e dove l'automazione non andrebbe applicata.
02/ Connect
Costruisci un progetto pilota circoscritto su casi reali
Co-progettiamo l'architettura con i team di business e IT, integriamo i sistemi necessari e valutiamo il workflow su casi rappresentativi, con i punti di revisione già in funzione.
03/ Unlock
Integra il workflow nel modello operativo
Integriamo monitoraggio, governance, deployment e processi di rilascio, poi prepariamo i team che sono responsabili dell'automazione e la usano a gestirla e a farla evolvere.
Una capability, tre contributi
Strategia, ingegneria e adozione devono incontrarsi.
Advisory
Individuare quale processo merita di essere automatizzato, definire il modello operativo e far emergere rischi e compromessi con le persone responsabili del lavoro.
Scopri LEAF AdvisoryLabs
Prototipare, ingegnerizzare, integrare e validare il workflow quando serve un supporto implementativo più profondo.
Scopri LEAF LabsAcademy
Preparare i team che supervisioneranno e gestiranno l'automazione e lavoreranno insieme a essa.
Scopri LEAF AcademyOgni incarico li combina secondo ciò che il lavoro richiede: non sono pacchetti separati da acquistare insieme.
Dove l'automazione ha senso, e dove no
Un processo debole non diventa buono perché viene eseguito da un modello.
L'obiettivo non è automatizzare il più possibile. È introdurre la quantità corretta di automazione in un processo che possa essere osservato, valutato e governato.
- I modelli sbagliano. Ogni passaggio affidato a un modello va progettato assumendo che output errati siano possibili.
- Un processo poco chiaro resta poco chiaro. Se nessuno sa spiegare come vanno gestiti i casi, l'automazione è prematura.
- Alcune decisioni devono restare alle persone, perché la responsabilità non si può delegare a un workflow.
- Gli agenti non sono automaticamente migliori dei workflow fissi.
- Più autonomia significa più stati e più percorsi di errore da testare.
- L'accesso agli strumenti deve restare limitato alle operazioni richieste dal workflow.
- Dati di origine scadenti possono produrre automazioni con esiti scadenti.
- Il retrieval può fornire contesto, ma non garantisce un'interpretazione corretta.
- L'automazione non rende sicura un'integrazione insicura.
- Il deployment privato non rende automaticamente conforme un sistema.
- Il fine-tuning non risolve automaticamente un workflow progettato male.
- Non tutti i processi producono abbastanza valore da giustificare i costi di integrazione e di gestione.
- Gli esiti di business dipendono da progettazione del processo, dati, sistemi, persone e architettura di deployment.
Inizia da un workflow che sai descrivere.
Mostraci un processo ripetitivo, i sistemi che coinvolge, le eccezioni che il tuo team gestisce e che cosa accade quando qualcosa va storto. Possiamo mappare dove basta l'automazione deterministica, dove l'AI può aiutare e dove le persone devono rimanere al comando.