Is software die met AI gebouwd is wel veilig?

De vraag die u zich mag stellen

Software die in dagen gebouwd wordt in plaats van maanden, met AI die een groot deel van de code schrijft: de eerlijke reactie daarop is wantrouwen, geen enthousiasme. “Wie heeft dit dan gecontroleerd?” is een goede vraag, geen onbeleefde. Het eerlijke antwoord is ook niet “ik lees alles na voor het live gaat”. Dat antwoord klinkt geruststellend. Maar het houdt bij software van enige omvang al lang geen stand meer, met AI geschreven of niet.

Waarom “ik lees alles na” niet meer klopt

Dat is geen nieuwe eigenaardigheid van AI-code. Grote, professioneel onderhouden software werd allang niet meer regel voor regel gelezen door één iemand die alles begreep. Daarvoor is de meeste software al jaren te groot, met te veel handen erin. Wat wel veranderde: bij AI is het makkelijker om te doen alsof dat ooit anders was.

Een treffend, recent voorbeeld: Linus Torvalds, de oprichter van Linux, zei op de Open Source Summit India 2026 dat hij zelf nauwelijks nog code leest. Hij leest de beschrijving die bij een codewijziging hoort en beoordeelt de intentie erachter, niet de implementatie regel voor regel. Hij heeft ook publiekelijk geweigerd om van de Linux-kernel een anti-AI-project te maken. Dat zegt de oprichter van een van de meest kritieke stukken software ter wereld. Dan is “ik lees alles zelf na” geen realistische standaard meer om aan software van een kmo op te hangen. Waarschijnlijk was dat nooit een realistische standaard, ook niet vóór AI.

“Het werkt” is geen bewijs dat het veilig is

Onderzoek van Veracode naar AI-gegenereerde code bevestigt wat hierboven al aannemelijk klinkt: functionele juistheid en veiligheid zijn twee aparte vragen geworden, geen twee kanten van dezelfde vraag. Code die doet wat ze moet doen, die de test doorstaat, die de juiste output geeft, bewijst niet dat ze onbevoegde toegang ook echt blokkeert. Een taalmodel (het soort AI-systeem dat de code schrijft) optimaliseert voor “dit werkt”, niet voor “dit weigert het juiste”. Dat gat tussen beide is precies waar kwetsbaarheden ontstaan, of de code nu door een mens of door AI geschreven is.

Een concreet voorbeeld daarvan is CVE-2025-48757, een kwetsbaarheid in applicaties gebouwd met het AI-platform Lovable. Rijbeveiliging (wie mag welke rij in de database zien) stond niet standaard aan. Daardoor kon data van de ene gebruiker zichtbaar zijn voor een andere. De applicaties in kwestie werkten prima: ze deden wat ze moesten doen. De functionaliteit klopte. Het probleem zat in wie er toegang toe had. Precies het soort fout dat “de code nalezen” niet betrouwbaar vangt: de code zelf zag er niet fout uit, de afwezigheid van een regel wél.

Waar veiligheid dan wel vandaan komt

Als lezen het niet is, wat dan wel? Vier dingen, samen. Geen van alle is op zich voldoende, maar samen vormen ze het systeem waar veiligheid uit voortkomt.

Het datamodel en de rechten, vroeg en bewust ontworpen. Wie bij welke data mag en wat een rol wel of niet kan doen, wordt bepaald voor het bouwen begint, niet halverwege bijgestuurd. Dat achteraf rechttrekken is geen laagje bijwerken. Het is de fundering opnieuw leggen, met alles wat daarbovenop staat.

Autorisatie getest, niet verondersteld. Een test die bewijst dat een functie werkt, bewijst niet dat iemand zonder rechten ze niet evengoed kan uitvoeren. Dat zijn twee aparte testen, met een aparte blik — precies het gat dat de Lovable-kwetsbaarheid blootlegde.

Zo min mogelijk rechten, overal. Elke toegang krijgt enkel wat nodig is voor die ene taak. Gaat er toch iets mis, dan blijft de schade beperkt tot dat ene stukje in plaats van het hele systeem.

Omkeerbaarheid en zichtbaarheid. Wijzigingen zijn terug te draaien. Een fout blijft niet onopgemerkt tot een klant hem vindt. Ze stuurt meteen een zichtbaar signaal naar een vaste, met naam gekende persoon. Software die stil faalt is erger dan software die luid faalt — bij stil falen weet u niet eens dat u het zelf nog moet oplossen.

Daarbovenop staat iemand die het geheel begrijpt: wat de software doet, hoe ze draait, wat ze aanraakt, en hoe ze beveiligd is. Dat is geen vage geruststelling. Het is een rol die iemand effectief vervult.

Wat dit niet belooft

Eerlijkheid hierover werkt in twee richtingen. Er bestaat geen langetermijnbewijs dat met AI gebouwde software het decennialang even goed blijft doen als traditioneel gebouwde software. Daarvoor is de praktijk simpelweg te jong. Wat wel te zeggen valt: de methode hierboven is bewust ontworpen tegen de fouten die vandaag al gedocumenteerd zijn, van de Lovable-kwetsbaarheid tot het bredere Veracode-patroon. Dat is geen garantie. Het is wel iets concreters dan vertrouwen op goed geluk.

Het is ook geen argument dat AI ontwikkelaars in het algemeen sneller maakt. De meest rigoureuze gecontroleerde studie tot nu toe (METR, 2025) vond dat ervaren ontwikkelaars op complexe taken juist 19% trager werkten met AI-hulp, niet sneller. De snelheid die hier telt is smaller: voor een afgebakende, goed geschetste bouwopdracht wint itereren met AI het van alles met de hand uittypen. Een algemene productiviteitsclaim is dat niet, en wordt hier ook niet gemaakt.

Wat dit voor Kufu betekent

Dit is de reden waarom “elke regel wordt gelezen” nooit de juiste belofte was, en waarom ze hier ook niet meer staat. De echte belofte is preciezer, en eerlijk gezegd minder geruststellend klinkend, maar wel waar te maken. Rechten en datamodel liggen vroeg vast. Autorisatie wordt apart getest. Toegang blijft minimaal. Fouten zijn luid. En er is één iemand, die de software ook zelf beheert, die op elk moment weet wat ze doet.

Wilt u dat voor uw eigen situatie concreet bekijken, dan is dat een van de dingen die tijdens een gratis kennismaking van een half uur mee op tafel komen.