Fonti dei dati citati nel testo: CodeRabbit 2025.12 / New Relic 2026 report, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms announcement, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. I casi presentati sono scenari rappresentativi e non fanno riferimento a specifiche aziende.

Il tuo errore più grande non è non aver comprato gli strumenti: è non aver scritto il CLAUDE.md

Il CIO di una banca regionale si è lamentato con me: strumenti di AI acquistati, modelli deployati, personale formato — eppure nell’intero primo semestre 2026 i tempi di consegna non si sono mossi di un giorno. Il responsabile del team core banking è stato ancora più diretto: “Il codice scritto dall’AI funziona, ma ogni volta va riscritto da capo — non conosce le nostre regole interne, non conosce i requisiti normativi, non sa come interfacciarsi con quel sistema legacy di 30 anni.”

Il problema non è che l’AI non sia abbastanza capace — è che non avete scritto le regole. A dicembre 2025, CodeRabbit ha pubblicato un’analisi su 470 pull request open source che è diventata un punto di riferimento citatissimo: le PR collaborative con AI contengono in media 10,83 problemi, contro i 6,45 delle PR puramente umane — 1,7 volte, ovvero il 70% di bug in più. Nel 2026 la storia non è cambiata: New Relic, nel suo 2026 State of AI Coding Report, rileva che il 78% dei team segnala più incidenti dopo aver messo in produzione codice scritto con l’AI, e il 62% dei leader tecnici ammette che i propri team “inviano codice AI con sicurezza, senza rivederlo riga per riga” (New Relic official report 2026, score 0,866, fonte primaria). I due dati dicono la stessa cosa — all’AI non manca capacità, manca contesto.

Ad agosto 2026, ogni narrativa sull’“accelerazione della trasformazione AI” va letta alla luce di questo confronto.

| Schieramento | Progressi (H1 2026) | Controesempi (H1 2026) |
|—|—|—|—|
| EY | Microsoft 365 Copilot distribuito a 150.000 dipendenti, con un risparmio di 2,5 milioni di ore / 250 milioni di dollari; estensione prevista a 400.000 dipendenti globali | Ammette però che il +95% di velocità e il -37% dei costi di operations finanziarie dipendono dalla “standardizzazione preventiva dei processi” |
| Atos | Implementazione in 54 paesi / 56.000 dipendenti; 19.000 agenti AI attivi in parallelo, con un piano di controllo unificato per identità, sicurezza, conformità e governance | Rigore nell’approccio: “prima attiviamo le capacità di governance di Agent 365, poi scaliamo” |
| Microsoft stessa | Work Trend Index 2026: l’82% dei leader prevede di espandere la forza lavoro con agenti AI entro 12-18 mesi | Riconosce nello stesso periodo che “il ritmo del cambiamento organizzativo è in ritardo rispetto all’adozione individuale” — il nodo centrale del concetto di Frontier Firm |

Fonte: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

Questi due confronti dimostrano una cosa sola: senza governance, scalare significa moltiplicare il rischio per N. La “velocità” di EY/Atos/Microsoft non è una questione di modelli più rapidi, ma di organizzazioni che hanno già risposto alla domanda “come usiamo l’AI”. È questo il contesto in cui la Spec-Driven Development (SDD, sviluppo guidato dalle specifiche) è diventata davvero mainstream nella prima metà del 2026 — non perché gli ingegneri amino la documentazione, ma perché senza specifiche è semplicemente impossibile sopravvivere in un ambiente con 19.000 agenti.

Questo articolo chiarisce tre punti: 1) perché i difetti nel codice generato dall’AI sono oltre 1,7 volte più gravi di quelli umani; 2) come cinque piattaforme — GitHub, AWS, OpenAI, Anthropic e Alibaba — siano arrivate nella prima metà del 2026 allo stesso paradigma: usare la documentazione per vincolare il comportamento dell’AI; 3) perché lo sviluppo guidato dalle specifiche è una capacità organizzativa, non una scelta di strumenti, e quali sono le tre fasi di implementazione nella prima metà del 2026.

Lunghezza barra = multiplo dei difetti AI rispetto all’umano; baseline 1.0× = livello umano

Baseline 1.0×

Problemi totali

1.7×
AI 10.83 vs umano 6.45 / PR

Errori logici / di correttezza

1.75×

Qualità del codice / manutenibilità

1.64×

Riscontri di sicurezza (complessivo)

1.57×

Gestione errata delle password

1.88×

Vulnerabilità XSS

2.74×
↑ massimo

Codice AI senza vincoli normativi supera l’umano in ogni dimensione
Finanza/telecom = riconciliazione conformità, gestione password, crittografia campi sensibili: l’AI non li vede

Uno: il tasso di difetti dell’AI non è un problema di modello, è un problema di contesto

Nel report di CodeRabbit c’è una frase che viene citata di continuo: “L’AI non ha la logica di business locale: il modello inferisce i pattern del codice per via statistica, non per comprensione semantica. Senza vincoli rigorosi, perde le regole di sistema che gli ingegneri senior hanno interiorizzato.”

Questa frase spiega perché la piattaforma di programmazione AI di CodeRabbit (un’azienda specializzata in code review con AI) abbia visto questi dati prima di altri — ogni giorno analizzano migliaia di pull request e osservano com’è fatto il codice scritto dall’AI. Il dato “più critico” non è il totale, ma la distribuzione:

Logica/correttezza +75%: errori di logica di business, errori di dipendenza, errori di flusso di controllo, errori di configurazione — problemi che non emergono necessariamente nei test, ma che in produzione causano incidenti.
Qualità del codice +64%: naming incoerente, struttura poco chiara, violazione dei pattern di progetto — è la “categoria con la maggiore differenza”. Un ingegnere senior lo nota al primo sguardo: “questo non è il nostro stile”.
Sicurezza +57% (XSS la più alta, 2,74×): gestione impropria delle password (1,88×), riferimenti a oggetti non sicuri (1,91×), esposizione di informazioni sensibili, deserializzazione non sicura (1,82×) — nel settore finanziario, non è una questione di “se funziona”, ma di “se si può rilasciare”.

Il problema non è che l’AI non sia abbastanza potente. È che non vede.

Torniamo al vero punto critico del CIO: tre guasti concreti dell’AI nei sistemi core finanziari.

Primo: l’AI non vede 30 anni di logica di riconciliazione. Le regole di risk management delle banche sono scritte nelle stored procedure del sistema core — scritte 30 anni fa, nessuno le ricorda più per intero. Il codice generato dall’AI sembra logicamente corretto, ma in produzione innesca quel controllo di riconciliazione che nessuno ricorda, facendo fallire l’intero batch di transazioni.

Secondo: l’AI non vede i vincoli di compliance. Le password devono passare dal key management system, i campi sensibili devono essere cifrati a riposo, i log non possono stampare informazioni sui clienti — sono vincoli normativi rigidi, scritti nelle policy interne. L’AI non lo sa: il codice che genera funziona, ma non supera la revisione di conformità.

Terzo: l’AI non vede il tuo debito tecnico. Quel sistema host di 30 anni fa usa un protocollo di interfaccia proprietario, la cui documentazione è andata persa da tempo. L’AI scrive codice secondo lo standard RESTful generico, va in produzione e scopre che le interfacce non combaciano — due settimane di rilavorazione.

Torniamo all’altro dato di New Relic: il 62% dei team “rilascia con sicurezza codice AI senza revisione”, e il 78% segnala più incidenti dopo il deploy. Mettendo insieme questi due numeri, il messaggio è chiaro — il tasso di difetti del codice AI non è il problema; “non sapere quali difetti ha il codice AI” è il problema.

Scenario tipico: una banca commerciale ha introdotto lo sviluppo assistito da AI per il modulo di controllo del rischio del suo sistema core. In tre mesi, il tasso di respingimento delle revisioni di conformità è aumentato in modo significativo. I problemi principali riguardavano la gestione delle password, la crittografia dei campi sensibili e la conformità dei log — tutte regole interne. Queste regole erano scritte nella documentazione interna, ma l’AI non poteva vederle. In seguito, il team ha trasferito le regole chiave in un file CLAUDE.md e il tasso di respingimento è calato nettamente.

2. I cinque grandi player nel primo semestre 2026: tutti sulla stessa strada, quella del “model-driven”

A luglio 2025 GitHub ha rilasciato Spec Kit; all’inizio del 2026 AWS Kiro, OpenAI Codex e Anthropic Claude Code hanno completato l’offerta; a maggio 2026 Alibaba Qoder ha integrato il “Spec-Driven Workflow” nel proprio posizionamento di prodotto. Nel primo semestre 2026, le cinque piattaforme sono arrivate allo stesso paradigma: usare la documentazione per vincolare il comportamento dell’AI. Non è un’invenzione di una singola azienda, ma la risposta collettiva del settore alla “crisi di qualità del codice AI”.

Vediamo le ultime mosse di ciascuna piattaforma nel primo semestre 2026:

GitHub Spec Kit: implementazione di riferimento, gate in cinque fasi. Open-sourced a settembre 2025, entro la prima metà del 2026 è già diventato lo standard di riferimento del settore. 5 comandi core + 2 supplementari: /speckit.constitution (principi non negoziabili), /speckit.specify (cosa fare e perché), /speckit.plan (come intervenire), /speckit.tasks (scomposizione in task), /speckit.implement (esecuzione), più /clarify e /analyze. Il punto chiave del design è l’indipendenza dal modello — gli stessi file spec/plan/tasks non sono legati a un agente esecutivo specifico: funzionano con Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf e Qwen Code. Questo lo ha trasformato in un “protocollo SDD a livello organizzativo”, non in un prodotto esclusivo di GitHub (vibecoding.app review, giugno 2026, punteggio 0.816, fonte secondaria).

AWS Kiro: la specifica come motore dell’IDE. Pubblicato a luglio 2025, evoluto in un vero e proprio Agent IDE nel primo semestre 2026. Il flusso di lavoro si articola in tre fasi: requisiti → design → task. La differenza rispetto a Spec Kit sta nei “ganci” (hook): i file spec di Kiro possono attivare azioni predefinite dell’agente, incorporando direttamente nel workflow passaggi che richiedono sistemi esterni, come conformità, audit o deployment. Se vuoi obbligare il team a scrivere le specifiche, scegli Kiro — perché senza spec, Kiro non parte (AWS Kiro, luglio 2025; documentazione Kiro.dev, 2026).

OpenAI Codex: AGENTS.md + Skills componibili. Tra il 2025 e il 2026, AGENTS.md è diventato il fulcro dell’ecosistema. Le Skills sono l’estensione chiave del primo semestre 2026: permettono di pre-assemblare procedure come “leggere un file Excel”, “generare SQL” o “eseguire una migrazione dati”, e di richiamarle come mattoncini Lego. A giugno 2026, Codex ha superato i 5 milioni di utenti attivi settimanali, di cui il 20% non sono sviluppatori — un segnale spesso trascurato: la guida tramite specifiche non riguarda più solo i team di ingegneria, ma tutta l’organizzazione. Product, operations e risk management stanno tutti scrivendo file AGENTS.md (annuncio OpenAI del 2.6.2026; recensione thebcms.com del 2026, punteggio 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic definisce i documenti di istruzioni di progetto come CLAUDE.md (entrato nel mercato ufficiale a febbraio 2026), .claude/rules/ (regole stratificate per directory) e Skills (workflow condivisibili). Claude Code è lo strumento con il più alto tasso di soddisfazione tra gli sviluppatori nel primo semestre 2026 — il sondaggio JetBrains 2026.1 riporta un CSAT del 91% e un NPS di 54, confermati da due ricerche indipendenti (Pragmatic Engineer 2026.2). È il punteggio più alto nell’attuale panorama degli strumenti di coding AI (uvik.net 2026.5, score 0.956, aggregazione di fonti primarie). Claude Code è passato da zero a 2,5 miliardi di dollari di ricavi annualizzati in 9 mesi (dati del round G di Anthropic, febbraio 2026), con 112.000 stelle su GitHub (repository Skills) — gli sviluppatori hanno votato con i fatti, dimostrando il valore reale di un approccio guidato da regole.

Alibaba Qoder: la spinta normativa nel mercato cinese. Rilasciato nell’agosto 2025 e aggiornato alla versione 1.0 il 15 maggio 2026, è passato ufficialmente da “AI IDE” a “Autonomous Agent Development Workbench”. Il suo Spec-Driven Workflow è stato lanciato insieme a Quest Mode (attività multi-file autonome), Expert Mode (team di esperti in parallelo) e RepoWiki (knowledge graph del repository). Il 28 maggio 2026 sono arrivati i Cloud Agents (runtime di agenti completamente gestito), il 21 luglio Qoder Security (capacità di conformità e sicurezza), e nello stesso mese è uscita la versione Mobile (Android/iOS/HarmonyOS). A maggio 2026, gli utenti globali avevano già superato i 5 milioni, e DingTalk CLI lo ha incluso tra gli ambienti di esecuzione agenti supportati (Yahoo Finance 2025; Alibaba Cloud ufficiale 2026; Baidu Baike 2026.7).

3. Lo sviluppo guidato dalle specifiche è una capacità organizzativa, non una scelta di strumenti

Questo è il punto più importante per chi prende decisioni. La spinta normativa non è una scelta di strumenti, ma la definizione di “come la nostra organizzazione collabora con l’AI”. Che tu scelga GitHub Spec Kit o Claude Code non è ciò che conta: ciò che conta è se hai scritto le norme in un documento, le hai messe in un repository, e hai fatto sì che tutte le persone e l’AI lavorino su quella base.

Senza questo, anche i migliori strumenti non fanno altro che far accumulare al team più debito tecnico, a maggiore velocità.

Paradigma condiviso: tutti — esseri umani e agenti AI — lavorano sullo stesso insieme di norme. I cinque team hanno dettagli implementativi diversi (nomi dei file / numero di fasi / meccanismi di hook), ma l’obiettivo è perfettamente identico.

Perché tutto questo si concentra nella prima metà del 2026? Perché la soglia delle capacità dell’AI è già stata superata — Claude Code come agente autonomo, Codex con agenti multipli in parallelo, Cursor con refactoring multi-file: l’AI non è più uno “strumento di completamento”, è un “collega”. Il documento di onboarding che daresti a un nuovo collega, devi poterlo dare anche all’AI.

Mettendo la questione nel contesto delle implementazioni su larga scala della prima metà del 2026, le evidenze diventano ancora più solide. Nel retrospective FY26 pubblicato da Microsoft a luglio 2026, i casi EY e Atos vengono presentati come modello “Frontier Firm” — non perché i modelli siano nuovi, ma perché entrambe le aziende hanno prima risposto alla domanda “come usare l’AI”:

EY: governance prima di tutto, risultati su scala. Tra il 2024 e il 2025, EY ha distribuito Microsoft 365 Copilot a 150.000 dipendenti, risparmiando 2,5 milioni di ore e circa 250 milioni di dollari. Il presupposto è stato “costruire prima il framework di governance dell’AI”: EY ha creato una toolchain unificata con Power Platform, Copilot Studio, Azure, Foundry e Fabric, mettendo conformità, compliance e audit sulla stessa base. Solo così sono arrivati il +95% di velocizzazione, il -37% dei costi operativi finanziari e fino al -90% dei flussi di lavoro manuali. Il vicepresidente di EY è stato molto diretto all’AI Tour 2026: “Non abbiamo prima distribuito l’AI e poi aggiustato la governance: abbiamo prima costruito la governance e poi distribuito l’AI”.

Atos: un piano di controllo unificato per 19.000 agenti. Atos è tra le prime organizzazioni al mondo ad aver implementato Microsoft 365 E7 (Frontier Suite), distribuendo Copilot a 56.000 dipendenti in 54 paesi. Oggi gestisce simultaneamente 19.000 agenti AI — dall’IT interno ai reparti business fino ai progetti per i clienti, tutti costruiti con Foundry e Copilot Studio. Il fattore chiave del successo di Atos è “un unico piano di controllo”: Entra (identità) + Defender (sicurezza) + Intune (dispositivi) + Purview (conformità) + Agent 365 (governance degli agenti), cinque componenti integrati tra loro. Questo modello di integrazione, tradotto nel settore finanziario, corrisponde a un’architettura di governance — che combina requisiti di cybersecurity, protezione dei dati, conformità normativa, audit e governance dei modelli — piuttosto che a un semplice strumento AI.

Il paradosso del cambiamento organizzativo di Microsoft. Nel report Work Trend Index 2026, Microsoft stessa ammette una cosa: “il ritmo del cambiamento organizzativo è in ritardo rispetto all’adozione individuale”. Tra i 20.000 utilizzatori di AI intervistati, l’82% dei leader prevede di espandere la forza lavoro con agenti AI entro 12-18 mesi, ma solo il 24% ha già completato la distribuzione a livello enterprise. L’81% dei leader prevede che gli agenti AI saranno integrati in modo moderato o significativo nella strategia AI — ma anche in questo caso, solo il 24% lo ha già fatto. Ciò significa che la maggior parte delle aziende si trova a 12-18 mesi di distanza tra “preparazione” e “realizzazione”, e il modo in cui colmare questo divario dipende principalmente dalla governance normativa.

Fonte: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, fonte primaria PDF); analisi Futurum Group 2026.1.26 (fonte secondaria).

Lezione 1: investire nella governance offre un ROI elevato.

CodeRabbit fornisce una base chiara per calcolare il ROI: il tasso di problemi nel codice generato dall’AI è circa 1,7 volte superiore, mentre le vulnerabilità di sicurezza si riducono di 2,74 volte. In pratica, questo significa:

Meno rilavorazioni (nel settore finanziario, una sola revisione di conformità può costare da 2 a 4 settimane di lavoro)
Meno incidenti di sicurezza (una violazione dei dati comporta multe normative e danni alla reputazione)
Costi di manutenzione inferiori (una riduzione del debito tecnico del 40% è un dato ricorrente)

Scrivere un file di specifiche di progetto come CLAUDE.md o AGENTS.md è l’investimento ingegneristico con il ROI più alto nell’era dell’AI. Il caso EY offre una conversione concreta: 150.000 persone che usano Copilot, con un risparmio di 250 milioni di dollari. Da notare: EY non ha risparmiato perché “lo strumento è potente”, ma perché “le specifiche hanno permesso di trasformare il valore dello strumento in risultati reali”.

Secondo insegnamento: incorporare le linee guida nei processi organizzativi, non affidarsi ai singoli individui.

Se le linee guida vivono solo nella testa di un ingegnere senior, si perdono non appena quella persona cambia ruolo o azienda. Vanno consolidate in:

Documentazione del repository (AGENTS.md / CLAUDE.md / constitution.md)
Controlli CI (verifica automatica della conformità alle linee guida)
Configurazione condivisa del team (il sistema Skills rende le linee guida utilizzabili da tutto il team)

Trasformare le regole in patrimonio organizzativo, non in competenza individuale

Questo principio è particolarmente critico nel settore finanziario: i requisiti di conformità, le regole di sicurezza e le policy di business sono asset a livello organizzativo, non la “esperienza” di un singolo ingegnere. I 19.000 agent di Atos operano in 54 paesi proprio perché la governance non è “qualcosa che qualcuno conosce”, ma “qualcosa che il sistema impone”.

Terzo insegnamento: i gate di controllo contano più della velocità.

I gate a cinque fasi di GitHub Spec Kit (constitution → specify → plan → tasks → implement), la regola di Claude Code “non scrivere codice prima che i test falliscano”, e l’impossibilità di avviare Kiro senza uno spec — tutti perseguono lo stesso obiettivo: inserire un “freno” tra l’AI e l’output finale. Ogni fase produce artefatti verificabili (spec.md, plan.md, tasks.md), che possono essere respinti o modificati prima della generazione del codice.

Più l’AI è autonoma, più servono gate di controllo. Il Change Advisory Board (CAB) nel settore finanziario, le procedure di registrazione degli algoritmi e le valutazioni di conformità (等保测评, il sistema cinese di classificazione della protezione della sicurezza informatica) sono essenzialmente gate introdotti prima della produzione. Anche il codice generato dall’AI richiede gate simili, solo con forme diverse. I team che, secondo il report 2026 di New Relic, rappresentano quel 62% e “pubblicano con sicurezza senza revisione” stanno pagando questa sicurezza con un tasso di incidenti più alto (78%).

La prima fase richiede più tempo, ma il ROI è il più alto
Nella maggior parte delle istituzioni finanziarie le regole sono sparse in documenti/email/menti; il primo riordino richiede 3-8 settimane

Quattro. Le tre fasi reali di implementazione nella prima metà del 2026

Prendendo il settore finanziario come esempio, il percorso si articola in tre fasi — un modello che può essere esteso ad altri settori fortemente regolamentati. La prassi di EY e Atos nella prima metà del 2026 corrisponde esattamente a queste tre fasi.

Fase 1: Inventario delle regole (2-4 settimane).

È la fase che richiede più tempo ma offre il ROI più alto. Si tratta di rintracciare tutte le regole disperse nell’organizzazione:

Requisiti di conformità: nel settore finanziario, la baseline minima = classificazione di protezione di livello 3 (Dengbao, il sistema cinese di classificazione della sicurezza informatica) + valutazione del trasferimento transfrontaliero dei dati (equivalente alle norme GDPR sull’export di dati) + registrazione degli algoritmi (il meccanismo cinese di filing per i sistemi algoritmici) — se manca anche solo uno di questi elementi, niente implementazione di AI. A questo si aggiungono gli obblighi di reporting regolamentare, la protezione dei dati dei clienti, le restrizioni sui flussi di dati transfrontalieri e la definizione di quali dati possono essere esposti ai sistemi di AI
Regole di sicurezza: gestione delle password, standard di crittografia, trattamento dei campi sensibili, requisiti di logging
Regole di business: soglie di rischio, condizioni di liquidazione sinistri, limiti di transazione, logiche di fatturazione
Vincoli tecnici: interfacce dei sistemi legacy, naming convention dei database, limiti di versione dei framework
Governance dei fornitori: come imporre contrattualmente ai fornitori l’adozione dei nostri standard, come auditare l’uso dell’AI da parte dei fornitori

Scenario tipico: durante la fase di inventario, una società di brokeraggio scopre che le regole sono sparse in una marea di documenti Word, wiki JIRA, email personali e fogli Excel — solo dopo averle raccolte si ottiene un elenco strutturato di regole. L’approccio di Atos è più sistematico: suddividono direttamente le regole in cinque categorie — “conformità, sicurezza, business, tecnica, fornitori” — ognuna con un workflow di governance dedicato, tutte integrate nel piano di controllo di Agent 365.

Non è una questione tecnica, è una questione organizzativa: devi riunire il team di conformità, il team di sicurezza e il team di business, e mettere per iscritto le regole che tutti condividono. La prima volta che lo fai, un’organizzazione finanziaria impiega in genere 3-8 settimane — ma è un asset organizzativo permanente.

Fase 2: caricare nel repository (1-2 settimane).

Scrivi le regole raccolte nella Fase 1 come documenti e caricale nel repository. GitHub Spec Kit usa constitution.md, Claude Code usa CLAUDE.md, OpenAI Codex usa AGENTS.md, Alibaba Qoder usa Spec Workflow. I nomi dei file sono diversi, ma l’obiettivo è lo stesso: far sì che l’IA le carichi nel momento in cui apre il repository.

Struttura consigliata (forma prevalente nella prima metà del 2026):

Panoramica del progetto: cosa fa questo sistema e a chi serve
Principi non negoziabili: linee rosse di sicurezza, conformità normativa e continuità operativa
Stack tecnologico e vincoli: framework, database e standard di interfaccia adottati
Standard di codice: convenzioni di naming, struttura delle directory e requisiti minimi di copertura dei test (senza imporre il ritmo TDD — basta definire soglie di copertura, percorsi obbligatori da testare e percorsi vietati; il TDD resta una scelta organizzativa, non un requisito normativo)
Regole di business: logiche di risk management, regole transazionali e criteri di fatturazione
Requisiti di conformità: classificazione della sicurezza (等保), trasferimento transfrontaliero dei dati, reporting regolamentare e obbligo di registrazione per algoritmi di IA generativa
Linee guida sull’uso dell’IA: casi d’uso ammessi, ambiti che richiedono revisione umana obbligatoria e regole sul trasferimento dei dati all’estero
Governance dei fornitori: clausole contrattuali, meccanismi di audit e ripartizione delle responsabilità

Appendice: scheletro CLAUDE.md per il settore finanziario (circa 200 righe, pronto da fork e adattare)

Di seguito uno scheletro di CLAUDE.md pensato per la modernizzazione del core banking di una banca commerciale, organizzato secondo la sequenza “principi non negoziabili → requisiti di conformità → uso dell’IA → regole di business → vincoli ingegneristici”. Non serve partire da zero: basta inserire le vostre regole specifiche negli spazi predisposti.

# CLAUDE.md — <nome del sistema> — standard di collaborazione con l'AI

> Ambito di applicazione: <nome del sistema> v<versione>. Tutti gli agenti AI (Claude Code / Cursor / Copilot / Codex)
> che lavorano in questo repository devono rispettare il presente standard. Il file è mantenuto dal <comitato di governance>,
> con revisione trimestrale.
> Ultimo aggiornamento: YYYY-MM-DD

## 1. Panoramica del progetto
- **Posizionamento di business**: nome del sistema core / segmenti di clientela / principali tipologie di transazione
- **Catena critica**: transazione → risk management → compensazione → riconciliazione → segnalazione
- **Finestra di indisponibilità**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (vietato qualsiasi intervento)
- **Dipendenze principali**: sistema a monte <sistema>, sistema a valle <sistema>, piattaforma di segnalazione regolamentare

## 2. Principi non negoziabili (linee rosse: ogni violazione = rifiuto della merge)

### 2.1 Linee rosse di sicurezza
- Password, chiavi e token devono passare esclusivamente dal KMS (Key Management Service): **vietato l'hardcoding**, **vietata la stampa nei log**
- I campi sensibili del cliente (documento d'identità / numero di carta / CVV / cellulare) **devono essere cifrati a riposo**; il testo in chiaro non può essere memorizzato in banca dati
- Nei log è vietato inserire: documento d'identità completo, numero di carta completo, password in chiaro, combinazione di nome cliente + numero di cellulare
- Le chiamate verso API esterne devono tassativamente passare dal API gateway; le connessioni dirette sono vietate

### 2.2 Linee rosse di conformità
- Se il codice generato dall'AI accede a dati del cliente, nella descrizione della PR deve essere riportata la dicitura "accesso dati: <campo>"
- È vietato il trasferimento transfrontaliero di dati; **ogni uscita di dati deve seguire il processo di Valutazione del trasferimento transfrontaliero di dati** (contattare l'ufficio conformità)
- Le decisioni algoritmiche (credito / tariffazione assicurativa / antifrode) devono mantenere un canale di revisione umana
- Ogni modifica di modello richiede la Registrazione degli algoritmi; il numero di registrazione deve essere citato nella descrizione della PR

### 2.3 Linee rosse di business
- La modifica delle soglie di risk management richiede la doppia firma del responsabile risk management + responsabile di business
- Le operazioni che coinvolgono fondi del cliente devono prevedere un design idempotente + rollback in caso di fallimento
- Le modifiche di limiti di transazione, commissioni e parametri di prodotto passano dalla piattaforma di gestione parametri; nessun hardcoding nel codice

## 3. Stack tecnologico e vincoli
- **Linguaggi**: Java 17 (core) / Kotlin (nuovi moduli) / SQL (database)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Database**: OceanBase 4.x (modalità compatibile MySQL); **vietato l'uso di chiavi esterne**
- **Standard di interfaccia**: gRPC per tutti i servizi interni; OpenAPI 3.0 per le interfacce esterne; RESTful solo per le interfacce di gestione
- **Convenzioni di denominazione**: classi Java in PascalCase, metodi in camelCase, costanti in UPPER_SNAKE; nomi tabella `t_<dominio>_<entità>`; indici `idx_<tabella>_<colonna>_<ordine>`
- **Struttura dei package**: `com.<società>.<dominio>.<sotto-dominio>.<livello>` (es. `com.bank.pay.tx.core.service`)

## 4. Standard di codice
- **Copertura minima dei test**: catena critica ≥ 80%, classi di utilità ≥ 60%; ogni PR di nuovo codice deve includere i test
- **Percorsi da testare obbligatoriamente**: tutti i controller devono avere test di integrazione (inclusi i percorsi di fallimento); tutti i rami degli enum devono avere unit test
- **Percorsi vietati**: è vietato modificare la directory `<modulo di debito storico>` — occorre prima creare uno strato di adattamento
- **Gestione delle dipendenze**: ogni nuova dipendenza di terze parti richiede una scansione SCA + approvazione della sicurezza

## 5. Regole di business (per dominio)
### 5.1 Transazioni
- Limite per singola operazione: <importo>; limite giornaliero: <importo>; il superamento richiede approvazione manuale
- Finestra temporale delle transazioni: <HH:MM> ~ <HH:MM>
- Criterio di duplicazione: stesso <campo> entro <finestra temporale> = transazione duplicata

### 5.2 Risk management
- Ordine di priorità delle liste nere: lista nera interna → liste regolamentari diffuse dall'autorità → blocco giudiziario
- Soglia di output del modello antifrode: <punteggio>; oltre tale soglia è obbligatoria la doppia revisione umana

### 5.3 Fatturazione
- Ogni modifica di tariffa deve avere un numero di versione + una data di decorrenza
- Gli ordini storici sono calcolati con la tariffa in vigore alla data di decorrenza, senza retroattività

## 6. Requisiti di conformità
- MLPS Livello 3 (classificazione cinese di protezione della sicurezza informatica - 等保三级): <autorità di vigilanza>, <data della prossima valutazione>
- Valutazione del trasferimento transfrontaliero di dati: ambito di applicazione (solo moduli di business transfrontaliero)
- Registrazione degli algoritmi: ambito di applicazione (algoritmi critici come credito / tariffazione assicurativa), numero di registrazione `<n. registrazione>`
- Segnalazioni regolamentari: tabella di mappatura dei campi per <CBIRC / Banca Popolare Cinese> al percorso `<percorso>`

## 7. Standard di utilizzo dell'AI
- **Scenari in cui l'AI è ammessa**: CRUD standard, generazione di unit test, bozze di documentazione, suggerimenti di ottimizzazione SQL
- **Scenari che richiedono obbligatoriamente la revisione umana**: logica di risk management, regole di fatturazione, controllo dei permessi, cifratura/decifratura, dati transfrontalieri
- **Scenari vietati all'AI in autonomia**: materiali di approvazione CAB (Change Advisory Board), esecuzione di modifiche in produzione, gestione delle emergenze
- **Regole sul trasferimento transfrontaliero dei dati**: dati di addestramento / prompt / log di output non possono uscire dal paese; priorità alle versioni con deployment localizzato (<fornitore>)
- **Requisiti di audit**: tutto il codice generato dall'AI deve riportare nella descrizione della PR la dicitura "Assistenza AI: <nome dello strumento>"

## 8. Governance dei fornitori
- **Onboarding dei fornitori**: obbligo di fornire report SOC 2 / ISO 27001; i modelli AI devono essere accompagnati dalla model card
- **Clausole contrattuali**: titolarità dei dati, interpretabilità del modello, clausola di uscita, diritto di audit
- **Meccanismi di audit**: audit trimestrale sull'uso dell'AI da parte dei fornitori; audit mensile per i fornitori ad alto rischio

## 9. Governance e aggiornamenti
- **Proprietario**: <comitato di governance> (conformità + sicurezza + architettura + business)
- **Frequenza di aggiornamento**: revisione trimestrale; per le Modifica di emergenza si attiva il canale rapido (doppia firma + pubblicazione di 24 ore)
- **Registro delle modifiche**: vedere `CLAUDE_CHANGELOG.md`
- **Gestione delle violazioni**: prima violazione = richiamo + formazione obbligatoria; seconda violazione = sospensione dell'uso degli strumenti AI; terza violazione = revoca dei permessi

Questa struttura non è una “risposta standard”, è un “modello da compilare”. Ciò che conta non è quanto scrivi in ogni campo, ma cosa ci metti dentro — gli spazi vuoti rivelano esattamente le parti su cui la vostra azienda “non ha ancora le idee chiare”.

Scenario tipico: il CLAUDE.md di una banca commerciale definisce regole specifiche per la gestione delle password — quando il codice generato dall’AI coinvolge password, deve obbligatoriamente richiamare l’API interna di gestione dei segreti, vietando l’hardcoding. Questo tipo di regole rappresenta una quota elevata dei motivi di respingimento nelle revisioni di conformità.

Nel primo semestre 2026, un campo nuovo e importante è Skills/definizione dei workflow — non più solo documentazione, ma una toolchain che l’AI può effettivamente invocare. Il sistema Skills di Claude Code (entrato nel marketplace ufficiale di Anthropic a febbraio 2026, 112.000 stelle su GitHub) trasforma operazioni come “leggere un file Excel”, “generare SQL” o “eseguire una migrazione dati” in workflow condivisibili. Questa è l’evoluzione chiave del paradigma normativo nel primo semestre 2026: le regole non sono solo vincoli, sono workflow eseguibili.

Fase tre: istituzionalizzazione (continua).

Scrivere le linee guida non è il traguardo, è il punto di partenza. Devi trasformarle in parte integrante dei processi organizzativi:

Gate CI integrato: verifica automatica che il codice rispetti le regole (ad esempio, rilevamento di password hardcoded o campi sensibili non cifrati)
Configurazione condivisa per il team: usa il sistema Skills per far sì che tutto il team adotti lo stesso set di regole
Meccanismo di aggiornamento periodico: quando le regole cambiano, anche le linee guida devono cambiare (revisione trimestrale)
Metriche e feedback: monitora il tasso di difetti nel codice generato da AI, il tasso di superamento delle verifiche di conformità e il tasso di rilavorazione
Governance degli agenti: estendi la governance dalle persone agli agenti AI — è esattamente ciò che Atos ha fatto con Agent 365, portando questo concetto da “livello individuale” a “livello sistemico”

Nel primo semestre 2026, sia EY che Atos hanno trasformato la terza fase in “capacità organizzativa”. Il risparmio di 2,5 milioni di ore dichiarato da EY è il risultato di aver impostato correttamente la prima e la terza fase — la seconda fase si è limitata a tradurre le regole in documenti leggibili dall’AI.

Cinque. Variante per settori fortemente regolamentati: tre approcci ingegneristici per incorporare la conformità

Nei settori fortemente regolamentati come finanza, telecomunicazioni e sanità, l’implementazione guidata dalle linee guida richiede un passaggio in più rispetto ai settori generali — la conformità non è un modulo esterno al processo, è parte integrante del codice. I tre approcci seguenti sono modalità di incorporazione della conformità validate nel primo semestre 2026, e i CIO e i responsabili della trasformazione digitale possono farvi direttamente riferimento nella progettazione organizzativa.

5.1 Rappresentanti di conformità integrati nei team di flusso: la conformità “presente sul campo”, non “in fase di approvazione”

L’approccio tradizionale: il team di sviluppo scrive il codice, il team di conformità lo verifica a posteriori — quando l’audit rileva un problema, il codice è già in produzione da due settimane, e il costo del rifacimento è di 2-4 settimane. Il problema di fondo è che la conformità arriva alla fine del processo.

Il nuovo approccio: integrare un rappresentante di conformità in ogni team di flusso (stream-aligned team), con una struttura di doppia linea di riporto: “linea solida” verso il dipartimento di conformità e “linea tratteggiata” verso il team di business. Nel concreto:

Dotazione organica: un rappresentante di conformità ogni 6-8 team di flusso, inquadrato nel dipartimento di conformità ma con postazione fisica nel team di business — non un “distacco” temporaneo
KPI in linea tratteggiata: il 50% della valutazione del rappresentante di conformità è legato al “tasso di difetti di conformità” e al “tasso di superamento delle revisioni al primo colpo” del team di business, non solo alla “copertura degli audit” del dipartimento di conformità
Intervento a monte: il rappresentante di conformità partecipa allo stand-up giornaliero (una volta a settimana è sufficiente), alle revisioni delle pull request, e il codice generato dall’AI deve essere validato dal rappresentante di conformità prima del merge — non scoperto e corretto dopo il merge
Supporto strumentale: il rappresentante di conformità utilizza le Skills della checklist di conformità, invece di fare verifiche manuali riga per riga

Scenario tipico: una banca commerciale a livello nazionale ha avviato nel primo semestre 2026 un progetto pilota con 3 team di sviluppo che integrano un referente compliance, riducendo il tasso di rifiuto per conformità del codice AI dal 35% all’8% — il punto non è che la compliance “controlli più severamente”, ma che “intervenga prima”. La chiave di questo approccio è che gli obiettivi del referente compliance siano allineati a quelli di business tramite una linea di riporto debole — se il suo KPI resta legato esclusivamente ai compiti assegnati dal dipartimento compliance, l’integrazione è destinata a fallire.

5.2 La compliance come enabling team: trasformare i vincoli in affordance

L’approccio tradizionale: il team compliance fa da “guardiano”, e i team di business lo percepiscono come “quello che crea problemi”. Risultato: un gioco a somma zero tra le due parti.

Il nuovo approccio: il team compliance viene ristrutturato secondo il modello enabling team di Team Topologies — non scrive codice direttamente, non fa review delle pull request, ma fornisce tre elementi che consentono ai team di business di essere “auto-conformi”:

Controlli di conformità integrati nella pipeline CI: i punti critici ricorrenti — hardcoding di password, campi sensibili in chiaro, trasferimenti transfrontalieri di dati, punti decisionali algoritmici — vengono trasformati in gate obbligatori su GitHub Actions / GitLab CI. Una PR del team business attiva il controllo automatico; se non conforme, fallisce direttamente — senza bisogno che il compliance officer faccia una verifica manuale.
Requisiti normativi come affordance (vincoli reattivi all’ambiente): ad esempio, quando si sviluppa una funzionalità che coinvolge dati dei clienti, il plugin dell’IDE mostra un suggerimento del tipo “per questo campo si consiglia di chiamare KMS”; durante la scrittura dei log, il sistema rileva automaticamente se sono presenti informazioni sensibili e genera un alert. L’obiettivo è che la conformità diventi “un’azione naturale durante lo sviluppo”, non “scoprire a posteriori cosa si è violato prima del rilascio”.
Libreria condivisa di Skills + formazione sulla conformità: il team compliance mantiene una raccolta di “Skills di conformità” a cui si accede direttamente all’onboarding di nuovi assunti o al passaggio tra team — trasformando la conoscenza normativa da “documentazione” a “strumento eseguibile”.

Scenario tipico: una banca regionale cinese ha attivato nel primo semestre 2026 i gate di conformità CI e i suggerimenti IDE, riducendo il tempo medio pro-capite per la revisione di conformità del codice AI da 45 minuti a 8 minuti per sessione. Il punto chiave non è che la “revisione” sia più veloce, ma che il codice generato da AI “non sbagli” a monte.

5.3 Conformità a doppia velocità: stratificazione per adattarsi al ritmo del business

L’ultimo dettaglio: la conformità non va gestita con un approccio unico per tutti. Dividete le regole in due livelli in base al rischio:

Regole ad alto rischio (che coinvolgono fondi dei clienti / decisioni algoritmiche / dati transfrontalieri / requisiti di sicurezza critici) richiedono controlli rigorosi: revisione manuale obbligatoria + doppia conferma AI + registrazione presso il Change Advisory Board
Regole a basso rischio (codice CRUD standard / utility / generazione di documentazione) seguono controlli self-service: basta la verifica automatica in CI, nessuna revisione manuale richiesta

Il control plane di Agent 365 di Atos è essenzialmente questa stratificazione: agenti di livello diverso sono vincolati a requisiti di governance diversi. Stratificare le regole di conformità per livello di rischio permette ai team di business di percepire che “la conformità non blocca tutto”.

Il quadro complessivo di queste tre cose: incorporare la conformità non significa aggiungere un passaggio procedurale, ma riprogettare la struttura e gli incentivi del team. Se il vostro ufficio compliance è ancora in modalità “revisione a posteriori”, l’adozione guidata dalle regole si bloccherà proprio sullo step più difficile — quello dell’”istituzionalizzazione”. L’ufficio compliance deve prima trasformarsi, perché l’adozione guidata dalle regole possa funzionare senza intoppi.

6. Domande probabili

“Abbiamo già delle linee guida di codifica — qual è la differenza?”

Le linee guida di codifica riguardano “come scrivere codice”; l’adozione guidata dalle regole riguarda “come collaborare con l’AI”. Le linee guida di codifica non includono: regole di business, requisiti di conformità, policy d’uso dell’AI. L’adozione guidata dalle regole rende esplicito l’intero flusso di collaborazione tra umani e AI — non è una guida di stile per il codice.

“Scrivere delle linee guida non rallenterà lo sviluppo?”

A breve termine sì, a lungo termine no. I dati di CodeRabbit danno una risposta chiara: il rischio di difetti nel codice AI senza vincoli è circa 1,7 volte più alto, e quello di vulnerabilità di sicurezza 2,74 volte. Nel settore finanziario, una revisione per conformità costa 2-4 settimane di rilavorazione — evitare una sola di queste ripetizioni ti dà il tempo per scrivere un mese di linee guida. I 250 milioni di dollari risparmiati da EY sono la prova concreta che questo approccio funziona quando diventa una capacità organizzativa.

“E se nel nostro team nessuno sa scrivere linee guida?”

Non devi partire da zero. GitHub Spec Kit, Claude Code Superpowers e AWS Kiro offrono tutti dei template. Devi solo inserire le regole specifiche della tua organizzazione — per la maggior parte si tratta di regole di conformità e sicurezza, che i dipartimenti di compliance e security hanno già scritto da tempo. Il problema è che non sono mai state messe in un formato che l’AI potesse leggere.

“Ci sono così tanti strumenti AI, quale scegliamo?”

Non è importante. Scegliete quello che già usate. Le specifiche guidano, non vincolano agli strumenti: CLAUDE.md funziona in Claude Code, Cursor e Codex; AGENTS.md gira nell’ecosistema OpenAI; constitution.md è indipendente dal modello. Il punto è scrivere le specifiche, non cambiare strumento. EY sta implementando nell’ecosistema Microsoft, Atos pure: la scelta dello strumento è solo superficie, l’uniformità della governance è la sostanza.

“L’EU AI Act diventa pienamente applicabile ad agosto 2026: questo ci riguarda?”

Sì. L’EU AI Act entra in piena applicazione il 2 agosto 2026, con requisiti obbligatori per i sistemi di IA ad alto rischio (inclusi credito, tariffazione assicurativa, selezione del personale e infrastrutture critiche): gestione del rischio (Art. 9), governance dei dati (Art. 10), trasparenza documentale (Art. 11-13), supervisione umana (Art. 14), accuratezza/robustezza (Art. 15). Le sanzioni arrivano fino a 35 milioni di euro o al 7% del fatturato globale. Per le aziende cinesi che si espandono all’estero, il mercato UE è una prova obbligata; per quelle domestiche, il quadro dell’EU AI Act è anche il riferimento più adottato a livello globale — puoi anche non esservi direttamente soggetto, ma difficilmente puoi ignorarne gli effetti di trasmissione su fornitori, partner e attività transfrontaliere (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Il parallelo interno: l’UE regola l’IA, e da noi?”

A livello nazionale, la governance dell’IA generativa si basa su un trio di strumenti: “registrazione degli algoritmi + revisione dei dati di addestramento + valutazione della sicurezza”, con il Regolamento provvisorio sulla gestione dei servizi di IA generativa (entrato in vigore ad agosto 2023) come pilastro centrale. La differenza più grande tra i due approcci non sta nel dettaglio delle disposizioni, ma nella filosofia legislativa:

Dimensione	EU AI Act	Regolamento cinese sulle “Misure di gestione dei servizi di IA generativa”
Natura giuridica	Regolamento orizzontale (si applica a tutti i sistemi di IA)	Regola verticale (focalizzata sui servizi di IA generativa)
Classificazione del rischio	4 livelli (inaccettabile / alto / limitato / minimo)	2 livelli (che coinvolgono la sicurezza dell’opinione pubblica / uso commerciale generale)
Tempistica della supervisione	Ex ante (registrazione già in fase di sviluppo)	Ex post (registrazione dopo il lancio + registrazione dell’algoritmo)
Trasparenza	Alta (richiede la pubblicazione di un riepilogo delle fonti dei dati di addestramento e delle model card)	Media (richiede la conformità dei dati di addestramento ma non impone la divulgazione delle fonti)
Massima sanzione	7% del fatturato globale o 35 milioni di euro	Sospensione del servizio / sanzioni pecuniarie (di solito multipli dei proventi illeciti)
Ambito di applicazione	Tutte le imprese che superano la soglia di fatturato globale	Tutti i soggetti che forniscono servizi sul territorio cinese

In pratica, i sistemi di IA degli istituti finanziari cinesi sono normalmente soggetti a tre livelli di regolamentazione simultanei — le Misure per la gestione dell’IA generativa (livello di base) + le Misure per la gestione dei prestiti online delle banche commerciali (livello operativo) + la classificazione di protezione della sicurezza informatica (等保, dengbao) + la registrazione degli algoritmi (livello di conformità). Questo significa che, per chi opera in Cina, non si può semplicemente ricalcare il framework dell’EU AI Act: bisogna integrare tutte e tre le direttrici — conformità dei dati di addestramento, registrazione degli algoritmi e reporting normativo — direttamente nel file CLAUDE.md.

Per chi si espande all’estero: i quattro pilastri dell’EU AI Act — gestione del rischio, governance dei dati, trasparenza documentale e supervisione umana — sono esattamente le direzioni verso cui anche la regolamentazione cinese si sta allineando. Già nel 2025, alcuni feedback sulle registrazioni di IA generativa da parte della Cyberspace Administration of China (CAC) mostrano un’evidente assimilazione del livello di dettaglio europeo. Scrivere oggi una policy compatibile con l’EU AI Act significa, con alta probabilità, essere già allineati anche con l’inasprimento normativo cinese dei prossimi tre anni (annunci di registrazione CAC 2025-2026; scadenza conformità EU AI Act: giugno 2026).

7. Cosa significa per i decision maker

Primo punto: scrivere una policy di progetto in un file CLAUDE.md o AGENTS.md è l’investimento di ingegneria con il più alto ROI nell’era dell’IA.

Il costo è di 3-8 settimane per organizzare il materiale, più 1-2 settimane per la documentazione. Il ritorno: il limite superiore del rischio di difetti si riduce a circa 1,7 volte, le vulnerabilità di sicurezza calano di 2,74 volte, e il tasso di rilavorazione scende di oltre il 40%. Nel settore finanziario, bastano una sola revisione di conformità evitata (2-4 settimane) a coprire questo costo. EY ha distribuito Copilot a 150.000 dipendenti risparmiando 250 milioni di dollari — ma solo perché prima aveva definito degli standard.

Lezione 2: La standardizzazione è una capacità organizzativa, non una scelta di strumenti.

Che tu scelga GitHub Spec Kit o Claude Code non è ciò che conta. Ciò che conta è se hai definito “come la nostra organizzazione collabora con l’AI”. Senza questo, anche il miglior strumento si limita a far accumulare debito tecnico più velocemente.

Lezione 3: Integra gli standard nei processi organizzativi, non affidarti ai singoli.

Se gli standard vivono solo nella testa di un ingegnere senior, si perdono appena quella persona cambia ruolo o azienda. Devono essere incorporati nella documentazione del repository, nei gate CI, nelle configurazioni condivise del team e nelle piattaforme di governance degli agenti. Gli standard devono diventare un asset organizzativo, non una competenza individuale. I 19.000 agenti di Atos operano in 54 paesi perché la governance non è “qualcuno che capisce”, ma “il sistema che impone”.

Lezione 4: I gate contano più della velocità.

GitHub Spec Kit 的 gate a cinque fasi, la regola di Superpowers “niente codice finché il test non fallisce”, l’obbligo di Kiro di “non si parte senza spec”: sono tutti modi per mettere un freno tra l’AI e il risultato finale. Più l’AI diventa capace, più la governance deve venire prima. Il 78% di incidenti nel report New Relic 2026 è il prezzo pagato da quel 62% di team che rilascia senza revisione. I CIO del settore finanziario lo capiscono meglio di chiunque altro: il vostro Change Advisory Board (CAB), le procedure di registrazione degli algoritmi, i test di conformità (等保测评, il sistema cinese di classificazione e verifica della sicurezza informatica) — sono tutti gate prima della messa in produzione. Anche il codice generato dall’AI ha bisogno di gate simili, e devono essere ancora più a monte.

Auto-verifica inversa (senza abbellire la risposta): il codice generato dall’AI che producete, la revisione di conformità richiede spesso rilavorazioni? Qual è stato l’ultimo problema causato da codice AI? Se chiedete al responsabile tecnico “come collaboriamo con l’AI”, sa produrvi un documento? Se non sapete rispondere a una di queste tre domande, significa che la governance basata su specifiche non è ancora operativa — prima le specifiche, poi gli strumenti.

Tre domande da coach per i decision maker

Chiudo con tre domande — non una checklist, ma spunti che potete usare direttamente nelle discussioni col vostro team:

“Se domani tutti gli strumenti di AI venissero spenti, di quanto calerebbe la qualità del codice del vostro team?” — Questa domanda rivela il valore reale dell’engineering enablement: se la risposta è “calerebbe significativamente”, significa che le vostre linee guida non sono ancora state interiorizzate; se la risposta è “quasi per niente”, allora l’approccio basato su standard sta già funzionando.
“Nel vostro progetto di engineering enablement, il team compliance svolge il ruolo di ‘guardiano’ o di ‘enabler’?” — Se la risposta è “guardiano”, la vostra velocità di implementazione sarà bloccata dai colli di bottiglia delle approvazioni; se la risposta è “enabler”, avete già intrapreso il percorso descritto nella sezione 5.2.
“Tra 12-18 mesi, come cambierà la dimensione del vostro team?” — La risposta del Microsoft WTI 2026 è che l’82% dei leader utilizzerà agenti AI per “espandere” la forza lavoro. Se la vostra risposta è “non cambierà”, o il vostro business non sta crescendo, oppure il vostro design organizzativo non sta sfruttando i benefici dell’engineering enablement.

Non esistono risposte giuste o sbagliate a queste tre domande. Ma la direzione delle risposte è più importante delle risposte stesse.

Prossimi passi

Questo è il sesto articolo della serie “La trasformazione dell’ingegneria del software nell’era dell’AI”. Siamo partiti da Conway (l’organizzazione determina l’architettura), passando per Team Topologies (come progettare l’organizzazione), fino al collo di bottiglia che si sposta (il problema non è la codifica ma la verifica). Oggi abbiamo parlato di engineering enablement (usare la documentazione per vincolare il comportamento dell’AI).

Nel prossimo articolo (il settimo), esamineremo l’infrastruttura sottostante che rende possibile tutto questo: il protocollo MCP (Model Context Protocol). Perché il protocollo open source di Anthropic è stato definito “l’USB-C dell’IA”, perché OpenAI, Google e Microsoft lo hanno tutti adottato, e come consente l’interoperabilità tra più strumenti e più agenti.

Vuoi applicare questo approccio alla tua azienda?

Quando l’approccio normativo entra in azienda, i problemi concreti da risolvere sono di solito pochi e specifici: come far confluire le regole chiave in CLAUDE.md / AGENTS.md, come adeguare il codice esistente, come integrare la conformità normativa, e con quali metriche valutare il progetto pilota.

Offriamo tre tipi di collaborazione:

Formazione aziendale: sulla base dei tuoi progetti reali, aiutiamo a strutturare la documentazione normativa, progettare i gate CI, definire il percorso di integrazione della conformità e costruire il meccanismo di governance.
Consulenza mirata: ci concentriamo su una decisione specifica, ad esempio “la nostra azienda dovrebbe iniziare scrivendo CLAUDE.md / AGENTS.md?” o la definizione delle priorità per la messa a norma del codice esistente.
Interventi per il management e keynote di settore: su strumenti di programmazione con IA, approccio normativo, governance organizzativa e Frontier Firms.

L’articolo fornisce un quadro generale di riferimento. L’implementazione concreta richiede comunque una riprogettazione basata sui requisiti di conformità aziendali, i confini normativi, la maturità ingegneristica e i processi di delivery esistenti. Per collaborazioni: coach@iaiuse.com.

Approfondimento: Metodologia Insegna il Metodo v1.0 (Imparare l’AI Lentamente 187), che presenta sistematicamente il framework in 7 fasi per la trasformazione AI delle imprese.

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 trasformazione digitale nei settori telecomunicazioni, finanza, manifattura ed e-commerce. La serie comprende 18 articoli e si concentra su come gli strumenti di programmazione AI, la governance basata su standard e la governance organizzativa influenzino i processi di delivery del software, le strutture organizzative e la maturità ingegneristica.

La serie monitora costantemente paper accademici, materiali dei vendor e report di settore. Il database di ricerca conta oltre 200 fonti, e per ogni giudizio chiave viene indicato il livello di evidenza, distinguendo il più possibile tra fatti verificati, affermazioni dei vendor, osservazioni di settore e deduzioni dell’autore.

Vanto di quasi 8 anni di esperienza in consulenza per grandi imprese e analisi di business, con un passato in IBM e progetti nei settori telecomunicazioni, finanza, assicurazioni e manifattura. Successivamente, ho continuato a operare in prima linea nello sviluppo di prodotti per operatori, prodotti internet e applicazioni AI, occupandomi di analisi dei requisiti, product design e implementazione cross-funzionale.

Questa serie di riflessioni su governance basata su standard, organizzazione e ingegnerizzazione nasce da queste esperienze pratiche, incrociate con ricerca pubblica e casi di settore per una validazione incrociata. I contenuti relativi a progetti specifici sono stati resi anonimi; alcuni scenari di settore sono ricostruzioni di problemi tipici, con le relative fonti elencate in fondo al documento.

Dietro questa pubblicazione c’è in realtà un piccolo team — io e 1-2 colleghi con cui collaboro da tempo, ognuno dei quali si occupa rispettivamente di ricerca sugli strumenti di coding con AI, 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 è preservato per lasciare spazio a futuri colleghi con cui collaboreremo.

Fonti di riferimento (tutte verificate, con livello di evidenza indicato per ciascuna)

CodeRabbit (2025.12). State of AI vs Human Code Generation Report. I problemi nel codice generato dall’AI sono 1,7 volte superiori a quelli del codice umano (10,83 vs 6,45 problemi per PR), con un rapporto di 1,75× per logica/correttezza, 1,64× per qualità del codice, 1,57× per sicurezza, 1,88× per gestione delle password e 2,74× per XSS. Livello di evidenza: primario. Fonte: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263
The Register (17.12.2025). Riporta il report completo di CodeRabbit: analisi di 470 PR open source, con PR assistite da AI che presentano 10,83 problemi contro i 6,45 dei PR puramente umani. Livello di evidenza: secondario. Fonte: URL sopra indicato
CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — il 2026 sarà l’anno della svolta: si passa dalla “velocità di generazione del codice” alla “qualità e governance del codice”. Livello di evidenza: secondario. Fonte: https://tfir.io/ai-code-quality-2026-guardrails
New Relic (2026). The 2026 State of AI Coding Report. Il 78% dei team registra più incidenti dopo aver messo in produzione codice generato dall’AI; il 62% dei leader tecnici ammette che i propri team “pubblicano con fiducia senza revisione” codice AI; il 96% ritiene l’osservabilità indispensabile. Livello di evidenza: primario (report del vendor). Fonte: https://newrelic.com/resources/report/2026-state-of-ai-coding
Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Sondaggio su 20.000 professionisti che usano l’AI, in 10 Paesi; l’82% dei leader prevede di espandere la forza lavoro con agenti AI entro 12-18 mesi; l’81% prevede un’integrazione media o elevata degli agenti AI; il 24% ha già implementato a livello enterprise; il 49% delle conversazioni con Copilot supporta il lavoro cognitivo; il 58% degli utenti AI dichiara di aver fatto “cose che un anno fa non sarebbero state possibili”, percentuale che sale all’80% tra i Frontier Professionals. Livello di evidenza: primario. Fonte: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
Microsoft FY26 Retrospective: dall’esperimento AI alla trasformazione di frontiera (28 luglio 2026). EY ha distribuito Microsoft 365 Copilot a 150.000 dipendenti, generando un risparmio di 2,5 milioni di ore e circa 250 milioni di dollari; l’implementazione è poi stata estesa a 400.000 dipendenti a livello globale, con un aumento della velocità del 95%, una riduzione del 37% dei costi operativi finanziari e una diminuzione fino al 90% dei flussi di lavoro manuali. Atos ha implementato Copilot in 56 paesi per 56.000 dipendenti, affiancando 19.000 agenti AI, con un piano di controllo unificato per identità, sicurezza, conformità e governance. Livello di evidenza: livello 1 (revisione ufficiale Microsoft). Fonte: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Collaborazione strategica tra Atos Group e Microsoft (2026.6.9). Atos implementa Microsoft 365 E7 (Frontier Suite) per 56.000 dipendenti in 56 paesi, con 19.000 agenti AI; piano di controllo unificato per Entra/Defender/Intune/Purview/Agent 365. Livello di evidenza: primario (comunicato stampa congiunto). Fonte: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group-workforce-and-clients
GitHub Spec Kit (open source nel settembre 2025, in evoluzione nella prima metà del 2026). Processo a 5 fasi con gate /speckit.constitution → /specify → /plan → /tasks → /implement, più /clarify /analyze; indipendente dal modello (funziona con Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Livello di evidenza: primario. Fonte: https://github.com/github/spec-kit
AWS Kiro (rilasciato a luglio 2025, in evoluzione nella prima metà del 2026). Workflow in tre fasi: requisiti → progettazione → attività; lo spec attiva azioni predefinite degli agenti; senza spec non si può avviare. Livello di evidenza: primario. Fonte: https://kiro.dev/
OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 ha superato i 5 milioni di utenti attivi settimanali, di cui il 20% non sviluppatori; AGENTS.md + Skills formano un set di istruzioni componibili. Livello di evidenza: primario (annuncio ufficiale OpenAI). Fonte: https://developers.openai.com/codex/skills
Claude Code (Anthropic, primo semestre 2026). Sistema basato su CLAUDE.md + .claude/rules/ + Skills; entrato nel marketplace ufficiale Anthropic a febbraio 2026; il repository GitHub delle Skills ha raggiunto 112.000 stelle; il round di serie G del febbraio 2026 ha rivelato ricavi annualizzati di 2,5 miliardi di dollari. Livello di evidenza: primario. Fonte: https://code.claude.com/docs/en/claude-directory
JetBrains AI Pulse Survey (2026.1). Sondaggio su 10.000+ sviluppatori professionisti a livello globale, localizzato in 8 lingue; CSAT di Claude Code al 91% / NPS 54 (il più alto del settore); adozione di Claude Code sul posto di lavoro al 18% (cresciuta di 6 volte dal 3% in 9 mesi), 24% in Nord America; Copilot al 29% di adozione sul posto di lavoro ma in stagnazione; Cursor al 18%. Livello di evidenza: primario. Fonte: https://www.jetbrains.com/lp/tools/ai-tools/
Pragmatic Engineer Newsletter (2026.2). Sondaggio su 15.000 sviluppatori; il 46% ha scelto Claude Code come “preferito in assoluto”, Cursor al 19%, Copilot al 9%. Livello di evidenza: primario. Fonte: https://newsletter.pragmaticengineer.com/
Alibaba Qoder (2025.8 → 2026.7). Pubblicato da Alibaba nell’agosto 2025; il 15 maggio 2026, Qoder 1.0 viene aggiornato ad Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; il 28 maggio 2026, Cloud Agents (runtime per agenti gestiti); il 21 luglio 2026, Qoder Security; a maggio 2026, oltre 5 milioni di utenti globali; integrazione CLI con DingTalk; il 20 maggio 2026, Tongyi Lima viene rinominato Qoder CN. Livello di evidenza: primario. Fonti: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525
vibecoding.app / thebcms.com / tfir.io (prima metà 2026). Comandi in cinque fasi per Spec Kit, confronto e valutazione degli strumenti SDD, notazione EARS. Livello di evidenza: secondario (valutazione di terze parti). Fonte: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development
EU AI Act / Code of Practice (piena applicazione dal 2.8.2026). Scadenza conformità per i sistemi di IA ad alto rischio fissata al 2.8.2026; i modelli GPAI esistenti hanno tempo fino al 2.8.2027; sanzioni fino a 35 milioni di euro o al 7% del fatturato globale annuo; Artt. 9-15 su gestione del rischio, governance dei dati, trasparenza documentale, supervisione umana, accuratezza e robustezza. Livello di evidenza: primario (regolamento + analisi di conformità secondaria). Fonte: https://artificialintelligenceact.eu/code-of-practice-overview; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide
Qodo State of AI Code Quality Report (2025). Il 44% dei problemi ha origine da una mancanza di contesto. Livello di evidenza: secondario (report del vendor). Fonte: https://www.qodo.ai/reports/state-of-ai-code-quality/

Slowly Learning AI: Una guida per i CIO e i decisori delle industrie di telecomunicazioni, finanziarie, manifatturiere e e-commerce

Introduzione

Come consulente di ricerca per l’IAUSE, questo blog è dedicato ai CIO e ai decisori delle industrie di telecomunicazioni, finanziarie, manifatturiere e e-commerce. In questo articolo, esploreremo le sfide e le opportunità dell’intelligenza artificiale (IA) e forniremo esempi di come le aziende possono implementare la tecnologia dell’IA per migliorare la loro efficienza e competitività.

La necessità di una strategia di IA

La tecnologia dell’IA sta cambiando rapidamente e le aziende devono essere in grado di adattarsi per rimanere competitive. Secondo un rapporto di Gartner, il 75% delle aziende ha già implementato la tecnologia dell’IA in qualche forma. Tuttavia, solo il 10% delle aziende ha una strategia di IA chiara e ben definita.

La strategia di IA

Una strategia di IA efficace deve essere basata su una comprensione profonda delle esigenze e delle sfide dell’azienda. Ciò richiede una collaborazione tra i dipartimenti di tecnologia, marketing e vendita per identificare le aree in cui l’IA può fornire più valore.

Esempi di implementazione dell’IA

Telecomunicazioni: AT&T ha implementato la tecnologia dell’IA per migliorare la sua capacità di gestione dei dati e di analisi dei dati. Ciò ha permesso all’azienda di migliorare la sua efficienza e di offrire servizi più personalizzati ai clienti.
Finanziarie: Deutsche Bank ha implementato la tecnologia dell’IA per migliorare la sua capacità di analisi dei dati e di gestione dei rischi. Ciò ha permesso all’azienda di migliorare la sua efficienza e di offrire servizi più sicuri ai clienti.
Manifatturiere: Siemens ha implementato la tecnologia dell’IA per migliorare la sua capacità di gestione dei dati e di analisi dei dati. Ciò ha permesso all’azienda di migliorare la sua efficienza e di offrire prodotti più innovativi ai clienti.
E-commerce: Amazon ha implementato la tecnologia dell’IA per migliorare la sua capacità di gestione dei dati e di analisi dei dati. Ciò ha permesso all’azienda di migliorare la sua efficienza e di offrire servizi più personalizzati ai clienti.

Conclusioni

La tecnologia dell’IA sta cambiando rapidamente e le aziende devono essere in grado di adattarsi per rimanere competitive. Una strategia di IA efficace deve essere basata su una comprensione profonda delle esigenze e delle sfide dell’azienda. Gli esempi di implementazione dell’IA sopra menzionati dimostrano come le aziende possono utilizzare la tecnologia dell’IA per migliorare la loro efficienza e competitività.

【Spec-Driven】Spec-Driven Development：Scrivere le specifiche è l'azione ingegneristica a più alto ROI nell'era dell'AI — L'evoluzione dell'ingegneria del software nell'era dell'AI — Impara l'AI lentamente 177