TL;DR: per un agente AI, prevenzione e contenimento risolvono problemi diversi. I gate preventivi riducono la probabilità di un’azione sbagliata; il contenimento limita il danno quando il gate non basta. Se devo scegliere dove investire per primo in una PMI, parto dalla prevenzione. Ma non autorizzo scritture su WordPress, CRM o infrastruttura senza un interruttore operativo già provato.

I framework dei laboratori frontier parlano molto di valutazioni, soglie di capacità e mitigazioni prima del deployment. È logico: il modo più economico per gestire un incidente è non farlo partire. Il problema emerge quando un modello ha tool, credenziali e tempo per agire. A quel punto non basta sapere che ha superato i test.

Un’valutazione pubblicata da Guidelight il 18 agosto 2026 ha confrontato cinque sviluppatori su logging, monitoraggio, azioni soggette a gate, circuit breaker, revisione esterna e piano di contenimento. Nessuna pratica ha superato 3 su 5, cioè “implementazione parziale sostanziale”. È una valutazione delle informazioni pubbliche, non la prova che dentro le aziende non esistano controlli migliori. Il segnale utile è un altro: i piani preventivi sono più visibili dei playbook da usare quando il controllo viene già contestato.

Il criterio: probabilità dell’errore contro ampiezza del danno

Confrontare prevenzione e contenimento come se fossero due prodotti equivalenti porta fuori strada. Il criterio corretto ha due assi. La prevenzione abbassa la probabilità che l’agente esegua un’azione pericolosa. Il contenimento riduce durata e impatto dell’incidente dopo il primo segnale anomalo.

Per una PMI questo si traduce in domande concrete. L’agente può pubblicare un articolo o soltanto preparare una bozza? Può chiamare qualsiasi dominio o una allowlist? Se crea utenti amministratori, invia email o modifica un database, chi può revocare il token e bloccare il workflow? Quanto tempo passa tra l’evento, l’allarme e lo stop?

Approccio A: prevenire prima dell’esecuzione

La prevenzione mette limiti prima che il modello tocchi il sistema reale: eval su casi avversi, sandbox, permessi minimi, approvazione umana per le azioni irreversibili e separazione tra lettura e scrittura. Google DeepMind descrive safety case prima dei lanci esterni e, per capacità avanzate di ricerca AI, anche prima di grandi deployment interni. Anthropic usa una Responsible Scaling Policy che collega livelli di rischio e salvaguardie richieste. OpenAI ha documentato il 18 agosto 2026 sandbox più forti, isolamento di rete e riduzione dei privilegi permanenti per workload che eseguono codice o usano tool.

I vantaggi sono chiari. Un permesso che non esiste non può essere abusato. Una pubblicazione che richiede approvazione resta bozza anche se il modello interpreta male una fonte. Una rete con uscita limitata impedisce a un plugin compromesso di parlare con servizi arbitrari.

Il contro è l’attrito. Ogni gate rallenta il flusso, richiede manutenzione e produce falsi positivi. Se i controlli sono troppo rigidi, il team li aggira. Se sono troppo generici, diventano una checklist che certifica il processo senza proteggere l’azione reale. La prevenzione fallisce anche in modo silenzioso: un tool autorizzato può fare la cosa sbagliata con credenziali perfettamente valide.

Approccio B: contenere quando il sistema devia

Il contenimento parte da un’assunzione meno comoda: qualche errore passerà. Servono quindi log completi, rilevazione durante l’esecuzione, soglie di stop, revoca rapida dei permessi, isolamento della rete e una procedura per portare offline il workload. Il Control standard di Guidelight tratta il circuito di arresto e il piano di contenimento come pratiche distinte dai gate preventivi.

Qui il vantaggio è la resilienza. Il sistema non dipende dalla previsione di ogni comportamento possibile. Può bloccare una sequenza anomala, conservare le evidenze e ripartire con credenziali ruotate. OpenAI riferisce di aver sospeso workload con esecuzione di codice o accesso a Internet dopo un incidente e di avere ripristinato solo percorsi più limitati. È un esempio concreto di risposta, non la dimostrazione che il problema del contenimento sia risolto.

Il costo è tecnico e organizzativo. I log devono essere leggibili in tempo utile. Lo stop deve funzionare senza dipendere dallo stesso agente che si vuole fermare. Va deciso prima chi ha autorità per bloccare il servizio. Inoltre un kill switch da solo arriva tardi se l’agente ha già pubblicato dati, inviato email o cancellato record.

WordPress e automazioni: il test che conta

Su WordPress la prevenzione significa account dedicato, Application Password separata, ruolo minimo, draft-first e allowlist degli endpoint REST. Per n8n o Make significa separare i nodi read-only da quelli di scrittura, limitare i domini raggiungibili e mettere approvazioni davanti a email, pagamenti, pubblicazioni e modifiche utenti.

Il contenimento richiede altro: un comando esterno che disattivi il workflow, token revocabili senza ricostruire tutto lo stack, backup verificato e log che colleghi prompt, tool call e risultato. Ho già affrontato il punto più ampio nell’articolo sulla sicurezza dell’intera catena AI: proteggere solo il modello lascia scoperti connettori, secret e destinazioni.

Il test utile è semplice. In staging, fai tentare all’agente un’azione vietata e verifica che venga bloccata. Poi simula una sequenza autorizzata ma anomala, per esempio cinque modifiche consecutive a utenti o pagine, e misura se l’allarme interrompe davvero il flusso. Se il team sa solo spegnere il server, non ha un piano di contenimento: ha un’ultima risorsa.

La mia take: prevenzione prima, contenimento prima della scrittura

Per workflow assistivi e read-only sceglierei la prevenzione: meno privilegi, output strutturati e revisione umana danno il miglior rapporto tra costo e rischio. Quando l’agente ottiene capacità di scrittura, il contenimento smette di essere una fase successiva. Deve esistere prima del primo run reale.

La scelta netta è questa: non affiderei un processo operativo a un agente che supera molti benchmark ma non può essere isolato in pochi minuti. Un modello meno brillante, chiuso in un perimetro osservabile e reversibile, è più utile a una PMI di un modello frontier con accesso largo e nessun playbook d’emergenza.

Fonti