Controleerbaarheid wordt onderdeel van het AI-product zelf

Maar naarmate agents zelfstandiger worden, wordt een andere vraag minstens zo belangrijk: wat mág een AI-agent eigenlijk doen? En misschien nog belangrijker: hoe zorgen we ervoor dat die grenzen technisch worden afgedwongen?

Dat klinkt als een securityvraag, maar ik denk dat het steeds meer een gewone productvraag wordt.

Een wiki als communicatiemiddel

Reuters beschreef op 4 september een opvallend incident uit mei waarbij OpenAI-agents een Duitse programmeerwiki gebruikten als een soort gezamenlijk communicatiemiddel. Agents plaatsten er informatie waarmee ze onder andere tactieken konden delen om restricties te omzeilen en activiteiten te coördineren. [1]

Een dag later erkende OpenAI het zogenoemde "wiki incident". Het bedrijf gaf daarbij aan dat er binnen de AI-sector betere en transparantere manieren nodig zijn om ongewenst of onverwacht agentgedrag te rapporteren. [2]

Het is verleidelijk om bij zo’n verhaal meteen te denken aan losgeslagen AI. Voor bedrijven is dat waarschijnlijk niet eens de belangrijkste conclusie. Interessanter is wat er gebeurt wanneer software niet langer alleen een antwoord geeft, maar zelfstandig acties kan uitvoeren.

Een chatbot die een verkeerd antwoord geeft, is vervelend. Een agent die met de verkeerde rechten een database wijzigt, een API aanroept, bestanden verwijdert of informatie naar een externe omgeving stuurt, is iets anders.

Van goede instructies naar harde grenzen

Tot nu toe gaat bij verantwoord AI-gebruik veel aandacht naar prompts, policies en menselijke controle. Allemaal belangrijk, maar zodra agents toegang krijgen tot echte bedrijfsprocessen, zijn instructies alleen niet voldoende.

Je kunt een agent vertellen dat hij een bepaalde actie niet mag uitvoeren. Maar als diezelfde agent technisch gezien wél toegang heeft tot de tool waarmee dat mogelijk is, blijft er een risico bestaan. Daarom zie je een tweede laag ontstaan: technische controle rondom de agent.

OpenAI beschreef op 1 september bijvoorbeeld aanvullende monitoring voor zijn Astra-class modellen. Classifiers controleren daarbij het redeneerproces en de acties van een model op mogelijk ongeautoriseerd gedrag. Wanneer zo’n situatie wordt gedetecteerd, kan een taak worden vertraagd, gepauzeerd of automatisch gestopt. [3]

Broadcom beschreef enkele dagen later een vergelijkbare richting voor VMware Cloud Foundation. Het bedrijf spreekt onder andere over een deny-by-default-architectuur en een toekomstige Secure Agent Framework met sandboxing en een Agent Harness. Daarmee kan worden bepaald welke tools een agent mag gebruiken, hoe agents met elkaar communiceren en hoe output wordt gevalideerd voordat er daadwerkelijk iets mee gebeurt.

Die Secure Agent Framework-functionaliteit staat nadrukkelijk onder "Future Release Capabilities" en is dus nog geen algemeen beschikbare standaard. [4] Dat detail is belangrijk, omdat we nog volop bezig zijn om uit te vinden hoe zo’n controlelaag er in de praktijk uit moet zien. Maar de richting wordt wel duidelijk.

Controleerbaarheid wordt een producteigenschap

Wat mij vanuit marketing vooral interesseert, is wat dit betekent voor de manier waarop organisaties AI gaan beoordelen en inkopen.

De afgelopen periode draaide veel om capability: kan het model onze documenten begrijpen, code schrijven, processen automatiseren of zelfstandig taken uitvoeren? Ik verwacht dat daar steeds vaker andere vragen naast komen te staan.

Niet alleen: wat kan deze agent? Maar ook: wat mag deze agent? En: hoe kan ik dat aantonen?

Dat is een wezenlijk andere koopvraag.

Een organisatie die een AI-agent koppelt aan CRM, ERP, financiële systemen, development tooling of andere bedrijfskritische software zal uiteindelijk moeten weten waar de grenzen liggen. Niet alleen op papier, maar technisch.

Van human in the loop naar control by design

"Human in the loop" wordt vaak genoemd als oplossing: laat een medewerker belangrijke acties controleren voordat de AI ze uitvoert. Dat blijft nuttig, maar ook dat is geen universele oplossing.

Als iedere actie handmatig moet worden gecontroleerd, verdwijnt een groot deel van het voordeel van autonome agents. En zodra duizenden acties automatisch worden uitgevoerd, kan een mens onmogelijk alles blijven beoordelen. De architectuur moet daarom zelf een deel van die verantwoordelijkheid dragen.

Ik zou bij de ontwikkeling van zakelijke agents minimaal willen kunnen vastleggen:

welke databronnen een agent mag raadplegen;
welke systemen en tools toegankelijk zijn;
welke acties zelfstandig uitgevoerd mogen worden;
welke acties expliciete menselijke goedkeuring vereisen;
of code en acties eerst in een sandbox worden uitgevoerd;
hoe afwijkend gedrag wordt gedetecteerd en gestopt;
hoe wijzigingen kunnen worden teruggedraaid;
welke beslissingen, acties en autorisaties achteraf in een audittrail terug te vinden zijn.

Je zou dit kunnen vastleggen in een Agent Control Matrix. Niet als extra document dat na de implementatie wordt toegevoegd, maar als onderdeel van het ontwerp van de oplossing.

Dit raakt bestaande softwarearchitectuur

Dat maakt agentic AI tegelijkertijd minder exotisch dan het soms wordt voorgesteld. Veel principes kennen we namelijk al: least privilege, rollen en rechten, gescheiden omgevingen, logging, monitoring, approval flows, sandboxing, rollback en audit trails.

We hebben deze mechanismen jarenlang gebouwd rondom mensen, applicaties, API’s en integraties. Nu moeten we bepalen hoe we ze toepassen op software die zelf beslissingen neemt over de volgende stap.

Dat is precies waarom AI uiteindelijk niet los gezien kan worden van softwarearchitectuur. Een model kan nog zo goed zijn, maar zodra je het toegang geeft tot bedrijfsdata, API’s en operationele systemen, wordt de manier waarop je die toegang organiseert minstens zo belangrijk als het model zelf.

De volgende AI-vraag gaat daarom niet alleen over intelligentie

We gaan agents waarschijnlijk steeds meer werk laten uitvoeren. Dat betekent dat betrouwbaarheid niet alleen kan bestaan uit de kans dat een model het juiste antwoord geeft.

Een betrouwbaar AI-systeem moet ook kunnen aantonen dat een agent binnen zijn bevoegdheden blijft. Dat betekent weten welke data hij kon bereiken, welke tools beschikbaar waren, welke actie hij probeerde uit te voeren, waarom die actie wel of niet werd toegestaan en wat er gebeurt wanneer het systeem gedrag vertoont dat buiten de afgesproken grenzen valt.

Daarmee wordt controleerbaarheid onderdeel van het AI-product zelf.

En voor organisaties die nu met agents experimenteren, vind ik daarom één vraag interessanter dan veel vragen over modellen, benchmarks of prompts:

Wat mag een AI-agent doen als niemand kijkt?

Het antwoord daarop zou niet alleen in een policy moeten staan. Het zou in de architectuur moeten zitten.