Generative AI: novità e riflessioni - #8 / 2026

Buon aggiornamento, e buone riflessioni..

Ascolta l'audio overview che sintetizza le novità

Generative AI: novità e riflessioni - #8 / 2026 - Audio Overview

0:00

/1051.213787

1×

Il podcast è stato generato attraverso Gemini Notebook.

Quando l’AI esce dalle demo ed entra nei processi reali

Ho fatto una chiacchierata con Raffaele Gaito su cosa succede davvero quando l’AI esce dalle demo ed entra nei processi reali.

Abbiamo parlato soprattutto di agenti AI e della distanza, ancora ampia, tra potenzialità e affidabilità. Creare un proof of concept oggi può richiedere pochi minuti; trasformarlo in un sistema che lavori migliaia di volte al giorno, in modo stabile e con costi sostenibili, è un problema completamente diverso.
Il vero lavoro spesso non è nel modello, ma in tutto ciò che gli sta intorno: dati, integrazioni, osservabilità, scalabilità, testing e controllo dei costi.

Anche per questo, in alcune sperimentazioni siamo riusciti a ridurre fino al 90% il consumo degli agenti, utilizzando lo stesso modello e intervenendo sul layer applicativo, sui tool e sulla quantità di informazioni inserite nel loop agentico.

Agenti AI in produzione: la sindrome del proof of concept (e come uscirne)

Una chiacchierata con Raffaele Gaito su agenti AI, Web MCP e prompt engineering: perché far funzionare un agente in demo è facile, ma renderlo affidabile in produzione è un altro mestiere. Con le tecniche per tagliare i costi di un agente del 90%, e una riflessione sul valore umano.

Alessio PomaroAlessio Pomaro

Ci siamo confrontati anche sul prompt engineering, che non considero affatto morto. Modelli più performanti non “leggono nella mente”: seguono meglio le istruzioni che ricevono.
Struttura, precisione e contesto diventano quindi ancora più importanti, soprattutto nei sistemi agentici e nei flussi multimodali.

Un altro tema centrale è quello delle competenze. L’AI può produrre qualcosa di bello o funzionante con indicazioni minime, ma la competenza permette di ottenere esattamente ciò che si ha in mente, capire cosa accade nel processo e mantenere il controllo sull’output.

Infine, abbiamo ragionato sul valore umano in uno scenario che cambia a grande velocità.
Per me resta nella curiosità, nella sperimentazione continua e nella capacità di condividere ciò che impariamo.

Molte applicazioni che oggi arrivano in produzione nascono da test fatti quando ancora non esisteva un caso d’uso evidente. Chi aspetta il caso reale per iniziare a sperimentare parte già in ritardo.

Dalla black box all’ingegneria: come progettare sistemi LLM affidabili

Vorrei partire da un commento ricevuto al video registrato con Raffaele Gaito:

“Come fai a stabilire con certezza assoluta che la black box stocastica ti dia quell’output quando l’input cambia anche solo di un token?”

La risposta breve è: non lo stabilisci. E non è nemmeno quello che dovresti cercare.
Dobbiamo evolvere il modo in cui concepiamo questi sistemi e superare l’idea che espressioni come “black box stocastica” o “pappagallo stocastico” descrivano davvero un moderno modello di frontiera.

Che un LLM generi il prossimo token a partire da una distribuzione probabilistica è vero. Ma concludere che stia semplicemente “indovinando parole” è un po’ come descrivere un computer dicendo che sposta elettroni.

Tecnicamente vero. Concettualmente poco utile.

All’interno della rete emergono rappresentazioni che permettono al modello di astrarre concetti, generalizzare, seguire istruzioni, pianificare azioni e utilizzare strumenti.
Possiamo discutere a lungo se chiamare tutto questo “comprensione”. Dal punto di vista ingegneristico, però, la questione interessante è un’altra: queste capacità esistono, sono osservabili e possiamo misurarne l’affidabilità.

Ed è qui che cambia il paradigma. Nel software tradizionale chiediamo: dato questo input, otterrò esattamente questo output?
Con un sistema generativo la domanda diventa: dato un insieme di input possibili, quanto è affidabile il comportamento del sistema e come posso mantenerlo entro confini accettabili?

Qui entra in gioco l’harness.

Non semplicemente “un prompt migliore”, ma il sistema ingegneristico costruito attorno al modello: eval automatiche, regression test, validazione degli output, grounding tramite RAG, tool calling, osservabilità, versioning, fallback, gestione degli errori e human-in-the-loop dove necessario.
Structured output, JSON, tool calling e orchestrazione non rendono deterministico un LLM. Restringono, però, lo spazio delle azioni possibili, rendono il comportamento più verificabile e aiutano a intercettare eventuali deviazioni.
Quindi no: non “preghiamo la black box” sperando che al prossimo token vada tutto bene.

Definiamo cosa significa “bene”. Lo misuriamo. Stressiamo il sistema. Intercettiamo le regressioni. Progettiamo i failure mode.
La certezza assoluta è spesso una falsa esigenza.
L’obiettivo reale è molto più utile: affidabilità misurabile, governabile e riproducibile su scala.

È qui che finisce la demo e comincia l’ingegneria.

Seedance 2.5: il nuovo riferimento per la generazione video?

Nell'ultimo periodo ho potuto testare Seedance 2.5 di ByteDance e, per quanto visto finora, credo che sia oggi uno dei modelli più potenti sul mercato per la generazione video.

Ho realizzato due test.

Nel primo ho utilizzato più reference image: una mia immagine full body, generata con GPT Image 2, un dettaglio del volto, uno delle scarpe e un cappellino con la stampa del mio sito web. Ho costruito un prompt molto strutturato, associando le diverse reference agli elementi della scena e definendo una timeline precisa. Il risultato è stato un video di 24 secondi.
Nel secondo test sono partito da una sola reference image del mio volto. Anche in questo caso ho scritto un prompt strutturato, con un richiamo esplicito alla reference e una timeline dettagliata, ottenendo un video di 30 secondi.

Per quanto mi riguarda, i risultati sono andati oltre le aspettative. Non parlo da tecnico del visual, ma sulla base del confronto con lo stato dell’arte che conoscevo fino a questo momento. Dal mio punto di vista, i modelli video di Google, come Veo e Omni, sono ancora lontani dalla qualità raggiunta da Seedance 2.5.

Ho scritto spesso che, nei modelli video, a stupire non è soltanto la qualità dell’output, ma soprattutto l’aderenza alle istruzioni: in altre parole, il controllo che il prompt permette di esercitare sul risultato. In questo caso, stupiscono entrambe.

Seedance 2.5 produce infatti un output di qualità elevata, mantiene una notevole coerenza con le reference e segue in modo estremamente preciso la timeline. Identità, abbigliamento, accessori, movimenti e successione delle scene restano sorprendentemente consistenti.

Mi ha colpito anche l’efficienza del processo. Nei test effettuati in passato erano spesso necessari diversi cicli di generazione e ottimizzazione del prompt per arrivare a un buon risultato. Per il primo video sono bastate due esecuzioni e, analizzando il tentativo iniziale, mi sono accorto che il problema era nel mio prompt. Per il secondo è stata sufficiente una sola generazione: “one shot, one kill”.

Test con storyboard

In un nuovo test ho lavorato su coerenza del personaggio, continuità tra le inquadrature e controllo della regia. Partendo da una mia immagine di reference, ho creato con GPT Image 2 uno storyboard di 12 inquadrature, definendo pose, movimenti, angoli di ripresa e progressione della coreografia.

Ho poi combinato reference del volto, storyboard e un prompt strutturato in sezioni, con indicazioni dettagliate su identità, abbigliamento, location, sequenza shot-by-shot, camera ed editing. Il risultato, ottenuto in un’unica generazione di 30 secondi, mostra un livello di controllo e coerenza molto elevato: il personaggio resta riconoscibile, l’abbigliamento è stabile, la location mantiene continuità e le inquadrature seguono bene la logica dello storyboard.

Sono emerse anche alcune imprecisioni, come la variazione della pavimentazione dell’helipad, ma il punto interessante è che l’errore era già presente nello storyboard e il modello lo ha semplicemente ereditato.

Nel complesso, reference personale, storyboard e prompt strutturato hanno prodotto un risultato molto convincente, con una qualità vicina a quella di un videoclip costruito e montato.

Quando l’AI separerà la conoscenza dalla comprensione

Forse non ci rendiamo ancora pienamente conto del momento straordinario che stiamo vivendo con l’intelligenza artificiale applicata alla scienza.

Recentemente ho condiviso le slide di Mathematics in the Age of AI, ma consiglio di guardare anche l’intervento di Terence Tao, perché contiene una riflessione che va ben oltre l’AI intesa come semplice strumento per risolvere problemi.

Tao paragona il momento attuale a una delle grandi svolte della matematica moderna: la crisi dei fondamenti tra la fine dell’Ottocento e l’inizio del Novecento.
Allora i matematici furono costretti a interrogarsi su questioni radicali: che cos’è una dimostrazione? Da quali assiomi possiamo partire? Che cosa sono i numeri? Come si definisce un insieme? Come trattiamo l’infinito? Un sistema matematico può dimostrare tutto ciò che è vero? Possiamo sapere se è privo di contraddizioni?

Da queste domande nacquero o si svilupparono la logica matematica, la teoria degli insiemi, il programma di Hilbert, i teoremi di Gödel e i risultati di Church e Turing sui limiti della calcolabilità.

Il punto di Tao è che l’AI potrebbe costringerci a una riflessione altrettanto profonda. Potremmo presto trovarci di fronte a un caso in cui un’AI dimostra un teorema importante in modo corretto e formalmente verificabile, ma attraverso una dimostrazione che nessun essere umano riesce realmente a comprendere.

A quel punto, possiamo dire di aver capito qualcosa? O sappiamo soltanto che il teorema è vero?

La distinzione è decisiva. Una buona dimostrazione non serve soltanto a certificare una verità: serve a spiegare perché è vera, a rivelare strutture, connessioni e nuove idee.

La stessa questione, aggiungo io, potrebbe emergere nel software. Se i sistemi di AI saranno in grado di scrivere, testare, verificare e modificare codice autonomamente, potremmo avere software perfettamente funzionante ma non più progettato per essere comprensibile agli esseri umani: codice per il quale l’interpretabilità umana non è più un requisito.

Per secoli abbiamo quasi identificato il progresso scientifico con l’aumento della comprensione umana. L’AI potrebbe separare, su larga scala, questi due aspetti: potremmo sapere che qualcosa è vero, o che funziona, senza comprenderne davvero il perché.

Forse una delle grandi domande dei prossimi anni sarà proprio questa: quanto siamo disposti a separare il progresso della conoscenza dalla comprensione umana?

Scrivere codice non è più la vera sfida

Benoit Schillings, VP della Ricerca di Google DeepMind, sostiene che l’ingegneria del software stia entrando in una nuova fase: il vero problema non è più produrre righe di codice, ma capire cosa costruire, specificarlo correttamente e verificarne il comportamento.

Schillings programma da circa 45 anni e individua tre fasi nell’evoluzione del software. All’inizio il limite era rappresentato dalla macchina: poca potenza di calcolo e la necessità di ottimizzare ogni istruzione. Con il cloud, il collo di bottiglia è diventato la capacità umana di gestire sistemi sempre più complessi. Ora, con l’AI, il limite si sta spostando ancora.

Modelli come Gemini sono già molto efficaci nel generare funzioni e codice quando il problema è ben specificato. Secondo Schillings, quindi, il lavoro dell’ingegnere si concentra sempre più su architettura, decomposizione dei problemi, verifica, sicurezza e gestione di codebase enormi senza introdurre conseguenze impreviste.

La sua tesi non è che l’ingegneria del software sia stata “risolta”, ma che la scrittura sintattica del codice stia progressivamente perdendo centralità.

Un altro passaggio interessante riguarda il self-play. Se i dati prodotti dagli esseri umani disponibili per addestrare i modelli diventassero insufficienti, i sistemi potrebbero creare autonomamente problemi di programmazione, tentare di risolverli e valutare le proprie soluzioni. Un approccio simile a quello che ha permesso ad AlphaZero di raggiungere prestazioni sovrumane attraverso l’autoapprendimento.

Schillings sostiene inoltre che una quota molto elevata del nuovo codice pubblicato su GitHub sia già generata dalle macchine.
Se il costo di generare software continuerà a diminuire, potrebbe cambiare anche il modo in cui il codice viene controllato. In futuro, gran parte del codice prodotto dai modelli potrebbe non essere più letto direttamente dagli esseri umani, proprio come oggi quasi nessuno controlla l’assembly generato da un compilatore.

Questo scenario apre anche una riflessione sui linguaggi di programmazione. Se il codice sarà scritto e letto soprattutto dalle macchine, potrebbero emergere linguaggi fortemente tipizzati e progettati più per garantire correttezza e verificabilità che per facilitare la leggibilità umana.

Il valore dell’ingegneria del software si sposterebbe così dalla semplice produzione di istruzioni alla specifica, verifica, architettura e comprensione dei sistemi complessi.

Quando gli agenti AI iniziano a coordinarsi da soli

OpenAI ha raccontato un caso particolarmente interessante di offensiva cyber condotta end-to-end da sistemi di intelligenza artificiale, che ha coinvolto anche l’infrastruttura di Hugging Face.
L’aspetto più significativo, però, non riguarda soltanto l’attacco in sé, ma il modo in cui diversi agenti inizialmente isolati sono riusciti a organizzarsi e collaborare autonomamente.

OpenAI stava conducendo numerose valutazioni di sicurezza su modelli sperimentali. Ogni agente operava all’interno di una propria macchina virtuale, senza accesso diretto a Internet, ma poteva utilizzare Artifactory, un servizio interno condiviso per la gestione dei pacchetti.
Quando alcuni agenti si sono trovati davanti a task impossibili o incompleti, hanno iniziato a cercare soluzioni alternative. Uno di loro ha scoperto di poter scrivere file su Artifactory e ha lasciato un messaggio chiedendo agli altri agenti se disponessero di un file che gli mancava.

Altri agenti hanno trovato il messaggio e hanno iniziato a rispondere.
Da quel momento è emerso spontaneamente un vero e proprio sistema di coordinamento: gli agenti si scambiavano informazioni, exploit e script, si assegnavano compiti e utilizzavano comandi come “hold swarm” per sincronizzare le attività. Alcuni payload venivano inoltre codificati in Base64.

Quando OpenAI ha eliminato il primo message board, gli agenti ne hanno creato un altro sfruttando i nomi delle directory di Artifactory. Avevano persino iniziato a utilizzare prefissi come “ZZ” per far comparire i loro messaggi in fondo agli elenchi ordinati alfabeticamente.

Questa collaborazione ha aumentato enormemente le loro capacità.
Gli agenti hanno individuato e concatenato diverse vulnerabilità nell’infrastruttura di OpenAI, ottenendo esecuzione di codice, privilegi root e accesso a credenziali e cluster interni.

Parallelamente hanno attaccato l’infrastruttura di Hugging Face, sfruttando due vulnerabilità zero-day nella gestione dei dataset e riuscendo a passare da un singolo pod a privilegi amministrativi su più cluster in meno di 13 ore.
Il punto centrale del talk è chiaro: l’offensiva cyber completamente automatizzata non è più soltanto un’ipotesi teorica.

Decine o centinaia di agenti possono lavorare contemporaneamente, condividere immediatamente ciò che scoprono e riutilizzare exploit, informazioni e credenziali trovati dagli altri.
Per OpenAI, questo cambia profondamente anche il problema della difesa. Automatizzare soltanto la scoperta delle vulnerabilità non sarà sufficiente: serviranno sistemi capaci di automatizzare l’intero ciclo di risposta, dalla detection alla patch, fino al deployment e all’eventuale rollback.

Perché se l’attacco diventa completamente automatizzato mentre la difesa continua a dipendere da processi umani, il divario in termini di velocità e scala rischia di diventare strutturale.

Google presenta Gemini 3.7 Flash: la guerra dei prezzi continua

Google presenta Gemini 3.7 Flash, il nuovo modello pensato soprattutto per coding, agenti AI e workflow complessi, con miglioramenti rilevanti rispetto a Gemini 3.6 Flash, presentato appena tre settimane prima.

Sul fronte del coding, Google dichiara progressi importanti nei benchmark dedicati al software engineering, debugging e generazione di codice pronto per la produzione. Migliora anche nello sviluppo web, dove il modello dovrebbe riuscire a creare applicazioni più complete e a seguire con maggiore precisione screenshot, immagini e design system.

Un altro salto riguarda i task ad alta densità informativa, come quelli nei settori della finanza, del diritto e delle bioscienze. Nei benchmark citati da Google, Gemini 3.7 Flash migliora sensibilmente anche nella gestione di documenti complessi e workflow di automazione.
Ma il punto forse più interessante riguarda gli agenti AI. Il modello è stato ottimizzato per seguire meglio le istruzioni, pianificare task multi-step, utilizzare strumenti esterni e gestire gli ostacoli con maggiore autonomia. L'obiettivo è ridurre tentativi ripetuti, errori e necessità di supervisione umana.

Poi c'è il prezzo.
Gemini 3.7 Flash viene lanciato a un prezzo di 0,75 dollari per milione di token in input e 3,75 dollari per milione in output: la metà del prezzo originale di Gemini 3.6 Flash.

È un segnale piuttosto chiaro della direzione che sta prendendo il mercato: non basta più avere il modello più potente. Conta sempre di più il rapporto tra capacità, velocità, affidabilità e costo reale per task.

Gemini 3.7 Flash sembra costruito esattamente attorno a questa idea: abbastanza intelligente da gestire workflow complessi, abbastanza veloce da essere utilizzato su larga scala e abbastanza economico da rendere sostenibili agenti e applicazioni AI in produzione.

PLUME: il cinema generativo diventa una vera produzione

Dave Clark ha presentato PLUME, un cortometraggio sci-fi realizzato con AI generativa e finalista al Best International AI Film degli Australian AI Film Awards.

Con oltre 21 minuti di durata, PLUME è il progetto GenAI più lungo realizzato finora da Clark. La storia segue Walker, un astronauta diretto verso Encelado durante una missione legata alla crisi idrica terrestre, fino alla scoperta di una possibile forma di vita aliena.

Clark ha scritto, diretto e montato personalmente il film. Non ha ancora pubblicato un making-of tecnico completo, ma, incrociando le informazioni disponibili, emerge una pipeline molto più vicina a una produzione cinematografica tradizionale che al semplice “text-to-video”.

Runway Gen-4 sembra essere stato uno dei principali modelli video utilizzati, anche se non è possibile confermare che ogni inquadratura sia stata generata con lo stesso sistema. Il metodo di Clark, documentato in altri suoi breakdown, parte da script, shot list, character design, ambienti e reference visive, per poi costruire le singole inquadrature attraverso image-to-video, coverage cinematografico e molteplici take.

La vera difficoltà, infatti, non è generare un bel clip di pochi secondi, ma mantenere personaggi, costumi, ambienti, illuminazione e linguaggio visivo coerenti per più di 20 minuti. Clark stesso ha spiegato che uno dei principali problemi del filmmaking GenAI è evitare il “model drift” e portare poi il materiale a una qualità adatta allo streaming.

Nel suo workflow pubblico compaiono anche strumenti come ElevenLabs per il voice-to-voice, Magnific per l’upscaling, Premiere Pro per editing e sound, DaVinci Resolve per il color grading e FilmConvert per grain e halation. Non tutti questi strumenti, però, sono stati confermati specificamente per PLUME.

Il risultato mostra bene la direzione che sta prendendo il cinema generativo: non un singolo prompt capace di produrre autonomamente un film, ma pipeline ibride in cui regia, montaggio, continuità, sound design e finishing restano processi fortemente controllati dall’autore.

ChatGPT Ads: targeting conversazionale senza accesso ai prompt degli utenti

Con l’arrivo di ChatGPT Ads in Europa, c’è un aspetto importante da chiarire: ricerche, prompt e conversazioni degli utenti non saranno messi a disposizione degli inserzionisti.

OpenAI potrà utilizzare il contesto e l’intento della conversazione per stabilire quali annunci mostrare, ma questo non significa che l’advertiser potrà leggere ciò che una persona ha scritto in chat.

Agli inserzionisti saranno invece disponibili dati e metriche aggregate sulle performance delle campagne, come impression, clic, CTR, CPC, CPM e conversioni, oltre a strumenti come OpenAI Pixel, Conversions API e integrazioni con piattaforme di misurazione esterne.

Il reporting potrà inoltre includere segmentazioni per elementi come Paese, dispositivo o prodotto, ma non un elenco delle query o dei prompt utilizzati dagli utenti.

La differenza è sostanziale: l’intento espresso in una conversazione può contribuire alla selezione dell’annuncio senza che il contenuto della conversazione venga esposto all’inserzionista.

È uno degli aspetti più interessanti del modello pubblicitario di ChatGPT: una forma di targeting basata sul contesto conversazionale, accompagnata dalle tradizionali metriche pubblicitarie, ma senza trasformare i prompt degli utenti in un report consultabile dagli advertiser.

Agenti AI e Machine Learning Engineering: quanto possono davvero amplificare il lavoro?

Ho voluto capire quanto un agente AI possa davvero supportare il lavoro di un Machine Learning Engineer, non limitandosi a scrivere codice, ma gestendo in autonomia interi cicli di sperimentazione, misurazione e correzione. Per il test ho utilizzato Claude Code CLI.

Nel primo esperimento ho fornito all’agente un dataset sintetico di marketing e un obiettivo semplice: prevedere il fatturato utilizzando variabili come budget, advertising, segmento cliente, prodotto, canale ed engagement.

L’agente ha costruito la pipeline, testato diverse reti neurali, confrontato architetture, learning rate, funzioni di loss, tecniche di regolarizzazione e trasformazioni del target, applicato l’early stopping e confrontato le reti con CatBoost.
Il risultato? 38 esperimenti, di cui 31 dedicati al training di reti neurali. A vincere non è stata la rete più complessa, ma una piccola MLP da circa 6.000 parametri, con un R² sul test pari a 0,963.

Poi ho voluto alzare drasticamente il livello.

Nel secondo test ho utilizzato dati commerciali reali anonimizzati di Olist e ho posto una domanda molto più vicina a un problema di business reale:

“Alla data T, utilizzando solo ciò che era già noto in quel momento, quanto fatturerà ciascun seller nei successivi 30 giorni?”

Qui il lavoro è diventato decisamente più complesso.
Claude Code ha ricostruito le relazioni tra più dataset, generato oltre 82.000 snapshot storici point-in-time, creato feature sul comportamento dei seller, controllato il future leakage e introdotto una rolling validation temporale con purge.
Ha quindi eseguito 46 esperimenti, confrontando reti neurali, CatBoost e modelli a due stadi.

Con circa il 38% dei casi a fatturato zero, il sistema migliore è risultato essere un modello two-stage: prima stima la probabilità che il seller venda nei successivi 30 giorni, poi prevede quanto fatturerà nel caso in cui venda.
Sul periodo futuro, mai utilizzato durante lo sviluppo, il modello ha ottenuto circa 961 BRL di RMSE, 365 BRL di MAE e un R² pari a 0,52.

Un risultato molto meno “perfetto” rispetto a quello ottenuto sul dataset sintetico, ma proprio per questo molto più interessante: si tratta di dati reali, rumorosi, sbilanciati e difficili.
L’agente ha inoltre individuato le aree in cui il modello funziona peggio, identificato le feature che influenzano maggiormente le previsioni, costruito intervalli di incertezza, dashboard, API e persino una simulazione dell’utilizzo del modello in produzione.

La parte che trovo più interessante, però, non è il singolo risultato. È il ciclo:
esperimento → misura → errore → ipotesi → nuovo test

Sono tutte attività che un ML Engineer può certamente svolgere, ma che richiedono una quantità enorme di tempo e attenzione.
Con una direzione umana forte, agenti come Claude Code CLI possono comprimere significativamente questo effort e permettere di esplorare molte più alternative.

L’obiettivo, quindi, non è sostituire il Machine Learning Engineer.
È amplificarlo.

Dario Amodei tra regolazione dell’AI, interessi di Anthropic e competizione globale

Dario Amodei ha pubblicato due post su X dedicati a regolazione dell’AI, concentrazione del potere, open weights e fiducia del pubblico.

La sua tesi è che una buona regolazione non debba proteggere i leader di mercato, ma rallentare soprattutto i laboratori di frontiera, lasciando più spazio ai challenger. Allo stesso tempo, sostiene che la fiducia nell’AI non si conquisti con il marketing, ma attraverso risultati concreti.

È una posizione coerente e convincente. Oggi, però, va letta anche alla luce della posizione di Anthropic.

L’azienda si prepara a una possibile IPO di grandi dimensioni e ha interesse a presentarsi come uno dei pochi operatori sufficientemente affidabili da gestire sistemi di AI avanzati. Dire che “servono regole severe anche per noi” può essere perfettamente sincero, ma produce anche un effetto strategico: rafforza l’idea che i modelli di frontiera debbano essere sottoposti a standard e test che le organizzazioni più capitalizzate sono in grado di affrontare meglio.

C’è poi il tema della Cina. Amodei sostiene che l’AI tenda a concentrare il potere perché le scaling laws premiano chi dispone di più capacità di calcolo e capitale, e che gli open weights attenuino solo in parte questo fenomeno.

Ma modelli come Kimi, DeepSeek e Qwen stanno mettendo questa tesi alla prova: maggiore efficienza, costi più bassi e open weights possono ridurre il vantaggio competitivo dei grandi laboratori statunitensi.

Regolamentare anche i modelli open quando si avvicinano alla frontiera ha quindi una doppia natura: può essere una misura di sicurezza sensata, ma coincide anche con l’interesse competitivo di Anthropic. I modelli cinesi, aperti ed economici, rappresentano infatti una minaccia concreta per i modelli proprietari occidentali.

Anche il discorso sul marketing contiene una tensione interessante. Amodei afferma di non voler fare promesse vuote e sostiene che il pubblico si fiderà dell’AI quando vedrà risultati reali. Allo stesso tempo, prevede che l’AI potrebbe contribuire a curare la maggior parte delle malattie nell’arco di 5-10 anni.

È, in altre parole, un anti-hype che contiene una previsione estremamente ambiziosa.

Non ne ricaverei che Amodei stia facendo lobbying travestito da filosofia. Le sue idee sulla sicurezza precedono l’eventuale IPO e mostrano una coerenza reale. Ma oggi convinzioni personali, interessi di Anthropic e politica industriale statunitense tendono inevitabilmente a sovrapporsi.

La parte più interessante è osservare come la sua filosofia stia diventando anche una strategia competitiva: i frontier models come categoria speciale, la regolazione come barriera ma anche come garanzia, la fiducia come vantaggio competitivo e gli open weights accettabili finché non diventano abbastanza potenti da modificare gli equilibri del mercato.

Anthropic e il TAM da 30.000 miliardi: la vera partita è la value capture

“Anthropic dirà agli investitori di vedere oltre 30.000 miliardi di dollari di ricavi potenziali”, titola il Wall Street Journal. Reuters rilancia: “Anthropic prevede oltre 30.000 miliardi di dollari di ricavi potenziali”.

Il numero è enorme, ma va interpretato correttamente: Anthropic non sta dicendo che realizzerà 30.000 miliardi di dollari di ricavi. Sta parlando di TAM, Total Addressable Market, cioè dell’opportunità teorica annua di ricavo nel caso in cui riuscisse a catturare il 100% del mercato indirizzabile.

La parte più interessante riguarda però il modo in cui questo mercato viene definito. Secondo Reuters, Anthropic considera le attività lavorative che potrebbero essere svolte dai modelli di intelligenza artificiale.
Il perimetro, quindi, assomiglia sempre più al mercato globale del lavoro cognitivo, non semplicemente a quello del software.

Se Claude può scrivere codice, fare ricerca, analizzare documenti, supportare clienti o automatizzare processi, il confronto non è più soltanto con quanto le aziende spendono in software, ma con quanto costa oggi svolgere quelle stesse attività.
Il confronto con i 28.500 miliardi di dollari di TAM indicati da SpaceX/xAI è interessante, ma solo fino a un certo punto. Siamo entrati nelle “TAM Olympics”: allargando sufficientemente il perimetro, è relativamente facile arrivare a numeri giganteschi.

La domanda importante, quindi, non è se il TAM sia di 20, 30 o 40 mila miliardi di dollari. È quale parte di questo mercato potrà realmente trasformarsi in ricavi per i provider di AI.
Anthropic stima circa 190-200 miliardi di dollari di ricavi nel 2028. Anche ipotizzando 200 miliardi, significherebbe catturare appena lo 0,7% di un TAM da 30.000 miliardi.
Sarebbe interessante vedere il dettaglio dei diversi revenue stream. La mia scommessa è che una quota enorme arriverà dall’Enterprise: coding, agenti, knowledge work e automazione dei workflow.

E OpenAI? Applicando la stessa logica potrebbe costruire un TAM ancora più ampio, includendo consumer, advertising, commerce, developer ecosystem e nuovi device.

Per questo il numero davvero importante non è il TAM. È la value capture: quanta parte del valore economico generato dall’AI finirà nelle mani dei model provider e, soprattutto, con quali margini.

La tesi implicita è molto più ambiziosa: Anthropic non sta pensando soltanto al mercato del software. Sta cercando di catturare una quota dell’economia globale del lavoro cognitivo.

GLM-5.3: il prossimo salto dell’AI potrebbe arrivare dal post-training

Mentre il Financial Times parla di Anthropic come candidata a una delle IPO più ambiziose della storia, Z.ai sta mostrando che la prossima battaglia dell’intelligenza artificiale potrebbe giocarsi altrove: non su modelli sempre più grandi, ma su quanto riesci a estrarre da quelli che hai già.

GLM-5.3 usa lo stesso base model di GLM-5.2. Il salto prestazionale arriva quasi interamente dal post-training. Ed è un salto notevole.

Nel benchmark interno Z.ai Code Bench passa dal 20,9% al 31,4%. Su Terminal-Bench 3.0 sale dal 4,6% al 28,3%. Su DeepSWE dal 46,2% al 66,9%. Su AutomationBench dal 26,2% al 48,2%.

Il punto, però, non è soltanto che il modello “scrive codice meglio”.

Z.ai sta addestrando il modello su traiettorie di lavoro molto più lunghe: analizzare repository, formulare ipotesi, usare strumenti, eseguire test, osservare i risultati, correggere gli errori e continuare fino alla soluzione. È il passaggio dal coding assistant all’agente software.
Ed è proprio qui che emerge uno degli aspetti più interessanti: la cybersecurity.

Secondo Z.ai, GLM-5.3 ha individuato 2.436 vulnerabilità in 269 progetti software durante i propri test. Su CyberGym raggiunge l’84,5%, mentre su ExploitBench passa dal 24,4% di GLM-5.2 al 54,4%.
Non perché sia stato costruito esclusivamente come modello cyber, ma perché un agente capace di comprendere sistemi software complessi, diagnosticarli e modificarli sviluppa naturalmente competenze molto vicine alla security. Questo è probabilmente il vero significato di GLM-5.3.

Il prossimo salto dell’AI potrebbe non richiedere necessariamente un nuovo pretraining gigantesco. Potrebbe arrivare da reinforcement learning più sofisticato, ambienti migliori, verifier più affidabili e da una quantità molto maggiore di compute investito nel post-training e nell’inferenza.

C’è però un prezzo: queste capacità richiedono traiettorie lunghe, molti token, numerose tool call e maggiore capacità computazionale.
E c’è anche un problema di sicurezza. Z.ai ha annunciato che i pesi di GLM-5.3 non verranno rilasciati immediatamente, ma soltanto dopo ulteriori valutazioni e attività di hardening, proprio a causa delle capacità cyber emerse durante l’addestramento.

Forse la competizione sui foundation model sta entrando in una nuova fase: meno ossessione per il modello base, più attenzione a ciò che accade dopo.

Qwen 3.8-Max: il nuovo modello di Alibaba per coding, automazione e lavoro professionale

Alibaba presenta Qwen 3.8-Max, il suo modello più avanzato, progettato per affrontare attività di coding, lavoro professionale e automazione di lungo periodo.

Il modello utilizza un’architettura da 2,4 trilioni di parametri, con 95 miliardi di parametri attivi. I pesi aperti di Qwen 3.8-Max saranno pubblicati prossimamente, insieme a quelli di Qwen 3.8-27B.

Tra le capacità evidenziate dal team Qwen c’è lo sviluppo software autonomo per oltre dieci giorni, partendo da una cartella vuota e procedendo attraverso cicli continui di implementazione, test e autocorrezione. Il modello è stato inoltre impiegato per produrre risultati professionali in settori come diritto, finanza, progettazione, ingegneria, sanità e analisi dei dati.

Qwen 3.8-Max è pensato anche per attività di lunga durata. Nei test presentati ha gestito oltre 500 iterazioni di ottimizzazione di un circuito hardware e una simulazione di gestione e-commerce estesa su 365 giorni, adattando progressivamente le proprie decisioni sulla base dei risultati ottenuti.

Un altro elemento centrale è l’intelligenza multimodale nativa. La visione non viene utilizzata soltanto per comprendere immagini, documenti e video, ma anche come sistema continuo di verifica durante l’esecuzione. Il modello può osservare i propri risultati intermedi, individuare errori e modificare autonomamente il piano di lavoro.

Qwen 3.8-Max viene descritto dal team come un agente capace di pianificare, utilizzare strumenti, coordinare sotto-agenti e correggere la propria strategia attraverso cicli di feedback.

Il modello è disponibile tramite Qwen Studio e QwenCloud. I prezzi API annunciati sono di 2 $ per milione di token in input e 6 $ per milione di token in output.

Grok 4.6 punta sugli agenti AI e sul rapporto prezzo/prestazioni

Grok 4.6 è il nuovo modello di xAI pensato soprattutto per i workload agentici: task lunghi, sviluppo software, ricerca, utilizzo di tool e creazione di applicazioni complete.

Rispetto a Grok 4.5, xAI dichiara una maggiore capacità di mantenere il contesto attraverso molti passaggi, verificare il proprio lavoro e iterare autonomamente su codice e interfacce.

La parte più interessante, però, è il posizionamento economico. Grok 4.6 parte da 2 dollari per milione di token in input e 6 dollari in output. Il costo dell’input è nella stessa fascia di modelli come Claude Sonnet 5 e Gemini 3.1 Pro, mentre quello dell’output è particolarmente aggressivo: Sonnet 5 costa 10 dollari, Gemini 3.1 Pro 12, Claude Opus 5 arriva a 25 e GPT-5.6 Sol a 30.

Nei coding agent, dove l’output può crescere rapidamente tra ragionamento, codice, tool call e revisioni, questa differenza può diventare significativa.

Interessanti anche i primi dati di Arena AI. In Code Arena: WebDev, Grok 4.6 High debutta in settima posizione con 1618 punti, rispetto alla tredicesima posizione e ai 1553 punti di Grok 4.5. Si trova praticamente nello stesso gruppo di GPT-5.6 Sol xHigh, sesto con 1622 punti, e Claude Fable 5, quinto con 1627.

Questo non significa che i modelli siano equivalenti in assoluto: Arena misura le preferenze tra gli output e la classifica può cambiare con l'aumentare dei voti. Il segnale, però, è rilevante: xAI sta cercando di offrire prestazioni da modello frontier con un'economia molto più vicina a quella dei modelli orientati al rapporto prezzo/prestazioni.

Alla fine, il parametro più utile non sarà il semplice costo per milione di token, ma il costo per task completato correttamente: quanti tentativi servono, quante correzioni sono necessarie e quanta autonomia reale riesce a mantenere l'agente.

Gemini Omni 1.1 Flash: la generazione video diventa più controllabile

Google ha annunciato Gemini Omni 1.1 Flash, un aggiornamento pensato per rendere la generazione video più controllabile, veloce e adatta a flussi di produzione reali.

Ho effettuato alcuni test utilizzando immagini di riferimento insieme a un prompt testuale.

Tra le novità più interessanti c’è la possibilità di estendere le scene fino a 40 secondi complessivi, mantenendo il contesto visivo dei segmenti precedenti.
È inoltre possibile controllare il primo e l’ultimo fotogramma, così da costruire con maggiore precisione transizioni, movimenti di camera e loop.

Per accelerare il processo creativo, Omni 1.1 Flash permette di generare rapidamente bozze a 360p, con costi inferiori, così da testare più varianti prima di passare al rendering finale. Una volta scelta la versione migliore, il video può essere prodotto in 1080p o 4K.
Il modello può anche utilizzare brevi video di riferimento per preservare elementi come movimento, stile, personaggi e contesto visivo. In questo modo il processo diventa meno dipendente dal singolo prompt e più vicino a un flusso di lavoro creativo strutturato.

L’approccio proposto da Google consiste infatti nel generare rapidamente diverse versioni, confrontarle, rifinire regia e transizioni e solo alla fine produrre l’output ad alta risoluzione.

La generazione video si sposta così dal semplice schema “prompt → video” verso uno strumento più vicino a una regia programmabile, con maggiore controllo su continuità, camera, riferimenti e iterazioni creative.
Google cita già integrazioni e utilizzi con Adobe Firefly, Figma Weave, GMI Cloud e Runway.

OpenAI introduce le immagini con sfondo trasparente in GPT Image 2

OpenAI introduce la possibilità di generare immagini con sfondo trasparente attraverso GPT Image 2.

Le immagini che ho condiviso sui social sono frutto dei miei test: il risultato è ottimo e trovo questa funzionalità particolarmente interessante e, soprattutto, utile.
La novità permette di creare direttamente asset PNG con alpha channel, senza dover prima generare un’immagine tradizionale e rimuovere lo sfondo in un secondo momento.

È un cambiamento particolarmente utile per i workflow di design, marketing e presentazioni, perché consente di ottenere elementi grafici già pronti per essere sovrapposti a sfondi, layout e template differenti.

Tra i casi d’uso mostrati da OpenAI ci sono prodotti e-commerce riutilizzabili in campagne stagionali, grafici da inserire in presentazioni aziendali, icone e sticker per template di design e illustrazioni destinate al print-on-demand.
Il vantaggio è evidente soprattutto quando il soggetto contiene dettagli difficili da scontornare, come vetro, nastri, fibre sottili o bordi complessi. Generare direttamente la trasparenza può ridurre aloni, ritagli imprecisi e interventi manuali di post-produzione.

Dal punto di vista tecnico, è possibile richiedere un output PNG con background="transparent". Il prompt resta però determinante: conviene descrivere il soggetto come un elemento isolato ed evitare richieste che introducano scene, pannelli, fondali o cornici.

OpenAI suggerisce inoltre di verificare programmaticamente che l’immagine contenga realmente un alpha channel e di introdurre controlli di qualità su trasparenza, bordi, coerenza visiva e correttezza dei contenuti.

Ho effettuato personalmente questa verifica tramite Python e il risultato è stato perfetto.

Il punto più interessante è il cambio di prospettiva: l’immagine generata dall’AI non è più soltanto un output finale, ma diventa un vero asset grafico modulare e riutilizzabile, pronto per essere integrato all’interno di workflow automatizzati.

FLUX Upscale porta i video fino al 4K con la super-resolution generativa

Black Forest Labs ha presentato FLUX Upscale, uno strumento pensato per portare video generati o esistenti fino al 4K, intervenendo non solo sulla risoluzione, ma anche sugli artefatti tipici dei video generati con l’AI.

Accetta input a partire da 480p e offre fattori di upscale di 1,5×, 2× e 3×. Il sistema è ottimizzato in particolare per gli output di FLUX 3 e cerca di correggere problemi come volti impastati, texture a griglia e artefatti su elementi complessi, ad esempio acqua ed erba.

Sono disponibili due modalità. Precise utilizza 4 step, costa 0,07 dollari per megapixel al secondo ed è pensata per preservare maggiormente identità e dettagli originali. Creative utilizza invece 8 step, costa 0,10 dollari per megapixel al secondo e interviene in modo più aggressivo nella ricostruzione dei dettagli, con un rischio maggiore di modificare alcuni elementi del video.
FLUX Upscale è disponibile come tool standalone, tramite API BFL e nel playground.

Più che un semplice ridimensionamento, il sistema si avvicina a un processo di super-resolution generativa con componenti di restauro. L’obiettivo è rendere utilizzabili in contesti ad alta risoluzione video generati inizialmente a dimensioni più contenute.

DeepSeek Harness: un’architettura modulare per costruire agenti AI

Oltre a lanciare V4-Pro, DeepSeek ha rilasciato DeepSeek Harness v0.1, un’infrastruttura open source pensata per chi costruisce agenti AI.

Il progetto, distribuito con licenza MIT, parte da un’idea molto precisa: “Everything is a plugin”.

GitHub - deepseek-ai/deepseek-harness: DeepSeek Harness: Everything is a Plugin.

DeepSeek Harness: Everything is a Plugin. Contribute to deepseek-ai/deepseek-harness development by creating an account on GitHub.

GitHubdeepseek-ai

In DeepSeek Harness praticamente ogni componente dell’agente viene trattato come un modulo sostituibile: modelli, tool, skill, sessioni, sandbox, filesystem, agent loop, orchestrazione e interfaccia utente.
Questo significa che l’harness non impone necessariamente uno stack rigido. In teoria è possibile utilizzare DeepSeek come modello, una sandbox Docker, un filesystem remoto e una determinata UI, per poi sostituire uno di questi elementi senza dover riprogettare l’intera architettura.

Alla base c’è Cordis, il meta-framework utilizzato per gestire la composizione dei plugin, le loro dipendenze e il loro ciclo di vita.
Un’altra scelta interessante riguarda le sessioni: l’attività dell’agente viene rappresentata come un log di eventi append-only. Messaggi, chiamate ai tool, risultati, step e turni diventano eventi che possono essere registrati e ricostruiti, con vantaggi in termini di debugging, persistenza, replay e auditabilità.

Il punto, quindi, non è semplicemente che DeepSeek abbia pubblicato un altro framework per agenti. Con Harness sta proponendo un’architettura in cui anche parti normalmente considerate core, come l’agent loop, il modello, il sistema di tool o la sandbox, diventano componenti intercambiabili.

L’open source e la licenza MIT rendono inoltre possibile la nascita di un ecosistema di plugin sviluppati da terze parti.

È un approccio che sposta l’attenzione dal singolo agente all’infrastruttura con cui gli agenti vengono costruiti, eseguiti e modificati.

Kimi Agent Swarm: orchestrare decine di agenti per affrontare ricerche complesse

Ho testato Kimi Agent Swarm in modo approfondito e lo trovo uno strumento straordinario per le elaborazioni su larga scala, soprattutto quando un problema può essere scomposto in molte attività indipendenti che devono poi essere ricomposte in un risultato coerente.

Un esempio concreto è la costruzione di un osservatorio sull’ecosistema mondiale degli AI Agent, affidando al sistema attività di ricerca, verifica delle fonti, classificazione, scoring, ranking, analisi delle contraddizioni, audit dei dati e produzione finale di diversi artefatti, tra cui dataset, PDF e un sito web navigabile.

Il risultato finale comprende 225 prodotti e progetti analizzati, 693 fonti e 127 contraddizioni documentate, oltre a metriche di qualità, grafici, matrici comparative e un red-team audit su 50 record.

La parte più interessante, però, è osservare come lavora Kimi Agent Swarm.

Il modello parte con una fase di reasoning, durante la quale scompone il problema e decide quali attività possono essere eseguite in parallelo. A quel punto crea diversi sub-agenti specializzati, che lavorano contemporaneamente utilizzando strumenti come ricerca web, terminale, API e codice.
Quando un gruppo di agenti termina il proprio lavoro, il sistema raccoglie i risultati, esegue un nuovo passaggio di reasoning, individua ciò che manca o ciò che deve essere verificato e avvia una nuova ondata di sub-agenti.
Il processo continua così per più cicli: decomposizione, esecuzione parallela, consolidamento e nuova decomposizione.

Kimi Agent Swarm, basato su K3, è quindi qualcosa di diverso dal semplice “far rispondere più agenti alla stessa domanda”. È un vero e proprio sistema di orchestrazione, nel quale un modello centrale crea e coordina dinamicamente una squadra di agenti e decide come distribuire il lavoro durante l’esecuzione.

In questo test il sistema ha lavorato per circa tre ore.

Il risultato non è perfetto — e, su un progetto di questa scala, sarebbe sorprendente il contrario — ma la capacità di gestire una ricerca così ampia, produrre artefatti differenti e soprattutto tornare sui propri risultati attraverso ulteriori cicli di verifica è l’aspetto che mi ha colpito di più.

Kimi K3: dalla generazione di codice alla creazione di applicazioni complete

Ho fatto qualche test con Kimi K3 nello sviluppo di semplici applicazioni pratiche e la prima impressione è stata ottima, soprattutto per la capacità di trasformare richieste abbastanza generiche in strumenti completi e realmente utilizzabili.

Un esempio è un’applicazione per lavorare con i PDF direttamente dal browser. Nel prompt avevo chiesto di poter caricare un documento, scegliere una pagina, convertirla in immagine, ritagliarla, aggiungere frecce, riquadri e testi ed esportare il risultato.

Il modello ha realizzato PDF Studio, andando parecchio oltre la richiesta iniziale. Ha costruito un’interfaccia completa con miniature delle pagine, toolbar per l’editing, pannello delle proprietà e strumenti di esportazione.

Ha aggiunto autonomamente anche funzioni per unire PDF, estrarre o dividere pagine, recuperare il testo dal documento, esportare più pagine in ZIP e creare PDF annotati. Sono presenti inoltre strumenti come penna ed evidenziatore, undo e redo, gestione delle annotazioni, rotazione delle pagine e scorciatoie da tastiera.

La parte più interessante dei test, però, non è tanto questa specifica applicazione quanto il processo di sviluppo. Il modello interpreta i requisiti, progetta l’interfaccia, scrive diversi componenti ed esegue cicli di test e correzione, fino alle verifiche finali di funzionamento.

Ho eseguito test simili anche con altri modelli e, tra quelli provati finora, Kimi K3 ha prodotto uno dei risultati più completi, rifiniti e soprattutto funzionanti già dalla prima esecuzione.

PDF Studio è solo un esempio, ma rende bene l’idea di quanto questi modelli stiano rapidamente passando dalla semplice generazione di codice alla costruzione di piccole applicazioni complete.

Kimi Linear: meno full attention, più efficienza senza perdere qualità

Il paper su Kimi Linear è interessante perché mette in discussione un’assunzione diventata quasi standard negli LLM: per ottenere la massima qualità non è necessariamente utile utilizzare la full attention in ogni layer.

La full attention è molto espressiva, ma sui contesti lunghi diventa costosa: il calcolo cresce rapidamente e la KV cache aumenta con la lunghezza della sequenza. Le architetture di linear attention cercano da tempo di risolvere il problema comprimendo il passato in uno stato di memoria compatto, ma storicamente hanno pagato questa efficienza con performance peggiori, soprattutto nel retrieval preciso.

Kimi Linear prova a superare questo compromesso attraverso un’architettura ibrida.

Tre layer su quattro utilizzano Kimi Delta Attention (KDA), mentre uno utilizza full attention MLA. KDA deriva da Gated DeltaNet, ma introduce un meccanismo di forgetting molto più fine: ogni dimensione della memoria può avere un proprio tasso di decadimento. In pratica, il modello può controllare meglio cosa conservare, aggiornare o dimenticare.
Il risultato più interessante è che il guadagno di efficienza non sembra richiedere un sacrificio evidente in termini di qualità.

Nei confronti controllati, i modelli hanno la stessa scala (48 miliardi di parametri totali e 3 miliardi attivati) e vengono addestrati con la stessa ricetta su 1,4 trilioni di token. Kimi Linear supera mediamente la baseline full-attention sia nei benchmark short-context sia in quelli long-context, mostrando anche una dinamica migliore durante il reinforcement learning matematico.
Sul lungo contesto, il vantaggio hardware diventa particolarmente rilevante: fino al 75% in meno di KV cache e, a 1 milione di token, fino a 6,3× di throughput nel decoding nelle configurazioni che sfruttano un batching più ampio.
Nel test con batch size 1 il vantaggio è più contenuto, circa 2,2× nel decoding. Il dato del “6×”, quindi, va interpretato soprattutto come un vantaggio in termini di throughput e capacità complessiva del sistema.

Il punto centrale non è che la full attention sia stata eliminata: non lo è. Il paper suggerisce invece che potrebbe essere inutile sostenerne il costo in ogni layer.

Una memoria ricorrente molto più economica nel 75% della rete, combinata periodicamente con attenzione globale, può offrire un rapporto migliore tra qualità, memoria e velocità.

Anthropic e il watermark di Claude: trasparenza reale o adempimento formale?

Anthropic presenta un sistema per riconoscere i contenuti generati o modificati con Claude. Ma si tratta di una soluzione davvero efficace o soprattutto di un modo per dimostrare di aver fatto la propria parte sul fronte della trasparenza richiesta dall’AI Act?

Si tratta di sistemi di marcatura dei contenuti prodotti o elaborati da Claude.

How Claude marks AI-generated content | Anthropic Help Center

Anthropic Help Center

Per il testo viene utilizzato un watermark invisibile, pensato per sopravvivere alle modifiche. Per file come immagini PNG, JPG e SVG, invece, possono essere incorporati metadati di provenienza firmati secondo lo standard C2PA.
L’obiettivo è lasciare una traccia del passaggio di un contenuto attraverso Claude e, in prospettiva, permettere a utenti e terze parti di verificare la presenza di queste marcature.

Il punto, però, è che la stessa Anthropic riconosce limiti piuttosto importanti.
Una marcatura positiva non dimostra necessariamente che Claude abbia creato il contenuto: potrebbe averlo soltanto corretto, tradotto, riassunto o modificato.
Allo stesso modo, l’assenza di una marcatura non dimostra che il contenuto sia stato prodotto da una persona. Il watermark può degradarsi dopo modifiche sostanziali, parafrasi o traduzioni, mentre i metadati possono sparire in seguito a conversioni di formato, screenshot o rimozioni intenzionali.

Per questo il sistema sembra molto più solido come strumento di provenienza che come vero metodo forense. Ed è qui che nasce la provocazione.

Implementare watermark, metadati e strumenti di verifica permette di dimostrare concretamente di aver adottato misure di trasparenza. Ma senza dati pubblici su falsi positivi, falsi negativi, resistenza alle riscritture, alle traduzioni e alle manipolazioni, è difficile valutare quanto questo sistema sia davvero efficace nel riconoscere i contenuti generati dall’AI.

Più che un detector affidabile, oggi sembra quindi un’infrastruttura di provenienza con limiti ben definiti: utile, ma molto meno definitiva di quanto possa suggerire l’idea di “riconoscere i contenuti generati dall’AI”.

Meta AI: gli output iniziano a diventare davvero interessanti

Con i nuovi modelli di testo e immagini appena rilasciati, gli output di Meta AI iniziano a diventare davvero interessanti.

Ho testato l’agente dedicato agli artefatti, utilizzando un prompt per creare una presentazione che spiegasse in modo semplice cosa sono le reti neurali artificiali, fornendo anche il contesto necessario.

Avevo fatto lo stesso test diverso tempo fa, ottenendo un output praticamente inutilizzabile. Oggi siamo a un livello nettamente superiore: il risultato rappresenta già una buona base di partenza su cui lavorare per arrivare alla presentazione finale.

Il tutto è modificabile direttamente dall’interfaccia ed esportabile in PPTX oppure direttamente in Google Presentazioni.

Muse Spark 1.2: la multimodalità passa dalla comprensione all’azione

I modelli di Meta crescono: l’aggiornamento Muse Spark 1.2 introduce nuovi progressi nell’intelligenza multimodale, con particolare attenzione alla capacità di comprendere immagini, video, audio e testo e trasformare queste informazioni in azioni concrete.

Uno degli aspetti più interessanti riguarda il visual coding. Muse Spark 1.2 può partire da un’immagine o da un video, comprenderne struttura, layout e stile e ricostruirli sotto forma di codice funzionante. Può quindi generare pagine web, interfacce o esperienze interattive, verificare il risultato e correggerlo in modo iterativo.

La multimodalità viene applicata anche alla robotica. Una versione specializzata del modello può interpretare l’ambiente, distinguere oggetti simili, scomporre un obiettivo complesso in attività più semplici e coordinare modelli che eseguono fisicamente le azioni. Meta mostra esempi che vanno dall’organizzazione di oggetti alla preparazione di un pranzo.

Sul fronte audio-video, Muse Spark 1.2 combina comprensione dei contenuti, descrizioni dettagliate e utilizzo di strumenti esterni. Il passaggio rilevante è proprio questo: non limitarsi a riconoscere ciò che accade in un video, ma utilizzare quelle informazioni per costruire workflow, generare contenuti o svolgere attività.

Meta introduce anche WildArtifactBench, un benchmark pensato per valutare agenti multimodali in scenari reali, dove spesso non esiste una singola risposta corretta. I risultati vengono confrontati attraverso win rate ed Elo, utilizzando sia valutazioni automatiche sia giudizi umani.

Muse Spark viene già utilizzato internamente da Meta anche per la generazione di contenuti multimediali, insieme a Muse Image e Muse Video.

La multimodalità sta quindi passando dalla semplice capacità di “vedere e capire” a quella di percepire, ragionare, utilizzare strumenti e produrre un risultato concreto.

Gemini Robotics 2: l’intelligenza artificiale entra nel mondo fisico

Google DeepMind ha presentato Gemini Robotics 2, una nuova generazione di modelli progettata per rendere i robot più autonomi, adattabili e capaci di operare in ambienti reali.

La novità principale è il controllo intelligente dell’intero corpo: un robot umanoide può camminare, piegarsi, mantenere l’equilibrio, afferrare oggetti e collocarli con precisione, coordinando movimenti che coinvolgono gambe, braccia, mani e dita.

Il sistema si basa su tre componenti:

1. Gemini Robotics 2 traduce immagini e istruzioni linguistiche in azioni motorie, controllando robot umanoidi e piattaforme a due bracci.
2. Gemini Robotics ER 2 gestisce il ragionamento ad alto livello: osserva l’ambiente, pianifica attività articolate, comunica con le persone, verifica i risultati e corregge eventuali errori.
3. Gemini Robotics On-Device 2 funziona direttamente sull’hardware, riducendo la dipendenza dalla rete e la latenza. Può inoltre essere adattato a robot con forme, sensori e gradi di libertà differenti utilizzando poche ore di dati e, generalmente, meno di 200 esempi.

Migliora anche la destrezza. I robot possono controllare mani a cinque dita per svolgere azioni delicate, come annodare fili o chiudere sacchetti, e utilizzare pinze a due dita per compiti di manipolazione e imballaggio di precisione.
Un altro progresso riguarda la collaborazione tra robot. Sistemi diversi possono comunicare, coordinarsi e suddividere attività complesse, eseguendo sequenze della durata di diversi minuti e gestendo centinaia di decisioni.

Sul fronte della sicurezza, DeepMind introduce ASIMOV-Agentic, un benchmark che valuta la capacità dei robot di rifiutare azioni pericolose, riconoscere situazioni di incertezza, richiedere l’intervento umano e fermarsi quando una persona si avvicina troppo.

Gemini Robotics 2 rappresenta quindi un passo verso un’intelligenza artificiale fisica generalista, capace di integrare percezione, linguaggio, ragionamento, movimento e collaborazione all’interno di robot progettati per lavorare accanto alle persone.

Jalapeño: il primo chip custom di OpenAI per l’inferenza AI

OpenAI ha presentato i primi risultati di Jalapeño, il suo primo chip custom progettato specificamente per l’inferenza AI.

L’obiettivo non è semplicemente realizzare un acceleratore più veloce, ma ottimizzare insieme chip, memoria, networking, software e sistemi rack-scale per i carichi di lavoro dei moderni modelli linguistici.

Nei benchmark citati da OpenAI su GPT-OSS 120B, DeepSeek R1 e Kimi K2.5, Jalapeño mostra fino a 1,5–1,9 volte più lavoro AI per watt al picco di throughput e una latenza end-to-end da 1,7 a 3,6 volte inferiore rispetto ai sistemi di confronto. Nei workload più interattivi, il vantaggio prestazionale arriva fino a 4,1 volte.

Una parte importante di questi risultati deriva dalla riduzione degli spostamenti di dati e dalla gestione locale di elementi come la KV cache, con benefici sia nella fase di prefill sia nel decode token per token.
Interessante anche il processo di sviluppo: OpenAI afferma di essere passata dal design iniziale al tapeout in nove mesi, utilizzando modelli AI per esplorare diverse implementazioni, verificare il progetto e ottimizzare i circuiti.

Codex e Astra sono stati poi utilizzati per adattare modelli open-weight all’hardware. In alcuni blocchi specifici di GPT-OSS, le implementazioni generate dall’AI sono risultate 1,5–1,8 volte più veloci di quelle sviluppate da esperti umani.
Jalapeño rappresenta quindi soprattutto un segnale strategico: OpenAI vuole integrare sempre di più modelli, software e infrastruttura hardware per ridurre costi e latenza dell’inferenza e aumentare la quantità di calcolo ottenibile a parità di energia.

Il deployment nella propria infrastruttura è previsto entro la fine del 2026, mentre una seconda generazione è già in fase avanzata di sviluppo e una terza generazione è in fase di progettazione.

WikiSkill: quando l’esperienza degli agenti AI diventa conoscenza

Google Research ha pubblicato un paper interessante su come gli agenti AI possano migliorare nel tempo senza limitarsi a riscrivere continuamente le proprie istruzioni.

Il framework si chiama WikiSkill e parte da un’idea precisa: l’esperienza accumulata durante l’esecuzione dei task non dovrebbe restare dispersa nei log né essere trasformata immediatamente in nuove skill. Dovrebbe prima diventare conoscenza persistente e strutturata.

WikiSkill separa quindi tre elementi: l’esperienza grezza dell’agente, la conoscenza accumulata e le skill operative. Le traiettorie complete vengono conservate, gli errori ricorrenti e le strategie efficaci vengono consolidati in una wiki persistente e, a partire da questa base, vengono proposte nuove modifiche alle skill.

Il ciclo è continuo: l’agente esegue i task, un componente analizza le traiettorie e aggiorna la wiki, un altro propone modifiche alle skill e un sistema di validazione decide se accettarle o effettuare un rollback. Una skill può essere scartata, mentre la conoscenza accumulata nella wiki rimane.

I risultati riportati su cinque benchmark e diversi modelli Qwen, Gemma e Gemini mostrano che WikiSkill supera in media i precedenti metodi di skill evolution e migliora quasi sempre le prestazioni rispetto all’assenza di skill.
Un dato particolarmente interessante riguarda la scala dei modelli: nella famiglia Qwen, il miglioramento medio ottenuto con WikiSkill cresce da +12,3 punti sul modello 4B a +23,9 punti sul 27B. Allo stesso tempo, un Qwen 9B con skill evolute raggiunge il 47,4%, superando il Qwen 27B senza skill, fermo al 39,4%.

Le skill risultano inoltre trasferibili tra modelli e, in alcuni casi, una skill sviluppata da un altro modello funziona meglio di quella auto-evoluta. Questo suggerisce una distinzione importante tra scoprire una buona procedura e avere la capacità di eseguirla bene.

Il punto centrale del paper è quindi questo: per costruire agenti che migliorano nel tempo, potrebbe non bastare accumulare più contesto o aggiornare continuamente le istruzioni.

Serve una memoria intermedia capace di trasformare l’esperienza in conoscenza riutilizzabile, dalla quale far evolvere procedure sempre più efficaci.

I limiti teorici del dense retrieval: perché il single-vector non basta sempre

Un paper di Google DeepMind, “On the Theoretical Limitations of Embedding-Based Retrieval”, pubblicato a ICLR 2026, mette in discussione un’idea che spesso diamo per scontata: che basti migliorare i modelli per rendere il dense retrieval sempre più preciso.

Gli autori mostrano che esiste un limite più profondo. Se rappresentiamo ogni documento con un solo vettore e utilizziamo una funzione di similarità per recuperare i risultati, a una dimensione fissata esistono combinazioni di documenti rilevanti che quel sistema non può rappresentare correttamente.

Non è quindi solo un problema di training, dati o qualità del modello: è un limite della rappresentazione single-vector.

Per dimostrarlo, gli autori costruiscono LIMIT, un dataset con query molto semplici, come “chi ama le mele?”, e documenti altrettanto semplici. Eppure molti embedding model state of the art faticano, mentre architetture più espressive, come multi-vector e cross-encoder, ottengono risultati migliori.

Questo si collega bene al sistema che avevo descritto nel mio articolo sul motore di discovery, basato su bi-encoder per massimizzare il recall e cross-encoder per aumentare la precisione.

Feed, contenuti, intelligenza: il nuovo motore della discovery

Una condivisione dei 3 studi più interessanti che mi hanno accompagnato nel 2025. Un viaggio tra dati, AI e automazioni che stanno ridefinendo il motore della discovery.

Alessio PomaroAlessio Pomaro

Il bi-encoder serve a cercare velocemente all’interno di un corpus enorme. Query e documento vengono trasformati separatamente in embedding, così i documenti possono essere pre-calcolati e indicizzati.
Il cross-encoder interviene invece in una fase successiva: prende query e documento insieme e valuta la rilevanza con molta più espressività, ma a un costo computazionale troppo elevato per essere utilizzato direttamente su milioni di contenuti.

Il paper aggiunge però una precisazione importante: il bi-encoder non è semplicemente meno preciso. In alcuni casi può essere proprio meno espressivo.
Questo cambia il modo in cui conviene interpretarne il ruolo: non come giudice finale della rilevanza, ma come candidate generator. Il suo obiettivo principale diventa quindi non perdere i documenti giusti.
Qui entra in gioco il multi-vector. Invece di comprimere un intero contenuto in un solo punto dello spazio vettoriale, lo rappresenta attraverso più vettori, preservando meglio i diversi aspetti del testo. È più costoso del single-vector, ma anche più espressivo e comunque indicizzabile.

La pipeline può quindi evolvere da un semplice single-vector seguito da cross-encoder a una candidate generation più ricca, che combina dense retrieval, sparse retrieval e multi-vector, lasciando poi al cross-encoder il ranking finale.

Il punto non è abbandonare gli embedding. È usarli per ciò che sanno fare meglio: ridurre rapidamente lo spazio di ricerca, lasciando a modelli più espressivi il compito di decidere davvero che cosa è rilevante.

GlucoFM: il foundation model di Google Research per interpretare le dinamiche del glucosio

Google Research ha presentato GlucoFM, un foundation model progettato per interpretare i dati dei sensori di monitoraggio continuo del glucosio (CGM).

Il modello separa il segnale glicemico in due componenti: una più lenta, legata allo stato metabolico di fondo, e una più rapida, associata a eventi come pasti, attività fisica o variazioni improvvise. Questo approccio consente di rappresentare meglio la dinamica del glucosio nel tempo.

GlucoFM è stato pre-addestrato in modalità self-supervised su circa 109.000 ore di dati CGM, imparando a ricostruire porzioni mancanti del segnale e a prevederne l’evoluzione senza richiedere grandi quantità di dati clinici etichettati.

Nei test condotti su diverse coorti, il modello ha mostrato risultati migliori rispetto ai principali baseline in compiti come la stima del rischio di diabete, dell’insulino-resistenza, della disfunzione delle cellule beta, dell’ipoglicemia, dell’obesità e di altri indicatori metabolici.
Un aspetto particolarmente interessante è la capacità di mantenere buone prestazioni anche quando viene applicato a popolazioni diverse da quelle utilizzate per l’addestramento e quando sono disponibili pochi dati clinici etichettati.

GlucoFM è stato inoltre utilizzato per prevedere la risposta glicemica nelle due ore successive a un pasto, combinando i dati CGM con informazioni nutrizionali e caratteristiche individuali.

L’obiettivo non è soltanto prevedere il prossimo valore di glucosio, ma costruire una rappresentazione generale delle dinamiche metaboliche: una sorta di “impronta metabolica” riutilizzabile per diversi compiti clinici.

I risultati sono promettenti, ma il modello rimane ancora uno strumento di ricerca e non un sistema diagnostico. I prossimi sviluppi riguarderanno dataset più ampi e diversificati e l’analisi di periodi più lunghi, estesi a settimane o mesi.

AlphaEvolve contribuisce a un nuovo record nella moltiplicazione di matrici

Google DeepMind e AlphaEvolve hanno contribuito a stabilire un nuovo record teorico sulla complessità della moltiplicazione di matrici.

Moltiplicare matrici è una delle operazioni fondamentali dell’informatica: è alla base del machine learning, della grafica, delle simulazioni scientifiche e di moltissimi calcoli ad alte prestazioni. Il problema è che, per matrici molto grandi, il numero di operazioni necessarie cresce rapidamente.

Da decenni i ricercatori cercano di capire quanto velocemente sia possibile eseguire questa operazione in teoria. Questo limite viene descritto da un valore chiamato omega (ω): più è basso, migliore è l’algoritmo teoricamente possibile.

Il precedente record era ω < 2,371339. Il nuovo lavoro porta il limite a ω < 2,371177.

Il risultato, però, non nasce da AlphaEvolve da solo. I ricercatori hanno prima riformulato un enorme problema di ottimizzazione matematica utilizzando tecniche moderne di machine learning, gradient descent, JAX e GPU, passando da circa 25.000 a quasi 7 milioni di parametri. AlphaEvolve ha poi modificato ed evoluto il programma di ottimizzazione, riuscendo a migliorare ulteriormente il risultato.

Questo non significa che da domani l’AI o i videogiochi diventeranno improvvisamente più veloci: si tratta di un avanzamento nella teoria degli algoritmi, non di un nuovo metodo già pronto per l’utilizzo quotidiano.

Il potenziale, però, è enorme. La moltiplicazione di matrici è un mattone fondamentale di moltissimi sistemi computazionali: capire come ridurne il costo significa, nel lungo periodo, aprire la strada a calcoli più efficienti, modelli più grandi, simulazioni più complesse e un utilizzo migliore dell’hardware.

E forse l’aspetto più interessante è un altro: in questo caso l’AI non si è limitata a eseguire un algoritmo, ma ha contribuito a migliorare il programma utilizzato per esplorare uno spazio matematico che, fino a poco tempo fa, era troppo grande per essere affrontato efficacemente.

Scegli questo sito web come fonte preferita

Ricevi più facilmente questi contenuti tra i risultati di Google.

Potrai modificare questa preferenza in qualsiasi momento dalle impostazioni di Google.