Partiamo dal fallimento, non dal percorso felice
Un assistente prepara risposte e aggiorna un sistema. Anche con istruzioni chiare può ricevere input malevoli, usare fonti sbagliate o proporre un’azione non consentita. Il guasto rende osservabile il confine «Input policy, tool allowlist, output validation, rate limit e audit» e obbliga a distinguere «azioni che il sistema può eseguire» da «affidare tutto al prompt».
I guardrail efficaci sono controlli distribuiti prima, durante e dopo il modello; un prompt che elenca divieti non può presidiare accessi, strumenti e azioni. Per questo la soluzione va scomposta in stati osservabili, ciascuno con un’identità e una regola di recupero; il controllo associato riguarda «formato e vincoli dell’output».
Il modello mentale corretto
Il sistema riceve un input, applica una decisione, produce un effetto e registra una prova; nel perimetro descritto conta «registrare fonti e decisioni». Se uno di questi elementi non ha identità propria, dopo un timeout non è possibile distinguere «non eseguito» da «eseguito ma non confermato»; il controesempio viene cercato in «dati accessibili per ruolo».
Nel tema «Guardrail per l’AI aziendale oltre il prompt», la precisione nasce dal contratto fra passaggi. Mappa ciascun rischio al livello tecnico che può realmente bloccarlo o renderlo osservabile.
La regola pratica è conservare abbastanza contesto da riprendere il caso senza ripeterlo alla cieca; la decisione resta collegata a «registrare fonti e decisioni». Questo contesto deve essere leggibile anche dall’operatore, non soltanto dal codice; qui la prova concreta è «Input policy, tool allowlist, output validation, rate limit e audit».
Anatomia tecnica: Input policy, tool allowlist, output validation, rate limit e audit
I controlli su «azioni che il sistema può eseguire» delimitano il comportamento prima dell’implementazione di combinare permessi, validazione, policy e supervisione. Ogni voce deve diventare un test o una vista capace di esporre «affidare tutto al prompt».
Azioni che il sistema può eseguire
Il comportamento va espresso come stato. Il contratto relativo a «azioni che il sistema può eseguire» specifica input, stato e comportamento davanti a «affidare tutto al prompt». Il controllo tecnico registra «dati accessibili per ruolo».
Dati accessibili per ruolo
Questo elemento permette diagnosi e recupero. Il contratto relativo a «dati accessibili per ruolo» specifica input, stato e comportamento davanti a «segreti nel contesto». Il controllo tecnico registra «formato e vincoli dell’output».
Formato e vincoli dell’output
Il test deve forzare anche il valore mancante. Il contratto relativo a «formato e vincoli dell’output» specifica input, stato e comportamento davanti a «strumenti con privilegi eccessivi». Il controllo tecnico registra «livello di danno e reversibilità».
Livello di danno e reversibilità
È parte del contratto tecnico. Il contratto relativo a «livello di danno e reversibilità» specifica input, stato e comportamento davanti a «log privi di tutela dei dati». Il controllo tecnico registra «azioni che il sistema può eseguire».
Il guasto da riprodurre
Caso isolato: «dati accessibili per ruolo». Operazione osservata: «validare input e output». Deviazione forzata: «strumenti con privilegi eccessivi».
Confine tecnico: «Input policy, tool allowlist, output validation, rate limit e audit». Stato, effetto e risposta vengono controllati separatamente. Perimetro della prova: «combinare permessi, validazione, policy e supervisione».
Controprova: «livello di danno e reversibilità». Arresto: «affidare tutto al prompt». Passo ammesso dopo il recupero: «registrare fonti e decisioni». Verbale finale: «Quali controlli servono attorno a un modello linguistico?»
Differenza decisiva: «Mappa ciascun rischio al livello tecnico che può realmente bloccarlo o renderlo osservabile». Regola di chiusura: «Il confine più forte è quello che il modello non può superare: accesso minimo, parametri validati e approvazione sulle azioni ad alto impatto».
Sequenza di implementazione
La sequenza riduce l’incertezza in ordine: prima identità e contratto, poi automazione, infine ottimizzazione; l’evidenza da conservare è «validare input e output». Saltare i primi passaggi rende più difficile diagnosticare qualunque metrica successiva; il caso operativo si verifica con «Input policy, tool allowlist, output validation, rate limit e audit».
- 1
Limitare strumenti e permessi
L’implementazione di «limitare strumenti e permessi» produce uno stato osservabile e una prova su «azioni che il sistema può eseguire». Si forza «affidare tutto al prompt»; soltanto dopo il recupero si passa a «validare input e output».
- 2
Validare input e output
L’implementazione di «validare input e output» produce uno stato osservabile e una prova su «dati accessibili per ruolo». Si forza «segreti nel contesto»; soltanto dopo il recupero si passa a «separare proposta ed esecuzione».
- 3
Separare proposta ed esecuzione
L’implementazione di «separare proposta ed esecuzione» produce uno stato osservabile e una prova su «formato e vincoli dell’output». Si forza «strumenti con privilegi eccessivi»; soltanto dopo il recupero si passa a «registrare fonti e decisioni».
- 4
Registrare fonti e decisioni
L’implementazione di «registrare fonti e decisioni» produce uno stato osservabile e una prova su «livello di danno e reversibilità». Si forza «log privi di tutela dei dati»; soltanto dopo il recupero si passa a «testare abusi e casi fuori perimetro».
- 5
Testare abusi e casi fuori perimetro
L’implementazione di «testare abusi e casi fuori perimetro» produce uno stato osservabile e una prova su «azioni che il sistema può eseguire». Si forza «affidare tutto al prompt»; soltanto dopo il recupero si passa a «limitare strumenti e permessi».
Failure mode da rendere visibili
I casi seguenti meritano un esito distinto. Riunirli sotto «errore generico» impedisce di scegliere fra retry, blocco, compensazione e revisione; il controllo associato riguarda «segreti nel contesto».
Affidare tutto al prompt
Rischio nominato: «affidare tutto al prompt». Perimetro operativo: «combinare permessi, validazione, policy e supervisione». Segnale osservato: «formato e vincoli dell’output». Recupero ammesso: «validare input e output». Checkpoint finale: «formato e vincoli dell’output».
Segreti nel contesto
Rischio nominato: «segreti nel contesto». Perimetro operativo: «combinare permessi, validazione, policy e supervisione». Segnale osservato: «livello di danno e reversibilità». Recupero ammesso: «separare proposta ed esecuzione». Checkpoint finale: «livello di danno e reversibilità».
Strumenti con privilegi eccessivi
Rischio nominato: «strumenti con privilegi eccessivi». Perimetro operativo: «combinare permessi, validazione, policy e supervisione». Segnale osservato: «azioni che il sistema può eseguire». Recupero ammesso: «registrare fonti e decisioni». Checkpoint finale: «azioni che il sistema può eseguire».
Log privi di tutela dei dati
Rischio nominato: «log privi di tutela dei dati». Perimetro operativo: «combinare permessi, validazione, policy e supervisione». Segnale osservato: «dati accessibili per ruolo». Recupero ammesso: «testare abusi e casi fuori perimetro». Checkpoint finale: «dati accessibili per ruolo».
Come testare senza una produzione perfetta
Si prepara una richiesta con identificatore noto, si forza il guasto nel punto più costoso e si verifica lo stato lasciato; nel perimetro descritto conta «Input policy, tool allowlist, output validation, rate limit e audit». Poi si ripete l’operazione per osservare duplicati, perdita di contesto e qualità del messaggio operativo; il controesempio viene cercato in «validare input e output».
Il test è superato solo se una persona non coinvolta nello sviluppo riesce a capire che cosa è successo e quale azione è sicura; la decisione resta collegata a «formato e vincoli dell’output». La sola risposta tecnica positiva non dimostra la recuperabilità.
Il confine di affidabilità
Il confine più forte è quello che il modello non può superare: accesso minimo, parametri validati e approvazione sulle azioni ad alto impatto. Per combinare permessi, validazione, policy e supervisione, affidabilità non significa assenza di errori: significa errore classificato, effetto circoscritto e percorso di rientro provato.
Il confine più forte è quello che il modello non può superare: accesso minimo, parametri validati e approvazione sulle azioni ad alto impatto. Il confine tecnico è pronto quando «limitare strumenti e permessi» sopravvive a «log privi di tutela dei dati» e lascia «formato e vincoli dell’output» disponibile per diagnosi e recupero.
Contesto e limiti
L’esempio è deliberatamente operativo e ipotetico: ragiona sul tema «combinare permessi, validazione, policy e supervisione», senza promettere un ritorno universale. La soluzione rimane leggibile a chi la gestirà ogni giorno.
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.