Waarom je AI-beheerder niets mag mogen
Een agent die zelf mag ingrijpen voelt krachtig — en is precies daarom onbetrouwbaar. Over de scheiding tussen waarnemen, redeneren, handelen en onthouden, en de vangrails die daar minimaal bij horen.
De demo is altijd hetzelfde. Een AI-agent leest een monitoringmelding, redeneert hardop over de oorzaak, herstart de dienst en meldt trots dat het probleem is opgelost. Het ziet eruit als de toekomst. En het werkt — tot de agent een keer de verkeerde conclusie trekt en dezelfde vloeiende beweging maakt richting een handeling die je niet had gewild.
De verleiding: een agent die zelf mag handelen
Autonomie is aantrekkelijk omdat het de laatste stap wegneemt. Je hoeft niet meer te kijken, niet meer te klikken, niet meer wakker te liggen. Het systeem repareert zichzelf. Dat is precies het beeld waarmee agent-frameworks worden verkocht: geef het model gereedschap, en het lost het op.
Het probleem zit niet in het redeneren. Moderne modellen zijn verrassend goed in het herkennen van patronen in logs, het leggen van verbanden en het formuleren van een plausibele diagnose. Het probleem zit in de sprong van plausibel naar uitgevoerd. Een diagnose die voor 80 procent klopt is nuttig als advies en gevaarlijk als handeling — want de handeling is onomkeerbaar en de twijfel niet zichtbaar.
Waarom autonomie en betrouwbaarheid tegen elkaar in werken
Een beheersysteem wordt beoordeeld op iets anders dan een chatbot. Bij een chatbot is een matig antwoord vervelend; je vraagt het opnieuw. Bij een beheersysteem is een matige actie een incident. De waarde zit niet in het gemiddelde, maar in de staart: wat gebeurt er in het ene procent van de gevallen waarin het model het mis heeft?
Daar komt bij dat een autonome agent zijn eigen fouten versterkt. Herstart hij een dienst op basis van een verkeerd signaal, dan verandert de toestand van het systeem. De volgende waarneming is dus vervuild door zijn eigen ingreep. Wat begint als één misinterpretatie eindigt als een reeks handelingen die elkaar rechtvaardigen. Dat is geen modelprobleem, maar een architectuurprobleem.
Betrouwbaarheid in agent-systemen komt niet van een slimmer model, maar van een strengere scheiding tussen denken en doen.
De scheiding: vier lagen, vier rollen
De opzet die wij draaien gaat uit van vier gescheiden lagen, elk met precies één verantwoordelijkheid en precies één set rechten.
Waarnemen. Monitors verzamelen signalen: containerstatus, foutmeldingen, systeembelasting, gebeurtenissen uit de infrastructuur. Deze laag heeft geen mening en geen bevoegdheid. Hij registreert.
Redeneren. Het AI-brein leest die signalen, legt verbanden en formuleert een voorstel. Het cruciale punt: dit brein mag alléén voorstellen doen. Het kan zelf niets muteren. Geen toegang tot uitvoerende commando's, geen omweg, geen uitzondering voor spoedgevallen. Wat het brein produceert is tekst — een onderbouwd voorstel, meer niet.
Handelen. Eén aparte, kleine component mag daadwerkelijk muteren. Die component is bewust dom: hij redeneert niet, hij voert uit wat is goedgekeurd, en alleen binnen zijn eigen vangrails. Doordat deze laag geen taalmodel bevat, is zijn gedrag volledig te lezen uit code in plaats van uit een prompt.
Onthouden. Alles wat gebeurt komt terecht in één append-only logboek — een logboek waaruit niets wordt verwijderd of herschreven. Signaal, redenering, voorstel, goedkeuring, uitvoering én weigering krijgen hetzelfde correlatie-id. Daardoor lees je een incident terug als één verhaal, in plaats van als losse regels in vijf systemen.
De vangrails die er minimaal moeten zijn
De uitvoerende laag zit bij ons achter een keten van controles. Elke schakel kan de handeling alsnog tegenhouden. Deze lijst is bewust concreet, zodat je hem kunt overnemen:
1. Whitelist. Alleen expliciet toegestane handelingen zijn mogelijk. Alles wat niet op de lijst staat, bestaat niet voor de agent. Dit is een standaard-weigeren-model, geen filter achteraf.
2. Deny-list. Bovenop de whitelist staat een tweede lijst van handelingen die onder geen enkele omstandigheid mogen, ook niet als ze technisch binnen een toegestane categorie vallen. Twee lijsten in plaats van één, omdat de gevaarlijkste fout altijd het randgeval is.
3. Load-vangrail. Bij te hoge systeembelasting wordt elke mutatie geweigerd. Dit is de belangrijkste en meest contra-intuïtieve regel: juist op het moment dat het systeem het zwaarst wordt belast — en dus het meest alarm slaat — mag er niets worden veranderd. Zware belasting is namelijk vaak legitiem, en een ingreep maakt het alleen erger.
4. Onderhoudsstand. Een schakelaar die alle mutaties bevriest omdat er bewust zwaar of handmatig wordt gewerkt. Zonder deze stand vecht je automatisering met je eigen onderhoud.
5. Cooldown. Na een handeling geldt een wachttijd voordat een vergelijkbare handeling opnieuw mag. Dit is de rem op herstart-lussen: het systeem krijgt de tijd om te laten zien of de ingreep werkte.
6. Backup vóór elke actie. De toestand wordt vastgelegd voordat er iets verandert. Niet omdat we verwachten terug te moeten, maar omdat de kosten van een backup verwaarloosbaar zijn en de kosten van dataverlies dat niet zijn.
Daarbovenop staat de menselijke schakel. Elk voorstel van het brein wordt een goedkeuringskaart op een dashboard. Pas na akkoord van een mens voert de uitvoerende laag het uit. Die kaart is geen formaliteit: hij dwingt af dat de redenering leesbaar is voordat er iets gebeurt. Een voorstel dat je niet in één scherm kunt beoordelen, is een voorstel dat je niet had moeten goedkeuren.
Praktijkvoorbeeld 1: de timeout onder zware belasting
Een health-check liep in een timeout terwijl het systeem zwaar — maar volstrekt legitiem — belast was. Er was niets kapot. Er was gewoon veel werk aan de gang.
Een naïeve automatisering doet in dat geval iets voorspelbaars: de check faalt, dus herstart de container. Nog steeds fout, dus nog een keer. En nog een keer. Na drie mislukte pogingen escaleert het systeem naar een AI-diagnose, die vervolgens gaat zoeken naar een oorzaak die er niet is — op een moment dat het systeem juist het minst ruimte heeft voor extra werk. Je hebt dan drie onnodige herstarts, een verstoorde werklast en een diagnoseronde over een fictief probleem.
In onze opzet gebeurt er iets anders. De load-vangrail weigert de herstart, omdat de belasting boven de drempel ligt. De escalatie naar AI-diagnose wordt onderdrukt, omdat er geen uitgevoerde actie is om op te volgen. Wat overblijft is één regel in het logboek, met de volledige redenering erbij: dit signaal kwam binnen, dit was de gedachte, dit was het voorstel, en dit is de reden dat het niet is uitgevoerd. Geen incident, wel een spoor.
Praktijkvoorbeeld 2: de monitor die te ruim keek
Het tweede voorbeeld is minder spectaculair en juist daarom leerzaam. Een monitor controleerde of containers draaiden door te matchen op containernaam — maar niet exact. Het gevolg: false-positive alarmen dat een container offline was, terwijl hij gewoon liep onder een naam die net iets anders was dan de monitor verwachtte.
De oplossing was banaal: exacte namen gebruiken in plaats van gedeeltelijke overeenkomsten. Maar het punt is wat er zou zijn gebeurd als de agent zelf had mogen handelen. Dan had een slordige tekstvergelijking geleid tot herstarts van gezonde diensten. Niet omdat het model slecht redeneerde, maar omdat de invoer verkeerd was. Een agent is nooit betrouwbaarder dan zijn waarnemingslaag, en een menselijke goedkeuringsstap is de enige plek waar dat soort onzin nog wordt opgemerkt voordat het schade doet.
Deze twee gevallen zijn geen uitzonderingen die we achteraf hebben opgelost. Ze zijn de reden dat de architectuur is zoals hij is. Wie deze opzet in de praktijk wil zien draaien, kan de Sentinel-showcase bekijken.
Conclusie: de waarde zit in de weigering
Een AI-beheerder verdient zijn plek niet door wat hij oplost, maar door wat hij weigert te doen. Elke geweigerde herstart onder zware belasting, elke handeling die buiten de whitelist valt, elke escalatie die wordt onderdrukt omdat er niets is gebeurd — dat zijn de momenten waarop de architectuur zijn werk doet.
Dat betekent niet dat zo'n systeem foutloos is. Vangrails kunnen verkeerd zijn afgesteld, drempels kunnen te ruim of te streng staan, en een goedkeuringskaart is alleen nuttig als er iemand kritisch naar kijkt. Maar het verschil tussen een agent die adviseert en een agent die handelt is het verschil tussen een fout die je leest en een fout die je moet herstellen.
Wie een AI-beheerder overweegt, doet er goed aan de vraag om te draaien. Niet: welke handelingen mag de agent uitvoeren? Maar: welke handelingen kan hij aantoonbaar níét uitvoeren, ook niet als hij het heel graag wil? Het antwoord op die vraag bepaalt of je een beheersysteem hebt of een risico. Meer over hoe wij dit soort systemen bouwen, staat bij onze diensten.