La soglia per creare un’app è crollata, quella per toccare i dati degli utenti no

I responsabili delle piattaforme digitali nell’e-commerce mi stanno facendo tutti la stessa domanda: il business side riesce a costruire tre piccoli strumenti interni con l’AI in una settimana, mentre la coda di sviluppo IT è ancora piena fino al prossimo trimestre. Dove sta esattamente il collo di bottiglia?

La nostra risposta è un’unica diagnosi: la soglia per sviluppare è crollata, quella per accedere ai dati degli utenti no.

Dietro questa frase ci sono due fenomeni che accadono simultaneamente.

Bolt.new è stato creato da StackBlitz e lanciato in silenzio con un singolo tweet nell’ottobre 2024. In cinque mesi ha raggiunto i 40 milioni di dollari di ARR. Sacra e Growth Unhinged lo monitorano come il prodotto con la crescita più rapida nella storia, secondo solo a ChatGPT. Alla chiusura dell’anno fiscale 2026, il CEO di StackBlitz Eric Simons ha rivelato su LinkedIn: Bolt.new è già utilizzato da tre quarti delle aziende Fortune 500, con un ARR enterprise cresciuto di 10 volte su base annua (post ufficiale di Eric Simons, chiusura FY2026). Lovable è un team di Stoccolma, Svezia (fondatore Anton Osika): a novembre 2025 ha chiuso un round A da 200 milioni di dollari con una valutazione di 1,8 miliardi; a fine dicembre 2025, un round B ha portato la valutazione a 6,6 miliardi — quasi quadruplicata in sei mesi (confermato in modo incrociato da Forbes, CNBC, Bloomberg e TechCrunch). A giugno 2026, l’ARR di Lovable ha superato i 500 milioni di dollari (riportato da Forbes, con conferma parallela di TechCrunch il 09-06-2026); lo stesso giorno Forbes ha citato quattro fonti vicine alla società secondo cui è in corso un nuovo round di finanziamento a una valutazione di 12 miliardi di dollari (circa il doppio). Strumenti di questo tipo comprimono il ciclo di sviluppo di un’applicazione — che prima richiedeva un team di più persone per diversi mesi — in una singola persona in un pomeriggio.

Ma mentre la soglia di sviluppo crolla, le barriere che davvero costano care e bloccano tutto nella tua azienda non si sono spostate di un millimetro: valutazione di trasferimento transfrontaliero dei dati, classificazione di protezione della sicurezza informatica (MLPS / Dengbao), registrazione degli algoritmi, approvazione delle modifiche (Change Advisory Board), riconciliazione e audit. Queste barriere non hanno quasi nulla a che fare con il codice in sé, eppure ognuna richiede settimane di lavoro. I generatori di app hanno sfondato la prima porta: il business può crearsi le proprie applicazioni. Ma la seconda porta — chi ha il diritto di toccare i dati di produzione, chi può modificare le transazioni core — non si è mossa di un centimetro.

Emerge così un’esposizione al rischio che la maggior parte dei decision maker non ha ancora colto: chi sa creare un’app non è necessariamente autorizzato a farla interagire legalmente con i dati.

Uno scenario reale che abbiamo seguito (e-commerce, dati anonimizzati): il team di creator management di un’azienda di arredamento online ha usato Lovable per costruire in due mesi sette piccoli tool interni: matching dei creator, simulazione commissioni, monitoraggio dei prodotti virali, attribuzione dei resi. Nessuno ha avvisato la piattaforma tecnica centrale. A metà anno, durante un inventario delle applicazioni shadow IT, è emerso che quattro di questi tool leggevano tabelle di ordini con numeri di telefono e indirizzi di spedizione, e due esportavano dati su cloud storage personali. È una situazione che i team delle piattaforme e-commerce si trovano sempre più spesso ad affrontare dal secondo semestre 2025 — non è un caso isolato.

Uno scenario reale che abbiamo seguito (operatore di telecomunicazioni, dati anonimizzati): durante una sessione di formazione interna in una filiale provinciale, il project manager del centro marketing ha ammesso di aver usato Bolt per creare un “tool di consultazione rapida del profilo cliente” in grado di recuperare, inserendo un numero di telefono, le modifiche al piano degli ultimi 90 giorni, lo storico dei reclami e le tabelle delle offerte consigliate — il reparto tecnico non ne sapeva nulla. Uno scenario che tocca direttamente le linee rosse della Cybersecurity Law e della Personal Information Protection Law cinesi in materia di autorizzazioni di accesso ai dati personali.

Prima di tutto, guardiamo un’immagine per capire l’entità del problema.

Ora entriamo nel dettaglio: quali problemi risolvono questi tool e per chi, come cambia il ruolo degli ingegneri, che forma stanno prendendo le applicazioni shadow nell’e-commerce, quali sono i veri colli di bottiglia normativi nei settori fortemente regolamentati, e come offrire al business un canale di conformità.

1. Mettiamo questi cinque tool nel loro contesto

Molte persone raggruppano questi strumenti sotto un’unica etichetta: “programmazione con l’AI”. In realtà servono due tipi di utenti molto diversi, e capire questa distinzione è il prerequisito per qualsiasi valutazione sensata.

Il primo gruppo è chi “sa già scrivere codice”. Quello che cerca è un editor di codice più veloce: uno strumento che capisca il contesto del tuo codebase, modifichi file su file, esegua i test automaticamente e spieghi gli errori. I rappresentanti tipici di questa categoria sono Cursor, Trae di ByteDance, Tongyi Lingma di Alibaba e GitHub Copilot. Il presupposto è che tu sia già un ingegnere: lo strumento ti solleva dal lavoro ripetitivo. Di questa categoria abbiamo già parlato nel quarto articolo della serie, quindi non ci torneremo sopra.

Il secondo gruppo è chi “non sa scrivere codice”. Questo è il protagonista di questo articolo: i generatori di app. Descrivi in una frase, in linguaggio naturale, quello che vuoi, e lui ti restituisce un’app funzionante: frontend, backend, database e deploy, tutto incluso. Non dà per scontato che tu sappia programmare.

Per questo articolo abbiamo selezionato quattro generatori di app. Tra gli IDE con AI, invece, abbiamo voluto isolare Trae, perché tocca un punto critico per i settori fortemente regolamentati.

Bolt.new (di StackBlitz). Un tweet pubblicato in silenzio nell’ottobre 2024, tracciato da Sacra e Growth Unhinged come il prodotto con la crescita più rapida della storia, secondo solo a ChatGPT: oltre 1 milione di dollari di ARR nella prima settimana, 4 milioni in un mese, circa 20 milioni in due mesi, 40 milioni in cinque mesi, con circa 5 milioni di utenti registrati (dichiarazioni pubbliche del CEO di StackBlitz). La tecnologia sottostante si chiama WebContainers: esegue un ambiente Node.js completo direttamente nel browser, consentendo all’AI di manipolare file, installare pacchetti e avviare servizi senza che l’utente debba configurare un ambiente locale. Alla chiusura dell’anno fiscale 2026, Bolt.new era utilizzato da tre quarti delle aziende Fortune 500, con un ARR enterprise cresciuto di 10 volte su base annua (post ufficiale di Eric Simons su LinkedIn, chiusura FY2026). StackBlitz ha raccolto un round Serie B da 105,5 milioni di dollari nel gennaio 2025, con una valutazione di circa 700 milioni (secondo Business Insider e altre testate). L’uso tipico è creare una piccola app o una landing page che si può aprire e provare immediatamente.

Lovable (fondata a Stoccolma da Anton Osika, in continuità con il progetto open source GPT Engineer). Il suo approccio è “da una singola frase a un’applicazione completa e deployabile”, posizionandosi più vicino alle applicazioni business full-stack rispetto a Bolt. A novembre 2025 ha chiuso un round Serie A da $200M con una valutazione di $1.8B; a fine dicembre 2025 un round Serie B da $330M con una valutazione di $6.6B — in sei mesi la valutazione è quasi quadruplicata. A giugno 2026 l’ARR ha superato i $500M (riportato da Forbes il 2026-06-05, con copertura simultanea di TechCrunch); lo stesso giorno, Forbes ha citato quattro fonti vicine alla società secondo cui è in corso un nuovo round di finanziamento a una valutazione di circa $12B (quasi il doppio, Forbes/Rashi Shrivastava). Tra i clienti enterprise di Lovable figurano già Workday, Asana e NVIDIA (riepilogo ARR.club 2026).

Vercel v0. Rilasciato nell’ottobre 2023, il 3 febbraio 2026 è stato ufficialmente rinominato da v0.dev a v0.app, evolvendosi da semplice scaffolding di componenti UI a generatore di applicazioni full-stack (runtime sandbox + integrazione GitHub + integrazione database Snowflake/AWS). A marzo 2026, Vercel ha dichiarato ufficialmente di avere oltre 6 milioni di sviluppatori utenti e circa 80.000 team attivi mensilmente (gli analisti competitor stimano un ARR di circa 42 milioni di dollari, secondo il riepilogo di Taskade del marzo 2026).

Replit Agent 4. Rilasciato il 13 marzo 2026, è l’aggiornamento più importante nella storia di Replit. Tre cose sono cambiate contemporaneamente: ① Design Mode è stato aggiornato a Infinite Design Canvas, che permette di progettare e modificare il codice in parallelo; ② la collaborazione è passata dal modello fork-and-merge a “stesso progetto, attività multi-thread” — più sub-agent eseguono in parallelo, e alla fine un sub-agent dedicato alla risoluzione dei conflitti li unisce automaticamente. Dato ufficiale: Agent 4 risolve automaticamente il 90% dei conflitti di merge (riportato da AlphaSignal nel 2026, confermato dal changelog ufficiale Replit di marzo 2026); ③ pianificazione ed esecuzione non sono più sequenziali: si può pianificare mentre si esegue. Nello stesso periodo, Replit ha chiuso un round di serie D con una valutazione di quasi 9 miliardi di dollari (riportato da Atal Upadhyay nel 2026; confermato da più fonti tra cui TechCrunch e Bloomberg). Replit è nato come ambiente di programmazione online, quindi ha sempre avuto collaborazione e hosting nel suo DNA. Con Agent 4, “mettere insieme un team per costruire un prodotto” è stato compresso a una velocità quasi pari a quella del lavoro individuale.

Il punto in comune di questi quattro: il costo di “creare un’app” è passato da team-mesi a persona-ore.

Parliamo di Trae separatamente, perché per le aziende di telecomunicazioni, finanza ed e-commerce rappresenta un rischio concreto legato al fornitore. Trae si presenta come un IDE (editor), ma in sostanza è un ambiente di sviluppo vincolato ai server di ByteDance — per gli utenti aziendali, non va trattato come un “normale IDE”, ma va sottoposto a una valutazione di ammissione come “strumento di trasferimento dati all’estero”. ByteDance lo ha lanciato a gennaio 2025, puntando a competere con Cursor, con una strategia basata sull’offerta gratuita di modelli premium come Claude e GPT-4o. In 12 mesi ha raggiunto 6 milioni di utenti registrati, 1,6 milioni di utenti attivi mensili e ha generato complessivamente circa 100 miliardi di righe di codice (sintesi della ricerca OpenAI Tools Hub, maggio 2026). Ma a luglio 2025, il ricercatore di sicurezza segmentationf4u1t ha pubblicato il progetto telemetry_research dimostrando che, anche disattivando la telemetria dalle impostazioni, Trae continua a trasmettere dati in background a server di ByteDance come mon-va.byteoversea.com — inclusi informazioni hardware, versione del sistema operativo, identificatori persistenti del dispositivo e della macchina, e dati sull’attività dei progetti; un singolo batch di telemetria può raggiungere 53.606 byte, e circa 7 minuti di utilizzo normale generano oltre 500 chiamate e circa 26 MB di dati (dati di prima mano da GitHub segmentationf4u1t/trae_telemetry_research, riportati da The Register/Cybernews il 28-07-2025).

La risposta successiva di ByteDance merita di essere documentata. Nell’aggiornamento del 2026-08-01, Cybernews riporta: la dichiarazione ufficiale di ByteDance ammette che il toggle di telemetria nelle impostazioni dell’IDE controlla solo la telemetria della parte framework di VS Code, mentre la raccolta dati degli altri strumenti Trae non è influenzata da questo interruttore — in parole povere: pensavi di averlo disattivato, ma in realtà non lo era. Dopo che i ricercatori hanno contattato direttamente il team di Trae, è stato confermato che una Privacy Mode separata è prevista per agosto 2026 circa. Nel frattempo, il “token-based paywall” introdotto da Trae a febbraio 2026 ha rotto la promessa “forever free”, spingendo molti sviluppatori che lo avevano integrato in produzione a riconsiderare le proprie scelte (sintesi dell’indagine OpenAI Tools Hub di maggio 2026).

Per lo sviluppatore individuale, la versione gratuita di Claude è piuttosto interessante. Per te, che sei il decisore, questo è un classico problema di conformità per il trasferimento transfrontaliero dei dati: i tuoi ingegneri stanno alimentando codice aziendale, e potenzialmente anche configurazioni e interfacce, in uno strumento che trasmette i dati ai server di ByteDance. In settori come telecomunicazioni e finanza, soggetti alla Legge sulla Sicurezza dei Dati e alla Legge sulla Protezione delle Informazioni Personali, questo passo da solo è sufficiente a innescare un incidente di conformità. La sezione 4 approfondirà questo punto.

2. Lo sviluppo riscritto: dal “scrivere codice” al “revisionare, orchestrare, vigilare”

I generatori di app vengono spesso fraintesi: “non serviranno più ingegneri”. È una lettura sbagliata.

La definizione corretta è questa: cambiano il fulcro del lavoro dell’ingegnere, non ne eliminano il ruolo. Quando anche l’AI e il personale business sono in grado di produrre codice e applicazioni, il valore dell’ingegnere si sposta dal “scrivere in prima persona” a tre attività: revisionare la correttezza di ciò che viene prodotto, orchestrarlo in sistemi affidabili, e vigilare su sicurezza e qualità.

Queste tre attività sono più rare del “scrivere codice”, e valgono di più. Chi sa scrivere un componente React ce n’è in abbondanza; chi sa giudicare se un’app promozionale generata dall’AI può andare in produzione toccando dati transazionali, se la sua autenticazione è solo di facciata, o se sta inviando log a servizi esteri — quello è molto più raro.

Qui serve un criterio di classificazione netto, perché troppe aziende oscillano tra due estremi: o si affida tutto al generatore, o si vieta tutto in blocco. Entrambi gli estremi fanno danni.

Questo schema vuole comunicare una sola cosa: sull’asse orizzontale c’è la complessità logica dell’applicazione, su quello verticale se tocca o meno denaro e dati personali. Nella cella in basso a destra (alta complessità + alta sensibilità), per quanto intelligente sia il generatore di app, non è il caso di farlo entrare in gioco. Una landing page promozionale puoi affidarla a Lovable senza problemi; il tuo gateway di pagamento — lì è solo una questione di tempo prima che succeda qualcosa.

Fissate questa linea rossa, e poi guardiamo cosa sta succedendo nell’e-commerce.

Tre: Il vero dolore dell’e-commerce: le shadow app incontrano i dati degli ordini

Facciamo un passo indietro e guardiamo un dato pubblicato da Gartner nella seconda metà del 2025: entro la fine del 2026, il 40% delle applicazioni aziendali incorporerà agenti AI specializzati per attività specifiche, rispetto a meno del 5% nel 2025 (previsione ufficiale Gartner, ripresa da Process Excellence Network il 27-08-2025). A questo si accompagna un altro dato ancora più eclatante: Gartner riporta che tra il Q1 2024 e il Q2 2025, le richieste di consulenza sui sistemi multi-agente sono aumentate del 1445% — il tema in più rapida crescita nell’ambito della consulenza AI di Gartner, senza eccezioni (fonte aggregata: RAPIDCLAW/Hendricks.ai/Arion Research).

Traduci questi due gruppi di numeri nel linguaggio dell’e-commerce: il 40% delle applicazioni aziendali eseguirà agenti AI, insieme a un altro dato — le consulenze per sistemi multi-agente in azienda sono aumentate del +1445% (dato basato sulla crescita delle consulenze AI advisory di Gartner, non sul deployment effettivo, ma il segnale direzionale è già chiaro): gli agenti AI sono passati dall’”aiutare a scrivere codice” a “più agenti che collaborano tra loro per portare a termine un intero flusso di business”. Quando gli agenti AI iniziano a essere implementati nelle applicazioni aziendali, toccando dati, eseguendo processi e scrivendo log, la natura del generatore di app si evolve da “strumento” a “sistema”.

Il report 2025 di UpGuard (State of Shadow AI, ripreso da Cybersecurity Dive) contiene due numeri che colpiscono più del 40% citato da Gartner: oltre l’80% dei dipendenti usa strumenti AI non approvati sul lavoro, e quasi il 90% lo fa persino all’interno dei team di sicurezza. E c’è di più: circa la metà dei dipendenti ammette di aver incollato dati aziendali riservati direttamente in questi strumenti non autorizzati. Mimecast parla del 51%, Teramind del 49% — cifre sostanzialmente allineate. L’altra faccia della medaglia secondo Gartner: il 69% delle organizzazioni sospetta o ha confermato che i dipendenti usano strumenti AI vietati, ma solo il 37% ha una policy formale sull’uso dell’AI (fonte: The Hacker News).

Traduciamo questi numeri nel linguaggio dell’e-commerce: i tuoi operatori, i tuoi marketer, i tuoi event planner stanno usando strumenti come Bolt, Lovable e v0 per crearsi da soli una serie di applicazioni. Configuratori di regole promozionali, dashboard per la selezione prodotti degli influencer, mini-app per il controllo stock, strumenti di gestione dei ticket post-vendita. Sono veloci, funzionano bene, risolvono problemi veri. E quasi tutti bypassano completamente IT e data governance.

Uno scenario reale che abbiamo seguito (e-commerce, dati anonimizzati): dalla seconda metà del 2025, quando abbiamo aiutato 4 aziende e-commerce di medie dimensioni (team IT di 50-200 persone) a fare un inventario dell’IT ombra, nessuna è uscita pulita. Il caso più emblematico: un’azienda di arredamento online. In due mesi, il team dei creator ha costruito da solo 7 tool interni con Lovable — 4 leggevano direttamente le tabelle degli ordini (con numeri di telefono e indirizzi di spedizione), 2 esportavano i dati su cloud personali. Il giorno dell’inventario, il responsabile della sicurezza ci ha detto: «Per poco non abbiamo interrotto tutto — avevamo paura che quello che veniva fuori fosse troppo grosso da gestire a livello dirigenziale».

Questo fenomeno si può chiamare “shadow IT dei dati”. Per dieci anni, lo shadow IT che ci ha fatto tribolare era quello dei reparti che compravano SaaS da soli (le vendite che prendono un CRM, il marketing che prende uno strumento di email marketing). Ora lo shadow IT è fatto di applicazioni che i reparti costruiscono da sé. Usano uno strumento non approvato — e peggio, producono un sistema nuovo che tocca dati sensibili, e che non compare da nessuna parte nell’inventario IT.

La differenza è di scala: comprare un SaaS significa collegare un sistema esterno; usare un generatore di app significa far crescere dal nulla, dentro la tua azienda, una miriade di sistemi nuovi, ognuno con le sue API, ognuno potenzialmente esposto a internet. In un anno, un’azienda e-commerce può ritrovarsi con centinaia di queste applicazioni, nessuna registrata nell’inventario IT.

Questa cosa non si blocca. Il dato dell’80% di UpGuard lo dice chiaramente: il “divieto” non funziona. Le persone trovano lo strumento più comodo per portare a termine il lavoro — è natura umana, ed è anche il KPI. Quindi la domanda giusta non è “come impediamo al business di usare i generatori”, ma “come facciamo a farli usare in sicurezza”. La sezione quattro parla delle soglie di conformità, la cinque di come aprire i canali.

Quattro: Quali sono le soglie di conformità — non trattarle come un test

Questa è la sezione che va chiarita meglio, ed è anche quella dove è più facile sbagliare.

Chi viene da contesti internet assume che “fare i controlli” significhi automaticamente test automatizzati in CI/CD: unit test, integration test, regression test, semaforo verde e si rilascia. I team tecnici che gestiscono i picchi di traffico dell’e-commerce conoscono bene questo schema.

Ma in telecomunicazioni, finanza, manifattura regolamentata ed e-commerce, la “validazione” va molto oltre i test. I veri colli di bottiglia sono una serie di passaggi che non hanno quasi nulla a che fare col codice, e ognuno richiede settimane. Ridurli a “test” è un pregiudizio da mondo internet, e porta i decision maker a sottostimare i tempi di delivery.

Vediamoli uno per uno.

Valutazione dell’esportazione dei dati.[^1] Se la tua applicazione utilizza servizi AI esteri (molti backend di generatori si appoggiano a OpenAI, Anthropic) o se i tuoi ingegneri usano IDE come Trae che trasferiscono dati all’estero, scatta l’obbligo di conformità all’esportazione previsto dalla Data Security Law e dalla Personal Information Protection Law (leggi cinesi sulla sicurezza dei dati e sulla protezione delle informazioni personali), purché i dati includano informazioni personali o dati sensibili. Completare una valutazione formale di sicurezza dell’esportazione o la registrazione di un contratto standard richiede da uno o due mesi a oltre sei mesi. Il caso di Trae — che continuava a trasmettere dati anche a telemetria disattivata — dimostra che, anche quando credi che non ci sia trasferimento, in realtà c’è. Strumenti del genere non dovrebbero proprio entrare in un ambiente di sviluppo in settori fortemente regolamentati.

Classificazione e verifica di protezione (MLPS / Dengbao).[^2] Ai sensi della Cybersecurity Law cinese, il sistema di classificazione della protezione (livello 2.0) prevede che un’applicazione rivolta al pubblico ricada molto probabilmente nel Livello III. Tra classificazione, registrazione, remediation e verifica, il ciclo completo richiede in genere da tre a sei mesi. È un requisito di legge, non un’opzione. Le applicazioni generate con l’AI non ottengono esenzioni dalla classificazione solo perché vengono sviluppate in fretta.

Registrazione dell’algoritmo.[^3] Se la tua applicazione è rivolta al pubblico e utilizza AI generativa (ad esempio generazione automatica di descrizioni prodotto, risposte automatiche all’assistenza clienti, o contenuti AI all’interno di raccomandazioni personalizzate), devi registrare l’algoritmo ai sensi delle Interim Measures for the Management of Generative AI Services e delle normative sulla raccomandazione algoritmica. Andare in produzione senza registrazione è una violazione di conformità.

Approvazione delle modifiche (CAB) e piano di rollback.[^4] Nei sistemi core di banche e telecomunicazioni, ogni rilascio in produzione deve passare dall’approvazione del Change Advisory Board: valutazione dell’impatto, piano di rollback, conferma della finestra di rilascio. Questa fase consuma tempo di calendario, non tempo macchina — se non rientri nella finestra, aspetti la settimana successiva.

Riconciliazione e audit.[^5] Per le campagne promozionali dell’e-commerce e la compensazione e liquidazione nel settore finanziario, dopo il rilascio bisogna riconciliare i dati con i fondi e con i sistemi upstream, e serve un audit log che tracci ogni singola transazione. Le applicazioni generate dall’AI spesso sono del tutto scoperte su questo fronte: funzionano, ma non hanno un meccanismo di riconciliazione progettato a monte — e quando emergono discrepanze contabili, non c’è modo di risalire alla causa.

Mettendo tutto insieme, emerge una conclusione controintuitiva: i generatori di app ti fanno passare dall’idea al prototipo funzionante dieci volte più velocemente, ma dal prototipo funzionante al rilascio conforme, il tempo non si riduce di un giorno. Quelle barriere richiedono lo stesso tempo di prima, né più né meno.

È la linea rossa che non si muove, nel grafico della prima sezione. La barriera dello sviluppo è crollata — ciò che risparmi è il tempo di scrittura del codice da parte degli ingegneri; la barriera della conformità non si è spostata — valutazioni, certificazioni, approvazioni: nessuna di queste si può saltare. L’errore più grande di chi prende le decisioni è credere che l’accelerazione della prima comporti automaticamente l’accelerazione della seconda. Non è così.

5. Dai al business un canale di conformità, non lasciarlo crescere selvaggio

Se non puoi bloccarlo, crea un canale — è una delle poche strade percorribili per governare lo shadow IT.

Per costruire questo canale, si procede in quattro passi.

Primo passo: l’azienda mette a disposizione un generatore interno, valutato e approvato dal punto di vista della sicurezza. Invece di lasciare che i team operativi vadano a usare un qualsiasi Lovable esterno, l’azienda acquista o costruisce una versione conforme alle normative di sicurezza nazionali (MLPS / Dengbao, il sistema cinese di classificazione e verifica della sicurezza informatica) e che non comporti il trasferimento di dati all’estero (la valutazione di sicurezza per l’export di dati, concettualmente simile al GDPR per i trasferimenti extra-UE). Le si dà un accesso interno. Se chi opera trova tutto ciò che gli serve, non andrà a cercare altrove: è il “canale di sfogo” che accompagna il “blocco”.

Microsoft, nel suo anno fiscale 2026, ha fornito un esempio di riferimento: EY ha distribuito Copilot a 150.000 dipendenti, ottenendo un aumento di produttività del 15%; Atos ha implementato Copilot per 56.000 dipendenti in 54 paesi, gestendo 19.000 agenti AI sotto un’unica control room per identità, sicurezza, conformità e governance degli agent (fonte: blog di recensione FY26 di Microsoft del 28-07-2026 e comunicato stampa ufficiale Atos del 09-06-2026; in entrambi i casi, dichiarazioni congiunte vendor-cliente). Il denominatore comune: entrambe hanno integrato gli strumenti AI nel piano di controllo di sicurezza e conformità aziendale. È l’esempio concreto di un canale “autorizzato”.

Sul fronte nazionale cinese, si possono citare le linee guida per l’applicazione conforme dei modelli di IA nel settore finanziario del CAICT (China Academy of Information and Communications Technology) e le pratiche di conformità nei progetti pilota del Ministero dell’Industria e dell’Information Technology per “l’AI a supporto della nuova industrializzazione”. Il percorso di localizzazione è già in corso; ciò che manca è integrarlo nei processi aziendali obbligatori.

Secondo passo: registrazione obbligatoria. Chi ha creato l’applicazione, quali dati legge, a quali utenti si rivolge: tutto finisce in un registro. La registrazione deve essere leggera — un modulo da compilare in 5 minuti, non un iter che dura due mesi. Altrimenti nessuno compila nulla e si torna nell’ombra. Lo scopo non è approvare ogni singola applicazione, ma avere un inventario chiaro.

Terzo passo: instradamento in base alla classificazione dei dati. Si usa la matrice della Sezione 2. Chi tocca solo dati anonimizzati o di test viene lasciato passare automaticamente; chi chiede accesso a ordini reali o dati personali attiva automaticamente la valutazione preliminare per il trasferimento transfrontaliero dei dati e la verifica di conformità alla classificazione di protezione (equivalente a una valutazione d’impatto ai sensi del GDPR). Il processo segue la sensibilità dei dati, non un approccio unico per tutte le applicazioni.

Passo 4: scansione automatica della sicurezza. Le applicazioni generate dall’IA presentano un tasso di vulnerabilità significativamente più alto rispetto al codice scritto da esseri umani. Il report di CodeRabbit del 2026 ha aggiornato questo dato: il codice assistito dall’IA produce 1,7 volte più problemi (inclusi bug logici e di correttezza) rispetto al codice scritto manualmente (metodologia proprietaria CodeRabbit, che include una prospettiva commerciale; confermato dal webinar congiunto DORA 2026-02 e dalla valutazione comparativa di Kunal Ganglani del 2026). Il report GenAI Code Security di Veracode del 2025 è ancora più diretto: nel suo campione, circa il 45% del codice generato dall’IA contiene vulnerabilità di livello OWASP Top 10 (il tasso di fallimento per il codice Java generato supera il 70%, metodologia proprietaria Veracode, con prospettiva commerciale). Anche uno studio accademico su larga scala basato su repository pubblici GitHub (arXiv:2510.26103) conferma la stessa direzione. Quindi, per le applicazioni generate dall’IA, la scansione non è un optional: è obbligatoria. Integra SAST, scansione delle dipendenze e scansione dei segreti nel pipeline di rilascio del generatore, e blocca il rilascio se non tutto è verde. A giugno 2026, CodeRabbit è stato pubblicamente riconosciuto come lo strumento di code review IA più installato su GitHub e GitLab, con oltre 15.000 clienti paganti e 6 milioni di repository analizzati. Persino Jensen Huang, CEO di NVIDIA, lo ha pubblicamente sostenuto: “Tutta NVIDIA usa CodeRabbit”. Considerarlo un benchmark di riferimento per il quality gate del codice IA a livello enterprise è ragionevole.

Questi quattro passaggi non hanno rallentato più di tanto il lato business, ma ogni applicazione è finita in una lista verificabile e tracciabile, e chi toccava dati sensibili è stato bloccato e indirizzato verso una valutazione formale. Questa è governance, non rallentamento.

Qui va chiarito un numero che è stato riportato in modo errato. Nella bozza originale compariva un “45% di tasso di adozione dell’AI ombra”, ma è un dato attribuito alla fonte sbagliata. Il 45% è il tasso di difetti nel codice generato dall’AI secondo il report di Veracode, non il tasso di adozione degli strumenti; per l’adozione dell’AI ombra bisogna guardare al 80%+ di UpGuard. Sono due cose completamente diverse, da non confondere.

Sei. Quando non usare i generatori di app

Non sono una pallottola d’argento. Quattro tipi di uso improprio, tutti visti nei clienti che abbiamo seguito.

Per transazioni core o risk management. Questo è il caso più pericoloso. Qualcuno pensa: “il generatore è così potente, proviamo anche con il gateway di pagamento”. L’angolo in basso a destra della matrice precedente è la zona rossa: logica complessa più gestione di denaro, affidarla al generatore equivale a consegnare il sistema centrale a uno stagista che non risponde di nulla. Se salta fuori un incidente finanziario, non c’è riconciliazione, non c’è audit, non c’è piano di rollback.

Il codice generato dall’AI è sicuro per impostazione predefinita. I dati di CodeRabbit (1,7x) e Veracode (45%) rispondono già a questa affermazione. Tra un’applicazione generata dall’AI che “sembra funzionare” e una che “funziona in modo sicuro” c’è un intero processo di ingegneria della sicurezza. Trattare le applicazioni generate dall’AI con standard diversi rispetto a quelle sviluppate manualmente, abbassando i requisiti di sicurezza, significa produrre più vulnerabilità a maggiore velocità.

Utilizzare generatori esteri per elaborare dati personali senza effettuare la valutazione d’impatto transfrontaliero. Questo è particolarmente insidioso nell’e-commerce: si crea una pagina promozionale rivolta ai consumatori, il backend chiama OpenAI per generare i testi, e il numero di telefono inserito dall’utente finisce incidentalmente su un servizio estero. È così che si oltrepassa la linea rossa della Personal Information Protection Law (PIPL, la legge cinese sulla protezione dei dati personali). Se qualcosa va storto, è un incidente di sicurezza dei dati, non un bug tecnico.

Installare di default per tutti gli ingegneri un IDE come Trae che trasferisce dati all’estero. La tentazione di un modello premium gratuito è forte, e gli ingegneri lo installeranno da soli. Una volta che il tuo codice core, le configurazioni e le interfacce finiscono sui server di ByteDance (o di qualsiasi altra entità estera), è troppo tardi per rimediare. L’introduzione di questi strumenti nell’ambiente di sviluppo richiede una valutazione di ammissione condivisa con i team sicurezza e legale, non è una decisione che il team tecnico può prendere da solo.

7. La prospettiva dei quattro settori: quali applicazioni si possono approvare, quali assolutamente no

Questo capitolo si concentra su 4 settori in cui abbiamo accompagnato le aziende attraverso problemi reali (e-commerce / finanza / telecomunicazioni / manifattura). Gli scenari fortemente regolamentati come pubblica amministrazione e sanità saranno trattati in un articolo dedicato, non in questo.

Passiamo ora ai quattro settori, con un esempio reale per ciascuno, tratto da ciò che abbiamo visto sul campo.

E-commerce. I punti più a rischio sono il “configuratore di regole promozionali”, la “dashboard di selezione prodotti per creator” e la “mini-app di consultazione inventario”: sembrano strumenti innocui, ma in realtà leggono tabelle di ordini con numeri di telefono e indirizzi. Queste applicazioni devono obbligatoriamente passare dal canale autorizzato descritto nella sezione 3, e l’accesso a dati reali attiva automaticamente la valutazione di conformità (MLPS / Dengbao, classificazione di sicurezza) e la valutazione di trasferimento dati all’estero (data export assessment). Abbiamo visto con i nostri occhi un team operativo di una società di e-commerce creare 7 strumenti interni in 2 mesi, di cui 4 leggevano tabelle di ordini — non è un caso isolato.

Finanza. La linea rossa è: “sistemi di trading / pagamenti / compensazione e liquidazione / risk management / antifrode / reporting regolamentare”. Il generatore è adatto per il cruscotto del relationship manager, il configuratore di campagne marketing e il front-end dei report di riconciliazione. Mai usarlo per il motore di risk management o le regole antifrode — il tasso di bug logici 1,7 volte superiore rilevato da CodeRabbit (metodologia proprietaria CodeRabbit, con posizione commerciale dichiarata), in ambito finanziario si traduce in un rischio amplificato sui fondi. Il caso aziendale è stato reso anonimo: una banca commerciale ha iniziato a fine 2025 a usare la programmazione AI per la generazione assistita di report regolamentari; il risultato è stato che lo script di reporting secondo le specifiche dell’autorità di vigilanza conteneva 3 errori di corrispondenza dei campi, portando a un richiamo formale da parte del regolatore — una delle cause profonde è stato il codice “che sembra corretto” generato dall’AI e mai verificato da nessuno.

Telecom/operatori. Un operatore regionale con cui abbiamo lavorato: il centro marketing di una filiale locale ha usato Bolt per creare un “query rapida del profilo cliente” — bastava inserire il numero di telefono per tirare fuori 90 giorni di storico tra piani tariffari, reclami e raccomandazioni. Un caso da manuale di violazione dei limiti di accesso previsti dal Personal Information Protection Law (PIPL). Nel contesto degli operatori, il generatore può essere usato per costruire un “cruscotto dell’account manager”, un “front-end per la knowledge base dell’assistenza” o un “configuratore di campagne marketing” — ma mai e poi mai per toccare billing, fatturazione o interrogazione dei dettagli di consumo. Quella è la zona vietata per un operatore: un errore lì e finisci sui titoli dei giornali.

Produzione. I sistemi MES/ERP, l’integrazione e il collaudo congiunto, il controllo qualità e l’invio dei report sono i sistemi core: il generatore può occuparsi solo della parte periferica — dashboard di reparto, interrogazione dei percorsi di lavorazione, demo dell’OEE delle attrezzature. Mai toccare: l’algoritmo core della schedulazione della produzione, le regole di giudizio qualità, l’interfaccia di riconciliazione con l’ERP a monte. Caso reso anonimo: un fornitore di componenti automotive (esistono diverse richiami simili documentati pubblicamente; i dettagli del caso sono ricostruiti da comunicati di richiamo pubblici e da progetti a cui ho partecipato, per illustrare la logica decisionale, senza riferirsi a un’azienda specifica) ha chiesto all’IT di costruire con Bolt una “dashboard front-end per il modello AI di controllo qualità” — l’intento era solo mostrare le immagini dei campioni e i risultati del giudizio. Ma durante il rendering lato client, la soglia di confidenza grezza dell’inferenza del modello AI è stata hard-codificata nel front-end. Un operatore, per sbaglio, l’ha modificata da 0,85 a 0,6: in 3 giorni, oltre 200 pezzi che avrebbero dovuto essere classificati come “non conformi” sono stati marcati “conformi” e sono fluiti a valle nella linea di produzione. È finita con il richiamo di 3 lotti. L’errore più comune nelle aziende manifatturiere di medie dimensioni è affidare al generatore anche il “front-end del modello AI di controllo qualità” — perché a valle delle regole di qualità c’è il richiamo del prodotto: sbagli una volta, e ti ritrovi con un comunicato di richiamo.

8. Cosa dovrebbero capire i decision maker

Lezione 1: Prima disegna una mappa a strati delle applicazioni, poi parla di acquisto di strumenti. Riprendi la matrice della Sezione 2 e inserisci le applicazioni che la tua azienda già possiede o intende realizzare, classificandole in base a complessità e sensibilità dei dati. Vedrai subito con chiarezza: quali sono le zone verdi, dove puoi affidarti con tranquillità ai generatori per accelerare il lavoro, e quali sono le zone rosse, da non toccare assolutamente. Questa mappa ti farà risparmiare un’infinità di proposte avventate del tipo “ricostruiamo i sistemi core con i generatori”, e allo stesso tempo darà legittimità all’accelerazione delle parti che meritano di essere accelerate.

Lezione 2: Tratta il trasferimento transfrontaliero dei dati e la classificazione di sicurezza come requisiti di accesso, non come adempimenti successivi. Prima di acquistare qualsiasi strumento di IA che venga a contatto con codice o dati, verifica questi due aspetti. Il problema di strumenti come Trae non è “se funzionano”, ma “se possono essere utilizzati nel tuo contesto normativo”. Questa valutazione va fatta in anticipo: il costo di sbagliarla si paga in termini di remediation, segnalazioni alle autorità e persino sospensione del servizio. In pratica: integra l’acquisto di strumenti di IA nel processo congiunto di approvazione con i team sicurezza e legale, e definisci chiaramente una lista di strumenti “ammessi nell’ambiente di sviluppo” e una lista di strumenti “soggetti ad approvazione caso per caso”.

Lezione 3: Offri al business un canale conforme, altrimenti le applicazioni ombra non faranno che moltiplicarsi. L’80% citato nella Sezione 3 dimostra che vietare non funziona. Invece di aspettare l’inventario post-incidente, costruisci fin da subito il canale descritto nella Sezione 5: generatori autorizzati, registrazione leggera, instradamento in base alla sensibilità dei dati, scansione automatica. Lascia che il business vada veloce, ma assicurati che ogni applicazione sia tracciata. È così che trasformi l’IT ombra da zona cieca non presidiata a patrimonio verificabile e sottoposto a controllo.

Quarto Spunto: cambia la metrica, altrimenti tutto il budget finisce in strumenti e il collo di bottiglia resta lì. Questo punto è per chi ha la responsabilità finale. Oggi molti consigli di amministrazione misurano il successo della trasformazione AI con parametri come “quante licenze AI abbiamo comprato” o “di quanto è aumentata la velocità di sviluppo”. Il problema di questo approccio è che il budget finisce tutto nell’acquisto di strumenti, mentre le funzioni che davvero sbloccano la consegna — come il team per la valutazione dei trasferimenti transfrontalieri di dati, il team di conformità alla classificazione di sicurezza (等保, Dengbao, il sistema cinese di protezione della sicurezza informatica a più livelli), l’ingegneria della sicurezza, la riconciliazione e l’audit — restano senza fondi e senza personale. Il risultato? Una montagna di strumenti, ma consegne sempre lente. Per curare la sindrome del “sappiamo cosa fare ma non riusciamo a muoverci”, bisogna cambiare la metrica a monte. Aggiungete indicatori come: “quante applicazioni sono coperte dal canale di conformità”, “le applicazioni shadow sono scese da N a M”, “il ciclo che va dal prototipo alla messa in produzione conforme per le applicazioni core”. Quando cambia la metrica, il budget segue e va dove serve davvero.

Autoverifica (senza abbellimenti): Quante applicazioni costruite dai reparti con l’AI stanno girando nella tua azienda, adesso? Riesci a dare un numero? Di queste, quante toccano ordini, numeri di telefono o indirizzi? L’IDE con AI che hai installato di default per i tuoi ingegneri, hai mai verificato dove finiscono i dati? I numeri che usi per misurare l’efficacia dell’AI stanno premiando “l’acquisto di strumenti” o “la velocità di consegna”? Se a una sola di queste domande non sai rispondere con certezza, il rischio descritto in questo articolo è già realtà nella tua azienda.

Prossimo passo

Questa è la quinta puntata di una serie di 18 articoli dedicata alla trasformazione dell’ingegneria del software nell’era dell’IA. Abbiamo visto come i generatori di app e gli IDE basati sull’IA abbiano abbattuto la soglia per “creare un’applicazione”, e perché la soglia legata all’accesso ai dati non crolli allo stesso modo.

La prossima puntata (la sesta) esamina una direzione opposta che sta diventando un consenso nel settore: lo sviluppo guidato dalle specifiche (Spec-Driven Development). Perché GitHub Spec Kit, Claude Code, AWS Kiro e AGENTS.md di OpenAI convergono tutti verso l’approccio “prima scrivi i requisiti in un documento, poi lascia che l’IA faccia il resto”. Nella sezione precedente abbiamo visto che il codice generato dall’IA ha un tasso di vulnerabilità superiore a quello scritto da esseri umani; lo sviluppo guidato dalle specifiche è proprio uno dei modi per curare questo problema: trasformare requisiti vaghi e verbali in specifiche verificabili, così che l’IA possa essere effettivamente controllata.

Nota sulla serie: questa serie seguirà costantemente le ultime evoluzioni degli strumenti di programmazione IA, delle strutture organizzative e dei paradigmi dell’ingegneria del software. Segui la serie per ricevere aggiornamenti continui.

Vuoi applicare queste valutazioni alla tua azienda?

Quando i generatori di app entrano in un’organizzazione, le questioni concrete da risolvere sono di solito poche e specifiche: quali applicazioni e dati possono essere generati autonomamente dalle business unit, quali devono restare sotto il controllo dell’IT, fino a che punto potenziare i processi di verifica esistenti, e con quali indicatori valutare i progetti pilota.

Attualmente offriamo tre tipi di collaborazione:

Formazione interna: sulla base di progetti reali della vostra azienda, completate la selezione del generatore di app, i confini d’uso, i canali di conformità e la progettazione dei meccanismi di governance.
Consulenza dedicata: focalizzata su una decisione specifica, ad esempio “se attivare un generatore di app autorizzato per le business unit” o la priorità di remediation dopo un inventario delle applicazioni shadow.
Interventi per il management e keynote di settore: incentrati su strumenti di coding AI, governance delle applicazioni shadow, trasformazione AI aziendale e governance organizzativa.

L’articolo fornisce un framework generale. L’implementazione concreta richiede comunque una riprogettazione basata sui confini dei dati, sui requisiti normativi, sulla maturità ingegneristica e sui flussi di delivery esistenti dell’azienda. Per collaborazioni: coach@iaiuse.com.

Lettura consigliata: “Metodologia InsegnaVista v1.0” (Imparare l’AI Lentamente 187), che illustra sistematicamente il framework in 7 fasi per la trasformazione AI aziendale.

Informazioni su questa serie

“La trasformazione dell’ingegneria del software nell’era dell’AI” è una serie di ricerca rivolta a CIO, CDO, CTO e responsabili della digitalizzazione nei settori telecomunicazioni, finanza, manifattura ed e-commerce. La serie comprende 18 articoli e si concentra su come gli strumenti di coding AI, i generatori di app e la governance delle applicazioni shadow influenzino i processi di delivery del software, la struttura organizzativa, i meccanismi di governance e le metriche di gestione.

Serie in continuo aggiornamento su paper accademici, documentazione dei vendor e report di settore: il database di ricerca supera i 200 documenti, con ogni giudizio chiave classificato per livello di evidenza, distinguendo tra fatti verificati, affermazioni dei vendor, osservazioni di settore e deduzioni dell’autore.

Ho quasi 8 anni di esperienza in consulenza per grandi aziende e analisi di business, con un passato in IBM su progetti nei settori telecomunicazioni, finanziario, assicurativo e manifatturiero. In seguito ho continuato a lavorare in prima linea sullo sviluppo di prodotti per operatori, prodotti internet e applicazioni di IA, occupandomi di analisi dei requisiti, progettazione del prodotto e implementazione cross-funzionale.

Le valutazioni di questa serie su selezione degli strumenti, limiti d’uso dei generatori di app, progettazione dei canali di conformità e governance organizzativa derivano da questa esperienza pratica, incrociate con ricerca pubblica e casi di settore. I contenuti relativi a progetti specifici sono stati tutti anonimizzati; alcuni scenari di settore sono esercizi di ragionamento su problemi tipici, con le relative fonti elencate in fondo.

Dietro questa rubrica c’è in realtà un piccolo team — io e 1-2 colleghi con cui collaboro da tempo, ciascuno responsabile rispettivamente di ricerca sugli strumenti di AI coding, analisi di casi di governance organizzativa e coaching conversation. La maggior parte dei progetti in cui “abbiamo accompagnato le aziende” nel testo sono stati consegnati insieme da noi. I confini di conformità dei clienti e i nomi delle persone restano comunque non menzionati: l’anonimato lascia spazio ai colleghi con cui collaboreremo in futuro.

Fonti di riferimento (tutte verificate, con livello di evidenza + posizione per ciascuna voce)

StackBlitz CEO Eric Simons（LinkedIn，chiusura anno fiscale 2026）. Bolt.new è utilizzato da tre quarti delle aziende Fortune 500, con un ARR enterprise in crescita di 10 volte su base annua. Dichiarazione diretta dell’azienda (prospettiva del fornitore). https://www.linkedin.com/posts/eric-simons-a464a664_a-growth-update-as-we-close-out-our-fiscal-activity-7425263313049026560-5tdV
Sacra / Growth Unhinged (2025). Monitoraggio della crescita ARR di Bolt.new (circa 5 mesi per raggiungere 40 milioni di dollari di ARR, circa 5 milioni di utenti, la seconda crescita più rapida della storia dopo ChatGPT). Ricerca primaria/monitoraggio. https://sacra.com/c/bolt-new/ 、https://www.growthunhinged.com/p/boltnew-growth-journey
Taskade (2026-03) / Business Insider. StackBlitz ha chiuso un round di Serie B da $105,5 milioni nel gennaio 2025, con una valutazione di circa $700 milioni; Bolt V2 è stato lanciato su Bolt Cloud. Sintesi della stampa di settore.
Forbes / Rashi Shrivastava (2026-06-05). Lovable sta raccogliendo un nuovo round di finanziamento con una valutazione di $12 miliardi; l’ARR ha superato i $500 milioni (confermato da TechCrunch il 2026-06-09). Copertura di primo livello. https://www.forbes.com/sites/rashishrivastava/2026/06/05/ai-coding-startup-lovable-in-talks-to-raise-funding-at-a-12-billion-valuation
CNBC / Bloomberg (2025-12) / TechCrunch (2025-11). Lovable ha chiuso una Serie B da $330 milioni con una valutazione di $6,6 miliardi, e una Serie A da $200 milioni con una valutazione di $1,8 miliardi. Copertura di settore.
ARR.club (2026-07). curva di crescita dell’ARR di Lovable: $17M (02/2025) → $100M (07/2025) → $200M (11/2025) → $400M (02/2026) → $500M (06/2026); clienti enterprise includono Workday, Asana e NVIDIA. Monitoraggio di settore.
Vercel (02/03/2026, blog ufficiale “Introducing the new v0”). v0 passa da v0.dev a v0.app, evolvendosi da generatore di componenti UI a vero e proprio generatore di applicazioni full-stack (sandbox runtime + GitHub + integrazioni Snowflake/AWS). Dichiarazione diretta del vendor. https://vercel.com/blog/introducing-the-new-v0
Taskade (03/2026) / Vercel. v0 conta oltre 6 milioni di utenti a marzo 2026, circa 80.000 team attivi mensilmente e un ARR stimato di circa $42M. Stima aggregata di settore.
Replit (2026-03-13 note di aggiornamento ufficiali + blog ufficiale “What’s changed from Agent 3 to Agent 4”). Agent 4 è stato rilasciato l’11 marzo 2026; Infinite Design Canvas; il flusso di lavoro fork-and-merge è stato sostituito da attività multi-thread sullo stesso progetto con risoluzione automatica dei conflitti (il 90% viene risolto automaticamente). Dichiarazione diretta del produttore. https://docs.replit.com/updates/2026/03/13/changelog
AlphaSignal (2026). Approfondimento su come Replit Agent 4 risolva automaticamente il 90% dei conflitti di merge nel lavoro di squadra. Copertura di settore. https://alphasignal.ai/news/replit-s-agent-4-resolves-90-of-team-merge-conflicts-automatically
Atal Upadhyay (2026-03-19). Nella stessa settimana, Replit ha annunciato un round di serie D da 400 milioni di dollari, con una valutazione di 9 miliardi (triplicata in sei mesi). Sintesi di report di settore. https://atalupadhyay.wordpress.com/2026/03/19/replit-agent-4-replit-just-changed-everything
Cybernews (aggiornato il 01/08/2026) / The Register (28/07/2025) / segmentationf4u1t (ricerca diretta su GitHub). Trae continua a trasmettere ai server di ByteDance dati su hardware, ID del dispositivo e attività di progetto anche quando la telemetria è disattivata; un singolo batch può raggiungere i 53.606 byte; in 7 minuti si registrano oltre 500 chiamate, pari a circa 26 MB; ByteDance ha ufficialmente confermato che l’interruttore controlla solo la parte basata su VS Code; la modalità Privacy è prevista per agosto 2026 circa; a febbraio 2026 Trae ha eliminato il piano “forever free” introducendo un paywall basato su token. Ricerca di sicurezza di primo livello + copertura giornalistica di settore + dichiarazioni ufficiali del produttore. https://cybernews.com/security/bytedance-ai-coding-tool-trae-data-collection 、https://www.theregister.com/software/2025/07/28/bytedance-ai-ide-trae-telemetry-continues-even-after-opt-out/ 、https://github.com/segmentationf4u1t/trae_telemetry_research
OpenAI Tools Hub / Jim Liu (2026-05-18). Trae ha registrato 6 milioni di iscrizioni in 12 mesi, con 1,6 milioni di utenti attivi mensili e 100 miliardi di righe di codice generate complessivamente; a febbraio il paywall sui token ha messo fine alla promessa “forever free”. Ricerca sintetica (prospettiva da analista).
Gartner (citato da Process Excellence Network, 2025-08-27 / DevOpsDigest / UC Today). Entro la fine del 2026, il 40% delle applicazioni aziendali includerà agenti AI dedicati a compiti specifici (nel 2025 meno del 5%); entro il 2035, l’AI agentica rappresenterà circa il 30% del mercato software aziendale (450 miliardi di dollari). Documento di previsione ufficiale. https://www.processexcellencenetwork.com/ai/news/gartner-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026
Gartner (citato da RapidClaw / Hendricks.ai / Arion Research, 2025-2026). Tra il Q1 2024 e il Q2 2025, le richieste di consulenza sulle architetture multi-agente sono cresciute del 1445% — il tema in più rapida espansione nell’ambito dell’AI advisory di Gartner. Ricerca primaria / fonte secondaria.
Microsoft (post di fine FY26, 2026-07-28). EY ha distribuito Copilot a 150.000 dipendenti, ottenendo un incremento di produttività del 15%, e sta ora estendendo l’implementazione a 400.000 dipendenti a livello globale; Atos ha distribuito Copilot a 56.000 dipendenti in 54 paesi, gestendo 19.000 agenti AI sotto un’unica console di controllo. Dichiarazione diretta del vendor + testimonianza del cliente (prospettiva vendor + system integrator). https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Atos Group (comunicato ufficiale del 09-06-2026). Atos amplia la collaborazione con Microsoft, implementando Copilot E7 (Frontier Suite) per 56.000 dipendenti, con unificazione del piano di controllo su Entra/Defender/Intune/Purview/Agent 365 e gestione di 19.000 agent. Dichiarazione diretta dell’azienda. https://www.atosgroup.com/en/press/atos-group-and-microsoft-expand-strategic-collaboration-scale-secure-agentic-ai-across-atos
UpGuard / Cybersecurity Dive (2025). Oltre l’80% dei dipendenti e quasi il 90% dei responsabili della sicurezza utilizzano strumenti di intelligenza artificiale non approvati; circa la metà dei dipendenti ha incollato dati riservati in questi strumenti (rapporti simili di Mimecast e Teramind confermano gli stessi dati, con verifica incrociata). Ricerca primaria + report di settore. https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/
Gartner (citato da The Hacker News, maggio 2026). Il 69% delle organizzazioni sospetta o conferma che i dipendenti utilizzano strumenti di IA vietati; solo il 37% dispone di linee guida per l’uso dell’IA. Riportato da pubblicazioni di settore.
CodeRabbit (webinar congiunto DORA del 2026-02 + benchmark trasversale di Kunal Ganglani del 2026-06). Il numero di problemi (inclusi bug logici e di correttezza) nel codice generato con assistenza AI è circa 1,7 volte superiore rispetto a quello scritto manualmente; CodeRabbit è lo strumento di review del codice AI più installato su GitHub/GitLab, con oltre 15.000 clienti paganti e 6 milioni di repository analizzati; il CEO di NVIDIA Jensen Huang ne ha dato un endorsement pubblico. Ricerca primaria / dati vendor / benchmark di settore. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
Veracode (2025 GenAI Code Security Report). Circa il 45% dei campioni di codice generato da AI contiene vulnerabilità OWASP Top 10 (il tasso di fallimento del codice Java generato supera il 70%). Ricerca primaria. https://www.veracode.com/blog/genai-code-security-report/ （Nota: la bozza originale aveva erroneamente interpretato questo “45%” come “tasso di adozione di shadow AI”, una direzione sbagliata, ora corretta — il 45% si riferisce al tasso di difetti nel codice generato da AI, non al tasso di adozione degli strumenti; per l’adozione di shadow AI si veda il dato di UpGuard, superiore all’80%.)
arXiv:2510.26103. Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories.（Uno studio empirico di prima mano sulle vulnerabilità di sicurezza nel codice generato da AI）

Nota sulla metodologia dei dati: tutti i dati quantitativi in questo articolo sono accompagnati dalla fonte; alcuni numeri per cui i vendor non hanno pubblicato dati ufficiali o che non sono stati verificati in modo indipendente (ad esempio, il round di finanziamento da $12 miliardi di Lovable, ancora in fase di trattativa, o il conteggio esatto dei 19.000 agent di Atos) sono stati trattati con cautela. I casi cliente sono stati anonimizzati (team operativo e-commerce, centro marketing di una filiale regionale di operatore telefonico, ecc.) e provengono da scenari osservati durante attività di delivery a cui ho partecipato direttamente, senza riferimenti a specifiche aziende. I requisiti normativi (trasferimento transfrontaliero dei dati, classificazione e protezione della sicurezza informatica, registrazione degli algoritmi) fanno riferimento alla normativa vigente; l’applicabilità concreta varia in base al business e al tipo di dati trattati. Prima di implementare qualsiasi soluzione, si raccomanda di ottenere un parere legale o di conformità.

[^1]: I dati importanti che escono dal Paese seguono l’articolo 31 della Legge sulla sicurezza dei dati (valutazione della sicurezza per l’uscita transfrontaliera di dati importanti); i dati personali che escono seguono gli articoli 38-43 della Legge sulla protezione delle informazioni personali (condizioni per l’uscita, contratto standard, percorso di certificazione, consenso informato). Norme complementari: Misure per la valutazione della sicurezza dell’uscita transfrontaliera dei dati (in vigore dal 01-09-2022, Ordinanza n. 11 dell’Ufficio Internet Nazionale) e Misure per il contratto standard sull’uscita transfrontaliera di dati personali (in vigore dal 01-06-2023).
[^2]: Articolo 21 della Legge sulla sicurezza informatica (sistema di protezione a livelli), Requisiti di base per la sicurezza informatica — Protezione a livelli GB/T 22239-2019 (noto come “Dengbao 2.0”); le Misure per la gestione della protezione a livelli della sicurezza informatica (Gongtongzi [2007] n. 43) prevedono che i sistemi di livello terzo vengano sottoposti a una valutazione del livello di sicurezza una volta all’anno, mentre quelli di livello secondo generalmente ogni due anni.

[^3]: Occorre distinguere tre cose diverse: ① l’articolo 24 del Regolamento sulla gestione delle raccomandazioni algoritmiche nei servizi di informazione Internet (in vigore dal 01-03-2022) (registrazione delle raccomandazioni algoritmiche); ② l’articolo 17 del Regolamento sulla gestione dei servizi di sintesi profonda nei servizi di informazione Internet (in vigore dal 10-01-2023) (registrazione della sintesi profonda); ③ l’articolo 17 delle Misure provvisorie per la gestione dei servizi di intelligenza artificiale generativa (in vigore dal 15-08-2023) (i servizi di IA generativa rivolti al pubblico con attributi di opinione pubblica richiedono una valutazione di sicurezza — questa è una valutazione, non una registrazione). Il codice generato da un generatore di app non attiva necessariamente queste tre categorie, ma se l’applicazione generata fornisce servizi di IA generativa al pubblico o include funzionalità di raccomandazione algoritmica/sintesi profonda, si applicano le disposizioni corrispondenti.
[^4]: Il framework generale per la gestione dei cambiamenti fa riferimento a ITIL 4 Change Enablement; per il settore finanziario, il riferimento più recente è il Regolamento sulla supervisione dei rischi dell’outsourcing IT per banche e istituti assicurativi (Circolare CBIRC n. 46 del 2021) e le relative circolari della National Financial Regulatory Administration del 2024; per il settore assicurativo si aggiungono le Linee guida per la gestione dell’informatizzazione degli istituti assicurativi (Circolare CIRC n. 17 del 2009, edizione rivista 2024).

[^5]: Registrazione delle transazioni: la fonte normativa è l’Articolo 31 della Legge sul Commercio Elettronico (le piattaforme devono registrare e conservare i dati delle transazioni per almeno 3 anni), integrato dall’Articolo 26 del Regolamento sulla Supervisione delle Transazioni Commerciali Online (che conferma il periodo di 3 anni). Per i log di audit: i sistemi di Livello 3 secondo lo standard di protezione della sicurezza informatica (等保, Dengbao — classificazione obbligatoria della cybersecurity in Cina) richiedono la conservazione dei log di rete per almeno 6 mesi (in attuazione dell’Articolo 21 della Legge sulla Sicurezza Informatica), ma per i sistemi critici del settore finanziario, l’Articolo 19 delle Linee Guida sulla Governance dei Dati per gli Istituti Bancari e le Norme di Controllo Interno per le Banche Commerciali impongono generalmente un periodo ≥ 5 anni — i 6 mesi rappresentano solo il minimo legale, non un valore raccomandato.