Een AI-app bouwen en die app live zetten zijn twee verschillende klussen. AI-tools versnellen de eerste. Voor de tweede heeft u nog steeds een doel, een eigenaar, een geteste weg terug en iemand die de eerste uren meekijkt nodig. Deze go-live checklist, ook wel AI deployment checklist genoemd, gaat over die tweede klus, voor founders en COO’s die een met AI-tools gebouwd product uitbrengen.
De checklist telt 25 controles in vijf fases: doelen en go/no-go, omgevingen en toegang, testen op staging, uitrol en monitoring, en rollback en herstel. De checklist gaat ervan uit dat het product al een readiness-check heeft doorstaan. Loop de lijst een paar weken vóór de lanceringsdatum door met degene die uw product bouwt. Voor de volledige route van prototype naar betalende gebruikers begint u met onze gids over AI-coding in productie.
TL;DR
Een go-live checklist is de lijst controles die een team uitvoert vóór, tijdens en na de release van een AI-app. Met de checklist heeft de release een doel en een eigenaar, is ze getest op staging, bereikt ze gebruikers in stappen, wordt ze vanaf het eerste uur bewaakt en is ze binnen enkele minuten terug te draaien.
- Doelen, eigenaar en go/no-go: één meetbaar releasedoel, een benoemde release-eigenaar, vastgelegde go/no-go-criteria en een stopregel, bijvoorbeeld een foutpercentage boven 2% gedurende 10 minuten.
- Omgevingen, sleutels en toegang: productie heeft een eigen omgeving, database en sleutels, er staat geen API-sleutel in de frontend-build en elke sleutel van een AI-aanbieder heeft een gebruikslimiet en een kostenalert.
- Testen op staging: de gebruikersacceptatietest is afgetekend, kritieke flows zijn na de laatste wijziging opnieuw getest en de AI-functie is getest met normale, lege en kwaadwillige invoer.
- Uitrol en monitoring: de eerste release gaat naar een pilotgroep, alerts komen binnen op de telefoon van een benoemde persoon en de app wordt 72 uur nauwlettend en 14 dagen dagelijks gevolgd.
- Rollback en herstel: de vorige versie is binnen 15 minuten terug te zetten, vóór de lancering één keer getest, met een vastgezette AI-modelversie en een kill switch voor AI-functies.
Wat een go-live checklist voor een AI-app omvat
Een go-live checklist omvat de release van een applicatie: de stap van een versie die werkt voor de bouwer naar een versie waarop echte gebruikers vertrouwen. Voor een AI-app telt de checklist in dit artikel 25 controles in vijf fases, van het releasedoel tot de rollback.
Twee begrippen lopen vaak door elkaar. Deployment zet een nieuwe versie van de app op de productieservers. Release maakt die versie beschikbaar voor gebruikers. Met een feature flag, een schakelaar die een functie aan- of uitzet zonder nieuwe deployment, kan een team op dinsdag deployen en op donderdag releasen. De go-live checklist dekt beide stappen.
De go-live checklist begint waar de production readiness checklist eindigt. De readiness-checklist vraagt of het product klaar is: toegangsregels, persoonsgegevens, foutafhandeling en eigenaarschap. De go-live checklist vraagt hoe u een product dat klaar is uitbrengt zonder onderweg de controle te verliezen.
Eén grens geldt. Het deployen van een machine-learningmodel dat uw team zelf heeft getraind, met datapijplijnen, modelkwantisatie, Kubernetes-clusters en drift- of biastests, vraagt om een aparte MLOps-checklist. Deze checklist is bedoeld voor producten die met AI-tools zijn gebouwd en een AI-model aanroepen via de API van een aanbieder, de manier waarop de meeste AI-producten van founders gebruikers bereiken.
De go-live checklist: 25 controles in vijf fases
De go-live checklist hieronder telt 25 controles in vijf fases. Controles met een B zijn blokkerende punten: een “nee” op een B-controle betekent dat de release wacht tot het punt is opgelost. Bij elke controle staat wie die beantwoordt, zodat een founder de lijst in één overleg met de bouwer kan doorlopen.
Fase 1: doelen, eigenaar en go/no-go
Fase 1 maakt van “we gaan volgende week live” een besluit met vastgelegde criteria. Zonder criteria gaat een release live omdat de datum is aangekondigd, niet omdat de app er klaar voor is. Vijf controles, waarvan twee blokkerend.
| # | Controle | Wie | Blokkerend |
|---|---|---|---|
| 1 | Er is één meetbaar releasedoel vastgelegd, bijvoorbeeld: 50 pilotgebruikers ronden de aanmelding af met een foutpercentage onder 1% | Founder | — |
| 2 | Er is een benoemde release-eigenaar en een go/no-go-tijdstip | Founder | B |
| 3 | De go/no-go-criteria zijn vastgelegd: alle B-controles op ja, gebruikersacceptatietest afgetekend, rollback getest | Founder + bouwer | B |
| 4 | Er is een stopregel vastgelegd, bijvoorbeeld een foutpercentage boven 2% gedurende 10 minuten, één mislukte betaling of AI-kosten boven het dubbele van een normale dag | Founder + bouwer | — |
| 5 | In de laatste werkdagen vóór de release gaan er geen nieuwe functies meer in, bijvoorbeeld de laatste 3 | Founder | — |
Fase 2: omgevingen, sleutels en toegang
Fase 2 zorgt dat de release terechtkomt in een productieomgeving die gescheiden, afgeschermd en beschermd is tegen oplopende AI-kosten. De OWASP Top 10 for LLM Applications 2025 noemt unbounded consumption (LLM10) als risico: ongecontroleerde verzoeken aan een model kunnen het budget opmaken of de dienst blokkeren voor echte gebruikers. De rate limits en gebruikslimieten in controle 10 en 11 beantwoorden dat risico.
| # | Controle | Wie | Blokkerend |
|---|---|---|---|
| 6 | Productie heeft een eigen omgeving, database en API-sleutels; ontwikkeling en staging kunnen niet bij productiedata | Bouwer | B |
| 7 | Er staat geen API-sleutel in de frontend-build of de coderepository, en elke sleutel die ooit is gelekt, is vervangen | Bouwer | B |
| 8 | Elke pagina en elk API-endpoint gebruikt HTTPS, en de hostingpartij versleutelt opgeslagen data | Bouwer | — |
| 9 | Toegang tot productie is beperkt tot benoemde personen met meerfactorauthenticatie, en een lijst toont wie mag deployen | Founder + bouwer | — |
| 10 | Rate limits per gebruiker en IP-adres beschermen inloggen, aanmelden en elk endpoint dat een AI-model aanroept | Bouwer | — |
| 11 | Elke sleutel van een AI-aanbieder heeft een maandelijkse gebruikslimiet en een kostenalert | Founder + bouwer | B |
Hoe API-sleutels uit code lekken en hoe u ze vervangt, leest u in gelekte API-sleutels.
Fase 3: testen op staging
Fase 3 test de release op staging, een kopie van productie die draait op testsleutels en testdata. AI-functies vragen om twee tests naast de normale gebruikersflows: hoe de functie reageert op ongebruikelijke invoer, en wat gebruikers zien als de modelaanbieder traag is of uitvalt.
| # | Controle | Wie | Blokkerend |
|---|---|---|---|
| 12 | De gebruikersacceptatietest (UAT) is afgetekend op staging | Founder | B |
| 13 | Aanmelden, inloggen, betalen en data-export zijn na de laatste codewijziging opnieuw getest | Bouwer | — |
| 14 | De AI-functie is getest met normale, lege, zeer lange en kwaadwillige invoer, en de antwoorden zijn vergeleken met afgesproken voorbeeldantwoorden | Founder + bouwer | — |
| 15 | Als de modelaanbieder traag is of uitvalt, zien gebruikers na een vaste time-out een duidelijke melding in plaats van een eindeloos laadscherm | Bouwer | — |
| 16 | De verwachte piekbelasting is één keer getest, bijvoorbeeld twee keer de pilotgroep tegelijk in de app | Bouwer | — |
Fase 4: uitrol en monitoring
Fase 4 beperkt wie de release als eerste ziet en maakt problemen binnen minuten zichtbaar. Teams die automatisch releasen via een CI/CD-pipeline leggen deze regels nog steeds zelf vast: de pipeline voert de release uit, maar bepaalt niet wie die als eerste krijgt.
| # | Controle | Wie | Blokkerend |
|---|---|---|---|
| 17 | De database is vlak vóór de release geback-upt, en databasewijzigingen zijn terug te draaien of werken nog met de vorige versie | Bouwer | B |
| 18 | De eerste release gaat naar een pilotgroep, niet naar alle gebruikers | Founder + bouwer | — |
| 19 | Uptime- en foutalerts komen binnen op de telefoon van een benoemde persoon, niet in een gedeelde inbox | Bouwer | B |
| 20 | AI-gebruik en -kosten worden de eerste 14 dagen dagelijks gecontroleerd, met een alert bij het dubbele van de verwachte dagkosten | Founder + bouwer | — |
| 21 | Gebruikers hebben één plek om problemen te melden, en meldingen komen bij de persoon met dienst | Founder | — |
Fase 5: rollback en herstel
Fase 5 is de weg terug, en AI-apps hebben daarin één extra punt nodig: de AI-modelversie. Aanbieders stoppen met modelversies op gepubliceerde data; de deprecations-pagina van de OpenAI API vermeldt uitfaseerdata voor oudere modellen. Een app die “het nieuwste model” aanroept, kan van gedrag veranderen zonder dat u zelf iets releaset.
| # | Controle | Wie | Blokkerend |
|---|---|---|---|
| 22 | De vorige versie is binnen 15 minuten terug te zetten, en dat terugzetten is vóór de lancering één keer getest | Bouwer | B |
| 23 | Elke release legt de gebruikte AI-modelversie en prompts vast, en de modelversie staat vast in plaats van op “latest” | Bouwer | — |
| 24 | AI-functies hebben een kill switch of feature flag die ze uitzet zonder nieuwe deployment | Bouwer | — |
| 25 | Een contactlijst voor incidenten noemt wie over een rollback beslist, wie gelekte sleutels vervangt en wie binnen 72 uur beslist over een melding op grond van artikel 33 AVG (GDPR) | Founder | — |
Is de tijd tot de lancering kort? Los dan eerst de negen B-controles op: 2, 3, 6, 7, 11, 12, 17, 19 en 22. De andere 16 controles beperken de schade van een mislukte release; de negen blokkerende punten bepalen of een mislukte release überhaupt te herstellen is.
Staan er nog meer dan twee blokkerende punten open?
Dat is gebruikelijk voor een product dat snel met AI-tools is gebouwd. Een AI-built product review controleert deployment en beheer samen met security en data: omgevingen en toegang, alerts, rollback en de AI-functies zelf. De bevindingen krijgt u in begrijpelijke taal, met de blokkerende punten eerst.
Big bang, gefaseerd, canary of shadow: welke releasestrategie past
Voor de meeste AI-apps met minder dan enkele duizenden actieve gebruikers is een gefaseerde release naar een benoemde pilotgroep de veiligste releasestrategie. Een gefaseerde release beperkt hoeveel gebruikers een foute versie zien, zonder de verkeersverdeling die een canary release nodig heeft.
| Strategie | Wat het inhoudt | Wat het vraagt | Past wanneer | Als er iets misgaat |
|---|---|---|---|---|
| Big bang | Alle gebruikers krijgen de nieuwe versie tegelijk | Niets extra | Interne tools met weinig gebruikers | Alle gebruikers worden tegelijk geraakt |
| Gefaseerd | Eerst pilotaccounts, dan 25%, dan alle accounts | Feature flags of schakelaars per account | De meeste AI-apps van founders | Alleen de pilotgroep wordt geraakt; de stopregel houdt de rest tegen |
| Canary | Zo’n 5% van het verkeer gaat naar de nieuwe versie en wordt vergeleken met de huidige | Hosting die verkeer per percentage verdeelt, plus automatische metingen | Apps met stabiel verkeer en iemand die de vergelijking volgt | Ongeveer 5% van de verzoeken wordt geraakt tot de rollback |
| Shadow | De nieuwe versie draait parallel op echte invoer; gebruikers zien nog de oude | Dubbele verwerking en extra modelkosten | Een AI-functie die een handmatige stap vervangt | Gebruikers merken er niets van |
| Blue-green | Twee identieke productieomgevingen; het verkeer schakelt tussen beide | Dubbele hosting tijdens de release | Apps die binnen seconden terug moeten kunnen | Alle gebruikers worden geraakt, maar terugschakelen kost seconden |
Wij raden een canary release alleen aan als uw hostingplatform het verkeer voor u verdeelt en iemand de vergelijking tijdens het releasevenster volgt. Shadow mode is de extra modelkosten waard als een AI-functie een handmatig proces vervangt en u eerst bewijs wilt dat de antwoorden goed genoeg zijn voordat klanten ze zien.
Elke releasestrategie hangt af van fase 5. Een gefaseerde of canary release beperkt de schade alleen als het team de uitrol kan stoppen en de vorige versie binnen enkele minuten kan terugzetten.
UAT-checklist: wat u vóór go-live op staging test
Een UAT-checklist beschrijft wat de toekomstige gebruikers van een app vóór go-live op staging bevestigen. De gebruikersacceptatietest (UAT) is de laatste test vóór een release. Een pilotklant of een collega uit operations voert de eigen taken uit op een stagingkopie en tekent af dat de app doet wat die moet doen. Voor een AI-app dekken acht controles het meeste af:
- Aanmelden, inloggen en wachtwoord herstellen werken voor een nieuw account.
- De drie belangrijkste gebruikerstaken lopen van begin tot eind.
- Betalen en terugbetalen werken in de testmodus van de betaalprovider.
- De AI-functie geeft een bruikbaar antwoord op normale invoer, op lege invoer en op één kwaadwillige invoer die de instructies probeert te omzeilen (een prompt-injectiepoging).
- E-mails en notificaties komen aan met de juiste afzender, en de links wijzen naar productie, niet naar staging.
- Twee testaccounts met verschillende rollen kunnen elkaars gegevens niet zien.
- De belangrijkste schermen werken in een mobiele browser.
- Een benoemde zakelijke gebruiker tekent af, met datum.
Staging draait op testsleutels en testdata. Wie echte klantgegevens naar staging kopieert, zet persoonsgegevens in een omgeving met zwakkere controles, en dat strookt niet met gegevensbescherming door ontwerp en standaardinstellingen uit artikel 25 AVG. Plan de UAT-ronde voordat de releasedatum vastligt, zodat een mislukte controle de datum verschuift in plaats van te worden overgeslagen.
Wie doet wat op de dag van de release
Een releasedag vraagt om vijf benoemde rollen, ook in een team van drie. Eén persoon kan meerdere rollen hebben, maar elke rol heeft vóór het go/no-go-tijdstip een naam nodig.
| Rol | Wie in een klein team | Verantwoordelijk voor |
|---|---|---|
| Go/no-go-besluit | Founder of COO | Keurt de release op het afgesproken tijdstip goed aan de hand van de vastgelegde criteria, of houdt die tegen |
| Deployment en rollback | Bouwer of developer | Voert de release uit en, als de stopregel afgaat, de rollback |
| Dienst (on-call) | Een benoemde persoon, vaak de bouwer | Volgt de eerste 72 uur de alerts en reageert erop |
| Gebruikers en support | Founder of customer success lead | Informeert pilotgebruikers over wat er veranderd is en stuurt meldingen door |
| Accounteigenaar | Wie de hosting- en AI-accounts beheert | Past gebruikslimieten aan, vervangt sleutels, controleert gebruik en facturen |
Escalatie van support volgt één route. Een melding van een gebruiker komt eerst bij support. Support geeft alles wat op een fout lijkt binnen het uur door aan de persoon met dienst. Die persoon beslist samen met de release-eigenaar over een rollback.
De go/no-go-criteria gaan over de releasedag. Of het product zelf klaar is, is een aparte vraag, die een production readiness review met bewijs beantwoordt voordat de releasedatum vastligt.
Wat u de eerste 14 dagen na go-live in de gaten houdt
Volg een AI-app de eerste 72 uur na go-live nauwlettend en controleer de app 14 dagen lang dagelijks, aan de hand van drempels die het team vóór de release heeft afgesproken. Drempels maken van monitoring een besluit: onder de lijn gaat u door, erboven grijpt u in.
| Signaal | Voorbeelddrempel | Actie |
|---|---|---|
| Uptime | Een storing langer dan 5 minuten | De persoon met dienst controleert de status van hosting en aanbieder; de release-eigenaar wordt geïnformeerd |
| Foutpercentage | Boven 2% van de verzoeken gedurende 10 minuten | Stop de uitrol; draai terug als het percentage niet daalt |
| Responstijd AI-functie | Gemiddeld antwoord trager dan de afgesproken grens, bijvoorbeeld 10 seconden | Controleer de status van de modelaanbieder; zet de terugvalmelding aan |
| AI-kosten | Meer dan het dubbele van de verwachte dagkosten | Controleer gebruik per gebruiker en rate limits; verlaag de limiet bij misbruik |
| Mislukte inlogpogingen | Plotselinge piek vanaf een paar IP-adressen | Scherp rate limits aan; controleer op pogingen tot accountovername |
| Gemelde foute of schadelijke AI-antwoorden | Meer dan het afgesproken aantal per dag, bijvoorbeeld 3 | Herzie prompts en modelversie; gebruik zo nodig de kill switch |
| Berichten van de modelaanbieder | Elke uitfaserings- of wijzigingsmelding voor uw model | Plan en test de overstap vóór de uitfaseerdatum |
De drempels in tabel 8 zijn voorbeelden. Leg vóór de release uw eigen getallen vast, op basis van wat de pilotgroep accepteert, en zet ze naast de stopregel uit controle 4.
Leg vanaf de eerste release twee leveringsmetrics vast die DORA definieert. Change fail rate is “the ratio of deployments that require immediate intervention following a deployment”. Failed deployment recovery time is “the time it takes to recover from a deployment that fails and requires immediate intervention”. Twee getallen per release laten zien of releases de eerste maanden veiliger worden.
Wanneer u terugdraait in plaats van vooruit te repareren
Draai terug als de stopregel afgaat, als gegevens of geld van gebruikers op het spel staan, of als de reparatie langer duurt dan de rollback. Vooruit repareren, dus een correctie uitbrengen in plaats van terug te gaan naar de vorige versie, past alleen bij een klein en afgebakend probleem met een bekende oplossing die snel te testen en uit te brengen is.
Een geteste rollback van minder dan 15 minuten (controle 22) maakt de keuze makkelijker, omdat terugdraaien dan weinig kost. Het eerste uur na een mislukte release volgt een vaste volgorde:
- Beslis: de release-eigenaar en de persoon met dienst spreken binnen 15 minuten na het alert af of er wordt teruggedraaid.
- Draai terug, of zet alleen de AI-functie uit met de kill switch als alleen die functie faalt.
- Controleer dat foutpercentage en responstijden weer normaal zijn.
- Controleer de gegevens die de foute versie heeft weggeschreven: dubbele bestellingen, beschadigde records, al verstuurde e-mails.
- Heeft de release een API-sleutel blootgelegd, vervang de sleutel dan bij de aanbieder. Een rollback zet code terug, maar trekt geen sleutel in (zie gelekte API-sleutels).
- Konden persoonsgegevens worden ingezien, beslis dan over een melding. Artikel 33 AVG verplicht een melding aan de Autoriteit Persoonsgegevens binnen 72 uur nadat u kennis kreeg van een datalek, tenzij het lek waarschijnlijk geen risico voor personen oplevert.
- Vertel pilotgebruikers wat er is gebeurd en wanneer de oplossing volgt.
Leg het incident daarna vast in de releasenotes en tel het mee in de change fail rate, zodat de volgende release begint bij wat er misging.
Hoe Sunbytes uw release vóór de lancering controleert
De releasecontroles die het vaakst falen, zijn de controles die een bouwer in eigen werk het lastigst kan beoordelen: een rollback die bestaat maar nooit is uitgevoerd, alerts die ‘s nachts in een inbox belanden die niemand leest, een AI-model dat op “latest” staat. Geen van die gaten komt in een demo naar boven. Allemaal komen ze naar boven in de eerste week van echt gebruik.
Sunbytes zoekt die gaten op in de AI-built product review, onderdeel van Transformatie-oplossingen. De review beoordeelt deployment en beheer samen met security en data, code en architectuur, betrouwbaarheid en onderhoudbaarheid, zodat een gat in de rollback wordt bekeken naast de code die de rollback moet terugzetten. De reviewers staan los van wie de bevindingen oplost, en elke bevinding wordt in begrijpelijke taal uitgelegd en gerangschikt, met de blokkerende punten eerst. Die rangorde sluit aan op de B-controles in deze lijst: uw team ziet wat vóór het go/no-go-tijdstip dicht moet en wat na de release kan volgen.
Twee andere onderdelen van Sunbytes komen er alleen bij als de bevindingen daarom vragen. Gaat een bevinding over toegang tot productie, het beheer van sleutels of het bewijs achter een besluit over artikel 33 AVG, dan richt Cybersecurity-oplossingen de maatregelen in. Vragen de reparaties vóór de lancering meer handen dan uw bouwer heeft, dan voegt een dedicated software development team senior engineers toe, doorgaans binnen 2–4 weken operationeel.
Toegang tot uw code en omgevingen tijdens de review valt onder het ISO/IEC 27001-gecertificeerde managementsysteem voor informatiebeveiliging van Sunbytes, met de opdracht aangestuurd vanuit Nederland. Voor een app met persoonsgegevens van Europese klanten blijft de review zelf zo binnen de maatregelen waar de go-live checklist om vraagt.
Komt uw lanceringsdatum dichtbij? Plan een AI-built product review voordat u het go/no-go-tijdstip vastlegt, zodat de blokkerende punten in deze checklist met bewijs worden beantwoord in plaats van met aannames.
