Il confine che l’architettura deve proteggere
Un sistema legge una richiesta, ne interpreta il contenuto e deve aggiornare CRM, creare un ticket e chiedere approvazione. Il modello può proporre dati, ma non governa da solo transazioni e retry. L’AI deve produrre un’interpretazione delimitata; il workflow deterministico deve validarla e decidere quali azioni sono consentite.
Nel perimetro «separare decisione probabilistica e controllo deterministico», il confine passa da «parte che richiede interpretazione»: qui una responsabilità, un permesso o un’interpretazione diventano stato operativo. Separa output probabilistico e controllo di processo con un contratto tipizzato fra i due livelli.
I componenti, spiegati attraverso structured output, schema validation, confidence routing e deterministic executor
Il componente responsabile di «azioni deterministiche successive» dichiara input, output e risposta a «prompt usato come workflow». Questo contratto precede la scelta della piattaforma e può diventare un test autonomo; il controesempio viene cercato in «azioni senza idempotenza».
Parte che richiede interpretazione
Questo controllo appartiene al livello che possiede il dato. Il componente responsabile di «parte che richiede interpretazione» espone «azioni deterministiche successive» nel proprio contratto e ferma il flusso in presenza di «prompt usato come workflow».
Azioni deterministiche successive
Il componente deve esporre questo confine. Il componente responsabile di «azioni deterministiche successive» espone «permessi e transazioni» nel proprio contratto e ferma il flusso in presenza di «azioni senza idempotenza».
Permessi e transazioni
Il contratto non può lasciarlo implicito. Il componente responsabile di «permessi e transazioni» espone «gestione di errori ed eccezioni» nel proprio contratto e ferma il flusso in presenza di «assenza di stato persistente».
Gestione di errori ed eccezioni
Qui si decide che cosa può proseguire. Il componente responsabile di «gestione di errori ed eccezioni» espone «parte che richiede interpretazione» nel proprio contratto e ferma il flusso in presenza di «nessun confine fra proposta ed esecuzione».
Il flusso end-to-end
Durante «definire output strutturato del modello» nasce l’identità del caso; «validare prima di agire» cambia lo stato senza perderla. Separare questi due passaggi permette di sostituire il meccanismo senza ridefinire separare decisione probabilistica e controllo deterministico.
- 1
Definire output strutturato del modello
Il passaggio «definire output strutturato del modello» accetta un input definito e restituisce «parte che richiede interpretazione» con provenienza. Il contratto gestisce «prompt usato come workflow» prima di invocare «validare prima di agire».
- 2
Validare prima di agire
Il passaggio «validare prima di agire» accetta un input definito e restituisce «azioni deterministiche successive» con provenienza. Il contratto gestisce «azioni senza idempotenza» prima di invocare «orchestrare con stati espliciti».
- 3
Orchestrare con stati espliciti
Il passaggio «orchestrare con stati espliciti» accetta un input definito e restituisce «permessi e transazioni» con provenienza. Il contratto gestisce «assenza di stato persistente» prima di invocare «inserire approvazioni per rischio».
- 4
Inserire approvazioni per rischio
Il passaggio «inserire approvazioni per rischio» accetta un input definito e restituisce «gestione di errori ed eccezioni» con provenienza. Il contratto gestisce «nessun confine fra proposta ed esecuzione» prima di invocare «registrare input, decisione ed esito».
- 5
Registrare input, decisione ed esito
Il passaggio «registrare input, decisione ed esito» accetta un input definito e restituisce «parte che richiede interpretazione» con provenienza. Il contratto gestisce «prompt usato come workflow» prima di invocare «definire output strutturato del modello».
Il contratto fra i passaggi
Per trasferire «permessi e transazioni» servono versione, provenienza e risultato ammesso. Se «orchestrare con stati espliciti» deve reinterpretare uno di questi elementi, la separazione fra componenti è soltanto grafica.
Nel tema «separare decisione probabilistica e controllo deterministico» un output limitato e validabile è più sicuro di una risposta ricca davanti a «azioni senza idempotenza». Gli stati «non disponibile» e «richiede revisione» fanno parte del contratto; la decisione resta collegata a «validare prima di agire».
Un dato che non va reinterpretato
Caso isolato: «gestione di errori ed eccezioni». Operazione osservata: «validare prima di agire». Deviazione forzata: «prompt usato come workflow».
Contratto osservato: «Structured output, schema validation, confidence routing e deterministic executor». Il componente non può reinterpretare «gestione di errori ed eccezioni». Perimetro della prova: «separare decisione probabilistica e controllo deterministico».
Controprova: «azioni deterministiche successive». Arresto: «assenza di stato persistente». Passo ammesso dopo il recupero: «inserire approvazioni per rischio». Verbale finale: «Perché un modello linguistico non sostituisce l’orchestrazione del processo?»
Differenza decisiva: «Separa output probabilistico e controllo di processo con un contratto tipizzato fra i due livelli». Regola di chiusura: «Il confine sano permette di sostituire il modello senza riscrivere il processo e di fermare un output che viola una regola nota».
Dove l’architettura deve fermarsi
«prompt usato come workflow» può consentire un nuovo tentativo; «azioni senza idempotenza» può richiedere autorizzazione; «assenza di stato persistente» può invalidare la fonte. Un solo fallback nasconderebbe decisioni diverse.
Prompt usato come workflow
Rischio nominato: «prompt usato come workflow». Perimetro operativo: «separare decisione probabilistica e controllo deterministico». Segnale osservato: «parte che richiede interpretazione». Recupero ammesso: «validare prima di agire». Checkpoint finale: «parte che richiede interpretazione».
Azioni senza idempotenza
Rischio nominato: «azioni senza idempotenza». Perimetro operativo: «separare decisione probabilistica e controllo deterministico». Segnale osservato: «azioni deterministiche successive». Recupero ammesso: «orchestrare con stati espliciti». Checkpoint finale: «azioni deterministiche successive».
Assenza di stato persistente
Rischio nominato: «assenza di stato persistente». Perimetro operativo: «separare decisione probabilistica e controllo deterministico». Segnale osservato: «permessi e transazioni». Recupero ammesso: «inserire approvazioni per rischio». Checkpoint finale: «permessi e transazioni».
Nessun confine fra proposta ed esecuzione
Rischio nominato: «nessun confine fra proposta ed esecuzione». Perimetro operativo: «separare decisione probabilistica e controllo deterministico». Segnale osservato: «gestione di errori ed eccezioni». Recupero ammesso: «registrare input, decisione ed esito». Checkpoint finale: «gestione di errori ed eccezioni».
Osservare il sistema con domande operative
La vista operativa collega «gestione di errori ed eccezioni» al componente che ha deciso e al destinatario di «nessun confine fra proposta ed esecuzione». Un generico «success/fail» non risponde a nessuna di queste domande; qui la prova concreta è «Structured output, schema validation, confidence routing e deterministic executor».
L’operatore vede l’identificatore necessario a «registrare input, decisione ed esito»; i dettagli tecnici possono restare altrove, purché il collegamento non dipenda da nomi file o memoria individuale.
La decisione architetturale
Il confine sano permette di sostituire il modello senza riscrivere il processo e di fermare un output che viola una regola nota. Il test di «Structured output, schema validation, confidence routing e deterministic executor» deve mantenere il confine durante errore, modifica e revoca.
Il confine sano permette di sostituire il modello senza riscrivere il processo e di fermare un output che viola una regola nota. Il contratto è sufficiente quando «azioni senza idempotenza» resta confinato, «parte che richiede interpretazione» conserva provenienza e «definire output strutturato del modello» non deve indovinare lo stato precedente.
Contesto e limiti
Nello scenario ipotetico l’obiettivo non è stimare ROI, ma capire se stato, dato e owner restano leggibili durante il cambiamento; il controesempio viene cercato in «permessi e transazioni». Il fallback viene progettato insieme al percorso standard.
Prossimo passo
Hai un caso d’uso, non ancora una soluzione?
Porta un’attività concreta, le fonti disponibili e il risultato atteso. Verifichiamo se l’AI è lo strumento giusto.