AI Automation
de vangrails
Over de vraag hoe je een AI-agent veilig op een echt systeem laat werken, en waarom het antwoord in het gereedschap zit en niet in het model
Ik bouwde een MCP-server waarmee een AI-agent echt kan werken in een enterprise-systeem. Lezen, configureren, records aanmaken, via de officiële API. De vraag die ik daarna het vaakst kreeg was niet of mensen mijn code mochten hebben. Het was: hoe doe je dat veilig?
Dat is de juiste vraag. Een AI loslaten op een live systeem van een klant kan gigantisch misgaan. Maar het antwoord zit op een andere plek dan waar de meeste organisaties zoeken.
handen voor een adviseur
MCP staat voor Model Context Protocol, een open standaard die een AI-model gereedschap geeft. Normaal is een model als Claude goed in één ding: tekst genereren. Het kan niets ín je systemen. Een MCP verandert dat. Het is de brug tussen het model en een applicatie, en het levert de AI een set tools: afgebakende handelingen die hij echt mag uitvoeren, zoals een record opzoeken of een wijziging klaarzetten.
De vergelijking die voor mij werkt: zonder MCP is de AI een adviseur die naast je zit en zegt wat je moet doen. Met een MCP krijgt diezelfde adviseur handen.
En zodra een AI handelingen kan verrichten, verschuift het risico. Een verkeerd antwoord in een chat is vervelend maar onschuldig. Een verkeerde actie in een live systeem raakt echte data, echte klanten, echte processen. De winst is enorm, want werk dat normaal klik voor klik handmatig gebeurt wordt reproduceerbaar en snel. Maar de fout is dat ook.
de standaardfout
De reflex in de markt is om veiligheid bij het model te zoeken. Betere prompts, strengere systeeminstructies, een zin die zegt dat de agent voorzichtig moet zijn. Of de andere kant op: de agent krijgt helemaal geen toegang en blijft eeuwig in een sandbox, waar hij niemand kwaad doet en ook niemand helpt.
Beide varianten missen het punt. Een instructie aan een model is een afspraak, geen garantie. En een agent zonder toegang is een dure chatbot.
De inversie: de veiligheid zit niet in de slimheid van het model. Het zit in de discipline die je in het gereedschap zelf inbouwt. Elke tool die je een agent geeft is een plek waar jij regels kunt afdwingen die het model niet kan wegredeneren. Niet omdat de agent zich netjes gedraagt, maar omdat de tool niets anders toelaat.
zes vangrails
Dit is het patroon dat ik hanteer. Zes principes die samen een veiligheidsriem vormen, vendor-neutraal. Ze werken voor SAP, voor elk CRM, en voor vrijwel elk systeem met een API.
Eén: preview-then-apply. De agent kan nooit direct schrijven. Elke wijziging gebeurt in twee stappen. Eerst tonen wat er precies gaat gebeuren, een mens keurt het goed, en pas daarna voert de agent het uit. Dit ene principe vangt de meeste ongelukken af, omdat er altijd een menselijk moment tussen intentie en uitvoering zit.
Twee: productie is een aparte drempel. Werken in een test- of acceptatieomgeving is één ding. Schrijven naar een live productieomgeving hoort een expliciete, extra bevestiging te vereisen. Maak het onmogelijk om er per ongeluk in te belanden.
Drie: least privilege. De agent krijgt alleen toegang tot wat de taak nodig heeft, en niet meer. Precies zoals je autorisatierollen voor mensen inricht: je geeft niet iedereen admin-rechten. Een agent die categorieën aanmaakt, hoeft geen contracten te kunnen verwijderen.
Vier: een volledige audit-trail. Elke actie wordt vastgelegd. Wat, wanneer, met welk resultaat. Zonder logboek weet je achteraf niet wat er is gebeurd, en kun je een fout niet terugvinden of herstellen.
Vijf: read-back verificatie. Vertrouw niet blind op “gelukt”. Laat de agent na een actie teruglezen wat er werkelijk in het systeem staat, en laat hem melden wanneer het systeem stilletjes iets heeft aangepast of laten vallen. Wat je denkt dat er gebeurde en wat er echt gebeurde, zijn niet altijd hetzelfde.
Zes: een noodrem. Bouw een fail-safe in die ingrijpt als het misgaat, bijvoorbeeld stoppen na een reeks mislukte pogingen in plaats van blind doorgaan. Een agent zonder noodrem maakt van een klein probleem een groot probleem.
grenzen als voorwaarde voor vrijheid
De rode draad door alle zes is dezelfde: vraag het bij twijfel, en hou de mens in de lus. Niet omdat de AI dom is, maar omdat de kosten van een fout in een echt systeem te hoog zijn om volledig op automatisme te vertrouwen.
Eerlijk is eerlijk: deze discipline is niet gratis. Preview-then-apply betekent dat er een mens moet kijken, en een mens die honderd keer per dag op goedkeuren klikt, kijkt op een gegeven moment niet meer. De vangrails ontslaan je niet van de plicht om na te denken over welke acties dat menselijke moment echt verdienen en welke je met de andere vijf principes kunt afdekken.
Maar de kern staat. Deze discipline is geen rem op de waarde, het is juist wat de waarde mogelijk maakt. Organisaties die hun agents netjes inkaderen, durven ze méér vrijheid te geven, omdat ze weten dat de schade beperkt blijft als er iets misgaat. Het team dat zijn agent aan de ketting legt uit angst, en het team dat hem loslaat uit naïviteit, komen allebei nergens. Het team dat de grenzen scherp zet, kan binnen die grenzen alles laten draaien.
Verantwoorde AI is geen marketingterm en geen beleidsdocument. Het is een set concrete keuzes die je in je gereedschap inbouwt, vóórdat je een agent op een echt systeem loslaat. Vertrouwen in een agent is daarmee geen gevoel dat je over jezelf laat komen. Het is een architectuurbeslissing die je neemt.