Een manager zegt dat code-review dood is. Zijn team is het daar niet mee eens. Iemand reageert met de vraag die het eigenlijk beslist: als je onder SOC 2 valt, hoe merge je dan zonder dat een mens de wijziging goedkeurt? Een compliance-praktijkbeoefenaar antwoordt, correct, dat het framework niet uitmaakt hoe de goedkeuring plaatsvindt, zolang je gedocumenteerde proces wordt gevolgd. Dat antwoord is juist, en daar begint het interessante deel, want het proces dat een team zou moeten opschrijven is smaller en vreemder dan beide partijen in de discussie aannemen.
De tools die hiervoor beschikbaar zijn, zijn reëel en vandaag al in gebruik: Greptile, GitHub Copilot code review, Claude Code, die allemaal pull requests lezen. De nuttige vraag is dus niet of een AI een wijziging mag goedkeuren. Het gaat erom wat SOC 2 eigenlijk van die goedkeuring vereist, en wat een code-review-signaal je vertelt, versus wat een compliance-goedkeuring nog steeds zelf moet vaststellen.
Wat CC8.1 eigenlijk vraagt
SOC 2 change management valt onder één criterium: CC8.1. In eenvoudige bewoordingen vereist dit dat een wijziging geautoriseerd, gebouwd, geconfigureerd, gedocumenteerd, getest, goedgekeurd en geïmplementeerd wordt via een gedefinieerd proces, zodat wijzigingen bewust in productie komen in plaats van per ongeluk. Het noemt de stappen die een wijziging moet doorlopen en verwacht dat je wijzigingen deze stappen daadwerkelijk doorlopen.
Het woord dat de hele discussie draagt, is 'goedgekeurd'. Het criterium noemt de stap. Het noemt niet wie, of wat, deze uitvoert. De criteria van SOC 2 zijn opgesteld om principegebaseerd en technologieneutraal te zijn: jij definieert de controle die aan het criterium voldoet, en de auditor test de controle die jij hebt gedefinieerd, zoals geschreven, over de periode. Niets in CC8.1 zegt dat de goedkeurder een persoon moet zijn. Een beleid dat geautomatiseerde goedkeuring toestaat voor een gedefinieerde klasse wijzigingen kan hieraan voldoen, mits de controle is afgebakend, gedocumenteerd, werkt zoals je hebt opgeschreven en je auditor dit als controle accepteert.
Dit is geen hypothetische situatie. Teams schrijven al change-management-beleid om, zodat laagrisico-wijzigingen door geautomatiseerde middelen kunnen worden goedgekeurd, met menselijke goedkeuring gereserveerd voor wijzigingen boven een risicodrempel die zij zelf definieeren. Dat is een verdedigbare houding ten aanzien van CC8.1 als je dit kunt aantonen. Het is een beleid, toegepast en getest, niet de afwezigheid daarvan.
De drie dingen die 'de AI heeft het goedgekeurd' negeert
Ten eerste: scheiding van taken. Een goedkeuring is alleen waardevol als de goedkeurder onafhankelijk is van de auteur. Dat is de oudste verwachting in change management: de persoon die de wijziging heeft geschreven, is niet de enige die deze goedkeurt, zodat geen enkele actor zomaar alles naar productie kan pushen. 'De AI heeft het goedgekeurd' botst hier direct op. Als dezelfde agent de diff schrijft en goedkeurt, of als twee automatiseringen dit doen zonder onafhankelijke controle daartussen, dan zijn auteur en goedkeurder samengevoegd. Dat is het deel waar een auditor op zal doorvragen, niet het woord 'AI'.
Ten tweede: het beleid moet dit daadwerkelijk zeggen. Een auditor test niet je intenties, maar je gedocumenteerde proces tegen wat er is gebeurd. 'De review-bot was tevreden' is geen controle tenzij je change-management-beleid die reviewer definieert: wat het is, welke wijzigingen het mag goedkeuren, wat het controleert en wanneer een mens nog steeds vereist is. Zonder dat is een geautomatiseerde goedkeuring geen controle die werkt zoals bedoeld. Het is een merge met een opmerking van een robot eraan gekoppeld.
Ten derde: het bewijsmateriaal is hetzelfde, ongeacht de methode. Wat een auditor steekproefsgewijs controleert, verandert niet omdat een bot heeft goedgekeurd: ze willen zien dat de wijziging geautoriseerd was, dat deze is getest, wie of wat deze heeft goedgekeurd en dat al deze informatie gekoppeld is aan de wijziging en gelogd. Geautomatiseerde goedkeuring voldoet aan CC8.1 als deze voor elke wijziging die het aanraakt, dit bewijsmateriaal produceert. Als het geen spoor achterlaat, heeft het de controle niet vervangen, maar overgeslagen.
Een technisch detail dat de discussie overslaat: een opmerking is geen goedkeuring
Onder de filosofie ligt een technisch detail dat meer beslist dan de filosofie zelf. In GitHub's eigen model zijn een AI-reviewer die feedback geeft en een AI-reviewer die de goedkeurende actie uitvoert twee verschillende dingen, en niet alle tools die mensen noemen, doen het tweede.
GitHub Copilot code review, beschikbaar sinds 2025, plaatst zijn feedback standaard als een Comment-review. Volgens GitHub's eigen beschrijving telt dit niet mee voor vereiste goedkeuringen en blokkeert of vrijgeeft het geen merge. Dus 'laat Copilot goedkeuren' is, mechanisch gezien, iets wat Copilot niet doet: een vereiste mens, of een automerge-regel die je hebt geconfigureerd, voert nog steeds de goedkeurende actie uit. De pull-request-actie van Claude Code leest wijzigingen en, afhankelijk van hoe je het instelt, plaatst het feedback als opmerkingen of als een formeel review-evenement. Wat het indient en of dit kan voldoen aan een branch-beschermingsregel, is iets wat je configureert en verifieert. Greptile leest elke pull request op bugs en kwaliteit met context uit de hele codebase en markeert problemen in de wijziging.
Dus 'de AI kan goedkeuren' is net zozeer een configuratiebeslissing als een beleidsbeslissing. Welke tool welk signaal afgeeft, wat dat signaal mag blokkeren of vrijgeven, en waar het record daarvan terechtkomt, zijn dingen die je bewust instelt in repository-regels en branch-bescherming, niet dingen die volgen uit een tweet. Stel ze bewust in, want die configuratie is de controle die je auditor daadwerkelijk zal testen.
Een groene review is geen compliance-review
Zelfs als de mechanica klopt, negeert de discussie stilletjes een moeilijkere vraag. Al die tools zijn gebouwd om de vragen te beantwoorden die code-review altijd heeft gesteld: is dit correct en is het veilig. Dat zijn de juiste vragen om bij een diff te stellen, en goede om te automatiseren. Of de wijziging nog steeds voldoet aan de frameworks waar je op wordt geaudit, is een andere vraag.
Die tweede vraag hangt af van welke controles je hebt gedocumenteerd en waar je laatste audit op vertrouwde, en dat is geen eigenschap van de code die een bug-reviewer uit de diff afleest. Een wijziging kan correct zijn, veilig, alle geautomatiseerde controles doorstaan en toch een controle aanpassen waar je op wordt gesampled. Hier is een voorbeeld.
export const auditLog = {- retentionDays: 365,+ retentionDays: 30, // trim storage cost}Schoon, correct en goedkoper: hier is niets een bug of kwetsbaarheid. SOC 2 stelt geen vast aantal dagen voor bewaring, maar je eigen logging- en monitoringcontrole wel, en deze is afhankelijk van het bestaan van deze logs voor de periode die je hebt toegezegd ze te bewaren. Als je controle of auditbewijs uitgaat van een langere periode, kunnen gebeurtenissen ouder dan de nieuwe termijn niet meer worden beoordeeld, en een audit die die periode steekproefsgewijs controleert, vindt de logs niet meer. Stel de bewaringstermijn in op basis van wat je controle en bewijs nodig hebben, niet alleen op basis van de opslagkosten.
Waar heygrc in past
Die wijziging in de bewaringstermijn is op zichzelf schoon en correct, wat precies de reden is dat een compliance-vraag open kan blijven staan, zelfs als alle code-review-signalen groen zijn. Dus als een beleid zegt dat een wijziging 'goedgekeurd is door geautomatiseerde middelen', is de eerlijke vervolgvraag: goedgekeurd als correct, of goedgekeurd als compliant? Dat zijn twee verschillende goedkeuringen, en in die discussie was er maar één op tafel.
heygrc is gebouwd voor de tweede. Het leest elke pull request tegen de frameworks waaraan je moet voldoen en noemt de exacte controle die een wijziging raakt, op het niveau van de diff, of een persoon of een agent deze heeft geschreven. Het probeert geen bugchecker te zijn: houd Greptile, Copilot of Claude Code aan voor correctheid en veiligheid, de rollen waarvoor ze zijn gebouwd, en gebruik heygrc voor de afzonderlijke compliance-lezing, gerapporteerd op de enige manier die een compliance-bevinding waardevol maakt: door de clausule te citeren.
Als je geautomatiseerde goedkeuring wilt toestaan voor laagrisico-wijzigingen onder CC8.1, is dat een redelijke richting. Een geautomatiseerde compliance-lezing is de ontbrekende controle die je helpt bepalen welke wijzigingen eigenlijk laagrisico zijn. De voorbeelden hier zijn illustratief, het soort wijziging dat de vraag oproept in plaats van telemetrie waar we claim op maken. Maar het punt staat op zichzelf: SOC 2 heeft nooit vereist dat een mens je pull requests moet goedkeuren. Het vereiste dat iemand, of iets, ze op de juiste manier heeft goedgekeurd, onafhankelijk, tegen een proces dat je hebt gedocumenteerd. Een tevreden code-reviewer is niet hetzelfde als dat proces dat is uitgevoerd.