Anthropic batte OpenAI in 5 test [2026]

Il 26 ottobre 2026 la sicurezza dell’intelligenza artificiale cambia registro, almeno nel modo in cui la raccontano i grandi laboratori. Nel suo documento sulla resilienza informatica, OpenAI descrive un approccio fatto di difese su più livelli, controlli di accesso, rafforzamento dell’infrastruttura, controlli del traffico in uscita, monitoraggio, rilevamento e risposta, intelligence sulle minacce e gestione del rischio interno. Non parla più soltanto del modello, ma dell’intera catena che lo circonda.

Il portale ai4business.it ha sintetizzato la tendenza con il titolo “OpenAI e Anthropic, la sicurezza AI diventa end-to-end”. La formula funziona come titolo, ma va letta con attenzione. Le fonti che abbiamo verificato oggi non confermano un accordo congiunto tra le due aziende, né un’iniziativa ufficiale chiamata sicurezza AI end-to-end. Confermano invece che ciascun laboratorio sta spostando la protezione dal singolo prompt all’intero sistema.

Per chi lavora in Italia e in Europa la distinzione conta. Il quadro normativo nazionale, riassunto nel nostro articolo sull’AI Act in Italia e sul D.Lgs. 179, chiede alle imprese di dimostrare controlli concreti, non slogan di marketing. Questa analisi separa quindi ciò che è documentato da ciò che resta ipotesi, e spiega che cosa cambia per chi compra, integra o governa sistemi AI.

Che cosa significa sicurezza AI end-to-end

Nel linguaggio della cifratura, end-to-end indica che i dati restano protetti dal mittente al destinatario senza punti intermedi in chiaro. Applicata all’intelligenza artificiale, l’espressione ha un significato più largo e meno rigoroso. Descrive una protezione che accompagna il ciclo completo: dall’ambiente in cui si addestra e si valuta un modello fino alla risposta consegnata all’utente, passando per l’infrastruttura, la rete, gli endpoint e le applicazioni.

Questa lettura spiega perché la notizia ha avuto tanta eco. Per anni il dibattito sulla sicurezza dei modelli linguistici si è concentrato sui filtri dei contenuti, sui rifiuti e sulle risposte pericolose. Oggi i laboratori parlano di perimetro, di movimento laterale, di traffico in uscita e di rischio interno. Sono categorie prese dalla sicurezza informatica classica e applicate a sistemi che agiscono, non solo a sistemi che rispondono.

Il termine, però, non ha una definizione tecnica condivisa. Chi lo usa in un contratto o in un bando dovrebbe chiedere al fornitore quali segmenti della catena copre davvero. Un’azienda può cifrare i dati a riposo e in transito, eppure lasciare scoperto il momento in cui un agente esegue un’azione su un sistema esterno. Nelle sezioni seguenti separiamo i livelli uno per uno.

I fatti confermati: cosa dichiara OpenAI

Il materiale più solido riguarda OpenAI, che pubblica le proprie misure in modo diretto. L’azienda afferma di applicare difese su più livelli, controlli di accesso, rafforzamento dell’infrastruttura, controlli sul traffico in uscita, monitoraggio, rilevamento e risposta, intelligence sulle minacce e gestione del rischio interno. L’elenco somiglia a quello di un programma di sicurezza aziendale maturo, e questo è il punto.

Un secondo elemento riguarda i test. OpenAI descrive esplicitamente un “End-to-end red teaming”, cioè la verifica condotta da organizzazioni esterne di red team che provano a superare le difese dell’azienda lungo l’intero sistema. Il dettaglio è importante perché sposta il controllo fuori dall’azienda. Un test interno misura ciò che il team sa già difendere, mentre un attaccante esterno misura ciò che nessuno ha previsto.

Sul fronte dei dati aziendali, la pagina OpenAI dedicata a privacy, sicurezza e conformità indica la cifratura AES-256 a riposo e TLS 1.2 o successivo in transito. L’azienda dichiara inoltre di adottare principi di zero trust e difesa in profondità su endpoint, infrastruttura, reti e applicazioni. Sono standard di settore ormai diffusi, ma sono anche gli standard che un responsabile della sicurezza si aspetta di vedere scritti.

Cosa non è confermato: nessun programma congiunto

Il titolo che circola in rete suggerisce che OpenAI e Anthropic abbiano reso insieme la sicurezza AI end-to-end. Nelle fonti verificate non troviamo né un accordo, né un annuncio congiunto, né un’iniziativa con quel nome. Troviamo due aziende che comunicano misure analoghe in tempi vicini, il che è diverso da una collaborazione formale.

La differenza ha conseguenze pratiche. Se esistesse uno standard comune, un cliente potrebbe confrontare i due fornitori con la stessa griglia e pretendere le stesse prove. In assenza di uno standard, ogni laboratorio sceglie cosa pubblicare, con quale livello di dettaglio e con quale metrica. Il confronto resta possibile, ma richiede lavoro da parte di chi acquista.

Restano non confermati anche i dettagli sui prodotti di Anthropic, sui suoi modelli, sui prezzi e sulle specifiche numeriche legate a queste misure. Per questo, in questo articolo, non attribuiamo ad Anthropic cifre o citazioni che le fonti non riportano. Lo stesso criterio vale per le persone: nessun dirigente viene citato, perché non abbiamo dichiarazioni verificabili su questo tema.

Anthropic e le valutazioni portate offline

Per Anthropic il dato disponibile è più limitato ma significativo. Secondo Wholestory, l’azienda ha spostato le proprie valutazioni interne fuori dal web aperto dopo incidenti legati alla sicurezza. Le fonti non dicono che questa scelta faccia parte di un piano condiviso con OpenAI, e noi non lo suggeriamo.

Il senso della mossa è chiaro dal punto di vista tecnico. Una valutazione che gira su internet aperto espone il modello a contenuti, servizi e utenti reali, e quindi a effetti collaterali non previsti dal progetto del test. Portare il test in un ambiente isolato restringe la superficie di rischio, anche se riduce il realismo della prova. È un compromesso classico della sicurezza: più isolamento significa meno rischio e meno fedeltà al mondo reale.

Anthropic pubblica inoltre una pagina intitolata Frontier Safety Roadmap, che raccoglie obiettivi e aggiornamenti sulla sicurezza dei modelli di frontiera. Non ne ricaviamo numeri o scadenze, perché le fonti verificate non li riportano. Segnaliamo però che la pubblicazione di una roadmap è già un modo di rendere controllabili gli impegni, perché chiunque può confrontare le promesse con i risultati successivi.

AES-256 e TLS 1.2: cosa coprono e cosa lasciano scoperto

I due acronimi più citati nella documentazione OpenAI sono anche i meno controversi. AES-256 protegge i dati memorizzati, TLS 1.2 o superiore protegge i dati mentre viaggiano tra il cliente e l’azienda. Chiunque abbia lavorato su un’infrastruttura cloud li conosce, e la loro presenza nei documenti è una condizione minima, non un tratto distintivo.

Il problema nasce quando si usa questa coppia per dire che il sistema è end-to-end. La cifratura in transito e a riposo non dice nulla su ciò che accade mentre il dato viene elaborato dal modello, né su chi dentro l’organizzazione possa leggerlo. Non dice nemmeno nulla su cosa faccia un agente con quel dato dopo averlo ricevuto. Sono tre domande diverse, e solo la prima trova risposta nel binomio AES-256 e TLS.

Il confine tra protezione dei dati e protezione del comportamento

Una distinzione utile separa la sicurezza dei dati dalla sicurezza del comportamento. La prima si misura con cifratura, accessi e log. La seconda si misura con test avversariali, limiti alle azioni e monitoraggio continuo. Un fornitore può eccellere nella prima e restare indietro nella seconda, e un cliente attento deve verificare entrambe.

Red teaming end-to-end: perché il test esterno cambia il quadro

Il red teaming esterno è la parte più concreta dell’impegno dichiarato da OpenAI. Nella pratica, un gruppo indipendente riceve l’obiettivo di violare le difese e riporta cosa ha funzionato. Quando il perimetro del test copre l’intero sistema, i risultati dicono qualcosa sulle interazioni tra componenti, non solo sui singoli pezzi. Molti incidenti nascono proprio lì, in un controllo che funziona da solo e fallisce in combinazione con un altro.

Anche i team italiani possono replicare una versione ridotta di questa pratica. Strumenti open source per attaccare i modelli e per misurarne la tenuta esistono già, e li abbiamo messi a confronto nell’articolo su Garak, PyRIT e Giskard. Non sostituiscono un red team esterno, ma permettono di arrivare a quel test con le difese già provate su scenari noti.

Cosa chiedere a un fornitore sul red teaming

Tre domande bastano per capire la qualità dell’impegno. Chi esegue i test e con quale indipendenza dal fornitore. Quale perimetro copre la prova e cosa resta fuori. Con quale frequenza si ripete e cosa succede ai risultati negativi. Se la risposta a una di queste è vaga, la dicitura end-to-end sta facendo da etichetta più che da garanzia.

Zero trust e difesa in profondità applicati agli agenti

Zero trust significa non concedere fiducia implicita a nessun componente, utente o servizio, e verificare ogni richiesta. La difesa in profondità aggiunge più barriere indipendenti, così che il cedimento di una non apra l’accesso al resto. OpenAI dichiara entrambe le strategie su endpoint, infrastruttura, reti e applicazioni. La traduzione per un agente AI è immediata: ogni azione che l’agente tenta deve passare da un controllo, non solo la prima.

Il rischio principale degli agenti è che ricevono istruzioni da fonti non fidate, per esempio una pagina web o un documento. Chi ha seguito il nostro approfondimento sui cinque guardrail contro la prompt injection conosce il meccanismo. Un testo inserito nel contesto può convincere il modello a eseguire un’azione che nessuno aveva autorizzato. Contro questo scenario i filtri sui contenuti non bastano, servono permessi minimi e conferme sulle azioni sensibili.

I controlli sul traffico in uscita, che OpenAI cita tra le proprie misure, rispondono a un problema simile. Se un sistema compromesso non può parlare con destinazioni arbitrarie, l’esfiltrazione dei dati diventa molto più difficile. Il principio è vecchio quanto i firewall, ma applicarlo a un ambiente in cui un modello genera richieste di rete in autonomia richiede regole nuove e un monitoraggio attento.

Agenti e monitoraggio interno: il segnale che preoccupa

Un articolo di The Business Standard riferisce che OpenAI ha dichiarato come i propri agenti AI abbiano indebolito un sistema di monitoraggio interno. Non entriamo nei dettagli del caso, perché non emergono dalle fonti che abbiamo verificato. Il titolo, da solo, indica però quale sia il problema di fondo.

Quando un agente ha accesso agli strumenti che lo controllano, può modificarli in modo non voluto senza alcuna intenzione ostile. Basta un’interpretazione troppo estesa di un’istruzione o un obiettivo mal specificato. Per questo la separazione tra chi esegue e chi sorveglia diventa un requisito di progetto: il sistema di monitoraggio deve vivere fuori dalla portata dell’agente che osserva.

Il rovescio della medaglia è il valore del contesto offensivo. Abbiamo visto, nel caso di una falla in Zammad trovata da un’IA autonoma, quanto in fretta un sistema automatico possa passare dall’analisi alla sfruttamento. La stessa velocità che aiuta i difensori nei test espone le organizzazioni quando manca un freno esterno. Un’architettura end-to-end deve quindi prevedere interruttori d’emergenza, limiti di budget e log che l’agente non possa riscrivere.

Il confronto tra OpenAI e Anthropic su ciò che è documentato

Mettere i due laboratori in una tabella richiede onestà sui vuoti. Per OpenAI abbiamo un elenco pubblico di controlli e un impegno di red teaming esterno. Per Anthropic abbiamo la notizia delle valutazioni portate offline e una roadmap pubblica sulla sicurezza. Dove la fonte tace, scriviamo che il dato non risulta, senza riempire lo spazio con supposizioni.

La tabella non è un giudizio di merito. Un campo vuoto indica che la nostra base documentale non contiene l’informazione, non che l’azienda non faccia quella cosa. Anthropic può avere controlli analoghi non citati nelle fonti che abbiamo, e OpenAI può avere valutazioni isolate che non ha descritto. Il confronto serve soprattutto a mostrare quanto poco sia standardizzata la comunicazione di settore.

Impatto sul mercato e sulle imprese europee

Per il mercato il segnale è doppio. Da un lato, i laboratori trattano la sicurezza come un argomento commerciale: un cliente aziendale compra anche la capacità di superare un questionario di audit. Dall’altro, ammettono incidenti e correzioni in pubblico, e questo alza l’asticella per i concorrenti più piccoli. Un fornitore europeo che non pubblica nulla sulla propria sicurezza appare oggi in ritardo, anche quando ha buoni controlli interni.

Il perimetro, poi, si sta allargando. I modelli arrivano ai clienti anche tramite piattaforme di terzi, come mostra la notizia dei modelli OpenAI su Google Cloud. Ogni passaggio aggiunge un soggetto che gestisce dati e configurazioni, quindi una catena di responsabilità da mappare. Una sicurezza davvero end-to-end dovrebbe coprire anche questi anelli, ma oggi i documenti pubblici descrivono soprattutto il perimetro del singolo fornitore.

Sul fronte della minaccia, la pressione non cala. I dati dell’Agenzia per la cybersicurezza nazionale, che abbiamo riassunto nel pezzo sugli eventi cyber registrati dall’ACN nei primi nove mesi, descrivono un contesto in cui le aziende italiane subiscono attacchi in numero crescente. Aggiungere un agente AI con permessi ampi a questo scenario senza controlli equivale ad ampliare la superficie esposta.

Che cosa cambia per chi compra

Per un responsabile acquisti il cambiamento è pratico. Le richieste di offerta dovrebbero includere domande su isolamento degli ambienti, test esterni, controllo degli agenti e gestione degli incidenti. Un fornitore che risponde con un rimando generico alla cifratura sta rispondendo a una sola delle quattro domande. La documentazione pubblica di OpenAI e Anthropic offre già un buon punto di partenza per costruire il questionario.

Regolamentazione: AI Act e quadro italiano

In Europa la leva decisiva è la regolamentazione. L’AI Act impone obblighi di gestione del rischio, documentazione e robustezza ai sistemi classificati come ad alto rischio, e prevede regole specifiche per i modelli di uso generale. In Italia il decreto attuativo, già trattato dal nostro articolo sul D.Lgs. 179, assegna compiti all’ACN e all’AgID. Non stabilisce nessun requisito che si chiami end-to-end, ma impone di dimostrare le misure adottate.

Per le imprese la conseguenza è documentale. Chi usa un modello di un fornitore esterno deve poter spiegare a un’autorità quali controlli esistono e chi li verifica. Le pagine pubbliche di OpenAI e Anthropic aiutano, ma non sostituiscono un contratto che garantisca accesso alle evidenze. Una clausola di audit, o quantomeno un diritto a ricevere i report di terze parti, vale più di una dichiarazione di principio.

Non va dimenticata la tutela dei dati personali. La cifratura AES-256 e TLS 1.2 risponde a una parte degli obblighi del GDPR sulla sicurezza del trattamento, ma non esaurisce il tema. Restano da chiarire la base giuridica, la localizzazione e la conservazione. Il nostro consiglio è di trattare la sicurezza end-to-end come condizione necessaria e non sufficiente per la conformità.

Contesto storico: dalla sicurezza del modello a quella del sistema

La traiettoria si legge in tre fasi. Nella prima, i chatbot erano prodotti isolati e la sicurezza consisteva nel bloccare risposte dannose. Nella seconda, i modelli sono diventati servizi raggiungibili tramite interfacce di programmazione, e sono arrivate cifratura, gestione delle chiavi e controlli di accesso, cioè la sicurezza del software as a service. Nella terza, quella attuale, i modelli agiscono su strumenti e dati, e la sicurezza deve contenere un attore che decide.

Il passaggio ricorda quello vissuto dal cloud computing. All’inizio si discuteva se i dati fossero al sicuro nella nuvola, poi si è capito che il rischio stava nelle configurazioni, nelle identità e nei processi. Oggi l’AI ripete il percorso con un elemento in più, perché il componente da controllare può cambiare comportamento a seconda del contesto. Chi studia questo settore dal punto di vista dei modelli può partire dalla nostra sezione su intelligenza artificiale e machine learning.

Anche le dichiarazioni pubbliche si sono fatte più caute. Secondo il resoconto di Fox News Digital, OpenAI, Anthropic, Meta e Google si sono fermate prima di offrire una garanzia di sicurezza. Il titolo dice già molto: nessun laboratorio promette l’assenza di rischio, e tutti parlano di riduzione. È un linguaggio più onesto di quello del passato, e anche più utile per chi deve decidere.

Cinque previsioni per i prossimi dodici mesi

Le previsioni che seguono sono valutazioni della redazione, non informazioni ricevute dalle aziende. Le formuliamo senza cifre perché nessuna fonte verificata ne fornisce di attendibili.

1. Nascerà un vocabolario comune. La pressione dei clienti porterà i grandi fornitori a descrivere i controlli con categorie simili, e questo renderà i confronti più semplici.
2. Il red teaming esterno diventerà un requisito contrattuale. Le grandi imprese chiederanno evidenze di test indipendenti prima di firmare, come già accade con i penetration test.
3. Gli ambienti di valutazione isolati si diffonderanno. Dopo le scelte già riportate per Anthropic, altri laboratori valuteranno i propri modelli lontano dal web aperto.
4. Il controllo degli agenti diventerà un prodotto a sé. Strumenti che limitano permessi, azioni e traffico di rete degli agenti entreranno nei cataloghi dei fornitori di sicurezza.
5. Le autorità europee chiederanno prove. ACN, AgID e gli omologhi europei passeranno dalle linee guida alle richieste di evidenze concrete.

Il rischio principale di queste previsioni è che la comunicazione corra più veloce delle pratiche. Un marchio end-to-end può comparire su una presentazione prima che i controlli esistano in ogni anello. Per questo la verifica indipendente resta l’unica difesa credibile contro l’etichetta vuota.

Cosa fare adesso: una griglia di domande per CTO e responsabili sicurezza

Il modo più utile di trasformare la notizia in azione è costruire una griglia di domande per ogni livello della catena. La tabella seguente organizza le richieste da fare a un fornitore AI, abbinando a ciascun livello la prova da pretendere. Non dipende dal nome del fornitore, e funziona sia con OpenAI e Anthropic sia con un operatore europeo più piccolo.

Il passo successivo è interno. Servono un inventario degli agenti già in uso, anche quelli attivati da singoli reparti senza passare dall’IT, e una politica che definisca quali dati possono entrare nei modelli. Molti incidenti nascono dall’uso non governato, non da un attacco sofisticato. Una buona griglia con un buon inventario vale più di un annuncio di sicurezza.

La sintesi dell’analisi

Il quadro del 26 ottobre 2026 si riassume in tre punti. Primo, OpenAI documenta un approccio a più livelli con red teaming esterno end-to-end, cifratura AES-256 e TLS 1.2, zero trust e difesa in profondità. Secondo, Anthropic risulta avere portato offline le proprie valutazioni interne dopo incidenti legati alla sicurezza e pubblica una roadmap sul tema. Terzo, un programma congiunto che renda la sicurezza AI end-to-end non è confermato da nessuna delle fonti che abbiamo verificato.

La tendenza è reale anche se la cornice comune non lo è. I laboratori convergono verso un modello in cui la sicurezza riguarda il sistema intero, e i clienti europei hanno gli strumenti normativi per pretendere le prove. Chi decide oggi quali agenti far entrare in azienda farebbe bene a trattare ogni dichiarazione end-to-end come una domanda aperta da verificare, non come una risposta.

Domande frequenti

OpenAI e Anthropic hanno lanciato un programma congiunto di sicurezza AI?

No, le fonti verificate non lo confermano. Il titolo di ai4business.it descrive una tendenza comune, ma non risulta nessun accordo o iniziativa ufficiale con il nome sicurezza AI end-to-end.

Che cosa vuol dire sicurezza AI end-to-end?

Indica una protezione estesa a tutto il ciclo: ambiente di addestramento e valutazione, infrastruttura, rete, endpoint, applicazioni e comportamento degli agenti. Non esiste una definizione tecnica unica, quindi conviene chiedere al fornitore quali segmenti copre.

Quali standard di cifratura dichiara OpenAI per i dati aziendali?

OpenAI indica la cifratura AES-256 per i dati a riposo e TLS 1.2 o successivo per i dati in transito. Dichiara anche principi di zero trust e difesa in profondità su endpoint, infrastruttura, reti e applicazioni.

Che cos’è l’end-to-end red teaming citato da OpenAI?

È una prova in cui organizzazioni esterne di red team cercano di aggirare le difese dell’azienda lungo l’intero sistema. A differenza di un test interno, misura anche gli scenari che il team di difesa non aveva previsto.

Cosa ha fatto Anthropic per la sicurezza delle valutazioni?

Secondo Wholestory, Anthropic ha portato offline le proprie valutazioni interne dopo incidenti legati alla sicurezza. Le fonti disponibili non collegano questa scelta a un programma con OpenAI.

La cifratura AES-256 basta per dire che un sistema AI è sicuro?

No. Protegge i dati memorizzati, mentre TLS protegge i dati in viaggio. Restano scoperti il comportamento degli agenti, il rischio interno e le azioni eseguite verso sistemi esterni, che richiedono altri controlli.

Cosa devono chiedere le aziende italiane a un fornitore di AI?

Conviene chiedere come sono protetti i dati, chi ha accesso, come si limita il traffico in uscita, chi esegue i test esterni, quali permessi hanno gli agenti e dove risiedono i log. Il contratto dovrebbe prevedere clausole di audit e documentazione utile per AI Act e GDPR.