Processi scritti in un linguaggio. Agenti che li rispettano.
Evo Calabs porta l'intelligenza artificiale dentro il Business Process Management. I processi si descrivono con linguaggi di dominio (DSL) che chi li gestisce sa leggere; gli agenti AI li eseguono; ogni azione passa da una regola verificabile prima di accadere.
La locomotiva sul carro
Quando arrivò il motore a vapore, il primo istinto fu montarlo sopra la carrozza a cavalli. Andava, finché alla prima curva il peso la ribaltava. Con l'AI succede lo stesso: un chatbot sopra il software e i processi di sempre. Nella demo funziona; nel lavoro vero si ribalta.
La ferrovia non era una carrozza più veloce: servivano binari, segnali e regole. Per l'AI i binari sono il processo descritto, i segnali sono le regole che lo proteggono. Evo Calabs costruisce entrambi, nello stesso linguaggio.
Non si governa ciò che non si è descritto
Prima di automatizzare un processo lo descriviamo su tre piani. Ogni piano ha il suo linguaggio, e ognuno è versionato come codice: si legge, si confronta, si torna indietro.
Cosa esiste
Entità, sistemi, ruoli, fonti di conoscenza. Un registro unico dell'azienda, su cui persone, software e agenti lavorano con gli stessi nomi.
Cosa può accadere
Processi, azioni, passaggi di stato. Scritti nei DSL di business ed eseguiti dal motore BPM, con gli agenti AI come esecutori di singoli passi.
Cosa deve accadere
Permessi, obblighi, divieti. Scritti come ToolGuard e compilati in controlli che il runtime valuta prima di ogni azione di un agente.
Più l'azienda può verificare, più può delegare.
Un DSL si legge senza tradurlo e si esegue senza interpretarlo
Un linguaggio di dominio è piccolo e costruito attorno a un solo tema. Chi conosce il processo lo legge; il motore lo esegue così com'è. Separiamo due famiglie: i DSL di business dicono cosa fare e perché, i DSL per l'AI dicono come l'agente ci arriva.
DSL di business IL COSA
- Workflow BPM: sequenze, decisioni, parallelismi, condizioni di passaggio.
- Regole di business: le decisioni (sconti, rischio, soglie) fuori dal codice del processo.
- Mappatura delle condizioni: quando un passo si attiva e quando no.
- Mappatura di campi e webservice: come i dati entrano ed escono dai sistemi esterni.
- Dipendenze tra campi: i vincoli tra i dati di una pratica.
- Documentazione generativa: manuali e schemi prodotti dalla definizione del processo, sempre allineati.
DSL per l'AI IL COME
- RAG agentico: quali fonti l'agente interroga, come le filtra e come le combina prima di rispondere.
- Pipeline agentiche: quali agenti, con quali strumenti, in che ordine, con quali passaggi a una persona.
- Firme e moduli: il compito dell'agente dichiarato per input e output; i prompt si ottimizzano sui dati, non si scrivono a mano.
Un esempio: la fattura di un fornitore. La regola di approvazione sta nel DSL di business. L'agente, con il DSL per il RAG, consulta contratti e policy interne, verifica la conformità e approva, oppure passa la pratica a una persona con il fascicolo già pronto.
Il modello può scrivere una regola. Non può valutarla.
Una policy in PDF non ferma un agente. Una ToolGuard sì: è una regola scritta in DSL, compilata in controlli deterministici e valutata dal runtime prima e dopo ogni chiamata a uno strumento. Tra chi propone la regola e chi la applica c'è una grammatica formale, non un prompt.
Proposta
Un LLM, o una persona, scrive la regola in DSL. È l'unico punto non deterministico, ed è contenuto.
Parsing
La grammatica accetta la regola o la rifiuta. Una regola malformata o inventata si ferma qui.
Compilazione
Lo stesso testo produce sempre gli stessi controlli.
Valutazione
Stesso input, stesso verdetto: l'azione passa, genera un avviso o viene fermata e affidata a una persona.
non deterministico, contenutodeterministico
// Il processo: una richiesta di adozione di uno strumento AI
process richiesta_ai {
states: [bozza, inviata, valutazione_it, valutazione_privacy,
approvazione_comitato, approvata, respinta]
transitions {
bozza -> inviata
inviata -> valutazione_it
valutazione_it -> valutazione_privacy
valutazione_privacy -> approvazione_comitato : requires rischio NOT MATCHES /inaccettabile/
approvazione_comitato -> approvata
}
}
// La regola: che cosa un agente non può registrare da solo
toolguard registra_sistema_ai {
pre {
assert categoria_rischio NOT MATCHES /inaccettabile/
assert tipologia_dati NOT MATCHES /biometrici|art_9/
}
on_violation: escalate(comitato_ai)
}
- Le regole sono dati, non codice: nulla di ciò che è salvato come regola viene eseguito come programma.
- Ogni valutazione lascia una traccia, così «nessuna violazione» si distingue da «nessun controllo».
- Se esistono regole critiche e il controllo non risponde, l'azione si ferma.
- Ciò che la grammatica accetta ma il runtime non sa ancora verificare viene segnalato come non compilato, mai scartato in silenzio.
Anche la governance dell'AI è un processo
DSL e ToolGuard hanno bisogno di un luogo dove le persone vedono, approvano e verificano. Lo stiamo progettando con Evolutivo come portale per la governance dell'AI in azienda: le approvazioni corrono sul motore BPM, le regole sono ToolGuard, ogni passaggio resta tracciato.
Registro dei sistemi AI
Ogni strumento con fornitore, responsabile interno, finalità, categoria di rischio secondo l'AI Act e data della prossima revisione.
Richieste di adozione
Dalla bozza all'approvazione del comitato, passando per funzione, IT, privacy, legale e budget. Un workflow BPM con la traccia completa di ogni passaggio.
Policy e presa visione
Pubblicazione versionata delle policy, accettazione registrata per persona e per versione.
Osservazione delle interazioni
L'uso dell'AI misurato in forma pseudonimizzata, nel rispetto dell'AI Act e dell'art. 4 dello Statuto dei Lavoratori.
Revisioni periodiche
Programmate dal processo, con promemoria prima della scadenza. L'esito aggiorna il registro.
Fascicolo di valutazione
Per ogni richiesta, un documento con la domanda e l'intera sequenza delle approvazioni, pronto per un'ispezione.
Riferimenti normativi: Regolamento (UE) 2024/1689 (AI Act), GDPR, ISO/IEC 27001, direttiva NIS2.
Le persone ai cancelli
Automatizzare non significa togliere le persone dal processo: significa metterle dove servono. Gli steward sono agenti senza autorità: chiedono, osservano, documentano e coprono i passaggi tra un ufficio e l'altro. I custodi sono persone: decidono nei punti in cui l'AI non deve decidere da sola.
Quando una ToolGuard chiede una decisione umana, il processo si mette in pausa, mostra il contesto a chi deve decidere e riprende con la sua risposta. La decisione entra nella traccia come ogni altro passo.
Dall'esperienza di Evolutivo, con la ricerca accademica
Evo Calabs SRL nasce dall'esperienza maturata da Evolutivo nel Business Process Management ed è un'iniziativa legata alla ricerca accademica sui sistemi informativi, con un obiettivo preciso: portare il BPM a un livello successivo. Ha sede a Catanzaro e trasforma in prodotto la ricerca sui linguaggi di dominio, sugli agenti AI e sulla governance dell'AI.
I DSL di business nascono sulla piattaforma open source coreBOS, su cui Evolutivo costruisce i propri progetti di gestione dei processi. Evo Calabs li estende con i DSL per l'AI, il motore delle ToolGuard e il portale di governance.
Portateci un processo
Scegliete un processo che oggi dipende da poche persone e da molte email. Lo descriviamo insieme nei nostri linguaggi, indichiamo dove un agente può lavorare e quali regole deve rispettare.