La giornata dell’intelligenza artificiale non ruota attorno a un nuovo modello da provare per curiosità. Il segnale più forte è più concreto: gli agenti stanno cercando un posto stabile dove lavorare, le aziende vogliono portarli dentro sistemi regolati e le piattaforme devono risolvere il problema meno glamour della corsa AI, cioè persone, energia, infrastrutture e procedure.
Il filo comune unisce OpenAI, Anthropic e Google in modo piuttosto netto. OpenAI vuole comprare Ona per dare a Codex ambienti cloud persistenti e controllabili. Anthropic prova a far uscire Claude dal perimetro della chat, da una parte con un programma da 150 milioni di dollari per le non profit e dall’altra con DXC nei sistemi di banche, compagnie aeree, assicurazioni e pubbliche amministrazioni. Google, invece, mette 50 milioni di dollari sulle competenze tecniche di chi costruisce e mantiene la base fisica dell’AI.
È una fotografia utile perché ridimensiona una lettura troppo semplice del mercato. La prossima fase non si gioca solo su benchmark, finestre di contesto o prezzi per milione di token. Si gioca su continuità operativa, confini di sicurezza, formazione, audit, competenze sul campo e fiducia pubblica. In altre parole: l’AI sta diventando meno demo e più lavoro organizzato.
OpenAI compra Ona per dare a Codex un ambiente persistente
La notizia principale arriva da OpenAI, che ha annunciato l’intenzione di acquisire Ona, società specializzata in esecuzione cloud e ambienti di sviluppo riproducibili. Nel suo annuncio ufficiale, OpenAI spiega che la tecnologia di Ona entrerà nell’ecosistema Codex per permettere agli agenti di lavorare in ambienti sicuri, persistenti e controllati dal cliente. L’operazione resta soggetta alle consuete condizioni di chiusura e alle approvazioni regolatorie, quindi non va trattata come già conclusa. Ma la direzione industriale è chiara.
Il punto non è soltanto che Codex diventi più comodo per gli sviluppatori. OpenAI dichiara che oltre 5 milioni di persone usano Codex ogni settimana, con una crescita del 400% rispetto a inizio anno. Sono numeri che, se confermati nella loro traiettoria, spiegano perché la società stia cercando infrastruttura invece di limitarsi a migliorare l’interfaccia. Quando un agente deve analizzare una codebase, preparare modifiche, eseguire test, risolvere conflitti, produrre documentazione e restare in attesa di revisione, una sessione legata al laptop dell’utente diventa un collo di bottiglia.
Ona porta proprio questo tassello: ambienti cloud dove strumenti, dipendenze, credenziali e contesto possono restare disponibili mentre il lavoro continua. OpenAI dice che Ona ha già aiutato 2 milioni di sviluppatori a lavorare in ambienti cloud sicuri e riproducibili. È una competenza molto diversa dal solo addestramento di un modello. Riguarda provisioning, isolamento, gestione dello stato, tracciabilità, collaborazione e integrazione con i sistemi interni di un’azienda.
“Agents need more than intelligence.”
Quella frase breve, attribuita nel comunicato al cofondatore di Ona, sintetizza la notizia meglio di molti slogan. Un agente utile non ha bisogno solo di ragionare bene. Ha bisogno di un luogo affidabile dove operare, di permessi misurati, di log consultabili, di un modo per essere fermato o corretto e di una superficie di revisione leggibile dagli esseri umani. Se manca questa parte, la promessa degli agenti resta fragile: potente in una demo, difficile da mettere in produzione.
La mossa è anche un segnale competitivo. Codex non vuole essere solo un assistente che suggerisce righe di codice, ma un sistema capace di portare avanti lavoro lungo, magari per ore o giorni. In questo scenario, la differenza tra “chat con un modello” e “agente operativo” non è più semantica. È architetturale. Chi controlla l’ambiente di esecuzione controlla cosa l’agente può vedere, cosa può fare, quanto può durare un task, come si recupera da un errore e quale responsabilità rimane al team umano.
Questo cambia anche il modo in cui si valuta il valore di un assistente per sviluppatori. Finora molte comparazioni si sono concentrate sulla qualità del suggerimento immediato: il completamento è corretto, il test passa, la patch è leggibile. Con agenti persistenti, la metrica si allarga. Conta la capacità di mantenere contesto tra passaggi, tornare su un errore dopo un test fallito, riassumere ciò che è stato provato, proporre alternative e non perdere lo stato quando l’utente cambia dispositivo o priorità. È una forma di produttività più vicina alla gestione di un collaboratore junior che all’uso di un autocomplete avanzato.
Gli agenti aziendali passano dal prompt alla governance
La conseguenza pratica è che il mercato degli agenti sta entrando in una fase meno spettacolare ma più seria. Per mesi molte aziende hanno chiesto una cosa semplice: un modello più capace. Ora la domanda cambia. Serve un sistema che possa fare lavoro reale senza diventare un rischio operativo. Questo significa controllo degli accessi, separazione tra ambienti, gestione delle credenziali, policy sui dati, revisione delle modifiche e capacità di ricostruire che cosa è successo quando qualcosa non funziona.
È qui che l’acquisizione di Ona diventa più importante della singola etichetta “coding agent”. Se un agente modifica software aziendale, non può comportarsi come un utente generico con privilegi indefiniti. Deve lavorare dentro un perimetro connesso ai repository, ai sistemi di ticketing, agli ambienti di test e ai processi di approvazione. Deve poter aprire una pull request, ma non distribuire in produzione senza controllo. Deve leggere il contesto necessario, ma non trasformarsi in una scorciatoia per esfiltrare informazioni.
Questa è anche la ragione per cui OpenAI insiste sugli ambienti “customer-controlled”. Le imprese non vogliono soltanto delegare attività; vogliono poter dire dove gira l’agente, quali dati attraversano il confine, quale log resta a disposizione e come si applicano le regole interne. Per un reparto IT o security, la domanda non è “il modello è bravo?” ma “posso spiegare a un auditor cosa ha fatto e perché?”.
La stessa dinamica vale fuori dal codice. Un agente persistente può preparare analisi finanziarie, aggiornare documentazione, controllare procedure, cercare anomalie, organizzare knowledge base o gestire flussi di back office. Ma più il lavoro si avvicina a sistemi reali, più diventa necessario trasformare il prompt in un contratto operativo. Quali strumenti può chiamare? Quali azioni richiedono conferma? Quando si interrompe? Che cosa succede se trova dati contraddittori?
Il tema più sottile è la memoria operativa. Un agente che resta nel tempo accumula contesto, preferenze, strumenti e tracce di decisione. Questo può renderlo molto più efficace, ma può anche creare una nuova forma di dipendenza. Se il contesto è opaco, se le autorizzazioni non sono riviste periodicamente o se nessuno sa quali assunzioni l’agente ha incorporato, la produttività iniziale può trasformarsi in debito di governance. Per questo la persistenza deve essere progettata come un vantaggio controllato, non come una semplice comodità.
Questa è la parte che molte aziende hanno sottovalutato nella prima ondata di entusiasmo. Il salto da chatbot a agente non è un pulsante. È un cambiamento di processo. Richiede owner, ruoli, metriche, test, fallback e limiti. Se la mossa Ona funziona, Codex potrebbe diventare uno dei riferimenti per questa grammatica: non solo modello più ambiente, ma modello più ambiente più governance.
C’è poi una lettura economica. L’infrastruttura persistente aumenta il valore medio di ogni attività delegata, ma aumenta anche il costo e la responsabilità. Un agente che lavora per due minuti è un consumo. Un agente che lavora per due giorni è un processo. Per questo le aziende chiederanno sempre più chiaramente metriche di ritorno: tempo risparmiato, bug evitati, debito tecnico ridotto, incidenti prevenuti, qualità della revisione e impatto sui team.
Il rischio opposto è trasformare ogni flusso in un esperimento costoso. Non tutto deve diventare agentico. Ci sono attività che restano più economiche con automazioni tradizionali, regole deterministiche o semplici template. La maturità consisterà nel capire dove l’incertezza del modello aggiunge valore, perché interpreta contesto e gestisce eccezioni, e dove invece introduce variabilità inutile. Le aziende che useranno meglio gli agenti saranno probabilmente quelle che non li useranno ovunque.
Claude Corps porta l’AI nelle non profit con un modello operativo
Il secondo grande tema è Anthropic, che ha annunciato Claude Corps, un programma nazionale pensato per portare competenze AI dentro organizzazioni non profit americane. La società parla di un impegno iniziale da 150 milioni di dollari, con 1.000 fellows formati all’uso di Claude e inseriti per un anno in almeno 400 organizzazioni. Ogni fellowship dura dodici mesi e prevede formazione intensiva, supporto continuativo e un ruolo in presenza dentro l’organizzazione ospitante.
Il dettaglio più interessante non è solo filantropico. Anthropic sta provando a costruire una catena di adozione. Non consegna semplicemente licenze o crediti; paga persone, le forma, le mette accanto a chi ha problemi concreti e misura il risultato con partner esterni come CodePath e Social Finance. È un modello molto diverso dal classico programma “AI for good” basato su comunicati, grant e workshop episodici.
La promessa è che Claude possa aiutare non profit a fare analisi, gestione dati, comunicazione, automazione amministrativa e supporto operativo. Ma la parte più utile sarà capire che cosa succede quando l’AI entra in organizzazioni che non hanno staff tecnici abbondanti. Molte non profit hanno dati disordinati, strumenti eterogenei, processi manuali e poco tempo per sperimentare. Un modello potente non basta se nessuno sa tradurre il bisogno in workflow sicuro.
Per questo Claude Corps è anche un esperimento sul lavoro. Anthropic lega il programma alla propria riflessione sull’impatto economico dell’AI: se i modelli cambiano mansioni e competenze, le aziende che li costruiscono devono investire direttamente in chi assorbe il cambiamento. È una posizione che va letta con attenzione. Da un lato mostra consapevolezza. Dall’altro non sostituisce politiche pubbliche, contrattazione, misurazione indipendente e regole su uso, responsabilità e sicurezza.
La parte più concreta sarà probabilmente la traduzione dei bisogni. Una banca o una grande azienda possono assumere consulenti, costruire team interni e comprare piattaforme. Una piccola organizzazione sociale spesso non ha questa possibilità. Il fellow diventa allora un ponte: ascolta operatori, volontari e responsabili di programma, capisce dove l’AI può alleggerire carichi ripetitivi e trasforma quel bisogno in procedure abbastanza semplici da essere mantenute. Se funziona, il valore non sarà solo “usare Claude”, ma imparare a descrivere meglio il lavoro.
In termini di mercato, però, la mossa è furba. Anthropic porta Claude in contesti sociali ad alto impatto e, nello stesso tempo, crea una generazione di operatori abituati a usare i suoi strumenti. Chi impara a costruire processi con Claude in una non profit potrà portare quella competenza altrove. È formazione, ma anche distribuzione. È impatto sociale, ma anche ecosistema.
Il rischio è che le organizzazioni più fragili diventino dipendenti da strumenti e consulenze che non possono sostenere nel lungo periodo. Per evitarlo, il valore del programma andrà misurato su tre cose: quanti processi restano utili dopo il primo anno, quanta competenza rimane nel team ospitante e quanto controllo mantengono le organizzazioni sui propri dati. Un progetto AI riuscito non è quello che produce una demo brillante, ma quello che continua a funzionare quando il fellow se ne va.
Un altro aspetto da seguire è il rapporto tra standardizzazione e contesto locale. Le non profit possono condividere molte esigenze, dalla rendicontazione alla raccolta fondi, ma lavorano in comunità diverse, con vincoli diversi e spesso con dati molto sensibili. Un programma nazionale dovrà evitare la tentazione di imporre ricette identiche. La parte più utile potrebbe nascere proprio dal confronto tra casi: quali automazioni funzionano in una food bank, quali in un’organizzazione educativa, quali in un’associazione sanitaria o ambientale. Se Anthropic saprà trasformare queste lezioni in guide pratiche e riusabili, il beneficio andrà oltre i 1.000 fellows iniziali.
DXC porta Claude nei sistemi regolati di banche e compagnie aeree
Nella stessa finestra, Anthropic ha annunciato anche una alleanza pluriennale con DXC Technology. Qui il tono cambia completamente: non più non profit, ma sistemi mission-critical. DXC formerà decine di migliaia di ingegneri certificati su Claude per portare l’AI nei sistemi che gestisce per grandi banche, compagnie aeree, assicurazioni, aziende manifatturiere e agenzie governative. È il tipo di annuncio che racconta quanto l’AI aziendale si stia spostando verso l’integrazione profonda.
DXC non è una startup che sperimenta in laboratorio. È un grande fornitore di servizi IT con sistemi legacy, contratti lunghi e clienti che non possono permettersi errori banali. Anthropic sottolinea che DXC opera con circa 115.000 dipendenti in 70 Paesi e che ha già usato Claude internamente per costruire DXC OASIS, piattaforma AI-native per managed services. Secondo la società, più del 95% del codice di OASIS è stato generato con Claude prima della revisione umana e lo sviluppo sarebbe stato accelerato di 10 volte.
Questi numeri vanno presi come claim aziendali, non come misurazioni accademiche indipendenti. Tuttavia indicano il tipo di narrativa che gli integratori stanno portando ai clienti: non “proviamo un chatbot”, ma “abbiamo già inserito l’AI nel nostro modo di costruire e gestire software”. Se un grande fornitore dimostra di aver usato Claude su sé stesso, può vendere ai clienti un percorso meno astratto.
Le aree iniziali nominate da Anthropic e DXC sono rivelatrici: assicurazioni, modernizzazione del legacy, cybersecurity e application services. Sono ambiti pieni di processi ripetitivi, documentazione tecnica, codice vecchio, regole settoriali e vincoli di compliance. Sono anche settori dove un errore può avere conseguenze economiche o reputazionali importanti. Per questo l’AI non può entrare come scorciatoia senza controllo.
Il passaggio chiave è la figura degli ingegneri “forward-deployed”, cioè tecnici embedded nelle organizzazioni clienti. È un modello che ricorda le migliori pratiche dell’enterprise software: non basta vendere una licenza, bisogna portare competenza dentro i processi. Se gli agenti devono lavorare su sistemi regolati, serve qualcuno che conosca sia il modello sia il dominio. Una compagnia aerea, una banca o un’assicurazione non comprano soltanto capacità generativa; comprano responsabilità operativa.
Questa alleanza rafforza anche un altro messaggio: Claude sta cercando di posizionarsi come modello affidabile per lavoro complesso, sicurezza e settori regolati. Non è una novità assoluta, ma il collegamento con DXC la rende più concreta. L’AI enterprise del 2026 non sarà vinta solo da chi ha il modello più brillante in chat. Sarà vinta da chi riesce a portare modelli dentro sistemi vecchi, sensibili, costosi e pieni di eccezioni.
La sfida sarà distinguere automazione utile da automazione fragile. Nei sistemi regolati, un agente può aiutare a leggere codice legacy, riassumere procedure, individuare anomalie, proporre refactoring o assistere un operatore di sicurezza. Ma ogni passaggio deve essere incastrato in controlli esistenti: change management, segregation of duties, audit trail, incident response e continuità operativa. Se questi pezzi mancano, la promessa di velocità diventa un rischio. Se invece sono presenti, l’AI può ridurre tempi morti e debito tecnico senza chiedere alle aziende di buttare via sistemi che reggono processi critici da decenni.
È anche una prova per il modello commerciale dei laboratori AI. Vendere API a sviluppatori è una cosa; diventare parte della manutenzione di sistemi essenziali è un’altra. Richiede supporto, garanzie, formazione, documentazione, roadmap prevedibili e capacità di spiegare i cambiamenti dei modelli. Se un aggiornamento modifica il comportamento dell’agente, un cliente regolato deve saperlo. Se una funzione viene ritirata, deve avere tempo per adattarsi. L’AI enterprise non può vivere con la stessa volatilità di un prodotto consumer in beta permanente.
Google investe negli operai dell’AI perché il cloud ha bisogno di mani
Il terzo tassello arriva da Google, che tramite Google.org ha annunciato un impegno da 50 milioni di dollari per aiutare a formare oltre 300.000 lavoratori americani nei mestieri tecnici. Nel post ufficiale, Google parla di elettricisti, saldatori, pipefitter, tecnici fibra, lavoratori manifatturieri e altre figure necessarie a costruire e mantenere infrastrutture avanzate. È una notizia AI anche se non parla di un modello nuovo.
Il punto è semplice: l’intelligenza artificiale non vive nel vuoto. Vive in data center, reti elettriche, sistemi di raffreddamento, fibre, trasformatori, cantieri, permessi e manutenzione. Se mancano le persone capaci di costruire e gestire questa base fisica, la corsa ai modelli incontra un limite molto concreto. Google dice che il programma sosterrà 14 sindacati e quattro associazioni di categoria in più di 20 Stati, modernizzando percorsi formativi e integrando strumenti AI nella formazione.
“No single entity can solve this American workforce shortage.”
La frase di Google è rilevante perché sposta la conversazione dall’azienda al sistema. Nessun laboratorio può costruire da solo la forza lavoro necessaria a sostenere l’espansione dell’AI. Servono scuole tecniche, sindacati, imprese, governi locali, utility, community college e percorsi di apprendistato. Il paradosso è che l’AI più avanzata dipende da lavori che molti racconti sul futuro avevano dato per marginali.
Questa iniziativa si inserisce in un quadro più ampio. Google ricorda di aver investito dal 2022 oltre 1 miliardo di dollari in programmi globali di formazione e competenze, raggiungendo più di 100 milioni di persone con skill digitali e AI. Ma il passaggio ai mestieri tecnici è diverso: non riguarda solo usare strumenti digitali, riguarda costruire l’infrastruttura che li rende possibili. È qui che la narrazione dell’AI come software puro mostra il suo limite.
Per l’Europa il messaggio è altrettanto importante. Anche se il programma è americano, il problema è globale. La domanda di energia, il ritmo di costruzione dei data center, le reti di trasmissione, la sostenibilità idrica e la disponibilità di competenze tecniche saranno variabili decisive per chi vuole rimanere competitivo. I modelli possono essere copiati, migliorati o distribuiti via API; la capacità fisica di alimentarli e mantenerli è molto più lenta da costruire.
La conseguenza è che le strategie AI nazionali dovranno parlare con le strategie industriali. Non basta annunciare crediti cloud, sandbox regolatorie o fondi per startup se poi mancano tecnici certificati, tempi di connessione alla rete, siti autorizzati e filiere di componenti. Google lo comunica con una lente americana, ma la lezione riguarda chiunque voglia competere: l’AI richiede capitale paziente, non solo capitale di rischio. Richiede luoghi, lavori e competenze che non crescono alla velocità di una release software.
La lezione per chi segue l’AI è non separare più modello e infrastruttura. Quando si valuta la prossima grande piattaforma, bisogna chiedere anche dove gira, quanto costa raffreddarla, chi la mantiene, quali colli di bottiglia fisici rischiano di rallentarla e quale consenso locale sostiene i cantieri. Nel 2026, l’AI industriale assomiglia sempre più a un settore energetico e infrastrutturale, non soltanto a un mercato software.
Questo ridisegna anche il dibattito sul lavoro. L’AI viene spesso raccontata come una tecnologia che sostituisce mansioni cognitive, ma il suo sviluppo crea domanda in settori molto materiali. Non è una compensazione automatica, né una risposta completa ai timori occupazionali. Però obbliga a leggere la transizione in modo meno binario. Alcuni lavori cambiano o si riducono, altri diventano più richiesti, altri ancora nascono dall’integrazione tra competenze tecniche tradizionali e strumenti digitali. La domanda politica diventa come accompagnare questi passaggi senza lasciare intere comunità fuori dalla nuova infrastruttura.
Trasparenza e provenienza diventano parte del prodotto AI
Nel mezzo di questi annunci, OpenAI ha pubblicato anche il proprio sostegno al Codice europeo sulla trasparenza dei contenuti generati dall’AI. È un tema diverso, ma si collega al quadro del giorno: più l’AI entra in processi reali, più la provenienza dei contenuti diventa una funzione di prodotto, non un accessorio etico da comunicato stampa.
OpenAI afferma di sostenere il codice collegato all’implementazione dell’AI Act e richiama il lavoro su metadati C2PA, watermark SynthID e strumenti pubblici di verifica. Il dettaglio tecnico è importante perché nessun segnale è perfetto. I metadati possono essere rimossi, i watermark possono degradare e le etichette servono solo se gli utenti le incontrano nel punto giusto. Per questo la provenienza sta diventando un sistema multi-livello: segnali nel file, standard interoperabili, verifica pubblica, policy di piattaforma e collaborazione tra aziende.
La connessione con la notizia Ona è più stretta di quanto sembri. Se Codex e gli altri agenti generano codice, immagini, documenti, report o modifiche operative, le organizzazioni avranno bisogno di sapere che cosa è stato prodotto da un modello, quale modello ha agito, con quale contesto e con quali passaggi di revisione. La provenienza non riguarda solo deepfake e disinformazione. Riguarda anche accountability interna.
Per i team che useranno agenti persistenti, questo diventa un requisito pratico. Un documento generato da AI deve poter essere riconosciuto. Una modifica al codice deve avere una storia leggibile. Un’immagine creata con strumenti generativi deve portare segnali di origine quando possibile. Un’analisi automatizzata deve dichiarare fonti, limiti e assunzioni. Senza questa disciplina, il rischio non è solo normativo; è decisionale. Le persone potrebbero fidarsi troppo di artefatti di cui non conoscono la genesi.
Qui l’Europa continua a giocare un ruolo di pressione regolatoria. Le aziende americane possono discutere tempi, dettagli e limiti tecnici, ma stanno adattando prodotti e messaggi al fatto che i mercati chiedono trasparenza. Per chi costruisce prodotti AI, il consiglio è semplice: non aspettare che l’obbligo arrivi come emergenza. Progettare da subito log, provenienza, etichette e verifica rende meno costoso scalare in settori regolati.
Va però evitata una falsa sicurezza. La provenienza non dice che un contenuto è vero, dice qualcosa sulla sua origine o sul modo in cui è stato prodotto. Un’immagine con segnali corretti può essere comunque ingannevole nel contesto sbagliato; un documento tracciato può contenere errori; una patch generata da un agente può essere firmata e comunque introdurre un bug. La trasparenza serve a migliorare la valutazione, non a sostituirla. Per questo deve essere affiancata da alfabetizzazione, controlli editoriali, verifica tecnica e responsabilità umana.
La competenza utile: progettare ambienti di lavoro per agenti
Il consiglio operativo della giornata riguarda chi sta introducendo agenti in azienda. Non partite dal modello, partite dall’ambiente. Se un team vuole usare Codex, Claude o un altro agente per lavoro reale, dovrebbe prima disegnare una scheda minima del workspace: quali sistemi sono accessibili, quali permessi sono concessi, quali dati sono esclusi, quali azioni richiedono approvazione, dove finiscono i log e chi ha responsabilità finale.
Il primo passo è scegliere un processo con confini chiari. Per esempio: triage di bug non critici, aggiornamento di test, migrazione di documentazione, analisi di log, preparazione di report o controllo di vulnerabilità note. Evitate di iniziare con processi dove l’agente può cambiare produzione, inviare comunicazioni esterne o modificare dati sensibili. L’obiettivo non è dimostrare che l’AI può fare tutto, ma costruire fiducia su un flusso misurabile.
Il secondo passo è ridurre i permessi. Un agente dovrebbe avere accesso solo agli strumenti necessari per il compito. Se deve aprire una pull request, non deve poter fare deploy. Se deve leggere ticket e codice, non deve vedere payroll o dati clienti non pertinenti. Se deve generare una bozza di risposta, non deve inviarla senza conferma. Questa disciplina può sembrare lenta, ma è ciò che permette di scalare senza trasformare l’agente in una fonte di rischio.
Il quinto passo, spesso dimenticato, è formare chi deve revisionare. Un revisore umano non può limitarsi a leggere l’output finale. Deve capire quali fonti sono state usate, quali test sono stati eseguiti, quali ipotesi sono rimaste aperte e quali parti richiedono una verifica indipendente. In un buon workflow, l’agente non consegna solo un risultato: consegna una traccia di lavoro abbastanza chiara da rendere la revisione più rapida, non più confusa.
Il terzo passo è misurare il risultato con metriche concrete. Tempo risparmiato, percentuale di task accettati senza modifiche sostanziali, errori introdotti, revisioni richieste, incidenti evitati, soddisfazione del team e costo per attività completata. Senza misure, l’AI resta impressione. Con misure, diventa processo migliorabile. È la differenza tra usare un assistente perché è nuovo e usarlo perché produce valore verificabile.
Il quarto passo è creare una procedura di stop. Ogni agente serio deve avere limiti di budget, durata, numero di azioni, soglie di incertezza e casi in cui passa la mano. Se incontra informazioni contraddittorie, credenziali mancanti, test instabili o richieste fuori perimetro, deve fermarsi e chiedere revisione. Un buon agente non è quello che procede sempre; è quello che sa quando non procedere.
Questa competenza diventerà più preziosa nei prossimi mesi. Le aziende non cercheranno solo prompt engineer. Cercheranno persone capaci di progettare ambienti di lavoro per agenti: metà product manager, metà security analyst, metà process owner. È un profilo ibrido, ma è probabilmente uno dei più concreti nella nuova fase dell’AI.
Una regola semplice può aiutare: ogni agente dovrebbe avere un “contratto di lavoro” leggibile. Non un documento giuridico complesso, ma una scheda che dica obiettivo, strumenti, limiti, dati accessibili, output attesi, metriche e casi di stop. Se questa scheda non si riesce a scrivere in modo chiaro, il processo non è ancora pronto per essere delegato. Se invece la scheda è chiara, il team può discutere rischi e benefici prima di spendere tempo in integrazioni.
Cosa monitorare ora tra acquisizioni, lavoro e infrastruttura
Il primo punto da monitorare è la chiusura dell’acquisizione di Ona. Finché l’operazione non sarà completata, OpenAI e Ona resteranno entità separate. Se il deal si chiuderà, bisognerà guardare come Codex integrerà gli ambienti persistenti: quali clienti potranno usarli, con quali controlli, quali cloud saranno supportati e quanto sarà semplice collegarli a repository, ticketing, CI e ambienti aziendali.
Il secondo punto è l’adozione reale di Claude Corps. Il numero iniziale è grande, ma il risultato dipenderà da esecuzione e misurazione. Quante non profit riusciranno a trasformare il fellow in capacità interna? Quali casi d’uso emergeranno davvero? Quanto resterà dopo dodici mesi? Se Anthropic pubblicherà risultati credibili, il programma potrebbe diventare un modello replicabile. Se resterà soprattutto comunicazione, il mercato lo tratterà come filantropia difensiva.
Il terzo punto è l’alleanza DXC-Anthropic. Qui gli indicatori da guardare sono clienti, settori, incidenti, certificazioni e casi d’uso. L’AI nei sistemi regolati non avanza solo con annunci: avanza quando clienti conservativi accettano di usarla su processi reali. Modernizzazione legacy, cybersecurity e assicurazioni sono terreni perfetti per creare valore, ma anche per mettere alla prova limiti, audit e responsabilità.
Il quarto punto è il lato fisico dell’AI. L’investimento di Google.org sui mestieri tecnici non sarà l’ultimo. Se la domanda di data center continua a salire, vedremo più programmi su elettricisti, raffreddamento, energia, fibra, manutenzione e sicurezza degli impianti. Per capire chi può scalare davvero, non basterà leggere i benchmark. Bisognerà guardare supply chain, rete elettrica, cantieri e consenso locale.
Infine, va osservata la convergenza tra governance e prodotto. La stessa settimana in cui OpenAI parla di ambienti persistenti per agenti, parla anche di provenienza e trasparenza dei contenuti AI in Europa. Non è una coincidenza: più gli strumenti diventano capaci, più devono diventare spiegabili, tracciabili e inseriti in regole. Il messaggio della giornata è questo: l’AI sta diventando infrastruttura. E quando una tecnologia diventa infrastruttura, non basta che funzioni. Deve poter essere controllata, capita, mantenuta e governata.
La sintesi operativa è quindi prudente, ma non difensiva. OpenAI sta cercando il workspace degli agenti, Anthropic sta cercando canali di distribuzione sociale e aziendale, Google sta lavorando sul lato fisico della scala. Sono tre risposte diverse alla stessa domanda: come si porta l’AI fuori dalla prova individuale e dentro il mondo che deve usarla ogni giorno? La risposta non sarà un modello unico. Sarà un insieme di ambienti, persone, regole e infrastrutture abbastanza robusto da reggere quando l’entusiasmo lascia spazio all’uso quotidiano.
Per chi deve decidere investimenti, la bussola è questa: privilegiare strumenti che mostrano controlli, integrazione e competenze intorno al modello. La potenza pura resta importante, ma la differenza competitiva emergerà da ciò che permette al modello di lavorare bene senza creare caos operativo.