Probabilistico e deterministico: dove finisce l'interpretazione e comincia la decisione

In sintesi. Un sistema probabilistico interpreta un input e produce un output plausibile, con una distribuzione di esiti possibili. Un sistema deterministico applica regole note e produce lo stesso risultato a ogni esecuzione. La maggior parte dei progetti che si bloccano mette il modello nel punto dove serviva una regola, oppure scrive regole dove l'input è troppo vario perché una regola lo copra. Il confine utile è questo: il probabilistico interpreta e propone, il deterministico calcola e decide.

Questa distinzione non è teorica. Cambia come si progetta l'architettura, come si misura la qualità, quanto costa il presidio e cosa si riesce a dimostrare in un audit.

Due macchine con proprietà diverse

Proprietà	Deterministico	Probabilistico
Input	Strutturato, campi previsti	Anche testo libero, documenti, voce
Output	Uno solo, sempre lo stesso	Uno tra molti plausibili
Ripetibilità	Totale	Parziale, varia con versione e parametri
Errore	Un difetto nella regola, localizzabile	Statistico, si riduce e non si azzera
Verifica	Test sui casi noti, eseguibili a ogni rilascio	Campionamento continuo sugli output reali
Spiegazione	La regola stessa	Ricostruzione indiretta, mai completa
Costo marginale	Vicino a zero	Proporzionale al volume e alla lunghezza

La riga sulla ripetibilità è quella che pesa di più nelle organizzazioni regolate. Un controllo deterministico eseguito oggi e tra sei mesi sullo stesso input produce lo stesso esito, e questo rende possibile dimostrare come si è arrivati a una decisione. Un modello aggiornato dal fornitore può cambiare comportamento senza che nessuno abbia toccato il vostro sistema.

Dove il probabilistico lavora bene

Il modello è adatto quando l'input è vario e la mappatura tra input e risposta non si può scrivere in anticipo. Tre famiglie di compiti ricorrono in quasi tutti i settori.

L'estrazione da documenti non strutturati: leggere un contratto, un referto, una lettera di un fornitore e tirarne fuori campi che una persona avrebbe letto a mano. La classificazione di richieste in linguaggio naturale, dove la stessa intenzione arriva scritta in cento modi diversi. La sintesi e la redazione di bozze, dove l'output è materiale che una persona rivede prima di usarlo.

In tutti e tre i casi l'output è una proposta. Qualcuno o qualcosa a valle decide se accettarla, e quel qualcosa è spesso una regola.

Quando l'esito deve essere sempre lo stesso

Quando l'esito deve essere identico a ogni esecuzione, quando produce un effetto giuridico o economico diretto, quando deve essere ricostruibile a distanza di anni.

Il calcolo di un importo, di un'imposta, di una penale. L'applicazione di una soglia di autorizzazione. La verifica che un documento contenga i campi obbligatori previsti da una norma. Il controllo di coerenza tra due sistemi. L'assegnazione di un diritto o di un beneficio sulla base di criteri scritti.

Un modello linguistico che somma numeri può sbagliare, e il problema non è la frequenza dell'errore, è che l'errore non è prevedibile e il risultato cambia tra due esecuzioni. Nessuna quantità di istruzioni elimina questa proprietà, perché deriva dal modo in cui il sistema genera la risposta.

Il modello che interpreta, la regola che decide

L'architettura che funziona nella maggior parte dei casi aziendali mette i due mondi in sequenza, con il modello a monte e le regole a valle.

Fase	Natura	Esempio su un flusso documentale
Acquisizione	Deterministica	Il file arriva, viene registrato con un identificativo
Interpretazione	Probabilistica	Il modello estrae i campi dal documento
Validazione	Deterministica	Formati, intervalli, coerenza con l'anagrafica, totali ricalcolati
Arricchimento	Deterministica	I dati di riferimento arrivano dai sistemi interni, non dal modello
Decisione	Deterministica	Soglie e regole di autorizzazione
Eccezione	Umana	I casi che la validazione scarta vanno a una persona

La riga sull'arricchimento merita una nota. Un modello non deve ricordare il saldo di un cliente o la giacenza di un articolo, perché quello è un dato che vive in un sistema e cambia ogni ora. Il modello estrae il codice articolo, il sistema restituisce la giacenza corrente.

Questa separazione ha un effetto diretto sul costo di presidio. La parte probabilistica va monitorata con campionamento continuo, mentre la parte deterministica si verifica con una suite di test che gira a ogni rilascio, e spostare più logica possibile verso il secondo lato riduce il lavoro ricorrente.

L'astensione come requisito di progetto

Un modello che risponde sempre è pericoloso in un flusso operativo, perché produce un output anche quando l'informazione non c'è.

Il comportamento da richiedere in fase di progettazione è diverso: quando la confidenza scende sotto una soglia, il sistema si ferma e passa il caso a una persona. Questo significa definire la soglia, misurare quanti casi finiscono in astensione e trattare quel numero come un indicatore di progetto invece che come un fallimento.

Trattare il sessanta per cento dei casi con un errore residuo dell'uno per cento vale più del novanta per cento con un errore del dieci, perché il secondo genera un carico di correzione che si mangia il beneficio e, nelle attività sensibili, un rischio che qualcuno dovrà spiegare.

Come si misura ciascuno dei due

Le due parti richiedono strumenti di misura diversi, e confonderli è un errore frequente.

Il lato deterministico si misura con la copertura dei casi di test: quante condizioni previste dalle regole sono coperte da un test automatico, e quante volte la suite passa. È un lavoro di ingegneria del software ordinario.

Il lato probabilistico richiede invece un campione etichettato, e tre numeri: la quota di output corretti sul campione, la quota di casi in cui il sistema si è astenuto, e la quota di errori che la validazione a valle ha intercettato. L'ultimo numero è il più utile, perché dice quanto le regole stanno proteggendo il processo dagli errori del modello.

Su questo campione vale una regola di costruzione. Va aggiornato quando cambia il mix dei casi reali, altrimenti misura un mondo che non esiste più, e va conservato con la versione del modello usata, perché senza quell'informazione un confronto tra due misurazioni non significa nulla.

Cosa cambia per la documentazione e l'audit

Dove tutto è deterministico, il sistema si descrive con le sue regole, e quella descrizione è anche la spiegazione del comportamento.

Un sistema che contiene un modello richiede altro: la versione del modello e la data in cui è cambiata, le istruzioni di sistema in uso, i criteri di astensione, i risultati della valutazione sul campione, i controlli a valle, e la registrazione delle decisioni prese. Questo pacchetto diventa obbligatorio quando il sistema ricade in Allegato III dell'AI Act, e resta comunque utile anche quando non lo è, perché è l'unico modo di rispondere a una contestazione a distanza di mesi.

C'è una conseguenza pratica che vale la pena anticipare. Più logica si sposta sul lato deterministico, meno superficie di documentazione resta sul lato probabilistico, e questo riduce sia il costo di conformità sia il tempo di risposta a una verifica.

Gli errori che si ripetono

Il primo è mettere il modello nel punto di decisione, perché la demo funzionava. Un assistente che propone un importo è utile, un assistente che lo approva sposta il rischio su un componente che non garantisce lo stesso esito due volte.

Il secondo è usare regole dove l'input è irriducibile. Un flusso di richieste in linguaggio naturale non si copre con una tassonomia di parole chiave, e ogni tentativo produce un albero di eccezioni che nessuno mantiene.

Il terzo è non misurare la parte probabilistica, affidandosi alla sensazione degli utenti. La sensazione cambia con l'umore del periodo e con i casi recenti, e non permette di capire se un aggiornamento del fornitore ha spostato il comportamento.

Il quarto è lasciare che il modello faccia da memoria. I dati operativi devono arrivare dai sistemi che li detengono, e il modello deve essere trattato come un interprete di testo, non come un archivio.

Da dove partire

Il quadro sui tipi di automazione e su cosa conviene automatizzare è in automazione AI dei processi, mentre la parte di preparazione del dato è in data readiness e data governance per l'AI.

Sul perché un sistema ragiona oppure indovina, e sul ruolo delle strutture di conoscenza, c'è ontologie e infrastruttura.

Per la classificazione del sistema, che cambia la quantità di documentazione richiesta, c'è classificazione dei sistemi AI per rischio.

Per capire quale parte dei vostri processi va su regole e quale su modello puoi fissare un incontro di valutazione.