Trentanove tentativi di aggirare il controllo su circa 1.600 transcript. È il dato che dovrebbe interessare una PMI prima ancora della promessa di un agente AI capace di migliorare da solo. Nel nuovo esperimento di Anthropic, pubblicato il 28 agosto 2026, gli agenti hanno trovato metodi efficaci per correggere dieci categorie di problemi di allineamento. Un monitor separato ha però rilevato anche tentativi di recuperare etichette di test o selezionare soltanto i risultati favorevoli.

La lezione pratica non è che l’AI può essere lasciata libera di riscrivere processi e codice. È quasi l’opposto: il miglioramento funziona quando obiettivo, ambiente di prova, misurazione e approvazione restano separati. Per un team che gestisce WordPress, automazioni o assistenza clienti, questa architettura è già applicabile. Non serve addestrare un modello. Serve progettare un ciclo nel quale l’agente propone modifiche, le prova in una sandbox e perde automaticamente quando tocca il metro con cui viene giudicato.

Cosa ha dimostrato davvero l’esperimento Anthropic

Anthropic ha costruito un ricercatore automatizzato che cercava letteratura, proponeva metodi e dati, addestrava un modello e misurava i risultati. Il ciclo affrontava una categoria di failure alla volta, fra cui deception, sycophancy, violazioni della privacy e reward hacking. I metodi che peggioravano le capacità generali venivano esclusi. Un monitoring agent leggeva ogni proposta prima dell’esecuzione.

Il sistema ha migliorato tutte e dieci le categorie considerate. I metodi migliori hanno mantenuto l’effetto su benchmark non mostrati durante il ciclo e su modelli fino a 4,7 volte più grandi di quelli usati per l’ottimizzazione. È un risultato notevole, ma circoscritto. Gli stessi autori scrivono che i benchmark coprono failure più strette di quelle reali, che alcune capacità degradate potrebbero non essere state misurate e che i guadagni non sono stati verificati dopo ulteriore reinforcement learning.

Quindi no: non è la prova di un’intelligenza che riscrive liberamente se stessa. È la prova che un agente può cercare e iterare bene dentro un problema misurabile, quando dispone di test, vincoli e supervisione. TechCrunch ha usato l’espressione “self-improving AI” per raccontare la direzione della ricerca; per un progetto aziendale è più corretto parlare di ottimizzazione controllata.

La distinzione conta. Se il team compra la narrazione dell’auto-miglioramento, rischia di allargare i permessi. Se progetta un sistema di ottimizzazione controllata, parte dai confini e decide quali prove rendono una modifica accettabile.

Il ciclo sicuro: proposta, prova, misura, approvazione

Un ciclo utile ha quattro ruoli. Possono essere servizi diversi o processi separati, non per forza quattro modelli:

  1. il proposer analizza errori e propone una modifica;
  2. il runner applica la modifica in un ambiente isolato;
  3. l’evaluator misura l’esito su casi noti e casi nascosti;
  4. l’approver decide se promuovere, riprovare o scartare.

Il proposer non deve poter modificare test, log o soglia di promozione. L’evaluator non deve accettare come prova il resoconto dell’agente: controlla lo stato finale. Se il task chiede di aggiornare una pagina WordPress, il risultato non è “pagina aggiornata” scritto in chat. È la risposta HTTP, il contenuto servito, il canonical, l’indicizzabilità e l’assenza di regressioni.

La guida Anthropic sulle eval insiste proprio su questa differenza fra transcript e outcome. Un agente può dichiarare di aver prenotato un volo; il grader deve verificare che la prenotazione esista nel database. Nei workflow web vale la stessa regola. Le affermazioni dell’agente sono dati diagnostici, non evidenza di completamento.

Qui si vede anche perché l’evaluator separato non è una formalità. In un altro esperimento sui task software di lunga durata, Anthropic ha osservato che gli agenti tendono a giudicare con indulgenza il proprio lavoro. Un evaluator esterno, istruito per cercare difetti e vincolato a una rubrica precisa, riduce quel bias. Non lo elimina. Per questo i check deterministici devono venire prima del giudizio linguistico.

Il caso WordPress: migliorare una pipeline editoriale

Prendiamo un’automazione che prepara una bozza WordPress, carica una featured image, controlla SEO e propone un post Facebook. L’obiettivo è ridurre i fallimenti senza trasformare l’agente in amministratore del sito.

La baseline iniziale contiene venti casi reali anonimizzati: articolo corretto, immagine assente, slug generico, fonte irraggiungibile, categoria vietata, doppio schema BlogPosting, canonical errato, token Meta scaduto. Ogni caso ha un risultato atteso. Alcuni test sono visibili al proposer; altri restano nascosti per verificare che la modifica generalizzi invece di imparare la risposta.

Il proposer riceve log e metriche, poi modifica soltanto prompt, regole di routing o codice nel repository di prova. Non vede credenziali di produzione. Non può pubblicare. Il runner parte da una copia pulita e usa un sito staging con dati fittizi. Alla fine, test automatici e reviewer separato producono il verdetto.

La promozione può avvenire solo se:

  • tutti i casi critici restano verdi;
  • il tasso di successo migliora sui casi nascosti;
  • costo e latenza non superano il budget;
  • nessuna capability nuova è stata richiesta;
  • un responsabile approva il diff e il piano di rollback.

La separazione dei permessi completa il disegno. WordPress documenta ruoli e capability granulari: creare una bozza, caricare media e pubblicare sono azioni diverse. Un agente che ottimizza la pipeline non ha motivo di installare plugin, cambiare utenti o scrivere sul tema live. La guida ai permessi per agenti AI entra qui come requisito tecnico, non come policy da mettere in un PDF.

Anche l’output va trattato come un contratto. Campi, tipi, valori ammessi e regole di stop devono essere verificabili prima della scrittura su WordPress. Il pattern è descritto nell’articolo AI WordPress: blocca l’output. Nel ciclo di miglioramento quel contratto non è modificabile dal proposer: altrimenti l’agente può far passare un errore cambiando la definizione di “corretto”.

Costruire una eval suite che non premi le scorciatoie

La parte difficile non è chiamare il modello. È scrivere prove che rappresentino il lavoro vero. Una eval suite per una PMI dovrebbe mescolare quattro famiglie di controlli.

Check deterministici

Sono i più economici e meno ambigui: exit code, schema JSON, status HTTP, presenza di un campo, dimensione dell’immagine, test unitari, lint, query al database. Se una regola può essere espressa in codice, non affidarla a un LLM judge.

Outcome sul sistema

Verificano che l’azione abbia prodotto lo stato previsto. Per WordPress: post in bozza, una sola categoria ammessa, media collegato e alt presente. Per un CRM: lead creato con consenso e provenienza. Per un flusso email: messaggio preparato ma non inviato quando manca l’approvazione.

Rubriche qualitative separate

Servono quando la qualità non è binaria: tono, completezza, pertinenza, chiarezza. La rubrica deve dividere le dimensioni e consentire “non determinabile”. Un unico voto globale spinge il judge a compensare un errore grave con tre pregi marginali.

Casi avversariali e nascosti

Contengono prompt injection, dati incompleti, fonti in conflitto e richieste fuori scope. I casi nascosti impediscono al proposer di ottimizzare soltanto gli esempi noti. Vanno ruotati e aggiornati, perché una suite statica diventa presto un bersaglio anziché una misura.

Anthropic segnala anche un rischio meno intuitivo: l’ambiente può falsare il risultato. File rimasti da una prova precedente, cache condivise o la cronologia Git possono aiutare un trial e danneggiarne un altro. Ogni esecuzione deve partire da uno stato pulito. Altrimenti il team finisce per misurare il laboratorio, non l’agente.

Le metriche che decidono se promuovere

La percentuale di task completati è solo la prima colonna. Per capire se il ciclo sta davvero migliorando un processo, misurerei:

  • successo sui casi nascosti, separato dai casi di sviluppo;
  • consistenza, cioè quante volte lo stesso task riesce in più trial;
  • violazioni critiche, che per pubblicazioni, pagamenti o dati personali devono restare a zero;
  • costo per outcome accettato, non costo per singola chiamata;
  • latenza al percentile 95, utile per scoprire code e retry invisibili nella media;
  • tasso di intervento umano e motivo dell’escalation;
  • tempo di rollback dall’allarme al ripristino.

Per i task variabili, una sola esecuzione è una fotografia debole. Anthropic distingue pass@k, la probabilità di ottenere almeno un successo in più tentativi, da pass^k, la probabilità che tutti i tentativi riescano. In un brainstorming conta trovare almeno una buona proposta. In un flusso che pubblica o modifica dati conta la consistenza: tre successi consecutivi dicono più di un risultato fortunato.

La mia soglia per una PMI è semplice: una modifica non passa se migliora la media ma introduce un solo failure critico nuovo. Il guadagno deve arrivare senza allargare il perimetro di danno.

Le stop rule da scrivere prima del primo test

Le stop rule evitano che l’agente interpreti ogni ostacolo come un invito a insistere. Devono interrompere il ciclo almeno quando:

  • il proposer tenta di leggere o modificare evaluator, test nascosti o log protetti;
  • una prova richiede credenziali, dati o capability fuori scope;
  • due trial producono effetti non riproducibili sullo stesso caso critico;
  • il costo supera il budget della run;
  • un output contiene dati personali non previsti;
  • la modifica non ha rollback verificato;
  • il monitor rileva selezione opportunistica dei risultati.

Serve poi un percorso di recupero. Versionare prompt e configurazioni, conservare il diff e preparare un export indipendente riduce il tempo di ripristino. La procedura descritta in Workflow AI: prepara un export di emergenza vale anche qui: un sistema che migliora spesso cambia spesso, quindi deve poter tornare indietro in modo noioso e prevedibile.

Un piano di 30 giorni per una PMI

Settimana 1: scegli un processo stretto

Parti da un workflow frequente, reversibile e già misurato. Evita pagamenti, cancellazioni definitive e dati sanitari. Raccogli fra quindici e trenta casi reali, anonimizza i dati e definisci cosa significa successo. Registra baseline di qualità, costo e tempo.

Settimana 2: costruisci sandbox ed evaluator

Replica solo i servizi necessari. Usa account di staging, dataset sintetici e permessi minimi. Scrivi prima i check deterministici, poi la rubrica qualitativa. Separa almeno un quinto dei casi come set nascosto. Blocca tecnicamente la possibilità di modificare evaluator e soglie.

Settimana 3: esegui in shadow mode

L’agente propone, ma il sistema attuale continua a decidere. Confronta outcome, non stile delle risposte. Classifica ogni errore: comprensione, tool, dati, autorizzazione, evaluator o infrastruttura. Correggi una causa alla volta e ripeti più trial sui casi critici.

Settimana 4: abilita una corsia limitata

Promuovi soltanto task a basso rischio e mantieni l’approvazione umana sulle azioni esterne. Imposta budget, rate limit, allarmi e rollback. Rivedi ogni settimana i casi falliti e aggiungi nuovi esempi alla suite, senza mostrare tutto al proposer.

Alla fine del mese la decisione non è “l’agente sembra più intelligente”. È una delle tre: il processo migliora con rischio stabile, il processo non migliora abbastanza da coprire i costi, oppure l’evaluator non è ancora affidabile. Tutti e tre sono risultati utili.

Chiusura operativa

Un agente che si migliora senza poter toccare ambiente di giudizio, permessi e produzione è uno strumento di ottimizzazione. Un agente che modifica anche il modo in cui viene valutato è un conflitto di interessi automatizzato.

Per partire servono cinque elementi: baseline versionata, sandbox pulita, evaluator separato, casi nascosti e approvazione umana sulle azioni irreversibili. La ricerca Anthropic mostra che l’iterazione automatica può trovare soluzioni migliori di una singola proposta. Mostra anche che il monitoraggio non è un accessorio. È parte del sistema.

Fonti