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. Onze bredere uitleg over vibe coding en AI-ondersteunde ontwikkeling geeft het maar één alinea. De risico's, de review die ze vangt en de vragen voor een leverancier hebben meer ruimte nodig.

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 leerden van publieke code, inclusief de fouten erin. Het 2025 GenAI Code Security Report van Veracode constateerde dat AI-gegenereerde code bij 45% van de testtaken een bekende beveiligingskwetsbaarheid bevatte: injectiegevoelige queries, cross-site scripting, log-injectie, zwakke cryptografie. Geen van deze bugs is exotisch. Het zijn dezelfde fouten die junior developers altijd al maakten, gegenereerd op een tempo dat geen mens ooit haalde. En leidt zo'n lek tot een datalek met persoonsgegevens, dan moet je dat in de meeste gevallen binnen 72 uur melden bij de Autoriteit Persoonsgegevens (AP) in Nederland of de Gegevensbeschermingsautoriteit (GBA) in België. Dan is 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 5,2% van de door commerciële modellen voorgestelde pakketten gehallucineerd was, tegenover ongeveer 21,7% voor open-sourcemodellen. Aanvallers hebben dat door: ze registreren echte pakketten onder precies die verzonnen namen, zodat de volgende developer die de importfout "oplost" malware installeert. 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 heeft er geen belang bij ze te vinden, want het heeft al een antwoord geproduceerd dat af lijkt.

Onderhoudsschuld. Code die niemand begrijpt is een last, ook als hij vandaag werkt. AI-modellen dupliceren regelmatig logica in plaats van die te hergebruiken, omdat elke prompt een nieuw antwoord krijgt zonder geheugen van wat de codebase al bevat. Zes maanden later breekt een kleine wijziging op één plek iets zonder duidelijk verband, 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 GDPR 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 GDPR (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-pagina rond 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 "GDPR-proof" die als een keurmerk wordt rondgezwaaid. De GDPR 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 elk ander alarmsignaal, want het is de praktijk waarvan alle andere waarborgen afhangen.

Veelgestelde vragen over de beveiliging van AI-code

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 →