In un team che si affida a agenti di coding, questi agenti aprono una grande parte delle pull request che vengono rilasciate e spesso sono bravi nel compito visibile: la funzionalità funziona, i test passano, le dipendenze sono aggiornate. Ciò che un agente potrebbe non avere motivo di valutare è se una modifica ha spostato un controllo su cui la tua azienda è sottoposta a audit, perché quell'obbligo risiede nei tuoi framework e nel tuo contesto, non nel diff che gli è stato chiesto di produrre. Questo divario è esattamente ciò per cui serve un controllo di conformità per il codice generato dall'IA.
Le raccolta esistenti di strumenti per la conformità del codice IA si riferiscono principalmente a una di tre cose: analisi statica per bug, scansione di dipendenze e licenze o rilevamento di segreti. Questi sono reali e utili da eseguire. Nessuno di essi è progettato per leggere una modifica rispetto a SOC 2, ISO 27001 o GDPR a livello di un controllo specifico, che è una domanda diversa posta alla stessa pull request.
Cosa significa conformità qui, a livello di controllo
La conformità per il codice generato dall'IA non è un controllo dell'intestazione della licenza o un punteggio di vulnerabilità. È la domanda se una modifica ha interessato un controllo che sei tenuto a mantenere: un confine di accesso logico, una registrazione di log di audit, un livello minimo di crittografia, un limite di conservazione. Questi obblighi sono nominati nei framework che la tua azienda ha selezionato, a un livello che puoi verificare, ad esempio ISO 27001:2022 A.8.15 per il logging o GDPR Art. 5(1)(c) per la minimizzazione dei dati.
Il motivo per cui questa è una lettura separata è che una modifica rilevante per il controllo è solitamente codice corretto. Di solito compila, è sicuro, ha una licenza appropriata e fa ciò che l'agente era stato incaricato di fare. Il problema non è un difetto nella modifica; è che la modifica ha silenziosamente spostato qualcosa che un auditor potrebbe esaminare in seguito. Un controllo che cerca solo difetti non è progettato per segnalare questo.
Un esempio pratico: un agente arricchisce un profilo con più dati del necessario
Supponiamo che un agente venga incaricato di aggiungere un badge di livello fedeltà alla pagina dell'account. Per calcolare il livello, aggiunge una cache user_profile e la popola dal servizio di identità. Il modo più semplice per farlo, e un modo che un agente che ottimizza per il compito potrebbe scegliere, è copiare l'intero record di identità nel nuovo archivio: data di nascita, ID nazionale, indirizzo di casa e telefono, insieme al livello e al nome visualizzato che il badge utilizza effettivamente.
La migrazione è pulita e la funzionalità funziona al primo tentativo. Ma il nuovo archivio ora contiene quattro categorie di dati personali che il badge fedeltà non utilizza. Questo riguarda la minimizzazione dei dati, GDPR Art. 5(1)(c): i dati personali devono essere adeguati, pertinenti e limitati a ciò che è necessario per lo scopo. La soluzione è una riga di intenti: popola la cache solo con il livello e il nome visualizzato, ed è più economico farlo nella pull request che ha introdotto l'archivio, mentre l'autore ha ancora il contesto. Se lasciata così, diventa un nuovo archivio che contiene dati personali non necessari per il suo scopo dichiarato, scoperti mesi dopo.
Perché gli scanner di bug, vulnerabilità e licenze non sono progettati per rilevare questo
La modifica sopra non è il tipo di cosa che questi scanner sono progettati per rilevare: il codice è corretto, quindi uno scanner di bug lo approva; non è arrivata alcuna nuova dipendenza, quindi uno scanner di licenze lo approva; e uno scanner di vulnerabilità non è progettato per leggere un allargamento dell'impronta dei dati personali come un riscontro. Quindi gli scanner progettati per trovare queste cose funzionano come previsto quando li approvano, perché una modifica rilevante per il controllo che è altrimenti pulita non è ciò che sono progettati per leggere. Questo non è una critica verso di loro; rilevare bug, vulnerabilità e derive delle licenze è davvero prezioso, e l'output di un agente ha bisogno di tutto questo.
Significa che una lettura di conformità è un livello distinto, non una versione più forte della stessa scansione. Legge il diff rispetto ai framework a cui sei vincolato e nomina il controllo che la modifica ha interessato, informazioni che gli altri strumenti non sono progettati per produrre. La postura sensata è eseguire entrambi: gli scanner di qualità del codice e sicurezza per i difetti, e un controllo di conformità per la deriva dei controlli, sulla stessa pull request.
Il cambiamento che rende questo urgente
Due cose cambiano quando gli agenti scrivono una grande parte del codice. Volume: un agente apre più pull request di quante un'attenta lettura umana di conformità possa gestire, quindi la lettura diventa un collo di bottiglia o viene saltata. Forma del fallimento: un agente ottimizza per il compito visibile, quindi il codice di controllo che appare come un attrito, una riga di log, un controllo delle autorizzazioni, un limite di conservazione, è esattamente il tipo di cosa che un diff può tagliare o allargare senza accorgersene.
Indipendentemente da chi ha scritto una modifica, l'auditor valuta comunque se il controllo ha operato, quindi il codice scritto dall'IA è soggetto agli stessi standard del codice scritto dall'uomo. Ciò che deve cambiare è che la lettura di conformità ora deve essere eseguita alla velocità della macchina per stare al passo, il che significa automatizzare il primo passaggio e riservare il giudizio umano ai casi segnalati.
Come aggiungere il controllo
Un controllo di conformità per il codice generato dall'IA viene eseguito sulla pull request nello stesso modo degli altri controlli: viene attivato quando una PR viene aperta o aggiornata, legge il diff rispetto ai framework che hai selezionato e al contesto della tua azienda, e pubblica i controlli che una modifica interessa con la clausola allegata, come commento più uno stato neutrale. Quando un agente apre la PR, il controllo incontra il codice dove l'agente lo ha già posizionato, senza passaggi aggiuntivi per l'umano che deve approvarlo.
heygrc è progettato per essere quel controllo come GitHub App: installalo, configura i tuoi framework e il contesto una volta (una singola chiamata REST che il tuo agente di coding può fare per te), e revisiona ogni pull request per l'impatto sulla conformità e cita il controllo nel diff. Pubblica uno stato neutro dei Checks più commenti in linea, quindi informa piuttosto che blocca, a meno che tu non scelga di renderlo obbligatorio. Usalo insieme ai tuoi scanner di bug e sicurezza, non al loro posto.