Strumenti, policy e governance per usare l'intelligenza artificiale in modo sicuro e produttivo

L'adozione dell'AI nel team di sviluppo non comincia quasi mai da una decisione: comincia da una scoperta.

Retrospettiva di fine sprint: un senior racconta di avere caricato ottocento righe di un servizio su un modello in cloud per farsele riscrivere.

Quel servizio gestiva dati di pagamento.

Nel 2026 la domanda non è più se il tuo team usa l'intelligenza artificiale, ma se qualcuno in azienda ha deciso come.

Il CTO seduto in quella stanza non ha un problema di tecnologia.

Ha un problema di date: l'AI è entrata in azienda mesi prima che lui la autorizzasse, ed è entrata dalla porta di servizio, quella che nessuno sorveglia perché non compare in nessun budget.

Nessuno ha fatto niente di male.

Semplicemente, nessuno ha fatto niente.

Adottare l'AI nel team tecnico senza una policy non è progressismo digitale, è gestire un rischio aziendale senza accorgersene.

Qui dentro trovi cosa sta succedendo davvero nei team italiani, i tre rischi che nella presentazione della conferenza non c'erano e come si sceglie uno strumento leggendo il contratto invece della demo.

Poi come si scrive una policy che gli sviluppatori aprono davvero, il processo in quattro passi per introdurla e il conto del ritorno su un team da cinque persone.

Quanto è diffusa davvero l'adozione dell'AI nei team di sviluppo italiani nel 2026?

Fallo in sala riunioni, per alzata di mano: “chi usa l'intelligenza artificiale per lavorare?”

Si alzano due mani, e sono quelle di chi non ha capito la domanda.

Rifallo davanti a un caffè: si alzano tutte.

Nel 2026 l'adozione dell'AI nei team di sviluppo italiani non è una scelta aziendale in attesa di essere presa: è un fatto già avvenuto, che nella maggior parte dei casi l'azienda non ha né autorizzato né misurato.

L'indagine di GitHub sull'uso dell'AI nello sviluppo software, pubblicata nell'agosto 2024 su duemila sviluppatori di aziende con più di mille dipendenti tra Stati Uniti, Brasile, Germania e India, dice due cose che vanno lette insieme.

Oltre il 97% ha usato strumenti di AI al lavoro, mentre le aziende che ne incoraggiano attivamente l'adozione restano meno di quattro su dieci perfino negli Stati Uniti, che è il paese messo meglio.

Sul tempo risparmiato il riferimento più solido resta lo studio McKinsey "Unleashing developer productivity with generative AI", del 2023: dal 45 al 50% sulla documentazione, dal 35 al 45% sulla generazione di codice, dal 20 al 30% sul refactoring, e meno del 10% sui compiti che gli sviluppatori stessi giudicano complessi.

Questi ultimi numeri nelle presentazioni non compaiono mai.

L'Italia in quelle rilevazioni non c'è, e dati altrettanto solidi sul nostro mercato non esistono: quello che vedo nei team con cui lavoro è che qui la distanza tra uso reale e uso autorizzato è anche più larga.

Il problema italiano quindi non è l'adozione.

È che avviene di nascosto.

Si chiama shadow AI, e vale la pena chiamarlo con il suo nome: è l'uso di strumenti di intelligenza artificiale dentro processi aziendali senza che l'azienda sappia quali sono, chi li usa e con quali dati.

Chi ha vissuto il 2012 lo riconosce: è la stessa storia delle cartelle personali su Dropbox con dentro i preventivi dei clienti, solo che questa volta a uscire non sono i file, è il ragionamento su come funziona il tuo software.

Da lì in poi le aziende prendono strade diverse.

La prima è il divieto, e regge benissimo sulla carta.

Un responsabile IT di una società finanziaria mi ha spiegato con orgoglio di avere bloccato i domini dei principali servizi sul firewall aziendale; tre settimane dopo ho visto un suo sviluppatore incollare codice dallo smartphone, in piedi accanto alla macchinetta del caffè, perché la scadenza era venerdì.

Il divieto non ha eliminato l'uso: ha eliminato la possibilità di vederlo.

La seconda strada è la più comune ed è anche la peggiore: nessun divieto e nessuna regola, ognuno usa quello che preferisce con i dati che gli servono.

Non è libertà, è assenza di decisione, e ha il difetto di non lasciare traccia.

Il giorno in cui serve sapere quale codice è passato per quale modello, la risposta non esiste da nessuna parte.

La terza strada la percorrono in pochi, e sono quelli che stanno già guadagnando terreno: strumenti scelti, regole scritte, uso misurato.

Vietare l'AI nel team di sviluppo non è una strategia conservativa, è una strategia di declino accelerato.

La domanda vera non è mai stata se usarla, ma chi risponde di cosa quando la si usa.

E qui c'è il punto che rende la conversazione difficile: il rischio di cui hai paura non è quello che ti farà male davvero.

Quello vero è molto più noioso, non fa notizia, e presenta il conto tra diciotto mesi.

Quali sono i rischi veri dell'AI nel codice aziendale?

La diapositiva che ti hanno mostrato alla conferenza aveva tre punti elenco e la parola "allucinazioni" in grassetto.

Nella pratica, in azienda, non ho mai visto un progetto andare in crisi per un'allucinazione: quelle possono essere viste, strappano un sorriso, e poi qualcuno le corregge.

I rischi concreti dell'AI nel codice aziendale sono altri tre: la proprietà intellettuale che esce senza che nessuno se ne accorga, il codice vulnerabile che entra in produzione, e il debito tecnico che si accumula alla stessa velocità con cui l'AI scrive.

La proprietà intellettuale esce dall'azienda senza rumore

Nessuno si porterebbe a casa una copia dei sorgenti su una chiavetta.

Incollare quattrocento righe in una finestra del browser sembra un gesto diverso, e non lo è.

La differenza sta solo nel fatto che il primo gesto lo vedi e il secondo no.

I modelli in cloud usati con account personali o con i piani gratuiti possono usare le conversazioni per addestrare le versioni successive.

Se uno sviluppatore ci carica dentro l'algoritmo di pricing, la logica di calcolo dei premi assicurativi o il motore di scheduling che avete costruito in sei anni, quello che state cedendo non è del codice: è il vantaggio competitivo che quel codice rappresenta.

Non è una violazione di legge, non fa scattare nessun allarme, e nessuno se ne accorge.

La risposta non è vietare.

È decidere due cose e scriverle: quali categorie di dati possono uscire e verso quali strumenti, e su quali piani contrattuali.

I piani enterprise di GitHub Copilot, ChatGPT e Claude garantiscono contrattualmente zero addestramento sui dati dei clienti, ed è esattamente per questo che esistono e costano di più.

Il codice generato è probabile, non sicuro

Un modello linguistico non sa cosa sia una vulnerabilità.

Sa cosa è statisticamente probabile che venga dopo la riga che hai appena scritto, ed è una cosa completamente diversa.

Sono documentati suggerimenti con SQL injection nelle query costruite per concatenazione, credenziali scritte in chiaro dentro i test, gestione insicura dei token JWT e controlli di autorizzazione mancanti, quelli che in gergo si chiamano IDOR.

Un endpoint che ti restituisce l'ordine numero 4711 solo perché glielo hai chiesto, senza verificare che sia il tuo.

In un progetto ASP.NET Core il caso classico è la query costruita a mano con FromSqlRaw, che il modello propone perché su internet ce ne sono migliaia di esempi, non perché sia la scelta giusta nel tuo contesto.

La difesa è meccanica e va messa nella pipeline, non nella buona volontà: analisi statica del codice obbligatoria in fase di build su tutto quello che entra, non solo su quello che sospetti sia stato generato.

SonarQube, Snyk e Semgrep intercettano prima del merge la maggior parte di questa roba.

Ed è un investimento che serve comunque, AI o no.

Il debito tecnico arriva alla velocità dell'AI

Questo è quello che nessuno mette nella presentazione, perché non fa paura e non fa notizia.

Immagina un muratore velocissimo che non ha mai visto il resto della casa: quello che costruisce sta in piedi, ma non è detto che si incastri con il resto.

Una funzionalità completa arriva in pochi minuti.

Se nessuno verifica che sia coerente con l'architettura che avete, quello che si accumula sono pattern diversi per fare la stessa cosa, nomi che non seguono nessuna convenzione, logica duplicata in tre punti e dipendenze circolari tra progetti che prima erano separati.

Il codice funziona, passa i test, va in produzione.

Diventa ingestibile dopo sei mesi, quando qualcuno deve modificarlo e scopre che non esiste più un modo solo di fare le cose.

La contromisura costa tempo e non è popolare: sulle funzionalità generate con l'AI serve una revisione architetturale, non solo una lettura del diff.

Qualcuno che guardi dove quel codice si appoggia, e non solo se compila.

Il paradosso è che nessuno di questi tre rischi si risolve scegliendo lo strumento giusto.

La scelta dello strumento decide però quanto ti costeranno, e si fa su un criterio che nella demo non compare mai.

Due team con lo stesso Copilot e lo stesso budget.

Il primo scopre a valle cosa è finito in produzione, il secondo ha qualcuno che quel codice lo guarda prima.

La differenza non è il modello, è chi siede al tavolo: il Corso Architetto Software Ai serve a diventare quel qualcuno.

Sicurezza, prevenzione della fuga di dati, validazione dell'output: le tre cose che l'articolo ti ha fatto vedere come rischi, lì dentro diventano scelte di progetto.

Il codice vulnerabile costa poco da intercettare prima del merge, molto dopo il rilascio.

Come costruire la lista degli strumenti AI approvati per un team .NET nel 2026

Una software house di Verona mi ha mostrato la sua lista degli strumenti approvati: quattro nomi, scelti perché li usava già qualcuno.

Nessuna data, nessun responsabile, nessuna riga sul piano contrattuale sottoscritto.

Era un elenco, non una decisione.

La lista degli strumenti approvati di un team .NET si costruisce su tre criteri, in quest'ordine:

• Cosa garantisce il contratto sui tuoi dati.
• Dove vive lo strumento rispetto a Visual Studio.
• Per che tipo di lavoro serve.

Il prezzo è il quarto criterio, e a queste cifre conta molto meno di quanto sembri.

Il punto di partenza per chi lavora in .NET resta GitHub Copilot nei piani Business ed Enterprise, tra i 19 e i 39 euro per sviluppatore al mese.

Vive dentro Visual Studio 2022, VS Code e gli ambienti JetBrains senza che nessuno debba cambiare abitudini, il che sembra un dettaglio e invece decide il tasso di adozione reale.

Il piano Enterprise è quello che ti mette per iscritto zero addestramento sui tuoi dati e la protezione sulla proprietà intellettuale.

Lavora benissimo sul completamento, sulla generazione dei test e sulla documentazione nel codice.

Il suo limite si sente il giorno in cui gli chiedi di ragionare su un modulo intero: il contesto di progetto profondo non ce l'ha.

Quel limite è esattamente il motivo per cui in molti team compare un secondo strumento.

Cursor, intorno ai venti dollari al mese, è un ambiente di sviluppo costruito attorno all'AI sulla base di VS Code, con una comprensione del progetto molto più ampia.

Diventa utile dove Copilot si ferma: rifattorizzare un modulo complesso, migrare codice, ricostruire il senso di un sistema legacy che nessuno ha più in testa.

Il prezzo lo paghi altrove: non è Visual Studio; quindi, chi lavora in Visual Studio deve cambiare ambiente, e questa è una decisione di team, non di singolo.

C'è poi un tipo di lavoro che nessuno dei due copre, ed è quello che conta di più quando le decisioni sono costose.

Claude, usato via API o dal piano Pro, è lo strumento a cui si affidano le revisioni architetturali, l'analisi di un problema di design, la documentazione tecnica di un sistema complesso, le revisioni di codice fatte per capire e non per correggere una virgola.

Non è un assistente che completa mentre scrivi: è uno strumento con cui ragionare prima di scrivere.

ChatGPT Enterprise chiude il quadro sulla generazione di codice generica e sulle spiegazioni, con le stesse garanzie contrattuali sulla privacy.

Messi in fila, i quattro fanno mestieri diversi e si scelgono per quello:

Il resto della lista è amministrazione, ed è la parte che salta sempre: accanto a ogni strumento va scritto il piano contrattuale ammesso, perché il piano gratuito dello stesso prodotto va nella lista dei vietati, e vanno scritti una data di revisione e il nome di chi la firma.

Una lista di nomi, però, non ha mai fermato nessuno.

Serve il documento che dice cosa ci fai, e quello è il punto in cui quasi tutte le aziende sbagliano formato.

Come scrivere una AI policy aziendale che funzioni davvero

Ne ho lette parecchie.

La più lunga arrivava a quattordici pagine e citava tre regolamenti europei nell'introduzione.

Nel team di sviluppo non l'aveva aperta nessuno, e la cosa non stupiva nessuno.

Una AI policy che funziona sta in due pagine, si legge in dieci minuti e risponde a cinque domande che gli sviluppatori si fanno per davvero: cosa posso usare, cosa posso caricare, chi risponde del codice, cosa devo aver imparato prima di partire e come verrà controllato tutto questo.

La prima domanda è la più semplice e quasi nessuno la chiude bene.

Serve l'elenco esplicito degli strumenti approvati con il piano contrattuale ammesso, l'elenco di quelli vietati, che comprende i piani gratuiti degli stessi prodotti e i modelli aperti installati senza controllo su dove finiscono i dati, e un terzo elenco, quello degli strumenti in valutazione, che serve a dare una risposta a chi arriva con una proposta nuova invece di lasciarlo fare da solo.

Si rivede ogni sei mesi, perché a questa velocità un anno è geologia.

La seconda risponde alla domanda che gli sviluppatori si fanno davanti alla finestra vuota: questo posso incollarlo o no?

Una classificazione utile sta in due righe.

Da una parte ciò che può uscire: codice non proprietario, documentazione pubblica, esempi ricostruiti.

Dall'altra ciò che non esce mai: gli algoritmi che sono il vostro vantaggio, i dati dei clienti, le credenziali, le logiche di prezzo.

Tradotta su un progetto ASP.NET Core la riga di confine diventa concreta.

Le stringhe di connessione e le chiavi che stanno in appsettings.json non escono mai, nemmeno anonimizzate: la struttura di quel file racconta com'è fatto il vostro ambiente anche senza i valori veri.

E il repository interno non si dà in pasto a nessuno strumento che non abbia un piano enterprise, per quanto comodo sia lasciarglielo indicizzare.

Un controller con i nomi cambiati, invece, può uscire senza che nessuno perda il sonno.

Se la classificazione richiede un avvocato per essere applicata, non verrà applicata.

La terza è quella che decide tutto il resto, ed è una frase sola: la responsabilità del codice è sempre di chi fa il commit, mai del modello.

Tradotto in processo: tutto il codice generato con l'AI passa da una revisione umana prima del merge, e le pull request in cui il codice generato supera il 30% richiedono la revisione di un senior.

Non è sfiducia, è la stessa regola che vale per una libreria di terze parti che decidi di includere.

La quarta è una scadenza, non un principio: workshop pratico obbligatorio di quattro ore per tutti entro trenta giorni dall'adozione, con dentro l'uso sicuro degli strumenti approvati, i pattern da evitare e gli esempi di codice generato con vulnerabilità vere.

La quinta è il controllo: una revisione mensile del team lead su quante pull request contengono codice generato e su quante di queste vengono respinte, con la policy che si aggiusta sui dati e non sulle impressioni.

Ci sono però due domande che una policy interna non chiude da sola, perché non le pone l'azienda: chi risponde dei dati che finiscono in un prompt, e chi deve poterlo dimostrare.

Il processo di adozione dell'AI nel team di sviluppo: i 4 step per non sbagliare

Il modo più veloce per far fallire tutto è cominciare dal documento.

Si scrive la policy, si manda per email, si scopre tre mesi dopo che il team usa esattamente gli stessi strumenti di prima, solo con meno voglia di dirlo.

L'adozione dell'AI nel team di sviluppo si fa in sei mesi e in quattro passi, in un ordine che non è negoziabile:

1. Settimane 1 e 2: censisci quello che il team già usa.
2. Settimane 3 e 4: scrivi la policy e spiegala di persona.
3. Mese 2: formazione pratica sul codice vostro.
4. Mesi da 3 a 6: misura, e correggi la policy sui dati.

Il censimento si fa con un questionario anonimo, e l'anonimato non è una gentilezza: è la condizione perché qualcuno risponda.

Quali strumenti stai usando, per fare cosa, con quali dati.

I risultati servono a due cose insieme: ti dicono dove il rischio è già in casa, e ti dicono dove l'adozione spontanea ha già trovato valore reale.

Quella seconda informazione vale più della prima, perché è gratis e nessun consulente te la può dare.

La comunicazione della policy non è un comunicato delle risorse umane, è una riunione tecnica con le domande dentro.

Ogni regola va spiegata con il rischio che copre: uno sviluppatore che ha capito cosa succede se incolla l'algoritmo di pricing non ha bisogno di essere controllato, non lo incolla e basta.

Chi non capisce la regola la aggira, e ha pure ragione lui.

Il mese due è quello che salta per primo quando il calendario si stringe, ed è anche l'unico che cambia davvero i comportamenti.

Non diapositive e non video: codice vostro, sul proiettore, con dentro esempi veri di suggerimenti sbagliati da riconoscere e correggere.

Nei laboratori che tengo su questo tema la scena che sposta le persone è sempre la stessa: un metodo generato che sembra perfetto, che passa i test, e che apre un buco di autorizzazione che nessuno nella sala aveva visto in cinque minuti di lettura.

Dal terzo mese si misura, e conviene aver fissato i valori di partenza prima di cominciare: story point per sprint, densità di difetti per funzionalità rilasciata, tempo medio di revisione.

Quelli sono i valori di partenza.

I numeri che dicono se l'adozione sta funzionando davvero, invece, sono altri quattro.

Hai il processo in quattro passi.

Il primo e il quarto li puoi fare da solo, con un questionario e un pannello di amministrazione.

Il secondo mese no, e provarci in autonomia è il motivo per cui la maggior parte delle adozioni si ferma alla policy: per quello esiste il Corso Architetto Software Ai.

Quattro ore con me valgono sei mesi di regole lette e mai applicate.

Il laboratorio architetturale lavora con un massimo di cinque partecipanti, perché oltre quel numero nessuno mette le mani sul codice.

AI e GDPR nello sviluppo software: chi risponde dei dati che finiscono nel prompt

Il bug si riproduce solo con i dati veri, il cliente aspetta da due giorni, e alle sei di sera un estratto della tabella clienti finisce dentro una finestra di chat con la domanda: perché questa query mi restituisce duplicati?

Nessuno ha rubato niente.

È solo che quei dati, da quel momento, sono usciti.

Quando dati personali finiscono in un prompt il titolare del trattamento resta l'azienda: il fornitore dello strumento è al massimo responsabile, e soltanto se esiste un contratto che lo nomina.

Servono quindi tre cose prima dell'uso, non dopo:

• Una base giuridica.
• Un accordo scritto con il fornitore.
• La certezza su dove i dati vengono elaborati e per quanto tempo restano.

Conviene togliere subito un equivoco.

Il GDPR non si occupa del codice, si occupa dei dati personali.

Il tuo sorgente, per quanto valga, è un problema di proprietà intellettuale e l'abbiamo già visto.

Il problema di protezione dei dati nasce da quello che gli sta intorno:

• I dati di collaudo copiati dalla produzione.
• I log incollati per capire un errore.
• La schermata con dentro nomi e indirizzi.
• Il file di esempio allegato al prompt.

È lì che il trattamento comincia, e quasi sempre nessuno se ne accorge perché quella finestra sembra un blocco note.

Chi risponde è la domanda successiva, e ha una risposta sola: l'azienda.

Il fornitore del modello diventa responsabile del trattamento solo se lo nomini con un contratto, ed è esattamente quello che i piani enterprise di GitHub Copilot, ChatGPT e Claude mettono a disposizione e i piani personali no.

Uno sviluppatore che usa il proprio account gratuito su dati aziendali non sta facendo un favore all'azienda: sta facendo un trattamento che l'azienda non ha autorizzato, non ha documentato e non può ricostruire.

È la differenza tra lo shadow AI come fastidio organizzativo e lo shadow AI come rilievo il giorno di una verifica.

La parte operativa è più corta di quanto sembri.

Gli strumenti approvati entrano nel registro dei trattamenti come qualsiasi altro fornitore, con tre informazioni accanto: in quale regione i dati vengono elaborati, per quanto tempo i prompt restano conservati, se vengono usati per addestrare.

I contratti enterprise rispondono a tutte e tre per iscritto, ed è metà del motivo per cui costano di più.

Se l'elaborazione avviene fuori dall'Unione europea serve una base per il trasferimento, tipicamente le clausole contrattuali standard: non è un ostacolo, è una casella che si spunta prima di firmare invece che dopo un incidente.

C'è poi l'obbligo che quasi nessuno collega a questo tema.

L'articolo 4 dell'AI Act chiede sia a chi fornisce sia a chi utilizza sistemi di intelligenza artificiale di garantire un livello adeguato di alfabetizzazione al proprio personale, e vale a prescindere dal livello di rischio dello strumento.

Si applica dal 2 febbraio 2025, le sanzioni sono operative dall'agosto successivo e dal 2 agosto 2026 il quadro di vigilanza è pienamente in vigore.

La norma non fissa un monte ore né una certificazione: chiede formazione proporzionata al ruolo e documentata.

Tradotto per il tuo team, il laboratorio di quattro ore della sezione precedente non è una buona pratica da azienda evoluta, è la prova che quell'obbligo è stato assolto, e l'elenco con nomi, data e programma vale quanto il contenuto della giornata.

Vale la pena dire anche cosa l'AI Act non chiede, perché intorno a questo tema circola molta ansia inutile.

Un assistente di codice non è un sistema ad alto rischio e nessuno deve certificare Copilot.

Il discorso cambia il giorno in cui l'intelligenza artificiale entra in un processo che decide su persone, dalla selezione del personale alla valutazione del merito creditizio, ma quello è un altro sistema e un'altra conversazione.

La regola che chiude il cerchio è una sola e va scritta nella policy accanto alla classificazione dei dati: nei prompt non entrano mai dati di produzione.

Se serve riprodurre un caso reale si generano dati sintetici, e in .NET costa poco.

Bogus produce anagrafiche, indirizzi e ordini verosimili in una decina di righe, i dati di inizializzazione di Entity Framework Core li rendono ripetibili, e il caso di prova che ne esce si può incollare ovunque senza chiedere il permesso a nessuno.

Dieci minuti la prima volta, zero le successive, e il problema smette di esistere invece di essere gestito.

Un documento scritto bene, però, non si applica da solo.

Il modo in cui lo introduci decide se diventa una regola condivisa o un fastidio da aggirare, e i primi quindici giorni pesano più di tutti i sei mesi successivi.

Come si misura l'adozione dell'AI dopo i primi sei mesi: i quattro numeri che contano

Dodici licenze da rinnovare, il responsabile che chiede se servono tutte, e un silenzio in riunione che dice già la risposta.

In sei mesi nessuno ha aperto il pannello di amministrazione.

L'adozione dell'AI si misura con quattro numeri, e nessuno dei quattro è la quantità di codice generato:

• Quante licenze vengono usate davvero ogni settimana.
• Quanto uso non dichiarato resta al secondo censimento.
• Quanta parte del team ha completato la formazione.
• Quante richieste di eccezione arrivano alla policy.

Il primo è il più semplice e il più ignorato: gli utenti attivi ogni settimana sul totale delle licenze pagate.

I pannelli di amministrazione dei piani business lo mostrano senza che tu debba costruire niente.

Sotto i due terzi il problema non è la pigrizia di qualcuno: o lo strumento non serve al lavoro che quelle persone fanno davvero, o non hanno avuto il tempo di impararlo.

Nel primo caso togli licenze e risparmi, nel secondo fai formazione e recuperi.

Sono due decisioni opposte, e senza quel numero la scegli a caso.

Il secondo si ottiene rifacendo a sei mesi lo stesso questionario anonimo del censimento iniziale, con le stesse domande.

È la misura più scomoda e la più onesta, perché dice quanta parte del team continua a usare strumenti fuori dalla lista.

Se scende, la policy è creduta.

Se resta uguale, il documento è stato letto e archiviato.

Se sale, hai vietato qualcosa che serviva e nessuno ha avuto voglia di dirtelo in faccia.

Il terzo è la percentuale di persone che ha completato la formazione prevista, con la data accanto.

Serve per due motivi che viaggiano insieme: è l'unica leva che sposta davvero i comportamenti, ed è la prova documentale che l'obbligo di alfabetizzazione della sezione precedente è stato assolto.

Un elenco con nomi, data e programma vale più di qualunque dichiarazione di intenti in riunione.

Il quarto è controintuitivo: quante richieste di eccezione o di valutazione di strumenti nuovi sono arrivate in sei mesi.

Zero non è un buon segno.

Significa che la lista degli strumenti in valutazione esiste solo sulla carta e che chi trova qualcosa di nuovo lo usa senza chiedere, perché ha già capito che chiedere non porta a niente.

Un paio di richieste a trimestre, con una risposta entro una settimana, sono il segnale che il processo è vivo.

Va detto anche cosa non misurare, perché sono esattamente le metriche che le piattaforme regalano già pronte.

Le righe di codice generate premiano chi accetta i suggerimenti senza leggerli.

La percentuale di suggerimenti accettati misura la docilità, non la qualità.

Un punteggio di utilizzo dell'AI per persona trasforma uno strumento in una gara, e ottieni quello che misuri: uso ostentato e nessun beneficio.

La qualità del codice generato si misura eccome, ma con altre metriche e altri strumenti, e ne parlo per esteso nell'articolo sulla governance del vibe coding in azienda.

Al sesto mese quei quattro numeri servono a una cosa sola: riscrivere la policy.

Gli strumenti che nessuno usa escono dalla lista, quelli che compaiono nel censimento sommerso o entrano con un piano contrattuale adeguato o vengono vietati con una motivazione scritta, e la classificazione dei dati si corregge nei punti in cui ha creato attrito senza ridurre il rischio.

Una policy che dopo sei mesi è identica a com'era non è stabile, è ignorata.

Al sesto mese qualcuno ti chiederà quanto è costato e quanto ha reso.

Conviene arrivarci con il conto già fatto.

Quei quattro numeri ti dicono se l'adozione funziona.

Non ti dicono cosa cambiare nell'architettura quando non funziona, e quella è la decisione che al sesto mese qualcuno deve saper prendere.

Nel Corso Architetto Software Ai si lavora esattamente lì: osservabilità, monitoraggio e tracciabilità delle decisioni su sistemi che usano l'AI in azienda.

Arrivi alla riunione del sesto mese con i numeri e con il piano per correggerli, non solo con i numeri.

Decidere adesso costa una riunione.

Decidere dopo costa un incidente, e il conto lo scrive qualcun altro.

Quanto rende davvero l'AI nel team tecnico: il calcolo del ROI con numeri reali

La domanda arriva sempre nello stesso modo, e non la fa il CTO: la fa chi firma.

Cinque licenze, dodici mesi, quanto rientra.

Su un team di cinque sviluppatori .NET con GitHub Copilot Enterprise il conto si chiude intorno a dieci volte l'investimento nel primo anno: circa 2.340 euro di licenze contro circa 24.000 euro di tempo recuperato.

Sono i due numeri da portare in riunione, e reggono a una verifica.

Il costo è l'unica parte certa: 39 euro al mese per cinque sviluppatori per dodici mesi fanno 2.340 euro l'anno, cioè l'ordine di grandezza di un singolo giorno di fermo su un progetto medio.

Il risparmio si stima in modo conservativo a partire dai dati di GitHub: due ore alla settimana per sviluppatore su lavoro meccanico, cioè test, codice ripetitivo e documentazione.

Due ore per cinque persone per quarantotto settimane lavorative fanno 480 ore l'anno, che a un costo pieno di 50 euro l'ora valgono 24.000 euro.

Ventiquattromila diviso duemilatrecentoquaranta fa dieci.

Nei team che hanno fatto formazione seria e hanno regole chiare su dove conviene usare l'AI, il risparmio dichiarato sale a quattro o cinque ore alla settimana per persona, e il rapporto arriva tra venti e venticinque volte.

Nella direzione opposta, con adozione senza formazione e senza policy, il risparmio reale si dimezza, il rischio di sicurezza cresce e il debito tecnico accelera: il conto resta positivo sulla carta e negativo nel bilancio dell'anno dopo.

Una precisazione onesta, perché quel dieci gira nelle presentazioni con troppa sicurezza.

Dentro c'è un'ipotesi forte: che il tempo risparmiato venga speso su lavoro di valore.

Se le due ore recuperate ogni settimana si sciolgono in riunioni aggiuntive, il ritorno resta sul foglio di calcolo e non arriva mai nel prodotto.

Il numero non misura l'AI, misura come lavora il team che la usa.

Ed è esattamente per questo che il calcolo, da solo, non basta a decidere.

l'AI è un amplificatore, non un sostituto

Le aziende che vinceranno tra il 2026 e il 2030 non sono quelle con il modello più potente.

Sono quelle con il processo migliore per usarlo.

Un team di cinque sviluppatori con regole chiare batte in modo sistematico un team di otto senza regole, e non perché l'AI faccia magie: perché amplifica quello che già c'è.

L'AI nel team tecnico è come un moltiplicatore di forza: amplifica ciò che già c'è. Se il team è bravo, diventa eccellente. Se il team ha problemi strutturali, li rende più visibili, e più costosi.

È il motivo per cui questa non è una decisione da ufficio acquisti.

Comprare le licenze è la parte facile e la sanno fare tutti; costruire le persone che sanno guidare uno strumento del genere, riconoscere un suggerimento sbagliato e dire di no a una funzionalità che funziona ma sfonda l'architettura, quella è un'altra questione.

Non la risolve un video, non la risolve un abbonamento: la risolve qualcuno che guarda il codice del tuo team e ti dice dove si romperà.

C'è chi passerà i prossimi tre anni a subire l'AI, scoprendo a valle cosa è stato caricato, cosa è finito in produzione e quanto costerà rimetterlo a posto.

E c'è chi decide adesso, quando decidere costa una riunione e non un incidente.

Il momento giusto per costruire la governance dell'AI nel tuo team non è quando il primo problema di sicurezza o la prima fuga di proprietà intellettuale ti obbligano a farlo di corsa: è il trimestre in cui non è ancora successo niente.

Torna per un attimo in quella retrospettiva, con le ottocento righe del servizio di pagamento già caricate da qualche parte.

Non è successo perché' il tuo team sia distratto: è successo perché' nessuno gli aveva detto dove si passa il confine.

Le licenze le compra chiunque, la policy la scrivi in due pagine, ma la persona capace di guardare una funzionalità generata e dire dove si romperà non arriva con un abbonamento.

Quella persona si costruisce, ed è quello che facciamo insieme nel Corso Architetto Software Ai, sul tuo sistema e non su un progetto di esempio.

Il trimestre in cui non è ancora successo niente è questo.

Tra un anno saprai già quale delle due strade hai preso, perché' l'avrai letta nel bilancio.