Is AI-code veilig? De echte risico's en wat review verandert

Ja, zodra een gekwalificeerde engineer elke regel reviewt, de code test en de dependencies controleert. Nee, rechtstreeks uit het model. Het verschil is niet de AI. Het is of iemand het werk heeft gecontroleerd voordat je bedrijf ervan afhankelijk werd.

Dit antwoord is kort met opzet, want de vraag verdient eerst een eerlijk antwoord. De rest is de lange versie: wat er echt misgaat wanneer AI-gegenereerde code zonder review live gaat, wat een echt reviewproces vangt, en wat je een leverancier moet vragen voordat je het hem toevertrouwt. Kom je van onze bredere uitleg over vibe coding en AI-ondersteunde ontwikkeling, dan is dit de verdieping van een vraag die daar maar één alinea krijgt.

De eerlijke risicolijst: wat er misgaat in niet-gereviewde AI-code

Een AI-model kent je bedrijf niet, en het draagt geen enkele consequentie als het iets fout doet. Het voorspelt code die er plausibel uitziet op basis van patronen in zijn trainingsdata, en "ziet er plausibel uit" is niet hetzelfde als "correct" of "veilig". Vier faalmodi duiken keer op keer op in code die niemand heeft gereviewd.

Beveiligingskwetsbaarheden. Grote taalmodellen zijn onder meer getraind op grote hoeveelheden publieke code, en gegenereerde output kan daardoor patronen en fouten bevatten; de precieze trainingsdata en herkomst verschillen per model. Het 2025 GenAI Code Security Report van Veracode constateerde dat 45% van de AI-gegenereerde codevoorbeelden bekende beveiligingskwetsbaarheden bevatte, waaronder ontbrekende invoervalidatie, injectiegevoelige queries en hardcoded inloggegevens; dat cijfer beschrijft de tests van dat rapport en is geen algemene foutprevalentie voor alle AI-code. Geen van deze bugs is exotisch: het gaat vaak om bekende beveiligingsproblemen, gegenereerd op een tempo dat geen mens ooit haalde. Voor een Nederlands of Vlaams bedrijf stopt de rekening niet bij het technische incident: als een beveiligingslek tot een datalek met persoonsgegevens leidt, moet de organisatie het risico voor de rechten en vrijheden van betrokkenen beoordelen. Een melding aan de Autoriteit Persoonsgegevens (AP) in Nederland of de Gegevensbeschermingsautoriteit (GBA) in België is in beginsel vereist wanneer dat risico waarschijnlijk is; bij een meldplicht geldt volgens het NCSC een termijn van 72 uur, en wordt het dossier net zo juridisch als technisch.

Gehallucineerde dependencies. Vraag een AI-model om een probleem op te lossen en het beveelt soms een softwarepakket aan dat niet bestaat. Het lijkt op een normale import-instructie, het leest als plausibel, en het is fictief. Een USENIX Security-studie uit 2025 analyseerde 576.000 codevoorbeelden en mat dat gemiddeld minstens 5,2% van de door commerciële modellen voorgestelde pakketten gehallucineerd was, tegenover ongeveer 21,7% voor open-sourcemodellen. Dit kan een supply-chainrisico creëren: aanvallers zouden een gehallucineerde pakketnaam kunnen registreren om ontwikkelaars te misleiden, zodat de volgende developer die de importfout "oplost" in plaats daarvan malware installeert. De studie toont het bestaan en de omvang van pakket-hallucinaties, maar levert geen bewijs dat elke genoemde naam daadwerkelijk al is geregistreerd of dat zulke aanvallen in elk concreet geval zijn uitgevoerd. Beveiligingsonderzoekers noemen dit fenomeen inmiddels slopsquatting, en niet-gereviewde vibe coding-sessies zijn de natuurlijke habitat ervan.

Subtiele logicafouten. Niet elke storing kondigt zich aan met een crash. Een kortingsberekening die de verkeerde kant op afrondt bij het omrekenen van excl. naar incl. btw, een datumfilter dat stilletjes de laatste dag van de maand weglaat, een rechtencheck die werkt voor elke rol behalve die ene die niemand testte: deze bugs gaan onopgemerkt live, draaien wekenlang, en komen pas boven wanneer een klant merkt dat het totaal niet klopt. Een AI-model kan zulke contextafhankelijke logicafouten missen, vooral wanneer de vereisten en tests onvolledig zijn, want het heeft al een antwoord geproduceerd dat af lijkt.

Onderhoudsschuld. Code die niemand begrijpt is een last, ook als hij vandaag werkt. AI-gegenereerde code kan duplicatie of moeilijk te onderhouden logica introduceren, omdat elke prompt een nieuw antwoord krijgt zonder geheugen van wat de codebase al bevat; zonder passende tests en review kunnen latere wijzigingen daardoor extra risico's opleveren. Bij een wijziging op één plek kan iets zonder duidelijk verband breken, en het team dat debugt heeft geen auteur aan wie het kan vragen waarom de oorspronkelijke code deed wat hij deed.

Niets hiervan is een argument tegen door AI geschreven code. Elk van deze vier problemen is precies wat een reviewstap moet vangen, en geen enkel vereist exotische tooling: gewoon een mens die het resultaat leest voordat het live gaat.

Wat verandert er wanneer AI-gegenereerde code wordt gereviewd

Gereviewde, AI-ondersteunde code is een ander product dan vibe-gecodeerde output, ook als hetzelfde model beide schreef. Twee praktijken doen het echte werk.

Een menselijke engineer leest elke regel. Geen steekproef, niet de stukken die "er risicovol uitzien": elke regel, voordat die wordt gemerged. Architectuurbeslissingen, beveiligingsgrenzen en randgevallen blijven reviewbeslissingen, nooit geaccepteerd op het woord van het model. Deze ene stap onderschept de hardcoded sleutel, de ontbrekende validatie en de import die naar een niet-bestaand pakket wijst. Onze eigen versie van deze praktijk, sprint na sprint, staat volledig beschreven in hoe we werk inplannen, bouwen en reviewen.

Dependency-scanning draait bij elke build. Elke push en elke pull request triggert een geautomatiseerde dependency-scan, Dependabot plus een dependency-audit in de CI-pipeline, zodat een pakket met een bekend beveiligingsadvies van matig of hoger niveau de build laat falen in plaats van de productie te bereiken. Daar wordt een gehallucineerde of gecompromitteerde dependency onderschept, ook als een reviewer die in de diff heeft gemist.

Één ding verdient het om ronduit gezegd te worden, want leveranciers zijn dat niet altijd. We bieden geen penetratietest aan in een standaardbuild. Heeft een project een onafhankelijke beveiligingsevaluatie nodig, dan benoemen we dat bij de scoping en helpen we die te regelen, dezelfde openheid die onze security-paginavolledig laat zien.

Die openheid is het kernpunt. Een leverancier die je precies vertelt welke controles draaien, en welke niet, is een leverancier van wie je de andere beweringen kunt geloven. Een leverancier die zwaait met "beveiliging op enterpriseniveau" zonder één praktijk te noemen, vraagt je om dezelfde sprong in het diepe die een niet-gereviewd AI-model al neemt op zijn eigen output.

Hoe beoordeel je de echte beveiligingspraktijken van een leverancier

Elk AI-ontwikkelbureau zal je vertellen dat zijn code veilig is. Weinigen kunnen beschrijven hoe ze dat weten. Neem deze vragen mee naar een scopinggesprek en luister naar details, niet naar bijvoeglijke naamwoorden.

• Wie leest de code, en wanneer? Je wilt een benoemde rol (een senior engineer, niet "het team") en een fase (vóór de merge, niet "ooit"). "Ons proces reviewt het" is geen antwoord; "een engineer leest elke regel vóór de merge" wel.
• Welke tools draaien bij elke build, en wat controleren ze echt? Dependency-scanning is gangbaar en verifieerbaar: vraag welke tool, en of een gefaalde controle een release blokkeert of alleen een waarschuwing logt.
• Wat doen jullie niet? Een leverancier die zijn grenzen benoemt, geen penetratietest standaard inbegrepen, geen certificering in bezit, wat dat bij hem ook is, vertelt je iets waars. Een leverancier zonder enige grens wordt door niemand gereviewd, jou incluis.
• Van wie is de code na oplevering? Beveiliging en eigendom zijn verwante vragen. Een leverancier die je de volledige code-eigendomtoekent, heeft er geen belang bij een sluiproute te verbergen in een codebase die hij je helemaal overdraagt.
• Waar gaat mijn code heen, en waar staan mijn gegevens? De leverancier stuurt je codebase naar een model dat ergens draait. Vraag welk model, onder welk contract, en of je productiegegevens er ooit doorheen gaan. Een leverancier die het antwoord niet heeft, heeft zijn eigen voorwaarden niet gelezen, en de AVG neemt met dat excuus geen genoegen.
• Mag ik mijn eigen technisch adviseur meenemen naar het gesprek? Een leverancier die zeker is van zijn praktijken verwelkomt een tweede paar ogen. Wie zich tegen het idee verzet, vertelt je ook iets.

Een nuttige verduidelijking, want de verwarring is wijdverbreid en duur. De Europese AI-verordening (AI Act) is niet van toepassing op je software omdat een AI hielp die te schrijven. Ze richt zich op AI-systemen die op de markt worden gebracht: draagt het opgeleverde product zelf een AI-functie, dan valt het in een risicocategorie met de bijbehorende verplichtingen; was de AI slechts een ontwikkeltool, dan blijft je software gewone software in de ogen van de tekst. De AVG geldt in beide gevallen, vanaf het eerste persoonsgegeven. Een leverancier die de twee door elkaar haalt, in welke richting dan ook, verkoopt angst of zorgeloosheid, en geen van beide helpt je.

We bouwden onze eigen security-paginarond precies deze test: benoem de praktijken duidelijk genoeg dat je adviseur ze kan controleren, en zeg helder wat we niet doen. Haal de beweringen van elke leverancier, de onze incluis, door hetzelfde filter.

Rode vlaggen: wanneer een leverancier deze vragen niet kan beantwoorden

Sommige antwoorden zijn erger dan geen antwoord.

"Onze AI schrijft standaard veilige code." Geen enkel model doet dat. Deze bewering weerspreekt de bevinding van Veracode hierboven en elke andere onafhankelijke studie over het onderwerp. Een leverancier die haar herhaalt, heeft het onderzoek niet gelezen, of hoopt dat jij dat niet deed.

Vage geruststelling in plaats van een benoemde praktijk. "Wij nemen beveiliging serieus" en "bescherming op enterpriseniveau" beschrijven niets verifieerbaars. Vraag wat die formuleringen in de praktijk betekenen, en let op of het antwoord preciezer wordt of abstracter.

Certificeringen die niemand kan tonen. "Bankwaardig" en "van militair niveau" zijn marketingtermen, geen normen. Claimt een leverancier ISO 27001, SOC 2 of een vergelijkbare certificering, vraag die dan te zien: een certificaat draagt een instantie, een nummer en een vervaldatum. Kan hij die niet tonen, dan heeft hij die niet. Wees ook op je hoede voor de claim "AVG-proof" die als een keurmerk wordt rondgezwaaid. De AVG certificeer je zo niet; het is een verplichting, geen trofee, en ermee pronken verraadt vaak dat er niet aan is gewerkt.

Geen antwoord op "wat doen jullie niet". Elke echte beveiligingspraktijk heeft een grens. Een leverancier die de zijne niet kan benoemen, is niet veiliger. Hij is minder precies, wat iets anders is, ook al lijkt het erop.

Stilte over wie de output reviewt. Als een leverancier zijn reviewproces niet in één heldere zin kan beschrijven, bestaat het waarschijnlijk niet. Die ene lacune weegt zwaarder dan bijna al het andere op deze lijst, want het is de praktijk waarvan alle andere waarborgen afhangen.

Veelgestelde vragen over de beveiliging van AI-code

Is AI-gegenereerde code veilig om in productie te gebruiken?

Dat kan, zodra een engineer elke regel reviewt, dependencies worden gescand en de software is getest tegen echte acceptatiecriteria. Standaard is hij niet veilig. Niet-gereviewde AI-code gaat regelmatig live met precies de kwetsbaarheden die hierboven staan beschreven.

Wat is het grootste beveiligingsrisico van AI-gegenereerde code?

Ontbrekende of zwakke invoervalidatie en hardcoded inloggegevens zijn de meest voorkomende bevindingen, aanwezig in 45% van de steekproeven in het Veracode-onderzoek van 2025. Twee oude, goed begrepen fouten die elk codereviewproces moet vangen.

Kan AI-gegenereerde code valse of gehallucineerde dependencies bevatten?

Ja. Modellen bevelen soms softwarepakketten aan die niet bestaan, een gedocumenteerd probleem dat onderzoekers pakkethallucinatie noemen. Aanvallers zouden echte pakketten onder die namen kunnen registreren, dus het installeren van de "fix" kan malware installeren. Dependency-scanning en review vangen dit allebei.

Maken geautomatiseerde tools alleen AI-gegenereerde code veilig?

Geen enkele tool op zichzelf garandeert veiligheid. Menselijke review van elke regel en geautomatiseerde dependency-scanning zijn de praktijken die vandaag bij Globaprom het echte werk doen. Vraag elke leverancier precies welke controles draaien en welke niet, in plaats van een lijst tools te vertrouwen.

Hoe weet ik of een softwareleverancier AI-gegenereerde code echt reviewt?

Vraag wie de code leest en wanneer, in één zin. Een echt antwoord noemt een rol en een fase: een engineer, vóór elke merge. Een leverancier die dat niet zo precies kan beantwoorden, heeft waarschijnlijk geen reviewstap.

Is AI-gegenereerde code veiliger of onveiliger dan code die een mens vanaf nul schrijft?

Geen van beide, op zichzelf. Veiligheid komt van review en tests, niet van wie of wat het eerste concept typte. Gereviewde AI-gegenereerde code en gereviewde door mensen geschreven code eindigen om dezelfde reden veilig: iemand heeft het gecontroleerd.

Stel de moeilijke vragen voordat je tekent

De veiligste positie bij elke leverancier, ons incluis, is om precies te vragen wie je code reviewt en wat er gebeurt als een controle faalt. Beschrijf wat je moet laten bouwen, en we beantwoorden beide vragen al bij het eerste gesprek, samen met een vaste scope, een vaste prijs en een opleverdatum.

Vraag een offerte met vaste prijs aan →