Een Ai-agent mag bij mij verrassend veel. Code schrijven, testen, verbeteren, foutmeldingen uitzoeken, hele stukken applicatie herbouwen. Wat hij níét mag, in geen enkel project, is op de knop drukken die iets naar productie zet.

Dat klinkt misschien overdreven voorzichtig voor iemand die zo’n beetje zijn hele werkdag door Ai laat ondersteunen. Maar het is precies andersom: juist omdat ik Ai zoveel laat doen, is die ene grens zo belangrijk. Een deploy naar productie is een eenrichtingsdeur. En door een eenrichtingsdeur laat je geen taalmodel lopen dat “denkt” dat het wel goed zit.

Waarom productie anders is dan al het andere#

De meeste dingen die een Ai-agent doet, zijn omkeerbaar. Schrijft hij slechte code, dan draai je de wijziging terug. Verpest hij een testomgeving, dan bouw je die opnieuw op. Vervelend, maar herstelbaar. De schade blijft binnen de muren.

Een deploy naar productie is dat niet. Dat is het moment waarop je wijziging de echte wereld raakt: echte klanten, echte data, echte facturen. Gaat het daar mis, dan is het niet “even terugdraaien in een testomgeving”, dan staat er een klant voor een kapotte applicatie, of erger, ziet iemand data die hij niet had mogen zien. Sommige deuren gaan maar één kant op. Precies die deuren wil je niet toevertrouwen aan een systeem waarvan de kern is dat het waarschijnlijkheden inschat.

Want dat is wat een taalmodel doet. Het is briljant in oordelen, patronen en taal, maar het is geen deterministische machine. Vraag het twee keer hetzelfde en je krijgt soms twee net iets andere antwoorden. Voor het schrijven en beoordelen van code is dat prima, zelfs een kracht. Voor het uitvoeren van een onomkeerbare handeling is het precies de verkeerde eigenschap. Daar wil je saaie, voorspelbare zekerheid: elke keer exact hetzelfde pad, geen verrassingen, geen creativiteit.

Hoe ik het in de praktijk scheid#

De oplossing die ik overal aanhoud, is een strikte taakverdeling tussen de slimme laag en de domme laag.

De Ai-agent bouwt en test, op een veilige omgeving. In mijn projecten mag een agent een wijziging maken en die neerzetten op een aparte testomgeving, los van productie. Daar draait vervolgens een verificatie: compileert het zonder waarschuwingen, slagen alle geautomatiseerde tests, komen de belangrijkste pagina’s netjes met een succesantwoord terug, werken de kernflows zoals inloggen en de hoofdactie? Pas als dat allemaal groen is, luidt het oordeel “klaar om te promoveren”. De agent commit zijn werk. Meer niet. Hij deployt nooit zelf.

Een dom script doet het gevaarlijke werk. En met “dom” bedoel ik een compliment: deterministisch, voorspelbaar, geen Ai. Dat script doet elke keer exact hetzelfde. Het legt eerst vast wat de huidige, werkende versie is, zodat er een ankerpunt is om naar terug te vallen. Dan zet het de nieuwe versie live. Het controleert of productie daarna nog gezond opstart. En gaat er iets mis bij die controle, dan draait het automatisch terug naar de vastgelegde vorige versie. Geen taalmodel dat ter plekke bedenkt wat te doen bij een probleem, maar een vast, uitgeschreven rollback-pad.

Op mijn hobbyproject, de voetbalvoorspelsite footballoracle.nl, draait dit patroon in volle glorie. Een optimalisatie-agent verbetert de site meerdere keren per dag, maar hij commit alleen. Een apart script zet het live, doet de gezondheidscheck, hermeet de prestaties en rolt automatisch terug als een score te ver zakt. De slimme agent beslist wát er moet gebeuren, het domme script voert het onomkeerbare deel uit.

Toen ik ditzelfde patroon nodig had voor een betaalde context, mijn zakelijke deploy-straat, heb ik bewust nóg een slot toegevoegd.

Voor betalende klanten: drie sloten en een mens#

Voor mijn hobby vind ik het prima dat de hele keten grotendeels vanzelf loopt. Zakt er een keer een score, dan draait het script het terug en heeft niemand er last van. Bij een betaalde klant liggen de risico’s anders, en dus ligt de lat hoger.

Daar heb ik het promotie-script zo gebouwd dat het standaard niks doet. Zonder een expliciet “ja, voer nu echt uit” laat het alleen zien wát het zou doen, zonder ook maar één echte handeling. En zelfs met dat groene licht controleert het eerst drie voorwaarden voordat het iets naar productie beweegt. Ontbreekt er één, dan weigert het en logt het de weigering:

  1. De wijziging is gekoppeld aan een concreet gepland werkitem. Geen losse, ongedocumenteerde ingrepen.
  2. De laatste verificatie op de testomgeving stond op “klaar om te promoveren”. Geen ongeteste code naar productie.
  3. De applicatie is technisch klaar om op de productie-infrastructuur te draaien.

En dan nog: de laatste, bewuste stap om het slot open te zetten, doe ik zelf. Niet de agent. Bij een omgeving waar echte klanten en echt geld in het spel zijn, hoort een mens die de knop indrukt en de gevolgen overziet.

Dat brengt me bij het principe waar het uiteindelijk om draait: de mate van autonomie hoort per project te verschillen, afhankelijk van wat er kapot kan. Mijn voetbalsite mag zichzelf de hele dag door live zetten, want de schade van een foutje is een tijdelijk lelijke pagina. Een omgeving waar facturen en klantgegevens omgaan, mag dat niet, want daar is de schade onomkeerbaar en het vertrouwen breekbaar. Dezelfde techniek, andere leiband. Niet omdat de ene Ai slimmer is dan de andere, maar omdat de deur achter de ene wél en achter de andere níét terug open kan.

Wat betekent dit voor jouw bedrijf?#

Je hoeft geen software te bouwen om deze les te gebruiken. Zodra je Ai processen laat aansturen, of het nu deployen is, mails versturen, betalingen doen of iets in een klantsysteem wijzigen, staat er ergens een eenrichtingsdeur. De kunst is die deur te herkennen en er een mens of een dom, voorspelbaar script voor te zetten.

  1. Scheid beslissen van uitvoeren. Laat Ai voorstellen, bouwen en beoordelen. Laat een deterministisch proces, een script of een mens, het onomkeerbare moment uitvoeren. Dat is geen wantrouwen tegen de Ai, het is de juiste gereedschapskeuze.
  2. Zet een terugval klaar vóór je de deur opent. Voor je iets onomkeerbaars laat gebeuren: leg vast hoe je terugkomt bij de vorige, werkende situatie. Een uitgeschreven rollback is goedkoper dan een incident.
  3. Stel de autonomie in per risico, niet per gemak. Bepaal per proces hoeveel de automatisering zelf mag, op basis van wat er kapot kan. Iets onschuldigs mag ruimte krijgen. Iets dat klanten of geld raakt, krijgt een mens ertussen.
  4. Maak de onomkeerbare handeling een bewuste, aparte stap. Niet iets dat “en passant” gebeurt aan het eind van een geslaagde run, maar een expliciet moment waarop iemand of iets met precondities de knal aftrapt.

De rode draad: Ai-gedreven, mens-bewaakt. De Ai doet het werk, ook ‘s nachts, ook als ik slaap. Maar de deuren die maar één kant op gaan, houd ik in menselijke handen of achter een script dat niet kan improviseren.

Zelf aan de slag#

Welke handelingen in jouw bedrijf zijn eigenlijk eenrichtingsdeuren, en welke mag Ai gerust zelf doen? Dat is precies de afweging die ik heb uitgewerkt in het Ai-stoplicht: een gratis hulpmiddel om per proces te bepalen wat een Ai-agent zelf mag, wat met melding, en wat nooit zonder jouw akkoord. Je vindt het bij de downloads.

Wil je samen kijken waar in jouw processen de eenrichtingsdeuren zitten en hoe je Ai veilig tot vlak daarvoor laat werken? Kijk dan op de consulting-pagina hoe ik werk.