Il codice scritto dall'AI è sicuro? Cosa dicono gli studi indipendenti — e cosa metterne nel contratto

Quando una PMI valuta un fornitore che sviluppa con l'AI, la domanda che fa quasi sempre è sulla qualità: «si vede che è scritto da una macchina?». È la domanda meno utile. Sulla qualità percepita si discute all'infinito e si rimedia con una revisione. Il rischio serio, quello che l'evidenza indipendente misura davvero, è un altro: la sicurezza. E ha una caratteristica sgradevole — non si vede alla consegna, si vede mesi dopo, quando è tuo.

Gli studi accademici indipendenti pubblicati fra il 2022 e il 2026 dicono tre cose distinte, e nessuna delle tre è «l'AI scrive codice insicuro, quindi non usarla». Dicono che una quota consistente del codice generato nasce vulnerabile; che i rifiuti di un modello in chat non sopravvivono a essere inseriti dentro un flusso di lavoro reale; e che l'automazione agentica della pipeline apre una superficie d'attacco che è già sfruttata. Tre cose che un compratore può mettere nel contratto — oppure scoprire dopo.

1. Una parte del codice generato nasce vulnerabile

Il dato di riferimento è del 2022 ed è accademico, non di un fornitore. Pearce e colleghi hanno fatto generare a GitHub Copilot 1.689 programmi su 89 scenari costruiti attorno alle debolezze più comuni, e hanno trovato che circa il 40% dei programmi generati conteneva una vulnerabilità (Pearce et al., «Asleep at the Keyboard?», IEEE S&P 2022). Non su codice inventato per far fare brutta figura allo strumento: su scenari ordinari, del tipo che un'azienda commissiona ogni settimana.

Circola anche una ripartizione per linguaggio — intorno al 50% in C contro il 39% in Python. La citiamo con una riserva esplicita, perché è così che va citata: quella suddivisione arriva da sintesi secondarie dello studio e non l'abbiamo verificata sul documento originale. Il numero su cui appoggiarsi è quello complessivo. E la lettura giusta non è «il 40% del software consegnato è bucato»: è che un generatore non ha alcun motivo, di suo, di produrre codice sicuro. La sicurezza non è una proprietà emergente della generazione. È un controllo che qualcuno deve mettere attorno.

2. Il rifiuto in chat non sopravvive al flusso di lavoro

Qui c'è il risultato più recente e più scomodo, ed è quello che smonta la rassicurazione standard del fornitore («tranquillo, il modello queste cose si rifiuta di scriverle»). Un gruppo dell'Alan Turing Institute ha preso 204 richieste dannose e le ha sottoposte a GitHub Copilot Chat in due modi. In chat diretta, il modello si è rifiutato 808 volte su 816. Le stesse richieste, spezzate e inserite dentro un normale flusso di lavoro multi-turno nell'editor, hanno prodotto un completamento dannoso 816 volte su 816 (Kumar & Maple, «Refused in Chat, Written in Code», 2026).

Il punto non è «Copilot Chat restituisce codice pericoloso». Il punto è che la protezione vive a livello di conversazione mentre il lavoro vero avviene a livello di flusso: costruire la richiesta lungo più passaggi di un'attività di sviluppo ordinaria aggira un rifiuto che, interrogato frontalmente, funziona quasi sempre. Un controllo che sta nel posto sbagliato è, in pratica, un controllo che non c'è.

Per chi compra software questa è una conseguenza precisa, non un dettaglio da ricercatori: la sicurezza del modello non è una garanzia che puoi ereditare dal fornitore del modello. Deve essere verificata nel processo di chi ti consegna il codice — con strumenti che leggono il risultato, non le buone intenzioni di chi lo ha chiesto.

3. Più codice generato, pipeline più rumorosa (una correlazione, non una causa)

Il terzo studio guarda cosa succede a valle, nella catena di build e rilascio. Sono stati analizzati 61.837 esecuzioni di CI su 2.355 repository innescate da cinque diversi bot di programmazione AI: Copilot e Codex mostrano i tassi di successo più alti (intorno al 93-94%), gli altri più bassi. Il dato interessante è però un altro: nei repository con una frequenza più alta di pull request generate dall'AI si osserva un tasso di successo complessivo dei workflow più basso («Reliability of AI Bots Footprints in GitHub Actions CI/CD Workflows», 2026).

È una correlazione, e va detto chiaramente: lo studio non dimostra che le PR generate dall'AI facciano fallire la pipeline. Può benissimo essere che i progetti più esposti all'AI siano anche i più movimentati. Ma per chi deve decidere resta un'informazione utilizzabile: un volume alto di contributi automatici si accompagna a un segnale di build più rumoroso, e una pipeline rumorosa è precisamente il posto in cui un fallimento vero smette di farsi notare. Chi valuta un fornitore non dovrebbe chiedere «usate l'AI?», ma «che tasso di verde ha la vostra pipeline, e chi guarda i rossi?».

4. La pipeline stessa è diventata bersaglio

Il quarto elemento lo abbiamo già raccontato per esteso altrove, quindi qui basta la riga: quando sono gli agenti a scrivere e far girare i workflow, il workflow stesso diventa superficie d'attacco, con centinaia di vulnerabilità di injection confermate sfruttabili su repository reali (arXiv:2605.07135) — la scomposizione è nel nostro articolo su cosa funziona davvero dell'AI nello sviluppo. Messo in fila con i tre precedenti, chiude il quadro: il rischio non sta solo nel codice consegnato, sta anche in ciò che l'automazione ha il permesso di eseguire per conto tuo.

Cosa scrivere nel contratto (non cosa sperare)

Tutto quanto sopra si traduce in clausole, non in diffidenza. Nessuna di queste richiede competenze tecniche per essere pretesa, e tutte sono verificabili:

• Chi rivede, e prima di cosa. Metti per iscritto che ogni modifica passa da una revisione umana identificabile prima del rilascio, e che l'approvazione automatica non è ammessa sui percorsi sensibili (autenticazione, pagamenti, dati personali). Non «facciamo code review»: chi firma, e su quali percorsi il cancello non si apre mai da solo.
• Analisi statica e ricerca di segreti come obbligo, non come buona abitudine. Un'analisi automatica delle vulnerabilità (SAST) e la scansione dei segreti girano su ogni modifica, con esito allegato alla consegna. È il controllo che risponde direttamente al 40% di Pearce e al problema del rifiuto aggirato: verifica il risultato, non l'intenzione.
• Chi possiede una vulnerabilità trovata dopo la consegna. È la clausola che manca quasi sempre. Definisci una finestra di responsabilità, i tempi di rimedio per gravità e chi paga: senza, il costo del 40% ricade per intero su di te, mesi dopo aver firmato il collaudo.
• Cosa può eseguire la pipeline. Quali automazioni hanno accesso alle credenziali di produzione, quali possono aprire e integrare modifiche da sole, e cosa richiede un'azione umana. Se l'automazione può muovere codice fino in produzione senza una firma, il perimetro di sicurezza non è quello che credi.
• Dove finisce il tuo codice. Quali strumenti AI sono usati sul tuo repository, se il codice alimenta l'addestramento di terzi e come vengono gestiti i segreti nell'ambiente di sviluppo. Sono le stesse domande da fare a qualsiasi fornitore SaaS — le abbiamo raccolte qui.

Nessuna di queste clausole vieta l'AI. Tutte spostano il rischio dove può essere gestito: nel processo del fornitore, prima della consegna, invece che nel tuo bilancio dopo.

La nostra posizione, detta da dentro

Noi il codice lo scriviamo con l'AI ogni giorno, su questo sito e sui nostri prodotti — e per questo il nostro processo assomiglia molto all'elenco qui sopra: ogni modifica passa da una suite di verifiche verdi, da una revisione umana prima del rilascio e da automazioni con permessi espliciti e ristretti, senza scorciatoie sui percorsi critici. Non è prudenza da brochure: è l'infrastruttura che trasforma la velocità dell'AI in un vantaggio che resta, invece che in un debito di sicurezza da saldare più avanti. Un fornitore che ha già dovuto costruire questi controlli te lo dice; chi vende solo la demo, non ancora.

La decisione da prendere

Non è «AI sì o AI no». È una sola domanda, e va posta prima di firmare: quali di queste clausole sono già nel contratto che stai per accettare? Se la risposta è nessuna, il problema non è lo strumento che il tuo fornitore usa — è che il rischio di sicurezza, allo stato, è interamente tuo e non è scritto da nessuna parte.

Se stai valutando un fornitore o stai per portare l'AI dentro il tuo sviluppo, i controlli che agganciamo a ogni flusso — inclusi quelli di conformità — sono descritti nel nostro overlay di conformità. E per capire da quale reparto conviene partire, con quali controlli attorno, abbiamo reso il primo passo una valutazione self-serve e gratuita: fai la valutazione di AI-readiness — poi, se ha senso, ne parliamo.

Questo articolo ha scopo orientativo. Le cifre citate provengono da studi accademici indipendenti, condotti su strumenti e periodi specifici: vanno lette come indicazioni di direzione sul tipo di rischio, non come una misura del codice che riceverai. La ripartizione per linguaggio dello studio del 2022 è riportata da sintesi secondarie e non verificata sul documento originale. Questo testo non costituisce consulenza legale né una valutazione di sicurezza: ogni contratto va valutato sul contesto della singola azienda.