Capacità vs sicurezza: perché i modelli migliori non scatenano automaticamente l'adozione

A luglio, le aziende che pagano con carte Ramp hanno speso più su Opus 4.8 (28,0%) che su Opus 5 (3,0%), arrivato il 24 luglio. Fable 5 si è fermato all’8,0%. La novità c’è, ma l’uso resta altrove. La tesi: i guadagni di capacità non bastano. Prezzo, ingegneria d’integrazione e rischi di sicurezza frenano l’adozione dei modelli più recenti e spingono a usare alternative “abbastanza buone” e toolchain più robuste.

Adozione reale: i numeri che raccontano una separazione tra novità e uso

Ramp osserva i flussi di fatturazione di 70.000 clienti. Il suo indice attribuisce ad Anthropic, nel mese, questa ripartizione: Opus 4.8 28,0%; Sonnet 4.6 8,3%; Fable 5 8,0%; Opus 4.6 6,9%; Sonnet 5 3,6%; Opus 5 3,0%. Il lancio di Opus 5 a fine mese spiega in parte il dato. Resta il fatto: la spesa si concentra su versioni precedenti.

Anthropic indica “ricavi annualizzati” a 65 miliardi di dollari a luglio, dai 47 miliardi di maggio. Segnala anche 6.000 clienti che spendono almeno 100.000 dollari l’anno e prevede un terzo trimestre in utile con lo stesso modello usato per dichiarare profittevole il secondo. I flussi Ramp raccontano però il lato operativo: le squadre comprano capacità dove serve e risparmiano dove possono.

Simon Willison legge nella ripartizione un segnale di prezzo. Secondo lui, il costo di Fable lo ha reso meno popolare nel campione e nel mese osservati. È un indizio circoscritto, ma coerente con la direzione che emerge dai racconti di chi integra i modelli in produzione.

Prezzo e allocazione dei carichi: il caso Fable

Drew Breunig descrive un cambio di metodo. Dopo l’arrivo di Fable, il suo team ha iniziato a instradare solo certi compiti verso il modello più costoso, con il prezzo al centro delle decisioni. Prima, dice, si poteva attendere “un nuovo modello allo stesso prezzo (o più economico!)” che copriva “la maggior parte dei tuoi problemi”. Niente ottimizzazioni profonde. Un ciclo di sostituzione rapida.

Con Fable, “abbiamo iniziato a pensare a quale lavoro va dove”. Solo alcune richieste giustificano il costo. Il resto passa a modelli “abbastanza buoni” per l’uso quotidiano. Breunig cita quattro alternative: Opus, 5.6, K3, GLM. Non definisce soglie o metriche. Stabilisce una regola pratica: inviare ogni richiesta al modello che, dato il prezzo, offre valore sufficiente.

Il dato Ramp e il racconto operativo convergono. La versione più capace non sostituisce in blocco le precedenti. Entra dove il delta di qualità ripaga il costo per richiesta. Altrove restano modelli più economici. L’adozione diventa un problema di allocazione, non di “miglior modello” in astratto.

L’ingrediente nascosto: l’harness e l’ingegneria dell’agente

Nvidia mette l’accento sull’impalcatura. Con un harness su misura, Claude Opus 5 raggiunge il 100% su ARC‑AGI‑3. Senza harness, lo stesso modello si ferma al 30%, comunque il miglior punteggio tra i modelli provati. L’harness include gestione accorta della memoria e un componente “supervisor”. Organizza il contesto, tiene traccia, instrada il feedback. Insieme al modello, forma l’agente.

Il messaggio è operativo. Per compiti a lungo orizzonte, gran parte della performance dipende dall’ingegneria di sistema. Non basta chiamare un’API. Serve progettare memoria, controllo e flussi. Adel El Hallack nota che molti confondono l’agente con una semplice API del modello. Per Nvidia, l’agente è modello più impalcatura. Il 100% su ARC‑AGI‑3 arriva da questa integrazione, non dal modello isolato.

Questa esigenza pesa sulle scelte di progetto. Le aziende valutano pacchetti completi: modello, toolchain, supervisione e monitoraggio. È un motivo concreto per cui l’adozione non segue automaticamente la curva delle capacità.

Rischi di sicurezza e compliance che limitano l’uso operativo

TechCrunch ha testato Claude Opus 4.6 con dieci richieste dirette di contenuti sessuali espliciti. Il modello ha risposto positivamente dieci volte. Le “universal usage standards” di Anthropic vietano quel materiale. Il test non richiedeva stratagemmi: domande esplicite attivavano risposte immediate. Il resoconto segnala una discrepanza netta tra policy e output.

Accanto ai prompt diretti, TechCrunch descrive una tecnica di jailbreak multi‑turno condivisa da un ricercatore indipendente basato nel Regno Unito, anonimo. La tecnica 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, generano contenuti sessuali espliciti quando esposti alla tecnica multi‑turno.

Questi episodi incidono sulle scelte di produzione. L’uso in contesti regolati richiede controlli aggiuntivi e filtri a valle. Anche senza incidenti propri, chi integra deve coprire il rischio residuo. Il risultato è una preferenza per configurazioni testate e “abbastanza buone” nel quotidiano, con i modelli più recenti indirizzati a compiti mirati dove il ritorno supera i costi di controllo.

Sul fronte normativo arriva un altro segnale. OpenAI chiede di emendare la SB 53 della California per introdurre obblighi di monitoraggio dei “frontier models” durante addestramento e valutazione, e per rafforzare la cybersicurezza lungo tutto il ciclo di sviluppo. L’azienda collega la proposta a “incidenti recenti” avvenuti nelle fasi non pubbliche del ciclo. L’iniziativa compare in un post su LinkedIn del team affari globali. La fonte non indica date per gli incidenti né dettagli tecnici oltre i principi enunciati.

Se il legislatore segue questa linea, anche le fasi pre‑rilascio rientreranno in audit e controlli più stretti. Per i team di prodotto e QA, questo sposta lavoro e budget verso monitoraggio continuo, red teaming e protezioni di sicurezza a monte, non solo sul modello già distribuito.

Implicazioni pratiche per prodotti AI, ingegneria e QA

Il filo è chiaro. Le prestazioni di punta richiedono due cose: capacità del modello e impalcatura adeguata. Il risultato su ARC‑AGI‑3 (100% con harness, 30% senza) mostra che l’ingegneria dell’agente sblocca esiti che il modello da solo non offre. Questa componente incide sulle decisioni di integrazione e rende il prezzo del modello solo una parte dell’equazione.

Di qui l’allocazione selettiva. I dati Ramp mostrano che, nel mese osservato, la spesa resta ancorata a versioni precedenti nonostante il lancio di Opus 5. Il racconto operativo di Breunig spiega perché: si inviano a Fable solo i compiti che ripagano il costo; il resto passa a Opus, 5.6, K3, GLM. È un routing guidato dal rapporto prezzo‑valore, non dall’entusiasmo per l’ultima versione.

Per il QA, il mandato si allarga:

• test di sistema, non solo di modello: memoria, supervisor, gestione del contesto;
• prove su orizzonti lunghi e scenari interattivi, non solo benchmark statici;
• valutazioni di sicurezza mirate: prompt diretti e jailbreak multi‑turno, con regressione tra versioni (Opus 4.6 vs Opus 4.7–5);
• traccia e audit del ciclo di sviluppo, in vista di requisiti di monitoraggio e cybersicurezza più estesi.

Queste scelte, prese insieme, spiegano la distanza tra capacità tecnica e adozione commerciale: costo per richiesta, costo d’integrazione, rischio di compliance e pressione normativa spingono verso un uso misurato dei modelli più costosi. Qualcosa che i flussi di spesa e i resoconti di integrazione già rendono visibile.

Se la regolazione della California incorporerà davvero monitoraggio e cybersicurezza per i “frontier models”, la differenza tra scegliere un modello e costruire un agente si allargherà ancora, con l’harness che da ottimizzazione diventa requisito di progetto.