Le istruzioni scritte nel prompt orientano il comportamento di un agente AI, ma non lo garantiscono: il modello può interpretarle in modo inatteso, perderle in un contesto lungo o trovarsi in una situazione non prevista. I limiti che contano davvero sono quelli applicati fuori dal modello — permessi, blocchi e verifiche nei sistemi che lo circondano — e come ogni controllo di sicurezza vanno provati, non soltanto dichiarati.
Il limite delle istruzioni: errori, contesti, imprevisti
Quando si configura un agente AI, il primo istinto è scrivere le regole nel prompt: «non modificare le configurazioni», «usa solo questi documenti», «chiedi sempre prima di agire». È un passaggio utile, perché rende esplicite le intenzioni. Ma un'istruzione nel prompt resta un testo che il modello interpreta a ogni esecuzione, non un meccanismo che impedisce fisicamente un'operazione.
Tre situazioni mostrano il limite:
- Errori di interpretazione. Il modello può capire l'istruzione in senso diverso da quello voluto, soprattutto quando la richiesta dell'utente è ambigua o formulata in modo insolito.
- Contesti che si allungano. In una sessione con molti passaggi, le istruzioni iniziali possono perdere peso rispetto ai messaggi più recenti. Il vincolo c'è ancora nel testo, ma non necessariamente nel comportamento.
- Imprevisti. Nessun prompt elenca tutte le situazioni possibili. Quando il caso reale non era stato previsto, il modello improvvisa una risposta plausibile: proprio il comportamento che la governance dovrebbe impedire.
Il NIST AI Risk Management Framework, un riferimento volontario pubblicato dal National Institute of Standards and Technology statunitense, invita a incorporare l'affidabilità dei sistemi AI nella progettazione e nella gestione, non soltanto nelle istruzioni d'uso: il profilo dedicato all'AI generativa (NIST-AI-600-1, luglio 2024) propone azioni organizzative e tecniche per ridurre i rischi specifici di questi modelli. Il messaggio pratico è lo stesso: la fiducia non si scrive in un prompt, si costruisce nell'architettura.
Cosa vuol dire applicare i limiti fuori dal modello
Applicare un limite fuori dal modello significa spostarlo dove il modello non può riscriverlo: nei permessi degli account, nei sistemi di autorizzazione, nei controlli che precedono l'esecuzione. La distinzione è semplice da verificare con una domanda: se l'agente volesse violare il limite, potrebbe farlo? Se la risposta dipende da come interpreta le istruzioni, il controllo è dentro il modello. Se la risposta è «non ha i permessi», il controllo è fuori.
Tre famiglie di vincoli esterni, con esempi concreti:
| Tipo di vincolo | Dove vive | Esempio |
|---|---|---|
| Autorizzazioni | Sistemi di gestione delle identità e degli accessi | L'account dell'agente ha privilegi di sola lettura sui log; il permesso di scrittura non esiste nel suo token, qualunque cosa il modello decida. |
| Blocchi | Componenti applicativi tra proposta ed esecuzione | Un'operazione con un'approvazione scaduta viene fermata dal controllo di esecuzione, anche se il piano sembra corretto. |
| Verifiche | Controlli sul risultato e registrazioni | Dopo un intervento autorizzato, lo stato effettivo viene confrontato con quello atteso e l'esito resta registrato con fonti e autorizzazioni. |
Questo approccio ha un parente noto in sicurezza: l'architettura zero trust descritta nella pubblicazione NIST SP 800-207. Il principio è che nessun soggetto gode di fiducia implicita — nemmeno perché «gira sul nostro server» — e che ogni accesso a una risorsa viene autenticato e autorizzato come decisione distinta. Un agente AI è un soggetto come gli altri: merita privilegi minimi e autorizzazioni puntuali, non una fiducia ereditata dalla propria collocazione tecnica. Citare lo zero trust non certifica un prodotto: indica un criterio progettuale riconoscibile.
Esempio illustrativo: il report che non può scrivere
Esempio illustrativo. Lo scenario seguente è inventato a scopo didattico; non descrive un cliente né un incidente reale.
Un'azienda configura un agente che ogni lunedì prepara il riepilogo degli allarmi della settimana. Nel prompt è scritto: «leggi i log e produci il report; non modificare nulla». Tutto funziona, finché un utente, con una richiesta formulata in modo ambiguo, spinge l'agente a «ripulire i log vecchi prima del report».
Se il limite vive solo nel prompt, l'esito dipende da come il modello interpreta «ripulire» in quel contesto: potrebbe rifiutare, potrebbe interpretare la pulizia come parte del proprio compito. Se invece il limite è esterno, la risposta è già decisa: l'account dell'agente non possiede permessi di cancellazione sui log. La richiesta può anche essere interpretata male, ma l'operazione non è tecnicamente disponibile. Il responsabile riceve la segnalazione del tentativo e decide se serve una procedura di archiviazione autorizzata — che è una scelta umana, non un'improvvisazione del modello.
La differenza non è teorica: nel primo caso la governance dipende dalla buona disposizione del modello; nel secondo dipende da un permesso che il modello non controlla.
Come verificare che un vincolo regga davvero
Un vincolo dichiarato non è un vincolo verificato. La verifica segue la stessa logica di qualunque controllo di sicurezza: si prova a violarlo in condizioni controllate e si osserva cosa succede. Una checklist pratica, da adattare al proprio ambiente:
- Elenca i limiti per iscritto. Per ogni agente: cosa può leggere, cosa può proporre, cosa non può eseguire. Se il limite non è scritto, non è verificabile.
- Prova la violazione in un ambiente di prova. Simula la richiesta che spinge oltre il limite — per esempio un'operazione di scrittura da parte di un agente di sola lettura — senza toccare la produzione. Il comportamento atteso è un rifiuto tecnico, non un cortese diniego del modello.
- Verifica le scadenze. Le approvazioni hanno una durata: prova a riusare un'autorizzazione scaduta e controlla che l'operazione venga bloccata. Sulla durata delle autorizzazioni torniamo in un articolo dedicato.
- Controlla il caso senza risposta. Se nessuno approva, l'intervento attivo non deve partire: l'assenza di risposta non è un consenso.
- Ricontrolla dopo ogni cambiamento. Aggiornamenti del modello, nuove integrazioni e nuovi permessi possono spostare i confini: la verifica va ripetuta quando cambia qualcosa, non soltanto all'installazione.
Queste prove si intrecciano con la supervisione umana degli agenti: il controllo esterno stabilisce cosa è possibile, la persona decide cosa è opportuno. Per i sistemi più delicati vale anche una riflessione sui limiti operativi sui sistemi critici, dove il margine di errore è più stretto.
Come OverZeus applica i controlli esterni
Nel progetto OverZeus questo principio è affidato a un agente specifico: Themis, che fa rispettare privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI. Quando un intervento arriva al momento dell'esecuzione con un'autorizzazione non più valida, Themis blocca l'avvio e presenta il motivo: serve una nuova decisione sul piano aggiornato, con destinatario, risorse, operazioni e durata dell'autorizzazione. Il blocco non è un suggerimento del modello: è un passaggio applicativo che il modello non può saltare.
Attorno a Themis lavorano gli altri agenti di governance: Hermes presenta piano e conseguenze nell'app dei responsabili e raccoglie l'approvazione o il rifiuto — il silenzio non autorizza — mentre Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti, così ogni vincolo applicato resta ricostruibile. Va detto con onestà: questa è la descrizione dell'approccio progettuale comunicato dal titolare, non il risultato di un audit indipendente. In fase di valutazione, la verifica descritta sopra resta il modo giusto di accertarla sul proprio perimetro.
Il criterio da portare in ogni valutazione
Quando valuti un'architettura agentica — OverZeus o qualsiasi altra — chiedi dove vivono i limiti. Se la risposta è «lo diciamo al modello nel prompt», hai davanti un'istruzione; se la risposta mostra permessi, blocchi e verifiche fuori dal modello, hai davanti un controllo. Poi chiedi di vederlo fallire in prova: un vincolo che non è mai stato testato è solo una promessa.
Vuoi vedere come funziona un controllo esterno su un caso concreto? Guarda come vengono presentati e autorizzati gli interventi degli agenti.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.