AI-agents bouwen is geen modelkeuze meer, maar een governance-keuze

De agent-hype mist vaak het echte knelpunt

Veel gesprekken over AI-agents beginnen bij de verkeerde vraag: welk model is het slimst, snelst of meest indrukwekkend? Dat is begrijpelijk, want modelkwaliteit is zichtbaar. Een agent die goed redeneert, code schrijft of een taakketen afmaakt, voelt meteen als vooruitgang. Maar voor teams die AI in echte processen willen gebruiken, zit het knelpunt meestal ergens anders. Niet bij de demo, maar bij de vraag wie beslist, wie controleert, wat wordt vastgelegd en welk systeem uiteindelijk gelijk heeft.

Zodra een AI-systeem niet alleen tekst genereert, maar ook acties voorbereidt of uitvoert, verandert de ontwerpopgave. Een chatbot die een antwoord suggereert is iets anders dan een agent die een ticket sluit, een offerte aanpast, een pull request maakt, klantdata verrijkt of prioriteiten in een planning wijzigt. In dat tweede geval bouw je niet alleen een interface met een model. Je bouwt een beslislaag in je operatie.

Daarom is agentontwikkeling geen zuivere modelkeuze meer. Het is een governance-keuze. Je moet vooraf bepalen welke beslissingen bij mensen blijven, welke beslissingen door een agent mogen worden voorbereid, welke acties automatisch mogen gebeuren en welke acties altijd een review nodig hebben. Als je dat niet expliciet ontwerpt, ontstaat de governance alsnog, maar dan impliciet: in prompts, workarounds, losse scripts en gewoontes van gebruikers.

Van agency naar beslissingsrechten

Discussies over AI-agency, modelgedrag en zelfs bewustzijn kunnen snel abstract worden. Voor productteams is de praktische vertaling kleiner en nuttiger: als een systeem handelingsruimte krijgt, moet die ruimte begrensd zijn. Agency is dan niet een filosofisch label, maar een ontwerpvariabele. Mag de agent alleen waarnemen? Mag hij opties voorstellen? Mag hij een actie klaarzetten? Mag hij zelfstandig uitvoeren binnen vooraf bepaalde grenzen?

Een bruikbare manier om dit te structureren is werken met autonomielevels. Level nul is analyse: het systeem vat samen, classificeert of zoekt informatie, maar verandert niets. Level één is voorstelvorming: de agent maakt een conceptactie die een mens accepteert of wijzigt. Level twee is uitvoering met toestemming: de agent kan handelen nadat een mens expliciet akkoord geeft. Level drie is uitvoering binnen grenzen: de agent mag bepaalde acties zelfstandig doen, zolang meetbare voorwaarden kloppen. Level vier, volledige autonomie in kritieke processen, hoort zelden het startpunt te zijn.

Die indeling dwingt teams om concreet te worden. Een agent die leads verrijkt, heeft andere rechten nodig dan een agent die contractvoorwaarden aanpast. Een agent die codevoorstellen doet, vraagt andere review dan een agent die automatisch deployt. De governancevraag is dus niet: vertrouwen we AI? De vraag is: voor welke taak, met welke impact, onder welke voorwaarden en met welk herstelpad laten we dit systeem handelen?

Geleidelijke verschuiving van macht is een operationeel risico

Een nuttig risicomodel voor AI is niet het spectaculaire scenario waarin systemen van de ene op de andere dag alles overnemen. Voor organisaties is het realistischere risico vaak geleidelijker. Een team automatiseert eerst samenvattingen, daarna prioritering, daarna conceptbesluiten, daarna uitvoering van standaardgevallen. Elke stap lijkt logisch. Elke stap bespaart tijd. Maar na een aantal stappen kan blijken dat mensen niet langer begrijpen waarom bepaalde beslissingen worden genomen of waar ze nog kunnen ingrijpen.

Dat is geen reden om agents te vermijden. Het is wel een reden om delegatie zichtbaar te maken. Welke beslissingen verdwijnen uit menselijke review? Welke uitzonderingen worden nog gezien? Welke feedback krijgt het model of de workflow terug? Welke dashboards tonen fouten, onzekerheid en overruling? En wie heeft de bevoegdheid om een agent tijdelijk terug te zetten naar een lager autonomielevel?

Veel AI-projecten meten vooral outputkwaliteit: is het antwoord juist, is de code bruikbaar, is de samenvatting netjes? Voor agents is dat te beperkt. Je moet ook meten wat er met het proces gebeurt. Worden mensen afhankelijk van automatisch voorgestelde keuzes? Worden alternatieven minder vaak bekeken? Worden afwijkende gevallen sneller weggefilterd? Als beslissingsmacht langzaam verschuift, zie je dat niet altijd in één foutmelding. Je ziet het in veranderend gedrag rondom het systeem.

Evals zijn geen formaliteit, maar je stuurmechanisme

Bij klassieke software kun je veel gedrag vooraf specificeren. Bij AI-agents is gedrag vaak contextafhankelijker. Daarom zijn evals geen nice-to-have en ook geen academische bijzaak. Ze zijn het stuurmechanisme waarmee je bepaalt of een agent binnen acceptabele grenzen werkt. Zonder evals blijft agentkwaliteit een verzameling anekdotes: deze demo ging goed, die klantcase ging fout, deze prompt voelt beter.

Goede evals beginnen bij taken, niet bij algemene modelindrukken. Een agent die supporttickets routeert, moet worden getest op routeringsnauwkeurigheid, onzekerheidsherkenning, escalatiegedrag en omgang met ontbrekende informatie. Een agent die code wijzigt, moet worden getest op regressies, securitygevoelige patronen, leesbaarheid en aansluiting op bestaande conventies. Een agent die commerciële opvolging voorbereidt, moet worden getest op feitelijke juistheid, toon, toestemming en bron van klantinformatie.

Belangrijk is ook dat evals onderhoudbaar zijn. Een eenmalige testset bij de start van het project is onvoldoende. Processen veranderen, producten veranderen, gebruikers veranderen en modellen veranderen. Teams hebben daarom een ritme nodig: nieuwe foutgevallen toevoegen, grensgevallen bewaren, regressies volgen en evaluaties koppelen aan releases. Een agent zonder eval-ritme is moeilijk bestuurbaar, ook als de eerste versie goed lijkt te werken.

Onderhoudbare code en een duidelijk system of record

Agents worden vaak gepresenteerd als laag bovenop bestaande systemen. In de praktijk raken ze juist de kern van je architectuur. Ze lezen uit CRM, ERP, ticketsystemen, documentatie, codebases, spreadsheets en chatgeschiedenis. Ze schrijven soms ook terug. Dan wordt de vraag belangrijk: welk systeem is leidend? Waar staat de waarheid? En mag een agent eigen geheugen of afgeleide data gebruiken alsof die gelijkwaardig is aan formele bedrijfsdata?

Het system of record moet expliciet blijven. Als het CRM leidend is voor klantstatus, mag een agent-memory die status niet stilletjes overschrijven. Als het ticketsysteem leidend is voor supporthistorie, moet een samenvatting herleidbaar blijven naar het originele ticket. Als de codebase leidend is voor productgedrag, moet agentgegenereerde code door dezelfde review-, test- en releasepaden als menselijke code. Anders ontstaat een schaduwlaag waarin niemand precies weet wat waar is.

Daarbij hoort onderhoudbare code. Snelle agentprototypes groeien makkelijk uit tot ondoorzichtige ketens van prompts, tools, callbacks en tijdelijke uitzonderingen. Dat werkt zolang één bouwer alles begrijpt. Het faalt zodra meerdere teams erop moeten vertrouwen. Behandel agentworkflows daarom als productiesoftware: versiebeheer, logging, duidelijke interfaces, foutafhandeling, toegangsrechten, testdata en documentatie. Een agent is geen magische collega buiten je architectuur. Het is software die beslissingen beïnvloedt.

Sovereignty en infrastructuur zijn afhankelijkheidsvragen

Naast procesgovernance speelt ook afhankelijkheid van de stack. AI-teams maken keuzes voor modellen, inferenceproviders, cloudomgevingen, GPU-infrastructuur, vector databases, observability en agentframeworks. Sommige keuzes zijn later makkelijk te vervangen. Andere keuzes kruipen diep in je product, je dataflows en je kostenstructuur. Het is verstandig om dat vooraf als architectuurvraag te behandelen, niet pas als contractvraag wanneer het systeem al kritisch is.

Voor Europese teams kan digitale soevereiniteit een relevante lens zijn, zonder dat je er een slogan van hoeft te maken. De concrete vragen zijn nuchter: waar wordt data verwerkt, welke logging is beschikbaar, welke contractuele afspraken zijn nodig, welke componenten kun je auditen, en wat gebeurt er als een model, API of infrastructuurlaag verandert? Dat zijn geen abstracte beleidsvragen meer zodra een agent operationele taken uitvoert.

Ook infrastructuurafhankelijkheid verdient aandacht. Als optimalisaties, kernels, tooling en hardware-ecosystemen steeds nauwer met elkaar verweven raken, kan een technische keuze meer lock-in opleveren dan op het eerste gezicht zichtbaar is. Dat betekent niet dat teams alles zelf moeten bouwen. Het betekent wel dat ze moeten weten welke onderdelen vervangbaar zijn, welke prestaties afhankelijk zijn van specifieke leveranciers en welke migratiekosten acceptabel zijn.

Een praktisch kader voor controleerbare agentinzet

Een houdbare aanpak begint met een simpele beslismatrix. Zet per agenttaak minimaal zes kolommen naast elkaar: taaktype, autonomielevel, eval-dekking, menselijke review, impact op het system of record en afhankelijkheid van leveranciers of infrastructuur. Die matrix hoeft niet perfect te zijn. Hij moet vooral zichtbaar maken waar je bewust kiest en waar je nog op aannames draait.

Voor laag-risicotaken kan een agent veel vrijheid krijgen, mits logging en herstel eenvoudig zijn. Voor taken met klantimpact, juridische impact, financiële impact of productierisico hoort de lat hoger te liggen. Dan wil je strengere evals, expliciete review, duidelijke escalatie en een helder rollback-pad. De truc is niet om overal maximale controle op te zetten. De truc is om controle te laten passen bij de schade die een fout kan veroorzaken.

Mijn nuchtere advies: begin niet met de vraag hoe autonoom je agent kan zijn. Begin met de vraag welke beslissing je verantwoord kunt delegeren. Daarna ontwerp je het model, de tools, de evals, de menselijke review en het system of record daaromheen. Dan bouw je geen losse AI-demo, maar een controleerbare agentlaag die in je organisatie past.

Voor teams die AI koppelen aan commerciële of operationele processen, sluit dit direct aan op bredere automatisering. Wie een agent inzet in leadopvolging, support, planning of klantcommunicatie, moet dezelfde discipline toepassen als bij andere bedrijfskritische workflows. Meer automatisering zonder eigenaarschap levert geen schaalbaarheid op, maar extra onduidelijkheid. Meer automatisering mét governance kan wel degelijk ruimte creëren, omdat mensen dan weten wanneer ze kunnen vertrouwen, wanneer ze moeten controleren en wanneer ze moeten ingrijpen.