La checklist del CISO per il software generato da AI

La domanda di sicurezza sul codice generato da AI viene di solito posta al contrario. "Il codice AI è meno sicuro del codice umano?" invita a una gara di citazioni di studi e manca il punto operativo: l'AI cambia volume, velocità e paternità del codice, e quei tre spostamenti rompono le assunzioni su cui era costruito il tuo programma di assurance esistente. I pen test annuali presumono che la codebase cambi lentamente. La revisione manuale presume un autore umano che ha capito la modifica e può risponderne. Il campionamento presume che il codice non campionato assomigli a quello campionato. Sotto lo sviluppo AI, nessuna delle tre regge.

Quindi il requisito a livello di CISO non è un verdetto sulla qualità dei modelli. I modelli continueranno comunque a cambiarti sotto i piedi. È un insieme di proprietà che il sistema di sviluppo deve avere a prescindere da quale modello abbia scritto il codice: ogni modifica attribuibile a un prompt, a una persona e a un'approvazione; le modifiche con conseguenze bloccate da policy prima del merge; test di sicurezza che girano in continuo e confermano i risultati sull'applicazione live invece di inondarti di rumore statico; e un registro immutabile abbastanza buono da ricostruire qualsiasi modifica per un auditor o una revisione d'incidente.

Inquadrato così, lo sviluppo AI non è una nuova categoria di rischio che esige una nuova teoria. È una categoria familiare, la gestione dei cambiamenti su larga scala, che esige macchinari migliori. La checklist qui sotto è quel macchinario, scritta come requisiti da mettere davanti a qualsiasi vendor o team di piattaforma interno.

La postura conta quanto i controlli. L'atteggiamento produttivo è presumere che il software generato da AI esista già nella tua organizzazione, perché è così, e rendere il percorso governato quello attraente, invece di annunciare un divieto che spinge le build ancora più nell'ombra. I team di sicurezza che pubblicano una via sanzionata con controlli chiari ottengono visibilità e adozione; i team che proibiscono non ottengono né l'una né l'altra, più lo stesso rischio. Ogni requisito qui sotto serve quella strategia: ognuno rende il modo sicuro di costruire anche il modo facile di rispondere di ciò che è stato costruito.

Parti da ciò che è già vero: le business unit stanno generando applicazioni con strumenti AI oggi, per lo più fuori dal campo visivo della sicurezza. L'incidente realistico a breve termine non è un attacco esotico ai modelli; è un'app costruita con l'AI e mai revisionata, con una policy di database troppo permissiva, che espone silenziosamente record dei clienti. Scoperta da un cliente. Lo sviluppo AI ombra è IT ombra con un generatore di codice attaccato, ed eredita ogni fallimento classico. Flussi di dati sconosciuti, dipendenze non aggiornate, nessun proprietario. A velocità di produzione molto più alta.

Dentro l'ingegneria, il rischio è più sottile: l'erosione della revisione sotto il volume. Quando le pull request generate dagli agenti triplicano e l'organico dei revisori no, l'approvazione o diventa il collo di bottiglia che uccide il guadagno di produttività o diventa un timbro di gomma che uccide il controllo. Entrambi gli esiti sono cattivi, e le organizzazioni che non hanno mai fatto la scelta esplicitamente di solito ottengono il secondo per default. L'unica risposta stabile è il triage via policy. Le macchine smaltiscono la routine, gli umani revisionano ciò che le regole segnalano come importante. Con la policy stessa posseduta dalla sicurezza, non da chi ha scritto il prompt.

E quando qualcosa va davvero storto, la domanda di incident response diventa l'intera partita: sai ricostruire cosa è cambiato, chi o cosa lo ha cambiato, quali test sono girati e chi ha approvato? Se la risposta onesta è un log di chat nell'account di un contractor che se n'è andato, non hai un programma di assurance per lo sviluppo AI. Hai esposizione con buone intenzioni.

Aspettati anche che la pressione esterna salga. Auditor, assicuratori cyber e clienti enterprise hanno iniziato a fare domande dirette sul codice generato da AI nei questionari di sicurezza e nelle valutazioni dei fornitori. Come viene revisionato, quali test lo bloccano, se esiste la provenienza. Le organizzazioni che sanno rispondere da un registro di controllo supereranno quelle revisioni come routine; le organizzazioni che improvvisano risposte vivranno ognuna come un'esercitazione antincendio. Costruire il macchinario delle prove ora, prima che un auditor specifico lo esiga, è materialmente più economico che costruirlo durante un rilievo.

Il livello di governance di Ciao è stato progettato esattamente contro questa checklist. Guardrails mappa il codice in aree di business, rileva le modifiche rischiose, applica policy in linguaggio semplice, registra la revisione umana e lascia un registro di controllo dietro ogni merge; il registro è append-only e copre prompt, merge, deploy e azioni amministrative. Security esegue scansione statica, controlli delle dipendenze e sonde di controllo degli accessi, e conferma le vulnerabilità sull'app live prima di segnalarle. La differenza tra un feed di risultati di cui il tuo team si fida e uno che silenzia. QA fa da gate a ogni pubblicazione con replay browser deterministici ed esegue controlli di produzione dopo.

Sul lato rischio fornitore: i report SOC 2 Type II sono disponibili sotto NDA; la piattaforma supporta SSO tramite SAML e OIDC, MFA opzionale e controllo degli accessi basato sui ruoli; il codice del cliente non viene usato per addestrare i modelli e l'inferenza gira sotto contratti modello a conservazione zero; e una scala di modelli multi-provider con fallback riduce la dipendenza da qualsiasi singolo vendor di modelli. I target di deploy includono il tuo account AWS, Azure o GCP, la VPC privata o l'on-prem con termini separati per i carichi classificati. I programmi di sviluppo seri partono da 10.000 USD all'anno. Se stai costruendo lo standard interno per lo sviluppo AI, richiedi il security pack e valuta Ciao contro ogni riga qui sopra.

Un suggerimento di rollout dai team che l'hanno fatto bene: sequenzialo come inventario, poi percorso sanzionato, poi migrazione. Prima trova quale software costruito con l'AI esiste già e chi lo possiede; secondo, metti in piedi la piattaforma governata e instrada le nuove build attraverso di essa; terzo, sposta gli strumenti esistenti in ordine di raggio d'impatto. Pubblicare la checklist stessa come tuo standard interno, qualunque piattaforma tu scelga, trasforma una preoccupazione diffusa in un programma con punteggio e proprietari, e dà alle business unit una risposta chiara a "cosa lo renderebbe accettabile?" invece di una porta chiusa.