Kort samengevat. Een AI-programmeertool bezorgt je in een weekend een werkend prototype, maar "werkt in de demo" en "veilig genoeg voor productie" zijn twee verschillende dingen. In vrijwel elke met AI gebouwde app duiken dezelfde drie problemen op: beveiligingslekken (blootgestelde sleutels, ontbrekende autorisatie, injectie), op hol geslagen API-kosten (5–20× te veel door niet-gecachte, niet-gebundelde, ongebonden aanroepen), en datalekken (gevoelige informatie in logs, API-antwoorden die te veel prijsgeven, blootstelling aan derden). Je gooit het prototype niet weg — je beoordeelt het, herstelt die drie categorieën, en levert op. Dit stuk is het draaiboek: wat er breekt, waarom, en het pad stap voor stap van prototype naar productie. Geef je het liever uit handen, dan is dat precies wat een audit van AI-code doet.

Wil je alleen het proces, spring dan naar hoe je het opleveren aanpakt.

Het prototype dat werkt in de demo en breekt in productie

Je hebt iets echts gebouwd. Cursor, Bolt, Lovable of een lange sessie met ChatGPT maakte in dagen in plaats van maanden een draaiende app van een idee. Het ziet er goed uit. Het werkt op jouw machine. Je demonstreert het aan vroege gebruikers of investeerders en de reacties zijn goed. Dus richt je er een domein op, zet je het op productie, en begin je er echte mensen heen te sturen.

Daar begint het probleem — en niet omdat je iets fout deed. AI-agents zijn buitengewoon goed in code produceren die werkt. Ze zijn niet goed in code produceren die productieklaar is, want dat zijn verschillende doelen. "Werkt" betekent dat het gelukkige pad loopt. "Productieklaar" betekent dat het een aanvaller, een verkeerspiek, een verkeerde invoer en een factuurperiode overleeft — en niets daarvan komt in een demo voor.

Dit is geen randverschijnsel. Veracode testte 100+ LLMs en vond dat 45% van de gegenereerde code zakt voor beveiligingstests. De analyse van Apiiro uit 2025 vond dat developers die AI gebruiken inloggegevens bijna twee keer zo vaak blootstellen. Onderzoekers van Stanford vonden dat developers die AI-assistenten gebruiken minder veilige code schrijven terwijl ze er zekerder van zijn dat die veilig is. Dat vertrouwensgat is het gevaarlijke deel: de demo voelt afgerond, dus de 20% die dat niet is blijft onzichtbaar tot hij je geld kost.

Het goede nieuws is dat het gat voorspelbaar is. Na tientallen door AI gegenereerde codebases te hebben beoordeeld, vallen de fouten in drie bakken uiteen — dezelfde drie die het prototype nooit reden had af te handelen.

De drie dingen die breken

1. Beveiligingslekken

AI-tools optimaliseren op de kortste weg naar een werkende functie, en die kortste weg is vrijwel nooit de veilige.

  • Blootgestelde sleutels en geheimen. API-sleutels, databasegegevens en dienstentokens worden hard in de broncode gezet, in bundels aan de clientkant gebakken, of in .env-bestanden vastgelegd. Eén gelekte sleutel van een derde partij kan binnen uren duizenden euro's aan ongeautoriseerd gebruik opleveren — of een aanvaller je gegevensopslag in handen geven.
  • Authenticatie zonder autorisatie. Er is een inlogscherm, dus het voelt veilig. Maar de backend controleert vaak niet wie wat mag. Endpoints accepteren elk verzoek; wijzig een ID in de URL en je leest andermans gegevens. Dit — gebroken autorisatie op objectniveau — is het meest voorkomende gebrek dat we vinden, en het staat niet voor niets bovenaan de OWASP API Security-lijst.
  • Injectie. SQL-injectie, XSS en zitten overal in met AI gebouwde code, omdat modellen vrolijk gebruikersinvoer rechtstreeks in query's, HTML of LLM-prompts plakken. Eén niet-ontsmet endpoint kan de hele database blootleggen of een aanvaller je AI laten sturen.
  • Onveilige opslag. Persoonsgegevens in leesbare tekst, sessietokens in localStorage, wachtwoorden gehasht met MD5 of helemaal niet. AI grijpt standaard naar de eenvoudigste uitvoering, en die is zelden de veilige. (We schreven een volledige uiteenzetting over hoe gegevens werkelijk versleuteld horen te worden, zowel in rust als onderweg — dat is de bron waar we klanten naartoe sturen.)

2. Op hol geslagen API-kosten

Dit is degene die een lancering stilletjes failliet laat gaan in plaats van hem te compromitteren.

  • Overbodige aanroepen. Met AI gebouwde apps roepen hetzelfde betaalde endpoint — geocodering, wisselkoersen, een LLM, een verificatie-API — keer op keer aan voor gegevens die ze al hebben. Geen caching, geen onthouden. We vinden geregeld apps waarin 60–80% van de API-uitgaven pure verspilling is.
  • Geen budgetten of . Geen plafond per gebruiker, geen daglimiet, geen noodrem. Eén enthousiaste gebruiker, een scraper of een bot kan je hele maandbudget in een middag opmaken. De AI heeft geen idee van je prijsniveaus of je resterende middelen, dus bouwt hij nooit vangrails.
  • Geen bundeling. Losse verzoeken afvuren in een lus in plaats van het bundelendpoint gebruiken dat de aanbieder biedt. Op demoschaal is het onzichtbaar; op productieschaal is het een maandrekening van vijf cijfers.

De kosten van een app bouwen zijn één ding — de kosten van een niet-geoptimaliseerde app draaien zijn de verrassing waar oprichters door worden overvallen.

3. Datalekken

De categorie die van een stil succes een compliance-incident maakt.

  • Gevoelige gegevens loggen. AI is dol op uitgebreid loggen. E-mailadressen, wachtwoorden, betaalgegevens en persoonsgegevens belanden in applicatielogs en foutopsporingsdiensten, vaak onbeperkt bewaard en leesbaar voor iedereen met toegang tot het dashboard.
  • Te veel prijsgeven via API's. Endpoints die het complete gebruikersobject teruggeven — gehashte wachtwoorden, interne ID's, metadata — terwijl de front-end alleen een weergavenaam nodig had. -endpoints zonder dieptelimiet waarmee een aanvaller je hele datamodel kan aflopen.
  • Blootstelling aan derden. Analyse-, monitoring- en foutopsporingstools aangekoppeld zonder na te denken over wat daarheen stroomt. Gebruikersgedrag en persoonsgegevens verlaten je systeem zonder toestemming, en precies daarvoor zijn de boetes onder de geschreven.

Hoe je een met AI gebouwd prototype naar productie brengt

Je bouwt niet opnieuw — dat gooit de 80% weg die de AI goed deed. Je beoordeelt het prototype, herstelt de drie categorieën hierboven op prioriteit, en levert op. Dit is het pad dat wij lopen.

Stap 1 — Bevries en baken af

De eerste ingeving na een goede demo is meer functies toevoegen. Weersta die. Code toevoegen aan een niet-beoordeelde basis vergroot alleen het oppervlak dat je straks moet herstellen. Zet de scope vast, geef leestoegang, en bepaal wat de beoordeling dekt — een volledige ronde, of een gerichte op de pijler die je het meest zorgen baart. Er verandert nog niets in productie.

Stap 2 — Geautomatiseerde scan

Statische analyse, scans op afhankelijkheden en geheimen, en kostenprofilering vangen de voor de hand liggende problemen snel: de vastgelegde API-sleutel, het pakket met een bekende CVE, het endpoint dat 300 keer per minuut wordt geraakt. Dit is de goedkope laag met veel volume.

Stap 3 — Handmatige beoordeling door een expert

De dure problemen verstoppen zich waar gereedschap ze niet ziet: een endpoint dat de juiste gegevens teruggeeft maar nooit controleert wie het vraagt, een facturatielus die klopt maar niet gecacht is, een koppeling met een derde partij die stilletjes persoonsgegevens naar buiten stuurt. Een mens leest de architectuur, de authenticatiestromen en de gegevenspaden. Dit is de stap die een audit van AI-code van een linter onderscheidt.

Stap 4 — Herstel op prioriteit

Bevindingen worden op ernst gesorteerd en in die volgorde hersteld. Eerst kritieke beveiligingslekken — een gelekte sleutel of het omzeilen van authenticatie is een noodgeval. Dan kostenbeheersing, want elke dag op 5–20× te veel is echt geld. Dan privacy en compliance. Jij beoordeelt en keurt elke wijziging goed voordat ze wordt samengevoegd; er gebeurt niets met je code zonder jouw akkoord.

Stap 5 — Lever met vertrouwen op

Test opnieuw tegen elke bevinding, bevestig dat de oplossingen standhouden, en rol uit. Zelfde product, zelfde met AI gebouwde fundament — nu gehard. Dat is het hele punt: je houdt de snelheid die de AI je gaf en voegt de duurzaamheid toe die hij niet kon leveren.

We hebben precies dit op echte bouwtrajecten gedraaid. Arcana, een streamende AI-chatclient, ging van prototype naar een opgeleverde app van productiekwaliteit — het weinig glamoureuze werk van streaming, authenticatie en gegevensverwerking harden is wat van een demo iets maakte waar mensen werkelijk op konden leunen.

Wat het kost en hoe lang het duurt

Een gerichte beveiligingsronde op een kleine app met één service kost 1–2 weken; een volledige audit van productiegereedheid — beveiliging, kosten, gegevens, prestaties, infrastructuur — op een doorsnee app met meerdere services kost 2–4 weken. Dat is een orde van grootte sneller en goedkoper dan de 3–6 maanden die een herbouw vanaf nul zou kosten, omdat je alles behoudt wat de AI goed deed en alleen herstelt wat hij fout deed.

Het denkmodel dat het waard is je eigen te maken: AI brengt je 80% van de weg in 5% van de tijd. De laatste 20% — beveiliging, kostenbeheersing, gegevensprivacy, foutafhandeling — is het volledige verschil tussen een demo en een product. Een audit koopt die 20% zonder het fundament weg te gooien. De volledige niveaus en tarieven staan op de pagina audit van AI-code.

Veelgestelde vragen

Zelden zonder wijzigingen. Het prototype werkt vrijwel zeker op het gelukkige pad, maar AI-tools slaan stelselmatig de delen over die alleen in productie tellen: autorisatiecontroles, kostenbeheersing voor API-verbruik, veilige gegevensopslag en privacy. De oplossing is geen herbouw — het is een audit die die gaten vindt en dicht, meestal in een tot vier weken, met behoud van de code die de AI al goed had.
Een audit van AI-code is een gestructureerde beoordeling van een door AI gegenereerde codebase die de problemen vindt en herstelt die AI-programmeergereedschap stelselmatig mist: beveiligingslekken, op hol geslagen API-kosten en datalekken. Ze combineert geautomatiseerd scannen (geheimen, afhankelijkheden, statische analyse) met een handmatige beoordeling door experts van architectuur, authenticatie en gegevensstromen, en levert daarna oplossingen op prioriteit — of voert ze voor je uit.
AI-modellen optimaliseren op de kortste weg naar werkende code, en die weg is vrijwel nooit de veilige. Ze zetten geheimen hard in de code, bouwen authenticatie zonder echte autorisatie, plakken gebruikersinvoer in databaseopdrachten en prompts, en slaan gegevens in leesbare tekst op. Onafhankelijke studies van Veracode, Apiiro en Stanford vonden allemaal dat met AI geschreven code meetbaar minder veilig is — terwijl developers er zekerder van zijn dat ze veilig is.
Doorgaans 5 tot 20 keer meer dan nodig. De gebruikelijke oorzaken zijn hetzelfde betaalde endpoint herhaaldelijk aanroepen zonder caching, losse verzoeken in een lus doen in plaats van bundelen, en geen verzoeklimieten per gebruiker of daglimiet hebben. We hebben maandelijkse API-rekeningen zien dalen van duizenden euros naar een paar honderd nadat die maatregelen waren toegevoegd.
Nee, en dat moet je ook niet doen. Een herbouw gooit de 80% weg die de AI goed deed en kost drie tot zes maanden. Een audit behoudt dat fundament en herstelt alleen de 20% die in productie breekt — beveiliging, kosten, privacy en foutafhandeling — in een tot vier weken. Je levert hetzelfde product op, gehard.
Nee. De audit beoordeelt broncode en draait alleen-lezen tests tegen een testomgeving, dus je live app blijft gewoon draaien. Wordt er een kritieke kwetsbaarheid gevonden die direct risico oplevert, dan hoor je dat meteen zodat jij kunt bepalen hoe te reageren.

Lever op wat je al hebt gebouwd

Je deed het lastige deel — je vond iets dat het bouwen waard is en kreeg het draaiend. Laat die onzichtbare 20% van een echt succes geen datalek, verrassingsrekening of complianceprobleem maken. Haal het prototype door een audit van AI-code, herstel de drie dingen die breken, en zet het met vertrouwen voor echte gebruikers.

Heb je een met AI gebouwde app waarvan je het uitrollen spannend vindt, plan dan een gratis analyse. We vertellen je welke van de drie pijlers je grootste risico is, wat het kost om die te herstellen, en geven je een offerte met vaste scope — geen gok.