Een lanceerdatum hoort te volgen op bewijs dat het product veilig te beheren is. Een production readiness checklist geeft founder en developer één gedeeld overzicht van wat aantoonbaar op orde is en wat nog openstaat.
Dit artikel behandelt 35 productchecks in zes gebieden, zes persoonsgegevenschecks voor situaties waarin de AVG (GDPR) van toepassing is, en drie routes om uw uitkomst te lezen. De gratis spreadsheet en pdf bevatten dezelfde vragen.
TL;DR
Een production readiness checklist is een lijst ja/nee-checks die toetst of een product echte gebruikers, persoonsgegevens en voorzienbare storingen aankan. Leg bij een AI-gebouwd product voor elk antwoord bewijs vast en los blokkerende punten op vóór klanten het product gebruiken. Een ingevulde checklist certificeert het product niet als veilig.
- De 35 productchecks dekken beveiliging en toegang, code en architectuur, betrouwbaarheid en kritieke flows, deployment en beheer, onderhoudbaarheid en code-eigendom, plus zeven checks voor producten die een AI-model aanroepen.
- De zes persoonsgegevenschecks dekken noodzakelijke verzameling, privé-standaardinstellingen, verwijderverzoeken, opslaglocaties, verwerkersovereenkomsten en eigenaarschap bij datalekken, elk gekoppeld aan het relevante AVG-artikel.
- De uitkomst begint bij blokkades: elk toepasselijk B-punt met “nee” of “weet ik niet” betekent eerst oplossen of verifiëren; drie of meer keer “weet ik niet” wijst op een onafhankelijke review.
De gids over AI coding in productie geeft de bredere context.
Wat is een production readiness checklist?
Een production readiness checklist legt vast aan welke voorwaarden software moet voldoen voordat klanten ervan afhankelijk worden. Production readiness betekent dat het product binnen het beoogde gebruik werkt en herstelt van voorzienbare storingen, zonder dat de bouwer elke interactie in de gaten houdt. De checklist maakt die voorwaarden toetsbaar.
Een AI-gebouwd product heeft deze checks ook nodig als de uiteindelijke applicatie nooit een AI-model aanroept. De zeven modelchecks gelden alleen wanneer een live functie verzoeken naar een model stuurt.
Een checklist is een zelfcheck; een onafhankelijke production readiness review onderzoekt het product en test het bewijs. De releaseplanning bepaalt hoe de gecontroleerde versie bij gebruikers komt. Een ingevuld formulier alleen is geen akkoord voor lancering.
Hoe gebruikt u de production readiness checklist?
De production readiness checklist werkt het best als founder en developer hem samen invullen: de founder bevestigt eigenaarschap en beoogd gebruik, de developer laat de technische maatregelen zien. Antwoord met ja, nee of weet ik niet. Een “ja” vraagt bewijs, zoals een testresultaat of configuratierecord, met productversie en datum.
B markeert een minimale lanceringspoort. Behandel “weet ik niet” als onopgelost, net als “nee”, tot iemand het antwoord verifieert. Begin vóór u een lanceerdatum vastlegt en herhaal de betrokken checks na grote wijzigingen.
Gebruik N.v.t. alleen met een schriftelijke reden, bijvoorbeeld voor betalingen in een product zonder betaalflow. Een niet-uitgevoerde check is geen N.v.t. De B-labels en de drempel van drie onbekende antwoorden zijn praktische prioriteringsregels, geen certificering of statistische score.
De production readiness checklist voor AI-gebouwde producten
De checklist bevat 28 algemene productchecks en zeven voorwaardelijke AI-modelchecks. B markeert 12 mogelijke lanceringspoorten, waaronder voorwaardelijke betaal- en modelpunten. Ook een punt zonder B kan de lancering blokkeren als testen een onaanvaardbaar risico bevestigt.
Beveiliging en toegang
Deze acht checks voor beveiliging en toegang vormen een vibe coding security-checklist met dezelfde bewijseisen als andere software. OWASP Top 10:2025 A01 plaatst toegangscontrole in vertrouwde server-side code of API’s. Het artikel over vibe coding-beveiligingsrisico’s licht de risico’s toe.
| # | Check | Waarom het telt | B |
|---|---|---|---|
| 1 | Worden login- en rechtencontroles voor elk beschermd verzoek op de server afgedwongen? | Server-side controles draaien op uw backend, buiten bereik van een bezoeker. | B |
| 2 | Is met twee testaccounts bevestigd dat het wijzigen van een record-ID geen privégegevens van een andere gebruiker toont? | Een geslaagde login moet nog steeds de datagrens van elke klant respecteren. | B |
| 3 | Staan privé-API-sleutels en andere secrets niet in browsercode of in de repositorygeschiedenis? | Publiceerbare sleutels verschillen van credentials die bevoorrechte toegang geven. | B |
| 4 | Zijn alle eerder gelekte sleutels vervangen en de oude sleutels uitgeschakeld? | Een zichtbare sleutel verwijderen stopt een gekopieerde sleutel niet. | B |
| 5 | Zijn databaserechten ingeschakeld en getest voor elke tabel die voor gebruikers toegankelijk is? | Elke blootgestelde tabel heeft regels nodig die passen bij de beoogde lezers en schrijvers. | B |
| 6 | Vereisen beheerdersaccounts multifactorauthenticatie? | Een extra verificatiestap beschermt accounts met ruimere toegang. | |
| 7 | Worden binnenkomende waarden op de server gevalideerd voordat ze data of acties beïnvloeden? | Controles in de browser zijn te omzeilen met directe verzoeken. | |
| 8 | Zijn externe packages gescand en zijn beveiligingsbevindingen beoordeeld op misbruikbaarheid? | Een scanresultaat vraagt een besluit over de getroffen versie en blootstelling. |
Maak bij gelekte API-sleutels onderscheid tussen privé-credentials en bewust publiceerbare identifiers. Leg het bewijs van vervanging vast bij punt 3 en 4.
Code en architectuur
Deze vier checks voor code en architectuur bepalen of het product begrijpelijk is en consistent te bouwen. Vraag waar kritieke regels staan en welke versies van afhankelijkheden worden gebruikt. OWASP A03:2025 behandelt het bijhouden van afhankelijkheden en controle op buildwijzigingen.
| # | Check | Waarom het telt | B |
|---|---|---|---|
| 9 | Zijn kritieke bedrijfsregels op één plek vastgelegd, zonder tegenstrijdige betaal- of loginlogica? | Herhaalde regels kunnen binnen hetzelfde product verschillende uitkomsten geven. | |
| 10 | Zijn ontwikkeling, staging en productie gescheiden, elk met eigen data en secrets? | Een omgeving is een aparte opzet voor bouwen, testen of gebruikers bedienen. | B |
| 11 | Zijn packageversies vastgelegd in een lockfile en de licenties geregistreerd? | Een lockfile legt versies vast zodat builds reproduceerbaar zijn. | |
| 12 | Kan een andere developer het datamodel uitleggen en aangeven waar kritieke regels draaien? | Kennis moet het vertrek van de oorspronkelijke bouwer overleven. |
Betrouwbaarheid en kritieke flows
Deze zes betrouwbaarheidschecks bepalen wat er gebeurt als klantprocessen falen en herstellen. De OWASP-richtlijn voor foutafhandeling scheidt interne foutregistratie van informatie die gebruikers te zien krijgen.
| # | Check | Waarom het telt | B |
|---|---|---|---|
| 13 | Zijn de toepasselijke kritieke flows, waaronder registratie, login, betaling en data-export, end-to-end getest? | B geldt als u betalingen aanbiedt; test ook mislukte en dubbele betalingen. | B |
| 14 | Tonen fouten een bruikbare melding en worden technische details privé vastgelegd? | Gebruikers hebben een vervolgstap nodig zonder interne fouten of credentials te zien. | |
| 15 | Hebben externe aanroepen timeouts en begrensde retries die geen betaling of andere schrijfactie herhalen? | Retries hebben waarborgen nodig tegen het twee keer uitvoeren van dezelfde actie. | |
| 16 | Draaien automatische back-ups volgens een vastgelegd schema? | Een schema maakt het mogelijke gat in herstelde data zichtbaar. | |
| 17 | Is het terugzetten van een back-up getest, met vastgelegd resultaat? | Een afgeronde back-uptaak bewijst niet dat herstel werkt. | |
| 18 | Is het product getest terwijl een kritieke externe dienst niet beschikbaar is? | Het product moet veilig falen en een eerlijke status tonen. |
Leg bij betalingen na een timeout de status vast die de klant ziet én het resultaat van de betaalprovider. Een screenshot van een werkende checkoutpagina is onvoldoende bewijs voor punt 13.
Deployment en beheer
Deze vijf checks voor deployment en beheer bevestigen dat storingen worden opgemerkt en hersteld. Het zijn readiness-poorten; de AI deployment checklist behandelt de releasevolgorde. Houd gedetailleerde uitrolinstructies in het releaseplan.
| # | Check | Waarom het telt | B |
|---|---|---|---|
| 19 | Bereikt een geteste storingsmelding een benoemde persoon? | Iemand moet de melding ontvangen en weten dat hij of zij eigenaar is van de reactie. | B |
| 20 | Zijn bruikbare logs beschikbaar zonder wachtwoorden, geheime sleutels of onnodige persoonsgegevens? | Logs moeten onderzoek ondersteunen zonder een nieuw risico te creëren. | |
| 21 | Kan het team een vorige werkende versie terugzetten en een gewijzigde databasestructuur opvangen? | Rollback betekent terug naar een werkende versie met compatibele data. | B |
| 22 | Volgen releases een vastgelegd, herhaalbaar proces met een review vóór productie? | Een tweede persoon moet hetzelfde releaserecord kunnen volgen. | |
| 23 | Is een benoemde persoon verantwoordelijk voor het live product en de externe diensten? | Eigenaarschap omvat leveranciersaccounts en incidentbesluiten na lancering. |
Een rollback hangt ook af van databasecompatibiliteit. Een oude build die start maar de huidige records niet kan lezen, is geen werkende herstelroute. Vraag om bewijs van de herstelroute.
Onderhoudbaarheid en code-eigendom
Deze vijf checks voor onderhoudbaarheid en code-eigendom bevestigen dat uw bedrijf het product kan beheren als bijdragers wisselen. Een README telt alleen als bewijs wanneer iemand anders hem met succes heeft gevolgd.
| # | Check | Waarom het telt | B |
|---|---|---|---|
| 24 | Beheert het bedrijf zelf de repository-, hosting-, facturatie- en domeinaccounts? | Een repository bevat code en historie; bedrijfstoegang moet een contract overleven. | B |
| 25 | Is de lijst van personen en diensten met toegang actueel? | Verwijder vertrokken bijdragers en onverklaarde serviceaccounts. | |
| 26 | Heeft een andere developer het product met de README kunnen draaien zonder hulp van de bouwer? | Een README is de schriftelijke installatiegids die met de code meekomt. | |
| 27 | Dekken herhaalbare tests de kritieke flows wanneer de code verandert? | Een eenmalig geslaagde test moet na latere wijzigingen controleerbaar blijven. | |
| 28 | Zijn bekende problemen vastgelegd met een eigenaar en een volgende actie? | Vastgelegde problemen zijn te prioriteren en over te dragen. |
Als uw product een AI-model aanroept
Producten die een AI-model aanroepen, hebben zeven extra checks nodig voor de verbinding tussen het model, uw data en de acties die het product toestaat. Least privilege betekent alleen de minimaal benodigde rechten toekennen. Prompt injection betekent dat een instructie in gebruikersinvoer of externe content probeert het gedrag van het model om te buigen. De OWASP-richtlijn over prompt injection adviseert gelaagde maatregelen, waaronder beperkte toolrechten en menselijke goedkeuring voor destructieve acties.
| # | Check | Waarom het telt | B |
|---|---|---|---|
| 29 | Zijn modelverbindingen en tools beperkt tot de minimaal benodigde data en acties? | Least privilege beperkt rechten, ook als een model een schadelijke instructie volgt. | B |
| 30 | Dekken prompt-injectiontests gebruikersinvoer en externe content, waarbij schadelijke uitkomsten worden geblokkeerd? | Test pogingen om het model naar ongeautoriseerde data of acties te sturen. | B |
| 31 | Worden dag- of gebruikerslimieten afgedwongen voordat de modelkosten het afgesproken plafond overschrijden? | Een factuurwaarschuwing alleen stopt extra verzoeken niet. | |
| 32 | Krijgen modelverzoeken een timeout en een duidelijke fallback als de provider uitvalt? | Fallbackgedrag vertelt gebruikers wat er gebeurde zonder een geslaagd resultaat te verzinnen. | |
| 33 | Zijn modelinteracties traceerbaar zonder onnodige prompt- of antwoordinhoud te bewaren? | Request-ID’s, uitkomsten en geredigeerde records kunnen voldoende zijn voor onderzoek. | |
| 34 | Wordt menselijke goedkeuring buiten het model afgedwongen vóór onomkeerbare acties? | De goedkeuring moet de specifieke verwijdering, betaling of het bericht dekken dat wordt uitgevoerd. | |
| 35 | Is er een verwerkersovereenkomst (artikel 28) als de modelprovider namens u persoonsgegevens verwerkt? | Een verwerkersovereenkomst legt vast hoe een provider data voor uw bedrijf behandelt. |
Een geslaagde prompt-injectiontest bewijst niet dat elke toekomstige aanval wordt tegengehouden. Houd toegangs- en goedkeuringscontroles buiten het model, en behandel een ontbrekende goedkeuringscheck voor een onomkeerbare actie als blokkade voor die functie. Waar een provider als uw verwerker optreedt, vereisen AVG-artikel 28 en de EDPB-richtsnoeren over verwerkingsverantwoordelijken en verwerkers een bindende verwerkingsafspraak. Is de AI-output zelf het product, zoals advies, scoring of diagnose, dan is daarnaast modelevaluatie nodig buiten deze checklist.
Drie of meer keer “weet ik niet” betekent dat de checklist technische opvolging nodig heeft. Een AI-built product review controleert de afgesproken onderdelen van uw codebase, met engineering en security samen onderzocht en bevindingen geprioriteerd in begrijpelijke taal.
Persoonsgegevenschecks onder AVG-artikel 25
AVG-artikel 25 vereist dat passende waarborgen in de verwerking zijn ingebouwd en dat standaard alleen noodzakelijke persoonsgegevens worden verwerkt. Controleer bij een AI-gebouwd product de instellingen voor verzameling, bewaring en toegang voordat u persoonsgegevens gebruikt. De EDPB-samenvatting van februari 2026 legt uit dat gegevensbescherming door ontwerp en door standaardinstellingen een doorlopende plicht is, ook voor kleine organisaties.
Zes datachecks vullen de 35 productchecks aan, samen 41 regels. Pas de relevante checks toe zodra u persoonsgegevens verwerkt, ook tijdens de ontwikkeling.
| ID | Persoonsgegevenscheck | Bepaling |
|---|---|---|
| P1 | Verzamelen formulieren en datastromen alleen wat elk vastgelegd doel nodig heeft, met gedefinieerde bewaartermijnen? | Artikel 25; dataminimalisatie en opslagbeperking. |
| P2 | Zijn profielen, records en deelinstellingen standaard privé waar openbare toegang niet nodig is? | Artikel 25; privacyvriendelijke standaardinstellingen. |
| P3 | Kan het team geldige verwijderverzoeken in alle relevante systemen uitvoeren en bewaaruitzonderingen uitleggen? | Artikel 17; rechten moeten in het product worden ondersteund. |
| P4 | Zijn opslaglocaties en toegang vanuit het buitenland bekend, met beoordeelde doorgifteafspraken? | Hoofdstuk V; hosting in de EU regelt toegang op afstand niet vanzelf. |
| P5 | Zijn er verwerkersovereenkomsten met hosting-, e-mail- en AI-providers die als verwerker optreden? | Artikel 28; beoordeel per provider de rol. |
| P6 | Is iemand aangewezen om een datalek te beoordelen en een eventuele melding aan de toezichthouder te doen? | Artikel 33; de meldtermijn hangt af van kennisname en risico. |
Hosting in de EU beantwoordt niet elke doorgiftevraag. Beoordeel ook supporttoegang vanuit het buitenland en subverwerkers. Een verwerkersovereenkomst regelt internationale doorgifte niet vanzelf.
Volgens artikel 33 en de EDPB-richtsnoeren over datalekken meldt u een datalek zonder onnodige vertraging en, waar mogelijk, binnen 72 uur na kennisname bij de bevoegde toezichthouder, tenzij het lek waarschijnlijk geen risico vormt voor de rechten en vrijheden van personen. In Nederland is dat de Autoriteit Persoonsgegevens. Wijs voor die beoordeling een vaste eigenaar aan. Deze checks afronden betekent niet dat u volledig aan de AVG voldoet.
Hoe leest u uw production readiness-uitkomst?
Een production readiness-uitkomst leest u aan de hand van onopgeloste voorwaarden, niet aan een totaalscore. Eén onopgeloste blokkade zet de betrokken lancering op pauze. De drie routes volgen de praktische regels van deze checklist; drie onbekende antwoorden is een signaal om hulp te zoeken, geen gevalideerde risicomaat.
| Uw uitkomst | Route | Volgende stap |
|---|---|---|
| Een toepasselijk B-punt is nee of weet ik niet | Eerst oplossen of verifiëren | Pauzeer de betrokken lancering tot de voorwaarde is aangetoond. |
| Drie of meer toepasselijke antwoorden zijn weet ik niet | Onafhankelijke review | Gebruik de onbekende punten om een production readiness review af te bakenen. |
| Alle toepasselijke B-punten zijn ja en er staat geen wezenlijk gat open | Door naar releaseplanning | Bekijk resterende punten en wettelijke eisen en bereid daarna de AI deployment checklist voor. |
Volg de routes in deze volgorde. Een bekende blokkade moet worden opgelost, ook als een review zinvol is. Elk onbekend B-punt vraagt verificatie. Geef niet-B-gaten een eigenaar en een volgende actie; escaleer bevestigde blootstelling van gevoelige data, bevoorrechte credentials of een ander onaanvaardbaar risico.
Los vóór de releaseplanning de toepasselijke wettelijke eisen op en controleer de redenen bij N.v.t. Alle B-punten met ja betekent dat de minimale poorten onderbouwd zijn. Neem het resterende werk op in de backlog met duidelijk eigenaarschap.
Wat een zelfcheck u niet vertelt
Een production readiness-zelfcheck kan niet aantonen dat elk relevant pad is onderzocht. Een “ja” bij punt 2 kan het accountscherm dekken, terwijl een exportendpoint nog records van een andere klant teruggeeft. Iemand moet de toepasselijke toegangspaden testen.
Founders kunnen accounteigendom en providerafspraken bevestigen; technische antwoorden vragen inspectie van code en deployment. OWASP A01:2025 neemt toegangscontroles op in unit- en integratietests.
Kies voor een onafhankelijke review als belangrijke antwoorden niet te verifiëren zijn of klanteisen verder gaan dan het beschikbare bewijs. Neem het ingevulde record mee om de onopgeloste onderdelen af te bakenen.
Hoe Sunbytes AI-gebouwde producten aan deze lijst toetst
Een production readiness checklist beschermt een lancering pas als elk “ja” steunt op bewijs uit de code en de deployment, niet op geheugen.
Sunbytes koppelt de checklist aan dat bewijs via de AI-built product review: software-engineers en securityspecialisten onderzoeken samen de afgesproken scope en testen toegang tussen gebruikers, oude credentials en uitval van externe diensten direct. Cybersecurity-oplossingen voegen de controlelaag toe wanneer bevindingen secrets, toegangsrechten of AVG-bewijs voor een klantaudit raken. Vraagt het herstel meer capaciteit dan uw team heeft, dan kan een dedicated software development team het werk oppakken. Samen voorkomen ze dat een lancering rust op antwoorden die niemand heeft geverifieerd.
Sunbytes is een in Nederland opgerichte partner voor technologie, cybersecurity en personeelsoplossingen, met het hoofdkantoor in Utrecht en een delivery hub in Ho Chi Minh-stad. In meer dan 15 jaar heeft Sunbytes ruim 300 projecten opgeleverd voor klanten in 20 landen, binnen een ISO/IEC 27001-gecertificeerd managementsysteem voor informatiebeveiliging. Die certificering geldt voor de eigen informatiebeveiliging van Sunbytes; uw product is daarmee niet gecertificeerd. Elke review wordt afgebakend rond de code, beveiliging, kritieke workflows en deployment-opzet van uw product, met bevindingen en een geprioriteerd actieplan in begrijpelijke taal. Herstel en hercontroles worden apart afgebakend, zodat u de reviewkosten los ziet van vervolgwerk en zelf kiest wie de fixes uitvoert.
Welke antwoorden staan bij u nog op “weet ik niet”? Bespreek uw checklist in een AI-built product review
