Learn
De CISO-checklist voor AI-gegenereerde software
AI-gebouwde software zit al binnen je organisatie, gesanctioneerd of niet. Deze checklist geeft securityleiders de controls en het bewijs om te eisen. Voordat het eerste incident het beleid voor je schrijft.
AI-gegenereerde software heeft dezelfde assurance nodig als door mensen geschreven software, plus controls specifiek voor hoe ze gemaakt is: herkomst voor elke wijziging, beleidsreview vóór merge, security-testing geverifieerd tegen de draaiende applicatie, en een audit trail die prompts aan deployments koppelt. Anders dan conventionele AppSec-review die code periodiek steekproefsgewijs bekijkt, moet assurance voor AI-gebouwde systemen continu draaien, omdat het wijzigingsvolume hoger ligt en het auteurschap gedeeld is tussen mensen en agents.
Gepubliceerd 2026-07-03 · Laatst bijgewerkt 2026-07-03 · Ciao-redactieteam
Het korte antwoord, uitgebreid
De securityvraag over AI-gegenereerde code wordt meestal achterstevoren gesteld. "Is AI-code minder veilig dan menselijke code?" nodigt uit tot een citatenwedstrijd van studies en mist het operationele punt: AI verandert het volume, de snelheid en het auteurschap van code, en die drie verschuivingen breken de aannames waarop je bestaande assuranceprogramma is gebouwd. Jaarlijkse pentests veronderstellen dat de codebase langzaam verandert. Handmatige review veronderstelt een menselijke auteur die de wijziging begreep en ervoor kan instaan. Steekproeven veronderstellen dat de niet-bemonsterde code lijkt op de bemonsterde. Onder AI-ontwikkeling houdt geen van die aannames stand.
De eis op CISO-niveau is dus geen oordeel over modelkwaliteit. Modellen blijven toch onder je veranderen. Het is een set eigenschappen die het ontwikkelsysteem moet hebben, ongeacht welk model de code schreef: elke wijziging herleidbaar tot een prompt, een persoon en een goedkeuring; consequentiële wijzigingen gegate door beleid vóór merge; security-testing die continu draait en bevindingen bevestigt tegen de live applicatie in plaats van je te overspoelen met statische ruis; en een onveranderbaar record dat goed genoeg is om elke wijziging te reconstrueren voor een auditor of een incidentreview.
Zo geframed is AI-ontwikkeling geen nieuwe risicocategorie die om een nieuwe theorie vraagt. Het is een vertrouwde categorie, wijzigingsbeheer op schaal, die om betere machinerie vraagt. De checklist hieronder is die machinerie, geschreven als eisen die je voor elke leverancier of elk intern platformteam kunt leggen.
Houding telt net zo zwaar als controls. De productieve houding is aannemen dat AI-gegenereerde software al in je organisatie bestaat, want dat doet ze, en het beheerde pad het aantrekkelijke maken in plaats van een verbod afkondigen dat het bouwen verder de schaduw in drijft. Securityteams die een gesanctioneerde route met heldere controls publiceren, krijgen zichtbaarheid en adoptie; teams die verbieden krijgen geen van beide, plus hetzelfde risico. Elke eis hieronder dient die strategie: elk maakt de veilige manier van bouwen ook de makkelijke manier om verantwoording af te leggen over wat er gebouwd is.
Het dreigingsmodel waar securityleiders werkelijk voor staan
Begin met wat al waar is: businessunits genereren vandaag applicaties met AI-tools, grotendeels buiten het gezichtsveld van security. Het realistische incident op korte termijn is geen exotische modelaanval; het is een onbeoordeelde AI-gebouwde app met een te ruim databasebeleid die stilletjes klantrecords blootlegt, ontdekt door een klant. Shadow-AI-ontwikkeling is shadow IT met een codegenerator eraan vast, en het erft elke klassieke fout, onbekende datastromen, ongepatchte dependencies, geen eigenaar, op veel hogere productiesnelheid.
Binnen engineering is het risico subtieler: erosie van review onder volume. Wanneer agent-gegenereerde pull requests verdrievoudigen en het aantal reviewers niet, wordt goedkeuring óf het knelpunt dat de productiviteitswinst doodt, óf een rubberen stempel die de control doodt. Beide uitkomsten zijn slecht, en organisaties die de keuze nooit expliciet maakten, krijgen meestal standaard de tweede. Het enige stabiele antwoord is triage per beleid. Machines wikkelen het routinewerk af, mensen beoordelen wat regels als consequentieel markeren. Met het beleid zelf in eigendom van security, niet van wie de prompt schreef.
En wanneer er wél iets misgaat, wordt de incident-response-vraag het hele spel: kun je reconstrueren wat er veranderde, wie of wat het veranderde, welke tests er draaiden, en wie het goedkeurde? Als het eerlijke antwoord een chatlog in het account van een vertrokken contractor is, heb je geen assuranceprogramma voor AI-ontwikkeling. Je hebt blootstelling met goede bedoelingen.
Verwacht ook stijgende externe druk. Auditors, cyberverzekeraars en enterprise-klanten zijn directe vragen gaan stellen over AI-gegenereerde code in securityvragenlijsten en leveranciersbeoordelingen. Hoe ze wordt beoordeeld, welke tests haar gaten, of er herkomst bestaat. Organisaties die vanuit een audit trail kunnen antwoorden, doorlopen die reviews als routine; organisaties die antwoorden improviseren, ervaren elke review als een brandoefening. De bewijsmachinerie nu bouwen, voordat een specifieke auditor haar eist, is wezenlijk goedkoper dan haar bouwen tijdens een bevinding.
Zeven controldomeinen voor AI-gegenereerde software
Elke eis in de checklist valt onder één van deze domeinen, en een gat in welk domein dan ook is waar je volgende incidentrapport zal beginnen.
- Herkomst en attributie. Elke wijziging herleidbaar tot de prompt of intentie die haar veroorzaakte, de agent of persoon die haar produceerde, en de mens die ervoor verantwoordelijk is. Zonder attributie kan niets stroomafwaarts, review, audit, incident response, functioneren.
- Wijzigingsgovernance. Beleid beslist welke wijzigingen automatisch mergen, welke vastgelegde menselijke goedkeuring vereisen, en welke gebieden, auth, betalingen, datatoegang, beschermde zones zijn die achteloze aanpassing weigeren.
- Geverifieerde security-testing. Statische analyse, dependency-checks en toegangscontrole-probes die continu draaien, met bevindingen bevestigd tegen de live applicatie, zodat je team echte kwetsbaarheden trieert in plaats van statische-analyse-weer.
- Identiteit en toegangscontrole. Het ontwikkelplatform zelf onder SSO met MFA en rolgebaseerde toegang, zodat wie mag prompten, goedkeuren en deployen met dezelfde strengheid wordt bestuurd als wie productie mag aanraken.
- Data- en modelvoorwaarden. Contractuele duidelijkheid dat je code en data niet worden gebruikt om modellen te trainen, retentievensters op inferentie, en gedocumenteerd gedrag wanneer een modelprovider wordt gewisseld of uitvalt.
- Deployment- en omgevingscontrole. Gegate releases met pre-publish checks en rollback, plus het vermogen om workloads te draaien waar beleid het vereist. Je eigen cloudaccount, private VPC of on-prem voor de workloads die dat eisen.
- Auditeerbaarheid en incidentgereedheid. Een append-only spoor over prompts, merges, deploys en admin-acties, exporteerbaar naar je auditors, compleet genoeg om elke wijziging maanden later onder incidentomstandigheden te reconstrueren.
De CISO-checklist
Formuleer elk punt als een eis om bewijs, niet als een vraag naar intentie. Voldoet een leverancier of intern team aan de eerste zeven, dan is de rest meestal een contracteeroefening in plaats van een engineeringoefening.
- ✓ Elke productiewijziging is herleidbaar tot een initiërende prompt of verzoek, een genererende agent of auteur, en een verantwoordelijke mens
- ✓ Beleid in gewone taal bepaalt welke wijzigingen automatisch mergen en welke vastgelegde menselijke goedkeuring vereisen
- ✓ Gevoelige gebieden, authenticatie, betalingen, datatoegang, PII-verwerking, zijn aangewezen beschermde zones met strengere gates
- ✓ Menselijke goedkeuringen worden vastgelegd, zijn attribueerbaar en permanent gekoppeld aan de specifieke wijziging
- ✓ Statische analyse en dependency-scanning draaien op elke wijziging, niet volgens een schema
- ✓ Toegangscontrole-probes testen de draaiende applicatie, en bevindingen worden live bevestigd voordat ze worden gemeld
- ✓ Geautomatiseerde tests inclusief browser-level checks gaten elke publicatie; fouten blokkeren standaard
- ✓ Het ontwikkelplatform dwingt SSO (SAML/OIDC), MFA en rolgebaseerde toegangscontrole af
- ✓ Klantcode en -data zijn contractueel uitgesloten van modeltraining; inferentie draait onder zero-retention-voorwaarden
- ✓ Modelprovider-failover bestaat en is gedocumenteerd, wat de afhankelijkheid van één leverancier vermindert
- ✓ Deployments passeren pre-publish smoke gates en post-publish productiechecks, met gedemonstreerde rollback
- ✓ Workloads kunnen draaien in je eigen cloudaccount, private VPC of on-prem waar classificatie dat vereist
- ✓ Een append-only audit trail overspant prompts, merges, deploys en admin-acties, en is exporteerbaar
- ✓ Leveranciersattestatie (SOC 2 Type II of gelijkwaardig) is beschikbaar onder NDA, met DPA- en subverwerkerstransparantie
Risico, control, bewijs
Voor elk hoofdrisico: de control die het adresseert en het artefact dat bewijst dat de control echt is. Gebruik de bewijskolom als agenda voor je volgende securitygesprek met een leverancier.
| Risico | Control | Bewijs om te eisen |
|---|---|---|
| Schaduw-AI-gebouwde apps | Gesanctioneerd beheerd platform dat goedkoper is om te gebruiken dan te omzeilen | Inventaris van AI-gebouwde apps met eigenaren en gezondheidsstatus |
| Onbeoordeelde risicovolle wijziging | Beleidsgates met vastgelegde menselijke goedkeuring | Een geblokkeerde wijziging en zijn audit-entry, live getoond |
| Kwetsbare gegenereerde code | Continue scanning geverifieerd tegen de live app | Recente bevestigde bevindingen met remediëringsspoor |
| Rubberen-stempel-review | Beleidstriage die mensen reserveert voor gemarkeerde wijzigingen | Metrics over goedkeuringslatentie en reviewdekking |
| IP- en datalekkage via modellen | No-training- en zero-retention-contractvoorwaarden | De clausules zelf, in de getekende overeenkomst |
| Onverantwoorde deployment | Gegate publicatie, productiechecks, rollback | Deploylogs en een rollback uitgevoerd op verzoek |
| Auditfalen | Append-only spoor van prompt tot productie | Een export overhandigd aan je auditteam voor een gesamplede wijziging |
Waar Ciao past
Ciao's governancelaag is precies tegen deze checklist ontworpen. Guardrails koppelt code aan bedrijfsdomeinen, detecteert risicovolle wijzigingen, past plain-English-beleid toe, legt menselijke review vast en laat een audit trail achter elke merge; het spoor is append-only en dekt prompts, merges, deploys en admin-acties. Security draait statische scanning, dependency-checks en toegangscontrole-probes, en bevestigt kwetsbaarheden tegen de live app voordat ze gemarkeerd worden. Het verschil tussen een bevindingenfeed die je team vertrouwt en een die ze dempen. QA gate elke publicatie met deterministische browserreplays en draait productiechecks erna.
Aan de leveranciersrisicokant: SOC 2 Type II-rapporten zijn beschikbaar onder NDA; het platform ondersteunt SSO via SAML en OIDC, optionele MFA en rolgebaseerde toegangscontrole; klantcode wordt niet gebruikt om modellen te trainen en inferentie draait onder zero-retention modelcontracten; en een multi-provider model ladder met fallback vermindert de afhankelijkheid van één enkele modelleverancier. Deploymenttargets omvatten je eigen AWS-, Azure- of GCP-account, private VPC, of on-prem onder aparte voorwaarden voor geclassificeerde workloads. Serieuze ontwikkelprogramma's beginnen bij USD 10.000 per jaar. Bouw je de interne standaard voor AI-ontwikkeling, vraag dan het securitypack op en scoor Ciao tegen elke regel hierboven.
Een uitrolsuggestie van teams die dit goed hebben gedaan: sequenceer het als inventaris, dan gesanctioneerd pad, dan migratie. Vind eerst welke AI-gebouwde software al bestaat en wie de eigenaar is; zet ten tweede het beheerde platform op en leid nieuwe bouwen erdoorheen; verhuis ten derde bestaande tools in volgorde van impactradius. De checklist zelf publiceren als je interne standaard, welk platform je ook kiest, verandert een diffuse zorg in een gescoord, belegbaar programma, en het geeft businessunits een helder antwoord op "wat zou dit oké maken?" in plaats van een gesloten deur.
Veelgestelde vragen
Is AI-gegenereerde code inherent minder veilig dan door mensen geschreven code?
Het eerlijke antwoord is dat het varieert per model, prompt en context, en dat de vraag minder belangrijk is dan ze lijkt. Volume en auteurschap zijn wat je risicopositie verandert, dus het duurzame antwoord is een systeem dat elke wijziging scant, verifieert en bestuurt, ongeacht wie of wat haar schreef.
Wat moet een CISO als eerste vragen aan een team dat al AI-ontwikkeltools gebruikt?
Een inventaris met eigenaren, daarna herkomst: laat me, voor een recente productiewijziging, het initiërende verzoek, de goedkeuring en het testbewijs zien. Het gat tussen wat teams denken te kunnen produceren en wat ze werkelijk kunnen, is de snelste eerlijke meting van je blootstelling.
Hoe voorkomen we dat review een rubberen stempel wordt naarmate AI het wijzigingsvolume opvoert?
Stop mensen te vragen alles te beoordelen en maak de triage expliciet: beleid wikkelt routinewijzigingen automatisch af en routeert consequentiële, op bedrijfsdomein, impactradius of datagevoeligheid, naar vastgelegde menselijke review. Security hoort dat beleid te bezitten, en goedkeuringslatentie plus dekking horen gevolgd te worden als elke andere controlmetric.
Doen zero-retention- en no-training-clausules er echt toe, of zijn het vinkjes?
Ze zijn de contractuele ruggengraat van je IP- en datapositie, en het moeten clausules zijn in plaats van blogposts. Op Ciao wordt klantcode niet gebruikt om modellen te trainen en draait inferentie onder zero-retention modelcontracten. De vorm van toezegging die je legal team kan afdwingen.
Hoe verschilt een audit trail voor AI-ontwikkeling van gewone git-geschiedenis?
Git legt vast wat er veranderde; een audit trail voor AI-ontwikkeling moet ook vastleggen waarom en onder wiens gezag. De initiërende prompt, de beleidsevaluatie, de vastgelegde menselijke goedkeuring, de deployment en zijn checks. In append-only vorm. Dat is het verschil tussen een incident in uren reconstrueren en in weken.
Kunnen gereguleerde workloads überhaupt op AI-gebouwde software draaien?
Ja, waar het leveringssysteem het bewijs levert dat toezichthouders verwachten: geattesteerde leverancierscontrols, bestuurde en vastgelegde wijzigingen, continue geverifieerde security-testing, en deployment in omgevingen die aan residentie- en isolatie-eisen voldoen. De checklist hierboven is feitelijk de gereedheidstest voor dat gesprek.