La giornata dell'intelligenza artificiale si concentra su un passaggio meno appariscente di un nuovo modello, ma più importante per chi usa davvero questi sistemi: lo stack si sta riaprendo. OpenAI e Microsoft hanno riscritto il loro accordo, togliendo esclusività a una relazione che per anni ha definito la distribuzione enterprise dell'AI; DeepSeek usa il lancio di V4 per spingere una guerra dei prezzi aggressiva; la ricerca su ASI-Evolve e sui limiti del RAG ricorda che gli agenti non dipendono solo da modelli più forti, ma da infrastrutture verificabili.
Il filo comune è la fine di una fase semplice. Nel 2024 e nel 2025 bastava chiedersi chi avesse il modello migliore; nel 2026 la domanda è più concreta: dove gira, quanto costa, chi lo può distribuire, quali tool può usare, come si controlla quando agisce e come si verifica ciò che recupera dalla memoria. Le aziende non comprano più solo una chat, ma una catena fatta di cloud, runtime, dati, agenti, policy e contratti.
Per questo le tre storie più forti non vanno lette separatamente. La nuova libertà commerciale di OpenAI cambia la concorrenza tra cloud; il prezzo di DeepSeek V4 mette pressione sui margini dei modelli proprietari; gli esperimenti di AI che ottimizza altra AI mostrano perché il collo di bottiglia si sposta dalla generazione di testo alla capacità di condurre cicli lunghi, misurati e controllati. La notizia del giorno è che l'AI diventa più aperta, ma anche più difficile da governare.
OpenAI e Microsoft riscrivono il patto del cloud
La notizia principale è il nuovo accordo tra OpenAI e Microsoft, pubblicato da entrambe le aziende. Nel post ufficiale di OpenAI, il punto chiave è netto: Microsoft resta il cloud partner primario, e i prodotti OpenAI usciranno prima su Azure quando Azure potrà supportarli, ma OpenAI potrà servire i propri prodotti ai clienti attraverso qualunque provider cloud. La licenza Microsoft sulla proprietà intellettuale di OpenAI continua fino al 2032, ma diventa non esclusiva.
OpenAI can now serve all its products to customers across any cloud provider.
È una frase breve, ma cambia il peso negoziale di tutto il mercato. Fino a ieri, molte decisioni enterprise su ChatGPT, API, agenti e prodotti collegati erano lette dentro la cornice Azure. Da oggi il messaggio è diverso: Azure resta centrale, ma non è più l'unica porta commerciale possibile. Microsoft ottiene chiarezza di lungo periodo, smette di pagare revenue share a OpenAI e continua a ricevere pagamenti da OpenAI fino al 2030, con un tetto. OpenAI, invece, guadagna libertà per trattare con AWS, Google Cloud e altri partner.
La ricostruzione di TechCrunch aiuta a capire perché questo non è un dettaglio contrattuale. OpenAI aveva già stretto un accordo con Amazon, collegato anche a un ambiente di runtime stateful per agenti su Bedrock e alla distribuzione di strumenti agentici. Il vecchio perimetro Microsoft poteva creare tensioni su API, prodotti first-party e diritti esclusivi. Il nuovo accordo abbassa quel rischio e permette ai clienti AWS di aspettarsi accesso più diretto ai modelli OpenAI dentro il proprio cloud.
Per Microsoft il cambiamento non è una sconfitta pura. La società conserva una licenza lunga, resta azionista rilevante e mantiene un ruolo privilegiato come piattaforma di lancio. Inoltre, liberarsi da alcuni obblighi di revenue share può migliorare la prevedibilità economica. Ma il rapporto smette di essere un recinto e diventa una partnership meno esclusiva. Per il mercato enterprise, questo significa più concorrenza nella distribuzione e più pressione sui prezzi, sulle latenze e sulle integrazioni.
Cambia anche il modo in cui le aziende possono negoziare con i fornitori. Finché un modello arriva solo attraverso un canale privilegiato, procurement, sicurezza e architettura cloud devono accettare molti vincoli come dati di fatto. Quando lo stesso modello può comparire in più ambienti, il cliente può chiedere condizioni diverse su residenza dei dati, logging, throughput, supporto e integrazione con sistemi già adottati. La leva negoziale si sposta dal nome del modello alle clausole operative.
Il punto tecnico più interessante è il concetto di runtime stateful. Gli agenti utili non sono semplici chiamate stateless a un modello: devono ricordare obiettivi, stato, passaggi intermedi, permessi e strumenti usati in una procedura lunga. Se quel runtime diventa disponibile su più cloud, il valore si sposta dal singolo modello al modo in cui modello, memoria, tool e dati aziendali vengono orchestrati. È il terreno su cui i cloud provider proveranno a differenziarsi.
Per chi compra AI, la conseguenza è pragmatica. Un CIO non dovrebbe chiedere soltanto quale modello OpenAI usare, ma su quale cloud convenga servirlo, con quali garanzie di portabilità e con quale controllo dei log. La nuova fase rende più facile evitare lock-in assoluti, ma non elimina il lock-in tecnico: agenti, datastore, permessi, osservabilità e costi di uscita restano specifici di ogni piattaforma. La libertà commerciale non è automaticamente portabilità operativa.
Questa modifica arriva anche in un momento in cui Microsoft coltiva più alternative AI, compresa la collaborazione con Anthropic per prodotti agentici, mentre OpenAI continua a cercare capacità computazionale e canali di distribuzione. La dinamica è ormai chiara: i grandi laboratori non vogliono dipendere da un solo cloud; i grandi cloud non vogliono dipendere da un solo laboratorio. Il risultato è una rete di alleanze incrociate, dove concorrenti e fornitori cambiano ruolo a seconda del prodotto.
DeepSeek V4 trasforma il prezzo in arma strategica
Il secondo segnale arriva dalla Cina. DeepSeek V4 era già importante per le dimensioni dichiarate, per il contesto da un milione di token e per il legame con chip Huawei Ascend. La novità operativa più fresca è però il prezzo. La pagina ufficiale dei prezzi DeepSeek mostra V4 Flash e V4 Pro con supporto a tool calls, output JSON, modalità thinking e una finestra di contesto da 1M token. V4 Pro è in promozione al 75%, mentre il prezzo dei cache hit in input è stato ridotto a un decimo del prezzo di lancio.
I numeri sono difficili da ignorare. Per V4 Pro, DeepSeek indica 0,435 dollari per un milione di token input cache miss e 0,87 dollari per un milione di token output durante la promozione; V4 Flash scende ancora di più, con 0,14 dollari input cache miss e 0,28 dollari output. Il cache hit diventa quasi simbolico: 0,003625 dollari per V4 Pro in promozione e 0,0028 per V4 Flash. In carichi agentici ricchi di memoria e riuso del contesto, questa scelta può contare quanto una miglioria di benchmark.
Aju Press, citando media cinesi e dati di traffico riportati localmente, scrive che le chiamate a V4 Pro sono salite a 13,6 miliardi di token in un giorno dopo il lancio, mentre V4 Flash avrebbe raggiunto 50,2 miliardi di token. Sono dati da trattare con prudenza, perché arrivano da fonti locali e da una fase promozionale, ma segnalano una strategia coerente: DeepSeek vuole trasformare il costo per token in un canale di acquisizione.
Il confronto con OpenAI, Anthropic e Google non si risolve in una tabella. Un modello più economico non è automaticamente migliore, e in molti ambienti regolati contano affidabilità, privacy, supporto, policy, disponibilità geografica e garanzie contrattuali. Però il prezzo cambia le soglie di sperimentazione. Se una startup o un reparto tecnico può testare agenti lunghi, RAG profondi e workflow multi-step a un costo molto più basso, il numero di prove aumenta. E più prove significano più possibilità di trovare casi d'uso reali.
La parte strategica è il legame con Huawei Ascend. V4 viene raccontato come modello pensato per infrastruttura domestica cinese, non come semplice alternativa economica su hardware Nvidia. Se DeepSeek riesce a mantenere prestazioni competitive su chip locali, la pressione non riguarda solo i laboratori occidentali, ma anche la dipendenza dalla filiera hardware statunitense. Qui il prezzo è un messaggio industriale: l'AI cinese vuole essere economica, scalabile e meno esposta ai controlli export.
Per gli sviluppatori, la lezione non è correre automaticamente su DeepSeek. La lezione è costruire sistemi capaci di confrontare modelli diversi con criteri ripetibili. Nel 2026 il costo di inferenza può cambiare in pochi giorni, come dimostra il taglio sul cache hit; un'architettura rigida, legata a un solo modello e a un solo formato, rende impossibile sfruttare questi movimenti. La valutazione continua diventa parte del prodotto, non un esercizio annuale.
Questo vale soprattutto per gli agenti che lavorano su documenti lunghi. Un assistente che legge un manuale, conserva memoria di una sessione, controlla allegati e poi chiama strumenti esterni consuma molti più token di una chat breve. Se il costo del contesto cala, diventano praticabili pattern prima troppo costosi: verifica su più passaggi, confronto tra modelli, retry controllati, simulazioni e red teaming automatico. Il prezzo basso non migliora da solo la qualità, ma permette di comprare più controllo.
In termini editoriali, DeepSeek V4 spinge una domanda scomoda: se la differenza percepita tra modelli frontier si riduce in molte attività quotidiane, quanto potranno reggere prezzi premium senza dimostrare vantaggi specifici? Le risposte possibili sono tre. I provider occidentali possono puntare su qualità assoluta, sicurezza e integrazioni; possono tagliare i prezzi; oppure possono vendere pacchetti agentici completi, dove il modello è solo una componente. La seconda e la terza opzione sembrano sempre più probabili.
Lo stack AI si sposta da modelli a runtime
Mettendo insieme OpenAI-Microsoft e DeepSeek, emerge un trend chiaro: il vantaggio competitivo non vive più soltanto nella scheda tecnica del modello. Vive nel runtime. Un sistema AI moderno deve decidere dove eseguire il modello, come conservare memoria, quando usare cache, quali strumenti chiamare, come recuperare documenti, come verificare permessi e come interrompere un'azione se supera i confini. Questa è la parte meno spettacolare, ma è anche quella che determina se un agente funziona davvero.
Il nuovo accordo OpenAI rende più visibile la concorrenza tra cloud proprio su questo livello. Se i modelli OpenAI possono arrivare su più provider, il valore di Azure, AWS o Google Cloud non sarà solo ospitare pesi e API, ma offrire il miglior ambiente per agenti stateful, osservabilità, governance e connessione ai dati aziendali. In altre parole, la piattaforma che vince non sarà necessariamente quella con il modello più famoso, ma quella che riduce il rischio operativo.
DeepSeek attacca lo stesso problema dal lato opposto: abbassare il costo di contesto lungo, output e cache. Per molti agenti, il costo non è generare una risposta breve, ma mantenere un flusso di lavoro ricco di istruzioni, documenti, memoria e verifiche. Un prezzo molto basso sul cache hit rende più praticabile riusare contesti estesi senza dover continuamente comprimere o tagliare. Questo può accelerare strumenti di coding, analisi documentale, supporto clienti e automazioni interne.
La combinazione crea una pressione doppia sui provider premium. Da un lato i clienti chiedono scelta cloud e riduzione del lock-in; dall'altro vedono modelli concorrenti che abbassano il costo marginale. Il provider che vuole difendere prezzi alti deve dimostrare vantaggi difficili da copiare: minore tasso di errore in task critici, migliore integrazione con workflow esistenti, SLA più solidi, sicurezza più trasparente e strumenti di audit. Il benchmark pubblico diventa solo una parte della prova.
Questo è anche il motivo per cui le notizie hardware, come l'ipotesi riportata da TechCrunch su un possibile telefono OpenAI basato su agenti, vanno lette con cautela ma non ignorate. La storia è ancora una nota di analista e OpenAI non ha commentato, quindi non è una certezza di prodotto. Però l'idea che gli agenti possano sostituire parte della logica delle app è coerente con il resto della giornata: chi controlla il runtime controlla il comportamento quotidiano dell'AI.
Se un agente vive solo dentro un'app, ha permessi limitati e dipende dal sistema operativo. Se vive dentro il dispositivo, nel cloud e nei servizi collegati, può coordinare più azioni: messaggi, calendario, pagamenti, ricerca, acquisti, documenti, prenotazioni. Questo spiega perché hardware, cloud e modelli stanno tornando a intrecciarsi. Non basta avere un modello capace; serve un punto di esecuzione abbastanza vicino all'utente e abbastanza integrato da agire.
La posta in gioco non è sostituire tutte le app con una conversazione, ma decidere chi media l'accesso alle app esistenti. Un agente con permessi ampi può diventare il nuovo livello di interfaccia tra utente, servizi e dati personali, con implicazioni immediate per consenso, privacy e concorrenza nel lavoro quotidiano digitale.
Per l'Europa e per le aziende regolamentate, il tema diventa ancora più delicato. Un runtime agentico deve rispettare residenza dei dati, logging, cancellazione, consenso, ruoli interni e audit. Un modello economico ma opaco può essere perfetto per prototipi e poco adatto a banche o sanità; un modello più costoso ma ben governato può essere la scelta razionale in processi sensibili. Il mercato non convergerà su un solo vincitore, ma su una segmentazione più matura.
La segmentazione sarà probabilmente dinamica. Lo stesso prodotto potrebbe usare un modello locale per documenti riservati, un modello low-cost per esplorazione, un modello premium per la risposta finale e un verificatore specializzato per controllare fonti e policy. Questo richiede orchestrazione, non fedeltà a un singolo brand. Il nuovo stack AI assomiglia meno a una scelta tra chatbot e più a una catena di decisioni tecniche ripetute a ogni richiesta.
Da qui nasce anche una nuova responsabilità per product manager e architetti. Ogni scelta di routing deve essere spiegabile: perché un documento è finito su un modello e non su un altro, perché una richiesta è stata servita in una regione specifica, perché un passaggio è stato verificato due volte e un altro no. La governance non può restare un allegato legale scritto dopo il deployment; deve entrare nella progettazione del flusso, altrimenti la libertà multi-cloud si trasforma in complessità non controllata.
ASI-Evolve mostra l'AI che ottimizza altra AI
Il progetto più interessante della giornata, sul lato ricerca, è ASI-Evolve. Il paper su arXiv è stato pubblicato a fine marzo, ma la nuova attenzione arriva da una lettura più ampia del suo impatto industriale. ASI-Evolve è un framework agentico per la ricerca AI-for-AI: impara da una base di conoscenza, propone modifiche, esegue esperimenti, analizza risultati e reinserisce lezioni nel ciclo successivo. Non è magia ricorsiva, ma un sistema progettato per chiudere il loop sperimentale.
Secondo gli autori, il framework lavora su tre aree fondative: dati di pretraining, architetture e algoritmi di apprendimento. I risultati dichiarati sono forti: 105 architetture di linear attention che superano DeltaNet, miglioramenti medi di quasi quattro punti nella curatela dei dati e guadagni superiori a 18 punti su MMLU in alcuni casi. Nel reinforcement learning, gli algoritmi scoperti superano GRPO su benchmark matematici come AMC32 e AIME24. Sono numeri da verificare nel tempo, ma la direzione è rilevante.
Il valore non sta nell'idea vaga di una AI che si migliora da sola. Sta nel metodo. ASI-Evolve usa una Cognition Base con conoscenze umane, euristiche e insidie tratte dalla letteratura; usa un Analyzer per distillare log, metriche ed esiti in lezioni riutilizzabili; usa componenti di ricerca e ingegneria per generare ipotesi e far girare esperimenti. In pratica, prova a trasformare il lavoro di ricerca iterativa in una pipeline con memoria.
VentureBeat nota un aspetto utile per le aziende: molti team non hanno le risorse per esplorare sistematicamente architetture, data cleaning, fine-tuning e algoritmi. Finiscono quindi per usare configurazioni standard, magari non ottimali per il proprio dominio. Un framework come ASI-Evolve suggerisce un futuro in cui il sistema non si limita a rispondere, ma propone modifiche misurabili alla pipeline AI interna.
Qui però serve freddezza. ASI-Evolve non elimina gli umani, non prova che la ricerca possa progredire senza vincoli e non risolve il costo computazionale. Gli spazi di ricerca sono definiti, le metriche sono scelte da persone, le valutazioni restano parziali e gli esperimenti consumano risorse. La parte interessante è più concreta: un agente può aiutare a conservare, trasferire e combinare intuizioni sperimentali che nei team spesso restano informali.
La connessione con DeepSeek e OpenAI è diretta. Se i costi di inferenza e sperimentazione scendono, e se i runtime cloud diventano più aperti, diventa più realistico far girare cicli autonomi di ottimizzazione. Non per inventare AGI in una notte, ma per migliorare retrieval, prompt, tool routing, dataset, test e policy. La produttività AI non sarà solo usare un modello per scrivere codice, ma usare agenti per migliorare il sistema che usa quel modello.
Per un'azienda, il primo caso d'uso realistico non è ridisegnare una nuova architettura di base. È far evolvere componenti più vicini al prodotto: pipeline di ingestion, regole di chunking, criteri di reranking, prompt di verifica, routing tra modelli, strategie di cache, test di regressione. Queste attività sono abbastanza misurabili da beneficiare di cicli automatici e abbastanza importanti da incidere sulla qualità percepita. Sono anche meno rischiose di lasciare a un agente la scelta di cambiare un modello centrale senza controllo.
Un modo prudente per adottare questo approccio è partire da esperimenti read-only. L'agente può analizzare log, proporre ipotesi e generare patch candidate senza poterle applicare in produzione. Un team umano sceglie quali prove far girare, poi l'agente confronta i risultati e aggiorna una knowledge base interna. In questo schema l'autonomia sperimentale accelera la ricerca, ma la responsabilità resta chiara. È meno affascinante dell'idea di una AI completamente autonoma, ma molto più utile per portare il metodo in azienda.
Il RAG resta utile solo se viene verificato
La skill pratica della giornata riguarda il RAG, perché gli agenti stateful e i sistemi AI-for-AI dipendono dalla qualità del contesto che recuperano. Una ricerca raccontata da VentureBeat avverte che il fine-tuning degli embedding per migliorare la sensibilità composizionale può degradare la generalizzazione del retrieval. In alcuni modelli piccoli il calo è dell'8-9%, mentre in un modello medio usato in produzione arriverebbe fino al 40%.
A close or high semantic similarity does not actually mean an exact intent.
La frase attribuita a Srijith Rajamohan di Redis è il promemoria operativo più utile. Due frasi possono condividere parole e tema, ma dire cose opposte: una negazione, un'inversione di ruoli, un modificatore applicato al soggetto sbagliato. Un embedding singolo tende a comprimere la frase in un punto nello spazio vettoriale; è ottimo per richiamare documenti simili, ma può essere fragile quando la differenza importante sta nella struttura.
La tentazione di molti team è risolvere tutto con un modello più grande o con hybrid search. Ma la ricerca citata suggerisce che il problema non è solo mancanza di parole chiave. Se due frasi hanno le stesse parole e ordine concettuale simile, BM25 e vettori possono concordare sul candidato sbagliato. Anche MaxSim e late interaction possono migliorare la rilevanza generale senza catturare bene i near-miss strutturali. Rilevanza e identità semantica non sono la stessa metrica.
Il consiglio pratico è progettare il RAG in due fasi. La prima fase deve privilegiare recall: recuperare un set abbastanza ampio e veloce di candidati plausibili. La seconda deve privilegiare precisione: verificare a livello di token, ruoli, negazioni e vincoli se il candidato è davvero adatto alla domanda. Questo secondo passo può usare un piccolo verifier, un cross-encoder mirato, regole domain-specific o un modello incaricato di cercare contraddizioni. Non serve sempre farlo su tutto, ma serve farlo sui processi sensibili.
Per applicazioni legali, contabili, mediche, HR o finanziarie, il costo di una verifica in più è spesso inferiore al costo di una risposta plausibile ma sbagliata. In un agente, l'errore di retrieval non produce solo una risposta errata: può attivare un'azione successiva, chiamare un tool, inviare un messaggio o aggiornare un sistema. La cascata agentica amplifica il difetto iniziale. Per questo un RAG progettato per chatbot informativi non è automaticamente pronto per agenti operativi.
Una checklist minima dovrebbe includere query di regressione con negazioni, ruoli invertiti, date vicine, importi simili e condizioni contrattuali opposte. Ogni volta che si fine-tuna un embedding o si cambia il chunking, bisogna misurare non solo precision@k e recall@k, ma anche la capacità di rifiutare candidati quasi identici ma sbagliati. Se il test migliora sui benchmark generali e peggiora sui near-miss, il sistema sta comprando velocità o precisione apparente con rischio nascosto.
Un esempio semplice chiarisce il problema: in un contratto, "il fornitore indennizza il cliente" e "il cliente indennizza il fornitore" contengono quasi le stesse parole, ma producono conseguenze opposte. Un recupero vettoriale può portarli vicini; un agente che non verifica i ruoli può generare una sintesi legalmente pericolosa. Per questo i dataset di valutazione devono includere casi costruiti per far fallire il sistema, non solo domande facili da soddisfare. La qualità del RAG si vede nei casi in cui deve dire no.
La parte più importante è organizzativa. Il team che gestisce RAG deve parlare con chi possiede il processo di business. Un errore di retrieval in una knowledge base marketing è diverso da un errore in una clausola contrattuale; un near-miss su un prodotto e-commerce è diverso da un near-miss su un dosaggio medico. La valutazione deve pesare gli errori in base alle conseguenze, non solo contarli. Un agente maturo non è quello che recupera più documenti, ma quello che sa quando il documento recuperato non basta.
Dal prototipo agentico al controllo dei permessi
Il modo più concreto per usare le notizie di oggi è rivedere i permessi degli agenti. Se OpenAI diventa distribuibile su più cloud, se DeepSeek abbassa il costo dei contesti lunghi e se framework come ASI-Evolve rendono più automatici i cicli sperimentali, aumenterà la quantità di agenti interni costruiti in fretta. Il rischio non è solo che falliscano; è che funzionino abbastanza da entrare nei processi senza governance adeguata.
Il primo principio è separare lettura, scrittura ed esecuzione. Un agente che può leggere documenti interni non deve automaticamente poter inviare email, aggiornare CRM, aprire ticket o approvare spese. Ogni tool dovrebbe avere permessi espliciti, limiti numerici e log. Il principio del minimo privilegio è più importante con i modelli linguistici che con software tradizionale, perché il modello può combinare contesti e interpretare istruzioni in modi non previsti.
Il secondo principio è usare ambienti shadow. Prima di dare a un agente il permesso di agire, lasciarlo simulare decisioni per alcune settimane e confrontare le sue proposte con decisioni umane reali. Questo aiuta a capire dove risparmia tempo, dove inventa scorciatoie, dove sbaglia retrieval e dove chiede aiuto. Una demo che chiude un workflow in cinque minuti è meno utile di cento casi shadow misurati bene.
Il terzo principio è scegliere modelli in base al rischio del passo, non solo al costo complessivo. Un workflow può usare un modello economico per sintesi preliminari e un modello più affidabile per verifica, policy, escalation o decisione finale. La discesa dei prezzi DeepSeek rende più facile moltiplicare passaggi economici, ma non obbliga a usarli ovunque. La strategia robusta è routing per rischio: ogni fase ha il modello e il controllo adatti alla conseguenza dell'errore.
Il quarto principio è rendere osservabile il runtime. Ogni agente dovrebbe lasciare traccia di input rilevanti, documenti recuperati, tool chiamati, decisioni rifiutate, soglie superate e interventi umani. Senza osservabilità, l'organizzazione non sa se un errore nasce dal modello, dal prompt, dal documento sbagliato, da un permesso troppo ampio o da un verificatore assente. L'audit non è burocrazia: è il modo per migliorare il sistema dopo incidenti piccoli, prima che diventino incidenti grandi.
Il quinto principio è progettare lo stop. Un agente dovrebbe fermarsi davanti a dati personali non previsti, clausole contrattuali nuove, richieste di credenziali, differenze di importo oltre soglia, conflitti tra fonti e incertezza alta. Lo stop non è un fallimento del prodotto; è una funzione. In molti workflow professionali, il valore dell'AI non è decidere al posto della persona, ma arrivare al punto critico con contesto migliore e allarme più chiaro.
Questa è la differenza tra automazione e delega. L'automazione classica segue regole rigide; la delega agentica interpreta obiettivi. Più aumenta l'interpretazione, più servono mandato, limiti e verifica. La giornata lo mostra da tre lati: OpenAI apre la distribuzione, DeepSeek abbassa il costo di esecuzione, ASI-Evolve automatizza parti della sperimentazione. Tutto invita a costruire più agenti. Proprio per questo bisogna costruirli con più freni.
Cosa monitorare tra cloud, prezzi e agenti
La prima cosa da monitorare è come AWS, Google Cloud e gli altri provider tradurranno il nuovo accordo OpenAI in prodotti concreti. Non basta annunciare disponibilità: conteranno regioni, latenze, tool supportati, pricing, logging, integrazione con Bedrock o piattaforme equivalenti e possibilità di migrare workflow già costruiti su Azure. Se i modelli OpenAI diventano davvero multi-cloud, la competizione si sposterà sulle funzioni attorno al modello.
La seconda cosa è la durata reale della guerra prezzi di DeepSeek. La promozione su V4 Pro è forte, ma il test sarà la sostenibilità dopo la finestra promozionale, la qualità sotto carico e la capacità di mantenere servizio stabile con volumi alti. Bisogna osservare anche come risponderanno Qwen, Kimi, MiniMax e i provider occidentali. Se più laboratori tagliano il costo del contesto lungo, gli agenti diventeranno più economici e quindi più diffusi.
La terza cosa, collegata alle prime due, è il modo in cui i contratti enterprise verranno riscritti. Le aziende dovrebbero aspettarsi clausole più precise su capacità riservata, fallback multi-cloud, diritto di esportare log, compatibilità con formati OpenAI-style o Anthropic-style, limiti di retention e responsabilità in caso di tool call errata. La vera maturità commerciale dell'AI si vedrà quando questi dettagli saranno standardizzati, non quando una demo mostrerà un agente più fluido.
La quarta cosa è l'adozione di ASI-Evolve e strumenti simili. Il codice aperto e il paper non bastano: serviranno repliche, casi aziendali, costi chiari e limiti ben documentati. La domanda giusta non è se una AI possa sostituire i ricercatori, ma se possa ridurre il tempo tra ipotesi, esperimento, analisi e nuova ipotesi in problemi circoscritti. Se la risposta è sì, molte pipeline ML interne cambieranno ritmo.
La quinta cosa è la maturazione dei test RAG. Nei prossimi mesi diventerà sempre più evidente che molte demo agentiche falliscono non perché il modello non ragiona, ma perché recupera contesto sbagliato o incompleto. I team più maturi cominceranno a pubblicare metriche su near-miss, negazioni, ruoli invertiti, freshness dei documenti e accuratezza del verifier. Chi non misura questi aspetti continuerà a confondere risposte fluenti con risposte affidabili.
La sesta cosa è l'hardware consumer. L'ipotesi di un dispositivo OpenAI con agenti al posto delle app resta non confermata, ma indica una direzione plausibile: il prossimo terreno di scontro sarà il punto di accesso quotidiano. Se un agente deve conoscere contesto personale, preferenze, calendario, messaggi e pagamenti, il controllo del dispositivo o del sistema operativo diventa un vantaggio enorme. Apple, Google, OpenAI e i produttori Android non stanno guardando solo al chatbot, ma alla nuova interfaccia primaria.
La sintesi è che l'AI del 2026 diventa una questione di distribuzione. I modelli restano centrali, ma non bastano. OpenAI prova a non restare chiusa in un solo cloud; DeepSeek prova a vincere facendo crollare il costo d'uso; ASI-Evolve mostra che anche la ricerca può diventare un ciclo agentico; il RAG ricorda che ogni ciclo senza verifica rischia di amplificare errori. La nuova competizione non è più solo chi risponde meglio, ma chi costruisce lo stack più utile, economico e controllabile.