La giornata dell’AI si è concentrata su una domanda molto concreta: chi controlla gli agenti quando smettono di essere semplici finestre di chat e iniziano a lavorare nei sistemi reali? La risposta non è arrivata da un solo annuncio. È arrivata, in parallelo, da Microsoft Build, dall’espansione di Project Glasswing di Anthropic, da un nuovo ordine esecutivo della Casa Bianca e da un incidente di sicurezza che ha coinvolto l’assistente di supporto AI di Meta.
Il filo comune è evidente: l’industria sta passando dalla fase “modello più intelligente” alla fase “modello con permessi, memoria, strumenti e responsabilità”. Microsoft vuole trasformare agenti, dati aziendali, Foundry, GitHub, Windows e Copilot in un’unica piattaforma governata. Anthropic sta ampliando l’accesso controllato a Claude Mythos Preview, un modello cyber potente abbastanza da rendere urgente il tema della patch velocity. Washington prova a disegnare un canale volontario di valutazione per i modelli frontier. Meta, invece, mostra cosa può succedere quando un agente ha troppa autonomia in una procedura sensibile.
Per chi usa l’AI sul lavoro, il punto pratico è semplice: il vantaggio non sarà solo scegliere il modello migliore, ma progettare bene il contesto in cui quel modello agisce. La newsletter di oggi legge le novità come un unico cambiamento operativo: agenti più presenti, modelli cyber più capaci, governi più coinvolti e una nuova disciplina quotidiana per chi deve mettere l’AI in produzione senza trasformarla in un rischio.
Microsoft Build porta gli agenti dentro lo stack aziendale
La notizia principale arriva da Microsoft Build 2026, dove Microsoft ha presentato una visione molto più ampia del solito Copilot. Il messaggio non è “un altro chatbot”, ma un sistema in cui agenti, dati, sviluppo software, sicurezza e dispositivi locali devono funzionare come un’infrastruttura unica. Nel post ufficiale di Build, Microsoft descrive tre assi: agenti radicati nel contesto dell’organizzazione, uno stack multi-modello dal laptop al cloud e nuove piattaforme scientifiche basate su agenti.
La parte più importante è Microsoft IQ, che diventa disponibile attraverso GitHub Copilot, Microsoft Foundry e Copilot Studio. L’idea è costruire un livello di contesto che unisca conoscenza del mondo, dati aziendali e lavoro quotidiano. Work IQ guarda a email, documenti, riunioni, persone e flussi organizzativi. Fabric IQ crea una base semantica sui dati strutturati. Foundry IQ collega recupero di informazioni aziendali e web. Web IQ, annunciato nella stessa giornata, aggiunge una ricerca web model-agnostic e nativa MCP, pensata per dare grounding agli agenti.
Questo cambia la competizione. Fino a poco tempo fa molte aziende valutavano l’AI chiedendosi quale modello rispondesse meglio. Microsoft sta dicendo che il vantaggio nasce dal modo in cui il modello viene inserito nel flusso: connesso ai dati, distribuito su strumenti già usati, osservabile, governato e sostituibile. Per un team IT questa è una differenza enorme, perché riduce il rischio di costruire prototipi brillanti ma impossibili da portare in produzione.
“Platforms don’t shift on their own; developers build them forward.”
La frase, pubblicata da Microsoft nel riepilogo ufficiale di Build 2026, sintetizza bene il tono dell’annuncio: non basta avere modelli potenti, servono strumenti da sviluppatore e controlli da impresa. Qui entrano Agent 365, ASSERT, Agent Control Specification e Codename MDASH. Agent 365 estende Entra, Defender e Purview agli agenti locali; ASSERT punta alla valutazione policy-driven; Agent Control Specification prova a standardizzare dove applicare i controlli nel ciclo dell’agente; MDASH usa più di cento agenti per cercare bug sfruttabili e proporre fix nel Defender Portal.
È una mossa molto Microsoft: prendere un fenomeno ancora caotico e trasformarlo in categorie amministrabili. Un agente non è più soltanto una conversazione intelligente, ma un’identità, un contesto, un set di permessi, una sandbox, una memoria e una superficie di audit. Chi costruisce software aziendale dovrà ragionare nello stesso modo in cui oggi ragiona su utenti, ruoli, API key, log e segregazione degli ambienti.
La seconda novità forte riguarda i modelli proprietari. Microsoft ha presentato la famiglia MAI, con MAI-Thinking-1 come primo modello di reasoning interno: 35 miliardi di parametri attivi, finestra di contesto da 256K token e disponibilità in private preview su Foundry. Accanto ci sono MAI-Image-2.5, MAI Transcribe 1.5, MAI-Voice-2 e MAI-Code-1, quest’ultimo già disponibile in Copilot e VS Code. Il segnale è che Microsoft non vuole restare solo orchestratore di modelli terzi: vuole un catalogo proprio, integrato nei suoi canali di distribuzione.
Questo non significa chiusura. Microsoft insiste sul multi-modello: i modelli MAI arriveranno anche su Fireworks AI, Baseten e OpenRouter, mentre Fireworks AI è ora generalmente disponibile su Foundry. Il messaggio ai developer è pragmatico: potete usare modelli diversi, ma dentro una piattaforma che garantisce governance, residenza dati e gestione enterprise. È un posizionamento diretto contro la frammentazione attuale, dove molti team testano modelli su più provider senza una vera cabina di controllo.
Build ha anche collegato gli agenti al dispositivo locale. Surface RTX Spark Dev Box, basato su NVIDIA RTX Spark, promette fino a un petaflop di compute AI e 128 GB di memoria unificata, con capacità di eseguire localmente modelli fino a 120 miliardi di parametri e contesti fino a un milione di token, secondo Microsoft e NVIDIA. È un messaggio coerente con il trend dei PC AI: alcune attività agentiche non dovranno per forza passare dal cloud, soprattutto quando privacy, latenza, costi o sviluppo locale contano.
La parte meno appariscente ma più strategica è Microsoft Execution Containers, ora in preview. Sono sandbox a livello di sistema operativo per agenti e workflow multi-step, usate anche da OpenClaw su Windows. In pratica Microsoft prova a trasformare Windows in un runtime agentico: non solo un ambiente dove l’utente apre app, ma un sistema che può confinare agenti, applicare policy, instradare inferenza e proteggere dati sensibili. Se questa architettura regge, il desktop torna centrale nell’AI, non come nostalgia del software installato, ma come luogo controllato in cui agenti e dati locali possono incontrarsi.
Infine c’è Microsoft Scout, presentato sul blog Microsoft 365 come agente personale sempre attivo. Scout appartiene alla nuova categoria degli Autopilots: agenti che restano in background, hanno una propria identità operativa e possono agire per conto dell’utente entro permessi e policy definiti. Per ora Microsoft parla di accesso ai clienti Frontier e di attività come preparazione delle riunioni, conflitti di calendario e routine di lavoro. La direzione, però, è chiara: l’agente personale non aspetta più ogni prompt, ma osserva il contesto e propone azioni.
Per chi compra tecnologia in azienda, questo sposta anche le domande da fare ai vendor. Non basta chiedere se il modello è migliore in coding, ricerca o immagini: bisogna chiedere dove vivono i dati, come vengono valutate le azioni dell’agente, quali log restano disponibili, come si revoca un permesso e quale modello alternativo può sostituire quello predefinito. La piattaforma più convincente sarà quella che rende questi controlli noiosi, ripetibili e verificabili, non quella che mostra solo la demo più fluida sul palco.
Questo è potente e delicato. Un agente sempre attivo nel lavoro quotidiano vale quanto la qualità dei suoi limiti. Se ha poco contesto, diventa rumoroso. Se ha troppo contesto senza controlli, diventa rischioso. La notizia Microsoft va letta quindi insieme agli altri eventi della giornata: agenti con memoria e permessi richiedono una nuova cultura di governance, non soltanto modelli più capaci.
Anthropic allarga Mythos e cambia la pressione sulla cybersecurity
La seconda notizia forte è l’espansione di Project Glasswing. Anthropic ha annunciato che estenderà l’accesso a Claude Mythos Preview a circa 150 nuove organizzazioni in più di 15 Paesi. Non è un rollout pubblico: ogni organizzazione dovrà soddisfare requisiti di sicurezza prima di ottenere accesso. È però un salto notevole rispetto alla prima fase, che coinvolgeva circa 50 partner.
Il punto non è soltanto il numero. Secondo Anthropic, il nuovo gruppo include settori che erano meno rappresentati nel primo cohort: energia, acqua, sanità, comunicazioni, hardware e vendor che mantengono codice usato da molte altre organizzazioni. In altre parole, Mythos non viene trattato come un prodotto consumer, ma come una capacità cyber da distribuire con cautela a chi difende infrastrutture essenziali.
Anthropic sostiene che i partner iniziali abbiano già trovato più di 10.000 vulnerabilità ad alta o critica severità. Nel suo aggiornamento precedente, la società ha indicato anche risultati su progetti open source: più di 1.000 progetti analizzati, 6.202 vulnerabilità stimate come alte o critiche e una quota di veri positivi molto alta tra quelle già verificate da società di sicurezza indipendenti. Sono numeri da leggere con prudenza, perché vengono dalla stessa Anthropic e perché la verifica completa richiede tempo. Ma anche con tutte le cautele, la direzione è chiara: il collo di bottiglia non è più solo trovare i bug, è verificarli, comunicarli e correggerli.
“Cheap, fast AI models with powerful cyber capabilities are around the corner.”
Questa frase, nel post Expanding Project Glasswing, è il cuore dell’annuncio. Anthropic sta dicendo che modelli cyber di classe Mythos potrebbero diventare comuni entro pochi mesi, anche fuori da contesti controllati. Se succede, gli attaccanti avranno strumenti migliori per trovare e sfruttare falle, ma anche i difensori potranno automatizzare scansione, triage, patching e pre-release security review.
È qui che la newsletter di oggi diventa più interessante di una semplice lista di annunci. Microsoft sta costruendo agenti con controlli, sandbox e identità. Anthropic sta espandendo un modello cyber potentissimo ma non pubblico. La Casa Bianca sta cercando un meccanismo volontario di valutazione dei modelli frontier. Tutti e tre guardano allo stesso problema: quando l’AI agisce sul software reale, la governance deve diventare parte del prodotto.
Project Glasswing introduce anche Claude Security, uno strumento in beta pubblica per clienti Claude Enterprise che aiuta a scansionare codebase e proporre patch usando modelli pubblici come Claude Opus 4.8. Anthropic afferma inoltre di voler rendere disponibili, su richiesta a team di sicurezza qualificati, gli strumenti usati dai partner Glasswing: skill operative, harness per mappare codebase, subagenti di scansione, triage e threat model builder. Questa è la parte più utile per le aziende che non avranno accesso a Mythos ma vogliono prepararsi a modelli cyber più potenti.
Il rischio operativo è l’effetto valanga. Se un modello trova migliaia di difetti, ma un team riesce a validarli e correggerli lentamente, la dashboard si riempie e la sicurezza peggiora invece di migliorare. Il lavoro necessario non è soltanto comprare un tool, ma accorciare cicli di patch, migliorare test di regressione, automatizzare l’inventario delle dipendenze e avere una procedura chiara per decidere quali bug correggere subito.
Per gli sviluppatori, Mythos è un promemoria duro: la qualità del codice non può più essere delegata a revisione umana occasionale e scanner tradizionali. I modelli stanno iniziando a ragionare su exploit chain, business logic, configurazioni e comportamenti emergenti. Se la stessa capacità arriva nelle mani degli attaccanti, il tempo tra scoperta e sfruttamento può ridursi drasticamente. Le organizzazioni che oggi non sanno patchare velocemente dovranno cambiare prima che sia il mercato a costringerle.
La buona notizia è che l’AI può aiutare anche in difesa. Modelli pubblici meno potenti di Mythos possono già generare test, spiegare vulnerabilità, suggerire patch e creare runbook. Il consiglio pratico è iniziare da flussi limitati e verificabili: un repository, una categoria di bug, una policy di triage, un set di test automatici e una revisione umana finale. Non serve trasformare tutto in un SOC agentico in una settimana. Serve costruire muscolo operativo.
Anthropic, però, pone anche una domanda politica: chi decide chi può usare un modello cyber avanzato? L’azienda sostiene che non esistano ancora salvaguardie abbastanza robuste per rilasciare pubblicamente capacità di questo livello. Allo stesso tempo, afferma che centinaia di migliaia di organizzazioni avranno bisogno di accesso a strumenti avanzati per difendersi. È una tensione reale: accesso ristretto protegge dal misuse, ma accesso troppo ristretto lascia vulnerabili molti difensori.
Washington sceglie un controllo volontario sui modelli frontier
La terza notizia è l’ordine esecutivo della Casa Bianca su innovazione e sicurezza nell’AI avanzata. Il testo ufficiale stabilisce una serie di scadenze per rafforzare la cyberdifesa dei sistemi federali e creare un processo di valutazione dei modelli frontier. La parte più sensibile è la sezione sul deployment sicuro: entro 60 giorni, Treasury, Department of War, NSA, DHS, CISA, NIST e altri uffici dovranno sviluppare un processo classificato di benchmark per valutare le capacità cyber avanzate dei modelli.
L’ordine prevede un framework volontario: gli sviluppatori potranno chiedere al governo di valutare se un modello in sviluppo rientra nella categoria di covered frontier model; potranno fornire accesso al governo per un periodo fino a 30 giorni prima del rilascio ad altri partner fidati; e potranno collaborare alla selezione di soggetti che riceveranno accesso anticipato per rafforzare la cyberdifesa delle infrastrutture critiche.
“Nothing in this section shall be construed to authorize” mandatory licensing.
La clausola, contenuta nell’ordine pubblicato dalla Casa Bianca, è importante perché definisce il compromesso politico: più coordinamento e valutazione, ma nessun sistema obbligatorio di licenza o pre-clearance per pubblicare nuovi modelli. Per chi segue l’AI policy, è il punto di equilibrio tra sicurezza nazionale e timore di frenare la competizione americana.
L’ordine richiede anche un AI cybersecurity clearinghouse in collaborazione volontaria con industria e operatori di infrastrutture critiche. Il suo compito sarà coordinare scansione delle vulnerabilità, validazione, priorità di remediation e distribuzione delle patch. È un passaggio molto collegato al problema Anthropic: se modelli come Mythos moltiplicano i finding, serve un meccanismo per evitare duplicazioni, disclosure caotiche e sovraccarico dei maintainer.
Il testo spinge poi le agenzie federali a facilitare l’accesso a strumenti di cyberdifesa AI-enabled per autorità statali e locali, ospedali rurali, banche di comunità e utility. Questo dettaglio è rilevante perché porta il discorso fuori dalle big tech. Il rischio cyber dei modelli frontier non riguarda solo le aziende che costruiscono AI, ma anche enti con budget limitati e sistemi legacy. Se il governo vuole davvero usare l’AI per la difesa, dovrà aiutare proprio questi soggetti a ricevere strumenti, competenze e priorità di patching.
La lettura politica è doppia. Da un lato, l’ordine è meno duro di un regime obbligatorio di pre-approvazione. Dall’altro, crea una porta istituzionale per osservare modelli prima del rilascio e definire soglie classificate di rischio. Per i laboratori AI, significa che la relazione con Washington diventa parte della roadmap. Per le aziende clienti, significa che i modelli con capacità cyber avanzate potrebbero arrivare con condizioni, audit e partner program più complessi.
Qui vale una distinzione: non tutti i modelli frontier sono uguali. Un modello molto bravo a scrivere testi o generare immagini non pone lo stesso tipo di problema di un modello che può automatizzare catene di exploit. L’ordine parla di advanced cyber capabilities, non di AI in generale. Questo aiuta a evitare panico generalizzato, ma richiede benchmark affidabili. Se la soglia è troppo bassa, il sistema diventa rumore burocratico; se è troppo alta, il governo arriva quando le capacità sono già diffuse.
Per il mercato europeo, l’ordine USA è un segnale da osservare. L’Europa ha già l’AI Act, ma la questione Mythos è più specifica: come gestire modelli dual-use che sono utilissimi ai difensori e pericolosi per gli attaccanti. Se Washington sceglie il canale volontario, Bruxelles potrebbe spingere su accesso controllato, standard di disclosure e cooperazione con agenzie di cybersecurity come ENISA. La notizia non chiude il dibattito, lo apre.
Meta mostra il rischio degli agenti con permessi sensibili
Il caso Meta AI Support Assistant è più piccolo delle mosse di Microsoft, Anthropic e Washington, ma è forse il più facile da capire. Secondo TechCrunch, alcuni account Instagram sono stati compromessi sfruttando il supporto AI di Meta. Il flusso descritto è inquietante: l’attaccante avrebbe usato una VPN per sembrare nella regione del target, poi avrebbe chiesto al chatbot di aggiungere un nuovo indirizzo email all’account e avrebbe completato la procedura di reset.
Instagram ha dichiarato che il problema è stato risolto. Resta però la lezione: un agente che può modificare credenziali, email, recovery flow o permessi non è un semplice bot di supporto. È una componente di sicurezza. Se l’agente accetta una richiesta sbagliata, l’errore non produce una risposta imprecisa, produce un takeover.
Questo incidente collega in modo concreto tutto il resto della giornata. Microsoft parla di agenti governati da identità, policy e sandbox. Anthropic parla di modelli cyber che possono scoprire vulnerabilità a scala. Washington parla di benchmark e accesso anticipato. Meta mostra che il rischio non è solo teorico: quando l’AI entra nei workflow operativi, ogni azione sensibile deve essere trattata come una transazione ad alto rischio.
La differenza tra un agente utile e un agente pericoloso è spesso nel design dei permessi. Un assistente può spiegare come recuperare un account; un altro può cambiare l’email associata a quell’account. Un agente può preparare una bozza di risposta; un altro può inviarla a clienti o autorità. Un modello può suggerire una patch; un altro può modificarla direttamente nel repository. Più l’AI si avvicina all’azione, più serve separare consiglio, proposta, approvazione ed esecuzione.
Per le aziende, il caso Meta offre una regola pratica: non dare all’agente un permesso che non sapresti monitorare, revocare e giustificare. Se un agente può cambiare dati critici, deve avere log leggibili, controlli di rischio, limiti di frequenza, escalation umana e test contro social engineering. Se un agente gestisce recupero account, deve verificare segnali indipendenti, non solo seguire una conversazione apparentemente coerente.
Il punto non è demonizzare i support bot. Il supporto clienti è uno dei casi d’uso più naturali per l’AI, perché unisce documentazione, conversazioni ripetitive e necessità di disponibilità continua. Ma l’AI deve essere usata in modo diverso a seconda del livello di rischio. Rispondere a una domanda sulla garanzia non è uguale a cambiare un metodo di autenticazione. Il primo può essere automatizzato con controlli leggeri; il secondo richiede una pipeline di verifica più dura.
Questo vale anche per gli agenti personali come Scout. Preparare un riepilogo prima di una riunione è poco rischioso. Spostare appuntamenti, scrivere a colleghi, accedere a documenti riservati o prenotare viaggi richiede policy. La promessa dell’agente sempre attivo è liberare attenzione, ma il costo nascosto è costruire un sistema che sappia quando fermarsi.
Il tool da provare è un processo, non un’app
La rubrica tool di oggi non riguarda un singolo servizio da installare, ma un progetto operativo da avviare: una agent permission matrix. È una matrice semplice che aiuta team prodotto, sicurezza e operations a decidere cosa può fare un agente, con quali dati, in quali condizioni e con quale livello di supervisione. È il tipo di strumento che diventerà indispensabile man mano che agenti come Scout, Copilot, Foundry Agent Service e support bot interni passeranno dalla demo all’uso quotidiano.
La matrice parte da quattro livelli. Il primo è read-only: l’agente può leggere dati approvati e generare risposte o sintesi, ma non modifica nulla. Il secondo è draft: l’agente prepara azioni, email, ticket, patch o comandi, ma un umano deve approvare. Il terzo è bounded execute: l’agente può eseguire azioni entro limiti espliciti, per esempio aprire un ticket, aggiornare un campo non sensibile o creare un branch di lavoro. Il quarto è privileged execute: l’agente può intervenire su account, pagamenti, sicurezza, dati personali o sistemi di produzione.
Ogni agente dovrebbe essere mappato su questa scala per funzione, non in blocco. Un assistente HR può essere read-only sui documenti di policy, draft sulle comunicazioni interne e completamente bloccato su retribuzioni o dati sanitari. Un agente di sviluppo può proporre patch, creare test e aprire pull request, ma non fare merge in produzione. Un support bot può guidare il recupero account, ma non cambiare email senza segnali indipendenti e controllo umano.
Il secondo elemento della matrice è il contesto consentito. Microsoft parla molto di Work IQ e dati aziendali perché il contesto è il carburante degli agenti. Ma non tutto il contesto deve essere disponibile sempre. Un agente di riunioni non dovrebbe leggere automaticamente ogni documento aziendale. Un agente di sales non dovrebbe accedere a dati finanziari non necessari. Un agente di sicurezza può aver bisogno di log e repository, ma non di inbox personali. La regola è minimizzare il contesto come si minimizzano i privilegi.
Il terzo elemento è la verifica dell’azione. Per azioni a basso rischio può bastare un log. Per azioni medie serve approvazione esplicita. Per azioni alte servono controlli multipli: autenticazione forte, conferma fuori banda, limiti temporali, revisione successiva e possibilità di rollback. Il caso Meta suggerisce che la conversazione stessa non può essere l’unica prova di identità. Un attaccante bravo a convincere un agente può sembrare più coerente di un utente legittimo in difficoltà.
Il quarto elemento è la misurazione. Un agente non va valutato solo su quante attività completa, ma su quante ne rifiuta correttamente. Quanti tentativi sospetti blocca? Quante escalation produce? Quante azioni vengono annullate? Quanti falsi positivi creano attrito inutile? Qui strumenti come ASSERT e specifiche di controllo possono diventare utili, perché portano metriche e test in un dominio spesso gestito a impressioni.
Il quinto elemento è il piano di incident response. Se un agente compie un’azione sbagliata, il team deve sapere come congelare credenziali, sospendere workflow, recuperare log, notificare utenti, ripristinare dati e aggiornare policy. L’errore di un agente non è sempre un bug applicativo: può essere un incidente di sicurezza. La differenza si vede nella preparazione.
Per iniziare, non serve una piattaforma complessa. Serve un documento condiviso con dieci agenti o workflow candidati, quattro livelli di permesso, dati accessibili, azioni consentite, approvazioni richieste, log e owner. Poi si sceglie un solo agente da portare da read-only a draft e si osserva cosa succede. La maturità agentica non nasce dal numero di automazioni, ma dalla chiarezza con cui si decide dove l’automazione deve fermarsi.
La skill utile è ridurre il rischio prima del prompt
Il consiglio pratico della giornata riguarda il modo di progettare prompt e workflow per agenti che hanno accesso a strumenti. Molti team iniziano dal prompt: “sei un assistente esperto, fai questo”. È comprensibile, ma insufficiente. Con agenti dotati di strumenti, il prompt arriva dopo la definizione del perimetro. Prima si decide cosa l’agente può vedere, cosa può fare, cosa deve chiedere e cosa deve rifiutare.
Una tecnica utile è scrivere un action contract prima del prompt. L’action contract descrive in linguaggio semplice tre cose: obiettivo, limiti, condizioni di escalation. Per esempio: “L’agente può preparare una risposta a un cliente usando solo documenti pubblici e ticket aperti; non può promettere rimborsi; deve chiedere approvazione se il cliente cita dati personali, minaccia azioni legali o chiede modifica di account”. Solo dopo questo contratto si scrive il prompt.
Il prompt, a quel punto, non deve essere creativo ma disciplinato. Deve ricordare all’agente che gli strumenti non sono scorciatoie, che le azioni irreversibili richiedono conferma, che l’assenza di dati è un risultato valido e che la richiesta dell’utente non basta a superare le policy. Questo approccio sembra meno spettacolare di un agente completamente autonomo, ma riduce il rischio di errori costosi.
La seconda skill è costruire test avversariali realistici. Non basta chiedere al modello di comportarsi bene. Bisogna simulare utenti confusi, utenti arrabbiati, richieste incomplete, tentativi di social engineering, istruzioni contraddittorie e casi in cui i dati sembrano confermare una richiesta fraudolenta. Se l’agente gestisce supporto account, testate VPN, cambio email, reset multipli e richieste su account ad alto valore. Se gestisce codice, testate prompt injection nei repository, issue malevole e dipendenze sospette.
La terza skill è misurare l’agente con una metrica che premi il rifiuto corretto. Molte dashboard mostrano task completati, tempo risparmiato e soddisfazione. Servono anche metriche di safe completion: azioni bloccate, escalation appropriate, richieste fuori policy, tentativi di accesso anomali, interventi umani correttivi. Un agente maturo non è quello che dice sempre sì, ma quello che sa distinguere quando l’automazione non deve proseguire.
La quarta skill è separare modello e workflow. Se un modello sbaglia, è utile poter sostituire modello, prompt o retrieval senza riscrivere tutto. Se un workflow è mal progettato, cambiare modello non basta. È qui che l’approccio di Microsoft, con specifiche di controllo e piattaforme multi-modello, diventa interessante anche per chi non usa Microsoft: il principio generale è progettare agenti come sistemi modulari, non come prompt giganti.
La quinta skill è documentare le assunzioni. Ogni agente nasce con ipotesi: quali utenti sono autorizzati, quali dati sono affidabili, quali azioni sono reversibili, quali errori sono accettabili. Quando quelle ipotesi cambiano, il rischio cambia. Un agente costruito per un team interno può diventare pericoloso se esposto a clienti. Un agente che scrive bozze può diventare pericoloso se ottiene permessi di invio. La documentazione serve a vedere questi passaggi prima che diventino incidenti.
Applicata alle notizie di oggi, questa skill produce una checklist semplice. Se volete sperimentare agenti personali, partite da read-only e draft. Se volete usare AI per sicurezza software, iniziate da scanning e triage prima di patch automatiche. Se dovete gestire dati sensibili, imponete conferme fuori banda. Se un vendor promette autonomia totale, chiedete dove sono log, policy, benchmark e rollback. È meno affascinante di una demo, ma è ciò che distingue l’adozione seria dall’entusiasmo fragile.
Cosa monitorare tra agenti aziendali e cyber AI
Nelle prossime settimane il primo elemento da seguire sarà la disponibilità reale di Microsoft Scout, delle API Work IQ e dei modelli MAI su Foundry. Gli annunci di Build sono ampi, ma il loro impatto dipenderà da pricing, regioni, controlli amministrativi, qualità dei connettori e facilità di integrazione. Un agente personale sempre attivo è utile solo se non diventa rumore, se rispetta i confini aziendali e se si integra con strumenti già usati.
Il secondo elemento è l’evoluzione di Project Glasswing. Anthropic vuole espandere ancora il programma e, in futuro, arrivare a capacità Mythos-level in accesso più generale. La domanda chiave è quale salvaguardia potrà permettere un rilascio più ampio senza consegnare capacità offensive a chiunque. Guardate anche Claude Security: se diventa un prodotto maturo, potrebbe portare parte dei benefici difensivi a organizzazioni senza accesso a Mythos.
Il terzo elemento è il framework della Casa Bianca. Le scadenze di 30 e 60 giorni diranno se l’ordine resta una cornice politica o diventa infrastruttura concreta: benchmark, clearinghouse, canali con i laboratori AI e criteri per i partner fidati. Il dettaglio più importante sarà la definizione operativa di “covered frontier model”. Senza una soglia chiara, il sistema rischia di essere troppo largo o troppo stretto.
Il quarto elemento è la risposta delle piattaforme consumer agli incidenti di supporto agentico. Il caso Meta non sarà l’ultimo. Ogni azienda che automatizza recupero account, moderazione, pagamenti o accesso a dati sensibili dovrà dimostrare che l’agente non può essere convinto a saltare la verifica. I prossimi incidenti potrebbero arrivare da e-commerce, banche, SaaS, telco o piattaforme creator.
Il quinto elemento è il ruolo degli standard. MCP sta diventando un linguaggio comune per collegare agenti a strumenti e dati; specifiche come Agent Control Specification provano a definire dove mettere controlli; benchmark cyber come quelli citati da Anthropic misurano capacità sempre più pericolose. L’adozione dell’AI agentica dipenderà da questi strati invisibili almeno quanto dai modelli in classifica.
La sintesi della giornata è che l’AI si sta spostando dal contenuto all’azione. Microsoft vuole industrializzare gli agenti, Anthropic vuole controllare la diffusione di capacità cyber avanzate, Washington vuole osservare i modelli prima che arrivino al mercato e Meta mostra quanto fragile possa essere un agente operativo se il perimetro è sbagliato. Per chi costruisce o usa AI, la priorità non è inseguire ogni annuncio: è scegliere dove concedere autonomia, come misurarla e quando riprendersi il controllo.