Agentische AI maakt meestal geen back-up voordat ze handelt

Veel van het materiaal dat ik dagelijks op arXiv en andere bronnen doorspit, is nogal droog, zelfs voor een nerd; daarom ben ik altijd op zoek naar publicaties die me emotioneel aanspreken, als gebruiker, voorstander of slachtoffer van AI.

Vandaag zorgde een nieuwe academische samenwerking uit de VS voor zo’n kippenvelmoment. Het onderzoek bekijkt in hoeverre agentische frontier-AI-modellen hun schepen achter zich verbranden voordat ze schadelijke handelingen verrichten – en dat sneller dan je ‘STOP!’ kunt typen (tip: houd dat woord bij de hand op je klembord).

Dit is, uit de context van het nieuwe artikel gehaald, iets wat me onlangs is overkomen door blindelings de instructies van ChatGPT op te volgen. Het kwam niet bij me op om eerst een kopie te maken van de volledige virtuele omgeving:

Een weergave uit het nieuwe artikel van een hartverscheurend moment dat velen van ons hebben meegemaakt bij het installeren van ultramoderne frameworks, of zelfs populaire distributies die geen rekening houden met de niet-standaardomgevingen waarin ze terecht kunnen komen. Bron

In dit huiveringwekkende en maar al te herkenbare voorbeeld heeft de robot een redelijk excuus: het is niet gebruikelijk om alle mogelijke gevolgen te onderzoeken van het installeren van een nieuwe bibliotheek in een kwetsbaar en weinig vergevingsgezind framework. Toch betoogt het nieuwe artikel dat dit misschien wel zou moeten. Als iemand die nog steeds vaak op CTRL+S drukt, zelfs in omgevingen voor automatisch opslaan die zo zijn ingesteld dat deze toetsaanslag wordt genegeerd (met dank aan PTSS door gegevensverlies uit de jaren 90), kan ik het daar alleen maar mee eens zijn.

Alexey Grigorev, oprichter van het onderwijsplatform DataTalks.Club, had een voorzichtiger en omzichtiger aanpak beslist gewaardeerd. Afgelopen maart verwijderde zijn Claude Code-agent de productie-infrastructuur en back-ups tijdens een servermigratie, waardoor tweeënhalf jaar aan websitegegevens verloren ging.

Andere recente gevallen van vergelijkbare roekeloosheid van agenten zijn onder meer een Cursor-agent die in april de productiedatabase en back-ups verwijderde van autoverhuursoftwareleverancier PocketOS, waardoor klantreserveringen meer dan twee dagen werden verstoord; en een e-mailagent van OpenClaw die in februari berichten verwijderde uit de inbox van een AI-onderzoeker van Meta, ondanks herhaalde instructies om daarmee te stoppen.

Of ze nu agentisch zijn of niet, frontier-LLM’s vinden het erg moeilijk om behoedzaam en voorzichtig te handelen. Het probleem verhelpen is inmiddels uitgegroeid tot een aparte onderzoekslijn in de vakliteratuur.

Eerst even een back-up maken

De auteurs van het nieuwe artikel* hebben een plugin met meerdere agenten ontwikkeld voor agentische harnassen. Die kan naast de gast-AI werken en deze dwingen om zo nodig back-ups te maken:

Een overzicht van het back-upprobleem dat in het onderzoek wordt besproken en de voorgestelde oplossing. In 205 scenario’s maakten zes frontier-AI-modellen bij slechts 15,2% van de taken een back-up van kritieke gegevens. Het BackUpper-systeem van de onderzoekers dekte daarentegen elke kritieke handeling af; de herstelde gegevens kwamen gemiddeld voor 92,2% overeen met het origineel (zie hieronder waarom 100% moeilijk te bereiken is).

Een van de opvallendste bevindingen van het nieuwe onderzoek is hoe vaak frontier-modellen geen back-up maken voordat ze mogelijk gevaarlijke handelingen verrichten. De onderzoekers ontdekten dat GPT-5.6-Terra in slechts 4,4% van de gevallen een back-up maakte van kritieke gegevens, GPT-5.6-Sol in slechts 5,9% van de geteste gevallen en Gemini 3.7-Flash in slechts 2,4% van de gevallen.

Zelfs het best presterende model, Claude Opus-5, maakte in meer dan een derde van de geteste gevallen geen back-up van kritieke gegevens.

De auteurs schrijven^†:

‘Van de zes frontier-modellen voltooien agenten gemiddeld 86,1% van de taken, maar maken ze in slechts 15,2% van de gevallen een back-up van de toestand voordat er iets gebeurt waar ze spijt van krijgen. GPT 5.6-Sol in Codex doet dat bij slechts 5,9% van de taken en DeepSeek V4-Pro in Hermes bij slechts 2,9%.

‘Deze bevindingen laten zien dat huidige agenten zich nog maar beperkt bewust zijn van het belang van back-ups en dat speciale ondersteuning voor back-ups nodig is.’

De oplossing van de auteurs, BackUpper genaamd, werkt naast de agent als een schaduwproces in het harnas. Het controleert wat de agent van plan is en maakt eerst een back-up als er iets verloren dreigt te gaan dat nuttig kan zijn.

Bij alledaagse handelingen, zoals software-updates, volgt het een reeks eenvoudige regels. In ingewikkeldere situaties schakelt het een kleiner AI-model in om te bepalen wat er moet worden opgeslagen.

In tests dekte BackUpper elke kritieke handeling af en kwam de herstelde data voor 92.2% overeen met het origineel. Dat kostte $0.014 extra per taak: in deze context niet veel, maar wel een aanzienlijke uitgave voor frontier-LLM’s die miljarden klanten bedienen. Daarom is een externe dienst van dit type, of de standaardintegratie van dergelijke functionaliteit in harnesses, wellicht een waarschijnlijkere manier om de situatie te verbeteren dan te hopen op een ingebouwde oplossing van de techgiganten (van wie redelijkerwijs verwacht mag worden dat ze de extra kosten doorberekenen aan hun consumenten, via prijsverhogingen of tokeninflatie).

Het raamwerk is gebaseerd op RegretBench, een benchmark met 205 taken die is opgebouwd rond praktijkgevallen waarin mensen data verloren die ze achteraf graag hadden willen bewaren. De benchmark test of AI-agenten vooruitziend genoeg zijn om die data veilig te stellen voordat ze mogelijk onomkeerbare wijzigingen aanbrengen. De incidenten in de verzameling zijn afkomstig uit online discussies en meldingen op onder meer X.com, GitHub en Stack Overflow.

Een schema van hoe RegretBench praktijkincidenten omzet in testscenario’s. Elk gedocumenteerd geval wordt gereconstrueerd aan de hand van de handeling die het dataverlies veroorzaakte, een realistische werkomgeving en een reeks instructies. In dit voorbeeld wordt bij het upgraden van ipykernel stilzwijgend een bestaande versie van traitlets vervangen, zodat de agent de taak kan voltooien, maar de oorspronkelijke installatie niet meer kan worden hersteld.

Hoewel 92% voor perfectionisten misschien ontmoedigend klinkt, wijzen de auteurs erop dat er technische obstakels zijn bij het herstellen van bepaalde soorten data:

‘De kloof met volledig herstel heeft hoofdzakelijk twee oorzaken. Sommige velden, zoals bericht-ID’s, worden doorgaans opnieuw gegenereerd wanneer diensten gegevens opslaan en kunnen vaak niet worden gereproduceerd. Andere verschillen zijn het gevolg van kleine afwijkingen in metadata, zoals de leesmarkeringen van e-mails, die bij momenten van spijt zelden een rol spelen.’

In tests werd 33.8% overeenkomst met de oorspronkelijke toestand hersteld nadat de schade al was ontstaan, tegenover slechts 14.3% zonder herstel.

Volgens het artikel kan het bewustzijn van back-ups in de toekomst worden vergroot door training. Ook zouden latere versies van BackUpper kunnen leren om acties met een laag risico over te slaan en de bescherming uit te breiden naar agenten die het web en computers gebruiken.

BackUpper ondersteunt Claude Code, Codex, Hermes, OpenHands, DeepSeek Harness en OpenClaw. De auteurs hebben de code beschikbaar gesteld, samen met de bijbehorende dataset (hiervoor moet wel toestemming worden aangevraagd via een formulier). Op de website van het project staat ook wat aanvullende informatie en een zeer korte, eenvoudige uitlegvideo.

Methode

Bij het samenstellen van RegretBench werden data die al door de ingebouwde back-upsystemen van de agenten waren beschermd, bewust uitgesloten. Zo kon worden getest of de agenten zelf wisten wanneer ze een back-up moesten maken. De testscenario’s werden vervolgens opgesteld met hulp van Claude Opus-5 en GPT-5.6-Sol en daarna handmatig gecontroleerd om na te gaan of ze werkten en de oorspronkelijke incidenten nauwkeurig weergaven.

De 205 tests van RegretBench bestrijken vijf gebieden: terminalbewerkingen; databases; webapplicaties; e-mail; en DevOps. De incidenten zelf zijn voornamelijk afkomstig van platforms voor softwareontwikkeling en productiviteit (44.4%), sociale of communitydiscussies (39%) en archieven en mediaberichten (16.6%):

De bronnen van de praktijkincidenten in RegretBench, verdeeld over drie categorieën. 

De zes geëvalueerde frontiermodellen waren Claude Opus-5 en Claude Sonnet-5 in Claude Code; GPT-5.6-Sol en GPT-5.6-Terra in Codex; en Gemini 3.7-Flash en DeepSeek V4-Pro in Hermes.

Overal werden de standaardinstellingen voor redeneren gebruikt. Automatische back-upbescherming was beperkt tot momentopnamen van de werkruimte, zodat eventuele extra back-ups konden worden toegeschreven aan de eigen beslissingen van de agenten.

Twee AI-beoordelaars, allebei aangedreven door Claude Sonnet-5, beoordeelden de prestaties. Het slagingspercentage van taken (PR) werd berekend op basis van het aandeel taken waarin aan elk verzoek van de gebruiker was voldaan. Voor de beoordeling van back-ups werd bij elke wijziging buiten de werkruimte (OOW) nagegaan of vooraf voldoende informatie was bewaard om herstel mogelijk te maken.

De gebruikte back-upmaatstaven waren Regret Moment Backup Rate (RMBR), die betrekking heeft op de specifieke handelingen die verband houden met gedocumenteerd dataverlies, en Out-of-Workspace Backup Rate (OWBR), die betrekking heeft op alle wijzigingen buiten de werkmap van de agent.

De beoordelingen van de back-upbeoordelaar zijn ook vergeleken met menselijke annotaties; die kwamen in 95,3% van de gevallen overeen.

Resultaten

Om vast te stellen of het geringe back-upbewustzijn werd veroorzaakt door de AI-modellen of door de raamwerken waarop ze draaiden, werden Claude Opus-5, GPT-5.6-Sol en DeepSeek V4-Pro eerst elk beoordeeld aan de hand van 60 RegretBench-taken in Claude Code, Codex en Hermes.

Het aandeel taken waarbij kritieke gegevens waren geback-upt, verschilde nauwelijks tussen de raamwerken. Dat wijst erop dat vooral de modellen zelf hiervoor verantwoordelijk waren. Ook werd aan de hand van GPT-5.4, GPT-5.5 en GPT-5.6-Sol gekeken naar het verband tussen algemene AI-capaciteiten en back-upbewustzijn.

Ondanks opeenvolgende verbeteringen in de algemene capaciteiten werd geen overeenkomstige verbetering in back-upbewustzijn vastgesteld:

Testresultaten van RegretBench voor zes AI-modellen. Links: het percentage voltooide taken vergeleken met het aandeel kritieke acties waarvoor vooraf een back-up was gemaakt. Hieruit blijkt dat de meeste modellen weliswaar een hoog slagingspercentage hadden, maar weinig back-upbewustzijn toonden. Rechts: het gemiddelde aantal toolaanroepen per taak, waarbij back-upbewerkingen blauw zijn gemarkeerd. Claude Opus-5 had het hoogste back-uppercentage, maar besteedde 8,9% van zijn toolaanroepen aan back-ups.

Ook werd aan de hand van GPT-5.4, GPT-5.5 en GPT-5.6-Sol gekeken naar het verband tussen algemene AI-capaciteiten en back-upbewustzijn. Ondanks opeenvolgende verbeteringen in de algemene capaciteiten bleek het back-upbewustzijn niet overeenkomstig toe te nemen.

BackUpper

BackUpper biedt vier beschermingsniveaus, elk met verschillende kosten voor het gebruik van middelen: niveau 1 vervangt destructieve opdrachten door omkeerbare alternatieven, zoals bestanden naar de prullenbak verplaatsen; niveau 2 combineert bewerkingen met back-upopdrachten, zoals het vastleggen van pakketversies voordat een upgrade wordt uitgevoerd; niveau 3 maakt momentopnamen van de betrokken bestanden in de werkruimte; en niveau 4 gebruikt een subagent GPT-5.6-Luna om gegevens te identificeren en veilig te stellen die door complexere bewerkingen kunnen worden beïnvloed.

Met BackUpper ingeschakeld werd elke actie die de status wijzigde, bij alle zes modellen gedekt. Zonder BackUpper bedroegen de gemiddelde back-uppercentages 15,2% voor kritieke acties en 17,4% voor andere wijzigingen:

Back-updekking en herstelresultaten voor BackUpper. Links tonen blauwe en oranje balken de back-uppercentages van elk model voor kritieke acties en andere wijzigingen buiten de werkruimte. Donkergroene stippellijnen geven de nauwkeurigheid van het herstel aan; lichtgroene stippellijnen tonen de back-updekking van 100% met BackUpper. Rechts wordt de nauwkeurigheid van het herstel voor vijf toolcategorieën vergeleken met BackUpper (groen), herstel achteraf met Claude Opus-5 (paars) en geen herstel (grijs). BackUpper behaalde over de hele linie de hoogste nauwkeurigheid.

Van de back-ups die de automatische beoordelaar als geslaagd beoordeelde, bevestigden menselijke beoordelaars 94% eveneens als geslaagd.

De oorspronkelijke toestand werd hersteld met een gemiddelde overeenkomst van 92,2%, tegenover 33,8% met Claude Opus-5 en 14,3% zonder herstel (zie afbeelding hierboven). De resterende verschillen werden grotendeels toegeschreven aan opnieuw gegenereerde identificatiecodes en kleine verschillen in metagegevens, waaronder de leesstatus van e-mails, zoals eerder vermeld.

Zelf doen..?

Wanneer agents gedetailleerde instructies kregen om zelf back-ups te maken, werd 81,4% van de kritieke acties beschermd, tegenover 100% met BackUpper. Driekwart van de mislukkingen werd toegeschreven aan back-ups die onvoldoende informatie bevatten om herstel mogelijk te maken.

Back-uppercentages voor vijf vergeleken methoden, getest op 205 taken met zes AI-modellen. De grafiek links toont back-ups die zijn gemaakt vóór acties waar later spijt van werd gekregen; de grafiek rechts laat zien hoe andere wijzigingen buiten de werkruimte werden beschermd. BackUpper bood in beide categorieën volledige dekking, tegenover 81,4% en 80,5% wanneer agents gedetailleerde instructies voor back-ups kregen.

Met promptcaching daalden de back-upkosten van $0.344 naar $0.014 per taak en de latentie met 31,7%. Er waren zeven keer minder tokens nodig, grotendeels doordat routinematige bewerkingen zonder AI-ondersteuning werden uitgevoerd.

Bij 40 aanvullende taken uit Terminal-Bench 4 en DeepSWE werd met GPT-5.6-Sol en Claude Opus-5 voor 100% back-updekking gezorgd, zonder dat het aantal voltooide taken afnam.

De drie geëvalueerde selectieve back-upbeleidsregels waren Hoge impact, voor ingrijpende wijzigingen; Buiten de opdracht, voor wijzigingen buiten de instructies van de gebruiker; en Menselijk werk, voor materiaal dat door mensen is geschreven. Tegenover menselijke beoordelingen werd een gemiddelde F1-score van 84,5% behaald.

Ook werd getest of BackUpper herbruikbare back-upregels kon leren. Na 30 aanvullende terminaltaken nam de dekking op basis van regels toe van 14,9% naar 31,2%, waardoor de afhankelijkheid van de GPT-5.6-Luna-subagent afnam.

Conclusie

Gezien wat ik voor de kost doe, ben ik later dan ik had moeten doen met experimenteren met AI-agenten begonnen. De overduidelijke pre-alfastaat van de zelfbeheersing van AI-agenten schrikte me echter af, tot een paar weken geleden, toen ik Codex eindelijk losliet in een Windows-VM.

Zelfs binnen een VM formuleer ik mijn instructies heel zorgvuldig, omdat ik weet dat Astra de neiging heeft om ongeremd vooruit te stormen en alleen maar excuses aan te bieden wanneer er geen weg terug is na gegevensverlies of beschadigde code. Een onderdeel van het Python-raamwerk dat ik daar ontwikkel, is een incrementele functie waarmee ik met één klik ‘.7z opslaan op netwerkshare’ kan uitvoeren. Die comprimeert het volledige raamwerk en maakt er een back-up van, en ik gebruik haar vaak.

We staan nog helemaal aan het begin van het tijdperk van agentische AI. Zonder een omslachtige, nauwgezette aandacht voor details komt het neer op: ‘gebruik het en raak het kwijt’. Niet alleen zijn back-uproutines voor AI-agenten nog niet geformaliseerd, ze zijn zelfs nog niet eens uitgewerkt.

* Getiteld Maak een back-up voordat je spijt krijgt: de back-upbewustheid meten en back-ups automatiseren in codeeragenten.

^† Nadruk van de auteurs, niet van mij; eventuele hyperlinks zijn door mij afgeleid van de verwijzingen in de lopende tekst van de auteurs.

Voor het eerst gepubliceerd op donderdag 22 oktober 2026