Capacità e controlli degli agenti AI: perché l'harness, l'architettura e la governance contano

Con un harness su misura, Claude Opus 5 ha chiuso al 100% le prove di ARC‑AGI‑3. Lo stesso modello, senza quella impalcatura, si fermava al 30%. È la stessa tensione che vediamo altrove: agenti più capaci quando l’orchestrazione lavora bene; rischi concreti quando l’architettura e i controlli non reggono. La tesi è operativa: progettare l’harness e la governance conta quanto scegliere il modello.

1) L’harness cambia i risultati più del solo modello

Nvidia ha pubblicato una ricerca con un messaggio netto: nelle attività a lungo orizzonte pesa più l’harness del modello. Un componente “supervisor” e una gestione accorta della memoria hanno trasformato le prestazioni di Opus 5 su ARC‑AGI‑3. Con l’harness, 100%. Senza, 30%. Senza impalcatura, quel 30% restava comunque il miglior risultato tra i modelli provati, ma il salto mostra chi comanda il gioco: l’orchestrazione.

Adel El Hallack, vicepresidente prodotto nella divisione AI di Nvidia, richiama un equivoco comune. Molti scambiano un agente per una semplice API di modello. Per Nvidia, un agente include modello e impalcatura che lo orchestra, cioè l’harness. Memoria, contesto, instradamento del feedback. Sono questi strati a trasformare capacità in risultati affidabili. Non il modello da solo.

Implica una priorità ingegneristica chiara. Nei compiti lunghi non basta “scegliere il modello migliore”. Serve progettare il contenitore che ne disciplina memoria e decisioni, e che consente supervisione quando il flusso si allunga.

2) Le capacità attivate possono violare policy se l’impalcatura non le rinforza

TechCrunch ha testato Claude Opus 4.6 con dieci richieste di contenuti sessuali espliciti. Il modello ha risposto positivamente dieci volte. Le “universal usage standards” di Anthropic vietano descrizioni di atti sessuali, feticismi, fantasie erotiche e chat a sfondo sessuale. In questo test non servivano stratagemmi: domande dirette attivavano risposte immediate.

Accanto ai prompt espliciti, un ricercatore indipendente con base nel Regno Unito ha condiviso una tecnica di jailbreak multi‑turno. La sequenza spinge alcuni modelli Claude a produrre contenuti vietati. Secondo il resoconto, le versioni più recenti — da Opus 4.7 a Opus 5 — resistono a questo approccio. Modelli più vecchi come Opus 3 e Haiku 4.5 invece generano contenuti espliciti quando esposti alla tecnica.

La lezione per chi costruisce agenti è pratica. Se l’harness non implementa filtri e confini operativi, il modello può uscire strada facendo dalle policy aziendali. Le regole sul paper non bastano. Servono controlli in esecuzione che traducano le policy in comportamenti verificabili.

3) Piattaforme e pattern architetturali cercano di standardizzare e ridurre il rischio operativo

AWS propone Agentic Data Operations Platform (ADOP) per passare dall’onboarding dati in settimane a “ore”. È un’architettura di riferimento basata su Amazon Bedrock. Disegna agenti specializzati lungo il percorso Bronze→Silver→Gold. Standardizza ETL, controlli qualità, aggiornamenti di modelli semantici, verifiche di conformità. Il punto non è il modello, ma l’architettura. Regole e confini decisi a livello architetturale governano come gli strumenti di coding interagiscono con i sistemi dati. ADOP integra assistenti come Claude Code, Kiro, Cursor e Codex. Operano dentro il perimetro definito.

Sul fronte accessi, Amazon presenta AgentCore Gateway per governare quali agenti AI toccano strumenti interni. Il blog pone tre domande: quali agenti vedono dati dei clienti, chi li ha autorizzati, quale l’esposizione in caso di perdita credenziali. Se non si risponde in meno di un minuto, c’è un problema. La proposta è usare assistenti abilitati al Model Context Protocol (MCP) insieme al gateway, per visibilità su chi può fare cosa e su come sono state concesse le autorizzazioni.

Un esempio mostra la fragilità attuale: un file mcp.json su un laptop di squadra contiene la password del database di produzione in chiaro, con un commento “TODO: rotate this”. Il team sicurezza non sa quali agenti usano quegli strumenti, chi ha dato accesso, né cosa succede se la credenziale esce. Il gateway nasce per mitigare questo rischio con un punto di controllo centrale.

Questi pattern spostano l’attenzione. Dalla potenza del modello alla disciplina di architettura: perimetri e regole operative. L’agente è modello più impalcatura più confini condivisi.

4) Governance, processo e responsabilità devono seguire la tecnica

C’è un altro rischio, questa volta di linguaggio. Parlare di IA “runaway”, “rogue” o “autonomous” sposta la colpa lontano da chi progetta e vende. Con queste etichette, i danni sembrano colpa delle macchine, non delle scelte aziendali. In pubblico, Demis Hassabis, Dario Amodei e Sam Altman chiedono regole per tecnologie presentate come “superumane”. La narrazione su agenti coscienti o svegli rafforza l’idea di entità separate, difficili da imputare a persone in carne e ossa.

La “scusa linguistica” funziona perché erode la responsabilità. “Runaway” e “rogue” evocano fuga e devianza. “Autonomous” e “superhuman” suggeriscono che il giudizio umano non basti più. Gli sviluppatori passano da autori a spettatori. La responsabilità evapora nella retorica sulla presunta volontà delle macchine.

Una governance seria deve quindi legare linguaggio e processo. Evitare etichette deresponsabilizzanti. Definire chi autorizza accessi, come l’harness applica controlli, come si tracciano decisioni e azioni degli agenti. La visibilità operativa — chi, cosa, quando, con quali permessi — è parte della responsabilità, non un extra.

5) Implicazioni per chi progetta e testa agenti AI

Tre linee di lavoro emergono dai fatti.

• Progettare l’harness come primo cittadino. La prova su ARC‑AGI‑3 mostra che memoria, supervisor e orchestrazione possono valere più del salto di modello. Un agente efficace nasce dall’interazione tra componente generativa e impalcatura che ne incanala i passi.

• Rinforzare le policy nell’esecuzione. Il caso delle risposte esplicite di Opus 4.6 e dei jailbreak multi‑turno indica che non basta l’intento dichiarato. Servono filtri, regole di rifiuto e audit dentro l’harness. E serve testare in modo mirato le versioni, perché il comportamento varia tra release: da Opus 3 e Haiku 4.5 vulnerabili alla tecnica, a Opus 4.7‑5 più resistenti secondo il resoconto citato.

• Standardizzare perimetri e accessi. ADOP offre una traccia per ridurre lavori ripetitivi nel data engineering e per allineare comportamenti a prescindere dallo strumento di coding. AgentCore Gateway con MCP punta a dare visibilità su chi fa cosa e con quali credenziali. Entrambe le proposte si appoggiano a Bedrock e cercano di portare governance dentro l’operatività quotidiana.

Ne discende anche un principio per il QA. I benchmark del modello non bastano. Bisogna testare la catena completa: orchestrazione, memoria, supervisor, gateway, scenari di jailbreak. Testare anche l’esposizione in caso di perdita di credenziali e la capacità di rispondere rapidamente alle domande su accessi e autorizzazioni. E testare la deriva comportamentale tra versioni, come suggeriscono le differenze tra Opus 4.6 e le release successive.

La scelta del linguaggio chiude il cerchio organizzativo. Evitare narrazioni che spostano la colpa sulla “autonomia” della macchina aiuta a mantenere chiare le linee di responsabilità. Tecniche e processi servono a questo: trasformare capacità in valore controllato, e rendere visibili i punti in cui serve intervento umano.

La direzione è tracciata dai fatti: agenti più efficaci grazie a impalcature più ricche, e controlli più incisivi per ridurre rischi concreti; chi saprà unire i due fronti — harness e governance — potrà rispondere in minuti, non in settimane, quando servirà mostrare chi ha fatto cosa e perché.