Als mensen horen dat ik een Ai-agent zonder toezicht op een live website laat sleutelen, is de eerste vraag bijna altijd dezelfde: “En als hij nou iets kapotmaakt?” Dat is precies de goede vraag. Alleen is mijn antwoord niet “dat gebeurt niet”, maar “dat heb ik van tevoren uitgetekend”. Op footballoracle.nl, mijn hobbyproject dat WK-voorspellingen doet, verbetert een agent de site ongeveer tien keer per dag. En het overgrote deel van mijn ontwerpwerk zat niet in wat die agent mag doen, maar in wat er gebeurt als het misgaat.

Ik noem dat de noodrem-mentaliteit: ontwerp eerst hoe je Ai faalt, dan pas wat hij oplevert. Failsafes zijn namelijk goedkoop, en incidenten zijn dat niet. In dit stuk laat ik zien welke vangrails ik heb ingebouwd en waarom elk ervan er zit.

De circuit-breaker: na twee missers stopt het feest#

De belangrijkste vangrail komt rechtstreeks uit de industriële techniek en de elektra: de circuit-breaker. Het principe is simpel. Gaat er twee keer achter elkaar iets fout, dan stopt de agent volledig met ingrijpen en schakelt hij over naar wat ik “observe-only” noem: hij mag nog wel kijken en meten, maar niet meer handelen. En hij stuurt mij een bericht.

Waarom twee keer, en niet drie of tien? Omdat één fout een incident kan zijn, maar twee op rij een patroon is. Als een agent twee pogingen achter elkaar de mist in gaat, is de kans groot dat er iets structureels mis is: een aanname klopt niet meer, een externe bron is veranderd, of de agent zit in een lus. Dan wil je niet dat hij vrolijk doorgaat en poging drie, vier en vijf ook verprutst. Je wilt dat hij stilstaat en een mens erbij haalt.

Dat laatste is cruciaal. Een circuit-breaker die alleen maar stopt en niemand waarschuwt, is een stille storing. Bij mij gaat er dus altijd een melding naar mijn telefoon zodra de breaker slaat, met de reden erbij. Zonder die twee helften (stoppen én seinen) heb je geen vangrail, maar een zwart gat waar werk in verdwijnt.

De pauzeschakelaar: één handeling en alles staat stil#

De tweede vangrail is bewust bijna dom in zijn eenvoud: een pauzeschakelaar. In mijn geval is dat letterlijk het bestaan van één bestand. Staat dat bestand er, dan slaat de agent bij zijn volgende ronde over en doet hij niets. Weg dat bestand, en hij pakt zijn werk weer op.

Waarom zo simpel? Omdat een noodstop betrouwbaar moet zijn op het moment dat je hem het hardst nodig hebt, en dat is meestal een moment van stress. Als ik ontdek dat er iets raars aan de hand is, wil ik niet eerst een dashboard openen, inloggen en drie menu’s diep klikken. Ik wil één handeling die gegarandeerd werkt en die de bloeding onmiddellijk stopt. De pauzeschakelaar is geen elegante feature, hij is een rem waar je met je volle gewicht op kunt gaan staan.

De stale-lock-detectie: vastgelopen is niet hetzelfde als bezig#

Een agent die ongeveer tien keer per dag draait, moet voorkomen dat twee exemplaren tegelijk aan het werk gaan. Daarvoor gebruik ik een lock: een markering die zegt “ik ben bezig, wacht even”. De volgende ronde ziet die markering en slaat over.

Maar wat als een run halverwege vastloopt en zijn lock nooit opruimt? Dan blijft die markering staan, en elke volgende ronde denkt braaf “er is er al eentje bezig” en doet niets. Je hele automatisering staat stil, en het ergste is: alles lijkt normaal, want er komt geen foutmelding. Dat is me een keer overkomen. Een vastgelopen run liet zijn lock bijna een etmaal staan en de site kreeg al die tijd geen enkele verbetering, zonder dat er ook maar iets rood kleurde.

De fix is de stale-lock-detectie. Een normale ronde is binnen een kwartier klaar. Dus als een lock ouder is dan een half uur, beschouw ik hem als dood: de vorige run is duidelijk vastgelopen, ik ruim de markering op en het werk kan weer verder. Het onderscheid dat de vangrail maakt is precies het goede onderscheid: is deze agent echt bezig, of alleen maar vastgelopen?

Score-tolerantie: niet elke daling is een ramp#

Op footballoracle.nl meet ik de kwaliteit van de site met een objectieve score voor snelheid, toegankelijkheid en vindbaarheid. De agent mag verbeteren, maar hoe voorkom ik dat een “verbetering” de boel stiekem slechter maakt?

Met een tolerantie. Na elke wijziging meet een deterministisch script (geen Ai, gewoon een vaste meting) de nieuwe score. Zakt die meer dan twee punten onder de uitgangswaarde, dan gaat de wijziging niet live en draait alles automatisch terug. Waarom twee punten speling en niet nul? Omdat dit soort metingen ruis bevat: dezelfde pagina scoort de ene keer net iets anders dan de andere, zonder dat er iets is veranderd. Zou ik op nul tolerantie staan, dan zou ik voortdurend goede wijzigingen terugdraaien om ruis. Twee punten is de marge die ruis toelaat maar echte achteruitgang tegenhoudt.

En als een wijziging sneuvelt? Dan gooi ik hem niet zomaar weg. De mislukte poging krijgt een label mee zodat ik hem later kan terugvinden en analyseren. Een mislukking is data, geen afval.

De checklist: wanneer mag Ai zichzelf herstellen?#

Al deze vangrails horen bij een grotere regel die ik voor mezelf heb opgeschreven. Een agent mag pas zelfstandig iets herstellen als aan vier voorwaarden is voldaan:

  1. Betrouwbaar signaal. Het probleem moet ondubbelzinnig vaststaan, niet “waarschijnlijk iets”.
  2. Idempotent. De actie twee keer uitvoeren mag geen extra schade geven.
  3. Kleine blast-radius. Als het tóch fout gaat, moet de schade klein en lokaal blijven.
  4. Omkeerbaar. Je moet het altijd terug kunnen draaien.

Voldoet een situatie niet aan alle vier, dan handelt de agent niet zelf maar meldt hij het. En rond die vier voorwaarden liggen de rails die ik hierboven beschreef: controleer de toestand vlak vóór je ingrijpt (is het probleem er eigenlijk nog?), hooguit twee tot drie pogingen, één agent tegelijk, en na afloop verifiëren op de meetwaarde die het probleem aangaf, niet alleen checken of het commando “gelukt” is. Dat laatste is een klassieke valkuil: een commando kan keurig slagen terwijl het probleem gewoon blijft bestaan.

Wat betekent dit voor jouw bedrijf?#

Je hoeft geen zelfverbeterende website te draaien om hier iets aan te hebben. Zodra je een Ai of een stuk automatisering iets zelfstandig laat doen (mail versturen, een bestand verwerken, een systeem bijwerken), gelden dezelfde vragen:

  • Wat gebeurt er na de tweede fout op rij? Als het antwoord “gewoon doorgaan” is, mist je een circuit-breaker.
  • Hoe zet je het in één handeling stil? Kun je dat niet, dan heb je geen noodrem.
  • Merk je het als de automatisering stilletjes vastloopt, of lijkt alles dan gewoon rustig?
  • Kun je elke actie terugdraaien, en controleer je achteraf of het probleem écht weg is?

De verleiding is om al die energie in de slimme kant te steken: wat kan de Ai allemaal. Mijn ervaring is dat de betrouwbaarheid juist zit in de saaie kant: hoe faalt hij netjes. Dat is geen rem op innovatie, het is de voorwaarde ervoor. Pas als het falen goed geregeld is, durf je een agent echt los te laten.

Wil je voor je eigen processen scherp krijgen wat een Ai-agent zelf mag doen en waar altijd een mens tussen moet zitten? Ik heb dat uitgewerkt in een gratis werkdocument, het Ai-stoplicht, dat je vindt bij de downloads. En loop je tegen een concrete situatie aan waar je wilt sparren over waar de vangrails moeten zitten, kijk dan op de consulting-pagina hoe ik werk.