Waarom de goedkeuring van een kleine pilot met een AI agent maanden duurt

Een team wil een AI agent uitproberen voor één duidelijk afgebakende taak. Bijvoorbeeld binnenkomende verzoeken sorteren of eerste antwoorden op routinevragen opstellen. De pilot is klein, duurt een paar weken en heeft betrekking op één proces. Toch duurt de goedkeuring maanden.

Dit komt vaak voor bij overheidsinstellingen en in gereguleerde sectoren. Eén team meldde dat elke kleine AI-toepassing binnen de organisatie een schriftelijk voorstel vereiste, een sponsor vanuit de business, goedkeuring van de kosten door Financiën, meerdere governancerondes, een beveiligingsbeoordeling en een gegevensbeschermingseffectbeoordeling (DPIA). De meeste projecten kwamen niet eens tot de livegang. Een ander team, bij een financiële instelling, meldde dat goedkeuring door de governanceafdeling een van de grootste obstakels was bij de inzet van agents. De zorg was concreet: kon de agent de verkeerde gebruikers aanmaken of hun de verkeerde rechten toekennen?

Het is makkelijk om het proces de schuld te geven. Maar dat is niet helemaal terecht. De beoordelaars hebben een belangrijke taak.

Een AI agent is geen chatvenster. Het is een programma dat gegevens leest, beslissingen neemt en via tools acties uitvoert. Wilt u eerst de basis kennen? Lees dan wat een AI agent is. Voor een beoordelaar betekent dit dat het risico niet alleen zit in wat het model zegt, maar ook in wat het systeem kan bereiken.

Een beveiligings- of privacyfunctionaris die een pilotaanvraag ontvangt, kent het systeem niet. Die kan het niet even in één middag testen. Daarom stelt die vragen. Elke vraag gaat terug naar het pilotteam. Het team legt de vraag voor aan de leverancier. Het antwoord komt terug en leidt vaak tot twee nieuwe vragen. Elke ronde kost een week of twee.

Daar gaan de maanden naartoe. Niet naar de beoordeling zelf, maar naar het wachten tussen de verschillende rondes.

Als u kijkt naar wat beoordelaars vragen, is de lijst kort. De details verschillen per organisatie, maar de kern blijft hetzelfde:

Wat draait waar? Welke onderdelen draaien op onze eigen machines en welke draaien elders? Welke gegevens verlaten onze omgeving? Welke gegevens gaan naar buiten, naar wie en via welke verbinding? Wie kan de code inzien? Kunnen wij, of iemand die wij vertrouwen, controleren wat de software doet? Waartoe heeft de agent toegang? Welke systemen, accounts en rechten krijgt de agent? Wie is verantwoordelijk? Wie neemt de verantwoordelijkheid, wie betaalt en wie beslist wanneer de pilot stopt? Geen van deze vragen is moeilijk. Maar elke vraag vereist een duidelijk en specifiek antwoord. "Het is veilig" is geen antwoord. "Gegevens zijn versleuteld" is slechts een deel van het antwoord.

Pilotteams bereiden vaak het verkeerde document voor. Ze schrijven over de voordelen: bespaarde uren, snellere dienstverlening en minder routinewerk. Dat is de onderbouwing voor de sponsor vanuit de business. Maar het is niet wat de beoordelaar nodig heeft.

De beoordelaar hoeft niet te bepalen of de pilot een goed idee is. De vraag is of de pilot veilig genoeg is om uit te proberen. Een sterke onderbouwing van de voordelen geeft daarop geen antwoord. Soms werkt die zelfs averechts, omdat ze de indruk wekt dat het team de reikwijdte wil uitbreiden voordat duidelijk is hoe de basis werkt.

Pilots die sneller worden goedgekeurd, pakken het anders aan. Ze leveren vanaf dag één antwoorden op de standaardvragen aan. Ze wachten niet tot iemand erom vraagt. Zo kan de beoordelaar de tijd besteden aan het beoordelen van de aanvraag, in plaats van aan het verzamelen van informatie.

Een goed antwoord is kort, specifiek en controleerbaar.

Bij de vraag "wat draait waar?" noemt u de onderdelen en de machines waarop ze draaien. Bij de vraag "welke gegevens verlaten onze omgeving?" somt u alle uitgaande verbindingen op, legt u uit waarvoor ze dienen en vermeldt u welke verbindingen uw team via de configuratie kan bepalen. Bij de vraag "wie kan de code inzien?" vermeldt u de licentie en waar de broncode te vinden is. Bij de vraag "wie is verantwoordelijk?" noemt u een persoon en diens rol, niet alleen een afdeling.

Een goed antwoord maakt ook duidelijk waar de grenzen liggen. Als een onderdeel afhankelijk is van een externe dienst, vermeld dat dan. Beoordelaars vertrouwen een team dat zelf de hiaten benoemt. Ze zijn juist op hun hoede bij een voorstel waarin alles perfect lijkt. Het helpt ook om vroeg te beantwoorden wie toezicht houdt op het systeem waarin de agent draait, en niet alleen op de agent zelf. Lees ook wie de agent-harness controleert.

Een kleine pilot moet ook in de documentatie klein blijven. Beperk de gegevens tot wat de taak nodig heeft. Gebruik waar mogelijk testgegevens of gegevens met een laag risico. Geef de agent alleen de tools die nodig zijn voor de taak. Stel een einddatum en een duidelijk stopcriterium vast. Elke beperking neemt een vraag weg bij de beoordelaar of maakt het antwoord eenvoudiger.

Hier zit een spanningsveld. Teams willen aantonen dat de pilot echte waarde oplevert, en daarvoor zijn echte gegevens nodig. Maar de eerste goedkeuring is makkelijker te krijgen als de reikwijdte beperkt blijft. Een tweede, bredere fase kan volgen zodra de eerste fase heeft aangetoond dat de aanpak werkt.

Schrijf één pagina voordat u de aanvraag indient. Vul voor elke regel de gegevens van uw team in:

De agent voert deze ene taak uit: ___, voor dit team: ___. Deze onderdelen draaien op deze machines: ___. Deze uitgaande verbindingen bestaan om de volgende redenen: ___. Deze verbindingen worden bepaald door onze configuratie en kunnen door ons worden uitgeschakeld: ___. De agent kan deze tools en accounts gebruiken, en geen andere: ___. De broncode kan worden ingezien door ___, onder de volgende licentie: ___. De pilot gebruikt deze gegevens en geen andere: ___. De eigenaar is ___, de pilot eindigt op ___ en we stoppen eerder als ___. Geef deze pagina samen met de aanvraag aan de beoordelaar. Wacht daar niet mee tot de eerste vraag binnenkomt.

Voor EpicStaff zijn sommige van deze punten eenvoudig te beschrijven. EpicStaff draait op uw eigen infrastructuur, dus bij de vraag "wat draait waar?" kunt u de machines noemen die u al beheert.

Voor de vragen over verbindingen geldt het volgende: EpicStaff maakt alleen verbinding met externe providers waarvoor u sleutels configureert. Tools voeren uit wat u ze opdraagt. Als u een tool bouwt of inschakelt die toegang heeft tot het internet, is dat uw keuze en uw configuratie.

Voor de vraag over tools geldt dat een AI agent in EpicStaff een ander systeem alleen kan bereiken via tools die uw team eraan koppelt: Python-tools (door uw team gemaakte tools of kant-en-klare tools die EpicStaff meelevert) of een MCP-server die uw team aansluit.

Voor de vraag over de code geldt dat EpicStaff source-available is onder de licentie PolyForm Perimeter 1.0.0. U kunt de code lezen, uitvoeren en aanpassen voor eigen gebruik. De belangrijkste beperking is dat u geen product aan anderen mag aanbieden dat met EpicStaff concurreert, ongeacht of u daarvoor geld vraagt. Het inzien van de code is niet beperkt. Er gelden ook andere voorwaarden, waaronder verplichtingen om de software te vermelden wanneer u deze doorgeeft. Raadpleeg daarvoor LICENSE.md.

De antwoorden over de taak, de gegevens en de eigenaar blijven de verantwoordelijkheid van uw team. Die beschrijven uw pilot, niet de software.