Per decenni il Process Mining è stato uno strumento di osservazione. Le aziende raccoglievano event log, ricostruivano i propri flussi operativi in modelli grafici, individuavano i colli di bottiglia e poi, manualmente, decidevano come intervenire. Un ciclo analitico, retrospettivo, per sua natura passivo.
Nel 2026 questo paradigma comincia a vacillare. La convergenza di tre tecnologie ormai mature — i foundation model addestrati specificamente sui dati di processo, i Large Language Model generici e i sistemi multi-agente autonomi — rende possibile un’architettura diversa: sistemi che non si limitano a osservare i processi, ma li gestiscono in autonomia, prendendo decisioni operative in tempo reale.
Non è uno scenario futuribile: è un’architettura realizzabile oggi con strumenti open-source e commerciali già disponibili. La domanda che un professionista dell’innovazione dovrebbe porsi non è se questo modello funzionerà, ma come implementarlo in modo etico, governato e conforme alle normative.
Indice degli argomenti
La convergenza tecnologica: le componenti
Il Process Mining fornisce la “verità operativa” dell’organizzazione.
Process mining come fondamento operativo
Strumenti come PM4Py, Celonis o ProM analizzano gli event log — timestamp, attività, risorse, casi — e restituiscono modelli di processo scoperti automaticamente, analisi di conformità, predizioni su tempi di completamento e rischi di deviazione.
Fin qui nulla di nuovo. Il salto avviene quando questi output possono essere consegnati a un sistema di agenti AI autonomi, capaci di intervenire direttamente sull’adattamento del processo.
Foundation model per process mining: il motore predittivo specializzato
Un elemento spesso trascurato nel dibattito pubblico è quello dei foundation model addestrati specificamente su tracce di processo, provenienti da settori diversi, manifatturiero, sanitario, finanziario, logistico, pubblica amministrazione. A differenza dei LLM generici (GPT, Claude), che apprendono il linguaggio naturale da corpus testuali enormi, questi modelli riconoscono nativamente pattern di processo, deviazioni, colli di bottiglia, correlazioni tra attività.
Un filone di ricerca recente sui foundation model per il predictive process monitoring esplora l’in-context learning applicato ai processi: la possibilità di condizionare il modello su un nuovo event log aziendale e, senza retraining, ottenere la predizione della prossima attività di un caso in esecuzione, la stima del tempo residuo di completamento, l’identificazione di anomalie e deviazioni dalla traccia attesa, il rilevamento di pattern ricorrenti di rischio.
Questo è rilevante per un sistema agentico perché fornisce agli agenti un motore predittivo specializzato, potenzialmente più accurato e a più bassa latenza di quanto un LLM generico possa replicare per questo compito specifico. Un LLM può descrivere un processo in linguaggio naturale, ma non è progettato per stimare, su base statistica e a partire da milioni di casi storici, la probabilità che un caso di procurement finisca in ritardo.
L’architettura tipica è quindi ibrida: il foundation model di PM gestisce la parte numerica, predittiva, statistica; il LLM generico gestisce la parte contestuale, linguistica, il ragionamento su policy e documenti; gli agenti orchestrano i due, combinando i segnali predittivi con la conoscenza aziendale recuperata dalla documentazione interna.
Large Language Model come livello di ragionamento contestuale
I LLM introducono una capacità critica: la comprensione semantica del contesto aziendale. Un agente LLM legge un’anomalia segnalata dal foundation model di PM, consulta policy aziendali, contratti e regolamenti interni tramite retrieval augmented generation, formula un piano d’azione in linguaggio naturale e comunica la decisione agli stakeholder.
Sistemi Multi-Agente: l’orchestrazione
L’architettura finale combina questi elementi in un sistema multi-agente specializzato:
- Discovery Agent: monitora continuamente gli event log e i segnali predittivi dal foundation model di PM
- Analyst Agent: consulta la documentazione aziendale pertinente per identificare le cause alla radice delle disfunzioni
- Decision Agent: formula piani d’azione basati su policy e vincoli
- Execution Agent: ha accesso API ai sistemi aziendali (ERP, CRM, email) e implementa le decisioni
Un esempio illustrativo: il collo di bottiglia procure-to-pay
Lo scenario che segue è ipotetico e a scopo puramente illustrativo: valori percentuali, p-value e tempi sono inventati per mostrare come le componenti dell’architettura interagirebbero, non dati misurati su un sistema reale.
In un’azienda manifatturiera il processo Procure-to-Pay mostra segnali di sofferenza.
Scenario tradizionale
Un analista di processo estrae i dati, costruisce un dashboard, scopre che le fatture del Fornitore X richiedono 14 giorni invece dei 3 standard, scrive un report, lo presenta al management, che decide. Il ciclo richiede settimane.
Scenario agentico con foundation model
Giorno 1, ore 9:00 — Il foundation model di process mining, alimentato in continuo dagli event log dell’ERP, segnala un’anomalia predittiva: i casi che coinvolgono il Fornitore X mostrano, nell’esempio, una probabilità elevata di superare i 10 giorni di ciclo, con una deviazione significativa dal modello di conformità.
Giorno 1, ore 9:02 — Il Discovery Agent riceve il segnale e lo passa all’Analyst Agent.
Giorno 1, ore 9:05 — L’Analyst Agent consulta i contratti con i fornitori e le policy OCR aziendali. Emerge che il Fornitore X ha recentemente cambiato il formato PDF delle fatture: il sistema OCR aziendale non riesce a leggerlo e instrada automaticamente i documenti in una coda manuale di eccezioni, attualmente sotto-organico.
Giorno 1, ore 9:15 — Il Decision Agent valuta l’analisi e verifica cosa suggeriscono le policy aziendali in una situazione simile, quindi formula un piano: mitigazione immediata, riassegnando due clerk dalla coda “Travel Expenses” (sottocarica) alla coda “Invoice Exceptions”; fix a lungo termine, inviando una comunicazione al Fornitore X per richiedere l’uso del portale API aziendale invece dei PDF; aggiornamento del sistema, sospendendo temporaneamente l’elaborazione OCR dei PDF del Fornitore X fino a un nuovo formato concordato.
Giorno 1, ore 9:20 — L’Execution Agent accede all’ERP via API e riassegna i due clerk, aggiorna le regole di routing OCR, invia la comunicazione al Fornitore X, registra tutte le azioni nel sistema di audit.
In questo scenario ipotetico il ciclo si chiude in circa venti minuti, senza intervento umano diretto, sulla base di predizioni statistiche del foundation model di PM, policy aziendali recuperate dalla documentazione interna e ragionamento contestuale del LLM.
Come implementarlo: l’architettura tecnica
PM4Py, open-source, come motore di base; modelli transformer pre-addestrati su event log (la letteratura recente propone diverse architetture in questo spazio); deployment come microservizio che espone API di predizione (next activity, remaining time, anomaly score).
Il frammento seguente è pseudo-codice, non eseguibile: non corrisponde a nessuna libreria reale ed è mostrato solo per illustrare l’idea di interfaccia. PM4Py non include, ad oggi, un modulo algo.analysis.transformer con queste funzionalità; un’implementazione reale richiederebbe una libreria esterna dedicata (custom, basata su PyTorch/Keras, o un progetto di ricerca specifico) che consumi l’output di PM4Py:
# PSEUDO-CODICE — nessuna libreria corrisponde esattamente a questa interfaccia
predictor = FoundationModelPM(model_path=”pm_foundation_model”)
prediction = predictor.predict_next_activity(event_log_trace)
Layer di ragionamento
LLM generico per l’interpretazione contestuale e la formulazione dei piani d’azione; retrieval augmented generation sulla documentazione aziendale per il recupero di policy e procedure.
Layer di orchestrazione Multi-Agente
Il Discovery Agent consuma le API del foundation model di PM; il Decision Agent combina segnali predittivi, retrieval documentale e ragionamento LLM; ogni agente accede solo alle informazioni pertinenti al proprio ruolo.
Layer di esecuzione
API gateway verso sistemi aziendali (ERP, CRM, email); meccanismi di approvazione umana per decisioni ad alto rischio; logging completo per audit trail.
La questione etica
Un’obiezione ricorrente riguarda la liceità di lasciare che un’IA prenda decisioni operative senza supervisione umana diretta. La risposta dipende in larga misura da come il sistema è progettato.
Se ben progettata, l’architettura descritta può incorporare alcuni principi di governance:
Tracciabilità
Ogni decisione può essere loggata con i segnali predittivi del foundation model, i documenti recuperati, la motivazione generata dal LLM, le azioni eseguite: un audit trail potenzialmente più dettagliato di molti processi decisionali umani, che restano spesso non documentati.
Confinamento del contesto
Ogni agente accede solo alle informazioni pertinenti al proprio ruolo: un agente di procurement non consulta dati HR. Questo riduce, senza eliminarlo, il rischio di decisioni fuori contesto.
Soglie di escalation
Il sistema può essere configurato per escalare automaticamente a un umano quando la decisione supera una soglia finanziaria, il caso è ambiguo, l’impatto coinvolge stakeholder esterni, o si rilevano pattern anomali non previsti.
Allineamento valoriale
Gli agenti possono essere orientati a valori organizzativi espliciti — dignità delle persone coinvolte, equità, sostenibilità — codificati nella documentazione di riferimento e recuperati contestualmente, con il limite che tale allineamento dipende dalla qualità e dalla completezza di come questi valori sono stati codificati.
Responsabilità
L’architettura agentica non elimina la responsabilità umana: la ridistribuisce. Gli umani definiscono le policy, monitorano le performance, intervengono in caso di ambiguità e restano responsabili del design del sistema.
Le sfide normative
L’implementazione di sistemi agentici solleva questioni normative rilevanti, specialmente in Europa con il GDPR e l’AI Act.
GDPR e processo decisionale automatizzato
L’articolo 22 del GDPR riconosce all’interessato il diritto a non essere sottoposto, salvo eccezioni, a decisioni basate unicamente su trattamento automatizzato che producano effetti giuridici o incidano significativamente sulla persona.
Se l’agente prende decisioni che riguardano dipendenti o altri interessati, occorre un meccanismo di intervento umano effettivo e informazioni chiare sulla logica sottostante. Il retrieval documentale e la motivazione generata dal LLM possono contribuire alla spiegabilità richiesta, ma non la garantiscono automaticamente: la conformità va valutata caso per caso, anche perché l’art. 22 GDPR e l’obbligo di sorveglianza umana previsto dall’AI Act (art. 14) sono basi giuridiche distinte, con requisiti non perfettamente sovrapponibili.
AI Act e sistemi ad alto rischio
I sistemi agentici potrebbero rientrare in categorie ad alto rischio se gestiscono risorse finanziarie significative o operano in settori regolamentati. I requisiti includono valutazione di conformità, sistemi di gestione del rischio, qualità dei dati, trasparenza, sorveglianza umana, accuratezza e cybersecurity.
I sistemi agentici descritti possono incorporare nativamente alcuni di questi requisiti — audit trail, escalation umana, retrieval documentale — ma restano soggetti a una valutazione formale di conformità caso per caso, che l’architettura da sola non sostituisce.
La specificità dei foundation model di PM
Un aspetto normativo spesso trascurato riguarda i foundation model di process mining addestrati su dati di processo provenienti da più organizzazioni. Questo solleva questioni aperte, ancora poco coperte dalla letteratura: la proprietà dei dati di training, ossia se e come gli event log di un’organizzazione siano stati usati per addestrare il modello; la riservatezza competitiva, ossia se il modello possa aver memorizzato pattern riconducibili a un concorrente; la trasparenza, ossia se e come dichiarare agli stakeholder l’uso di un foundation model pre-addestrato su dati terzi.
Una possibile mitigazione consiste nel preferire deployment on-premise o foundation model fine-tuned sui propri dati, richiedere ai fornitori garanzie contrattuali di non-contaminazione, documentare la provenienza dei dati di training.
Responsabilità Civile
Chi risponde se un agente AI prende una decisione errata che causa danni finanziari è, ad oggi, un quadro normativo in evoluzione. I principi emergenti indicano una possibile responsabilità del fornitore, in caso di difetto di progettazione, dell’utilizzatore, in caso di uso improprio, o condivisa, a seconda dei fatti concreti.
Sul piano pratico, conviene predisporre coperture assicurative specifiche per rischi AI, contratti che allochino chiaramente le responsabilità, documentazione completa, meccanismi di rollback.
Chi potrà avvantaggiarsi dalla gestione agentica dei processi e come
La gestione agentica dei processi è un’architettura implementabile già oggi, che combina foundation model specializzati per il process mining come motore predittivo, LLM generici per il ragionamento contestuale, sistemi multi-agente per l’orchestrazione autonoma.
Le domande aperte per chi valuta questi sistemi non riguardano tanto la fattibilità tecnica, quanto come implementarli in modo etico e governato, quali processi si prestino davvero all’automazione agentica e quali no, come preparare l’organizzazione a collaborare con agenti AI autonomi, quali competenze occorra sviluppare internamente.
Le organizzazioni che inizieranno a sperimentare con questi sistemi nel 2026-2027 potranno acquisire un vantaggio, non tanto perché automatizzano processi esistenti, quanto perché costruiscono sistemi che apprendono, predicono e agiscono in modo adattivo — liberando risorse umane per attività a maggior valore aggiunto.
La tecnologia esiste, così come gli strumenti. La questione etica è affrontabile con un design consapevole. Le normative, pur complesse, non vietano l’innovazione: la orientano.
Partecipa alla community