Is de code die AI schrijft veilig? Wat de onafhankelijke studies zeggen — en wat u ervan in het contract zet

Wanneer een mkb-bedrijf een leverancier beoordeelt die met AI ontwikkelt, gaat de vraag bijna altijd over kwaliteit: „zie je dat het door een machine geschreven is?”. Dat is de minst nuttige vraag. Over waargenomen kwaliteit kun je eindeloos discussiëren, en je verhelpt het met een review. Het serieuze risico, dat wat het onafhankelijke bewijs werkelijk meet, is een ander: de veiligheid. En dat risico heeft een onaangename eigenschap — je ziet het niet bij de oplevering, je ziet het maanden later, wanneer het van u is.

De onafhankelijke academische studies die tussen 2022 en 2026 zijn gepubliceerd, zeggen drie verschillende dingen, en geen van de drie is „AI schrijft onveilige code, gebruik het dus niet”. Ze zeggen dat een aanzienlijk deel van de gegenereerde code kwetsbaar ter wereld komt; dat de weigeringen van een model in de chat niet overleven zodra ze in een echte werkstroom belanden; en dat de agentische automatisering van de pipeline een aanvalsoppervlak opent dat al wordt misbruikt. Drie dingen die een koper in het contract kan zetten — of achteraf kan ontdekken.

1. Een deel van de gegenereerde code komt kwetsbaar ter wereld

Het referentiecijfer stamt uit 2022 en is academisch, niet van een leverancier. Pearce en collega's lieten GitHub Copilot 1.689 programma's genereren over 89 scenario's die rond de meest voorkomende zwakheden waren gebouwd, en vonden dat ongeveer 40% van de gegenereerde programma's een kwetsbaarheid bevatte (Pearce et al., „Asleep at the Keyboard?”, IEEE S&P 2022). Niet op code die bedacht was om de tool voor schut te zetten: op alledaagse scenario's, van het soort dat een bedrijf elke week uitbesteedt.

Er circuleert ook een uitsplitsing per taal — rond de 50% in C tegenover 39% in Python. We noemen die met een expliciet voorbehoud, want zo hoort ze geciteerd te worden: die uitsplitsing komt uit secundaire samenvattingen van de studie en we hebben haar niet geverifieerd tegen het oorspronkelijke document. Het getal om op te leunen is het totaalcijfer. En de juiste lezing is niet „40% van de opgeleverde software is lek”: het is dat een generator uit zichzelf geen enkele reden heeft om veilige code te produceren. Veiligheid is geen eigenschap die vanzelf uit de generatie ontstaat. Het is een controle die iemand er omheen moet zetten.

2. De weigering in de chat overleeft de werkstroom niet

Hier zit het meest recente en meest ongemakkelijke resultaat, en het is precies wat de standaard geruststelling van de leverancier onderuithaalt („geen zorgen, dat soort dingen weigert het model te schrijven”). Een groep van het Alan Turing Institute nam 204 kwaadaardige verzoeken en legde ze op twee manieren voor aan GitHub Copilot Chat. In directe chat weigerde het model 808 van de 816 keer. Dezelfde verzoeken, opgeknipt en ingebracht in een gewone werkstroom over meerdere beurten in de editor, leverden 816 van de 816 keer een kwaadaardige completion op (Kumar & Maple, „Refused in Chat, Written in Code”, 2026).

Het punt is niet „Copilot Chat geeft gevaarlijke code terug”. Het punt is dat de bescherming op gespreksniveau leeft terwijl het echte werk op werkstroomniveau gebeurt: het verzoek opbouwen over meerdere stappen van een doodgewone ontwikkeltaak omzeilt een weigering die, frontaal bevraagd, bijna altijd werkt. Een controle op de verkeerde plek is in de praktijk een controle die er niet is.

Voor wie software koopt is dat een precieze consequentie, geen detail voor onderzoekers: de veiligheid van het model is geen garantie die u van de modelleverancier kunt erven. Ze moet geverifieerd worden in het proces van degene die u de code oplevert — met tooling die het resultaat leest, niet de goede bedoelingen van wie erom vroeg.

3. Meer gegenereerde code, een luidruchtiger pipeline (een correlatie, geen oorzaak)

De derde studie kijkt naar wat er stroomafwaarts gebeurt, in de build- en releaseketen. Er werden 61.837 CI-uitvoeringen over 2.355 repository's geanalyseerd, aangestoten door vijf verschillende AI-programmeerbots: Copilot en Codex tonen de hoogste slagingspercentages (rond de 93-94%), de andere lagere. Het interessante gegeven is echter een ander: in de repository's met een hogere frequentie van door AI gegenereerde pull requests ziet men een lager totaal slagingspercentage van de workflows („Reliability of AI Bots Footprints in GitHub Actions CI/CD Workflows”, 2026).

Het is een correlatie, en dat moet duidelijk gezegd worden: de studie bewijst niet dat door AI gegenereerde PR's de pipeline doen falen. Het kan heel goed zijn dat de projecten die het meest aan AI blootstaan ook de drukste zijn. Maar voor wie moet beslissen blijft het bruikbare informatie: een hoog volume aan automatische bijdragen gaat gepaard met een luidruchtiger buildsignaal, en een luidruchtige pipeline is precies de plek waar een echte failure ophoudt op te vallen. Wie een leverancier beoordeelt, zou niet moeten vragen „gebruikt u AI?”, maar „hoeveel groen haalt uw pipeline, en wie kijkt er naar de rode?”.

4. De pipeline zelf is doelwit geworden

Het vierde element hebben we elders al uitvoerig verteld, dus hier volstaat de regel: wanneer agents de workflows schrijven en draaien, wordt de workflow zelf aanvalsoppervlak, met honderden bevestigd misbruikbare injection-kwetsbaarheden op echte repository's (arXiv:2605.07135) — de ontleding staat in ons artikel over wat er echt werkt van AI in de ontwikkeling. Naast de drie voorgaande gezet, maakt het het beeld compleet: het risico zit niet alleen in de opgeleverde code, het zit ook in wat de automatisering namens u mag uitvoeren.

Wat u in het contract schrijft (niet wat u hoopt)

Al het bovenstaande vertaalt zich in clausules, niet in wantrouwen. Geen ervan vraagt technische kennis om te kunnen eisen, en alle zijn verifieerbaar:

• Wie reviewt, en vóór wat. Leg schriftelijk vast dat elke wijziging langs een identificeerbare menselijke review gaat vóór de release, en dat automatische goedkeuring niet is toegestaan op de gevoelige paden (authenticatie, betalingen, persoonsgegevens). Niet „we doen aan code review”: wie tekent, en op welke paden de poort nooit vanzelf opengaat.
• Statische analyse en secrets-scanning als verplichting, niet als goede gewoonte. Een automatische kwetsbaarheidsanalyse (SAST) en het scannen op secrets draaien op elke wijziging, met de uitkomst bijgevoegd bij de oplevering. Het is de controle die rechtstreeks antwoordt op de 40% van Pearce en op het probleem van de omzeilde weigering: verifieer het resultaat, niet de intentie.
• Wie een na de oplevering gevonden kwetsbaarheid bezit. Dat is de clausule die vrijwel altijd ontbreekt. Definieer een aansprakelijkheidsvenster, de hersteltermijnen per ernstgraad en wie betaalt: zonder dat valt de kosten van die 40% volledig op u terug, maanden nadat u de oplevering hebt afgetekend.
• Wat de pipeline mag uitvoeren. Welke automatiseringen toegang hebben tot de productiecredentials, welke zelfstandig wijzigingen mogen openen en integreren, en wat een menselijke handeling vereist. Als de automatisering code tot in productie kan bewegen zonder een handtekening, is de veiligheidsperimeter niet wat u denkt.
• Waar uw code terechtkomt. Welke AI-tools op uw repository worden gebruikt, of de code de training van derden voedt en hoe de secrets in de ontwikkelomgeving worden beheerd. Het zijn dezelfde vragen die u aan elke SaaS-leverancier stelt — we hebben ze hier verzameld.

Geen van deze clausules verbiedt AI. Alle verplaatsen ze het risico naar waar het beheerd kan worden: naar het proces van de leverancier, vóór de oplevering, in plaats van naar uw balans daarna.

Ons standpunt, van binnenuit gezegd

Wij schrijven de code elke dag met AI, op deze site en op onze eigen producten — en juist daarom lijkt ons proces sterk op de lijst hierboven: elke wijziging doorstaat een reeks groene controles, een menselijke review vóór de release en automatiseringen met expliciete, beperkte rechten, zonder shortcuts op de kritieke paden. Dat is geen voorzichtigheid uit een brochure: het is de infrastructuur die de snelheid van AI omzet in een blijvend voordeel in plaats van in een veiligheidsschuld die later betaald moet worden. Een leverancier die deze controles al heeft moeten bouwen, zegt u dat; wie alleen de demo verkoopt, nog niet.

De beslissing die genomen moet worden

Het is geen „AI ja of AI nee”. Het is één enkele vraag, en die hoort vóór de ondertekening gesteld te worden: welke van deze clausules staan al in het contract dat u op het punt staat te accepteren? Als het antwoord geen enkele is, is het probleem niet de tool die uw leverancier gebruikt — het is dat het veiligheidsrisico op dit moment volledig van u is en nergens is opgeschreven.

Beoordeelt u een leverancier, of staat u op het punt AI uw ontwikkeling binnen te halen, dan zijn de controles die we aan elke workflow vasthaken — inclusief die voor compliance — beschreven in onze compliance-overlay. En om te begrijpen bij welke afdeling u het beste begint, met welke controles eromheen, hebben we de eerste stap omgezet in een self-service en gratis beoordeling: doe de AI-readiness-beoordeling — daarna, als het zinvol is, praten we erover.

Dit artikel is bedoeld ter oriëntatie. De genoemde cijfers komen uit onafhankelijke academische studies, uitgevoerd op specifieke tools en in specifieke periodes: lees ze als richtingaanwijzers over het type risico, niet als een maat voor de code die u zult ontvangen. De uitsplitsing per taal van de studie uit 2022 is afkomstig uit secundaire samenvattingen en niet geverifieerd tegen het oorspronkelijke document. Deze tekst vormt geen juridisch advies en evenmin een veiligheidsbeoordeling: elk contract moet worden beoordeeld op de context van het individuele bedrijf.