Een werkend AI-gebouwd product beantwoordt één vraag: draait het? Een AI code audit beantwoordt de volgende: houdt het product stand zodra er echte gebruikers, echte persoonsgegevens en het securityteam van een zakelijke klant bij komen? Dit artikel gaat over de audit van software waarvan de code grotendeels door AI-tools is geschreven. Audits die door AI-tools worden uitgevoerd, zijn een aparte vraag, beantwoord in het onderdeel over het kiezen van een aanbieder.
U leest welke vijf reviewgebieden een audit omvat, hoe de opdracht in vier fasen verloopt, welke drie deliverables u ontvangt en hoe een audit zich verhoudt tot een geautomatiseerde scan, een penetratietest en een secure code review. Voor het bredere traject van prototype naar live product leest u de founder-gids over AI coding in productie.
TL;DR
Een AI code audit is een onafhankelijke review van een product waarvan de code grotendeels is geschreven met AI-tools zoals Lovable, Bolt, Replit of Cursor. De audit controleert of het product veilig en onderhoudbaar genoeg is voor echte gebruikers, en ondersteunt één beslissing: lanceren, verkopen aan een zakelijke klant, investering ophalen of het product overdragen aan engineers.
- Vijf reviewgebieden vormen een AI code audit, elk als workstream met eigen bewijs: toegang en databeveiliging, architectuur en codekwaliteit, kritieke workflows, deployment en operations, en eigenaarschap en overdracht.
- Vier fasen structureren de opdracht: scoping, review, rapport en toelichting, en een optionele fase voor herstel en hertest die het contract apart vastlegt.
- Drie deliverables levert de audit op: bevindingen met bewijs, een geprioriteerd actieplan (nu oplossen, kan wachten, waar te beginnen) en een technische overdracht waarmee een team of AI-codingtool aan de slag kan.
- Een AI code audit komt eerst bij een AI-gebouwd product vóór de lancering; een penetratietest komt erbij als het dreigingsmodel of een klant bewijs vraagt dat het draaiende product een aanval weerstaat, en een secure code review past bij een volwassen codebase die alleen security-diepgang nodig heeft.
Bereidt u een lancering, een security-review van een zakelijke klant of een overdracht aan engineers voor?
Een afgebakende AI-built product review geeft u bevindingen met bewijs, een geprioriteerde volgorde van oplossen en een technische overdracht. Bekijk wat Sunbytes beoordeelt voordat u zich vastlegt op de volgende mijlpaal.
Wat is een AI code audit?
Een AI code audit is een onafhankelijke review van een softwareproduct waarvan de code grotendeels door AI-tools is geschreven, met één vraag: is het product veilig en onderhoudbaar genoeg voor echte gebruikers? Het gaat om een audit van AI-gegenereerde code, niet om een audit die een AI-tool uitvoert; AI-audittools zijn één input voor de review, niet de review zelf.
Producten gebouwd met Lovable, Bolt, Replit of Cursor werken snel, en daar zijn die tools voor gemaakt. De tools beslissen niet wie welke data mag lezen, waar de sleutels van betaalde diensten staan of wat er gebeurt als een betaling halverwege mislukt. Een AI code audit controleert die beslissingen in de hele codebase, op de plekken waar code uit verschillende prompts samenkomt.
Het risico is meetbaar. Het Veracode 2025 GenAI Code Security Report testte meer dan 100 taalmodellen op 80 programmeertaken: in 45% van de taken bevatte de gegenereerde code een kwetsbaarheid uit de OWASP Top 10.
Een AI code audit is geen certificaat en geen penetratietest. De audit leest broncode, configuratie en infrastructuurinstellingen en levert bevindingen met een volgorde van oplossen op, geen stempel ‘goedgekeurd’ of ‘afgekeurd’. Founders zoeken dezelfde dienst ook als vibe code audit of broncode audit.
Wanneer heeft een AI-gebouwd product een code audit nodig?
Een AI-gebouwd product heeft een code audit nodig vóór het eerste moment waarop iemand buiten het oprichtersteam op de code vertrouwt of de code inspecteert. Vijf gebeurtenissen markeren dat moment:
- Er komen echte gebruikers of persoonsgegevens in het product. Vanaf dat moment eist artikel 32 van de AVG (GDPR) beveiligingsmaatregelen die passen bij het risico.
- Een zakelijke klant stuurt een security-vragenlijst voor leveranciers. Veel vragenlijsten volgen uit NIS2 (Richtlijn (EU) 2022/2555) artikel 21, lid 2, onder d, dat organisaties onder NIS2 verplicht de beveiliging van hun toeleveringsketen te regelen, inclusief de relatie met directe leveranciers en dienstverleners.
- Een investeerder start een technische due diligence.
- U neemt de eerste engineer aan of draagt het product over aan een bureau.
- Bugs of storingen stapelen zich op in de weken na de lancering.
Geldt nog geen van de vijf, bijvoorbeeld bij een prototype met testdata en zonder betalende gebruikers, dan kan de audit wachten tot een van de vijf zich voordoet.
Wat omvat een AI code audit? Vijf reviewgebieden
Een AI code audit omvat vijf reviewgebieden, en elk gebied loopt als een aparte workstream met eigen controles en eigen bewijs: toegang en databeveiliging, architectuur en codekwaliteit, kritieke workflows, deployment en operations, en eigenaarschap en overdracht. Voor een koper is de nuttige vraag over de scope wat de reviewer per workstream verifieert en welk bewijs in het rapport terugkomt. De foutpatronen zelf staan beschreven in de founder-gids onder waar AI-gebouwde producten breken en, voor security, in vibe coding security-risico’s.
| Audit-workstream | Wat de reviewer verifieert | Bewijs in het rapport |
|---|---|---|
| Toegang en databeveiliging | Autorisatie afgedwongen voor alle relevante rollen en records | Geteste rol en endpoint, bewijs van onbevoegde toegang waar gevonden |
| Architectuur en codekwaliteit | Gedupliceerde logica, koppeling, beperkingen in onderhoudbaarheid | Betrokken modules, voorbeelden, aanpak voor herstel |
| Kritieke workflows | Mislukte transacties, foutstatussen, herstelgedrag | Testscenario, waargenomen resultaat, verwacht gedrag |
| Deployment en operations | Configuratie, monitoring, back-up en releasecontroles | Configuratiebevindingen, ontbrekende controles, aanbevolen acties |
| Eigenaarschap en overdracht | Documentatie, tests, dependencies en verantwoordelijkheden voor support | Ontbrekende artefacten, gaten in eigenaarschap en eisen voor overdracht |
Een bevinding komt pas in het rapport nadat de reviewer haar heeft gevalideerd. Bij toegang en databeveiliging reproduceert de reviewer het probleem met testaccounts in minstens twee rollen en legt hij het verzoek en het antwoord vast. Bij kritieke workflows voert de reviewer het faalscenario uit en zet hij het waargenomen resultaat naast het verwachte gedrag. Een vermoed probleem dat niet te reproduceren is, komt in het rapport als risico om te onderzoeken, met de reden waarom het niet te bevestigen was.
Securitybevindingen krijgen een OWASP Top 10:2025-categorie als die van toepassing is, bijvoorbeeld A01:2025 Broken Access Control voor een rol die records van een andere klant kan openen. Bevindingen over codekwaliteit, tests, documentatie of eigenaarschap krijgen geen OWASP-label, omdat de OWASP-lijst beveiligingsrisico’s indeelt en geen engineeringkwaliteit. Voor producten met persoonsgegevens ondersteunt het bewijs uit toegang en databeveiliging ook AVG-artikel 25 (gegevensbescherming door ontwerp en door standaardinstellingen) en artikel 32 (beveiliging van de verwerking).
Weet u niet welk van de vijf gebieden het zwakst is in uw product?
Een AI-built product review controleert alle vijf in één keer en legt elke bevinding uit in begrijpelijke taal: wat we vonden, waarom het ertoe doet voor uw lancering en wat u eerst oplost. Engineering en security worden samen beoordeeld, dus u krijgt één geprioriteerde lijst in plaats van twee rapporten die elkaar tegenspreken.
AI code audit-checklist: 12 controles voor een auditvoorstel
Een AI code audit-checklist voor kopers toetst het voorstel, niet het product: 12 controles laten zien of de scope, het bewijs en de voorwaarden dekken wat de audit moet aantonen. Gebruik de lijst om offertes te vergelijken voordat u tekent.
| # | Controle in het voorstel | Hoe een volledig antwoord eruitziet |
|---|---|---|
| 1 | Alle vijf workstreams in scope | Elke workstream benoemd, met uitsluitingen vermeld |
| 2 | Geteste rollen en records | De gebruikersrollen en datatypes waarvoor de reviewer toegang test |
| 3 | Kritieke workflows benoemd | Registratie, betaling of andere flows, met de faalscenario’s die worden uitgevoerd |
| 4 | Omgevingen gedekt | Welke omgevingen en welke configuratie de reviewer leest |
| 5 | Dependencies en licenties | Of externe pakketten worden gecontroleerd op bekende kwetsbaarheden en licentieconflicten |
| 6 | Bewijs per bevinding | Locatie, reproductiestappen of testresultaat, en ernst voor elke bevinding |
| 7 | Validatiemethode | Hoe bevindingen worden bevestigd en hoe onbevestigde risico’s worden gelabeld |
| 8 | Prioriteringsmethode | Hoe ernst en volgorde van oplossen worden bepaald tegenover uw beslissing en datum |
| 9 | Rapportvorm en toelichting | Een voorbeeldbevinding of rapportfragment, plus een toelichting met de beslisser |
| 10 | Vertrouwelijkheid en toegang | Alleen-lezen toegang, benoemde reviewers, een NDA en hoe de toegang na de audit eindigt |
| 11 | Onafhankelijkheid | Wie het product bouwt of herstelt, en of de reviewer los van dat werk staat |
| 12 | Voorwaarden voor hertest | Of een hertest is inbegrepen, hoeveel rondes en binnen welke termijn |
Controles 6, 7 en 12 kan een aanbod dat op een scanner draait niet beantwoorden: een scanoutput heeft geen gereproduceerd bewijs, geen validatiestap en geen voorwaarden voor een hertest.
Hoe verloopt een AI code audit?
Een AI code audit-opdracht verloopt in vier fasen, en elke fase heeft een input van de klant, een activiteit van de reviewer en een resultaat dat de fase afsluit. Fase 1 tot en met 3 vormen de audit zelf. Fase 4, herstel en hertest, is een aparte scope die het contract moet vastleggen.
| Auditfase | Input van de klant | Activiteit van de reviewer | Resultaat of acceptatiepunt |
|---|---|---|---|
| 1. Scoping | De beslissing die de audit ondersteunt, omgevingen, gebruikersrollen, alleen-lezen toegang tot de repository | Legt workstreams, kritieke workflows en uitsluitingen vast; bevestigt afspraken over toegang en vertrouwelijkheid | Getekende scope met workstreams, workflows in scope en rapportdatum |
| 2. Review | Antwoorden op vragen van de reviewer; een testaccount per rol | Reviewt code, configuratie en deployment in de vijf workstreams; test kritieke workflows en toegang per rol | Conceptbevindingen, elk met bewijs |
| 3. Rapport en toelichting | Beslisser en technisch verantwoordelijke zijn bij de toelichting | Prioriteert bevindingen en loopt bewijs en volgorde van oplossen door | Eindrapport geaccepteerd: bevindingen, geprioriteerd actieplan, technische overdracht |
| 4. Herstel en hertest (optioneel) | Fixes door uw team, uw AI-codingtool of een partner; lijst van bevindingen die als opgelost worden gemeld | Hertest elke gemelde fix tegen het oorspronkelijke bewijs | Hertestresultaat per bevinding: gesloten, deels gesloten of open |
Herstel en hertest horen standaard niet bij de audit. Leg drie voorwaarden vast voordat de scoping sluit: of een hertest is inbegrepen, hoeveel rondes en binnen welke termijn na het rapport. Zonder die voorwaarden is er geen afgesproken manier om een opgeloste bevinding te sluiten.
Wat u voorbereidt vóór de audit
Met vijf inputs kan de review op dag één starten:
- Alleen-lezen toegang tot de coderepository.
- Een lijst van omgevingen (ontwikkeling, staging, productie) en externe diensten zoals betalingen, e-mail, inloggen en API’s van AI-modellen.
- De gebruikersrollen en wat elke rol mag zien of wijzigen.
- Bekende problemen, bugs en storingen tot nu toe.
- De beslissing die de audit moet ondersteunen, met de datum.
Toegang tot de code is de eerste vertrouwelijkheidsvraag van elke founder, en het antwoord waar u om vraagt is concreet: alleen benoemde reviewers zien de code, de toegang is alleen-lezen en een geheimhoudingsovereenkomst (NDA) voor de code en de bevindingen is getekend voordat toegang wordt verleend. Bij Sunbytes valt de toegang tot code onder een ISO/IEC 27001:2022-gecertificeerd managementsysteem voor informatiebeveiliging (ISMS).
Doorlooptijd en kosten
Doorlooptijd en kosten van een AI code audit hangen af van vier factoren: de omvang van de codebase, het aantal gebruikersrollen en integraties, het aantal omgevingen en of een hertest is inbegrepen. Een vaste scope uit de eerste fase legt beide vast voordat de review begint. kosten van een AI code audit laat zien hoe elke factor de prijs beïnvloedt.
Wat ontvangt u? De deliverables van de audit
Een AI code audit levert drie dingen op: heldere bevindingen, een geprioriteerd actieplan en een technische overdracht. Elke deliverable is zo geschreven dat een niet-technische founder kan beslissen en een engineer of AI-codingtool kan handelen.
- Heldere bevindingen: wat er is gevonden, waarom het ertoe doet en het bewijs (bestand, endpoint, verzoek en antwoord).
- Geprioriteerd actieplan: wat u nu oplost, wat kan wachten en waar u begint.
- Technische overdracht: instructies waarmee uw team of een AI-codingtool aan de slag kan.
| Veld | Inhoud |
|---|---|
| Titel | Elke ingelogde gebruiker kan facturen van andere klanten lezen |
| Ernst | Hoog · OWASP A01:2025 Broken Access Control |
| Waar | Factuur-endpoint, GET /api/invoices/{id} |
| Bewijs | Ingelogd als testgebruiker A geeft een verzoek om een factuur-ID van testgebruiker B de factuur van B terug, met naam, adres en bedrag. |
| Zakelijke impact | De persoonsgegevens van elke klant liggen open voor elke andere klant. De bevinding is een kwetsbaarheid; het wordt pas een datalek als de toegangslogs laten zien dat de factuur van een ander account echt is geopend. Is dat bevestigd, dan eist AVG-artikel 33 een melding bij de Autoriteit Persoonsgegevens binnen 72 uur nadat u het lek hebt ontdekt, tenzij het waarschijnlijk geen risico oplevert voor de betrokken klanten. |
| Oplossing | Controleer op de server of de factuur bij het account van de ingelogde gebruiker hoort voordat u die teruggeeft; voeg een automatische test toe voor toegang tussen accounts en controleer de toegangslogs op verzoeken tussen accounts. |
| Inspanning | Klein: één gedeelde toegangscontrole, toegepast op elk endpoint dat klantrecords teruggeeft. |
Een scannerexport is geen auditrapport. Een scanner geeft patroonmatches met een ernstscore; een auditbevinding voegt de zakelijke impact toe, het bewijs dat het probleem bereikbaar is en de plek in de volgorde van oplossen. Een volledig voorbeeld van een AI code audit-rapport laat zien hoe de drie deliverables samenhangen.
AI code audit, penetratietest of secure code review?
Een AI code audit is de eerste controle als de beslissing is of een AI-gebouwd product klaar is voor echte gebruikers. Een penetratietest of secure code review komt erbij als het risico meer diepgang in één richting vraagt, en die keuze hangt net zo goed af van het dreigingsmodel en de data in het product als van de vraag van een klant.
| Situatie | Aanbevolen controle | Waarom |
|---|---|---|
| AI-gebouwd product vóór of net na de lancering; de beslissing is lancering, verkoop, investering of overdracht | AI code audit | Dekt engineering en security in vijf workstreams en levert een volgorde van oplossen op |
| Het product verwerkt betaal-, gezondheids- of andere gevoelige persoonsgegevens, of is een waarschijnlijk doelwit | AI code audit, daarna een penetratietest | Het dreigingsmodel vraagt bewijs dat het draaiende product een aanvaller weerstaat, zodra de fixes uit de audit live staan |
| Een klant of auditor vraagt testbewijs van het draaiende systeem | Penetratietest, na of naast de audit | Het bewijs moet komen uit een aanval op het live systeem, niet uit het lezen van code |
| Volwassen codebase, engineeringkwaliteit op orde, security-diepgang nodig in specifieke modules | Secure code review | Een regel-voor-regel securityreview van de modules waar het risico zit |
Geautomatiseerde scans blijven in elk geval in de delivery-pipeline. AVG-artikel 32, lid 1, onder d, verwacht een procedure om beveiligingsmaatregelen regelmatig te testen, beoordelen en evalueren, en een eenmalige audit of test vervangt die procedure niet. Kies een secure code review als de codebase volwassen is en de open vraag security-diepgang in specifieke modules is.
Hoe kiest u een onafhankelijke AI code audit-partij?
Een onafhankelijke AI code audit-partij is een aanbieder waarvan de reviewers het product niet hebben gebouwd en voor hun resultaat niet afhankelijk zijn van het herstelwerk. Zeven criteria laten zien of een aanbieder dat kan waarmaken:
- Kwalificaties van reviewers: benoemde reviewers met engineering- en securityervaring in de stack van uw product.
- Onafhankelijkheid van de bouw: de reviewer heeft het product niet gebouwd en staat los van het team of de tool die de code genereerde.
- Dekking van engineering en security: beide disciplines reviewen dezelfde codebase, zodat het rapport één volgorde van oplossen heeft in plaats van twee.
- Kwaliteit van bewijs: een voorbeeldbevinding toont locatie, reproductie of testresultaat, ernst en zakelijke impact.
- Scheiding van herstelwerk: de audit wordt los van eventueel herstelwerk gecontracteerd, zodat bevindingen niet worden opgeblazen om fixes te verkopen.
- Vertrouwelijkheid: alleen-lezen toegang, benoemde reviewers, een NDA en een vastgelegd einde van de toegang tot de code.
- Voorwaarden voor hertest: of een hertest is inbegrepen, hoeveel rondes en binnen welke termijn.
Functiescheiding is een benoemde maatregel in ISO/IEC 27001:2022, bijlage A 5.3, en hetzelfde principe geldt voor een audit: de partij die de code bouwt of herstelt, hoort niet de enige te zijn die haar controleert. De volledige lijst met vragen staat in een AI code audit-partner kiezen.
AI-audittools en scanners horen in de pipeline en kunnen input leveren voor de review, maar ze beoordelen geen bedrijfsregels, rolontwerp of de volgorde van oplossen voor een specifieke lancering. De volledige onderbouwing staat in de founder-gids onder wie AI-gegenereerde code moet reviewen, en in AI code review.
Na de audit: wie lost wat op?
Na een AI code audit krijgt elke bevinding een eigenaar, een herstelroute en een sluitvoorwaarde voordat het werk begint. De eigenaar is een benoemde persoon aan uw kant, ook als een partner of een AI-codingtool de wijziging maakt. De herstelroute is uw eigen team, uw AI-codingtool op basis van de technische overdracht, of een partner onder een apart contract.
Een bevinding sluit pas als er bewijs is dat de fix werkt: de oorspronkelijke reproductiestappen of het testscenario worden opnieuw uitgevoerd en geven het verwachte resultaat, en de wijziging is aan de bevinding gekoppeld. Bevindingen die vóór de beslisdatum niet op te lossen zijn, accepteert de beslisser schriftelijk als bekend risico, met een streefdatum.
Bevindingen waarbij persoonsgegevens bereikbaar zijn, komen eerst, en daarbij zijn drie situaties te onderscheiden. Een kwetsbaarheid betekent dat persoonsgegevens bereikt kunnen worden; op zichzelf levert dat geen meldplicht onder de AVG op. Een bevestigd datalek betekent dat logs of ander bewijs laten zien dat persoonsgegevens echt zijn ingezien, gewijzigd of verloren. Een meldplichtig datalek is een bevestigd lek dat waarschijnlijk een risico oplevert voor de betrokkenen: AVG-artikel 33 eist dan een melding bij de Autoriteit Persoonsgegevens binnen 72 uur nadat u het lek hebt ontdekt, zoals de EDPB-richtsnoeren 9/2022 over het melden van datalekken toelichten. Wijzen de bevindingen op structurele problemen, dan staat de keuze tussen behouden, refactoren of herbouwen in de founder-gids onder herstellen, refactoren of herbouwen, en in herbouwen of refactoren.
Hoe Sunbytes AI-gebouwde producten beoordeelt
De meeste risico’s in AI-gebouwde producten ontstaan waar code, gebruikersrechten, data en kritieke workflows samenkomen. Daarom benadert Sunbytes de AI-built product review als een onafhankelijke beoordeling van de gereedheid van uw product, niet als aanleiding om het product opnieuw te ontwerpen.
Onze engineering-, QA- en securityspecialisten combineren handmatige review met geautomatiseerde tools om bevindingen te valideren en aanbevelingen te doen die met bewijs zijn onderbouwd. De review duurt doorgaans vijf werkdagen vanaf het moment dat de volledige toegang er is, met scope en omgang met data vooraf vastgelegd. U ontvangt een rapport in begrijpelijke taal dat laat zien wat u moet oplossen vóór breder gebruik en wat kan wachten.
Is diepgaander securitytesten nodig, dan kan ons team voor Cybersecurity-oplossingen een aparte penetratietest of secure code review uitvoeren. Vraagt het herstel om extra engineeringcapaciteit, dan kan een dedicated software development team de fixes ondersteunen onder een aparte overeenkomst. U blijft vrij om met uw eigen team of een andere aanbieder te werken.
Sunbytes brengt meer dan 15 jaar ervaring, ruim 300 opgeleverde projecten in 20 landen en een ISO/IEC 27001:2022-certificering mee in elke technische review.
Bekijk onze AI-built product review of bespreek uw AI-gebouwde product met ons team vóór uw volgende lancering, zakelijke deal of overdracht aan engineers.
