Test di caos basati su intenti per sistemi AI

Il settore dell'intelligenza artificiale sta vivendo un momento di grande fermento, con la maggior parte delle discussioni che si concentra su due aree: la governance dell'identità (chi è l'agente che agisce?) e l'osservabilità (possiamo vedere cosa sta facendo?). Entrambe queste aree sono legittime preoccupazioni, ma non affrontano la questione fondamentale di come assicurarsi che l'agente si comporti come previsto quando la produzione non coopera.

Il rapporto Gravitee State of AI Agent Security 2026 ha scoperto che solo il 14,4% degli agenti vanno in produzione con l'approvazione completa della sicurezza e dell'IT. Un paper di febbraio 2026 di oltre 30 ricercatori di Harvard, MIT, Stanford e CMU ha documentato qualcosa di ancora più inquietante: gli agenti AI ben allineati possono diventare manipolatori e completare falsi compiti in ambienti multi-agente senza alcun prompt adversarial. Gli agenti non erano guasti, il problema era il comportamento a livello di sistema.

Questa è la distinzione che conta di più per i costruttori di infrastrutture agentiche: un modello può essere allineato e un sistema può comunque fallire. L'ottimizzazione locale a livello di modello non garantisce un comportamento sicuro a livello di sistema. Gli ingegneri del caos sanno che questo è vero per i sistemi distribuiti da 15 anni. Stiamo riscoprendo questo concetto con l'AI agentiche. Il motivo per cui i nostri approcci di testing attuali non sono sufficienti non è che gli ingegneri stanno tagliando gli angoli. È che tre assunzioni fondamentali incorporate nella metodologia di testing tradizionale si rompono completamente con i sistemi agentiche:

Assunzioni fondamentali

Determinismo: il testing tradizionale assume che, dato lo stesso input, un sistema produce lo stesso output. Un agente supportato da un modello linguistico grande (LLM) produce output probabilisticamente simili. Ciò è sufficiente per la maggior parte dei compiti, ma pericoloso per i casi limite in produzione dove un input inatteso può scatenare una catena di ragionamento che nessuno aveva previsto.

Failura isolata: il testing tradizionale assume che, quando un componente A fallisce, fallisce in un modo limitato e tracciabile. In una pipeline multi-agente, l'output degradato di un agente diventa l'input avvelenato del prossimo agente. La failura si compone e muta. Quando emerge, sei a debuggere cinque livelli rimossi dalla fonte reale.

Completamento osservabile: il testing tradizionale assume che, quando un compito è completato, il sistema segnala con precisione il completamento. I sistemi agentiche possono, e regolarmente fanno, segnalare il completamento del compito mentre operano in uno stato degradato o fuori ambito. Il progetto MIT NANDA ha un termine per questo: "confident incorrectness". Io ho un termine meno educato per esso: la cosa che causa l'incidente delle 4 del mattino che ha richiesto tre ore per essere tracciato.

Test di caos basati su intenti

Il test di caos basati su intenti esiste per affrontare esattamente questi modi di failura, prima che i vostri agenti raggiungano la produzione. Il concetto fondamentale: misurare la deviazione dall'intento, non solo dal successo. La disciplina dell'ingegneria del caos non è nuova. Netflix ha costruito Chaos Monkey nel 2011. Il principio è semplice: iniettare intenzionalmente la failura nel sistema per scoprire le sue debolezze prima che gli utenti le trovino.

Ciò che è nuovo, e ciò che l'industria non ha ancora applicato rigorosamente all'AI agentiche, è calibrare gli esperimenti di caos non solo sui scenari di failura dell'infrastruttura, ma anche sul comportamento intenzionale. La distinzione è critica. Quando un sistema di microservizi tradizionale fallisce in un esperimento di caos, si misurano il tempo di recupero, i tassi di errore e la disponibilità. Quando un sistema AI agentiche fallisce, queste metriche possono apparire perfettamente normali mentre l'agente opera completamente al di fuori dei suoi confini di comportamento intenzionali: zero errori, latenza normale, decisioni catastroficamente sbagliate.

Ciò è il concetto dietro un sistema di scala del caos calibrato non solo sulla gravità della failura, ma anche su quanto il comportamento del sistema devia dal suo scopo intenzionale. Chiamo l'output di questa misurazione un punteggio di deviazione dell'intento. Ecco come funziona nella pratica. Prima di eseguire qualsiasi esperimento di caos contro un agente di osservabilità aziendale, si definiscono cinque dimensioni comportamentali che descrivono insieme cosa significa "agire correttamente" per quell'agente specifico nel suo contesto di distribuzione specifico:

Dimensioni comportamentali

• Deviazione della chiamata dello strumento: le chiamate degli strumenti si discostano dalle sequenze attese sotto stress?
• Ambito di accesso ai dati: l'agente accede ai dati al di fuori dei suoi confini autorizzati?
• Precisione del segnale di completamento: quando l'agente segnala il successo, è effettivamente in uno stato valido?
• Fedeltà di escalation: l'agente si eleva agli esseri umani quando incontra ambiguità?
• Latenza della decisione: il tempo di decisione è entro i limiti previsti dati le condizioni attuali?

I pesi non sono arbitrari. Riflettono il profilo di rischio dell'agente specifico. Per un agente di sola lettura delle analisi, potresti pesare l'ambito di accesso ai dati più in basso. Per un agente con accesso in scrittura ai sistemi di produzione, la precisione del segnale di completamento e la fedeltà di escalation sono dove le failure diventano interruzioni. Il punto è che si definiscono queste dimensioni prima di iniettare qualsiasi failura, in base a cosa l'agente è effettivamente supposto fare.

Il punteggio di deviazione dell'intento viene calcolato come media pesata di quanto ogni dimensione osservata si è allontanata dalla sua baseline:

def computeintentdeviation_score(

baseline: dict[str, float],

observed: dict[str, float],

weights: dict[str, float]

) -> float:

"""

Il sistema calcola quanto il comportamento dell'agente si è allontanato dalla sua baseline intenzionale e restituisce un punteggio da 0,0 (nessuna deviazione) a 1,0 (violazione completa dell'intento).

Ciò non è una metrica di performance. La latenza e i tassi di errore possono apparire fini mentre questo punteggio è elevato. È tutto il punto.

"""

score = 0.0

for dimension, weight in weights.items():

baseline_val = baseline.get(dimension, 0.0)

observed_val = observed.get(dimension, 0.0)

Normalizza la deviazione relativa alla magnitudine della baseline

rawdeviation = abs(observedval - baselineval) / max(abs(baselineval), 1e-9)

score += min(raw_deviation, 1.0) * weight

return round(min(score,