Alisina NawabiEen chatbot geeft antwoord. Een AI-agent handelt: hij roept tools aan, leest en schrijft in je systemen, stuurt mails, maakt records aan en verstookt ondertussen tokens. Dat maakt agents nuttig, maar het betekent ook dat een fout niet meer een raar antwoord is, maar een actie in de echte wereld. Een agent die de verkeerde klant mailt, een record overschrijft of in een lus belandt en in een nacht honderden euro's aan tokens opmaakt: het gebeurt, en zonder registratie kun je achteraf niet reconstrueren wat er precies is gebeurd.
Deze gids is voor wie agents van een experiment naar productie tilt: de ondernemer of het team dat een of meer agents laat draaien op echte data en echte processen, van een MKB-bedrijf tot een afdeling binnen een grotere organisatie. Het doel is concreet: je weet straks van elke agent-actie wie, wat, wanneer en met welke kosten, je hebt budgetten en een noodrem, en je logging voldoet aan wat de wet van je vraagt. Geen theorie, wel de stappen, de valkuilen en een eerlijke afweging tussen kant-en-klaar en zelf bouwen.
Waarom dit nu moet, niet straks
De businesskant is duidelijk: een agent die je niet kunt zien, kun je niet vertrouwen en dus niet opschalen. Maar er is ook een juridische laag. Onder de EU AI Act gelden de verplichtingen voor hoog-risico AI-systemen vanaf 2 augustus 2026 volledig. Twee artikelen raken precies het onderwerp van deze gids. Artikel 12 eist dat een hoog-risicosysteem technisch automatische registratie van gebeurtenissen (logs) over de hele levensduur mogelijk maakt, zodat je risico's, incidenten en wijzigingen kunt herleiden. Artikel 26 legt de gebruiker (deployer) op om die logs te bewaren voor een periode die past bij het doel, met een minimum van zes maanden, en om menselijk toezicht te beleggen bij mensen met de juiste bevoegdheid.
Valt jouw agent niet onder hoog-risico, dan zijn deze eisen niet wettelijk verplicht, maar ze zijn alsnog de blauwdruk voor een agent die je durft te laten draaien. Welke systemen wel onder hoog-risico vallen en wat je verder moet regelen, werk ik uit in een AI Act-nalevingschecklist met een praktisch stappenplan voor het MKB. Begin hoe dan ook bij het uitgangspunt dat elke agent-actie herleidbaar moet zijn.
Wat je nodig hebt
Voordat je begint, zorg dat je dit op orde hebt. Veel hoef je niet te kopen; de meeste bouwstenen zijn open source of zitten al in je cloud.
- Een inventarisatie van je agents. Welke agents draaien er, wat mogen ze (welke tools, welke systemen, welke modellen), en wie is eigenaar? Zonder die lijst monitor je gaten.
- Een centraal doorgeefpunt voor modelaanroepen. Een proxy of gateway waar elke aanroep doorheen gaat, zodat je op een plek logt, meet en afremt. LiteLLM is hiervoor de meest gebruikte open-source proxy; AWS-gebruikers kunnen Amazon Bedrock AgentCore inzetten.
- Een plek om logs en traces op te slaan, met voldoende retentie (minstens zes maanden voor de AI Act) en toegangscontrole. Dat kan een database zijn, een log-platform of een observability-tool.
- Een observability-tool die niet alleen losse aanroepen logt, maar hele agent-stappen (traces en spans) zichtbaar maakt: welke tool riep de agent aan, met welke input, wat kwam eruit.
- Afspraken over toezicht en escalatie. Wie kijkt mee, wie mag ingrijpen, en bij welke acties zet je een mens in de lus? Techniek zonder eigenaar is geen toezicht.
De stappen
Je bouwt een audit-trail door alle modelaanroepen door een centrale proxy te leiden, daar te loggen en te budgetteren, agent-stappen te tracen, en een kill-switch plus menselijke goedkeuring in te bouwen. Het resultaat: per actie weet je wie, wat, wanneer en wat het kostte, en je kunt op elk moment ingrijpen. Doorloop de stappen in deze volgorde.
Stap 1: Inventariseer en registreer je agents
Maak een eenvoudig register: per agent een naam, eigenaar, doel, de modellen en tools die hij mag gebruiken, en het classificatieniveau (raakt hij persoonsgegevens, geld, of kritieke systemen?). Dit is geen bureaucratie, het bepaalt welke agents strakke controle nodig hebben en welke licht mogen. Begin hier, want al het volgende hangt aan deze lijst.
Stap 2: Zet alle modelaanroepen door een centrale proxy
Laat geen enkele agent rechtstreeks naar de API van een modelaanbieder praten. Zet er een proxy tussen. Met LiteLLM draai je dat zelf: je geeft een master_key op, koppelt een database voor de administratie, en definieert je modellen in een model_list. Vanaf dat moment loopt elke aanroep via een endpoint dat je beheert, en dat is precies waar je gaat loggen en afremmen. Draai je op AWS, dan biedt Amazon Bedrock AgentCore een vergelijkbaar knooppunt met ingebouwde observability. Deze ene architectuurkeuze maakt al het andere mogelijk: zonder centraal punt log en budgetteer je versnipperd.
Stap 3: Geef elke agent een eigen sleutel met een tokenbudget
Geneer per agent (of per team) een virtuele sleutel in plaats van overal dezelfde API-key te plakken. In LiteLLM doe je dat via /key/generate, waar je meteen max_budget en budget_duration meegeeft, plus welke modellen die sleutel mag aanspreken:
curl http://0.0.0.0:4000/key/generate \
-H 'Authorization: Bearer <master-key>' \
-H 'Content-Type: application/json' \
-d '{"models": ["gpt-4"], "max_budget": 100, "budget_duration": "30d"}'
De proxy houdt de uitgaven per sleutel, gebruiker en team automatisch bij en blokkeert zodra het budget op is. Zo wordt een agent die in een lus belandt een geblokkeerde sleutel in plaats van een schrikfactuur. Stel ook rpm_limit en tpm_limit in om pieken af te toppen. De achterliggende mechanismen om je AI-rekening voorspelbaar te houden werk ik verder uit in een gids over tokenkosten van AI-agenten beheersen zonder verrassingen op de rekening.
Stap 4: Trace hele agent-stappen, niet alleen losse aanroepen
Een agent doet per taak vaak tien tot honderd modelaanroepen en tool-acties. Een platte log van losse calls vertelt je dan weinig. Je wilt traces en spans: de volledige boom van een taak, met per stap de input, de gekozen tool, het resultaat en de duur. Amazon Bedrock AgentCore Observability levert dit standaard: het geeft traces, spans, logs en metrics zoals sessieaantal, latency, tokengebruik en foutpercentages, in OpenTelemetry-formaat, met dashboards in Amazon CloudWatch. Wil je leverancieronafhankelijk en zelf-gehost werken, dan is Langfuse een open-source platform dat je met Docker of Kubernetes op je eigen infrastructuur draait en dezelfde traces, observaties en scores vastlegt. Kies een tool die OpenTelemetry spreekt, dan zit je nergens vast.
Stap 5: Bouw een kill-switch en menselijke goedkeuring in
Toezicht moet kunnen ingrijpen, niet alleen toekijken. Twee mechanismen horen erbij. Een kill-switch: een manier om een agent (of alle agents) per direct te stoppen, bijvoorbeeld door zijn sleutel in de proxy in te trekken of op nul budget te zetten. En menselijke goedkeuring voor onomkeerbare of gevoelige acties: de agent stelt de actie voor, een mens keurt goed of af voordat hij wordt uitgevoerd. AWS positioneert die menselijke controle bewust als rem op autonome AI-agenten, en dat is een verstandig uitgangspunt: hoe groter de impact van een actie, hoe meer een mens ertussen hoort. Laat afkeuringen, stops en goedkeuringen meelopen in dezelfde audit-log. Stuur kritieke meldingen naar een kanaal waar iemand ze ziet, bijvoorbeeld via een koppeling met Slack, zodat een ontspoorde agent geen stille gebeurtenis is.
Stap 6: Bewaar de logs en maak je rapportage klaar
Log per actie minimaal: tijdstip, welke agent, welke gebruiker/sleutel, de aangeroepen tool en input, het resultaat, het model, het tokengebruik en de kosten. Bewaar die logs minstens zes maanden (de AI Act-ondergrens voor gebruikers van hoog-risicosystemen) en beveilig ze tegen aanpassing: een audit-trail die je achteraf kunt bewerken, is geen audit-trail. Het zichtbaarheidsgat tussen wat agents doen en wat je kunt aantonen, is precies waar IBM Guardium zijn monitoring op AI-agents richt. Met de gegevens uit stap 2 tot en met 5 heb je de bron al; de rapportage is dan een kwestie van de juiste velden ontsluiten, niet van data verzamelen die je nooit had.
Valkuilen
- Loggen zonder context. Alleen prompts en antwoorden opslaan is te weinig. Zonder de tool-acties, de gebruiker en de kosten per stap kun je een incident niet reconstrueren. Log de hele trace, niet alleen de tekst.
- Eén gedeelde API-key voor alles. Dan kun je niets toerekenen, niets gericht afremmen en geen enkele agent stoppen zonder ze allemaal te raken. Een sleutel per agent of team is de basis.
- Budgetten als rapportage in plaats van als rem. Een dashboard dat achteraf laat zien dat je te veel uitgaf, helpt niet. Het budget moet hard blokkeren, niet alleen waarschuwen.
- Toezicht zonder eigenaar. Een kill-switch die niemand bewaakt, en goedkeuringsverzoeken die in een ongelezen inbox belanden, zijn schijnveiligheid. Beleg wie kijkt en wie mag ingrijpen.
- Logs die je kunt bewerken of die te kort bewaard blijven. Voor de AI Act is zes maanden de ondergrens, en de logs moeten betrouwbaar zijn. Bewaar ze onveranderlijk en lang genoeg.
- Pas inrichten als de agent al draait. Achteraf een audit-trail aanleggen over acties die al hebben plaatsgevonden, kan niet. De proxy en logging horen er te staan vóór de eerste productie-actie.
Kant-en-klaar vs. maatwerk
De drie hoofdroutes verschillen vooral in hoeveel je zelf in handen houdt en waar je vastzit.
| Aanpak | Wat je krijgt | Kosten | Let op |
|---|---|---|---|
| Cloud-platform (AWS Bedrock AgentCore) | Observability, traces en dashboards ingebouwd, weinig opzet | Verbruik via CloudWatch; AgentCore Observability heeft geen eigen tarief, je betaalt de telemetrie in CloudWatch | Sterke binding aan AWS; je data en logs leven in hun stack |
| Open source, zelf-gehost (LiteLLM + Langfuse) | Volledige controle, eigen data, leverancieronafhankelijk, OpenTelemetry | Geen licentiekosten voor de kern; wel je eigen hosting en beheer | Je beheert het zelf: updates, schaalbaarheid, beschikbaarheid |
| Maatwerk op je processen | Logging, budgetten en goedkeuringen precies op jouw agents, tools en rapportage-eisen | Hoogste opzet, laagste ruis daarna | Alleen zinvol als je workflows of compliance-eisen specifiek zijn |
Voor de meeste organisaties is de open-source route de verstandige middenweg: LiteLLM als proxy met budgetten en sleutels, Langfuse voor de traces, alles op je eigen infrastructuur. Je houdt je data in huis en zit aan geen enkele aanbieder vast. Zit je al diep in AWS, dan is AgentCore sneller opgezet, met als prijs de binding. Maatwerk loont pas als je agents of je rapportageplicht zo specifiek zijn dat de standaardtools je in een keurslijf duwen, en dan nog bouw je het bovenop dezelfde bouwstenen.
Wat je ook kiest, de volgorde blijft gelijk: eerst alles door een centraal punt, dan loggen, dan budgetteren, dan tracen, dan de noodrem. Een agent die je volledig kunt zien en op elk moment kunt stoppen, is geen rem op vooruitgang; het is precies de voorwaarde om hem op meer en belangrijker werk los te durven laten. De organisaties die straks het meest uit AI-agents halen, zijn niet degenen die het hardst van stapel liepen, maar degenen die hun agents durfden te vertrouwen omdat ze elke stap konden verantwoorden.
