Il 97,9% di accuratezza in un test di migrazione COBOL sembra vicino alla soluzione. In produzione, però, il 2,1% restante può contenere una regola contabile, un arrotondamento o un’integrazione che nessuno ha documentato. Le notizie AI di oggi raccontano la stessa transizione da quattro angoli: i modelli stanno diventando infrastruttura aziendale, mentre controllo, costi e responsabilità restano problemi umani.

Anthropic porta il modello verso la Borsa

Anthropic ha depositato il prospetto per la quotazione con il ticker ANT. Nel primo semestre 2026 ha dichiarato 16,3 miliardi di dollari di ricavi, contro 1,2 miliardi nello stesso periodo del 2025. A fine settembre contava inoltre più di 11.900 clienti con una spesa annua di almeno 100.000 dollari.

Il dato utile per un’impresa non è la valutazione finanziaria, ma la direzione del mercato: i fornitori di modelli stanno costruendo relazioni enterprise sempre più profonde. La struttura prevista assegna alla Founder LLC il 50,1% dei diritti di voto, mentre il Long-Term Benefit Trust mantiene un ruolo nella nomina del consiglio. Chi adotta un provider AI deve quindi valutare anche governance, dipendenze e possibilità di uscita, non soltanto qualità del modello e prezzo per token. È lo stesso principio applicato quando si progetta uno stack AI con leve di controllo.

Il COBOL misura il confine dell’automazione

OpenAI ha pubblicato una valutazione sulla migrazione di programmi COBOL verso C++, Java, Kotlin, Python e Rust. GPT-6.1 Sol raggiunge l’86,6% di accuratezza a basso reasoning e il 97,9% a reasoning più elevato, con test nascosti che richiedono parità byte per byte dell’output osservabile.

È un progresso concreto, ma non equivale a sostituire un sistema legacy. OpenAI stessa specifica che l’uso in produzione richiede revisione esperta e test sulle regole aziendali e sulle dipendenze. Un gestionale storico non è solo codice: contiene formati dati, procedure, eccezioni e integrazioni cresciute negli anni. Per una PMI la sequenza sensata è più prudente: inventario, test di caratterizzazione, migrazione di un modulo isolato, esecuzione parallela e confronto degli output. L’AI riduce il costo della traduzione; non firma il collaudo.

Le GPU ricordano che il picco non è il carico reale

Un progetto sperimentale ha rimosso un limite alle operazioni tensor FP16 e BF16 con accumulo FP32 su alcune GPU Nvidia RTX delle serie 20, 30 e 40. Su una RTX 4090 il throughput teorico è passato da circa 166 a 332 TFLOPS. Nei test cuBLAS dello stesso progetto, però, i guadagni mediani FP16 sono variati dal 12% al 34%; un carico quantizzato di serving non ha ottenuto benefici.

Il software usa inoltre moduli non ufficiali e gli autori avvertono che può bloccare la GPU, corrompere dati o danneggiare l’hardware. Non è quindi una scorciatoia consigliabile per un server aziendale. È piuttosto un promemoria per il capacity planning: confrontare token al secondo, latenza, consumo e stabilità sul proprio workload, come già conviene fare quando si sceglie tra hardware locale e GPU cloud.

L’open source prova a filtrare l’AI

I moderatori di r/opensource hanno introdotto regole che escludono progetti realizzati con AI, destinati all’AI o che la usano. Sono stati aggiunti anche requisiti su anzianità, numero di contributori e comunità esistente. Un moderatore ha ammesso che non esiste un criterio oggettivo per applicare la policy; un altro ha dichiarato di non essere stato consultato.

Il problema di partenza è reale: distinguere un progetto mantenibile da codice generato in fretta costa tempo. Il divieto basato sullo strumento, però, non misura test, sicurezza, manutenzione o responsabilità. Per team web e WordPress è più utile registrare provenienza delle modifiche, review umana, test automatici e autore responsabile. Il gate deve giudicare l’output e il processo, non indovinare come è stata scritta ogni riga.

La take operativa: comprare controllo

Le quattro notizie convergono su una decisione: nel 2026 adottare AI significa comprare una dipendenza operativa. Prima di estendere un progetto, una PMI dovrebbe misurare un workflow reale, fissare un criterio di accettazione e preparare un percorso di rollback. Il provider va valutato per governance e portabilità; la migrazione per equivalenza del comportamento; l’hardware per prestazioni applicative; il codice assistito per verificabilità.

La metrica utile non è “quanto codice genera” o “quanti TFLOPS promette”, ma quante attività corrette arrivano in produzione senza ampliare il rischio. Un buon punto di partenza è misurare il ROI su un solo workflow e ampliare l’adozione solo dopo aver registrato errori, tempi di revisione e costi di uscita.

Fonti