Dall'idea alla scala: come vendor, infrastrutture e standard provano a rendere l'AI ripetibile

Oracle fatturerà l’AI per singola attività, oltre al prezzo per utente. L’ha detto Chris Leone all’investor day. La metrica è l’“AI unit”, che si consuma quando l’AI completa compiti nelle applicazioni Oracle¹. Tesi: i vendor stanno spostando l’attenzione dalla demo alla gestione operativa. Pricing per attività, runtime gestiti, ottimizzazioni hardware e standard di conformità puntano alla produzione. La cautela degli sviluppatori resta il freno.

1) Pricing per attività e prevedibilità dei costi

Oracle affianca all’abbonamento per seat un flusso legato all’uso. Più attività l’AI completa, più ricavi entrano. Non serve aggiungere seat per far crescere il fatturato. Serve che l’AI lavori di più dentro i sistemi Oracle¹. Il messaggio è diretto: l’AI diventa una voce variabile, misurata con “AI units”.

Resta un nodo. Nelle dichiarazioni citate non c’è una definizione operativa di “AI unit”. Mancano modalità di misura e perimetro delle attività conteggiate. Senza questi dettagli, la prevedibilità dei costi per i clienti è incerta¹. È una scelta con effetti pratici. Le aziende devono capire come leggere il consumo e come mettergli un tetto.

Il contesto di prodotto è coerente. Leone lega il tema dei ricavi all’adozione di agenti di AI nelle suite enterprise di Oracle. L’azienda ha presentato Fusion Claw, un runtime che aiuta i clienti a controllare agenti che automatizzano processi di business. Il perimetro indicato tocca ERP, finanza e supply chain management¹. Se gli agenti prendono in carico più passaggi, il consumo di “AI units” si muove con loro. La responsabilità di misurare e governare quel consumo scivola sulle spalle dei team che impostano i processi.

La tendenza è chiara: il prezzo segue l’azione, non solo la presenza dell’utente. È un invito a progettare flussi con soglie, metriche e rollback. Senza questi elementi, il rischio è una fattura che cresce con dinamiche non note in anticipo¹.

2) Runtime gestiti per agenti: ridurre il lavoro di integrazione

Microsoft porta il Copilot harness in Foundry Agent Service in public preview. In parallelo rende disponibile la resilienza per esecuzioni long running degli hosted agents⁴. Cambia il punto di partenza per chi sviluppa. Si sceglie un modello supportato. Si decide quanta parte dello stack costruire in proprio. L’infrastruttura di base è gestita⁴.

Il Copilot harness fornisce una base di esecuzione per agenti che ragionano, usano strumenti e completano task complessi e prolungati. Coordina chiamate al modello e agli strumenti. Mantiene il contesto. Gestisce i file. Decide i passaggi successivi nel loop dell’agente. L’offerta concentra queste capacità in un servizio gestito. I team si concentrano sulla logica dell’agente e sulla scelta del modello, non sulla colla tra componenti⁴.

L’effetto sul lavoro quotidiano è tangibile. Molti team oggi ricostruiscono la stessa “macchina d’esecuzione”: orchestrazione, stato, controllo del flusso, persistenza dei dati transitori. Microsoft propone di trattarla come piattaforma e non come codice ripetuto⁴. Il risparmio è tempo di integrazione. Il costo è la necessità di valutare vincoli e controllo operativo. Qui il collegamento con il pricing per attività è diretto. Se l’agente corre su un runtime gestito, la misurazione del lavoro svolto e la mappa dei costi devono essere leggibili a livello di task, non solo di risorse.

3) Ottimizzazioni hardware software per latenza e throughput

Gli agenti lavorano a più passaggi. Ogni passaggio pesca nel contesto. Qui i colli di bottiglia non sono solo nel modello. Contano anche stato e persistenza. HPE propone di spostare la KV cache sulle Alletra Storage MP X10000. Nei test validati da Kamiwaza, il time to first token si riduce fino a 20 volte. Il throughput aumenta di 17 volte su GPU NVIDIA H200, rispetto all’esecuzione senza offload della cache⁵.

La KV cache conserva lo stato del contesto generato durante l’inference. Di norma resta in memoria GPU. HPE la porta su Alletra MP X10000, così lo stato calcolato resta disponibile e non serve ricostruirlo quando il sistema torna sugli stessi contenuti⁵. Il guadagno nasce qui. Se lo stato non viene espulso, gli acceleratori ricalcolano meno. I cicli liberi vanno all’inference utile. Il primo token arriva prima. A parità di tempo, escono più token. I rapporti misurati indicano l’ordine di grandezza dell’effetto⁵.

L’implicazione per gli agenti è concreta. Catene di ragionamento, recupero di documenti, controlli sul risultato ripresentano lo stesso contesto. Una cache persistente tra step riduce latenza e sprechi di calcolo⁵. È un intervento che sposta la leva di performance dallo scaling del modello alla gestione dello stato. Per i team, significa valutare architetture che tengono il contesto vicino e riusabile tra esecuzioni. E mettere in relazione questi guadagni con i modelli di costo citati sopra: meno ricalcolo, meno attività fatturate se il perimetro include la ricostruzione dello stato^1,5.

4) Standard, conformità e il freno degli sviluppatori esperti

Sul fronte dell’orchestrazione, arriva un passaggio istituzionale. AI Conformance passa da Working Group a sottoprogetto di SIG Architecture in Kubernetes. Lo annuncia uno “SIG Architecture spotlight”, un’intervista a Janet Kuo e Yuan Tang³. Kuo si presenta come Senior Staff Software Engineer in Google. Mantiene Kubernetes dal 2015. È co‑chair e TL di SIG Apps e guida AI Conformance. Dice di voler mantenere Kubernetes la piattaforma migliore per i carichi di prossima generazione, con l’AI citata in modo esplicito. Tang è Senior Principal Software Engineer in Red Hat. Guida la piattaforma AI dell’azienda e la strategia open source upstream³.

Il focus del botta e risposta resta su percorso, responsabilità e obiettivi del programma. L’ingresso in SIG Architecture porta il tema della conformità AI dentro il cuore delle scelte architetturali del progetto. Il segnale è che interoperabilità e verifica delle capacità diventano materia di standard, non solo di best practice locali³. Per chi costruisce piattaforme, questo apre uno spazio di allineamento tra runtime gestiti, gestione dello stato e requisiti di conformità.

Sul terreno, però, la velocità la decidono gli sviluppatori. Thoughtworks, nel lavoro per il Technology Radar, registra una cautela netta sugli agenti che scrivono codice. “Built isn’t the same as working in production.” La frase ha orientato la discussione. Un agente può assemblare componenti e passare i test locali. Il rischio emerge dopo, con carico reale, integrazioni, incidenti. Gli sviluppatori chiedono prova sul campo. Non confondono un prototipo con un sistema pronto².

Questo crea una tensione sana. Pricing per attività, piattaforme gestite e ottimizzazioni promettono efficienza e velocità. La valutazione resta ancorata alla tenuta operativa. La standardizzazione in Kubernetes aiuta a misurare requisiti e responsabilità. La prova in produzione decide l’adozione^2,3.

Chi disegna roadmap deve tenere insieme i quattro pezzi. Misurare il lavoro degli agenti in modo leggibile per il bilancio¹. Delegare l’orchestrazione che non porta differenza competitiva⁴. Investire su stato e latenza dove i flussi lo richiedono⁵. Legare queste scelte a standard di conformità che proteggono l’operatività, non solo la portabilità³. La prossima verifica non è in demo, è sotto carico.