Un manager afferma che la revisione del codice è morta. Il suo team non è d'accordo. Qualcuno risponde con la domanda che decide effettivamente la questione: se sei soggetto a SOC 2, come fai il merge senza che un essere umano approvi la modifica? Un esperto di conformità risponde, correttamente, che il framework non si preoccupa di come avviene l'approvazione, ma solo che il processo documentato venga seguito. Questa risposta è corretta e rappresenta il punto di partenza per la parte interessante, perché il processo che un team dovrebbe documentare è più ristretto e strano di quanto entrambe le parti dell'argomento suppongano.
Gli strumenti disponibili per questo sono reali e già operativi: Greptile, GitHub Copilot code review, Claude Code, ognuno dei quali analizza le pull request in questo momento. Quindi la domanda utile non è se un'AI può approvare una modifica. È cosa SOC 2 richiede effettivamente per quell'approvazione e cosa un segnale di revisione del codice è progettato per indicare, rispetto a cosa un'approvazione di conformità deve comunque stabilire autonomamente.
Cosa richiede effettivamente CC8.1
La gestione delle modifiche in SOC 2 è racchiusa in un solo criterio, CC8.1. In termini semplici, richiede che una modifica sia autorizzata, costruita, configurata, documentata, testata, approvata e implementata tramite un processo definito, in modo che le modifiche raggiungano la produzione in modo deliberato piuttosto che per caso. Indica i passaggi che una modifica deve superare e si aspetta che le modifiche li superino effettivamente.
La parola che porta avanti tutto l'argomento è 'approvata'. Il criterio nomina il passaggio. Non specifica chi, o cosa, lo esegue. I criteri di SOC 2 sono scritti per essere basati su principi e neutrali rispetto alla tecnologia: tu definisci il controllo che soddisfa il criterio e l'auditor verifica il controllo che hai definito, così com'è, nel periodo considerato. Nulla in CC8.1 afferma che l'approvatore debba essere una persona. Una policy che autorizza l'approvazione automatica per una classe definita di modifiche può soddisfarlo, se il controllo è delimitato, documentato e funziona nel modo in cui lo hai descritto, e il tuo auditor lo accetta come controllo.
Questo non è ipotetico. I team stanno già riscrivendo le policy di change management in modo che le modifiche a basso rischio possano essere approvate con mezzi automatici, riservando l'approvazione umana alle modifiche sopra una soglia di rischio che definiscono. Questa è una posizione difendibile per CC8.1 quando puoi fornire le prove. È una policy, applicata e testata, non la sua assenza.
Le tre cose che 'l'AI l'ha approvato' ignora
Prima, la separazione dei compiti. Un'approvazione vale qualcosa solo se l'approvatore è indipendente dall'autore. Questa è l'aspettativa più antica nella gestione delle modifiche: la persona che ha scritto la modifica non è l'unica che la approva, in modo che nessun singolo attore possa spingere in produzione ciò che preferisce. 'L'AI l'ha approvato' va dritto contro questo principio. Se lo stesso agente scrive la diff e la approva, o se due automazioni lo fanno senza un controllo indipendente tra loro, hai fuso autore e approvatore. Questa è la parte su cui un auditor insiste, non la parola 'AI'.
Seconda, la policy deve effettivamente dirlo. Un auditor non verifica le tue intenzioni, ma il processo documentato rispetto a ciò che è successo. 'Il bot revisore era soddisfatto' non è un controllo a meno che la tua policy di change management non definisca quel revisore: cosa è, quali modifiche può approvare, cosa verifica e quando è ancora richiesto un essere umano. Senza questo, un'approvazione automatica non è un controllo che opera come progettato. È un merge con un commento di un robot allegato.
Terza, la traccia delle prove è la stessa in ogni caso. Ciò che un auditor campiona non cambia perché un bot ha approvato: vuole vedere che la modifica sia stata autorizzata, che sia stata testata, chi o cosa l'abbia approvata e che tutto sia collegato alla modifica e registrato. L'approvazione automatica soddisfa CC8.1 quando produce quella traccia per ogni modifica che tocca. Se non lascia traccia, non ha sostituito il controllo, lo ha saltato.
Un dettaglio tecnico che il thread salta: il commento non è un'approvazione
Sotto la filosofia c'è un dettaglio di configurazione che decide più della filosofia stessa. Nel modello di GitHub, un revisore AI che lascia un feedback e un revisore AI che emette l'azione di approvazione sono due cose diverse, e gli strumenti citati non svolgono tutti la seconda.
GitHub Copilot code review, disponibile dal 2025, pubblica i suoi feedback come Comment review per progettazione. Secondo la stessa descrizione di GitHub, non contribuisce alle approvazioni richieste e non blocca o sblocca un merge. Quindi 'lasciare che Copilot approvi' non è, tecnicamente, qualcosa che Copilot fa: un essere umano richiesto o una regola di automerge che hai configurato emette comunque l'azione di approvazione. L'azione di pull-request di Claude Code legge le modifiche e, a seconda di come la configuri, pubblica il feedback come commenti o come evento di revisione formale, quindi cosa invia e se può soddisfare una regola di protezione del branch è qualcosa che configuri e verifichi. Greptile legge ogni pull request alla ricerca di bug e problemi di qualità con il contesto dell'intera codebase e segnalare problemi nella modifica.
Quindi 'l'AI può approvare' è una decisione di configurazione tanto quanto una decisione di policy. Quale strumento emette quale segnale, cosa quel segnale è autorizzato a controllare e dove finisce la registrazione sono cose che imposti deliberatamente, nelle regole del repository e nella protezione del branch, non cose che derivano da un tweet. Impostale con attenzione, perché quella configurazione è il controllo che il tuo auditor verificherà effettivamente.
Una revisione verde non è una revisione di conformità
Anche una volta che la parte tecnica è corretta, il thread dà per scontata una domanda più difficile. Ognuno di quegli strumenti è progettato per rispondere alle domande che la revisione del codice ha sempre posto: questa modifica è corretta e sicura? Queste sono le domande giuste da porre su una diff e sono buone da automatizzare. Se la modifica soddisfa ancora i framework per cui sei sottoposto a audit è una domanda diversa.
Quella seconda domanda dipende da quali controlli hai documentato e da cosa si basava il tuo ultimo audit, e non è una proprietà del codice che un revisore di bug può leggere dalla diff. Una modifica può essere corretta, sicura, superare tutti i controlli automatici e spostare comunque un controllo che sarà campionato. Ecco un esempio.
export const auditLog = {- retentionDays: 365,+ retentionDays: 30, // trim storage cost}Pulita, corretta e più economica: qui non c'è un bug o una vulnerabilità. SOC 2 non imposta un numero di conservazione, ma il tuo controllo di logging e monitoraggio sì, e dipende dall'esistenza di questi log per tutto il tempo in cui ti sei impegnato a conservarli. Se il tuo controllo o le prove di audit presuppongono una finestra temporale più lunga, gli eventi più vecchi di quella nuova non possono più essere revisionati e un audit che campiona il periodo trova che i log non lo coprono più. Imposta la conservazione in base a ciò che richiedono il tuo controllo e le tue prove, non solo in base al costo di archiviazione.
Dove si inserisce heygrc
Quella modifica della conservazione è pulita e corretta nei suoi termini, ed è proprio per questo che una domanda di conformità può rimanere aperta anche dopo che tutti i segnali di revisione del codice su di essa sono verdi. Quindi, quando una policy afferma che una modifica è stata 'approvata con mezzi automatici', la domanda onesta da porsi è: approvata come corretta o approvata come conforme? Queste sono due approvazioni diverse e in quel thread solo una di esse era in discussione.
heygrc è progettato per la seconda. Legge ogni pull request rispetto ai framework che devi rispettare e identifica il controllo esatto che una modifica tocca, a livello di diff, indipendentemente dal fatto che sia stata scritta da una persona o da un agente. Non cerca di essere un controllore di bug: tieni Greptile, Copilot o Claude Code per la correttezza e la sicurezza, i ruoli per cui sono stati creati, e usa heygrc per la lettura di conformità separata, riportata nell'unico modo in cui un riscontro di conformità vale qualcosa, citando la clausola.
Se hai intenzione di consentire l'approvazione automatica per il merge di modifiche a basso rischio ai sensi di CC8.1, questa è una direzione ragionevole. Una lettura automatica di conformità è il controllo mancante che ti aiuta a decidere quali modifiche sono effettivamente a basso rischio in primo luogo. Gli esempi qui sono illustrativi, del tipo di modifica che solleva la domanda piuttosto che telemetria che stiamo affermando. Ma il punto regge da solo: SOC 2 non ha mai richiesto che un essere umano approvasse le tue pull request. Ha richiesto che qualcuno, o qualcosa, le approvasse in modo documentato, indipendentemente, secondo un processo che hai scritto. Un revisore del codice soddisfatto non è la stessa cosa del fatto che quel processo sia stato eseguito.