EVO CALABSBPM, AI e linguaggi di dominio
BPM · Intelligenza artificiale · Linguaggi di dominio

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.

Il problema

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.

Metodo

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.

1

Cosa esiste

Entità, sistemi, ruoli, fonti di conoscenza. Un registro unico dell'azienda, su cui persone, software e agenti lavorano con gli stessi nomi.

2

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.

3

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.

I linguaggi

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.

ToolGuard

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.

  1. Proposta

    Un LLM, o una persona, scrive la regola in DSL. È l'unico punto non deterministico, ed è contenuto.

  2. Parsing

    La grammatica accetta la regola o la rifiuta. Una regola malformata o inventata si ferma qui.

  3. Compilazione

    Lo stesso testo produce sempre gli stessi controlli.

  4. 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)
}
Processo e regola nello stesso linguaggio. Il testo è valido per il compilatore che usiamo sui nostri agenti.
  • 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.
Dichiarazione dell'agente ToolGuard Confine di processo Contratto di comunicazione
Portale di governance AI IN PROGETTAZIONE

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

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.

Chi siamo

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.

Contatti

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.