Bij een team dat afhankelijk is van codeeragents, openen die agents een groot deel van de pull requests die worden geïmplementeerd, en ze zijn vaak goed in de zichtbare taak: de functionaliteit werkt, de tests slagen, de afhankelijkheden zijn actueel. Wat een agent geen reden heeft om te overwegen, is of een wijziging een controle heeft verplaatst waar je bedrijf op wordt geaudit, omdat die verplichting in je frameworks en context staat, niet in de diff die het moest produceren. Die leemte is precies waar een compliancecontrole voor door AI gegenereerde code voor bedoeld is.
De bestaande overzichten van AI-codecompliancetools bedoelen meestal één van drie dingen: statische analyse voor bugs, afhankelijkheids- en licentiescanning of detectie van geheimen. Die zijn reëel en de moeite waard om uit te voeren. Geen van hen is echter ontworpen om een wijziging af te zetten tegen SOC 2, ISO 27001 of de GDPR op het niveau van een specifieke controle, wat een andere vraag is die aan dezelfde pull request wordt gesteld.
Wat compliance hier betekent, op controleniveau
Compliance voor door AI gegenereerde code is geen controle op licentieheaders of een kwetsbaarheidsscore. Het gaat om de vraag of een wijziging een controle heeft aangeraakt waar je verplicht bent aan te voldoen: een logische toegangsgens, een auditlogrecord, een encryptie-eis, een bewaartermijn. Die verplichtingen zijn benoemd in de frameworks die je bedrijf heeft geselecteerd, op een niveau dat je kunt verifiëren, bijvoorbeeld ISO 27001:2022 A.8.15 voor logging of GDPR Art. 5(1)(c) voor dataminimalisatie.
De reden dat dit een aparte lezing is, is dat een controle-relevante wijziging meestal correcte code is. Deze compileert, is veilig, is correct gelicenseerd en doet wat de agent gevraagd werd te doen. Het probleem is niet een fout in de wijziging; het is dat de wijziging stilletjes iets heeft verplaatst wat een auditor later kan onderzoeken. Een controle die alleen naar fouten zoekt, is niet ontworpen om dit te signaleren.
Een uitgewerkt voorbeeld: een agent verrijkt een profiel met meer gegevens dan nodig
Stel, een agent wordt gevraagd om een loyaliteitsniveau-badge toe te voegen aan de accountpagina. Om het niveau te berekenen voegt de agent een user_profile-cache toe en vult deze aan met gegevens uit de identiteitsdienst. De meest voor de hand liggende manier om dat te doen, en een manier die een agent die optimaliseert voor de taak zou kunnen kiezen, is om het volledige identiteitsrecord naar de nieuwe opslag te kopiëren: geboortedatum, nationaal ID, thuisadres en telefoonnummer, naast het niveau en de weergavenaam die de badge daadwerkelijk gebruikt.
De migratie verloopt soepel en de functionaliteit werkt bij de eerste poging. Maar de nieuwe opslag bevat nu vier categorieën persoonsgegevens waar de loyaliteitsbadge geen doel voor heeft. Dat is dataminimalisatie, GDPR Art. 5(1)(c): persoonsgegevens moeten toereikend, relevant en beperkt zijn tot wat noodzakelijk is voor het doel. De oplossing is één regel intentie: vul de cache alleen met het niveau en de weergavenaam, en het is het goedkoopst om dit te doen in de pull request die de opslag introduceerde, terwijl de auteur nog de context heeft. Als het zo blijft, wordt het een nieuwe opslag met persoonsgegevens die niet nodig zijn voor het aangegeven doel, ontdekt maanden later.
Waarom bug-, kwetsbaarheids- en licentiescanners dit niet detecteren
De bovenstaande wijziging is niet het soort ding dat die scanners zijn ontworpen om te detecteren: de code is correct, dus een bugscanner keurt het goed; er is geen nieuwe afhankelijkheid toegevoegd, dus een licentiescanner keurt het goed; en een kwetsbaarheidsscanner is niet ontworpen om een uitgebreide persoonsgegevensvoetafdruk als bevinding te lezen. Dus de scanners die zijn ontworpen om die dingen te vinden, werken zoals bedoeld als ze het goedkeuren, omdat een controle-relevante wijziging die verder correct is, niet is wat ze zijn ontworpen om te lezen. Dit is geen kritiek op hen; het detecteren van bugs, kwetsbaarheden en licentieafwijkingen is echt waardevol, en de uitvoer van een agent heeft al die controles nodig.
Het betekent wel dat een compliancelezing een aparte laag is, geen sterkere versie van dezelfde scan. Deze leest de diff af tegen de frameworks waaraan je gebonden bent en noemt de controle die de wijziging heeft aangeraakt, wat informatie is die de andere tools niet zijn ontworpen om te produceren. De verstandige houding is om beide uit te voeren: de codekwaliteits- en beveiligingsscanners voor defecten, en een compliancecontrole voor controleafwijkingen, op dezelfde pull request.
De verandering die dit urgent maakt
Twee dingen veranderen wanneer agents een groot deel van de code schrijven. Volume: een agent opent meer pull requests dan een zorgvuldige menselijke compliancecontrole bij kan houden, dus de controle wordt ofwel een knelpunt of wordt overgeslagen. Foutpatroon: een agent optimaliseert voor de zichtbare taak, dus controlecodes die als wrijving worden gelezen, een logregel, een toestemmingscontrole, een bewaartermijn, zijn precies het soort dingen dat een diff kan inkorten of uitbreiden zonder dat het opvalt.
Ongeacht wie een wijziging heeft geschreven, beoordeelt de auditor nog steeds of de controle heeft gewerkt, dus door AI geschreven code wordt aan dezelfde lat gelegd als door mensen geschreven code. Wat moet veranderen, is dat de compliancecontrole nu op machinesnelheid moet worden uitgevoerd om het tempo bij te houden, wat betekent dat de eerste controle geautomatiseerd moet worden en menselijk oordeel gereserveerd moet worden voor de gemarkeerde gevallen.
Hoe de controle toe te voegen
Een compliancecontrole voor door AI gegenereerde code wordt uitgevoerd op de pull request op dezelfde manier als je andere controles: deze wordt geactiveerd wanneer een PR wordt geopend of bijgewerkt, leest de diff af tegen de frameworks die je hebt geselecteerd en de context van je bedrijf, en plaatst de controles die een wijziging aanraakt met de bijbehorende clausule, als opmerking plus een neutrale status. Wanneer een agent de PR opent, ontmoet de controle de code waar de agent deze al heeft geplaatst, zonder extra stap voor de mens die goedkeuring moet geven.
heygrc is ontworpen om die controle als GitHub App uit te voeren: installeer het, configureer je frameworks en context één keer (een enkele REST-aanroep die je codeeragent voor je kan doen), en het beoordeelt elke pull request op compliance-impact en citeert de controle bij de diff. Het plaatst een neutrale Checks-status plus inline opmerkingen, zodat het informeert in plaats van blokkeert, tenzij je kiest om het verplicht te stellen. Gebruik het naast je bug- en beveiligingsscanners, niet in plaats daarvan.