AI code governance is een engineeringsysteem, geen beleidsdocument: schriftelijke regels, benoemde eigenaren en automatische controles die bepalen hoe met AI-tools geschreven code in productie komt. De regels gelden of de code nu komt van een AI-assistent in de editor, een AI-appbouwer of een coding agent die zelf pull requests opent. De CTO is eigenaar van dat systeem, ook als budget en goedkeuring bij de directie liggen.
In de Stack Overflow Developer Survey 2025 zei 84% van de ontwikkelaars AI-tools te gebruiken of dat van plan te zijn, en ongeveer 31% gebruikt al AI-agents op het werk. Deze gids behandelt de componenten en beleidsbeslissingen, de controles die AI toevoegt per leveringspoort en voor coding agents, het eigenaarschap per teamgrootte, de EU-eisen die ertoe doen en een uitrol van 30 dagen. De volledige route van AI-gebouwd prototype naar live product staat in onze gids over AI coding in productie.
TL;DR
AI code governance is het geheel van schriftelijke regels, benoemde eigenaren en automatische controles dat bepaalt hoe met AI-tools geschreven code in een product komt en daar wordt onderhouden. AI code governance staat boven code review en DevSecOps: het bepaalt welke tools, gegevens, goedkeuringen en bewijzen gelden voor wijzigingen die AI schreef.
- AI code governance heeft vijf componenten, te beginnen met het AI-codeerbeleid: het AI-codeerbeleid, automatische controles, menselijke review, herkomstregistratie en monitoring met bewijs; het AI-codeerbeleid neemt zes beslissingen over tools, promptgegevens, goedkeuringsrechten, reviewdiepte, afhankelijkheden en herleidbaarheid.
- AI voegt controles toe op zes leveringspoorten en voor elke coding agent: editor, commit, pull request, CI, release en productie, plus een eigen identiteit, minimale rechten en een menselijke goedkeurder per agent.
- De CTO is eindverantwoordelijk voor AI code governance bij elke teamgrootte: een solo-founder heeft drie regels nodig, een team van 2–5 ontwikkelaars de zes beslissingen op één pagina, en teams met coding agents alle vijf componenten.
- EU-eisen leggen verplichtingen op, geen sjabloon: artikel 4 van de AI-verordening, artikel 28 van de AVG en artikel 20 van NIS2 gelden afhankelijk van de reikwijdte; ISO/IEC 27001 is een vrijwillige norm die klanten contractueel kunnen eisen.
Wat is AI code governance?
AI code governance is het geheel van schriftelijke regels, benoemde eigenaren en automatische controles dat bepaalt hoe met AI-tools geschreven code in een product komt en daar wordt onderhouden. Het omvat code, tests, configuratie en infrastructure-as-code, prompts en de gegevens daarin, en coding agents die zelf wijzigingen openen.
Het DORA-onderzoek van Google behandelt een uitgesproken standpunt over AI-gebruik als engineeringvaardigheid: “clear and communicated AI stance” is de eerste van zeven vaardigheden in het DORA AI Capabilities Model, gepubliceerd op 10 december 2025, naast sterk versiebeheer en werken in kleine batches.
| Begrip | Waar het over gaat | Gebruikelijke eigenaar |
|---|---|---|
| AI code governance | Hoe door AI geschreven code in het product komt, wie die goedkeurt, welk bewijs wordt bewaard | CTO (eindverantwoordelijk), directie (goedkeuring beleid) |
| AI-governance | Welke AI-systemen het bedrijf bouwt, koopt of gebruikt, en de bedrijfsrisico’s daarvan | Directie met juridische zaken of compliance |
| DevSecOps | Beveiliging in elke fase van de leveringspipeline, voor alle code | Engineering- en platformteams |
| Code review | Of één wijziging correct en veilig is — één controle binnen AI code governance | Ontwikkelaars en reviewers |
| Naleving van de AI-verordening | Verplichtingen voor AI-systemen die op de markt worden gebracht of worden gebruikt, per risicocategorie | Juridische zaken of compliance |
AI code governance is een onderdeel van de bredere AI-governance van een bedrijf. AI-governance legt bedrijfsbrede regels vast voor elk AI-systeem dat het bedrijf bouwt, koopt of gebruikt; AI code governance past die toe op AI-tools die de eigen software schrijven en voegt de engineeringcontroles toe die daarvoor nodig zijn. Aan de engineeringkant is het een laag bovenop DevSecOps, geen vervanging.
Waarom heeft door AI geschreven code eigen regels nodig?
Door AI geschreven code heeft eigen regels nodig omdat AI-tools vier aannames veranderen waarop een klassiek reviewproces leunde: de hoeveelheid code, het auteurschap, de gegevensstroom en de afhankelijkheden. In de Stack Overflow Developer Survey 2025 zei 46% van de respondenten de nauwkeurigheid van AI-tools te wantrouwen, tegenover 33% die erop vertrouwt, en noemde 66% “AI solutions that are almost right, but not quite” als grootste ergernis.
Hoeveelheid. Eén ontwikkelaar met een AI-assistent produceert per dag meer diff dan één reviewer zorgvuldig kan lezen. Zonder regel voor reviewdiepte naar risico daalt de reviewkwaliteit precies waar de code het snelst verandert.
Auteurschap. Zes maanden later weet niemand welke regels uit een prompt kwamen, tenzij wijzigingen met AI-hulp bij het samenvoegen zijn gemarkeerd.
Gegevensstroom. Waar promptgegevens terechtkomen, hangt af van het type tool. Een cloud-AI-assistent stuurt prompts en codecontext naar de servers van de leverancier, en het abonnement en contract bepalen bewaartermijn, opslaglocatie en of de gegevens het model mogen trainen. Zakelijke abonnementen kunnen een verwerkersovereenkomst en een uitsluiting van training toevoegen — controleer de voorwaarden, niet de naam van het abonnement. Een lokaal of zelfgehost model houdt prompts binnenshuis, maar vraagt nog steeds om regels voor logs, toegang en de modellicentie. Onze gids over gelekte API-keys laat zien hoe sleutels in AI-gebouwde producten belanden en hoe u ze verwijdert.
Afhankelijkheden. AI-tools stellen open-sourcepakketten voor die niemand bewust koos, en soms pakketten die niet bestaan. Zonder goedkeuringsstap verzamelt het product ongemerkt licenties en onderhoudsrisico.
Uit welke componenten bestaat AI code governance?
AI code governance bestaat uit vijf componenten: een schriftelijk AI-codeerbeleid, automatische controles die het afdwingen, menselijke review waar oordeel nodig is, herkomstregistratie van wijzigingen met AI-hulp, en monitoring die bewijs oplevert. De componenten passen op de vier practice groups van het NIST Secure Software Development Framework (SSDF), SP 800-218 versie 1.1 — Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) en Respond to Vulnerabilities (RV) — zodat een bestaand SSDF- of ISO-proces ze kan opnemen.
| Component | Wat het doet | Voorbeeldcontrole | SSDF-groep | Eigenaar |
|---|---|---|---|---|
| 1. AI-codeerbeleid | Legt vast wat mag en wie beslist | Eén pagina met de zes beslissingen hieronder | PO | CTO stelt op; directie keurt goed |
| 2. Automatische controles | Dwingt het beleid af zonder op geheugen te leunen | Verplichte goedkeurders, secret scanning, controles op afhankelijkheden en licenties | PW · PS | Platform- of tech lead |
| 3. Menselijke review | Beoordeelt wat tools niet kunnen: bedrijfsregels, gegevensgrenzen, ontwerp | Tweede reviewer op code rond betalingen, inloggen en persoonsgegevens | PW | Ontwikkelaars + onafhankelijke reviewer |
| 4. Herkomstregistratie | Legt vast welke wijzigingen AI-tools of agents maakten | AI-regel in elke pull request; commits van agents onder een eigen identiteit | PS | Elke ontwikkelaar; platform voor agents |
| 5. Monitoring en bewijs | Laat zien dat de controles blijven werken | Maandelijkse metingen, reviewverslagen, merge-historie | RV · PO | CTO rapporteert; directie beoordeelt |
Bouw de componenten in deze volgorde. Wie een governancetool koopt voordat het beleid er is, dwingt regels af waarover niemand het eens werd.
Welke zes beslissingen neemt een AI-codeerbeleid?
Het AI-codeerbeleid — de eerste van de vijf componenten — neemt zes beslissingen: welke tools zijn goedgekeurd, welke gegevens in prompts mogen, wie wijzigingen mag samenvoegen, hoe diep de review gaat naar risico, hoe nieuwe afhankelijkheden worden goedgekeurd, en hoe wijzigingen met AI-hulp worden vastgelegd. Zes regels van één zin passen op één pagina die een team van 10 ontwikkelaars vanaf de volgende werkdag kan volgen.
| Beslissing | Wat u beslist | Voorbeeldregel voor een team van 10 ontwikkelaars |
|---|---|---|
| 1. Goedgekeurde tools | Welke tools, waar ze gegevens verwerken, onder welke voorwaarden | “Alleen tools van de lijst: cloudtools met een verwerkersovereenkomst en training uitgeschakeld; zelfgehoste modellen alleen op bedrijfsinfrastructuur.” |
| 2. Gegevens in prompts | Welke gegevens nooit in een prompt gaan | “Geen persoonsgegevens, productielogs, sleutels of wachtwoorden in cloudtools; geen klantcode zonder schriftelijke toestemming.” |
| 3. Goedkeuringsrechten | Wie productiewijzigingen goedkeurt | “Eén menselijke goedkeurder die de wijziging niet schreef; agents keuren nooit hun eigen werk goed.” |
| 4. Reviewdiepte naar risico | Welke code extra review krijgt | “Betalingen, authenticatie, rechten en persoonsgegevens krijgen een tweede reviewer.” |
| 5. Afhankelijkheden en licenties | Hoe nieuwe pakketten binnenkomen | “Nieuwe pakketten vragen goedkeuring van de tech lead, een bestaanscheck en een licentiecheck.” |
| 6. Herleidbaarheid | Hoe wijzigingen met AI-hulp worden gemarkeerd | “De pull request vermeldt welke AI-tool of agent is gebruikt en voor welk deel.” |
Beslissing 2 heeft een juridische kant. Als de leverancier van een cloud-AI-tool persoonsgegevens namens u verwerkt, vereist artikel 28 van de AVG (GDPR) een overeenkomst met die verwerker; klantgegevens in een tool plakken zonder zulke voorwaarden schept een verwerkingsrelatie die niemand heeft getekend.
Beslissing 3 en 4 leggen twee niveaus van menselijke review vast. De basisreview geldt voor elke wijziging: één menselijke goedkeurder die de wijziging niet schreef. De aanvullende review geldt alleen voor code met een hoog risico: een tweede reviewer voor betalingen, authenticatie, rechten en persoonsgegevens. Hoe u AI-gegenereerde code laag voor laag reviewt, en welk bewijs een pull request vóór het samenvoegen nodig heeft, staat in onze gids over AI code review.
Geen van de zes regels verbiedt AI-tools; elke regel vertelt ontwikkelaars waar AI-gebruik veilig is. Wij raden aan alle zes te publiceren voordat de eerste coding agent schrijfrechten krijgt, omdat regels die pas na het ontstaan van gewoontes komen moeilijker te handhaven zijn.
Welke controles heeft door AI geschreven code nodig per leveringspoort?
Door AI geschreven code heeft één extra controle nodig op elk van zes leveringspoorten — editor, commit, pull request, CI, release en productie — bovenop de beveiligingscontroles die uw bestaande DevSecOps-pipeline al uitvoert. De basispipeline blijft zoals hij is; Tabel 4 noemt alleen wat AI verandert.
| Poort | Toevoegen als AI de code schrijft | Waarom |
|---|---|---|
| Editor | Goedgekeurde toolinstellingen; een projectregelbestand dat de assistent de conventies en verboden patronen van het team geeft | AI-output volgt de codebase in plaats van generieke voorbeelden |
| Commit | Secret scanning op door AI voorgestelde configuratie en voorbeeldcode | Assistenten kopiëren placeholders en echte sleutels uit de context |
| Pull request | AI-regel; verplichte menselijke goedkeurder die auteur noch agent is | Herkomst en functiescheiding bij elke wijziging |
| CI | Bestaans- en licentiecheck voor nieuw toegevoegde pakketten; tests voor de wijziging die niet door dezelfde AI-sessie zijn geschreven | Vangt verzonnen pakketten en tests die de code alleen bevestigen |
| Release | Wijzigingsrecord dat wijzigingen met AI-hulp in risicogebieden markeert | De release-goedkeurder ziet waar reviewdiepte telt |
| Productie | Change fail rate apart gevolgd voor services met veel AI-code | Laat zien of de controles standhouden na de release |
Het DORA AI Capabilities Model van Google (10 december 2025) noemt sterk versiebeheer en werken in kleine batches onder zijn zeven vaardigheden; beide maken poortcontroles goedkoop. Automatiseer elke regel die een machine objectief kan toetsen — bestaan van pakketten, licentielijsten, verplichte goedkeurders — en houd menselijke review voor regels die productkennis vragen, zoals of klant A de gegevens van klant B kan zien.
Weet wat er al in de codebase zit voordat u AI-tools en agents opschaalt.
Controles sturen de volgende wijziging; ze zeggen niets over de code die AI-tools al hebben geschreven. Een review van AI-gebouwde software geeft u die nulmeting: een reviewer die de code niet schreef, beoordeelt code, productgedrag en technische opzet, en levert de bevindingen in begrijpelijke taal met een geprioriteerd actieplan — zodat u weet welke controles u als eerste aanzet.
Hoe bestuurt u AI coding agents?
Bestuur AI coding agents als niet-menselijke bijdragers: elke agent krijgt een eigen identiteit, alleen de rechten die hij nodig heeft, een afgebakende reikwijdte en een menselijke goedkeurder voor elke wijziging. In de Stack Overflow Developer Survey 2025 zei 81% van de respondenten zorgen te hebben over de beveiliging en privacy van gegevens bij het gebruik van AI-agents, en had 87% zorgen over de nauwkeurigheid van hun output.
| Controle | Regel |
|---|---|
| Identiteit | Elke agent draait onder een eigen serviceaccount, nooit met het persoonlijke token van een ontwikkelaar. |
| Rechten | Minimale rechten op repositories en omgevingen; geen beheer- of omzeilrechten (ISO/IEC 27001:2022 Annex A 8.2, bevoorrechte toegangsrechten). |
| Reikwijdte | Toegestane repositories en mappen staan vast; code rond betalingen, authenticatie en rechten alleen samen met een mens. |
| Goedkeuring | Een agent keurt nooit zijn eigen pull request goed of voegt die samen; een benoemde mens keurt goed. |
| Uitvoering | Agents draaien in een sandbox zonder productiesleutels of productiegegevens. |
| Volume | Een maximum aan open pull requests per agent houdt de reviewwachtrij binnen de capaciteit van reviewers. |
| Audit | Elke actie van een agent — branch, commit, toolaanroep — wordt gelogd en bij de merge-historie bewaard. |
Laat agents beginnen met werk met een laag risico, zoals testopzet, documentatie en updates van afhankelijkheden. Verruim hun reikwijdte zodra pull requests van agents over een vooraf vastgelegde periode een change fail rate laten zien die niet hoger is dan die van het team zelf. Wij raden twee maandelijkse metingen aan als startpunt, omdat één maand zelden genoeg agentwijzigingen bevat om trend van ruis te onderscheiden; pas de periode aan op uw releasefrequentie. Een mislukte agentwijziging in code rond betalingen, authenticatie of persoonsgegevens is een incident, geen trend: draai haar terug en zet de agent voor dat gebied direct stil.
Wie is eigenaar van AI code governance?
De CTO is eindverantwoordelijk voor AI code governance: de directie keurt het AI-codeerbeleid goed, teamleads voeren de controles uit, een security lead adviseert waar het bedrijf er een heeft, elke ontwikkelaar staat in voor de eigen wijzigingen, en een onafhankelijke reviewer geeft het oordeel vóór grote releases. Die verdeling volgt functiescheiding uit ISO/IEC 27001:2022 Annex A 5.3: wie een wijziging maakt, is niet de enige die haar goedkeurt.
| Activiteit | COO / founder | CTO | Security lead | Teamleads | Ontwikkelaars | Onafh. reviewer |
|---|---|---|---|---|---|---|
| Het AI-codeerbeleid goedkeuren | A | R | C | C | I | C |
| De lijst met goedgekeurde tools bijhouden | C | A | C | R | I | – |
| Poort- en agentcontroles instellen | I | A | C | R | I | – |
| Wijzigingen in productiecode goedkeuren | – | I | – | A | R | – |
| De regel voor gegevens in prompts naleven | I | A | C | C | R | – |
| Review vóór een grote release | I | A | C | R | C | R |
| Beveiligingsvragenlijsten van klanten beantwoorden | C | A | R | C | – | C |
Is één persoon founder, CTO en enige ontwikkelaar tegelijk, dan is de onafhankelijke reviewer de enige functiescheiding die er is — plan die review vóór de eerste betalende klanten, niet na het eerste incident.
Hoeveel AI code governance heeft uw team nodig?
De juiste hoeveelheid AI code governance volgt drie triggers: teamgrootte, type klant en type gegevens. Ga in Tabel 7 een rij omhoog zodra één daarvan verandert — een tweede ontwikkelaar, een zakelijke klant, persoons- of betaalgegevens, of de eerste coding agent. In de Stack Overflow Developer Survey 2025 gebruikte 13,8% van de respondenten AI alleen als copilot of autocomplete, terwijl 14,1% dagelijks AI-agents gebruikte.
| Fase | Typische opzet | Minimale governance | Omhoog wanneer |
|---|---|---|---|
| Solo-founder | Eén persoon, AI-appbouwer of assistent | Goedgekeurde tool, regel voor gegevens in prompts, onafhankelijke review vóór livegang | Eerste betalende klanten of persoonsgegevens |
| 2–5 ontwikkelaars | Dagelijks gebruik van AI-assistenten | Zes beslissingen op één pagina, verplichte goedkeurder, secret scanning | Zakelijke klant of extern team |
| 6–50 ontwikkelaars of een extern team | Meerdere teams of leveranciers aan één product | Alle vijf componenten, poortcontroles, eigenaarschapstabel, maandelijkse metingen | Eerste coding agent krijgt schrijfrechten |
| Coding agents in productiegebruik | Agents openen zelf pull requests | Agentcontroles uit Tabel 5 bovenop alle vijf componenten | — |
Vibe coding governance voor een solo-founder
Vibe coding governance is de minimale set regels voor een founder die met een AI-appbouwer werkt en de code niet leest. Drie regels volstaan: een tool waarvan u de gegevensvoorwaarden hebt gecontroleerd, geen klantgegevens of sleutels in prompts, en een onafhankelijke review voordat echte gebruikers komen — de enige controle die niet op het eigen oordeel van de founder leunt.
Welke knelpunten komen teams tegen bij AI code governance, en hoe lost u ze op?
Vijf knelpunten komen terug in de meeste engineeringteams die AI code governance invoeren: schaduw-AI, weerstand bij ontwikkelaars, ontbrekende herkomst, ontbrekende context in AI-output en agents die sneller gaan dan de review. Ontbrekende context wordt het vaakst onderschat: in de Stack Overflow Developer Survey 2025 zei 45% van de ontwikkelaars dat het debuggen van AI-gegenereerde code meer tijd kost.
| Knelpunt | Signaal | Oplossing |
|---|---|---|
| Schaduw-AI | Tools in gebruik die niet op de goedgekeurde lijst staan; persoonlijke accounts op bedrijfscode | Keur een tool goed die ontwikkelaars willen gebruiken, met gecontroleerde voorwaarden; een verbod maakt gebruik alleen onzichtbaar |
| Weerstand bij ontwikkelaars | Reviewwachtrijen groeien; ontwikkelaars omzeilen controles om te kunnen leveren | Automatiseer objectieve controles zodat de basisreviewer zich op de logica kan richten; voeg de tweede, aanvullende review alleen toe voor code met een hoog risico (beslissing 4) |
| Ontbrekende herkomst | Niemand kan zeggen hoe een fout in de code kwam | AI-regel afgedwongen via het pull-requestsjabloon; agents onder een eigen identiteit |
| Ontbrekende context | AI-code slaagt voor de tests maar breekt een bedrijfsregel of een architectuurgrens | Projectregelbestand voor de assistent; een reviewer met domeinkennis toetst de bedrijfslogica |
| Agents sneller dan review | Pull requests van agents wachten dagen of worden ongelezen samengevoegd | Maximum aan open pull requests per agent; agents alleen op werk met een laag risico |
Gelden twee of meer signalen uit Tabel 8 tegelijk, pak dan eerst schaduw-AI aan: governance kan geen tools dekken waarvan het bedrijf het bestaan niet kent.
Welke EU-eisen en beveiligingsnormen doen ertoe?
Geen enkele EU-wet regelt door AI geschreven code als zodanig. Drie EU-wetten en één vrijwillige norm zijn relevant voor AI code governance, en of elk daarvan geldt, hangt af van de rol, sector en gegevens van uw bedrijf, niet van de manier waarop de code is geschreven. De wetten leggen verplichtingen op maar schrijven geen vorm van bewijs voor; Tabel 9 houdt de eis gescheiden van het governancebewijs dat bedrijven vaak zelf kiezen te bewaren.
| Eis | Soort | Wanneer van toepassing | Wat de eis vraagt | Governancebewijs dat bedrijven vaak bewaren |
|---|---|---|---|---|
| AI-verordening artikel 4 (AI-geletterdheid) | EU-verordening | Sinds 2 februari 2025, voor aanbieders en gebruiksverantwoordelijken van AI-systemen; een bedrijf dat beroepsmatig AI-tools gebruikt, is in de regel gebruiksverantwoordelijke. Gewijzigd door de Digital Omnibus on AI in 2026 | Maatregelen nemen om de AI-geletterdheid te ondersteunen van medewerkers die AI-systemen gebruiken; geen gegarandeerd niveau en geen voorgeschreven vorm | Overzicht van training of instructie voor gebruikers van AI-tools; het AI-codeerbeleid |
| AVG (GDPR) artikel 28 | EU-verordening | Als een toolleverancier persoonsgegevens namens u verwerkt | Een overeenkomst met de verwerker die de verwerkingsvoorwaarden vastlegt | Lijst met goedgekeurde tools en verwerkersovereenkomsten; regel voor gegevens in prompts |
| NIS2 artikel 20 en artikel 21(2)(d)–(e) | EU-richtlijn; in Nederland de Cyberbeveiligingswet | Essentiële en belangrijke entiteiten in de sectoren van NIS2-bijlage I en II, in de regel middelgroot en groter; leveranciers buiten de reikwijdte krijgen ermee te maken via klantcontracten | Het bestuur keurt cyberbeveiligingsmaatregelen goed en houdt er toezicht op; beveiliging van de toeleveringsketen; beveiliging bij ontwikkeling en onderhoud | Door het bestuur goedgekeurd AI-codeerbeleid; eigenaarschapstabel |
| ISO/IEC 27001:2022 | Vrijwillige norm — geen wet | Als uw bedrijf gecertificeerd is, of een klantcontract het eist | Een managementsysteem voor informatiebeveiliging met Annex A-beheersmaatregelen gekozen op basis van risicoanalyse | Beleid en reviewverslagen als input voor het ISMS |
In Nederland geldt NIS2 via de Cyberbeveiligingswet, die op 15 augustus 2026 in werking is getreden (Staatsblad 2026, 187 en 189). Bedrijven buiten de reikwijdte krijgen er via hun klanten toch mee te maken: klanten binnen de reikwijdte moeten op grond van NIS2-artikel 21(2)(d) de beveiliging van hun toeleveringsketen regelen en stellen die vragen door aan hun softwareleveranciers.
Welke ISO/IEC 27001 Annex A-maatregelen en OWASP-standaarden gelden voor door AI geschreven code, hoe AVG-artikel 32 daarin past en welk beveiligingsbewijs u een auditor laat zien, staat in onze gids over beveiligingsstandaarden voor AI-gegenereerde code. Sunbytes levert zelf onder een ISO 27001-gecertificeerd managementsysteem voor informatiebeveiliging. Laat de reikwijdte toetsen door uw juridisch adviseur: Tabel 9 vat eisen samen, maar beslist niet of elke eis voor uw bedrijf geldt.
Welke vijf metingen laten zien dat AI code governance werkt?
Vijf metingen laten zien of AI code governance werkt, en elke meting komt uit gegevens die de codehost, de scanners of het laatste reviewverslag al opleveren.
- Aandeel onafhankelijke goedkeuring: het deel van de productiewijzigingen dat is goedgekeurd door iemand anders dan de auteur of een agent (basisreview), en het deel van de wijzigingen met een hoog risico dat ook een tweede reviewer had (aanvullende review). Doel: voor beide 100%.
- Sleutels in de hoofdbranch: sleutels of wachtwoorden die de scanner na het samenvoegen vindt. Doel: nul per maand.
- Toolkloof: gebruikte AI-tools en agents vergeleken met de goedgekeurde lijst. Doel: geen verschil.
- Change fail rate: een van de vijf metingen in DORA’s software delivery performance metrics, gedefinieerd als “the ratio of deployments that require immediate intervention following a deployment”. Doel: services met veel AI-code scoren niet slechter dan de rest.
- Openstaande reviewbevindingen: bevindingen met hoge prioriteit uit de laatste review die nog openstaan. Doel: gesloten vóór de volgende release.
Behandel incidenten en trends verschillend. Een incident — een sleutel in de hoofdbranch, een wijziging samengevoegd zonder onafhankelijke goedkeurder, een agent die buiten zijn reikwijdte handelt — wordt dezelfde dag opgelost en wacht niet op een overleg. Trends bespreekt u maandelijks; wij raden aan de bijbehorende regel aan te scherpen als een meting in twee opeenvolgende besprekingen de verkeerde kant op gaat, wat eenmalige uitschieters wegfiltert zonder een echte daling een kwartaal te laten doorlopen. Teams met weinig releases kunnen een langere periode nemen. Het zakelijke resultaat is voorspelbare onderhoudskosten, zoals onze gids over de kosten van een AI-app laat zien.
Hoe rolt u AI code governance uit in 30 dagen?
Een engineeringteam kan AI code governance in 30 dagen uitrollen, met één stap per week en met de codehost en scanners die het al heeft. Week 1 en 2 dekken de NIST SSDF-groep Prepare the Organization (PO); week 3 en 4 dekken Protect the Software (PS) en Produce Well-Secured Software (PW).
| Week 1 — Inventaris | Breng per team, repository en abonnement in kaart welke AI-tools en agents worden gebruikt, en waar prompts worden verwerkt. |
| Week 2 — Beleid | Leg de zes beslissingen vast op één pagina; de directie keurt goed; teamleads informeren ontwikkelaars en leveranciers. |
| Week 3 — Controles | Zet verplichte goedkeurders, secret scanning en pakketcontroles aan; voeg de AI-regel toe aan het pull-requestsjabloon; maak aparte accounts voor agents. |
| Week 4 — Nulmeting | Laat de code die al met AI-tools is geschreven reviewen door iemand die haar niet schreef; onze gids over een AI code audit legt de reikwijdte uit. |
Vindt week 4 problemen in code rond betalingen, authenticatie of persoonsgegevens, los die dan op voordat u het gebruik van AI of agents verruimt.
Hoe Sunbytes u helpt AI code governance in de praktijk te brengen
AI code governance is zo sterk als het bewijs erachter: controles die draaien, reviewverslagen die een klant kan lezen, en bevindingen die echt zijn opgelost.
Sunbytes levert de bewijskant met een review van AI-gebouwde software. Wij bakenen af wat er is gebouwd en wie het gebruikt, beoordelen de afgesproken onderdelen van code, productgedrag en technische opzet, en scheiden wat nu aandacht vraagt van wat kan wachten. De reviewer heeft de code niet geschreven, en u krijgt de bevindingen in begrijpelijke taal met een geprioriteerd actieplan. Uw team kan elke bevinding gebruiken om te zien waar een beleidsregel ontbreekt of een poortcontrole een probleem niet opving, en te bepalen welke van de zes beslissingen het eerst moet worden aangescherpt.
Raken de bevindingen toegangsbeheer of persoonsgegevens, dan voegt ons cybersecurityteam de beveiligingsmaatregelen en het bewijs toe waar NIS2- en ISO 27001-vragenlijsten van leveranciers om vragen. Uw team herstelt de bevindingen, of Sunbytes herstelt de prioritaire punten en controleert ze opnieuw. Het werk verloopt onder Nederlandse regie, met meer dan 15 jaar ervaring in softwarelevering en ruim 300 opgeleverde projecten.
→ Bespreek uw AI-gebouwde product met ons, dan bakenen wij de review af rond de governance die u uitrolt.
