Un controller incollato «solo per trovare il bug», una chiave di accesso dimenticata alla riga 12: la revisione del codice con l'IA spesso fa trapelare dati con gesti banali. Sei errori frequenti, e come lavorare senza commetterli.
Martedì, ore 16.30. Un test di integrazione fallisce dal mattino e il rilascio in produzione è previsto per giovedì. Lo sviluppatore seleziona l'intero controller, quattrocento righe, lo incolla in un'IA di largo consumo e scrive: «trova il bug». La risposta arriva, ed è giusta. Nessuno si accorge che la riga 12 conteneva una chiave di accesso all'ambiente di collaudo, che i commenti citavano il cliente per nome e che la regola di calcolo degli sconti, quella che il team ha impiegato due anni ad affinare, si trova ora presso un fornitore che nessuno ha scelto.
È l'errore che vediamo più spesso: non un'imprudenza clamorosa, ma un copia e incolla fatto sotto pressione. Eppure l'IA è un ottimo revisore di codice. Bisogna però sapere che cosa le si consegna, e dove.
Il codice scritto per un datore di lavoro o per un cliente in genere non vi appartiene. Rientra nel segreto commerciale, che la legge tutela in Svizzera come in Italia; spesso è coperto da una clausola di riservatezza nel contratto di lavoro o di prestazione; e il regolamento informatico dell'azienda vieta di frequente di trasmettere codice a un servizio non approvato. Per chi lavora come fornitore esterno, il codice a volte appartiene al cliente, che non ha mai autorizzato a farlo uscire.
A questo si aggiungono i dati personali che si infilano nel codice: set di dati di test copiati dalla produzione, log di errore, indirizzi nelle fixture. Questi ricadono sotto il GDPR o la legge svizzera sulla protezione dei dati (LPD), qualunque sia la natura del progetto.
Un file isolato sembra innocuo. Ma spesso è proprio il file che conta: l'algoritmo di determinazione dei prezzi, la logica di un motore di raccomandazione, l'aggiramento di un limite di una libreria. Una volta incollato in un'IA di largo consumo, si trova presso un terzo che può conservarne la cronologia, e il cui fornitore può essere soggetto a leggi straniere che lo obbligano a consegnare ciò che detiene.
Il rimedio: fare la revisione con un modello confidenziale. In IA Confidential, i modelli locali e specializzati sono modelli aperti installati su server in Svizzera, nel quadro della legge svizzera sulla protezione dei dati e fuori dalla portata del CLOUD Act; non trasmettono nulla a terzi. La scelta del modello è automatica o manuale, e per una revisione un modello confidenziale è il punto di partenza giusto.
Chiavi di accesso scritte nel codice, stringa di connessione al database, token di un servizio terzo, file di configurazione dell'ambiente allegato «per contesto», stack trace che contiene l'indirizzo e-mail di un utente. Li si incolla senza vederli, perché si cerca un bug, non una fuga di dati.
Il rimedio: togliere i segreti prima di qualsiasi invio, anche verso uno strumento confidenziale. Una revisione non ha mai bisogno del vero valore di una chiave: sostituitelo con [CHIAVE_API], e i dati reali con valori inventati. Se una chiave è già partita da qualche parte, cambiatela. La guida sui dati da non incollare mai in un'IA approfondisce il caso dei segreti di accesso. La richiesta più semplice dimostra che se ne può fare a meno:
Ecco uno stack trace PHP e il metodo che lo provoca. Ho sostituito gli identificativi e i dati con valori fittizi. Spiegami la causa probabile in tre frasi, poi proponi la correzione più piccola possibile.
Rinominare calcolaScontoClienteX in f1, togliere il nome dell'azienda dai commenti: si ha l'impressione di aver reso anonimo il codice. Ma ciò che dà valore a un codice proprietario è la sua logica, e quella resta intatta. I nomi delle tabelle, i domini interni e i messaggi di errore bastano spesso a riconoscere il progetto.
Il Filtro di riservatezza di IA Confidential non pretende di fare di più. Quando scegliete un modello esterno, rileva prima i dati sensibili e vi lascia decidere: rispondere con un modello confidenziale, con il messaggio intatto; inviare una versione anonimizzata, che potete rileggere e correggere; oppure inviare così com'è. Per un allegato partono solo gli estratti utili, pseudonimizzati. Ma ciò che sostituisce sono dati che identificano: un nome, un indirizzo, un identificativo. Non un algoritmo.
Il rimedio: distinguere due tipi di domande. «Perché questo ordinamento è lento?» sul vostro modulo di fatturazione resta su un modello confidenziale. «Come funziona in generale il blocco ottimistico?» può andare a un modello esterno, senza il vostro codice. Per i nomi che non volete mai veder uscire, come il nome del cliente, il nome in codice del progetto o un dominio interno, scriveteli nelle istruzioni di anonimizzazione del pannello Riservatezza: sono proprio gli elementi che nessun rilevatore indovina da solo. La guida anonimizzazione o pseudonimizzazione spiega la differenza.
Due eccessi opposti. O si allega un solo file, e l'IA inventa il comportamento delle classi che non vede. Oppure le si affida la radice del progetto «perché abbia tutto», con la configurazione di produzione, i backup del database e gli script di deploy.
Il rimedio: fornire il contesto utile, e solo quello. Sul computer, con Chrome, Edge o Opera, potete aggiungere a uno spazio fino a dieci cartelle del vostro dispositivo, con permessi per cartella: Ricerca, Lettura, Scrittura. Per una revisione, aggiungete la cartella del modulo interessato invece della radice, senza il permesso di Scrittura, e attivate l'opzione «Modelli confidenziali»: la cartella non viene allora mai inviata a un modello esterno. Con un account connesso, l'assistente vi ritrova automaticamente i passaggi utili alla vostra domanda. Con un altro browser, allegate al messaggio i file necessari: vengono letti nel vostro browser, e nessuno viene conservato sui nostri server.
Senza criteri, la revisione resta generica: osservazioni di stile, un consiglio sui nomi, il suggerimento di aggiungere commenti. La vera questione (una perdita di memoria, una query in un ciclo, una vulnerabilità di tipo injection) passa inosservata.
Il rimedio: fissare il quadro una volta per tutte, poi precisare a ogni richiesta. Create uno spazio di tipo «Sviluppo» per ogni progetto: propone esempi per leggere, correggere e scrivere codice, e risposte dettagliate. Nella scheda Assistente, le istruzioni dello spazio stabiliscono il linguaggio e la sua versione, il framework, le vostre convenzioni, ciò che è fuori tema; prevalgono sulle vostre preferenze generali. La richiesta dice poi che cosa cercate:
Rivedi il metodo di importazione qui sotto, chiamato su file di 50 000 righe. Non voglio osservazioni di stile. Cerca solo: le query eseguite in un ciclo, i caricamenti completi in memoria e i casi in cui una riga non valida interrompe tutta l'importazione. Per ogni punto, cita la riga e stima l'effetto su un file di grandi dimensioni.
L'IA sbaglia con sicurezza. Inventa un metodo che non esiste nella vostra versione della libreria, propone una correzione che fa passare il test senza risolvere la causa, dichiara «sicuro» un codice in cui le è sfuggita una vulnerabilità. Una revisione con l'IA non è un audit di sicurezza, e una correzione accettata di fretta finisce in produzione giovedì.
Il rimedio: pretendere che si spieghi, e verificare. Chiedete i numeri di riga, ipotesi esplicite, ciò che non ha potuto vedere. Poi fate passare ogni correzione dai vostri test e dalla consueta revisione umana del team. La richiesta più approfondita assomiglia a questa:
Ecco il diff di una merge request che modifica la nostra autenticazione tramite token, con i due file che tocca. Fai una revisione di sicurezza: controllo degli accessi, validazione degli input, gestione degli errori, confronto dei token. Per ogni rischio, indica la riga, uno scenario di attacco concreto e la correzione minima. Elenca poi ciò che non hai potuto verificare perché non vedi il resto del codice, e proponi tre test che dimostrerebbero che la correzione funziona.
La responsabilità del codice integrato resta del team che lo integra.
Con un modello confidenziale, il vostro codice lascia la vostra postazione per essere elaborato su server situati in Svizzera, poi da parte nostra non viene conservato nulla. Una cartella aggiunta con l'opzione «Modelli confidenziali» non viene mai inviata a un modello esterno, e l'indice che permette di ritrovarvi i passaggi resta nella cartella, sul vostro computer. I file allegati vengono letti nel vostro browser.
Con un modello esterno, siete voi a decidere che cosa parte, dopo il passaggio dal filtro: versione anonimizzata, estratti pseudonimizzati, o messaggio così com'è se ve ne assumete la responsabilità. Il vostro profilo personale, invece, non viene mai inviato a un modello esterno. Tenete presente che l'anonimizzazione maschera nomi, non una logica: un codice il cui segreto è l'algoritmo resta sui modelli confidenziali.
La cronologia delle vostre conversazioni, estratti di codice compresi, vive nel vostro browser e da nessun'altra parte. Su una postazione condivisa o su una macchina di collaudo comune, è leggibile da chiunque usi la stessa sessione: lavorate in una sessione personale e disconnettetevi quando ve ne andate. E un segreto tolto dal messaggio è protetto solo se lo è anche nel vostro repository.
Se il vostro team esita ancora ad autorizzare l'IA, gli argomenti della guida usare l'IA al lavoro senza rischi valgono anche per un reparto di sviluppo. Per provare su un modulo senza rischi, con i segreti rimossi: aprite la chat.
