Daniel Reyes, YuSMP Group
Daniel Reyes Principal Engineer (AI/ML), YuSMP Group · Agenti IA e sistemi LLM applicati per team statunitensi ed europei
Illustrazione isometrica di un nucleo IA luminoso bloccato dietro una barriera a strisce mentre due pod gareggiano avanti su piste di luce ambra e blu, su sfondo blu notte

La risposta breve

Il modello di punta di Google, Gemini 3.5 Pro, è in ritardo di mesi perché le sue prestazioni nel coding non hanno superato la soglia interna dell'azienda, secondo un rapporto di Bloomberg del 16 luglio 2026. Presentato al Google I/O di maggio con un rilascio più ampio previsto a giugno, il tier Pro è ancora in test con i partner; un tentativo di fine giugno di colmare il divario aggiornando i dati di addestramento avrebbe deluso le aspettative. Le azioni di Alphabet sono scese di circa il 4% alla notizia, perdendo circa 200 miliardi di dollari in una sola seduta.

Per i team che sviluppano prodotti o scrivono codice con l'IA, la lezione non è “evitate Gemini.” È che le date della roadmap di un singolo lab non sono garanzie di consegna, e la qualità del coding ora muove i mercati. I team che rimangono calmi in questi frangenti sono quelli che già instradano il lavoro attraverso un livello model-agnostic e valutano i modelli sui propri task specifici — così un rilascio posticipato è un non-evento, non una revisione dei piani.

Cosa ha effettivamente ritardato Google?

Google ha presentato la famiglia Gemini 3.5 alla sua conferenza per sviluppatori I/O a maggio 2026. In quella sede l'azienda aveva dichiarato che il tier Pro di punta era in uso interno e che un rollout più ampio sarebbe seguito il mese successivo. Giugno è passato senza che ciò accadesse. Il 16 luglio Bloomberg ha riportato — citando persone informate sui fatti — che il modello è ora in ritardo di diversi mesi, specificamente perché le sue capacità, e il coding in particolare, non hanno superato le aspettative interne di Google.

Il dettaglio temporale è rilevante. A fine giugno, secondo le fonti, Google ha aggiornato i dati usati per addestrare il modello nel tentativo di colmare il divario con i concorrenti, ma i risultati sono rimasti al di sotto delle aspettative. Si tratta di un problema diverso da un ordinario ritardo tecnico: suggerisce che la capacità in sé non è ancora dove Google vuole, non che una checklist di lancio sia incompleta. Google non ha contestato la sostanza. Un portavoce ha dichiarato a Reuters che l'azienda sta “attualmente testando 3.5 Pro, un modello Flash aggiornato e altri modelli con i partner,” e ha inquadrato la propria strategia come “spedire rapidamente su un'ampia gamma di modelli mantenendoli altamente cost-effective.” Per i team i cui prodotti si appoggiano all'IA applicata, ML e dati, il messaggio è che “annunciato” e “generalmente disponibile” sono ora separati da un divario che non si può pianificare con precisione.

Due cose non sono interessate dal ritardo. Gemini 3.5 Flash e Flash-Lite sono già stati rilasciati, e il Pro della generazione precedente rimane disponibile. Se utilizzi Gemini tramite Vertex AI, i tuoi carichi di lavoro attivi continuano a girare sui modelli odierni; ciò che è slittato è il prossimo passo di capacità, non il servizio in sé.

Perché un deficit di coding muove il mercato?

Una caduta del 4% in una sola seduta — circa 200 miliardi di capitalizzazione — è una reazione imponente per un modello posticipato che pochi clienti avevano ancora utilizzato. Ha senso se si considera cosa il mercato sta effettivamente prezzando: il coding è diventato il proxy del progresso di frontiera. Nell'ultimo anno i modelli che hanno guadagnato terreno lo hanno fatto sulla generazione di software e sui flussi di lavoro agentici, con i concorrenti che hanno dettato il ritmo. OpenAI ha rilasciato GPT-5.6 il 9 luglio con un prodotto orientato al lavoro, e Meta ha lanciato nuovi modelli propri; entrambi sono stati letti come superiori alla linea attuale di Google sul codice. Un modello Google che non supera il proprio bar interno sul coding viene interpretato dagli investitori come terreno perso nell'unico benchmark che oggi conta di più.

C'è anche un segnale concreto per i responsabili tecnici. Quando un lab con le risorse di Google sceglie di trattenere un modello di punta invece di rilasciarlo, è il lab stesso che ti sta dicendo che i suoi eval interni non erano convincenti. Vale più di qualsiasi leaderboard: è un promemoria che i punteggi dei benchmark e la qualità reale del coding divergono, e che l'entità più vicina al modello ha preferito fidarsi dei propri eval privati alla pressione del lancio. Il tuo team dovrebbe applicare la stessa disciplina in piccolo: fidati delle valutazioni eseguite sul tuo codice, non dei numeri in un comunicato stampa.

Quale rischio emerge nel tuo stack?

Il rischio concreto è l'accoppiamento con la timeline del vendor. Se una funzionalità nella tua roadmap presuppone che “il prossimo Gemini gestirà questo,” o se il tuo tooling per sviluppatori si è standardizzato sull'assistente di un unico vendor, un ritardo come questo ricade direttamente sul tuo piano di consegna. Erediti un calendario che non controlli, fissato da un lab che ottimizza per la propria posizione competitiva, non per la tua data di rilascio.

Il secondo rischio è la concentrazione su un singolo provider in modo più ampio. Non è un problema esclusivo di Google — nello stesso mese i team hanno assistito a variazioni di prezzo e gap di disponibilità regionale da altri lab. Qualsiasi architettura in grado di chiamare solo l'API di un fornitore è esposta contemporaneamente ai suoi ritardi, variazioni di prezzo, rate limit, deprecazioni e vincoli di residenza dei dati. Per i team regolamentati nel FinTech e nell'healthcare, l'aspetto della residenza e della compliance è il più critico: “passeremo al modello conforme quando sarà rilasciato” non è un piano se il cambio implica una nuova integrazione completa.

Il terzo rischio, più silenzioso, è il debito di valutazione. I team che adottano un modello sulla base del suo annuncio — invece di un harness di test sui propri task — non hanno un modo oggettivo per stabilire se un modello posticipato o sostituito li aiuti davvero. Senza eval propri, si sta esternalizzando a una timeline di marketing del vendor una decisione di build-or-buy.

Cosa significa per i team software italiani

Nulla di tutto questo richiede una modifica d'emergenza a un sistema funzionante. I modelli rilasciati di Gemini continuano a funzionare; il cielo non sta cadendo per chi usa Flash o il Pro attuale. La risposta utile è trattare il ritardo come uno stress test del grado di accoppiamento con un singolo modello — e acquisire flessibilità prima di averne bisogno.

La mossa a più alto leverage è un livello di astrazione del provider: instrada tutte le chiamate ai modelli attraverso un'interfaccia interna, in modo che sostituire OpenAI, Anthropic, Google o un modello open-source al suo interno sia una modifica di configurazione, non una migrazione di codice. Affiancalo a un piccolo harness di valutazione che misuri i modelli candidati su un insieme fisso di task di coding e di prodotto tuoi. In questo modo un ritardo, un taglio di prezzo o un nuovo rilascio diventano un esperimento controllato che esegui in un pomeriggio, invece di uno scramble strategico. È esattamente la disciplina che distingue un build software personalizzato duraturo da uno silenziosamente incatenato a una singola API.

C'è anche una lettura procurement per i responsabili tecnici. Smetti di trattare le date di disponibilità dichiarate da un lab come impegni nella pianificazione; trattale come previsioni ottimistiche e pianifica in base ai modelli generalmente disponibili oggi. Se un elemento della roadmap richiede genuinamente una capacità offerta solo da un modello non ancora rilasciato, segnalalo come dipendenza a rischio e mantieni un percorso alternativo sui modelli attuali. I team che hanno passato questa settimana senza problemi sono quelli per cui “quale modello di frontiera è avanti questo mese” è un'ottimizzazione, non una fondamenta.

Cosa significa per il mercato italiano: In Italia, il ritardo di Gemini 3.5 Pro si inserisce in un contesto di crescente attenzione alla dipendenza tecnologica dalle grandi piattaforme americane. Con il Piano Nazionale di Ripresa e Resilienza (PNRR) che finanzia la digitalizzazione delle PMI e della PA, molte organizzazioni italiane stanno integrando strumenti di IA per la prima volta — rendendo la scelta del fornitore una decisione con conseguenze a lungo termine. Il Garante Privacy italiano ha già emesso linee guida sull'uso dei sistemi di IA e sul trasferimento dei dati verso paesi terzi: un cambio di modello imprevisto potrebbe rimettere in discussione le valutazioni di impatto sulla protezione dei dati (DPIA) già effettuate. Costruire fin dall'inizio un livello di astrazione che permetta di passare da Google a modelli alternativi — inclusi modelli open source ospitati in UE — è una scelta che riduce sia il rischio di roadmap sia quello di conformità normativa.

Cosa fare questo trimestre

Trasforma la notizia in un breve esercizio pratico di rafforzamento architetturale, non in un dibattito filosofico sui vendor.

  1. Metti le chiamate ai modelli dietro un'unica interfaccia. Se il tuo codice chiama direttamente l'SDK di un vendor in molti punti, wrappalo. Un singolo punto di astrazione è ciò che rende ogni successivo cambio economico.
  2. Costruisci un eval set a livello di task. Raccogli 20–50 task rappresentativi del tuo prodotto e della tua codebase, con output attesi graduati, e misura qualsiasi modello candidato su di essi — non sui benchmark pubblici.
  3. Configura un provider alternativo. Tieni almeno un modello alternativo collegato e testato per i tuoi carichi di lavoro principali, in modo che un ritardo, un'interruzione o un picco di prezzo sia un cambio di configurazione, non un progetto.
  4. Mappa gli elementi della roadmap alle dipendenze dai modelli. Segnala qualsiasi funzionalità che presuppone un modello non ancora rilasciato; assegna a ciascuna un piano B sui modelli attualmente disponibili.
  5. Imposta guardrail su costi e residenza. Monitora la spesa per modello e verifica che ogni provider su cui fai affidamento soddisfi i tuoi requisiti di residenza dei dati e compliance prima di dipendervi.
  6. Ri-esegui gli eval ad ogni nuovo rilascio. Quando un modello atteso viene finalmente rilasciato, decidi con i dati — sottoponilo allo stesso harness e confronta, invece di adottarlo per reputazione.

Un rilascio bloccato da uno dei lab di IA più forti non è una crisi — è un promemoria utile che la capacità dei modelli arriva in modo discontinuo. I team che trattano i modelli come componenti intercambiabili, valutati sui propri task, continueranno a consegnare indipendentemente da quale lab sia avanti questo mese. I team che trattano la roadmap di un singolo vendor come la propria continueranno a ridefinire i piani ogni volta che uno slitterà.

Domande frequenti

Perché Gemini 3.5 Pro è in ritardo?

Secondo un rapporto di Bloomberg del 16 luglio 2026, che cita fonti interne a Google, il rilascio ampio di Gemini 3.5 Pro è stato posticipato perché le capacità del modello non hanno raggiunto le aspettative interne — le prestazioni nel coding in particolare. Un aggiornamento dei dati di addestramento a fine giugno, pensato per colmare il divario con i concorrenti, avrebbe ancora deluso le aspettative. Google ha dichiarato a Reuters di essere “attualmente in fase di test di 3.5 Pro, un modello Flash aggiornato e altri modelli con i partner.”

Quando sarà disponibile Gemini 3.5 Pro?

Google non ha fornito una nuova data ferma. Gemini 3.5 è stato presentato all'I/O di maggio 2026 con la versione Pro descritta come in uso interno e un rollout più ampio previsto il mese successivo; quella finestra di giugno è passata. Al 16 luglio il modello era descritto come in ritardo di diversi mesi e ancora in test con i partner. Tratta qualsiasi data indicata come indicativa e pianifica in base ai modelli generalmente disponibili oggi.

Come ha influenzato il ritardo le azioni di Alphabet?

Le azioni di Alphabet sono scese di circa il 4% giovedì 16 luglio 2026 dopo la notizia del ritardo — un movimento che ha cancellato circa 200 miliardi di dollari di capitalizzazione di mercato in una sola seduta. La reazione riflette quanto siano diventate centrali le prestazioni nel coding e nei flussi di lavoro agentici nella competizione tra Google, OpenAI, Anthropic e Meta.

Cosa devono fare i team che usano Gemini per il coding?

Non è necessario sospendere i sistemi funzionanti, ma è opportuno ridurre la dipendenza da un unico fornitore. Continuate a usare gli assistenti e le funzionalità basati sui modelli Gemini disponibili oggi (Flash, Flash-Lite e il Pro precedente), instradata tutto attraverso un livello di astrazione che permetta di cambiare modello senza riscrivere il codice, e valutate qualsiasi candidato sui vostri task di coding rappresentativi — non sui benchmark dei vendor. Trattate il ritardo come conferma che le date della roadmap non sono garanzie di consegna.

Gemini 3.5 Flash è interessato dal ritardo?

Il ritardo riguarda il tier Pro di punta. Gemini 3.5 Flash e Flash-Lite sono già stati rilasciati, e Google ha indicato che un Flash aggiornato è tra i modelli in test con i partner. I team che usano Flash per carichi di lavoro cost-sensitive non sono bloccati dal ritardo del Pro — anche se vale la stessa disciplina multi-modello: valutate le prestazioni sui vostri task e tenete configurato un provider alternativo.

Fonti

CNBC — Le azioni di Alphabet calano dopo il report sul ritardo di Gemini 3.5 Pro, il modello di IA più potente, 16 luglio 2026
9to5Google — Ritardi di Gemini 3.5 Pro per le prestazioni nel coding; Flash aggiornato in test, 16 luglio 2026
Reuters / Global Banking & Finance — Il lancio di Google Gemini posticipato: la tecnologia non raggiunge gli obiettivi interni, secondo Bloomberg News