TL;DR: Dal 10 settembre 2026 Copilot Studio e Copilot Cowork generano applicazioni aziendali complete a partire da una descrizione in linguaggio naturale, non più solo agenti conversazionali. È un cambio di natura della piattaforma, più rilevante dell’arrivo di GPT‑6 Astra: sposta il problema dalla qualità del modello alla governance del codice che nessun umano ha scritto. I dati sul vibe coding dicono che quel problema è reale.
A luglio ho raccontato su questo blog come ho costruito “Bussola”, il mio primo agente serio in Copilot Studio, in una notte. Era un agente: rispondeva, cercava, orchestrava qualche tool. Il codice, nel senso classico, non c’era, e la cosa mi sembrava già abbastanza vertiginosa. Due mesi dopo la stessa piattaforma mi propone, dalla home page, un pulsante App (Preview) accanto ad Agenti e Workflow. Descrivo cosa voglio, e Copilot Studio mi restituisce un’applicazione: interfaccia, dati, azioni, codice ispezionabile.
Nella mia esperienza, trent’anni di IT insegnano una cosa: quando lo strumento diventa facile, il problema si sposta su chi ne risponde. È di questo che voglio parlare. Non del modello nuovo, ma di chi firma il codice.
Che cosa è successo davvero a settembre 2026?
In una settimana Microsoft ha rilasciato due novità distinte per Copilot Studio: il modello GPT‑6 Astra (annuncio del 4 settembre) e l’app building in linguaggio naturale (annuncio del 10 settembre, preview in Cowork dall’8 settembre). La prima migliora ciò che la piattaforma già faceva; la seconda cambia ciò che la piattaforma è. Per questo sostengo che la seconda conta di più.
Il post ufficiale è firmato da Ryan Cunningham, Corporate Vice President di Microsoft Copilot Studio e Power Platform, e si apre così: “AI is changing who can build software. People who could never write code can now describe an idea and generate a working application in minutes”. Poi il passaggio che mi interessa: “But generating an application is only part of the equation” — le applicazioni devono connettersi ai dati aziendali, operare in sicurezza e stare dentro i processi esistenti, e “IT needs the governance and controls” (Cunningham, 2026).
Il funzionamento, secondo lo stesso post: in Cowork si invoca la skill /app (disponibile via programma Frontier), in Copilot Studio si sceglie App (Preview) dalla home. Si descrive risultato, utenti, dati e azioni; Copilot Studio usa agentic coding per produrre uno scaffold funzionante; si itera in linguaggio naturale, si vede l’anteprima e — punto chiave — si può “review the underlying code”. Le app usano i connettori per accedere ai dati aziendali. In Copilot Studio il rollout è in public preview “over the next week” dal 10 settembre (Cunningham, 2026).
Il Message Center MC1469329 aggiunge il quadro amministrativo: preview in Cowork dall’8 settembre 2026, Copilot Studio “within the next couple of weeks”, app governate dalle policy esistenti e gestite dal Microsoft 365 admin center (Microsoft, 2026a). La pagina What’s new in Copilot Cowork conferma per settembre 2026 tre ingressi contemporanei: App skill (Frontier), Claude Fable 5.1 e GPT 6 Astra nel selettore modelli (Microsoft Learn, 2026a).
Terminologia che uso nel pezzo. Agente: software che ragiona e agisce su richiesta, conversazionale o autonomo. Workflow: sequenza deterministica di passi. Applicazione agentica: un’app con interfaccia e dati propri, generata e mantenuta tramite AI, che può incorporare agenti e workflow. Citizen developer: chi costruisce software senza essere uno sviluppatore di mestiere. Vibe coding: costruire software dettando all’AI in linguaggio naturale senza leggere il codice prodotto.
In cosa l’app building di Copilot Studio è diverso da Power Apps e dal low-code che conosciamo?
La differenza non è “si fa in linguaggio naturale”: Copilot in Power Apps lo faceva già. La differenza è che l’output è codice applicativo generato da un agente, ispezionabile e versionato, e che nasce nello stesso ambiente in cui vivono agenti e workflow. Il low-code tradizionale nascondeva il codice dietro componenti; qui il codice c’è, ed è scritto da una macchina.
Microsoft Learn documenta da tempo la creazione di app conversazionale in Power Apps: si descrive il bisogno, il servizio genera tabelle Dataverse e una canvas app (Microsoft Learn, 2026b). Il nuovo approccio, secondo il post di Cunningham, serve “a broad spectrum of builders”: l’information worker resta sulla soluzione, il maker avanzato e lo sviluppatore “can go deeper into the app’s structure and code when they need more control” (Cunningham, 2026).
Un confronto sintetico, basato sulle fonti citate e sulla mia lettura:
| Aspetto | Low-code classico (Power Apps) | App building Copilot Studio / Cowork (sett. 2026) |
|---|---|---|
| Input | Designer visuale + Copilot per tabelle | Descrizione in linguaggio naturale, iterazione in chat |
| Output | Canvas/model-driven app su Dataverse | Scaffold applicativo generato via agentic coding, codice ispezionabile |
| Convivenza con agenti | Separata (Copilot Studio a parte) | Stessa home: Agenti, Workflow, App |
| Ciclo di vita dichiarato | Solutions, pipelines Power Platform | Source control, deployment stages e version isolation integrati, su infrastruttura ospitata da Microsoft (jtung, 2026) |
| Chi costruisce | Maker formati | Chiunque abbia licenza e accesso alla preview |
L’ultima riga è il punto: si allarga il perimetro di chi produce software in azienda. Nella mia esperienza, ogni volta che quel perimetro si è allargato — dai fogli Excel con le macro alle prime Power Apps — la governance è arrivata dopo, e a caro prezzo.
Perché la novità più importante non è GPT‑6 Astra?
GPT‑6 Astra è un modello migliore dentro un contenitore che già esisteva; l’app building cambia il contenitore. Un modello più capace alza la qualità delle risposte, ma la responsabilità di ciò che viene prodotto resta dove era. Un’app generata e pubblicata da un non sviluppatore, invece, crea un artefatto software nuovo che qualcuno dovrà mantenere, patchare e difendere.
Il post di Bas Brekelmans sul Microsoft Copilot Blog del 4 settembre 2026 dice che GPT‑6 Astra “joins the frontier models available in Copilot Cowork and Copilot Studio”, che “availability may vary by region and organization” e che gli admin gestiscono l’accesso dal Microsoft 365 admin center (Brekelmans, 2026) [VERIFY: virgolettati letti tramite mirror 365community.online; autore, data e sommario confermati sull’indice del Microsoft Copilot Blog — fonte: techcommunity.microsoft.com]. Il giorno prima l’Azure Blog aveva annunciato la disponibilità generale del modello in Microsoft Foundry (Sweetman & Moneypenny, 2026). Tutto vero e utile. Ma è il quarto o quinto “modello frontier” che entra in Copilot Studio in un anno: la pagina What’s new registra GPT‑5 Chat GA il 24 novembre 2025, poi Claude Sonnet 4.5/4.6/Opus a marzo 2026, GPT‑5.5 Reasoning (Deep) ad aprile, Claude Sonnet 5 e GPT‑5.5 Chat GA a giugno (Microsoft Learn, 2026c). I modelli si avvicendano; l’architettura di chi-fa-cosa cambia molto più di rado.
I dati suggeriscono che Microsoft stessa la legge così: nello stesso mese in cui arriva Astra, la release 2026.6.3 introduce le API Power Platform per creare, aggiornare, elencare, leggere ed eliminare agenti e recuperare i loro componenti, e porta le analytics operative a metriche per singolo agente nel tempo con error rate come indicatore di salute (Microsoft Learn, 2026d). Sono strumenti di gestione del ciclo di vita, non di intelligenza. Quando una piattaforma investe in API di lifecycle, sta dicendo che i suoi oggetti stanno diventando tanti e troppo importanti per essere gestiti a mano.
Chi è responsabile di un’app generata in linguaggio naturale da un non sviluppatore?
Formalmente, l’organizzazione che la pubblica: le app costruite in Copilot Studio e Cowork sono governate dalle policy esistenti e amministrate dal Microsoft 365 admin center, secondo MC1469329 (Microsoft, 2026a). Nella pratica, la responsabilità è distribuita fra chi descrive l’app, chi la approva, chi amministra il tenant — e nessuno dei tre ha necessariamente letto il codice.
Gli strumenti ci sono, almeno sulla carta. Il post del Copilot Studio Blog del 15 settembre 2026 descrive app “full-stack” con “built-in source control, deployment stages, and version isolation”, create nell’ambiente di sviluppo personale del maker secondo le policy di environment routing già in vigore, e precisa che le app accedono ai dati “on behalf of the signed-in user”: pubblicare o condividere un’app non concede a nessuno dati che non potesse già raggiungere (jtung, 2026). Lo stesso post elenca ciò che l’admin vede nel Microsoft 365 admin center per ogni app pubblicata — chi l’ha costruita, stato del ciclo di vita, sorgenti dati e connettori, policy applicate, metriche d’uso — e ricorda che costruzione ed esecuzione sono misurate come due servizi separati in Copilot Credits, con tetti di credito impostabili per utente (jtung, 2026). Dal luglio 2026 Copilot Studio crea automaticamente un Microsoft Entra Agent ID per ogni nuovo agente, senza possibilità di opt-out a livello di ambiente (Microsoft Learn, 2026c): ogni agente ha un’identità propria su cui applicare Conditional Access e permessi. La release 2026.6.3 aggiunge che la condivisione degli agenti rispetta in modo coerente le policy organizzative e che l’inventario agenti è attivo di default anche nei cloud governativi GCC e High (Microsoft Learn, 2026d).
Ma identità, inventario e API risolvono il dove e il chi: non risolvono il cosa c’è dentro. E qui la ricerca indipendente è meno rassicurante di un blog di prodotto.
Quanto è rischioso il vibe coding aziendale? Cosa dice la ricerca?
Molto, e in modo misurabile. La Cloud Security Alliance, in una research note del 2 giugno 2026, riporta uno studio su 5.600 applicazioni vibe-coded in produzione: zero avevano protezione CSRF, security header o access policy correttamente delimitate. E rileva che nessuno dei principali framework di sicurezza AI — NIST AI RMF, OWASP LLM Top 10, CSA MAESTRO, CSA AICM — offre una guida dedicata e accessibile ai citizen developer (Cloud Security Alliance AI Safety Initiative, 2026).
La CSA introduce anche un concetto che trovo esatto: le “shadow operations”. Non più solo shadow IT come uso di tool non autorizzati, ma dipendenti che “build and deploy autonomous, data-processing applications on approved enterprise platforms without IT or security involvement” — su piattaforme approvate, dunque invisibili ai controlli pensati per bloccare l’esterno (Cloud Security Alliance AI Safety Initiative, 2026). È esattamente lo scenario che l’app building rende comodo.
La stessa nota ricorda l’origine del termine: il 6 febbraio 2025 Andrej Karpathy descrisse “a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists”; il post fu visto oltre 4,5 milioni di volte e “vibe coding” divenne Word of the Year 2025 per il Collins English Dictionary (Cloud Security Alliance AI Safety Initiative, 2026). Il punto di Karpathy era un esperimento personale nel weekend. Il punto di un’azienda è un’altra cosa.
Sul fronte accademico, una systematic literature review pubblicata su AI and Ethics (Springer) esamina la “duplice natura” del codice generato da AI — opportunità di produttività e sfide di sicurezza — sui modelli GPT e Claude più recenti [VERIFY: autori, data esatta e conclusioni numeriche non ancora consultati; DOI 10.1007/s43681-026-01203-2 — fonte: link.springer.com]. Sul fronte analisti, IBM Think (Bergmann, 18 giugno 2026) sostiene che i rischi del vibe coding non sono ordinari perché chi produce il codice non è in grado di valutarlo, e distingue il vibe coding dall’agentic engineering, che mantiene revisione e responsabilità umana (Bergmann, 2026).
Distinguo evidenza da opinione: i numeri della CSA riguardano app vibe-coded su piattaforme generiche, non app costruite in Copilot Studio, che ha connettori governati, DLP e identità agente. Non ho dati specifici sul nuovo app building, che è in preview da otto giorni. Ma la mia opinione è che la struttura del rischio sia la stessa: chi descrive non legge, chi legge non ha descritto.
Le nuove API e le analytics rendono possibile un vero ALM enterprise?
Rendono possibile l’automazione del ciclo di vita, che è la precondizione dell’ALM; non lo sostituiscono. La release 2026.6.3 fornisce endpoint API per l’intero CRUD degli agenti, analytics per agente con error rate, classificazione più dettagliata degli esiti delle sessioni e conteggi di reazioni raggruppabili per sessione (Microsoft Learn, 2026d). È il materiale grezzo per pipeline CI/CD e monitoraggio continuativo. Il processo — chi approva, chi promuove tra ambienti, chi legge l’error rate il lunedì mattina — lo deve costruire l’organizzazione.
La stessa release contiene un promemoria utile su cosa significa vivere su una piattaforma che evolve ogni settimana: un breaking change dichiarato, per cui gli Skill agents ora bloccano tipi di file di riferimento non supportati che prima venivano accettati (Microsoft Learn, 2026d). Chi ha agenti costruiti su repository documentali eterogenei se ne accorgerà. Chi non ha analytics attive se ne accorgerà dagli utenti.
Ecco cosa, nella mia esperienza, un ALM minimo per agenti e app agentiche dovrebbe includere oggi:
- Inventario — sapere quanti agenti e app esistono, di chi sono, con quale identità (Entra Agent ID è ora automatico per i nuovi agenti).
- Ambienti separati — sviluppo, test, produzione, con promozione tramite solutions e pipelines Power Platform, non copia-incolla.
- Revisione del codice generato — almeno per le app che toccano dati personali o sistemi core; il codice è ispezionabile, qualcuno deve ispezionarlo.
- Metriche operative — error rate per agente, esiti sessione, costi in Copilot Credits, letti con cadenza fissa.
- Registro dei breaking change — qualcuno che legge le release notes prima che lo faccia la produzione.
Cosa deve fare un IT manager prima che i colleghi inizino a costruire app da soli?
Decidere, prima che la preview arrivi nel tenant, tre cose: chi può creare app, in quali ambienti, e chi le approva prima della pubblicazione. Il resto — DLP, identità, analytics — è configurazione; queste tre sono scelte organizzative, e nessuna piattaforma le prende al posto nostro.
Ryan Cunningham lo scrive con onestà: “as more people become app builders, IT needs the governance and controls to confidently bring those solutions into the enterprise” (Cunningham, 2026). La parola che conta è confidently. La fiducia non viene dal pulsante App (Preview), viene dal sapere che l’app che un collega ha pubblicato venerdì sera è stata vista da qualcuno che sa cosa cerca.
Coerentemente con un principio che ripeto spesso su questo blog: l’AI non è un prodotto che si assegna a un reparto. L’app building lo dimostra in modo brutale: la persona che descrive l’app sta in vendite, i dati stanno in produzione, l’identità sta in IT, la responsabilità sta al vertice. Se uno solo di questi anelli pensa che “l’AI è roba dell’IT”, l’app esiste comunque — e nessuno la governa.
Implicazioni pratiche per le PMI italiane
Per una PMI italiana con Microsoft 365 Copilot, la novità è un’arma a doppio taglio più affilata del solito. Il lato buono è concreto: il backlog di piccole applicazioni interne — il registro visite, il tracciamento dei campionari, il form per le non conformità — che nessun system integrator prende volentieri sotto una certa soglia, diventa costruibile in casa, in una conversazione, con connettori a dati che l’azienda già possiede.
Il lato rischioso è altrettanto concreto. La PMI tipica non ha un CoE Power Platform, spesso non ha un amministratore dedicato al tenant, e la persona che costruirà la prima app sarà probabilmente la più curiosa dell’ufficio amministrativo, non un maker formato. I dati della CSA sulle 5.600 app senza controlli di base descrivono esattamente cosa succede quando entusiasmo e mancanza di revisione si incontrano (Cloud Security Alliance AI Safety Initiative, 2026).
Opportunità contro hype, per come la vedo io:
- Opportunità reale: eliminare fogli Excel condivisi e processi via email con app leggere e governate, in giorni anziché mesi.
- Hype da sgonfiare: “chiunque può costruire software aziendale senza IT”. Chiunque può generare software; costruirlo, nel senso di mantenerlo in produzione, resta un lavoro.
- Costo nascosto: le funzionalità su GitHub Copilot harness sono a consumo in Copilot Credits, incluse costruzione, test e valutazione (Microsoft Learn, 2026e). Chi costruisce dieci app “per provare” lo vede in fattura.
Il consiglio che darei a un titolare di PMI non è “aspetta”, perché la preview arriverà comunque nel tenant. È: decidi ora chi ha il permesso di premere Pubblica, e fallo prima che qualcuno lo scopra da solo.
Domande frequenti
L’app building di Copilot Studio è già disponibile per tutti?
No. Al 10 settembre 2026 la skill /app in Copilot Cowork è disponibile tramite il programma Frontier, e in Copilot Studio l’app building è in public preview con rollout “over the next week”. Il Message Center MC1469329 indica per Copilot Studio “within the next couple of weeks” dall’8 settembre. La disponibilità effettiva va verificata nel proprio tenant.
Che differenza c’è tra un agente e un’applicazione agentica in Copilot Studio?
Un agente è un software che ragiona e agisce su richiesta, tipicamente in conversazione, usando conoscenza e tool. Un’applicazione agentica ha interfaccia, dati e azioni proprie, viene generata via agentic coding da una descrizione in linguaggio naturale e può incorporare agenti e workflow. Da settembre 2026 le tre voci — Agenti, Workflow, App — convivono nella home di Copilot Studio.
Il codice generato da Copilot Studio si può leggere e modificare?
Sì, secondo il post ufficiale di Ryan Cunningham del 10 settembre 2026: dopo la generazione si può iterare in linguaggio naturale, ispezionare l’anteprima e “review the underlying code”. Maker avanzati e sviluppatori possono intervenire su struttura e codice. Che qualcuno lo faccia davvero, prima della pubblicazione, dipende dal processo dell’organizzazione, non dalla piattaforma.
GPT‑6 Astra è necessario per usare l’app building?
Le fonti ufficiali non collegano le due novità: sono annunci separati (4 e 10 settembre 2026). GPT‑6 Astra è un modello selezionabile in Cowork e Copilot Studio, con disponibilità variabile per regione e organizzazione e accesso gestito dagli admin nel Microsoft 365 admin center. L’app building è una capacità della piattaforma, non una funzione del singolo modello.
Quali sono i rischi documentati del vibe coding in azienda?
La Cloud Security Alliance (2 giugno 2026) cita uno studio su 5.600 app vibe-coded in produzione: nessuna aveva protezione CSRF, security header o access policy corrette. Segnala inoltre che i framework NIST AI RMF, OWASP LLM Top 10, CSA MAESTRO e CSA AICM non offrono guida dedicata ai citizen developer, e descrive il fenomeno delle “shadow operations” su piattaforme aziendali approvate.
Conclusioni
Ho iniziato l’anno costruendo un agente in una notte e lo chiudo guardando una piattaforma che costruisce applicazioni in una conversazione. La traiettoria è chiara e Microsoft non la nasconde: Copilot Studio vuole essere il posto dove agenti, workflow e app nascono insieme, con identità, API e analytics per gestirli. È una direzione che condivido, e che rende il lavoro di chi fa il mio mestiere più interessante, non meno.
Ma la mia posizione è netta: la notizia di settembre non è che l’AI scrive app. È che l’AI scrive app per persone che non le leggeranno, dentro piattaforme che le organizzazioni hanno già approvato. I dati della CSA sul vibe coding descrivono cosa succede quando nessuno guarda. La differenza tra un’opportunità e un incidente non la fa il modello — Astra o il prossimo — la fa chi decide, prima, che qualcuno deve guardare.
Riferimenti (APA)
- Cunningham, R. (2026, 10 settembre). Build apps in Copilot Cowork and Copilot Studio. Microsoft Copilot Blog. https://www.microsoft.com/en-us/copilot/blog/copilot-studio/build-apps-in-copilot-cowork-and-copilot-studio/ — Livello B
- Microsoft. (2026a, 9 settembre). MC1469329 — Build apps in Microsoft Copilot Studio and Copilot Cowork. Microsoft 365 Message Center (consultato tramite repost pubblico m365admin.handsontek.net). — Livello B
- jtung. (2026, 15 settembre). Managing apps built in Copilot Studio. Microsoft Tech Community, Copilot Studio Blog. https://techcommunity.microsoft.com/category/microsoft-copilot/blog/copilot-studio-blog [VERIFY: testo integrale letto su techcommunity.microsoft.com (pagina tag “copilot studio”); sostituire con l’URL permanente dell’articolo — fonte: techcommunity.microsoft.com] — Livello B
- Microsoft Learn. (2026a). What’s new in Copilot Cowork. https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/whats-new — Livello B
- Microsoft Learn. (2026b). Build apps through conversation with Copilot. https://learn.microsoft.com/power-apps/maker/canvas-apps/ai-conversations-create-app — Livello B
- Microsoft Learn. (2026c). What’s new in Copilot Studio. https://learn.microsoft.com/en-us/microsoft-copilot-studio/whats-new — Livello B
- Microsoft Learn. (2026d). Microsoft Copilot Studio Platform — Build 2026.6.3. https://learn.microsoft.com/en-us/power-platform/released-versions/copilotstudio/2026.6.3 — Livello B
- Microsoft Learn. (2026e). Quickstart: Create an automated solution with natural language in the GitHub Copilot harness (preview). https://learn.microsoft.com/microsoft-copilot-studio/create-automation-natural-language — Livello B
- Brekelmans, B. (2026, 4 settembre). Available today: OpenAI GPT‑6 Astra in Microsoft Copilot. Microsoft Tech Community, Microsoft Copilot Blog. https://techcommunity.microsoft.com/category/microsoft-copilot/blog/microsoft-copilot-blog [VERIFY: virgolettati letti tramite mirror 365community.online; sostituire con l’URL permanente dell’articolo — fonte: techcommunity.microsoft.com] — Livello B
- Sweetman, S., & Moneypenny, N. (2026, 3 settembre). GPT‑6 Astra: Frontier intelligence for work, now generally available in Microsoft Foundry. Microsoft Azure Blog. https://azure.microsoft.com/en-us/blog/gpt-6-astra-frontier-intelligence-for-work-now-generally-available-in-microsoft-foundry/ — Livello B
- Cloud Security Alliance AI Safety Initiative. (2026, 2 giugno). The Vibe Coding Governance Gap (Research Note). https://labs.cloudsecurityalliance.org/research/csa-research-note-vibe-coding-ai-governance-gap-20260602-csa/ — Livello A/B (ente di ricerca di settore)
- [VERIFY: autori e data — fonte: link.springer.com] (2026). A comprehensive analysis of security risks and productivity impacts of AI-generated code: a systematic literature review. AI and Ethics. https://doi.org/10.1007/s43681-026-01203-2 — Livello A
- Bergmann, D. (2026, 18 giugno). Vibe coding security risks aren’t like ordinary security risks. IBM Think. https://www.ibm.com/think/insights/vibe-coding-security-risks — Livello B
Fonti verificate al 18 settembre 2026.
Link interni Argos
- Come ho costruito “Bussola” in una notte con Copilot Studio
- Skills, agenti e il conto: chi governa e chi paga
- Governance e sicurezza degli agenti AI: la domanda che ogni CIO fa prima o poi
- L’AI non è un tool: è un cambio di paradigma
Trasparenza sull’uso dell’intelligenza artificiale
Questo articolo è stato redatto con l’assistenza di un sistema di intelligenza artificiale generativa (Claude Sonnet 5, tramite l’agente Argos Newsroom su Microsoft Copilot Studio) per la ricerca delle fonti, la strutturazione e la prima stesura. Il testo è stato successivamente verificato, corretto e approvato da un autore umano, Luca Borio, che ne detiene la responsabilità editoriale ai sensi dell’art. 50 del Regolamento (UE) 2024/1689. Dati, citazioni e link sono stati controllati sulle fonti originali indicate. Eventuali errori residui sono miei.
Rispondi