Er is een moment waarop het griezelig wordt met Ai-agents, en dat is het moment waarop een agent zijn eigen code aanpast. Niet de code van een applicatie waar hij aan werkt, maar zijn eigen instructies, zijn eigen script, de logica die bepaalt wat hij doet. Op zo’n moment is de machine niet langer alleen uitvoerder, maar ook zijn eigen verbouwer.

Dat is precies wat een van mijn agents op een avond deed. En het ging goed. Niet door geluk, maar omdat er drie voorzorgen omheen stonden die van “een agent die zichzelf verbouwt” iets veiligs maakten in plaats van iets gevaarlijks. Ik schrijf dit op omdat de neiging om Ai zichzelf te laten verbeteren alleen maar groter wordt, en omdat de meeste mensen die daaraan beginnen die drie voorzorgen níét hebben ingebouwd.

Wat er precies gebeurde#

Een van mijn beheer-agents draait periodiek om te kijken of er werk te doen is op mijn server. Op een gegeven moment ontdekte die agent iets vervelends: door een tekortkoming in zijn eigen script werd bepaald werk dubbel opgepakt. Twee mechanismen triggerden op hetzelfde signaal, waardoor er een lus dreigde te ontstaan. Hij deed er twee keer zoveel werk voor niks.

In plaats van dat te melden en te wachten tot ik het zou oplossen, deed de agent iets opmerkelijks. Hij bepaalde welk stukje logica de dubbeling veroorzaakte, schakelde dat stukje uit, en loste zo zijn eigen probleem op. Een agent die zijn eigen gedrag corrigeert. Voor veel mensen is dat het punt waarop de nekharen overeind gaan staan, en terecht.

Want stel dat hij zich vergist had? Stel dat het “probleem” geen probleem was, en dat hij door zijn wijziging juist iets belangrijks had uitgezet? Dan had ik een agent gehad die stilletjes zijn eigen kerntaak had gesloopt, zonder dat iemand het doorhad. Dat is de nachtmerrie-versie van dit verhaal.

Die nachtmerrie bleef uit, en dat kwam door drie dingen die de agent deed voordat en nadat hij de knip zette.

Waarborg 1: een backup met tijdstempel#

Voordat de agent ook maar één letter van zijn eigen script veranderde, maakte hij een kopie van de oorspronkelijke versie, voorzien van een tijdstempel in de bestandsnaam. Zo simpel is het, en zo cruciaal.

Die backup is het ankerpunt. Als achteraf blijkt dat de wijziging verkeerd was, is er altijd een exacte, ongewijzigde versie om naar terug te vallen. Geen “ik denk dat het zo was”, geen reconstructie uit het geheugen, maar het echte bestand van vóór de ingreep, klaar om teruggezet te worden. Zolang die backup bestaat, is de wijziging omkeerbaar. En omkeerbaarheid is de eigenschap die het verschil maakt tussen een berekend risico en roekeloosheid.

Waarborg 2: een voorstel dat de wijziging beschrijft#

De agent schreef ook op wát hij ging doen en waarom. Niet in code, maar in gewone taal: dit is het probleem dat ik zie, dit is de wijziging die ik voorstel, dit is wat ik verwacht dat er daarna gebeurt.

Dat voorstel-document lijkt bureaucratisch, maar het doet twee dingen tegelijk. Ten eerste dwingt het de agent om zijn eigen redenering expliciet te maken. Een wijziging die je moet kunnen uitleggen, is een wijziging die je beter hebt doordacht dan een wijziging die je zomaar doorvoert. Ten tweede laat het een spoor achter dat ik als mens kan lezen. Ik kan later terugkijken en zien: dit heeft hij aangepast, om deze reden, met deze verwachting. Ik hoef niet uit de code te reconstrueren wat er gebeurd is, het staat er in mensentaal.

Een agent die zichzelf verbouwt zonder zo’n spoor achter te laten, is een black box die je gaandeweg minder begrijpt. Elke onverklaarde zelfwijziging maakt het geheel een stukje ondoorzichtiger. Het voorstel-document houdt de boel leesbaar.

Waarborg 3: verificatie achteraf#

En dan het laatste, misschien wel het belangrijkste: nadat de agent zijn script had aangepast, controleerde hij of het beoogde gedrag ook echt optrad. Hij liet zichzelf opnieuw draaien en keek: doe ik nu inderdaad niet meer het dubbele werk? Klopt het dat ik nu netjes één keer beslis in plaats van twee keer?

Zonder die controle weet je niets. Een wijziging maken en aannemen dat het goed zit, is precies de valkuil waar zoveel geautomatiseerd werk in trapt. De code is aangepast, dus het zal wel werken. Nee: aangepast is niet hetzelfde als werkend. Pas als je hebt gezien dat het beoogde effect optreedt, mag je concluderen dat de ingreep geslaagd is. De agent deed die controle, zag dat het klopte, en pas toen was de klus af.

Waarom deze drie samen het verschil maken#

Het mooie is dat de agent deze drie stappen deed zonder dat het expliciet in zijn opdracht stond. Hij had ergens de discipline meegekregen die het verschil maakt tussen improviseren en verantwoord ingrijpen. En die discipline valt in drie woorden samen te vatten: omkeerbaar, transparant, geverifieerd.

  • Omkeerbaar door de backup: er is altijd een weg terug.
  • Transparant door het voorstel: een mens kan achteraf begrijpen wat er gebeurde en waarom.
  • Geverifieerd door de controle achteraf: er is bewijs dat het beoogde effect optrad, niet alleen de aanname.

Haal er één weg en het kaartenhuis valt om. Zonder backup is een verkeerde wijziging blijvend. Zonder voorstel wordt je systeem een ondoorgrondelijke doos. Zonder verificatie weet je nooit of het werkte. Pas alle drie samen maken zelf-modificatie iets waar ik rustig van kan slapen.

Wat betekent dit voor jouw bedrijf?#

Je hoeft geen agents op een server te draaien om iets aan deze les te hebben. Zodra je Ai iets laat veranderen aan een proces, een instelling, een sjabloon, een regel in je administratie, geldt dezelfde vraag: is deze wijziging omkeerbaar, is ze transparant, en heb je gecontroleerd dat ze het beoogde effect had?

De meeste mensen die Ai zelfstandig dingen laten aanpassen, slaan minstens één van die drie over. Ze laten de Ai iets wijzigen zonder een kopie van het origineel te bewaren. Of ze krijgen geen uitleg bij wat er precies veranderd is. Of ze nemen aan dat het goed ging omdat er geen foutmelding kwam. Elk van die drie gaten is de plek waar het een keer misgaat.

De regel die ik overal aanhoud: laat een Ai-systeem pas iets aan zichzelf of aan een belangrijk proces veranderen als alle drie de waarborgen aanwezig zijn. Bewaar het origineel, laat de wijziging in gewone taal beschrijven, en controleer achteraf of het beoogde effect optrad. Is er ook maar één van de drie niet geregeld, dan is het geen zelf-verbetering, dan is het een gok.

Zelf aan de slag#

Welke wijzigingen mag een Ai-systeem in jouw bedrijf zelfstandig doen, en welke horen achter een menselijk akkoord te blijven? Die afweging heb ik uitgewerkt in het Ai-stoplicht, een gratis werkblad om per handeling te bepalen wat een agent zelf mag, wat met melding, en wat nooit zonder jou. Je vindt het bij de downloads.

Wil je samen kijken waar in jouw automatisering het verstandig is om Ai ruimte te geven, en waar juist niet, kijk dan op de consulting-pagina hoe ik werk.