Wat ISO 42001 van een organisatie vraagt

Mik Nijhuis — Sun, 06 Sep 2026 00:00:00 +0000

Leveranciersvragenlijsten kregen er dit jaar een regel bij: zijn jullie ISO/IEC 42001-gecertificeerd, en zo niet, wanneer wel? De norm achter die vraag telt 51 pagina's. Deze gids legt in bedrijfstaal uit wat die pagina's van een organisatie vragen en wat het certificaat wel en niet bewijst.</p>

Het bredere beeld bespraken we in de spelregels die rond AI ontstaan</a>. Hier behandelen we de norm zelf, op basis van het gratis gepubliceerde deel, de gedeelde structuur van ISO-managementsysteemnormen, geaccrediteerde certificeringsinstanties en auditors en aankondigingen van gecertificeerde organisaties.</p>

ISO/IEC 42001:2023</a>, gepubliceerd in december 2023, stelt eisen aan een AI-managementsysteem. Dat is het geheel van beleid, rollen, processen en vastlegging waarmee een organisatie iets bewust bestuurt in plaats van uit gewoonte. ISO 9001 doet dit voor kwaliteit, ISO 27001 voor informatiebeveiliging en ISO 42001 voor ontwikkeling, aanbod en gebruik van AI.</p>
Het certificaat zegt dus iets specifieks: een geaccrediteerde auditor stelde vast dat de organisatie heeft bepaald welke AI zij bestuurt, risico's en impact beoordeelt, controls kiest, gegevens vastlegt, zichzelf controleert en bevindingen corrigeert. Het zegt niet dat een model nauwkeurig of eerlijk is, of dat de organisatie aan de EU AI Act voldoet. Over AI buiten de vastgelegde scope zegt het niets.</p>
ISO 42001 is bedoeld voor het verschil: risico's die specifiek zijn voor AI. Denk aan bias, transparantie, verantwoord gebruik, ethiek en veiligheid. Danny Manimbo, Schellman</b> · ISO 42001 certification FAQ, February 2025</cite> </blockquote>
De norm noemt drie rollen: producent, aanbieder en gebruiker. Eén organisatie kan er meerdere hebben. Een bedrijf dat agents runt op een gekocht platform is gebruiker van het platform en mogelijk aanbieder van de agent. De rollen vormen de scope en die bepaalt wat de audit omvat.</p>

Het certificaat dekt een scope, geen heel bedrijf</p>
Het certificaat van AWS noemt vier diensten. Dat van Microsoft negen Copilot- en Foundry-producten. Dat van IBM één modelfamilie. Zegt een leverancier gecertificeerd te zijn, vraag dan: voor welke systemen, en valt wat wij kopen binnen die scope?</p> </div>
02</span>Hoe is de norm opgebouwd?</h2>
Pagina's 1 tot en met 16 bevatten de scope, 26 definities en de eisen in clausules 4 tot en met 10. Bijlage A telt vier pagina's en noemt 38 controls onder negen doelstellingen. De normatieve Bijlage B telt 25 pagina's en geeft implementatierichtlijnen per control. Bijlagen C en D zijn informatief.</p>

De helft van het document bestaat uit richtlijnen voor de 38 controls.</b> De eisen beslaan 16 pagina's, grotendeels de structuur die elke ISO-managementsysteemnorm deelt. Paginanummers uit de gepubliceerde inhoudsopgave.</figcaption> </figure>
Clausules 4 tot en met 10 gebruiken de geharmoniseerde ISO-structuur: dezelfde nummering, titels en kerntekst in alle managementsysteemnormen. Wie ISO 27001 heeft gerund, herkent bijna alles. Het nieuwe AI-deel zit in enkele subclausules, gemarkeerd in de figuur, en in de bijlagen. De volledige Engelstalige tekst kost CHF 225 bij ISO of circa EUR 250 exclusief btw bij NEN. De gratis preview stopt na clausule 4.</p>
03</span>Wat vereisen clausules 4 tot en met 10?</h2>
De tabel beschrijft elke clausule in gewone taal, met de vastlegging waar een auditor naar zoekt. De rechterkolom telt meer dan de middelste. Een map vol beleid zonder bewijs erachter faalt de audit.</p>

Clausule</th> Wat wordt gevraagd</th> Wat je moet kunnen aantonen</th></tr> </thead>

4
Context</th> Bepaal wat jullie AI-gebruik beïnvloedt en welke AI-systemen onder het managementsysteem vallen</td> Een geschreven scope, belanghebbenden en hun verwachtingen. Clausule 4.1 vraagt ook of klimaatverandering relevant is</td></tr>
5
Leiderschap</th> Topmanagement committeert zich, stelt AI-beleid vast en wijst verantwoordelijkheden toe</td> AI-beleid goedgekeurd aan de top. Benoemde eigenaren voor AI-risico, impactbeoordeling en het systeem</td></tr>
6
Planning</th> Definieer beoordeling en behandeling van AI-risico en impact op mensen. Stel meetbare AI-doelen</td> Een risicomethode met vooraf vastgestelde criteria, behandelplan, Statement of Applicability, impactproces en doelen met eigenaren</td></tr>
7
Support</th> Zorg voor middelen en competente mensen, bewustzijn, communicatie en documentbeheer</td> Bewijs van competentie en beheerde documenten met versies</td></tr>
8
Operatie</th> Voer processen en beoordelingen uit op geplande momenten en bij belangrijke wijzigingen</td> Resultaten van elke beoordeling en bewijs dat processen en wijzigingsreviews zijn uitgevoerd</td></tr>
9
Evaluatie</th> Monitor en meet, voer interne audits uit en laat management resultaten beoordelen</td> Monitoringsresultaten, intern auditprogramma met bevindingen en managementreviewrecords</td></tr>
10
Verbetering</th> Herstel afwijkingen, pak oorzaken aan en verbeter doorlopend</td> Vastlegging van elke afwijking, corrigerende actie en het effect ervan</td></tr> </tbody> </table> </div>
Hier is objectief bewijs nodig dat jullie AI-managementsysteem werkelijk werkt en niet alleen uit intenties bestaat. Ali Moshayedi, ISO 42001 auditor, BSI</b> · on clause 9, BSI webinar, March 2026</cite> </blockquote>
04</span>Wat is specifiek voor AI?</h2>
Drie processen, gedefinieerd in clausule 6 en uitgevoerd in clausule 8.</p>
AI-risicobeoordeling (6.1.2, 8.2).</b> Bepaal wat de AI-systemen van de organisatie met haar eigen doelen kunnen doen, op basis van vooraf vastgestelde criteria. Bijlage C geeft mogelijke risicobronnen.</p>
AI-risicobehandeling (6.1.3, 8.3).</b> Kies welke controls de risico's behandelen en leg dit vast in een Statement of Applicability, inclusief onderbouwing van opgenomen en uitgesloten controls. Dit is het eerste wat een auditor leest.</p>
AI-systeemimpactbeoordeling (6.1.4, 8.4).</b> Beoordeel de gevolgen van het ontwikkelen, aanbieden of gebruiken van een AI-systeem voor individuen, groepen en de samenleving. Een risicobeoordeling kijkt naar binnen, naar de organisatie. Een impactbeoordeling kijkt naar buiten, naar de mensen die het systeem raakt.</p>

De impactbeoordeling is de naar buiten gerichte toevoeging.</b> De meeste managementsysteemnormen kennen al een risicobeoordeling. ISO 42001 voegt een tweede toe, gericht op getroffen mensen. ISO/IEC 42005:2025</a> geeft richtlijnen voor doel, betrokkenen, voorzienbare impact en maatregelen.</figcaption> </figure>
De negen controledoelstellingen</h3>
Bijlage A groepeert 38 controls onder negen doelstellingen. Je selecteert wat de risicobehandeling vereist, kunt eigen controls toevoegen en onderbouwt elke opname en uitsluiting in de Statement of Applicability.</p>

Doelstelling</th> Controls</th> Wat er in gewone taal onder valt</th></tr> </thead>

A.2 Beleid voor AI</th> 3</td> AI-beleid dat aansluit op ander beleid en volgens planning wordt beoordeeld</td></tr>
A.3 Interne organisatie</th> 2</td> Wie waarvoor verantwoordelijk is en hoe medewerkers zorgen over AI melden</td></tr>
A.4 Middelen</th> 5</td> Data, tools, rekenkracht en mensen waarvan elk AI-systeem afhankelijk is</td></tr>
A.5 Impactbeoordeling</th> 4</td> Een proces om impact op individuen, groepen en samenleving te beoordelen en vast te leggen</td></tr>
A.6 Levenscyclus</th> 9</td> Verantwoord ontwerp, verificatie, validatie, inzet, operatie, monitoring, documentatie en eventlogs</td></tr>
A.7 Data</th> 5</td> Herkomst, kwaliteit, provenance en voorbereiding van data</td></tr>
A.8 Informatie voor belanghebbenden</th> 4</td> Informatie aan gebruikers, externe rapportage en communicatie over incidenten</td></tr>
A.9 Gebruik van AI</th> 3</td> Processen voor verantwoord gebruik en een beoogd doel per systeem</td></tr>
A.10 Derden en klanten</th> 3</td> Verantwoordelijkheden in de keten, leveranciersbeheer en plichten aan klanten</td></tr> </tbody> </table> </div>
Vijf van de negen zijn nieuw ten opzichte van een informatiebeveiligingsnorm: A.5 tot en met A.9 over impact, levenscyclus, data, informatie en gebruik. Daar zit het meeste nieuwe werk.</p>
05</span>Wat houdt certificering in?</h2>
Certificering komt van een certificeringsinstantie die zelf voor ISO 42001 is geaccrediteerd onder ISO/IEC 42006:2025</a>. In Nederland accrediteerde de RvA BSI en DNV in januari 2025</a> en TÜV NORD in februari 2026. Sommige vroege certificaten kwamen onder andere schema's tot stand. Controleer daarom het accreditatiemerk.</p>
De audit volgt het ISO 27001-patroon: Stage 1 beoordeelt documentatie in één of twee dagen, Stage 2 test in één tot drie weken of het systeem werkt, gevolgd door een driejarig certificaat met jaarlijkse surveillance. Dit zijn gepubliceerde ervaringen van Schellman</a>. Het bedrijf noemt auditkosten in het eerste jaar van enkele tienduizenden dollars. Stage 2 zoekt naar records, dus het systeem moet vóór de audit hebben gedraaid. Implementers noemen zes tot twaalf maanden vanaf nul en drie tot zes maanden bij een bestaand ISO 27001-systeem. Behandel dit als ervaringscijfers, niet als universele norm. De grootste kosten zitten intern in inventarisatie, beoordelingen en vastlegging.</p>
Als jullie scope niet volledig helder is, falen de governance en de audit. Fran Caballero, ISO 42001 auditor, BSI</b> · BSI webinar with Darktrace, May 2026</cite> </blockquote>
Caballero noemt drie terugkerende fouten bij BSI: een scope die niet zegt waar AI begint en eindigt, metrics uit gewone IT die niets zeggen over drift, eerlijkheid of datanauwkeurigheid en gedownload beleid dat alleen voor de audit dient. Daaraan vooraf gaat de inventaris: de eerste vraag van een auditor is een lijst van AI-systemen in scope met hun beoogde gebruik.</p>
06</span>Hoe pakten de eerste gecertificeerde organisaties het aan?</h2>

Organisatie</th> Gecertificeerd</th> Scope</th> Wat opvalt</th></tr> </thead>

AWS</a></th> Nov 2024, Schellman</td> Bedrock, Q Business, Textract, Transcribe</td> Governance langs de zeven AI-lifecyclefasen van ISO/IEC 22989. Eerste surveillanceaudit in nov 2025 zonder bevindingen</td></tr>
Anthropic</a></th> Jan 2025, Schellman</td> AI-producten en -diensten, inclusief de Claude-modellen</td> Koppelt het managementsysteem aan het Responsible Scaling Policy</td></tr>
Microsoft</a></th> Mrt 2025, hercertificeerd mei 2026</td> Negen benoemde Copilot- en Foundry-producten</td> Risicogestuurde review zodat senior controle naar systemen met meer impact gaat. Scope groeide in jaar twee van twee naar drie systemen</td></tr>
Darktrace</a></th> Jul 2025, BSI</td> De AI-gedreven securityproducten</td> Gebouwd op een bestaand ISO 27001- en 27018-systeem. Elke AI-wijziging doorloopt nu vóór productie een impactbeoordeling</td></tr>
Metyis, Amsterdam</a></th> Jul 2025, DNV</td> Het AI-managementsysteem</td> Eerste in Nederland uitgegeven ISO 42001-certificaat onder RvA-accreditatie</td></tr> </tbody> </table> </div>
Ook Google Cloud, Workday, Snowflake, Salesforce, SAP, IBM voor de Granite-modellen, KPMG in de VS en BCG kondigden certificaten aan. BCG rekende zichzelf in januari 2026 tot de eerste honderd organisaties wereldwijd</a>. Voor zover wij konden vaststellen, had in september 2026 nog geen Nederlandse bank, verzekeraar of overheidsinstantie een certificaat aangekondigd.</p>
Wanneer we een AI-systeem wijzigen, doorloopt het nu vóór productie een AI-impactbeoordeling van datakwaliteit, bias, risico en klantimpact. Darktrace compliance team</b> · BSI webinar, May 2026</cite> </blockquote>
Drie patronen keren terug. De scope is smal en benoemd. Het systeem bouwt voort op bestaande ISO 27001-processen, aangevuld met AI-beoordelingen en vijf nieuwe controlgebieden. Darktrace benadrukte dat het ISO 42001 niet vanaf nul bouwde. De zichtbare operationele verandering is een controlepoort: een impactbeoordeling vóór een AI-systeem of wijziging productie bereikt.</p>
Het commerciële effect is al zichtbaar. Volgens Schellman vereist Microsofts leveranciersprogramma SSPA ISO 42001-certificering van leveranciers waarvan het AI-gebruik als gevoelig of high-risk geldt. Zonder certificaat of gedateerd plan krijgt een leverancier nu een langere vragenlijst en later mogelijk uitsluiting van werk. Voor een inkoper is ernaar vragen een goedkope toets of de leverancier een inventaris bijhoudt, impact beoordeelt en na release monitort.</p>
07</span>Hoe verhoudt de norm zich tot de EU AI Act?</h2>
ISO 42001 is geen geharmoniseerde norm onder de AI Act en certificering geeft geen vermoeden van conformiteit. CEN-CENELEC JTC 21 schreef voor artikel 17 de eigen kwaliteitsmanagementnorm EN 18286, goedgekeurd in juli 2026. Artikel 17 geldt per high-risksysteem als product, terwijl 42001 een organisatie bestuurt. In september 2026 was nog geen geharmoniseerde AI Act-norm in het Publicatieblad genoemd. 42001 werd in 2026 als Europese norm overgenomen; overname is geen harmonisatie.</p>

</th> EU AI Act</th> ISO/IEC 42001</th></tr> </thead>

Wat het is</th> Wet, gefaseerd van kracht van 2025 tot 2028</td> Een vrijwillige norm waarvoor je je kunt laten certificeren</td></tr>
Wie gebonden is</th> Aanbieders en gebruiksverantwoordelijken, naar rol en risiconiveau</td> Wie ervoor kiest, binnen de eigen gedefinieerde scope</td></tr>
De eenheid</th> Elk AI-systeem, geclassificeerd naar beoogd doel</td> Het managementsysteem van de organisatie</td></tr>
Wat het bewijst</th> Dat aan de verplichtingen voor dat systeem is voldaan</td> Dat een geaccrediteerde auditor een werkend managementsysteem aantrof</td></tr>
Waar ze overlappen</th> Risicomanagement, datagovernance, documentatie en logging, menselijke controle, monitoring na release, leveranciersbeheer en communicatie over incidenten</td></tr>
Wat 42001 niet dekt</th> Conformiteitsbeoordeling, CE-markering en conformiteitsverklaring; registratie in de EU-databank; grondrechteneffectbeoordeling uit artikel 27; incidentmeldtermijnen uit artikel 73; technisch dossier uit Bijlage IV per systeem</td></tr> </tbody> </table> </div>
Het betekent niet dat je automatisch compliant bent. Het is wel de eerste trede op de ladder, de eerste stap richting compliance. Will Booth, Director of Cybersecurity Compliance, Darktrace</b> · on the AI Act, BSI webinar, May 2026</cite> </blockquote>
Voor een organisatie die met beide te maken heeft, werkt één managementsysteem plus één dossier per AI-systeem praktisch. Het managementsysteem bevat beleid, beoordelingen, audits en reviews. Het systeemdossier bevat wat de wet voor dat systeem vraagt, zoals uitgewerkt in wat de AI Act van een gebruiksverantwoordelijke vraagt</a>.</p>

Wat Control voor een auditor bewaart</h3>
Per agentrol · zes soorten bewijs</p>

Beoogd gebruik en scope.</b>Elke agent heeft een gedefinieerde taak, een benoemde menselijke eigenaar en expliciete grenzen. De Scan inventariseert werk en systemen vóór de eerste run. (A.9.4; clausule 4.3.)</span></li>
Menselijke controle.</b>Elke capaciteit draait op een supervision level: Suggests, Drafts of Auto. Bewijs verhoogt het niveau; regels verlagen het. Elke goedkeuring en reden wordt vastgelegd. (A.9.2; clausule 5.3.)</span></li>
Operatie, monitoring en eventlogs.</b>Elke handeling in productie wordt met controles, reviewer en uitkomst vastgelegd. Governancewijzigingen staan in dezelfde historie. (A.6.2.6; A.6.2.8; clausule 9.1.)</span></li>
Verificatie en validatie.</b>Een modelwijziging stuurt de agent terug naar de apart gehouden testcases voordat hij zijn niveau behoudt. Uitzonderingen, beleidsovertredingen en kwaliteitspoorten worden gevolgd. (A.6.2.4.)</span></li>
Modellen van derden.</b>Elke rol gebruikt een goedgekeurd model van een vervangbare aanbieder. Elke koppeling met jullie systemen toont hoe die is beveiligd. (A.10.3; A.4.)</span></li>
Correctie en verbetering.</b>Geaccepteerde menselijke correcties worden voorgestelde wijzigingen aan de rol. Elke doorgevoerde wijziging is zichtbaar en omkeerbaar. (Clausule 10.)</span></li> </ol> </div>
Control schrijft niet het managementsysteem. AI-beleid, scope, beoordelingen, interne audit, managementreview en Statement of Applicability blijven documenten van de organisatie. Die leest een certificeringsinstantie als eerste. Is vóór go-live een impactbeoordeling nodig, dan bereiden wij de operationele input voor: doel, geraakte data, grenzen en supervision. De verantwoordelijke proceseigenaar bij de klant besluit of de impact wordt geaccepteerd. Aitonomy heeft geen ISO 42001-certificaat en certificeert niemand. De mapping hierboven is van ons, niet van een auditor.</p>
Neem één AI-systeem dat jullie al runnen en stel de vragen uit de norm. Waarvoor dient het? Wie is eigenaar? Wat kan het doen met de mensen aan de andere kant? Wat deed het vorige week en wie controleerde dat? Bestaan de antwoorden als records, dan is certificering een vraag van scope en auditdatum. Bestaan ze niet, dan ligt daar het werk. Ook als geen vragenlijst er ooit om vraagt.</p>
Veelgestelde vragen</h2>

Wat is ISO 42001 in gewone taal?+</span></summary>
ISO/IEC 42001:2023 is de internationale norm voor een AI-managementsysteem: beleid, rollen, beoordelingen, vastlegging en reviews waarmee een organisatie de AI bestuurt die zij ontwikkelt, aanbiedt of gebruikt. De structuur lijkt op ISO 27001, aangevuld met AI-risico- en impactbeoordelingen en 38 mogelijke controls. Een geaccrediteerde instantie kan een organisatie hiervoor certificeren.</div> </details>

Betekent ISO 42001-certificering dat je aan de EU AI Act voldoet?+</span></summary>
Nee. ISO 42001 is geen geharmoniseerde norm onder de AI Act en geeft geen vermoeden van conformiteit. Er is veel overlap, maar productplichten zoals conformiteitsbeoordeling, CE-markering, registratie en de grondrechteneffectbeoordeling vallen erbuiten. De norm is een bruikbare basis voor werk aan de AI Act</a>, geen vervanging.</div> </details>

Heb je ISO 27001 nodig vóór ISO 42001?+</span></summary>
Nee. De norm vereist niet dat eerst een ander managementsysteem is ingevoerd of gecertificeerd. In de praktijk bouwden de meeste vroege gebruikers voort op een bestaand ISO 27001-systeem en voegden ze AI-specifieke beoordelingen en controls toe.</div> </details> </div>

Bronnen en reikwijdte</h4>

ISO/IEC 42001:2023</a>, Information technology, Artificial intelligence, Management system. Read in the public preview. Companion standards ISO/IEC 42005:2025</a> (AI system impact assessment) and ISO/IEC 42006:2025</a> (requirements for certification bodies).</li>
Annex A control titles cross-checked against the NIST AI RMF to ISO/IEC 42001 crosswalk</a>.</li>
Schellman, lessons learned from auditing ISO 42001</a> and its certification FAQ</a> (fees, Microsoft SSPA).</li>
Accreditation: RvA</a> (January 2025), UKAS</a> (January 2026), TÜV NORD</a> (February 2026).</li>
Certifications: the organisations’ own announcements, linked in the table, plus AWS’s first surveillance audit</a>, Microsoft’s May 2026 recertification</a>, Google Cloud</a>, Salesforce</a> and IBM</a>.</li>
AI Act: Cloud Security Alliance on EN 18286 and ISO 42001</a> (April 2026); CEN-CENELEC on EN 18286</a> (July 2026).</li>
Sources checked 6 September 2026. A practical guide, not legal advice, and not a substitute for the standard itself; the plain-language descriptions are ours.</li> </ul>
Kijk en luister</h4>

Watch:</b> BSI, “Unlocking value with ISO/IEC 27001 and ISO/IEC 42001”</a> (May 2026): a BSI auditor on where audits fail, and Darktrace on what certification changed.</li>
Watch:</b> BSI, “AI governance and assurance”</a> (March 2026): an ISO 42001 auditor on the clauses, the impact assessment and EN 18286.</li>
Watch:</b> INCITS and NIST, “Unlocking the power of AI management systems”</a> (2024): the workshop at the standard’s launch, with Microsoft’s Kim Lucy on why the impact assessment was added.</li> </ul> </div> </div> </article>

Wat de EU AI Act van een gebruiksverantwoordelijke vraagt

Mik Nijhuis — Thu, 03 Sep 2026 00:00:00 +0000

Een agent die leveranciersfacturen koppelt en een agent die sollicitanten filtert, kunnen op hetzelfde platform draaien. Toch gelden voor hen niet dezelfde verplichtingen onder de EU AI Act. Het doel van het werk telt, net als de rol van jullie organisatie bij het aanbieden of gebruiken van het systeem.</p>
Voor een operationeel team zijn de eerste vragen praktisch. Zijn we gebruiksverantwoordelijke, aanbieder of allebei? Is dit gebruik high-risk? Wat moeten we nu doen en welk bewijs hebben we nodig wanneer de overige regels gaan gelden?</p>
Het bredere beeld bespraken we in de spelregels die rond AI ontstaan</a>. Dit artikel kiest het perspectief van de gebruiksverantwoordelijke: de organisatie die een AI-systeem onder haar verantwoordelijkheid gebruikt. De focus ligt op terugkerend bedrijfswerk, niet op specialistische regels voor rechtshandhaving of alle productveiligheidsregimes.</p>
Een aanbieder ontwikkelt een systeem of laat het ontwikkelen en brengt het onder eigen naam of merk op de markt of stelt het in gebruik. Daarvoor hoef je het onderliggende model niet zelf te trainen of software aan andere bedrijven te verkopen. Ook opdracht geven voor een systeem voor eigen gebruik kan relevant zijn. Dit zijn de definities uit artikel 3</a>.</p>
De rollen horen bij het systeem en de activiteit. Een organisatie kan gebruiksverantwoordelijke zijn voor het ene systeem en aanbieder van het andere. De aankoop van een agentplatform bepaalt niet vanzelf de status van alles wat erop wordt gebouwd.</p>
Artikel 25</a> noemt drie situaties waarin een gebruiksverantwoordelijke of andere partij de verplichtingen van een aanbieder van een high-risksysteem overneemt:</p>

Een eigen naam of merk op een bestaand high-risksysteem zetten, met inachtneming van de bepaling over contractuele verdeling van verplichtingen.</li>
Een bestaand high-risksysteem wezenlijk wijzigen, waarbij het high-risk blijft.</li>
Het beoogde doel van een niet-high-risksysteem zo veranderen dat het high-risk wordt.</li> </ul>
Routineconfiguratie is niet automatisch een wezenlijke wijziging. Omgekeerd kan iets dat intern “alleen een nieuwe workflow” heet, het beoogde doel wel veranderen. Breid je een documentassistent uit naar sollicitantenscreening, beoordeel de classificatie dan opnieuw vóór go-live.</p>

Leg het vast in het contract</p>
Het contract moet benoemen wie het systeem aanbiedt, wat het beoogde doel is, welke wijzigingen zijn toegestaan, wie toegang krijgt tot documentatie en wat er gebeurt bij een andere rol of classificatie. Artikel 25 erkent contractuele verdeling in het geval van naam en merk. Dat is geen algemeen recht om de wet contractueel buiten werking te zetten.</p> </div>
Artikel 6</a> kent twee hoofdroutes. De eerste betreft bepaalde producten en veiligheidscomponenten onder de wetgeving in Bijlage I, wanneer de relevante conformiteitsbeoordeling door een derde vereist is. De tweede betreft toepassingen uit Bijlage III, waaronder specifieke vormen van inzet bij werk, onderwijs, essentiële diensten, biometrie en kritieke infrastructuur.</p>
Voor veel operationele teams is Bijlage III de meest directe vraag. Sollicitanten screenen, de kredietwaardigheid van personen beoordelen en risico of prijs bepalen voor levens- en zorgverzekeringen staan op de lijst. Leveranciersfacturen koppelen of achter een leverdatum aangaan valt op basis van die omschrijving normaal gesproken niet in die categorieën.</p>
Artikel 6(3) bevat beperkte uitzonderingen voor sommige systemen uit Bijlage III, waaronder bepaalde smalle procedurele of voorbereidende taken zonder significant risico. Dit zijn voorwaarden om zorgvuldig te toetsen, geen labels om losjes toe te passen. Systemen uit Bijlage III die natuurlijke personen profileren, worden onder deze bepaling altijd als high-risk behandeld.</p>
Vraag de aanbieder om het beoogde doel en de classificatie en vergelijk die met wat jullie werkelijk van plan zijn. Leg de beslissing en redenen vast. Verandert het werk, beoordeel dan opnieuw.</p>
Dit hangt samen met, maar staat los van, de geschiktheid van het werk voor een AI-agent</a>. Een proces kan juridisch toegestaan zijn en toch te duur om te controleren of te moeilijk om te begeleiden.</p>
De Digital Omnibus voor AI, Verordening (EU) 2026/1744</a>, wijzigde de AI Act in juli 2026. Specifieke high-riskbepalingen zijn uitgesteld, niet de hele wet. De door de Raad aangenomen tekst</a> beschrijft de wijzigingen in artikelen 111 en 113.</p>

Bepaling</th> Geldt vanaf</th> Wat te controleren</th></tr> </thead>

Artikel 4
AI-geletterdheid</th> 2 feb 2025</td> Tekst gewijzigd in juli 2026. Maatregelen die AI-geletterdheid ondersteunen van medewerkers en anderen die namens jullie AI gebruiken</td></tr>
Artikel 5
verboden</th> 2 feb 2025</td> Of een praktijk verboden is, vóórdat controls of openbaarmaking worden overwogen</td></tr>
Artikel 50
transparantie</th> 2 aug 2026</td> Welke plicht geldt en of die bij jullie of de aanbieder ligt. Sommige kennen uitzonderingen</td></tr>
Hoofdstuk III
Afdelingen 1 t/m 3</th> 2 dec 2027</td> High-risksystemen uit Bijlage III, behalve artikel 6(5). Classificatie, systeemeisen en plichten uit artikelen 26 en 27</td></tr>
Hoofdstuk III
Afdelingen 1 t/m 3</th> 2 aug 2028</td> Dezelfde bepalingen voor artikel 6(1) en systemen uit Bijlage I, met de toepasselijke productregels</td></tr> </tbody> </table> </div>
Dit zijn algemene data. Het gewijzigde artikel 111 bevat overgangsregels voor high-risksystemen die vóór de relevante datum uit Hoofdstuk III al op de markt of in gebruik waren, met voorwaarden rond ingrijpende ontwerpwijzigingen. Stel per systeem vast welke regels gelden. Behandel december 2027 niet als universele deadline voor elke bestaande inzet.</p>
AI-geletterdheid vraagt nu al actie</h3>
Het gewijzigde artikel 4 vereist maatregelen die de ontwikkeling van AI-geletterdheid ondersteunen. Het eist geen gegarandeerd niveau voor ieder individu. Training en begeleiding moeten passen bij de mensen, systemen en gebruikscontext. Leg vast wat is aangeboden en waarom dat passend was. De vragen en antwoorden over AI-geletterdheid</a> van de Commissie lichten de gewijzigde aanpak toe.</p>
Transparantie hangt af van gebruik en rol</h3>
Artikel 50 scheidt plichten van aanbieders en gebruiksverantwoordelijken. Aanbieders moeten systemen voor rechtstreekse interactie met mensen zo ontwerpen dat duidelijk is dat zij met AI te maken hebben, tenzij dat uit de omstandigheden al vanzelf spreekt. Ook dragen aanbieders de plicht voor machineleesbare markering van synthetische content.</p>
Gebruiksverantwoordelijken hebben specifieke plichten voor emotieherkenning en biometrische categorisering, deepfakes en door AI gegenereerde of gemanipuleerde tekst die het publiek informeert over zaken van algemeen belang. Voor die laatste categorie geldt een uitzondering bij menselijke review of redactionele controle, mits een persoon of organisatie redactioneel verantwoordelijk is. Voor duidelijk artistieke, creatieve, satirische of fictieve deepfakes gelden bijzondere regels. Zie artikel 50</a>.</p>
Voor een bestaand generatief systeem dat vóór 2 augustus 2026 op de markt kwam, is de markeringsdeadline voor de aanbieder uit artikel 50(2) 2 december 2026. Die overgang stelt de eigen openbaarmakingsplichten van de gebruiksverantwoordelijke niet uit.</p>
De Omnibus voegt per 2 december 2026 ook verboden toe voor bepaalde seksuele of intieme content zonder toestemming en materiaal van seksueel misbruik van kinderen. Openbaarmaking maakt verboden gebruik niet rechtmatig.</p>
De AVG, arbeidsregels en toepasselijke sectoreisen blijven naast de AI Act gelden. Het high-riskuitstel schort die niet op.</p>
04</span>Wat vereist artikel 26 van een high-riskgebruiksverantwoordelijke?</h2>
Zodra artikel 26 op jullie systeem van toepassing is, gaan de belangrijkste eisen over gebruik, menselijke controle en monitoring. Hieronder staat een praktische samenvatting, geen vervanging van de volledige bepaling of sectorspecifieke voorwaarden.</p>

Gebied</th> Wat de gebruiksverantwoordelijke moet doen</th> Artikel</th></tr> </thead>

Gebruik</th> Technische en organisatorische maatregelen nemen om het systeem volgens de instructies van de aanbieder te gebruiken</td> 26(1)</td></tr>
Menselijke controle</th> Die beleggen bij mensen met de competentie, training, bevoegdheid en ondersteuning om haar uit te oefenen</td> 26(2)</td></tr>
Inputdata</th> Waar de gebruiksverantwoordelijke de inputdata beheert, zorgen dat die relevant en voldoende representatief is voor het beoogde doel</td> 26(4)</td></tr>
Monitoring</th> De werking monitoren, handelen bij relevante risico's, gebruik waar vereist opschorten en de nodige meldingen doen</td> 26(5)</td></tr>
Logs</th> Automatisch gegenereerde logs onder eigen controle passend en minstens zes maanden bewaren, tenzij toepasselijk recht anders bepaalt</td> 26(6)</td></tr>
Werknemers</th> Betrokken werknemers en hun vertegenwoordigers vóór gebruik op de werkplek informeren dat zij aan het high-risksysteem worden onderworpen</td> 26(7)</td></tr>
Registratie</th> Als overheidsinstantie of namens een overheid, de toepasselijke registratie- en databankcontroles uitvoeren</td> 26(8)</td></tr>
Gegevensbescherming</th> Bij een verplichte DPIA de informatie van de aanbieder gebruiken ter ondersteuning</td> 26(9)</td></tr>
Betrokken personen</th> Bij relevante systemen uit Bijlage III die beslissingen over personen nemen of ondersteunen, die personen informeren over het gebruik</td> 26(11)</td></tr>
Autoriteiten</th> Meewerken met bevoegde autoriteiten aan maatregelen rond het systeem</td> 26(12)</td></tr> </tbody> </table> </div>
De volledige tekst staat in artikel 26</a>. Iemand beschikbaar hebben om output goed te keuren is niet genoeg als die persoon de beperkingen niet begrijpt, de relevante informatie niet kan verkrijgen of het werk niet kan stoppen.</p>
Artikel 27 voegt voor bepaalde gebruiksverantwoordelijken en toepassingen een grondrechteneffectbeoordeling toe. Dit geldt voor publiekrechtelijke instellingen, private partijen die publieke diensten leveren en gebruiksverantwoordelijken van de genoemde systemen voor kredietwaardigheid en levens- of zorgverzekeringen. De categorie kritieke infrastructuur uit Bijlage III is uitgezonderd. Niet elke private organisatie met high-risk-AI hoeft deze beoordeling uit te voeren.</p>
Waar vereist, vindt de beoordeling vóór het eerste gebruik plaats, blijft ze actueel en worden de resultaten zoals voorgeschreven gemeld. De Omnibus staat kruisverwijzingen naar relevante delen van een bestaande DPIA toe, of opname daarvan in de grondrechtenbeoordeling. De beoordeling zelf vervalt niet. Zie artikel 27</a> en de wijzigingen</a>.</p>
Zes maanden is een bewaartermijn</h3>
Artikel 26(6) bepaalt hoelang relevante logs moeten worden bewaard zodra de plicht geldt. Het vereist niet dat op de eerste dag al zes maanden historie bestaat.</p>
Eerder beginnen kan helpen monitoring te testen en fouten te onderzoeken, maar moet een bewuste operationele beslissing zijn. Stel bewaartermijn, toegangsrechten en verwijderregels samen vast, rekening houdend met toepasselijke eisen voor persoonsgegevens.</p>
05</span>Wat gebeurt er wanneer een incident wordt ontdekt?</h2>
Wanneer artikel 26(5) geldt, moet een gebruiksverantwoordelijke die een ernstig incident vaststelt onmiddellijk de aanbieder informeren, vervolgens de importeur of distributeur en de relevante markttoezichtautoriteiten. Is de aanbieder niet bereikbaar, dan geldt artikel 73 met de nodige aanpassingen voor de gebruiksverantwoordelijke.</p>
Bij een risico zoals genoemd in artikel 26(5) omvat de plicht het zonder onnodige vertraging informeren van de relevante partijen en het opschorten van gebruik. Niet elke onjuiste output is juridisch een ernstig incident. Het team heeft wel een route nodig om dat direct te beoordelen, zonder op de maandelijkse review te wachten.</p>
Artikel 73</a> bevat vooral de meldingsplichten van de aanbieder. De algemene uiterste termijn is 15 dagen na kennisname, met kortere termijnen van tien dagen bij overlijden en twee dagen bij een wijdverbreide inbreuk of de genoemde ernstige verstoring van kritieke infrastructuur. Deze termijnen staan naast plichten om bij de relevante trigger onmiddellijk te melden. Ze geven een gebruiksverantwoordelijke geen toestemming om met een melding onder artikel 26 te wachten.</p>
Het materiaal van de Commissie over incidentmeldingen omvat conceptrichtlijnen</a>. Baseer de incidentprocedure op de wettelijke triggers en controleer de status van richtlijnen voordat je erop vertrouwt.</p>
Spreek vóór de lancering af wie een waarschuwing ontvangt, wie het systeem kan opschorten, hoe de aanbieder wordt bereikt en wie verplichte meldingen doet. Test die route. Logs kunnen vaststellen wat er gebeurde, maar nemen niet zelfstandig contact op met de juiste mensen.</p>
Artikel 86</a> geeft getroffen personen onder bepaalde omstandigheden recht op een duidelijke en betekenisvolle uitleg. Het gaat om beslissingen op basis van output van high-risksystemen uit Bijlage III, behalve kritieke infrastructuur, met juridische of vergelijkbaar aanzienlijke gevolgen die volgens de persoon nadelig zijn voor gezondheid, veiligheid of grondrechten.</p>
De uitleg moet de rol van het AI-systeem en de belangrijkste elementen van de beslissing omvatten. De bepaling kent uitzonderingen en geldt alleen voor zover dat recht niet al uit ander EU-recht volgt.</p>
Artikel 86 is niet uitdrukkelijk opgenomen in het uitstel van Hoofdstuk III, Afdelingen 1 tot en met 3. Alleen op basis van die wijziging blijft de algemene datum van 2 augustus 2026 dus staan. Hoe de bepaling samenwerkt met uitgestelde classificatieregels en overgangsrecht moet per systeem worden beoordeeld. Neem niet aan dat de latere datum voor artikel 26 ook elke uitlegplicht uitstelt.</p>
Bewaar operationeel de informatie die nodig is om de beslissing uit te leggen: relevante feiten, criteria, systeemoutput en menselijke betrokkenheid. Een technisch eventlog kan helpen dat bewijs te vinden, maar is niet vanzelf een betekenisvolle uitleg voor de getroffen persoon.</p>

Wat aantoonbaar moet zijn</h3>
Eén agentrol · zes controles</p>

Doel en rollen.</b>Waarvoor de agent wordt gebruikt, de classificatie en wie hem aanbiedt en inzet.</span></li>
Menselijke controle.</b>Wie toezicht houdt, welke training die persoon kreeg en welke bevoegdheid er is om in te grijpen.</span></li>
De case.</b>Wat in een specifieke case gebeurde, welke controles liepen en wat een mens goedkeurde of wijzigde.</span></li>
Informatie en beoordelingen.</b>Welke vereist waren en of ze zijn afgerond.</span></li>
Incidenten.</b>Wat gebeurde nadat een risico of incident werd ontdekt, inclusief opschorting en meldingen waar nodig.</span></li>
Wijzigingen.</b>Wat veranderde in het systeem of doel en wat vóór inwerkingtreding is beoordeeld.</span></li> </ol> </div>
Dit is een operationele checklist, geen claim dat de wet één standaardbestand met alle zes onderdelen eist. Sommige records horen bij het agentplatform, andere bij de proceseigenaar of teams voor HR, privacy en legal.</p>
Hier past het werk van Aitonomy. De Scan</a> en ons team stellen het beoogde werk, de betrokken systemen en gaten in het bewijs vast. Waar classificatie of een gewijzigde juridische rol moet worden beoordeeld, bereiden we de technische en operationele informatie voor de klant en adviseurs voor.</p>
In productie bewaart Aitonomy Control het operationele bewijs: agentactiviteit, goedkeuringen, controles en de historie van wijzigingen en supervision-beslissingen. Ons team gebruikt die vastlegging om problemen te onderzoeken en beslissingen voor te leggen aan de verantwoordelijke proceseigenaar. De supervision levels</a> bepalen hoe bevoegdheid wordt verdiend en verlaagd. Ze ondersteunen menselijke controle, maar vervangen artikel 26 niet.</p>
Control voert niet zelfstandig een effectbeoordeling uit, informeert geen werknemers en bepaalt niet of een configuratie iemand tot aanbieder maakt. Ook vereiste logs, toegang en bewaartermijnen moeten voor de daadwerkelijke inzet worden gecontroleerd. Wijs die verantwoordelijkheden toe; neem niet aan dat de aankoop van een platform ze afdekt.</p>
Begin bij de agent die jullie al runnen of overwegen. Leg het doel en de rollen van partijen vast, bepaal welke plichten gelden en test of de verantwoordelijke mensen het bewijs kunnen vinden en erop kunnen handelen. Dat werk is al vóór een deadline nuttig, omdat het ook nodig is om een agent verantwoord in productie te runnen</a>.</p>
Veelgestelde vragen</h2>

Geldt de EU AI Act ook voor een organisatie die AI alleen gebruikt?+</span></summary>
Ja, als de organisatie en het gebruik binnen de reikwijdte van de wet vallen. AI onder eigen verantwoordelijkheid gebruiken maakt je doorgaans gebruiksverantwoordelijke. AI-geletterdheid, verboden en relevante transparantieplichten gelden al. De aanvullende plichten uit artikel 26 gaan over high-risksystemen en hebben eigen ingangsdata en overgangsregels.</div> </details>

Kan een organisatie zowel AI-aanbieder als gebruiksverantwoordelijke zijn?+</span></summary>
Ja. De rollen hangen af van systeem en activiteit. Een organisatie kan het systeem van een leverancier gebruiken en een ander systeem onder eigen naam aanbieden. Ontwikkeling laten uitvoeren, een high-risksysteem onder eigen merk brengen of het doel wijzigen kan de analyse veranderen. De aankoop van een platform bepaalt de rol niet.</div> </details>

Zijn AI-agents automatisch high-risk onder de AI Act?+</span></summary>
Nee. De classificatie hangt af van het beoogde doel en de voorwaarden uit artikel 6, niet van het label agent of het autonomieniveau</a>. Sollicitantenscreening en bepaalde krediet- of verzekeringstoepassingen staan in Bijlage III. Routinematige factuurmatching meestal niet, alleen op basis van die omschrijving. Menselijke goedkeuring neemt de high-riskstatus niet automatisch weg.</div> </details>

Welke plichten voor gebruiksverantwoordelijken zijn uitgesteld?+</span></summary>
De relevante plichten uit Hoofdstuk III, Afdelingen 1 tot en met 3, waaronder artikel 26, gelden vanaf 2 december 2027 voor high-risksystemen uit Bijlage III en vanaf 2 augustus 2028 voor artikel 6(1)- en Bijlage I-systemen, met overgangsregels. Het uitstel geldt in het algemeen niet voor AI-geletterdheid, bestaande verboden of transparantieplichten uit artikel 50.</div> </details>

Hoelang moet een gebruiksverantwoordelijke AI-systeemlogs bewaren?+</span></summary>
Wanneer artikel 26(6) geldt, moeten automatisch gegenereerde logs onder controle van de gebruiksverantwoordelijke passend en minstens zes maanden worden bewaard, tenzij toepasselijk EU- of nationaal recht anders bepaalt. Dit is een bewaartermijn, geen eis om vóór ingang van de plicht al zes maanden historie te hebben.</div> </details> </div>

Bronnen en reikwijdte</h4>

Regulation (EU) 2024/1689, the Artificial Intelligence Act</a>, as amended by Regulation (EU) 2026/1744</a>.</li>
Council of the EU, adopted Digital Omnibus text</a>, particularly the amendments to Articles 4, 25, 27, 111 and 113, and its adoption announcement</a>.</li>
European Commission AI Act Service Desk, the article texts linked above. Some pages carry an explicit warning that they have not yet incorporated the Omnibus amendments; those passages must be read with the amending text.</li>
European Commission, AI literacy questions and answers</a> and draft serious-incident reporting guidance</a>.</li>
Sources checked 4 September 2026. This is an operational guide, not legal advice or an exhaustive compliance checklist. Application to a particular system depends on its purpose, the parties’ roles, transitional provisions and other applicable law. The interpretation of Article 86’s timing is identified separately above.</li> </ul> </div> </div> </article>

Autonomie moet je verdienen: supervision levels voor agents in productie

Mik Nijhuis — Tue, 01 Sep 2026 00:00:00 +0000

Het gebruikelijke advies klopt voor zover het gaat. Laat een agent beginnen met intensieve review. Verruim wat hij mag doen zodra hij zich bewijst. Houd een mens verantwoordelijk voor de uitkomst. We schreven zelf een versie daarvan en stelden dat bewijs autonomie moet kunnen verlagen én verhogen</a>, zonder uit te werken wat dat in de praktijk betekent.</p>
Dat werken we hier uit. Niet de exacte cijfers, die horen in beleid dat we met een specifieke klant vastleggen, maar de opzet: welke niveaus er zijn, hoeveel reviewtijd elk niveau kost, welk bewijs een agent laat bewegen en wat autonomie terugneemt zonder te wachten tot iemand het opmerkt.</p>
Een supervision level voor een AI-agent bepaalt wat de agent mag doen, hoeveel van zijn werk een mens moet beoordelen en welk bewijs de autonomie kan verhogen of verlagen.</p>
Dat autonomie in stappen moet worden toegekend en niet simpelweg aangezet. Dat inzicht is niet nieuw. Thomas Sheridan en William Verplank beschreven in 1978</b> al een tienpuntsschaal voor menselijke controle</a>. Die loopt van een mens die alles zonder hulp doet, via een machine die opties beperkt en er één voorstelt, tot een machine die handelt zonder iemand te informeren. Later werk van Parasuraman, Sheridan en Wickens verdeelde automatisering in vier functies</a>: informatie verzamelen, interpreteren, een handeling kiezen en die uitvoeren.</p>
Een ladder met gradaties bestaat dus al bijna vijftig jaar. Huidige richtlijnen over agents en hun operationele loops</a> komen uit bij hetzelfde brede principe: autonomie moet stapsgewijs toenemen. De discussie gaat niet over de ladder.</p>
Die gaat over de treden. Veel voorgestelde promotiecriteria zijn kwalitatief: het correctiepercentage wordt acceptabel, de uitzonderingslijst stabiliseert, reviewers veranderen steeds minder. Ze beschrijven een gevoel over de agent. Iemand die niet bij het gesprek was, kan ze niet controleren. Later auditen kan dus evenmin. Daarmee beslist uiteindelijk degene die in de vergadering het meeste vertrouwen uitstraalt of de scope wordt verruimd.</p>
Raja Parasuraman en Dietrich Manzey beoordeelden het empirische onderzoek hierover in 2010 in Human Factors</a>. Hun bevindingen zijn ongemakkelijk als een mens die output controleert de enige control is. Automation complacency komt voor bij experts én beginners en verdwijnt niet door simpelweg te oefenen. Training of instructies voorkomen automation bias niet betrouwbaar. Het veroorzaakt beide soorten fouten: accepteren wat de machine fout deed en missen wat de machine nooit signaleerde.</p>
Een eerder experiment laat het onderliggende effect zien. In een gesimuleerde vliegtaak uit 1999</a> presteerden deelnemers zonder geautomatiseerd hulpmiddel beter op monitoring dan deelnemers met een zeer, maar niet volledig betrouwbare tool. De groep met ondersteuning maakte omissiefouten wanneer de automatisering een gebeurtenis niet markeerde, en commissiefouten wanneer ze een slecht advies volgden terwijl andere geldige informatie beschikbaar was.</p>
Dit onderzoek stamt van vóór AI-agents in productie en gaat over geautomatiseerde beslisondersteuning, grotendeels in de luchtvaart. Het stelt geen foutpercentage voor agentreview vast. Het laat wel zien waarom menselijke review niet de enige control moet zijn: aandacht is begrensd en betrouwbare automatisering verandert waar mensen die aandacht aan besteden.</p>
Menselijke review blijft nodig. Het reviewpercentage, de steekproef en de escalatieregels moeten structureel zijn. Leg in beleid vast hoeveel van de agentoutput een mens moet zien en laat het systeem dat afdwingen. Laat het niet afhangen van het oordeel van de reviewer op die dag.</p>
03</span>Wat zijn de drie niveaus?</h2>
Elke agent die we runnen staat op een van drie niveaus. Het niveau is een instelling in Aitonomy Control. Iedereen met toegang ziet op welk niveau een agent vandaag staat en welk bewijs hem daar heeft gebracht.</p>

</th> Wat de agent doet</th> Wat een mens doet</th></tr> </thead>

Suggests</th> Doet een aanbeveling en verandert niets</td> Beoordeelt elk resultaat inhoudelijk en voert de handeling uit of keurt die goed</td></tr>
Drafts</th> Rondt het werk af en zet de handeling klaar</td> Keurt elke handeling goed, met gerichte review van uitzonderingen en geselecteerde details</td></tr>
Auto</th> Rondt afgesproken routinecases af en handelt binnen de scope</td> Beoordeelt een steekproef en elke escalatie, en kan de agent pauzeren</td></tr> </tbody> </table> </div>
Elke agent begint bij Suggests. Er is geen versnelde route voor een proces waar iemand veel vertrouwen in heeft. Een agent begint ook niet bij Auto omdat een vergelijkbare agent elders dat niveau heeft verdiend.</p>
De derde kolom is de belangrijkste. Een niveau is een afspraak over hoeveel menselijke aandacht het werk verbruikt. Dat maakt het onderdeel van de operationele kosten</a> én van de controls. Een agent van Suggests naar Drafts verplaatsen kan tijd vrijmaken, mits goedkeuring minder inspanning kost dan het oorspronkelijke werk en de vrijgekomen capaciteit wordt benut. Daarom verruimen we een niveau nooit achteloos.</p>
04</span>Wat laat een agent een niveau stijgen?</h2>
Vijf soorten bewijs, in een vaste combinatie. Control meet ze alle vijf voortdurend aan drempels die vóór de eerste run zijn vastgesteld.</p>
Tijd op het huidige niveau.</b> Lang genoeg om de variatie van het proces zichtbaar te maken, ook in delen van de maand of het kwartaal die anders verlopen.</p>
Volume.</b> Genoeg afgeronde cases om de interventiegraad betekenis te geven. Een handvol foutloze resultaten is geen bewijs.</p>
Interventiegraad.</b> Het aandeel van de agentoutput dat een mens wijzigde voordat het effect kreeg. Dat aandeel moet dalen en onder de norm van het niveau blijven.</p>
Blijvende kwaliteit.</b> Het aandeel dat na de afgesproken periode nog standhoudt. Dat is een ander cijfer dan het aandeel dat op de dag zelf werd geaccepteerd. Het verschil tussen beide</a> is werk dat iemand opnieuw opende, corrigeerde of terugdraaide. Een agent die alleen op acceptatie van dag één promoveert, promoveert op het verkeerde signaal.</p>
Geen kritieke fouten.</b> Een kritieke fout is een uitkomst die een vooraf bepaalde grens voor die agent overschrijdt. Het beleid beschrijft welke uitkomsten hieronder vallen, welk bewijs nodig is en wie een fout mag vastleggen. Tijdens de kwalificatieperiode mag er geen optreden.</p>
We beginnen met standaardbeleid en spreken de drempels per agent af. Daarna laden we ze in Control, zodat altijd het afgesproken getal wordt afgedwongen. Ook een processpecifieke afwijking wordt daar geconfigureerd, met de reden erbij. De cijfers blijven in het ondertekende beleid. De juiste drempel voor factuurmatching is niet de juiste drempel voor werk waarbij fouten een klant bereiken. Wat niet varieert: de drempels staan vast vóór de agent draait en blijven de maatstaf voor latere beoordeling.</p>

Waarom je ze vooraf vastlegt</p>
Een drempel die je afspreekt nadat de resultaten binnen zijn, is geen drempel. Als het getal kan meebewegen met het bewijs, verliest het bewijs zijn functie. De promotiebeslissing ligt dan stilletjes weer bij degene met het meeste zelfvertrouwen in de vergadering.</p> </div>
05</span>Wat zet de agent weer een niveau lager?</h2>
Dezelfde cijfers. Een ladder die alleen omhooggaat, beschrijft een lancering. De weg omlaag maakt het supervision. Juist die blijft vaak onbeschreven.</p>
Een kritieke fout verlaagt het niveau direct.</b> Zodra een fout volgens de afgesproken definitie is vastgelegd, verlaagt Control het niveau. Eén fout is genoeg. Het systeem wacht niet op de maandelijkse review en weegt de fout niet af tegen hoe goed de agent verder draaide.</p>
Een stijgende interventiegraad bevriest de scope.</b> Dat is op zichzelf geen verlaging, maar de agent breidt niet verder uit totdat de oorzaak bekend is. De scope groeit niet terwijl mensen steeds vaker corrigeren.</p>
Een modelwijziging stuurt de agent terug naar de testset.</b> Een ander model maakt het bewijs bij de vorige configuratie ongeldig totdat de apart gehouden cases opnieuw zijn gedraaid. De agent behoudt zijn niveau alleen als de nieuwe configuratie dezelfde norm haalt.</p>
Control voert de geconfigureerde reactie uit zodra het bewijs aan een van deze voorwaarden voldoet. Het systeem vertrouwt er niet op dat een reviewer tijdens routinegoedkeuring afwijkingen opmerkt. Dan zou juist de zwakte terugkeren die de niveaus moeten verkleinen.</p>
In Aitonomy Control. Daar staan voor elke agent het huidige niveau, het onderliggende bewijs, de afgedwongen drempels en de beslisgeschiedenis. Een mens keurt een stijging goed. Bereikt het vastgelegde bewijs een geconfigureerde verlagingsvoorwaarde, dan bevriest of verlaagt Control de autonomie zonder op de maandelijkse review te wachten. Zo ontstaat een traceerbare operationele vastlegging</a> die een auditor of toezichthouder kan beoordelen, geen reconstructie achteraf.</p>
Elke agent krijgt maandelijks een besluit: verruimen, behouden, terugzetten of stoppen. Het bewijs ligt al klaar. De vergadering gaat dus over het oordeel, niet over het verzamelen van de onderbouwing. Behouden hoort een normale uitkomst te zijn. Als elke agent in een portfolio wordt verruimd, moet je je afvragen of de interventiegraad en blijvende kwaliteit wel genoeg gewicht krijgen.</p>
Met een korte toets zie je of dit binnen een organisatie werkelijk bestaat. Toegang tot het systeem is niet nodig. Vraag wanneer een agent voor het laatst een niveau omlaag ging. Vraag wie daartoe bevoegd is en of die persoon daarvoor toestemming nodig heeft. Kan niemand uitleggen hoe een verlaging werkt of heeft niemand de bevoegdheid, dan zijn de niveaus slechts labels.</p>
Een agent wordt niet betrouwbaar doordat hij al een tijd draait. Betrouwbaarheid ontstaat doordat de agent bewijs levert tegen een norm die is vastgesteld vóór iemand wist of hij die zou halen. En doordat dezelfde norm dat vertrouwen ook weer kan terugnemen.</p>
Veelgestelde vragen</h2>

Wat zijn supervision levels voor AI-agents?+</span></summary>
Ze bepalen hoeveel van het werk van een agent door een mens moet worden beoordeeld. Bij Suggests beveelt de agent een handeling aan maar verandert niets. Bij Drafts rondt hij het werk af en wacht op goedkeuring. Bij Auto handelt hij binnen de goedgekeurde scope, terwijl escalaties en een steekproef nog steeds worden beoordeeld.</div> </details>

Hoe verdient een AI-agent meer autonomie?+</span></summary>
Door drempels te halen die vooraf zijn vastgesteld. Het bewijs omvat tijd en volume op het huidige niveau, de menselijke interventiegraad, of resultaten na een afgesproken periode standhouden en of er kritieke fouten optraden. Elke agent begint op het niveau met de meeste review.</div> </details>

Kan menselijke review elke fout van een AI-agent onderscheppen?+</span></summary>
Nee. Mensen worden minder alert wanneer een geautomatiseerd systeem meestal gelijk heeft. Dit goed gedocumenteerde effect heet automation complacency. Menselijke review blijft nodig, maar mag niet de enige control zijn. Reviewpercentages, escalatieregels, automatische controles en een leesbare vastlegging van wat de agent deed</a> moeten in het operationele model zijn ingebouwd.</div> </details>

Wanneer moet een AI-agent autonomie verliezen?+</span></summary>
Een kritieke fout moet de autonomie direct verlagen en de vereiste review verhogen. Een stijgende interventiegraad stopt elke uitbreiding tot de oorzaak bekend is. Een modelwijziging leidt tot nieuwe tests voordat de agent zijn bestaande niveau behoudt. Deze regels horen bij een agent in productie runnen</a> en moeten worden afgedwongen, niet aan iemands geheugen worden overgelaten.</div> </details> </div>

Bronnen</h4>

Thomas Sheridan and William Verplank, Human and Computer Control of Undersea Teleoperators</a>, MIT Man-Machine Systems Laboratory (1978), the ten-point scale of human supervisory control that later levels-of-automation work is built on</li>
Raja Parasuraman, Thomas Sheridan and Christopher Wickens, A Model for Types and Levels of Human Interaction with Automation</a>, IEEE Transactions on Systems, Man, and Cybernetics</i> 30:3 (2000), separating automation into information acquisition, analysis, decision selection and action implementation</li>
Linda Skitka, Kathleen Mosier and Mark Burdick, Does Automation Bias Decision-Making?</a>, International Journal of Human-Computer Studies</i> 51:5 (1999), comparing monitoring with and without a highly but imperfectly reliable automated aid</li>
Raja Parasuraman and Dietrich Manzey, Complacency and Bias in Human Use of Automation: An Attentional Integration</a>, Human Factors</i> 52:3 (2010), reviewing automation complacency, automation bias and the limits of practice, training and instructions</li>
De drie niveaus, het bewijs voor verhoging en de regels voor verlaging zijn van Aitonomy zelf. Ze komen uit het autonomiebeleid dat we per agent ondertekenen en in Aitonomy Control afdwingen. De drempels zelf staan in dat beleid en publiceren we hier niet.</li> </ul> </div> </div> </article>
Zo bouw je de businesscase voor een AI-agent

Joep — Wed, 26 Aug 2026 00:00:00 +0000

De meeste adviezen over AI-businesscases richten zich op de presentatie van de uitkomst: vertaal voordelen naar geld, toon een bandbreedte en bereken de terugverdientijd. Dat telt, maar veronderstelt dat de onderliggende cijfers kloppen.</p>
Een businesscase voor een AI-agent vergelijkt na met voor. Begin met één proces en leg het huidige volume, de inspanning, kwaliteit, wachttijd en kosten vast. Schat vervolgens welk deel van die inspanning bij een agent past</a>, trek review- en operationele kosten af, benoem of de uitkomst cash, vermeden kosten of vrijgekomen capaciteit is en maak één vaste eigenaar verantwoordelijk.</p>
Houd elke schatting zichtbaar. Na go-live gebruik je dezelfde case om te toetsen of de agent de investering waard was.</p>
Voor McKinsey’s State of AI</a>-onderzoek, gepubliceerd in augustus 2026, reageerden 1.719 deelnemers. 80 procent zei dat AI hun individuele productiviteit had verbeterd. 37 procent schreef minstens enig effect op het bedrijfsresultaat vóór rente en belasting toe aan AI. Zes procent voldeed aan McKinsey’s veel hogere norm voor een AI high performer: minstens 5 procent van de EBIT toegeschreven aan AI én naar eigen zeggen aanzienlijke impact.</p>
Die cijfers spreken elkaar niet tegen. Ze meten individuele ervaring, enige financiële impact op organisatieniveau en een veeleisende prestatiedrempel. Wie ze samenvoegt tot één succespercentage, verwijdert precies het onderscheid dat een businesscase nodig heeft: wat veranderde, voor wie en ten opzichte van welk vertrekpunt?</p>
Gartner voorspelt</a> dat eind 2027 meer dan 40 procent van de agentic-AI-projecten is stopgezet. Genoemde redenen zijn oplopende kosten, onduidelijke bedrijfswaarde en gebrekkige risicocontroles. Elk daarvan hoort vóór de bouw in de case.</p>
Een onderzoek uit 2026 in California Management Review</a> onder 24 professionals vond een vergelijkbaar patroon. Tien noemden het ontbreken van een succesmaatstaf vóór aankoop als grootste belemmering voor het meten van financiële impact. Slechts twee gebruikten een controlegroep of A/B-test. Zestien vertrouwden op zelfgerapporteerde tijdwinst, terwijl maar negen werkelijk vertrouwen hadden in dat bewijs.</p>
Je kunt verbetering niet meten aan een doel dat niet bestaat. Mahboubeh Cheraghian</b> · California Management Review</a>, August 2026</cite> </blockquote>
De steekproef was klein en doelgericht en onderzocht AI op de werkvloer, niet agents in productie. Ze kan dus geen algemeen percentage vaststellen. Wel illustreert ze het meetprobleem dat een businesscase moet oplossen.</p>
02</span>Wat is een nulmeting?</h2>
Een nulmeting legt vast hoe het werk presteert voordat het operationele model verandert. De periode moet lang genoeg zijn om normale variatie te omvatten. Bij seizoensgebonden vraag kan dat een volledige cyclus zijn. Bij stabiel werk met veel volume kan een kortere periode volstaan.</p>
De nuttige maatstaven hangen af van de geclaimde waarde. Meestal omvatten ze volume, behandelinspanning, doorlooptijd, ouderdom van de wachtrij, herstelwerk, afwijzingen, uitzonderingen, escalaties en de kosten van betrokken mensen en systemen. Alleen gemiddelden zijn zelden genoeg. Als de moeilijkste 20 procent van de cases de helft van de inspanning vraagt, verbergt de gemiddelde behandeltijd juist het werk dat overblijft.</p>
Ook de uurkosten bepalen wat het getal betekent. Een volledig kostentarief kan een capaciteitsequivalent voordeel beschrijven, maar bewijst geen cashbesparing. Het onderscheid tussen cash, vermeden kosten en vrijgekomen capaciteit bepaalt wat de case werkelijk mag claimen.</p>
Bij de meeste organisaties ontbreken enkele van deze maatstaven. De case kan nog steeds worden gebouwd, zolang duidelijk is welke cijfers op bewijs rusten en welke aannames blijven.</p>

</th> Gemeten nulmeting</th> Gemodelleerde nulmeting</th></tr> </thead>

Vertrekt vanuit</th> De eigen vastgelegde historie van de organisatie</td> Beschikbare records plus een benchmark of expliciete aanname</td></tr>
Beantwoordt</th> Wat het werk aantoonbaar deed</td> Wat het werk waarschijnlijk deed, binnen een aangegeven bandbreedte</td></tr>
Bevat</th> Grenzen aan datakwaliteit en normale variatie</td> Aannames, bandbreedtes en een betrouwbaarheidsniveau</td></tr>
Faalt wanneer</th> Onvolledige records als volledig worden behandeld</td> Een schatting als meting wordt gepresenteerd</td></tr> </tbody> </table> </div>
Na go-live kan een historische nulmeting soms nog worden hersteld, maar mogelijk is die niet meer vergelijkbaar. Proces, volumes, team en gedrag kunnen al zijn veranderd. De nulmeting vooraf vastleggen verkleint hindsight bias en bewaart de omstandigheden waaronder de beslissing is genomen.</p>

Onze vaste regel</p>
Een eerlijk gelabelde gemodelleerde nulmeting is beter dan een verzonnen nulmeting die stilzwijgend als feit geldt. Laat het label staan wanneer het getal opnieuw wordt gebruikt. Wordt een schatting later door een meting vervangen, dan moet de vastlegging tonen</a> wat veranderde en waarom.</p> </div>

De andere vijf velden hangen af van de nulmeting.</b> Dit is ook het enige veld dat je op twee manieren kunt bepalen. Daarom legt de pagina vast welke route is gebruikt.</figcaption> </figure>
Het werk en de bedrijfsuitkomst.</b> Het operationele probleem, het gewenste resultaat en de grens van de voorgestelde verantwoordelijkheid van de agent. Begin bij de uitkomst en bepaal daarna wat bij mensen, een agent en bestaande automatisering hoort.</p>
Kwaliteit en gevolgen.</b> De norm waaraan het werk moet voldoen, wat er gebeurt als het fout is en waar menselijke goedkeuring of escalatie nodig blijft</a>.</p>
De nulmeting.</b> Huidig volume, inspanning, kwaliteit, wachttijd en kosten. Elk belangrijk getal krijgt het label gemeten of gemodelleerd, met periode en bron.</p>
Investering en operationele kosten.</b> Bouw en integratie, plus de doorlopende kosten: model- en toolgebruik, menselijke review, uitzonderingsafhandeling, monitoring, governance, onderhoud, procesverandering en de kosten van stoppen of fouten herstellen.</p>
Het doel en meetplan.</b> De primaire uitkomst die moet verbeteren, de verwachte bandbreedte, hoe het effect wordt toegeschreven en welk bewijs nodig is om door te gaan, de scope te verkleinen of te stoppen. Waar het proces dit toelaat, is een gefaseerde uitrol, matched comparison of holdout sterker dan een simpele voor-en-nameting.</p>
De benoemde eigenaar en het conversieplan.</b> Eén persoon bij de klant is verantwoordelijk voor het resultaat en bepaalt wat vrijgekomen capaciteit wordt. Een afdeling kan geen tijd herverdelen en geen verantwoording afleggen voor een gemist doel.</p>
Kosten, verwachte waarde en beslismoment moeten samen leesbaar zijn. Het doel beschrijft hoe het wordt gemeten. Elke capaciteitsclaim legt uit hoe de vrijgekomen tijd wordt gebruikt.</p>
04</span>Waarom overschat theoretische capaciteit de waarde?</h2>
Theoretische capaciteit wordt meestal berekend als volume maal gemiddelde behandeltijd maal het aandeel cases dat een agent kan overnemen. Dat geeft een bruikbaar plafond, niet het verwachte voordeel. Voor een bruikbare schatting zijn drie verdere correcties nodig.</p>
Dekking moet naar inspanning worden gewogen.</b> Agents beginnen vaak met het werk dat het eenvoudigst te herkennen en controleren is. Daarmee kan een groot aandeel van de cases verdwijnen, terwijl een veel groter aandeel van de inspanning blijft.</p>
Crediteurenadministratie biedt een bruikbaar voorbeeld. De benchmark van Ardent Partners uit 2025, gepubliceerd door Medius</a>, rapporteert gemiddeld 22 procent factuuruitzonderingen. Voor de berekening hieronder nemen we aan dat een uitzondering vier keer zoveel inspanning vraagt als een factuur die rechtstreeks wordt verwerkt.</p>

</th> Rechtstreeks verwerkt</th> Uitzonderingen</th></tr> </thead>

Aandeel cases</th> 78 procent</td> 22 procent</td></tr>
Aangenomen relatieve inspanning per case</th> 1</td> 4</td></tr>
Aandeel totale inspanning</th> 47 procent</b></td> 53 procent</b></td></tr> </tbody> </table> </div>
In dit vereenvoudigde voorbeeld verwijdert het overnemen van alle rechtstreekse facturen 78 procent van het volume, maar slechts 47 procent van de inspanning. De factor vier is illustratief en geen bevinding van Ardent Partners. Gebruik voor een echte case de eigen behandeldata.</p>
Review en restwerk blijven bestaan.</b> Een mens moet mogelijk nog resultaten controleren, uitzonderingen afhandelen en genoeg context behouden om in te grijpen. Bainbridge beschreef dit operationele probleem in Ironies of Automation</a>: routinewerk automatiseren kan mensen achterlaten met afwijkende situaties én een nieuwe monitoringtaak. Zij schreef over industriële automatisering, niet over AI-agents, maar dezelfde workloadvraag hoort in deze case. Menselijke controle kost tijd en die tijd moet worden gemeten.</p>
Vrijgekomen capaciteit moet bruikbaar zijn.</b> Dertig minuten uit één wachtrij halen kan de service direct verbeteren. Twee minuten verspreid over vijftien mensen worden mogelijk nooit cash of extra output. De businesscase moet zeggen welke uitkomst wordt verwacht.</p>
Customer support geeft nog een voorbeeld. Een deflected case eindigde zonder een mens te bereiken. Een resolved case eindigde omdat het probleem van de klant was opgelost. Beide als dezelfde uitkomst tellen, maakt van een systeemevent een waardeclaim zonder te controleren wat er werkelijk gebeurde.</p>
05</span>Met welk getal moet je plannen?</h2>
Gebruik het beschikbare bewijs om een bandbreedte te plannen, in plaats van te beginnen met een universele kortingsfactor.</p>

Potentieel vrijgekomen capaciteit</p>
Huidig casevolume × huidige inspanning × naar inspanning gewogen dekking</b>, minus review, herstelwerk en resterende inspanning voor uitzonderingen.</p> </div>
Classificeer daarna de uitkomst. De vier regels zijn niet onderling uitwisselbaar.</p>

Classificatie</th> Wat de case mag meetellen</th></tr> </thead>

Cashbesparing</th> Uitgaven die werkelijk uit de kostenbasis verdwijnen</td></tr>
Vermeden kosten</th> Een specifieke hire, contractor of dienst die niet langer nodig is</td></tr>
Vrijgekomen capaciteit</th> Capaciteitsequivalente uren, los van cash totdat ze een gemeten uitkomst opleveren</td></tr>
Operationele waarde</th> Verbetering van kwaliteit, beschikbaarheid, output of risico, met een eigen nulmeting</td></tr> </tbody> </table> </div>
Trek ten slotte de volledige eigendomskosten af: bouw, integratie, gebruik, review, control, onderhoud en verandering. Is een belangrijke input onbekend, toon die dan als bandbreedte en maak het verkleinen daarvan een beslismoment.</p>
Workday’s onderzoek uit januari 2026</a> laat zien waarom review in de berekening hoort. In een enquête onder 3.200 actieve AI-gebruikers op de werkvloer ging bijna 40 procent van de gerapporteerde tijdwinst terug naar herstelwerk. Slechts 14 procent meldde consequent een duidelijk positief nettoresultaat. Het bewijs is zelfgerapporteerd en gaat niet over productie-agents. Het levert dus geen kortingsfactor voor een specifiek proces, maar toont wel het risico van bruto tijdwinst als waarde behandelen zonder het herstelwerk te bekijken.</p>
Laat in de lage, verwachte en hoge scenario's de aannames variëren die ertoe doen: naar inspanning gewogen dekking, verificatiekosten, uitzonderingslast, operationele kosten en het aandeel capaciteit dat kan worden omgezet. Gebruik scenario's om onzekerheid zichtbaar te maken, niet om dezelfde ongefundeerde schatting drie labels te geven.</p>
Is de bandbreedte te groot voor een beslissing, meet dan vóór de bouw wat ontbreekt. Afhankelijk van de uitkomst moet de voorgestelde rol mogelijk worden verkleind of gestopt.</p>
06</span>Wat als de waarde niet in uren zit?</h2>
Uren worden vaak gebruikt omdat ze gemakkelijk te tellen zijn, maar vormen lang niet altijd de sterkste waardemaatstaf.</p>
Kwaliteit.</b> Bij een meetbaar fout- of herstelpercentage kan waarde ontstaan door minder correcties, creditnota's, klachten of heropende cases. Een agent kan een regel consistenter toepassen. Behandel dat als een te bewijzen doel, niet als gegarandeerde eigenschap.</p>
Beschikbaarheid.</b> Werk dat een nacht of in een wachtrij blijft liggen, heeft servicekosten. De nulmeting bestaat uit wachtrijleeftijd, tijd tot eerste reactie en het aandeel cases dat een serviceniveau overschrijdt. Meet het resultaat in doorlooptijd en serviceprestatie, niet automatisch in headcount.</p>
Capaciteit zonder nieuwe mensen.</b> Bij groeiende vraag kan het handhaven van het serviceniveau terwijl het volume stijgt een geplande hire of externe dienst voorkomen. De case heeft de volumetrend, de personeelstrigger en het moment nodig waarop de uitgave anders zou ontstaan.</p>
Het werk dat overblijft.</b> Routineadministratie wegnemen kan mensen meer ruimte geven voor uitzonderingen en afwegingen. Dat is pas waardevol wanneer de organisatie benoemt waar die tijd naartoe gaat en meet wat verbetert.</p>

Waardelijn</th> Nulmeting</th> Bewijs na go-live</th></tr> </thead>

Kwaliteit</th> Fout-, herstel- en afwijzingspercentages</td> Correcties, klachten en creditnota's</td></tr>
Beschikbaarheid</th> Wachtrijleeftijd en reactietijd</td> Doorlooptijd en serviceniveau</td></tr>
Vermeden hire</th> Volumetrend en personeelstrigger</td> Service behouden zonder de geplande uitgave</td></tr>
Restwerk</th> Achterstand, overwerk en leeftijd van uitzonderingen</td> Moeilijke cases sneller of beter afgehandeld</td></tr> </tbody> </table> </div>
Snellere afhandeling, vrijgekomen capaciteit en vermeden hires kunnen dezelfde onderliggende verandering beschrijven. Ze apart optellen overschat de case. Kies één primaire financiële claim, behoud de operationele maatstaven die hem bewijzen en ken geen geld toe aan andere verwachte effecten tenzij die onafhankelijk meetbaar zijn.</p>
07</span>Hoe ziet een gemodelleerde nulmeting eruit?</h2>
In een geanonimiseerde case was geen gemeten nulmeting van de behandeltijd beschikbaar, terwijl een beslissing nodig was voordat die kon worden gemaakt.</p>
We combineerden de vastgelegde volumes met aannames over de behandeltijd in de kandidaatprocessen. De uitkomst was een schatting van ongeveer 5.800 capaciteitsequivalente uren per jaar. We behandelden die als vertrekpunt, niet als besparing.</p>
Herinzetbaarheid was de enige factor met steviger bewijs, omdat het bezettingspatroon liet zien hoeveel vrijgekomen tijd realistisch kon worden benut. We stelden dat op ongeveer twee derde. Zo ontstond een verwacht scenario van circa 3.750 capaciteitsequivalente uren.</p>
Dekking en verificatie waren nog niet op echte cases gemeten. In plaats van vaste kortingspercentages kreeg de case een bandbreedte van 2.000 tot 6.000 uur. De bovengrens lag iets boven de startsom omdat ook de behandeltijd onzeker bleef. Elk cijfer kreeg het label hypothese.</p>
De bandbreedte maakte zichtbaar wat de beoordeling nog moest meten: behandelinspanning per casetype, haalbare dekking op apart gehouden werk en de tijd om een resultaat te controleren. Met elke bevinding werd de bandbreedte kleiner en kon de bouwbeslissing veranderen.</p>
Zo maakt een gemodelleerde nulmeting onzekerheid toetsbaar zonder haar als feit te presenteren.</p>
08</span>Hoe blijft de case leven na goedkeuring?</h2>
De nulmeting, het doel en het meetplan blijven na go-live aan het werk gekoppeld. Elke rapportageperiode vergelijkt live bewijs met de voorwaarden die vóór de beslissing zijn vastgelegd en voedt de operationele vastlegging</a>.</p>
Voor een stabiel proces met veel volume kan een simpele voor-en-navergelijking genoeg zijn. Kunnen seizoenen, bezetting of veranderende vraag het resultaat verklaren, gebruik dan waar mogelijk sterkere attributie: een gefaseerde uitrol, matched team, holdout-wachtrij of gedocumenteerde trendvergelijking.</p>
De cijfers mogen veranderen wanneer de werkelijkheid verandert, zolang de wijziging traceerbaar blijft. Worden nulmeting, scope of doel herzien, dan toont de vastlegging de oude waarde, de nieuwe waarde, de reden en wie goedkeurde.</p>
Een businesscase moet ruimte laten voor nee. Als het bewijs geen haalbare bandbreedte ondersteunt, de volledige operationele kosten de waarde wegnemen, de gevolgen van falen te groot zijn of niemand eigenaar is, kan eerst voorbereiden, de rol verkleinen of het werk bij mensen laten de juiste beslissing zijn. Anders dan een voorstel moet de case ook een besluit om niet door te gaan ondersteunen.</p>
09</span>Waar passen de Scan en Aitonomy Control?</h2>
De Scan en ons team stellen de nulmeting vast vóór de bouwbeslissing. Met goedgekeurde toegang tot de betrokken systemen reconstrueren we het vastgelegde proces, toetsen we de kwaliteit van het bewijs en onderzoeken we de gaten met de mensen die eigenaar zijn van het werk. Samen labelen we wat gemeten is, wat gemodelleerd is en wat nog moet worden bewezen.</p>
Het resultaat is een case van één pagina die openstaande aannames toont en vier mogelijke beslissingen ondersteunt.</p>

Beslissing</th> Wat die betekent</th></tr> </thead>

Bouwen</th> Het bewijs ondersteunt doorgaan met de voorgestelde rol en controls</td></tr>
Eerst voorbereiden</th> Kansrijk, maar data, proces, eigenaarschap of controls vragen werk vóór de bouw</td></tr>
Scope verkleinen</th> Slechts een deel van de voorgestelde rol is waardevol, haalbaar en veilig genoeg</td></tr>
Stoppen</th> De verwachte waarde, haalbaarheid of het risico rechtvaardigt doorgaan niet</td></tr> </tbody> </table> </div>
Gaat het werk door, dan levert Aitonomy Control de runtime, monitoring, governance en traceerbaarheid in productie. De operationele vastlegging vergelijkt live prestaties met de afgesproken nulmeting en het doel.</p>
Voor een eerste test heb je geen Scan nodig. Neem het proces dat jullie al overwegen en probeer de zes velden in te vullen. Kun je de nulmeting, totale operationele kosten of vaste eigenaar niet invullen, dan weet je waar je moet beginnen. Het bewijs achter die velden produceren is waar wij beginnen</a>.</p>
Bouw de businesscase vóór de agent en blijf haar na go-live gebruiken. Alleen dan kun je de verwachte waarde toetsen aan wat werkelijk gebeurde.</p>
Veelgestelde vragen</h2>

Hoe bereken je de ROI van een AI-agent?+</span></summary>
Begin met werk dat geschikt is voor een AI-agent</a> en leg huidig volume, inspanning, kwaliteit, wachttijd en kosten vast. Schat hoeveel inspanning de agent kan overnemen en trek review- en operationele kosten af. Benoem de waarde eerlijk als cashbesparing, vermeden kosten of vrijgekomen capaciteit. Die zijn niet hetzelfde.</div> </details>

Wat als er geen data voor een nulmeting is?+</span></summary>
Bouw een gemodelleerde nulmeting uit een vergelijkbaar proces, externe benchmark of expliciete aanname en label die duidelijk. Houd aannames zichtbaar, zodat ze kunnen worden betwist en vervangen wanneer echte data beschikbaar komt. Een schatting is bruikbaar als iedereen ziet dat het een schatting is.</div> </details>

Waarom kan theoretische tijdwinst de waarde overschatten?+</span></summary>
Casevolume en menselijke inspanning zijn niet gelijk verdeeld. Een agent kan veel eenvoudige cases afhandelen terwijl de tragere uitzonderingen bij het team blijven. Zo verdwijnt veel volume zonder dat hetzelfde aandeel werk verdwijnt. Baseer waarde op inspanning die werkelijk verdwijnt of elders bruikbaar wordt.</div> </details>

Wat hoort in de businesscase voor een AI-agent?+</span></summary>
Zet zes zaken op één pagina: werk en beoogde uitkomst, vereiste kwaliteit en gevolgen van fouten, nulmeting, investering en operationele kosten, doel en meetplan en een vaste eigenaar. Hangt de case af van vrijgekomen capaciteit, zeg dan hoe die wordt gebruikt. Het bewijs moet vier beslissingen ondersteunen: bouwen, eerst voorbereiden, scope verkleinen of stoppen. Bij bouwen blijft de case in gebruik terwijl de agent in productie draait</a>.</div> </details>

Is vrijgekomen capaciteit hetzelfde als een kostenbesparing?+</span></summary>
Nee. Vrijgekomen capaciteit betekent dat mensen tijd beschikbaar hebben voor ander werk. Het wordt pas een cashbesparing wanneer uitgaven uit de kostenbasis verdwijnen, en vermeden kosten wanneer een geplande hire of uitgave niet meer nodig is. Houd deze drie waardevormen in de case apart.</div> </details> </div>

Bronnen</h4>

McKinsey & Company, The state of AI in 2026: On the road to ROI</a> (August 2026), a survey of 1,719 participants, on individual productivity, EBIT attribution and the high-performer threshold</li>
Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027</a> (June 2025), naming escalating costs, unclear business value and inadequate risk controls</li>
Mahboubeh Cheraghian, Beyond AI Licenses: How to Measure Whether Your AI Is Actually Working</a>, California Management Review</i> (August 2026), a structured study of 24 practitioners on measurement barriers and attribution</li>
Workday, Beyond Productivity: Measuring the Real Value of AI</a> (January 2026), a survey of 3,200 active workplace AI users, fielded in November 2025</li>
Ardent Partners, Accounts Payable Metrics that Matter in 2025</a>, on an average invoice exception rate of 22 percent. The four-times effort multiplier used above is illustrative and is not an Ardent Partners finding</li>
Lisanne Bainbridge, Ironies of Automation</a>, Automatica</i> 19:6 (1983), on the residual work and monitoring duty left to people after automation</li>
The six-field business case, the measured and modelled baseline labels, and the anonymised example are part of Aitonomy’s Scan method. The example has its organisation, sector and commercial terms removed.</li> </ul> </div> </div> </article>
Welk werk is geschikt voor een AI-agent?

Joep — Thu, 13 Aug 2026 00:00:00 +0000

Vraag welk werk geschikt is voor een AI-agent en je krijgt meestal hetzelfde antwoord. Herhaalbaar. Veel volume. Duidelijke regels. Digitale input. Een heldere definitie van klaar, met iemand beschikbaar voor uitzonderingen.</p>
Dat is allemaal nuttig. Het beschrijft wat een agent kan</a>. Dat is iets anders dan welk werk de moeite waard is om over te dragen. Een proces kan aan de hele lijst voldoen en toch financieel onaantrekkelijk zijn, of meer controle vragen dan de opbrengst rechtvaardigt.</p>
Het korte antwoord: werk past wanneer het vaak genoeg terugkeert om te meten, een correct resultaat betaalbaar te controleren is, fouten begrensd of omkeerbaar zijn en een vaste persoon uitzonderingen kan afhandelen. Volume en duidelijke regels bepalen de haalbaarheid. Verificatiekosten en de gevolgen van fouten bepalen of overdracht waarde creëert.</p>
01</span>Wat ziet het gebruikelijke advies goed?</h2>
Best veel. De gebruikelijke lijst is een echte filter en verwijdert veel zwakke kandidaten. Werk dat op papier binnenkomt, vier keer per jaar voorkomt of afhangt van regels die niemand kan uitleggen, is moeilijker over te dragen. Daarmee beginnen maakt een toch al onzekere bouw duurder.</p>
De beperking is dat de lijst alleen de inputkant beschrijft. Is het werk leesbaar? Is er genoeg volume? Zijn de systemen bereikbaar? De lijst vraagt niet wat het werk kost zodra een agent het uitvoert.</p>
Twee aanvullende vragen bepalen dat. Wat kost het om één resultaat te controleren? En wat gebeurt er als een fout resultaat doorglipt? Beide kun je onderzoeken voordat er iets wordt gebouwd.</p>
Aanpalend onderzoek naar AI op de werkvloer laat zien hoeveel schijnbare productiviteit daarin kan verdwijnen. Workday ondervroeg in november 2025 3.200 fulltime medewerkers bij organisaties met meer dan 100 miljoen dollar jaaromzet, allemaal actieve AI-gebruikers. De resultaten verschenen in januari 2026</a>. 85 procent meldde een besparing van één tot zeven uur per week. Workday rapporteerde ook:</p>
Bijna 40 procent van de tijdwinst door AI gaat verloren aan herstelwerk, zoals fouten corrigeren, content herschrijven en output controleren. Workday</b> · Beyond Productivity</a>, January 2026</cite> </blockquote>
Slechts 14 procent van de respondenten rapporteerde consequent een duidelijk positief nettoresultaat. Van de frequente gebruikers zei 77 procent AI-gegenereerd werk minstens zo zorgvuldig te controleren als mensenwerk.</p>
Dit is zelfgerapporteerd onderzoek naar AI op de werkvloer, geen meting van agents in productie. Het bewijst niet wat verificatie in een specifiek proces kost. Het laat wel zien waarom die kosten vanaf het begin in de businesscase horen.</p>
Een systematische review en meta-analyse</a> uit 2024 van 106 experimenten kwam tot een verwante conclusie. Gemiddeld presteerde de combinatie mens en AI slechter dan de beste van de twee afzonderlijk. Waar mensen beter waren dan AI, hielp de combinatie. Waar AI beter was dan mensen, werkte de combinatie juist nadelig. Het onderzoek ging niet over productie-agents, maar onderstreept hetzelfde punt vanuit een andere hoek: een mens in de loop maakt het resultaat niet automatisch beter.</p>
Behandel verificatie daarom als terugkerende operationele kosten, totdat bewijs laat zien dat minder controle verantwoord is. Betere kwaliteit, deterministische controles, gerichtere steekproeven en verdiende autonomie kunnen de benodigde review verminderen. Nauwkeurigheid alleen neemt verantwoordelijkheid niet weg.</p>
De nuttige vraag is dus niet of controle verdwijnt. Vraag wat één controle kost, wie die kan uitvoeren en welk bewijs minder controle zou rechtvaardigen.</p>

</th> Een factuur aan een order koppelen</th> Zes maanden notities samenvatten</th></tr> </thead>

De controle is</th> Komen de drie documenten overeen?</td> Geeft dit het dossier eerlijk weer?</td></tr>
Tijd tot zekerheid</th> Seconden</td> Mogelijk even lang als het oorspronkelijke werk</td></tr>
Wie kan het doen</th> Iedereen die de regel kent</td> Iemand die het bronmateriaal kent</td></tr>
Een fout wordt zichtbaar</th> Direct</td> Wanneer iemand op de samenvatting vertrouwt</td></tr> </tbody> </table> </div>
Dezelfde organisatie, dezelfde systemen, vergelijkbaar volume. Een totaal andere economie.</p>
De toets is of je een correct antwoord goedkoop kunt herkennen. Is dat zo, dan kan een agent meer werk dragen terwijl een mens zicht houdt op het resultaat. Zo niet, dan kies je tussen uitgebreide review, een beperktere scope of een vertrouwensniveau dat de mogelijke gevolgen misschien niet toelaten.</p>
03</span>Wat gebeurt er als het fout gaat?</h2>
De tweede vraag bepaalt hoeveel bewijs nodig is voordat een agent met meer autonomie mag handelen. Het vertrekpunt is niet hoe capabel het model lijkt, maar wat er stukgaat als de output niet klopt.</p>
Dit is niet alleen een regelgevingsprincipe. Het vrijwillige AI Risk Management Framework</a> van NIST verbindt het beoogde gebruik, verwachte voordelen, foutkosten, menselijke controle en doorlopende meting aan de beslissing of een systeem überhaupt moet worden ingezet. De EU AI Act</a> past in omschreven gevallen een vergelijkbare risicogebaseerde logica toe als wet. Verplichtingen hangen af van het beoogde doel, de getroffen personen, de rol van elke partij in de waardeketen en de risicoclassificatie. Over het operationele bewijs daarachter schreven we apart in laat zien wat elke agent deed en wie het goedkeurde</a>.</p>
Roosterplanning laat zien waarom het detail telt. Een systeem kan onder de high-riskcategorieën voor werk vallen wanneer het beslissingen neemt die arbeidsrelaties beïnvloeden, of taken toewijst op basis van individueel gedrag of persoonlijke kenmerken. Dat maakt niet elke roostertool automatisch high-risk. De classificatie hangt af van het beoogde doel, de invloed op de beslissing en de voorwaarden uit artikel 6.</p>
De Scan legt het beoogde gebruik vast, de betrokken data, de beslissingen die de agent beïnvloedt, de geraakte personen en de rol van elke partij. Dat vormt de technische en operationele input voor een classificatie met de klant en diens adviseurs. Het is geen juridisch oordeel van ons.</p>
Onze eigen operationele controls kunnen strenger zijn dan het wettelijke minimum. Bij werk met grotere gevolgen kan dat een langere shadowperiode betekenen, alleen concepten laten maken en vaste goedkeuringen vóór go-live. Dat zijn operationele keuzes voor een specifiek proces, geen universele eisen.</p>
Dit sluit het proces niet uit. Het maakt vóór de bouwbeslissing wel de kosten en voorwaarden van beheerste inzet zichtbaar.</p>
Dat is wat de Scan</a> doet. We reconstrueren het vastgelegde proces, scoren acht gebieden en onderzoeken de gaten met de mensen die het werk bezitten. Het resultaat is niet automatisch een agentvoorstel. Het is een lijst met hiaten en een beslissing: bouwen, eerst voorbereiden, de scope verkleinen of het werk bij mensen laten.</p>

Gebied</th> Waar het antwoord begint</th></tr> </thead>

Volume</th> Aantallen in eventlogs</td></tr>
Geraakte systemen</th> Eventlogs en systeeminventaris</td></tr>
Datatoegang</th> Verbindings- en rechtentest</td></tr>
Datakwaliteit</th> Steekproef van records</td></tr>
Aansluiting op procedure</th> Conformance checking tegen het gedocumenteerde proces</td></tr>
Kosten van controle</th> Hersteldata, steekproeven en observatie</td></tr>
Reviewcapaciteit</th> Wachtrijdiepte, achterstand en eigenaarschap</td></tr>
Gevolgen van een fout</th> Oordeel van proceseigenaar, risk en legal</td></tr> </tbody> </table> </div>
Waar systemen redelijk complete eventlogs met stabiele case-ID's produceren, kan process mining reconstrueren hoe het werk stroomt. Het is een gevestigd vakgebied</a> voor het ontdekken, monitoren en verbeteren van operationele processen.</p>
Vier gebieden worden vooral in de systemen geobserveerd. Volume is een telling. Geraakte systemen vormen een inventaris. Datatoegang wordt getest met de goedgekeurde rechten. Datakwaliteit beoordelen we door de records te bekijken die de agent werkelijk zou ontvangen.</p>
Ook de aansluiting op de procedure is meetbaar als de logs volledig genoeg zijn. Conformance checking vergelijkt het gedocumenteerde proces met de volgorde in het log. Wordt een vastgelegde stap regelmatig overgeslagen, dan is dat zichtbaar voordat het een fout van de agent wordt.</p>
Het vastgelegde proces is bewijs, geen blauwdruk. De Scan begint bij de gewenste bedrijfsuitkomst en bepaalt daarna welke verantwoordelijkheden bij mensen, agents en bestaande systemen horen. We automatiseren het huidige proces niet simpelweg omdat dat in het log staat.</p>
De kosten van controle en de reviewcapaciteit beginnen bij bewijs en eindigen bij mensen. Heropende cases, gecorrigeerde invoer en herhaalde stappen laten zien waar al herstelwerk zit. Wachtrijdiepte, ouderdom van de achterstand en eigenaarschap laten zien of iemand de uitzonderingen van de agent kan beoordelen. De mensen die het werk doen, verklaren wat niet in het record staat.</p>
De gevolgen van een fout vragen vanaf het begin om een oordeel. Ze landen meestal buiten het systeem dat de case vastlegde: een klant die niet terugkwam, een vraag van de toezichthouder of een correctie per e-mail.</p>

Zeven van de acht beginnen bij vastgelegd bewijs.</b> De gevolgen van falen beginnen bij een verantwoordelijk oordeel. Gesprekken verklaren de gaten en gevolgen, in plaats van mensen te vragen een heel proces uit hun geheugen te reconstrueren.</figcaption> </figure>
De eerlijke beperking is werk dat geen bruikbaar spoor achterlaat. Een spreadsheet op een tweede scherm, een bericht aan een collega, kopiëren en plakken tussen systemen die nooit aan elkaar zijn gekoppeld. Een deel is vast te leggen via observatie of desktopevidence. De rest moet worden besproken. Juist daar zitten vaak de belangrijkste uitzonderingen.</p>
Dat verandert het gesprek. In plaats van iemand te vragen het hele proces te beschrijven, kan de Scan vragen waarom een bepaalde stap in vier van de tien vastgelegde cases ontbreekt. Bewijs brengt de discussie terug tot de uitzonderingen en beslissingen die werkelijk tellen.</p>
05</span>Hoe ziet een echte beoordeling eruit?</h2>
Neem een illustratief proces voor de intake van claims. Veel volume, regelgestuurd, digitale input. Het doorstaat de gebruikelijke geschiktheidstoets ruimschoots.</p>
De Scan vindt drie tegenstrijdige signalen. Volume en systeemtoegang scoren goed. De aansluiting op de procedure niet, omdat het vastgelegde proces regelmatig afwijkt van het beschreven proces. Ook de reviewcapaciteit scoort slecht, omdat geen eigenaar genoeg tijd heeft om de voorgestelde output te controleren.</p>

Claims intake</p> Readiness · 8 areas scored</span> </div>
Three of the eight, and the three that decide what happens next.</p>

Data access</span>
78</p>
</i>clean API</span> </i>three years of history</span> </div> </div>
Documentation</span>
40</p>
</i>SOP four years stale</span> </i>team works around it</span> </div> </div>
Review capacity</span>
25</p>
</i>one team lead</span> </i>200 cases a day</span> </div> </div> </div>
Illustratief</span> Rewrite the SOP before building</span> Find a second reviewer, or narrow the scope</span> </div> </div>
De scores zijn niet de uitkomst. De lijst met hiaten is dat wel.</b> Niets zegt hier dat het proces moet worden afgewezen. Het laat zien wat moet veranderen, zolang aanpassen nog goedkoop is.</figcaption> </figure>
Samen vertellen de signalen iets wat de standaardchecklist mist. Het werk is bereikbaar en ruim aanwezig. De gedocumenteerde procedure beschrijft het niet meer. En er is geen capaciteit om de output te beoordelen. Direct bouwen zou een proces reproduceren dat al is veranderd, om de resultaten vervolgens te geven aan iemand die geen tijd heeft om dat op te merken.</p>
De bruikbare uitkomst is de lijst met hiaten. Werk de procedure bij en creëer daarna reviewcapaciteit, of beperk de eerste agentrol tot het deel waar één persoon zicht op kan houden. Beide zijn vóór de bouw goed te organiseren en na go-live duur om alsnog te ontdekken.</p>
06</span>Welk werk kun je beter met rust laten?</h2>
Een deel. Dat benoemen hoort bij het werk. Tegelijk staat er een financiële prikkel tegenover. Volgens Michael Birshan, een van de managing partners van McKinsey, kwam in november 2025 ongeveer een kwart van de wereldwijde omzet uit outcome-based pricing in plaats van tijd. Dat zei hij tegen Business Insider</a>. Als de vergoeding volgt op de bouw, moet een beoordeling met als uitkomst “niet bouwen” op zichzelf waardevol genoeg zijn om voor te betalen. Anders verdwijnt die conclusie stilletjes. Een scan die alleen “ja” oplevert, is een offerte met extra stappen.</b> Hij moet ook bruikbaar zijn als het antwoord luidt: nog niet, niet met deze scope of niet bouwen.</p>
Dit zijn de duidelijkste stopsignalen.</p>
Een correct antwoord is alleen te herkennen door het werk opnieuw te doen.</b> Onderzoekssamenvattingen, oordelen zonder referentie om tegen te toetsen en elke taak die de reviewer moet herhalen om te weten of die klopt. De agent kan een goed resultaat leveren. Het proces kan dat niet economisch verifiëren.</p>
Niemand heeft ruimte om het te beoordelen.</b> Als de beoogde reviewer al vol zit, verklein dan de scope tot review wel past of los eerst de bezetting op. Een agent toevoegen aan een wachtrij waar niemand zicht op kan houden, verplaatst de bottleneck in plaats van hem op te lossen.</p>
De regels veranderen sneller dan ze kunnen worden onderhouden.</b> Uitzonderingen zijn normaal. Het wordt anders wanneer het onderliggende beleid elke paar weken verandert en niemand kan zeggen welke versie nu geldt.</p>
Het proces draait te weinig om betrouwbaar te meten.</b> Een proces dat enkele keren per maand voorkomt, levert mogelijk nooit genoeg cases op voor een stabiele nulmeting, om afwijkingen te signaleren of de eigen controle te rechtvaardigen. Een mens met een goede checklist is vaak goedkoper.</p>
Het pad is volledig deterministisch.</b> Als elke stap en vertakking vooraf te specificeren is, is gewone workflowautomatisering waarschijnlijk goedkoper en betrouwbaarder. Een agent verdient zijn plek waar werkelijk enige begrensde interpretatie of aanpassing nodig is.</p>

Wat dit je niet vertelt</p>
Een goede score betekent niet dat een agent zal slagen. Het betekent dat het werk het proberen waard is</b> en dat de operationele risico's bekend zijn. Bewijzen dat het in productie standhoudt is een apart vraagstuk. Daarover schreven we in wat er werkelijk nodig is om een agent in productie te runnen</a>.</p> </div>
07</span>Welk werk past goed bij een AI-agent?</h2>
Werk past wanneer een correct antwoord betaalbaar te herkennen is, de gevolgen van een fout begrensd of omkeerbaar zijn, er genoeg volume is om prestaties te meten en iemand de ruimte en bevoegdheid heeft om uitzonderingen af te handelen. Het werk moet ook genoeg variatie of oordeelsvorming bevatten om een agent te rechtvaardigen in plaats van gewone automatisering.</p>
Facturen koppelen aan orders en ontvangstbewijzen. Gestructureerde velden uit documenten overnemen in een registratiesysteem. Eerstelijnstriage waarbij de routeringsbeslissing in één oogopslag is te controleren. Het werk is begrensd, maar niet altijd identiek.</p>
Terug naar de claimsintake. Tweehonderd cases per dag en één teamlead. De meeste cases zijn eenduidig en in enkele seconden te bevestigen. Het overdragen van dat begrensde deel verandert de rekensom. De teamlead houdt meer tijd over voor de kleinere groep die werkelijk onzeker is.</p>
Het werk verdwijnt niet. Voor uitzonderingen was altijd al een mens nodig. Tegelijk kregen juist die het minste aandacht, omdat dezelfde persoon ook al het routinevolume droeg.</p>
De winst is dus niet automatisch een besparing. Het is capaciteit die vrijkomt uit routinewerk. Die wordt waarde wanneer een benoemde eigenaar haar inzet voor meer output, betere service, beter oordeel of een concrete kostenverbetering. Die omzetting hoort in de businesscase en moet na go-live worden gemeten.</p>
Onthoud de twee vragen. Neem het proces dat jullie al overwogen. Vraag hoe lang iemand nodig heeft om te weten dat één resultaat klopt. Vraag daarna wat er gebeurt als een fout resultaat doorglipt. Is een van beide antwoorden onbekend, dan is dat de eerste bevinding.</p>
Het vastgelegde proces lezen vraagt goedgekeurde toegang tot de systemen waarop het werk draait. Daarvoor is de Scan bedoeld en daar beginnen we</a>. Voor de twee vragen is geen tooling nodig. Stel ze voordat je met een leverancier praat en de businesscase staat direct steviger.</p>
Geschiktheid is geen eigenschap van het werk alleen. Het is de combinatie van het werk, de kosten van verificatie en de gevolgen van een fout. Een geschikte agent neemt meetbaar volume over binnen grenzen waar een mens grip op houdt.</p>
Veelgestelde vragen</h2>

Welke processen zijn geschikt voor een AI-agent?+</span></summary>
Zoek werk waarbij een correct resultaat betaalbaar te controleren is, de gevolgen van een fout begrensd zijn, er genoeg volume is om prestaties te meten en iemand de uitzonderingen kan afhandelen. Het werk moet ook genoeg variatie bevatten om een agent te rechtvaardigen in plaats van gewone workflowautomatisering.</div> </details>

Past herhaalbaar werk met veel volume altijd goed?+</span></summary>
Nee. Die kenmerken beschrijven werk dat een agent mogelijk kan doen, maar niet of het de moeite waard is om over te dragen. Als de controle van elk resultaat evenveel inspanning vraagt als het werk zelf, blijft de businesscase zwak, hoe capabel de agent ook lijkt.</div> </details>

Waarom tellen de kosten van controle van agentwerk mee?+</span></summary>
Controle is onderdeel van de operationele kosten. Als het verifiëren van een resultaat evenveel inspanning vraagt als het maken ervan, is het werk naar review verplaatst in plaats van verdwenen. Neem verificatie op als terugkerende kosten in de businesscase</a> totdat productiebewijs minder controle rechtvaardigt.</div> </details>

Welk werk kun je beter niet aan een AI-agent geven?+</span></summary>
Vermijd werk waarbij controle even lang duurt als uitvoering, een fout een klant of toezichthouder kan bereiken voordat iemand ingrijpt, of niemand de uitzonderingen kan afhandelen. Is het pad volledig voorspelbaar, dan is gewone automatisering meestal eenvoudiger en goedkoper.</div> </details>

Hoe beoordeel je of een proces klaar is voor een AI-agent?+</span></summary>
Begin bij het werk zoals het werkelijk gebeurt. Eventlogs, caserecords en steekproeven laten zien waar tijd heen gaat, hoe vaak uitzonderingen voorkomen en wat mensen later corrigeren. Onderzoek de gaten daarna met de mensen die eigenaar zijn van het proces. Alleen een workshop legt vooral de procedure vast die mensen dénken te volgen. Gaat het werk door, dan moet apart bewijs laten zien dat het in productie standhoudt</a>.</div> </details> </div>

Bronnen</h4>

Workday, Beyond Productivity: Measuring the Real Value of AI</a> (January 2026), a survey of 3,200 active AI users across North America, APAC and EMEA, fielded November 2025</li>
Michelle Vaccaro, Abdullah Almaatouq and Thomas Malone, When combinations of humans and AI are useful: a systematic review and meta-analysis</a>, Nature Human Behaviour</i> 8 (2024), covering 106 experiments and 370 effect sizes</li>
National Institute of Standards and Technology, AI Risk Management Framework (AI RMF 1.0)</a> (2023), on intended context, error costs, human oversight and deployment decisions</li>
European Union, Regulation (EU) 2024/1689, the Artificial Intelligence Act</a>, including Article 6 and Annex III on high-risk classification</li>
IEEE Task Force on Process Mining, Process Mining Manifesto</a> (2011), on process discovery, monitoring and conformance checking</li>
Michael Birshan of McKinsey on outcome-based fees, reported by Business Insider and syndicated here</a> (November 2025)</li>
The eight readiness areas, the Scan method and the claims-intake example are Aitonomy’s own. The example and its scores are illustrative.</li> </ul> </div> </div> </article>

Een AI-agent bouwen is het eenvoudige deel

Mik Nijhuis — Thu, 23 Jul 2026 00:00:00 +0000

In bijna elk agentproject valt de ruimte op een gegeven moment op een goede manier stil. De agent leest het document, roept het systeem aan, schrijft het record en iedereen ziet dat het werkt.</p>
Dat moment is waardevol. Tegelijk is het de minst representatieve run die de agent ooit zal uitvoeren. Een demo is één zorgvuldig gekozen case, terwijl iemand meekijkt. Productie is elke case die binnenkomt, ook de lastige, lang nadat de ruimte leeg is.</p>
Een agent bouwen is eenvoudiger geworden doordat de tooling is verbeterd. De moeilijkheid is verschoven, niet verdwenen.</p>
Gartner verwacht dat meer dan 40 procent van de agentic-AI-projecten eind 2027 is stopgezet</a>. De belangrijkste redenen zijn oplopende kosten, onduidelijke bedrijfswaarde en gebrekkige risicocontroles. Capaciteit en de aansluiting op de use case blijven relevant. Maar capaciteit alleen brengt een werkende agent niet naar productie.</p>
Het DORA-onderzoek uit 2025 kwam voor softwaredelivery tot een vergelijkbare conclusie: AI versterkt het systeem eromheen</a>. Sterke workflows, platforms en feedbackloops vergroten het effect. Zwakke worden zichtbaarder.</p>
Een pilot beantwoordt één vraag: kan de agent dit één keer? Productie stelt vier andere. Houdt het werk volgende maand nog stand? Wat kost het bij de echte casemix? Wie is verantwoordelijk als het fout gaat? Kun je reconstrueren wat de agent deed en waarom?</p>
In ons artikel over wat een agent werkelijk is</a> maakten we hetzelfde punt over zijn anatomie: het model is één onderdeel; de lagen eromheen maken het werk bruikbaar. Dit artikel gaat over de volgende laag. Niet waaruit een agent bestaat, maar wat nodig is om AI-agents in productie te runnen.</p>
Het werk wordt ongemerkt teruggedraaid</h3>
De meeste systemen kunnen acceptatie op de dag zelf meten: kwam de output door de controle, keurde iemand hem goed en is het record geschreven? Of dat werk een maand later nog overeind staat, weet je pas later. Het venster waarin iets kan misgaan is langer dan het meetvenster.</b></p>
Een creditnota wordt aangemaakt en twee weken later teruggedraaid. Een leveranciersrecord wordt bijgewerkt en daarna gecorrigeerd door de eigenaar. Op het dashboard lijken beide runs op de dag zelf geslaagd. In werkelijkheid veroorzaakten ze allebei herstelwerk.</p>
Als de correctie de operationele loop niet bereikt, leert de agent er niets van. Erger nog: het team kan instructies en evals blijven aanpassen op basis van wat op de dag zelf werd geaccepteerd, in plaats van wat later standhield. Het systeem rond de agent optimaliseert dan voor het verkeerde signaal.</p>
Softwaredelivery geeft een goed gemeten voorbeeld van dat risico, omdat wijzigingen en terugdraaiingen worden gelogd. Bill Harding, CEO van codeanalysebedrijf GitClear, beschreef de prikkel helder.</p>
AI schrijft bij voorkeur code die niet als defect wordt aangemerkt. Bill Harding, GitClear</b> · LeadDev</a>, July 2026</cite> </blockquote>
Uit het onderzoek van GitClear uit 2026 naar 623 miljoen codewijzigingen</a> bleek dat werk dat binnen twee weken werd herzien met 15 procent toenam. Constructies die fouten maskeren namen tussen 2023 en 2026 met 47 procent toe. Dat is bewijs over software, geen bewijs dat elke zakelijke agent zich hetzelfde gedraagt. Het laat wel zien waarom directe acceptatie geen vervanging is voor blijvende kwaliteit.</p>

</th> De demo</th> Productie</th></tr> </thead>

De case</th> Gekozen en afgebakend</td> Alles wat binnenkomt</td></tr>
Toezicht</th> Er kijken mensen mee</td> Monitoring moet zijn ontworpen</td></tr>
Succes is</th> De output zag er goed uit</td> De uitkomst houdt later nog stand</td></tr>
Meting</th> Direct</td> Over het hele faalvenster</td></tr>
Kosten per case</th> Een eerste observatie</td> Een spreiding bepaald door echte cases</td></tr>
Stopt wanneer</th> De vergadering eindigt</td> Een benoemde eigenaar beslist</td></tr> </tbody> </table> </div>
Context verandert de kostencurve</h3>
In een loop die bij elke stap een groeiende historie opnieuw meestuurt, kunnen de inputkosten sneller stijgen dan het aantal stappen. Instructies, voorbeelden, opgehaalde documenten en toolbeschrijvingen strijden allemaal om dezelfde context. Uitzonderingen voegen vaak meer materiaal toe. Die toevoegingen stapelen zich op als niemand ze verwijdert of herstructureert.</p>
Louis-François Bouchard mat dit bij een tutoring agent in productie. Zijn diagnose is het onthouden waard.</p>
Het model werd niet dommer. Zijn context wel. Louis-François Bouchard</b> · Context engineering in 2026</a>, August 2026</cite> </blockquote>
Zijn resultaten laten ook zien dat dit geen onvermijdelijke ontwikkeling in één richting is. In zijn workload verlaagde een limiet op tooloutput de kosten per beurt met 38 procent, zonder meetbaar geheugenverlies. Prompt caching, retrieval, outputlimieten, bewust snoeien en modelrouting kunnen de curve allemaal veranderen.</p>
De pilotkosten zijn dus niet per definitie het laagste bedrag dat de agent ooit zal halen. Het is simpelweg geen productieprognose. De productie-economie moet per case worden gemeten, tegen de werkelijke spreiding van het werk.</p>
Bij weinig volume is het gemiddelde minder stabiel</h3>
De kosten per case zijn vaak rechts-scheef verdeeld. De meeste cases zijn gewoon; een klein aantal duurt lang. Bij weinig volume kunnen die uitschieters het maandelijkse gemiddelde sterk beïnvloeden. Bij veel volume is het gemiddelde doorgaans stabieler, ook als de totale rekening hoger is.</p>
Dat verschil telt. Een financeproces met duizenden vergelijkbare cases kan in totaal duur zijn, maar per case voorspelbaar. Een analistenproces met vijf diepgaande onderzoeken kan goedkoper zijn en toch elke maand verrassen.</p>
In ons eigen werk vonden we dit patroon in kostenmodellen, niet in een universele productiebenchmark. Het veranderde welke processen we economisch onzeker noemen en welk bewijs we vragen voordat we ze goedkeuren.</p>
03</span>Wat spreken we af vóór de bouw?</h2>
Een proces heeft een businesscase nodig voordat de agents een architectuur nodig hebben. Zonder businesscase ontbreekt een stabiele uitkomst, nulmeting en beslisregel waaraan je het systeem kunt houden.</p>
Het onderscheid tussen proces en agent is belangrijk. Een organisatie draagt een procesuitkomst over. Eén agent kan die dragen, of meerdere kleinere agents kunnen eronder samenwerken. Dat is een architectuurkeuze die tijdens de bouw kan veranderen. De businesscase en commerciële eenheid blijven het proces. Het splitsen of combineren van agents verandert dus niet stilletjes wat de klant heeft gekocht.</p>
Voor elk proces dat we in productie brengen, past de businesscase op één pagina. Die legt zes zaken vast: het werk, kwaliteit en risico, de nulmeting, investering en waarde, het prestatiedoel en de benoemde eigenaar.</p>
Twee details bepalen of de rest bruikbaar is.</p>
De nulmeting krijgt een label.</b> Waar de historie van de organisatie voldoende basis biedt, wordt de nulmeting berekend en als gemeten gemarkeerd. Anders wordt ze gemodelleerd op basis van een vergelijkbaar proces, een externe benchmark of een expliciete aanname, met het label gemodelleerd. Een gemodelleerde nulmeting kun je ter discussie stellen en vervangen. Een verborgen aanname niet.</p>
Capaciteit wordt niet als waarde gepresenteerd.</b> De businesscase maakt onderscheid tussen tijd die als capaciteit vrijkomt en gerealiseerde waarde. Vrijgekomen tijd wordt pas waarde wanneer een benoemde eigenaar die omzet in meer output, betere dienstverlening, lagere externe uitgaven of een concrete personeelsbeslissing. Tot dat moment is het beschikbare capaciteit, geen besparing.</p>
De businesscase moet negatief mogen uitvallen. Anders is het een rechtvaardigingsdocument in plaats van een beslisinstrument.</p>
We gebruiken een methode met vier fasen</a>. De opbouw telt meer dan de namen.</p>
Scan</b> stelt de gewenste uitkomst en de huidige nulmeting vast, en bepaalt of het werk geschikt is. Onboard</b> definieert de agentrollen, systeemtoegang, grenzen en verantwoordelijke eigenaar. Earn trust</b> test de agents op echte cases voordat ze zelfstandig handelen. Grow</b> meet het proces zolang het draait aan de businesscase.</p>

Elke fase levert bewijs dat de volgende nodig heeft.</b> Grow keert terug naar Scan wanneer het proces, de systemen of het beoogde gebruik verandert. Latere prestaties worden gemeten aan de nulmeting uit Scan.</figcaption> </figure>
De pijl terug is belangrijk. Bronsystemen krijgen updates. Regels veranderen. Modellen worden vervangen. Een configuratie die een jaar niet is beoordeeld, is niet bewezen stabiel alleen omdat ze nog draait.</p>
In de dagelijkse operatie staan vier signalen naast elkaar: benutting, blijvende kwaliteit, effect op de procescapaciteit en kosten per case. Ze voeden de drie maatstaven uit de businesscase waarmee de rol wordt beoordeeld: kwaliteit, capaciteit en waarde.</p>
De kwaliteitsmeting moet langer duren dan het faalvenster. First-time-right op de dag zelf is een vroeg signaal. First-time-right na de afgesproken periode is het blijvende resultaat. Het verschil bestaat uit werk dat iemand opnieuw opende, corrigeerde of terugdraaide.</p>
Dat cijfer is de meting, niet de oplossing. De oplossing is elke correctie opvangen en terugbrengen in de operationele loop: wat deed de agent, wat veranderde een mens en waarom? Een terugkerende correctie wordt een kandidaat-regel. Die komt pas in de vaste context van de agent nadat hij de tests en evals van die agent doorstaat.</p>
De loop is het antwoord, niet het dashboard.</b> Sluit je de loop, dan baseer je toekomstige wijzigingen op de uitkomst die werkelijk standhield. Laat je hem open, dan kan de kwaliteitsscore verbeteren terwijl de organisatie het werk blijft terugdraaien.</p>
Binnen Aitonomy runnen we code review, QA, security checks, documentatie, infrastructuurcontroles en interne rapportage als agents op verschillende autonomieniveaus. Daar werden verschillende faalpatronen uit dit artikel voor ons voor het eerst zichtbaar.</p>
05</span>Wat hebben we veranderd?</h2>
We veranderden twee onderdelen van onze eigen methode.</p>
We gebruiken het aantal agents niet langer als eenheid.</b> We hadden al geconcludeerd dat de inspanning afhangt van de complexiteit van het proces, niet van het aantal agents. Die conclusie hadden we nog niet doorgevoerd in de manier waarop we het werk beschreven en prijsden. Een lezer van ons eigen document wees ons op de inconsistentie.</p>
Het proces is nu de bedrijfsmatige en commerciële eenheid. De agents daaronder blijven architectuurrollen. Hun aantal kan veranderen zonder dat de beloofde uitkomst of de prijs stilletjes verandert.</p>
We veranderden onze omgang met kostenrisico bij weinig volume.</b> Eerst namen we aan dat processen met veel volume het moeilijkst te voorspellen waren, omdat daar de totale uitgaven het hoogst zijn. Onze modellering liet zien dat de gemiddelde maandelijkse kosten per case bij weinig volume minder stabiel zijn. Een paar lange cases kunnen het resultaat dan sterk verschuiven.</p>
We ontdekten dat tijdens de modellering, voordat het een live businesscase raakte. Het waardevolle was niet dat we de fout voorkwamen, maar dat een meetwaarde ons dwong de methode te veranderen.</p>
06</span>Hoe houden we grip op een agent?</h2>
Dit is het werk dat Aitonomy voortzet nadat een agent live gaat. Aitonomy Control legt het bewijs uit de operatie vast. Ons operationele team runt de control loop en gebruikt dat bewijs om afwijkingen te onderzoeken en de inzet van de agent aan te passen. De proceseigenaar bij de klant blijft verantwoordelijk voor de uitkomst en bekrachtigt elke maand het besluit om de scope te verruimen, gelijk te houden, te verkleinen of de agent te stoppen.</p>
Grip begint vóór de bouw. We spreken af wat wordt gemeten, stellen de nulmeting vast, definiëren de grenzen van de agent en bepalen welk bewijs nodig is voordat hij met meer autonomie mag handelen.</p>
De faalpatronen in dit artikel delen die eis. Directe acceptatie vervangt geen blijvende kwaliteit. Pilotkosten vervangen geen productiekosten per case. Een theoretische capaciteitsschatting vervangt geen gerealiseerde waarde. En een autonomieniveau mag niet alleen omhoog kunnen.</p>

Wanneer dit niet van toepassing is</p>
Als werk maar een paar keer per maand voorkomt, of de regels bij elke uitvoering veranderen, kan een groot deel van dit besturingssysteem onnodige overhead zijn.</b> Het is bedoeld voor processen die vaak genoeg terugkeren om te meten. Onder die grens kan een mens met een goede checklist goedkoper en beter zijn. Een Scan die tot die conclusie komt, heeft zijn werk gedaan.</p> </div>
Aitonomy Control houdt dat bewijs vervolgens bij elkaar: wat elke agent deed, wat een mens goedkeurde, of het werk standhield en hoe kwaliteit, capaciteit, waarde en kosten zich verhouden tot de afgesproken nulmeting.</p>

Kwaliteit, capaciteit en waarde</p> Kai · finance operations</span> </div>
Eén agent, gemeten aan de nulmeting die vóór de bouw is afgesproken. De cijfers zijn illustratief.</p>

Na 30 dagen nog correct</span>
91%</small></p>
</i>96% op de dag geaccepteerd</span> </i>1 onder de norm</span> </i>82% vóór de agent</span> </div>
Deze maand vrijgekomen</span>
≈374 h</small></p>
</i>houdt stand</span> </i>zelfstandig ≈291u</span> </i>nulmeting 240u</span> </div>
Waarde-equivalent rendement</span>
≈7.5×</small></p>
</i>houdt stand</span> </i>ca. €39,3k</span> </i>1× is break-even</span> </div>
Illustratief</span> Nulmeting akkoord 12 jun</span> Laatste 12 weken</span> Besluit: verruimen</span> Volgende review 1 sep</span> </div> </div>
Directe acceptatie naast blijvende kwaliteit</b>, gemeten na het afgesproken faalvenster. Het verschil is werk dat later opnieuw werd geopend, gecorrigeerd of teruggedraaid.</figcaption>
Illustratief, geen klantresultaat.</b> Dit laat de vorm van een maandelijkse review zien: één finance-operationsagent over twaalf weken, afgezet tegen een maandelijkse nulmeting van 240 uur vóór de bouw. Vrijgekomen uren zijn capaciteit die teruggaat naar het team. Het is geen directe kostenbesparing. De waarde hangt af van wat het team met die capaciteit doet. Het rendement waardeert de uren tegen het eigen tarief van de organisatie en vergelijkt dat met de runkosten van de agent. Vervang alle cijfers door jullie eigen nulmeting, tarief en kosten voordat je dit model in een businesscase gebruikt.</p> </figure>
Dat bewijs moet beslissingen veranderen. We kunnen de context aanpassen, overstappen op een lichter model als dat dezelfde norm haalt, de autonomie verkleinen of verruimen, of de rol stoppen. Veranderen het beoogde doel, de scope of het gebruik van een agent, dan moeten ook de relevante classificatie, documentatie, menselijke controls en verantwoordelijkheden opnieuw worden beoordeeld. De formele juridische beoordeling blijft losstaan van het technische bewijs dat Aitonomy Control levert. Dit is ook het operationele uitgangspunt achter laten zien wat elke agent deed en wie het goedkeurde</a>.</p>
Agents kunnen veel monitoringwerk voorbereiden: scoreboards lezen, afwijkingen markeren en relevante runs verzamelen. Ons operationele team beoordeelt dat materiaal en brengt het bewijs naar de proceseigenaar. Het besluit zelf blijft mensenwerk.</p>
Er is een eenvoudige toets voor echte governance. Vraag wanneer een agent voor het laatst een autonomieniveau omlaag ging. Vraag wanneer een maandbesluit voor het laatst een agent stopzette. Vraag wat er vorige maand veranderde door het scoreboard.</p>
Als het antwoord op alle drie “nooit” is, rapporteert het systeem alleen. Het stuurt niet. Een control die nooit een beslissing verandert, is slechts een dashboard.</b></p>
Een agent het werk één keer laten doen wordt steeds eenvoudiger. Goed runnen begint daarna: een nulmeting vóór de bouw, een benoemde eigenaar, bewijs dat autonomie kan verlagen én verhogen en een maandelijks besluit dat de agent ook mag stoppen.</p>
Veelgestelde vragen</h2>

Waarom slagen pilots met AI-agents en lopen ze daarna vast?+</span></summary>
Een pilot laat zien dat een agent het werk kan afronden. Productie stelt moeilijkere vragen: houdt de kwaliteit stand, wat kost elke case en levert het proces werkelijk capaciteit op? Teams lopen vast wanneer ze de taak één keer hebben bewezen, maar geen businesscase</a> hebben gedefinieerd of geen besturingssysteem rond de agent hebben gebouwd.</div> </details>

Wat bepaalt de kosten van een AI-agent?+</span></summary>
De kosten hangen af van de werkelijke casemix, het aantal stappen, de hoeveelheid context, de gebruikte modellen en tools en het controle- en uitzonderingswerk dat bij mensen blijft. Meet in productie de spreiding van de kosten per case. Een pilotrun is geen betrouwbare voorspelling.</div> </details>

Wat meet je zodra een AI-agent live is?+</span></summary>
Meet benutting, blijvende kwaliteit, het effect op de procescapaciteit en de kosten per case. Samen laten die signalen zien of de agent kwaliteit, capaciteit en waarde creëert. Veel activiteit is niet genoeg. Een agent kan druk zijn zonder het omliggende proces te verbeteren.</div> </details>

Waarom kan first-time-right misleidend zijn?+</span></summary>
Werk kan op de dag zelf correct lijken en later toch opnieuw worden geopend, gecorrigeerd of teruggedraaid. Meet first-time-right opnieuw na een afgesproken periode. Het verschil tussen beide cijfers laat zien of het resultaat in het echte proces standhield.</div> </details>

Wie is verantwoordelijk voor een AI-agent in productie?+</span></summary>
Een benoemde persoon bij de klant. Die blijft verantwoordelijk voor de uitkomst en bepaalt op basis van het bewijs uit de operatie of de scope wordt verruimd, gelijk blijft, wordt verkleind of de agent stopt. Het supervision policy</a> definieert welk bewijs voor die beslissingen nodig is. Een afdeling of stuurgroep vervangt geen eigenaar.</div> </details> </div>

Bronnen</h4>

Gartner, Over 40% of agentic AI projects will be cancelled by the end of 2027</a></li>
DORA, State of AI-assisted software development 2025</a></li>
GitClear, The Maintainability Gap</a>, and Bill Harding interviewed in LeadDev</a></li>
Louis-François Bouchard, Context engineering in 2026</a></li>
European Union, Regulation (EU) 2024/1689, the Artificial Intelligence Act</a></li>
Uitspraken over Aitonomy’s eigen kostenmonitoring en modellering zijn in het artikel als zodanig benoemd. Ze worden niet gepresenteerd als externe benchmarks.</li> </ul> </div> </div> </article>

De spelregels voor agents komen eraan. Ze vragen om één ding: laat je werk zien

Mik Nijhuis — Wed, 08 Jul 2026 00:00:00 +0000

De Europese AI Act, de ISO-managementnorm waar inkopers nu naar vragen en de soevereiniteitsvraag wie jullie stack beheert, komen tegelijk op organisaties af. Ze lijken los van elkaar te staan. Dat doen ze niet. Uiteindelijk vragen ze allemaal om hetzelfde: een vastlegging van wat jullie AI deed en op welke basis. Bij agents, die zelfstandig meerdere stappen uitvoeren, is juist die vastlegging het moeilijke deel.</p>
De meeste teams krijgen een agent wel aan het werk. Achteraf bewijzen wat hij deed, op welke basis en wie het goedkeurde, is waar het misgaat. Precies dat bewijs beginnen de regels nu te eisen.</p>
De grote boodschap in 2026 is dat de EU pas op de plaats maakte. Op 19 november 2025 publiceerde de Commissie haar Digital Omnibus. Na de triloogonderhandelingen kwamen de instellingen in mei 2026 overeen om de high-riskverplichtingen uit de AI Act uit te stellen. Zelfstandige hoog-risicosystemen uit Bijlage III verschuiven van 2 augustus 2026 naar 2 december 2027. Voor AI in gereguleerde producten wordt dat 2 augustus 2028. Advocatenkantoren die de ontwikkelingen volgen, zoals Gibson Dunn</a>, zien het uitstel als reactie op onvoltooide geharmoniseerde normen en nationale autoriteiten die nog niet klaar waren.</p>
Dat kun je gemakkelijk lezen als: “compliance kan wachten”. Dat kan niet. Het AI-rechtsteam van Jones Walker</a> benadrukt dat 2 augustus nog steeds telt, omdat de meeste transparantieverplichtingen uit artikel 50 ongewijzigd bleven. Artikel 50 geldt vanaf 2 augustus 2026 en verdeelt de plichten naar rol, in plaats van iedereen dezelfde op te leggen. Aanbieders moeten systemen die rechtstreeks met mensen interacteren zo ontwerpen dat duidelijk is dat het om AI gaat, tenzij dat al vanzelf spreekt. Ook dragen zij de verantwoordelijkheid voor machineleesbare markering van synthetische content. Gebruiksverantwoordelijken hebben beperktere, eigen plichten rond emotieherkenning en biometrische categorisering, deepfakes en AI-gegenereerde tekst die het publiek informeert over zaken van algemeen belang. Voor die laatste categorie geldt een uitzondering wanneer een mens de tekst heeft beoordeeld en iemand redactioneel verantwoordelijk is. Niet elk door AI gemaakt beeld, fragment of tekstdeel legt dus dezelfde verplichting op aan de organisatie die het gebruikt. De regels voor general-purpose modellen gelden al sinds augustus 2025. De eerste last is daarom niet het zware high-riskpapierwerk. Het begint met weten welke plichten bij jullie rol horen</a> en kunnen aantonen wat de machine produceerde en op welke basis.</p>
Onafhankelijk analist Luiza Jarovsky</a> volgde in haar nieuwsbrief elke wijziging tot en met de goedkeuring door de Raad. Haar punt verdient herhaling: het uitstel is geen pauzeknop.</p>
De tweede set spelregels is helemaal geen wet. ISO/IEC 42001</a>, gepubliceerd in december 2023, is de eerste managementsysteemnorm voor AI. Zie het als de tegenhanger van ISO 27001, maar dan voor de manier waarop een organisatie haar AI beheerst. De norm wordt een selectiecriterium in inkoop. Anthropic behoorde tot de eerste frontier labs met certificering</a>, geldig vanaf januari 2025. AWS en Microsoft volgden. Inkopers bij Fortune 500-bedrijven vragen leveranciers inmiddels om het certificaat of om een geloofwaardige route ernaartoe. De norm toetst iets weinig spectaculairs maar veelzeggend: hebben jullie beleid, risicobeoordelingen en monitoring, en kunnen jullie dat aantonen? Opnieuw draait het om vastlegging.</p>
De Amerikaanse wetgeving kijkt niet zozeer naar waar data staat. Bepalend is of een Amerikaanse partij de data beheert en controleert. Frank Karlitschek, Nextcloud</b> · Holistic Sovereignty podcast</cite> </blockquote>
In november 2025 ondertekenden alle 27 EU-lidstaten een verklaring om de digitale soevereiniteit te versterken en strategische afhankelijkheden te verkleinen. Voor organisaties die agents laten werken met hun eigen code en data, en die van klanten, is de vraag welk rechtsgebied afgifte kan afdwingen nu een volwaardige ontwerpkeuze. Geen voetnoot.</p>
Dit is de zakelijke kern. Agents vermenigvuldigen het aantal geautomatiseerde beslissingen in jullie organisatie. Elke set regels hierboven maakt het duurder als je daar geen verantwoording over kunt afleggen. Gartner verwacht dat meer dan 40 procent van de agentic-AI-projecten vóór 2027 wordt stopgezet</a>, onder meer door onduidelijke waarde en gebrekkige controls. Teams die hun werk kunnen laten zien, komen door audits, winnen gereguleerde klanten en blijven leveren. Teams die dat niet kunnen, lopen vast.</p>
Wat alle drie de sets regels vragen, is niet zozeer juridisch als wel bestuurlijk. Ethan Mollick schrijft in One Useful Thing: “als je kunt uitleggen wat je nodig hebt, effectieve feedback kunt geven en manieren kunt ontwerpen om werk te beoordelen, kun je met agents werken.”</a> Grip houden op een agent is hem managen: specificeer het werk, beoordeel het en leg beide vast. De regels maken die vastlegging verplicht.</p>
Dat is de laag die wij bouwen. Aitonomy werkt rond de coding agent die jullie gebruiken en maakt diens activiteit beheersbaar en aantoonbaar.</p>

Wat het platform biedt</h3>
Eén uitgangspunt · een leesbare vastlegging</p>

Controlepoorten.</b>Een wijziging van een agent geldt pas als afgerond wanneer die de controles voor die stap doorstaat. Dezelfde poort geldt voor een pull request van een mens of een agent.</span></li>
Goedkeuring.</b>Waar beleid menselijke goedkeuring vereist, wordt die vastgelegd. Zo heeft autonomie een benoemde eigenaar en geen anonieme geautomatiseerde commit.</span></li>
Audittrail.</b>Elke stap, specificatie, controle en beslissing wordt vastgelegd en is maanden later nog terug te lezen. Dat is de vastlegging waar de transparantieplichten uit de AI Act, een ISO 42001-audit en een soevereiniteitsbeoordeling uiteindelijk allemaal om vragen.</span></li> </ol> </div>
Geen van deze onderdelen maakt een agent op zichzelf compliant. Ze zorgen wel dat het bewijs bestaat. Teams ontdekken meestal pas dat juist dat ontbreekt wanneer iemand erom vraagt.</p>
De eerlijke kanttekening: het omnibusuitstel geeft lucht, maar trekt de regels niet in. Wie het als afstel behandelt, komt in 2027 alsnog in tijdnood. Ook een certificaat staat niet gelijk aan veiligheid. ISO 42001 toetst of er een systeem is, niet of dat systeem goed werkt. Governance verwordt tot toneel wanneer de vastlegging alleen wordt geproduceerd om een auditor tevreden te stellen en niet om het werk daadwerkelijk te sturen.</p>
Het doel is niet meer papierwerk. Het doel is dat je snel en naar waarheid kunt antwoorden wat jullie agents deden en waarom.</p>
Welke van deze drie komt als eerste op jullie bureau terecht? En kunnen jullie de vraag beantwoorden?</p>
Veelgestelde vragen</h2>

Is de EU AI Act uitgesteld?+</span></summary>
Voor een deel. De verplichtingen voor hoog-risicosystemen zijn in 2026 uitgesteld, maar andere plichten volgen nog steeds de oorspronkelijke planning. Dat geldt onder meer voor de meeste transparantieverplichtingen uit artikel 50. Het uitstel geeft meer voorbereidingstijd, maar neemt de noodzaak niet weg om vast te leggen wat een AI-systeem produceerde en op welke basis.</div> </details>

Wat is ISO 42001 en waarom is het relevant?+</span></summary>
ISO/IEC 42001 is een managementsysteemnorm voor AI. De norm vraagt of een organisatie beleid, risicobeoordelingen, monitoring en bewijs heeft voor de manier waarop zij AI beheerst. Nu inkopers de norm meenemen in hun selectie, wordt het naast een compliancevraag ook een commerciële vraag.</div> </details>

Maakt hosting in de EU een AI-systeem soeverein?+</span></summary>
Niet vanzelf. De locatie van de server telt, maar ook wie de stack beheert en aanstuurt. De praktische vraag is onder welk rechtsgebied die organisatie kan worden gedwongen data af te staan. Een Europees datacenter beantwoordt die vraag niet op zichzelf.</div> </details>

Welk bewijs moet je bewaren over het werk van een AI-agent?+</span></summary>
Bewaar genoeg om te reconstrueren wat de agent deed, waarom, welke controles hij doorliep en wie het resultaat goedkeurde. Die vastlegging maakt de agent op zichzelf niet compliant of veilig. Ze levert wel het bewijs dat nodig is om de agent in productie te runnen</a> en geeft operators, inkopers en auditors iets concreets om te beoordelen.</div> </details> </div>

Bronnen</h4>

EU AI Act Digital Omnibus, deferral of high-risk obligations. Gibson Dunn, Omnibus Agreement: postponed high-risk deadlines</a>; Jones Walker, Yes, August 2 Still Matters</a></li>
Luiza Jarovsky, Changes to the AI Act Approved by the Council of the EU</a> (independent AI Act analyst)</li>
ISO/IEC 42001:2023, AI management systems</a>; Anthropic, ISO 42001 certification</a></li>
Ethan Mollick, Management as an AI superpower</a> (One Useful Thing)</li>
The Lawfare Podcast, Itsiq Benizri on the EU AI Act</a></li>
Gartner, Over 40% of agentic AI projects will be canceled by 2027</a></li> </ul> </div> </div> </article>

Wat een agent werkelijk is

Mik Nijhuis — Wed, 24 Jun 2026 00:00:00 +0000

Als mensen zeggen dat ze “AI gebruiken”, bedoelen ze meestal een chat: je typt, een model antwoordt, jij leest. Nuttig, maar het blijft één modelcall. Een agent is iets anders. Het verschil zit niet in het model, maar in alles eromheen. Precies dat is wat wij bouwen.</p>
Twee jaar lang kon de sector het niet eens worden over wat “agent” precies betekende. Die discussie is grotendeels beslecht. Na honderden definities te hebben verzameld, kwam Simon Willison tot een heldere omschrijving: “een LLM-agent gebruikt tools in een loop om een doel te bereiken.”</a> Anthropic gebruikt vrijwel dezelfde woorden, “LLM's die zelfstandig tools gebruiken in een loop”, en trekt in het veelgelezen Building Effective Agents</a> een scherpe grens: een workflow volgt vooraf gedefinieerde codepaden, terwijl bij een agent het model zelf zijn proces en toolgebruik aanstuurt en bepaalt hoe het de taak uitvoert.</p>
Een chat is vraag en antwoord. Een agent is doel, plan, handelen, observeren en herhalen. Het model bepaalt de volgende stap, niet jij.</p>
Een systeem is meer agentgestuurd naarmate een LLM meer bepaalt hoe het systeem zich kan gedragen. Harrison Chase, LangChain</b> · “Wat is een AI-agent?”</cite> </blockquote>
Chase ziet het als een schaal, niet als een keurmerk. Andrew Ng zegt vanuit de andere kant hetzelfde: systemen kunnen in verschillende mate agentgestuurd zijn. Een kale chat staat op nul. Geef het model tools, geheugen en een loop en het schuift op.</p>

Een chat is de stip in het midden. Een agent is het hele diagram.</b> “Introduction to Agents” van Google en Kaggle beschrijft de binnenkant: model, tools en orchestration. Lilian Weng van OpenAI voegt planning en geheugen toe. De buitenste ring is wat wij bouwen.</figcaption> </figure>
De whitepaper vat de binnenkant helder samen: een model</strong> (het brein), tools</strong> (de handen die de buitenwereld bereiken) en een orchestration layer</strong> (de loop van denken, handelen en observeren). Weng voegt twee onderdelen toe die inmiddels vanzelfsprekend zijn: planning</strong> (het doel opdelen in stappen, reflecteren en bijsturen) en geheugen</strong> (context vasthouden over meerdere stappen, niet alleen binnen één bericht). Het model is noodzakelijk, maar bij lange na niet voldoende.</p>

</th> Een chat</th> Een agent</th></tr> </thead>

Interactie</th> Jij vraagt, de chat antwoordt en jij zet de volgende stap</td> Je draagt een doel over; de agent plant, handelt en observeert in een loop</td></tr>
Controle</th> Jij bepaalt wanneer het verdergaat</td> De agent gaat door tot een stopvoorwaarde is bereikt</td></tr>
Bevoegdheid</th> Werkt in een eigen sessie en geeft je het resultaat</td> Heeft toegewezen toegang en handelt in jullie systemen</td></tr>
Geheugen</th> Een gemak binnen het gesprek</td> Wordt bewust meegenomen, omdat de volgende stap afhangt van de vorige</td></tr>
Verantwoordelijk voor</th> Het antwoord dat voor je staat</td> De uitkomst, met een benoemde eigenaar en vastlegging</td></tr> </tbody> </table> </div>
Het verschil tussen de twee kolommen zit niet in wat het systeem kan. Een goede chatassistent kan geheugen gebruiken, code uitvoeren, bestanden lezen en het web doorzoeken. Het verschil is delegatie: keur je elke stap zelf goed of draag je een doel over? Werkt het systeem in een eigen sessie of heeft het toegang tot die van jullie? En is iemand eigenaar van het resultaat zodra het stopt?</p>
02</span>De ladder die we zelf beklommen</h2>
Dit ontstond niet uit één beslissing. Net als de meeste teams beklommen we een ladder. Het helpt om de treden te benoemen, zodat je ziet waar jullie zelf staan.</p>

Van links naar rechts neemt de autonomie toe. Jij blijft betrokken; alleen je plek in het proces verandert.</b> Op trede vier typ je de wijziging niet meer zelf, maar keur je de pull request van de agent goed of af.</figcaption> </figure>
Trede één was kopiëren en plakken: het antwoord kwam uit de chat, de code ging de editor in en de mens verbond alles. Trede twee was inline aanvulling, waarbij de editor de regel afmaakt. Op trede drie staan de meeste teams nu: heen en weer met het model tot de wijziging klopt. Trede vier wordt interessant. Je geeft een agent een doel en laat hem uitvoeren, schrijven, toetsen aan de specificatie, het resultaat lezen, corrigeren en herhalen tot de eindvoorwaarde is bereikt. Dat is de loop. Calvin French-Owen, die aan OpenAI Codex werkte, benoemt de beperking die daarbij bepalend is: “de agent voorspelt telkens het volgende token en elk token moet binnen een context window passen. Wie coding agents goed wil gebruiken, moet context begrijpen.”</a></p>
We hebben deze ladder geformaliseerd omdat dit is wat we leveren. Intern lopen onze niveaus van Supervised naar Co-Author, Spec-First, Autonomous Routine en tot slot een beperkte Selective Autonomy. Teams doorlopen die ontwikkeling in kwartalen, niet in weken. Op elke trede blijf je betrokken. Alleen je positie verandert.</p>
03</span>Waarom de lagen juist het verschil maken</h2>
Dit bepaalt of je een agent veilig binnen een organisatie kunt inzetten. Een fout antwoord van een chat kost een minuut. Een agent die handelt, kan een pull request openen, data verplaatsen of productie raken. Zodra een model iets kan doen</em>, zijn er lagen nodig die bij een chat nooit nodig waren: grenzen aan wat het mag aanraken, bewijs dat het werkt en een vastlegging van wat het heeft gedaan.</p>
Die buitenste ring is wat wij bouwen. Niet het model en niet de coding agent. We bouwen de skill</strong> (de capaciteit die een agent krijgt), het beleid</strong> (wat hij wel en niet mag doen), de evals</strong> (bewijs dat hij het werk aankan) en de audittrail</strong> (achteraf bewijs van elke handeling). Op ons platform is een agent letterlijk de verbinding van die onderdelen: een ondertekend pakket van skill, beleid, evals, manifest en trigger. Een generieke runtime bevat die niet.</p>
Het product bestaat uit de grenzen en de controls. Rechten, goedkeuringen, begrensde API-integraties, audits, rapportages, logs en waarschuwingen. Jake Stauch, Serval</b> · Sequoia Training Data, May 2026</cite> </blockquote> Dat is geen eigenzinnige opvatting. James Everingham, voormalig Meta en nu bouwer van een AI control plane, zei bij Dev Interrupted hetzelfde: “je moet kunnen begrijpen wat deze agents in je infrastructuur doen, in plaats van ze overal toegang toe te geven en ze maar hun gang te laten gaan.”</a> Simon Willison is in zijn stuk over het ontwerpen van agent loops</a> duidelijk over de reden: “agents zijn van zichzelf riskant. Laat je agent in een beveiligde sandbox draaien en stel een strakke budgetlimiet in als credentials geld kunnen uitgeven.” Dat is precies wat wij doen. Elke werkeenheid draait in een eigen tijdelijke sandbox, vóór elke toolcall wordt het beleid getoetst en een call die het budget overschrijdt stopt.</p>

De loop is de agent. Dankzij de controlepoorten kun je hem laten doorwerken.</b> Een beleidstoets vóór een handeling, een evaltoets vóór iets onomkeerbaars, een auditstempel op elke stap en menselijke goedkeuring of afwijzing bij de pull request.</figcaption> </figure> Het eerste is onboarding: welke context je meegeeft. Harrison Chase noemt dit context engineering en beschrijft het probleem helder: “als een agent niet betrouwbaar presteert, komt dat meestal doordat de juiste context, instructies en tools niet aan het model zijn doorgegeven.”</a> Voor ons betekent een capaciteit onboarden dat we een skill schrijven in het open Agent Skills-formaat. Elke feature krijgt vóór het schrijven van code een verificatiespecificatie. Voor routine-agents neemt een evalsuite die rol over. De domeinexpert van een partner kan die via een wizard opstellen: skill, evals, beleid, connectors, autonomieniveau en publiceren. Vóór ondertekening controleert het systeem of het beleid en het autonomieniveau elkaar niet tegenspreken.</p>
Het tweede is actueel blijven. Anthropic beschrijft in zijn werk over context engineering</a> “context rot”: naarmate het context window voller raakt, haalt een model informatie minder goed terug. De oplossingen zijn compactie en gestructureerde notities, of agentgeheugen, buiten het window.</p>
De grootste beperking om deze modellen nuttiger te maken is tegenwoordig niet hun ruwe intelligentie, maar hun begrip van nieuwe en veranderende context. Jessy Lin, Engram</b> · Sequoia Training Data, June 2026</cite> </blockquote>
Onze agents bouwen over verschillende runs een geheugen op. Na elke run zet een consolidatiestap de uitkomst om in geheugen en kandidaat-skills. Een kandidaat wordt pas een echte skill nadat die de evalnorm haalt. Leren betekent hier informatie opbouwen en terughalen, nooit het model opnieuw trainen. Verandert een skill of evalsuite, dan wordt de agent vóór ingebruikname opnieuw gecertificeerd voor zijn niveau.</p>
05</span>Context is meer dan de organisatie</h2>
De context die een agent vormt, bestaat niet alleen uit jullie codebase en huisstijl. Ook de wet- en regelgeving waarbinnen hij opereert is een volwaardige input, geen voetnoot. In ons pakket voor personeelsplanning in de zorg toetst de agent direct aan de geldende arbeidsregels: de geldigheid van registraties en de rust- en urengrenzen uit de cao. Elke koppeling die een blokkerende regel raakt, krijgt de status “controle nodig” en wordt nooit automatisch bevestigd. Een gereguleerde tenant kan als beleid een strengere ondergrens instellen die overal geldt.</p>
Hier bewijst de auditlaag zijn waarde. Harrison Chase schrijft over agent observability</a> dat governance begint bij een ongemakkelijke waarheid: je weet pas wat agents doen wanneer je ze daadwerkelijk laat draaien; hun gedrag ontstaat tijdens runtime. Daarom leggen we het juist dan vast. Elke beslissing bij een controlepoort en elke handeling wordt een onveranderbaar, contentblind record: welk veld veranderde en welke beleidsversie gold, nooit de privédata zelf. Zo kan bij een high-risk audit onder de EU AI Act worden gereconstrueerd wat er is gebeurd.</p>

Waarom dit ertoe doet</p>
Voor een klein team zit hierin de hele businesscase voor deze lagen: ze stellen één persoon in staat om veilig werk te runnen waarvoor eerder een team nodig was, zonder het spoor te verliezen waar een klant of toezichthouder om vraagt.</b></p> </div>
Succes is niet: “we hebben AI ingevoerd”. In de benchmark van LinearB uit 2026 werd 32,7 procent van de AI-ondersteunde pull requests gemerged, minder dan de helft van het percentage bij menselijke pull requests. Het team vat de waarschuwing helder samen: “verwar adoptie niet met impact.”</a> CEO Ori Keren scherpt dat aan: “we produceren twee keer zoveel code, maar de winst ligt ergens tussen de 10 en 15 procent.” Succes is een agent waarvan het werk daadwerkelijk in productie komt en standhoudt. De evalrichtlijnen van Anthropic</a> geven een bruikbare toets voor “goed”: een taak waarbij twee domeinexperts onafhankelijk tot hetzelfde oordeel slagen of zakken komen, en waarbij fouten eerlijk aanvoelen. Harrison Chase schetst het eerlijke beeld: agents zijn niet tot negen negens betrouwbaar. Maar voor langlopend werk dat een eerste versie oplevert, zijn ze uitzonderlijk waardevol.</p>

Een eenvoudige manier om te beginnen</h3>
In deze volgorde · eerst omkeerbaar, dan autonoom</p>

Kies één afgebakende, waardevolle en omkeerbare taak.</b>Iets dat kan uitmonden in een concept-pull request of voorstel, waarbij een fout goedkoop te onderscheppen is.</span></li>
Leg eerst het doel en de toets vast.</b>Wat moet de agent doen en hoe weet je dat het gelukt is? De toets is de specificatie.</span></li>
Geef de agent een strakke scope en een budget.</b>Een sandbox, een korte lijst met tools en een bestedingslimiet. Minimaal noodzakelijke rechten, geen “toegang tot alles”.</span></li>
Laat een mens de pull request beoordelen.</b>Goedkeuren of afwijzen. Autonomie wordt verdiend wanneer de acceptatiegraad standhoudt, niet vooraf toegekend.</span></li>
Leg vanaf dag één elke handeling vast.</b>Wat je niet kunt terugspelen, kun je niet beheersen.</span></li>
Laat de agent leren en toets opnieuw.</b>Geef terug wat werkte en draai de evals opnieuw voordat je de scope verruimt.</span></li> </ol> </div> Een eerlijke kanttekening hoort erbij. Logan Kilpatrick van Google DeepMind stelt dat “het model de harness opeet”</a>: hulpmiddelen die vandaag voor het model uit lopen, worden er morgen in opgenomen. Voor mechanische scaffolding heeft hij gelijk. Maar het model neemt jullie grenzen aan bevoegdheden, het bewijs dat het aan jullie norm voldeed en de vastlegging waar een toezichthouder om vraagt niet over. Die lagen overleven het volgende model. De harness rond productie-agents wordt dan ook groter, niet kleiner.</p>
Dus wanneer iemand zegt een “AI-agent” te hebben, is de relevante vraag niet welk model erachter zit. Vraag welke tools, welk geheugen, welke loop en wie de regie houdt. Het model is het eenvoudige deel. De agent is alles eromheen.</p>
Welke laag is volgens jou het moeilijkst om goed te krijgen in productie?</p>
Veelgestelde vragen</h2>

Wat is het verschil tussen een AI-agent en een chatbot?+</span></summary>
Een chatbot reageert op een vraag. Een agent werkt naar een doel toe: hij plant, handelt, bekijkt het resultaat en bepaalt de volgende stap. Door die loop, samen met tools en geheugen, kan een agent werk afronden in plaats van er alleen vragen over te beantwoorden.</div> </details>

Wat maakt een AI-systeem agentgestuurd?+</span></summary>
Agentgestuurd is geen ja of nee, maar een schaal. Hoe meer het model zelf bepaalt hoe het werk wordt gepland, welke tools het gebruikt en wat de volgende stap is, hoe meer agentgestuurd het systeem is. De nuttige vraag is niet welk label erop zit, maar hoeveel controle het model heeft.</div> </details>

Wat heeft een AI-agent naast een model nodig?+</span></summary>
Een agent heeft tools, geheugen, planning en een loop nodig die het werk voortzet. Binnen een organisatie zijn daarnaast een gedefinieerde skill, duidelijke rechten, tests die aantonen dat de agent het werk aankan en een audittrail nodig. Het model is maar één onderdeel van het systeem.</div> </details>

Hoe houd je grip op een AI-agent?+</span></summary>
Geef de agent een gedefinieerde skill, beperk waartoe hij toegang heeft en wat hij mag doen, toets het werk aan duidelijke evals en leg elke stap vast</a>. Laat een mens goedkeuren</a> waar een fout kostbaar of onomkeerbaar zou zijn. De agent mag de volgende stap bepalen, maar scope, budget en stopvoorwaarden blijven begrensd.</div> </details> </div>

Bronnen</h4>

Simon Willison, a widely agreed definition of “agent”</a> and designing agentic loops</a></li>
Anthropic, Building Effective Agents</a>, Effective context engineering</a> & Demystifying evals</a></li>
Harrison Chase / LangChain, What is an AI agent?</a>, The rise of context engineering</a> & agent observability</a></li>
Google & Kaggle, Agents whitepaper</a>; Lilian Weng, LLM Powered Autonomous Agents</a></li>
Jake Stauch, Rebuilding IT for the AI Age</a>; Jessy Lin, Memory and Continual Learning</a>; Logan Kilpatrick, Why the Model Eats the Harness</a> (Sequoia Training Data)</li>
LinearB Dev Interrupted, 2026 Benchmarks</a> & an AI control plane</a>; Calvin French-Owen, Coding Agents in Feb 2026</a></li> </ul> </div> </div> </article>

Eén miljoen tokens</th>	Illustratieve bandbreedte</th>	Wat dit betekent</th></tr></thead>
Elektriciteit</th>	0,1 tot 1 kWh</td>	Een brede schatting voor het draaien van modellen, geen benchmark. Een workload met veel context en redeneerstappen kan erbuiten vallen</td></tr>
Elektriciteit tegen een industrieel tarief in Texas</th>	ongeveer $0,01 tot $0,07</td>	Bij 6,6 dollarcent per kWh, vóór een eventuele marge van de aanbieder</td></tr>
Elektriciteit tegen het EU-gemiddelde voor niet-huishoudens</th>	ongeveer €0,02 tot €0,18</td>	Bij 18,4 eurocent per kWh. Grote datacenters betalen normaal niet dit gemiddelde tarief</td></tr> </tbody> </table> </div> De bandbreedte geeft gevoel voor de schaal, maar is niet geschikt om aanbieders te vergelijken. Een tokenprijs betaalt ook voor chips, netwerkapparatuur, het gebouw, modelontwikkeling, software, gereserveerde capaciteit en de marge van de aanbieder. Epoch AI begroot een AI-datacenter van één gigawatt op ongeveer 38 miljard dollar aan initiële investeringen</a>. Servers vormen 56 procent van die schatting en de faciliteit 30 procent. De jaarlijkse elektriciteitskosten zijn met ongeveer 0,6 miljard dollar aanzienlijk, maar lager dan de jaarlijkse afschrijving en financiering van de hardware.</p> Een gigawatt in perspectief</p> Een IT-belasting van één gigawatt die continu draait, gebruikt vóór koeling en andere overhead 8,76 terawattuur per jaar. Bij een benutting van 70 procent is dat 6,1 TWh. Nederlandse datacenters kregen in 2024 samen 5,1 TWh geleverd, volgens het CBS. Dit is een vergelijking van schaal, geen één-op-één schatting van een faciliteit.</p> </div> Elektriciteit vormt misschien een bescheiden deel van de tokenprijs, maar toegang tot stroom groeit langzaam mee. Volgens het IEA kost de bouw van een datacenter twee tot drie jaar</a>. Een nieuwe netaansluiting in Europa kan, afhankelijk van land en locatie, twee tot tien jaar</a> duren.</p> De vraag groeit sneller dan het elektriciteitssysteem als geheel. Het IEA meldt dat het stroomverbruik van datacenters in 2025 met 17 procent groeide, tegenover 3 procent voor het totale elektriciteitsverbruik. In de centrale prognose stijgt het wereldwijde verbruik van datacenters van 485 TWh in 2025 naar ongeveer 950 TWh in 2030</a>. Die prognose is voorwaardelijk. Financiering, rendement, beschikbaarheid van apparatuur en ruimtelijke besluiten kunnen de uitkomst veranderen.</p> De levertijd van apparatuur vormt een extra beperking. Volgens het IEA steeg het aantal bestellingen voor gasturbines in 2025 met 70 procent. GE Vernova meldde in juli 2026 116 GW aan orderportefeuille en reserveringen voor gasinstallaties</a>. Opwekking naast een datacenter kan een wachtrij voor het net omzeilen, maar blijft afhankelijk van schaarse apparatuur, vergunningen en brandstof.</p> In Nederland wordt die doorlooptijd zichtbaar. Datacenters ontvingen in 2024 4,6 procent van de Nederlandse elektriciteit</a>. In 2026 oordeelde een rechter dat TenneT een aansluiting van 70 MW in Vijfhuizen mocht uitstellen tot het regionale net is verzwaard. Volgens de NOS wordt tussen 2033 en 2035</a> voldoende capaciteit verwacht. De aansluitdatum bepaalt hier wanneer de capaciteit kan draaien, niet de prijs van de elektriciteit.</p> Epoch AI schat dat de wereldwijde rekenkracht van AI-chips sinds 2022 met ongeveer een factor 3,3 per jaar</a> is gegroeid. Dat is uitzonderlijk snel voor fysieke infrastructuur, maar nog altijd langzamer dan sommige metingen van de vraag naar tokens. Het is bovendien een historische schatting, geen garantie dat dit tempo aanhoudt.</p> De chipproductie hangt van meer af dan de laatste assemblagestap. Geavanceerde logische chips, geheugen met zeer hoge bandbreedte, chipverpakking en lithografiemachines moeten allemaal op tijd beschikbaar zijn. ASML is de enige leverancier van EUV-lithografiesystemen</a> voor de meest complexe lagen van geavanceerde chips. Nieuwe fabrieksruimte kost jaren om te bouwen voordat die machines kunnen worden geïnstalleerd.</p> High-bandwidth memory, meestal afgekort tot HBM, is een tweede beperking. Dit geheugen zit direct naast de processor en verplaatst modeldata snel genoeg om de chip aan het werk te houden. Het IEA verwacht dat het huidige tekort tot en met 2027</a> aanhoudt. Microsoft meldde dat zijn investeringen van 41 miljard dollar in het kwartaal tot en met juni 2026 mede werden beïnvloed door hogere prijzen voor componenten. Deze beperkingen leggen de chipproductie niet stil, maar maken het aanbod op korte termijn minder gevoelig voor een hogere vraag.</p> Eén marktindicator bewoog tegen de bekende trend in. De index van SemiAnalysis voor H100-huurcontracten met een looptijd van één jaar steeg van $1,70 per GPU-uur in oktober 2025 naar $2,35 in maart 2026</a>, een stijging van 38 procent. De index gaat over onderhandelde huurcontracten voor één type chip en één looptijd. Hij laat niet zien dat alle AI-rekenkracht 38 procent duurder is geworden.</p> De beweging is toch relevant. De H100 verscheen in 2022, waardoor nieuwere hardware de huurprijs normaal gesproken zou drukken. Een sterke vraag, volgeboekte capaciteit en hogere componentprijzen duwden de andere kant op.</p> Over het vervolg lopen de meningen uiteen. Dwarkesh Patel stelt dat de omzet van ontwikkelaars van de meest geavanceerde modellen veel sneller groeit dan het aanbod van rekenkracht. Wanneer betere modellen meer opleveren per eenheid rekenkracht, kunnen deze bedrijven meer bieden voor schaarse capaciteit. Epoch AI komt vanuit geschatte vraag en aanbod tot een vergelijkbaar scenario: de inferentiecapaciteit bij een vaste modelgrootte groeit met ongeveer een factor 3,4 per jaar, terwijl de geschatte potentiële vraag veel sneller groeit. Beide prognoses steunen op onzekere aannames. Ze beschrijven een risico, geen prijscurve om op te begroten.</p> De prijs van modelprestaties en de prijs van ruwe rekenkracht meten iets anders.</b> Een benchmarkresultaat werd veel goedkoper, terwijl één schaarse markt voor GPU-huur duurder werd.</figcaption> </figure> Epoch AI berekende dat de laagste prijs om de score van GPT-4 uit maart 2023 op de MMLU-benchmark te evenaren, in februari 2025 was gedaald van $37,50 naar $0,18 per miljoen tokens</a>. Dit resultaat geldt voor deze benchmark en combineert input- en outputprijzen in een vaste verhouding. Het is niet de prijs van elke taak die GPT-4 kon uitvoeren. De daling verschilde sterk tussen de benchmarks die Epoch onderzocht.</p> Ook de kosten van aanbieders zijn gedaald. Google meldde dat het de kosten per eenheid voor Gemini in 2025 door verbeteringen aan modellen, efficiëntie en benutting met 78 procent</a> verlaagde. Een goedkopere eenheid garandeert alleen geen lagere totaalfactuur. Meer gebruik, langere context, extra redeneerstappen en herstelpogingen kunnen de besparing opnemen.</p> Agents maken dat vraageffect concreet. Anthropic meldt dat agents binnen zijn eigen onderzoekssysteem ongeveer vier keer zoveel tokens gebruikten als chatinteracties</a>. Systemen met meerdere agents gebruikten ongeveer vijftien keer zoveel. Die verhoudingen beschrijven één systeem, niet iedere agent. Het algemene punt blijft staan: de kosten van een agent hangen af van de manier waarop die een case afhandelt, niet alleen van de prijs per miljoen tokens.</p> Daarmee verdwijnt de schijnbare tegenstelling. De capaciteit van gisteren kan goedkoper worden, terwijl de nieuwste capaciteit en de benodigde hardware schaars blijven. Een bedrijf kan van de eerste ontwikkeling profiteren zonder de tweede te hoeven voorspellen, mits het kwaliteit kan meten en veilig van model kan wisselen.</p> Vier regels voor iedere agentrol</h3> Meet het werk en stuur daarna op rekenkracht</p> Meet de volledige kosten per afgeronde case.</b>Neem input- en outputtokens, toolaanroepen, herstelpogingen, mislukte runs en de menselijke controle die nodig is mee. Vergelijk dit met de nulmeting in de businesscase</a>.</span></li> Gebruik het goedkoopste model dat voor de evals slaagt.</b>Het matchen van facturen en het afhandelen van uitzonderingen kunnen verschillende modellen vragen. Routeer op taak en risico in plaats van overal het nieuwste model te gebruiken.</span></li> Zorg dat een modelwissel mogelijk blijft.</b>Houd prompts, tools en tests voldoende overdraagbaar om een andere aanbieder te beoordelen. Voer vóór de overstap de regressie-evals uit. Een lagere tokenprijs heeft geen waarde als de kwaliteit daalt of de beheersmaatregelen niet meer werken.</span></li> Beoordeel prijs en gebruik samen.</b>Maak een nieuwe prognose wanneer de agentrol, het aantal cases, de contextlengte of het model verandert. Stel een budgetgrens vast en onderzoek de oorzaak wanneer de kosten per case daarbuiten komen.</span></li> </ol> </div> Dit is de manier waarop Aitonomy met agentkosten omgaat. We leggen de businesscase per agentrol vast vóór het besluit om te bouwen. In productie biedt Aitonomy Control de beheerde runtime, governance, monitoring en traceerbaarheid die nodig zijn om het werk met die nulmeting te vergelijken. Welke kostengegevens beschikbaar zijn, hangt ook af van de modelaanbieder en de integratie. Het maandelijkse oordeel kijkt daarom naar afgeronde cases, kwaliteit, uitzonderingen en volledige kosten, niet alleen naar tokenvolume.</p> Dezelfde discipline geldt voor een modelwissel. Een agentrol gaat pas over op een goedkoper model wanneer uit het bewijs blijkt dat dit nog steeds aan de vereiste kwaliteit en het afgesproken supervisieniveau voldoet. Dat hoort bij het draaien van een agent in productie</a>, niet bij een eenmalige inkoopkeuze.</p> Ga er in de begroting niet vanuit dat AI alleen maar goedkoper wordt, of dat schaarste alles duurder blijft maken. Meet de kosten van het werk, houd de modelkeuze open en werk de businesscase bij met bewijs uit de operatie.</p> Veelgestelde vragen</h2> Hoeveel elektriciteit gebruikt een AI-token?+</span></summary> Daar is geen betrouwbaar universeel getal voor. Google mat in mei 2025 een mediaan tekstverzoek in Gemini Apps op 0,24 wattuur, maar publiceerde niet hoeveel tokens dat verzoek bevatte. Op basis van verschillende openbare gegevens komen wij voor een illustratieve bandbreedte uit op 0,1 tot 1 kilowattuur per miljoen tokens. Het werkelijke verbruik hangt af van het model, de hardware, de lengte van de input en output, de benutting en wat er wordt meegerekend.</div> </details> Wordt AI-rekenkracht goedkoper of duurder?+</span></summary> Beide kunnen tegelijk waar zijn. De laagste prijs voor een vast benchmarkniveau is snel gedaald, terwijl schaarse GPU-huurcapaciteit recent duurder werd. Een bedrijf moet daarom het model en de kosten per afgeronde case volgen, in plaats van ervan uit te gaan dat alle tokenprijzen dezelfde kant op bewegen.</div> </details> Waarom is stroom een knelpunt voor AI?+</span></summary> De elektriciteit zelf vormt vaak maar een klein deel van de prijs van een token van een frontiermodel, maar nieuwe opwekcapaciteit en netaansluitingen kosten jaren. Een datacenter kan klaar zijn voordat het elektriciteitsnet de aansluiting kan leveren. Stroom bepaalt daardoor waar en wanneer extra chips kunnen draaien.</div> </details> Hoe begroot een bedrijf de tokenkosten van AI-agents?+</span></summary> Begroot de volledige variabele kosten per afgeronde case, waaronder input- en outputtokens, toolaanroepen, herstelpogingen en menselijke controle. Kies het goedkoopste model dat slaagt voor de evals van de agentrol, zorg dat een modelwissel mogelijk blijft en vergelijk kosten en kwaliteit op vaste momenten met de goedgekeurde businesscase.</div> </details> </div> Bronnen en afbakening</h4> IEA: Energy and AI</a> (2025), Key Questions on Energy and AI</a> (2026) en het artikel over Europese netbeperkingen</a> (2025).</li> Google: energieverbruik van AI-inferentie</a> (2025, methode en cijfers van Google, niet onafhankelijk geverifieerd), toelichting op de kosten in 2025</a> en tokenvolumes tijdens I/O 2026</a>.</li> Epoch AI: trends in inferentieprijzen</a> (2025), wereldwijde capaciteit van AI-chips</a>, kosten van datacenters</a> en het scenario van schaarse rekenkracht</a> (2026).</li> Markt- en bedrijfsbronnen: ASML</a> over EUV-lithografie; SemiAnalysis, H100-huurindex</a> (2026); GE Vernova, resultaten tweede kwartaal 2026</a>; Microsoft, toelichting op het vierde kwartaal van boekjaar 2026</a>; en Anthropic over tokengebruik in zijn onderzoekssysteem met meerdere agents</a> (2025).</li> Nederland: CBS</a> over het stroomverbruik van datacenters (2025) en NOS</a> over de aansluiting in Vijfhuizen (2026).</li> Elektriciteitstarieven voor de illustratieve bandbreedte: US Energy Information Administration</a> en Eurostat</a>.</li> Bronnen gecontroleerd op 7 september 2026. Prognoses staan als prognose vermeld. Illustratieve berekeningen zijn schattingen van een orde van grootte, geen gemeten voetafdruk per token of voorspelling van de prijzen van aanbieders.</li> </ul> Kijk en luister</h4> Kijk:</b> Dwarkesh Patel, “Why smarter AI models could drive up compute prices 10x”</a> (augustus 2026, 11 minuten). Zie dit als een redenering over een mogelijke marktuitkomst, niet als een prognose om op te begroten.</li> Luister:</b> Dwarkesh Podcast met Dylan Patel</a> (maart 2026) over de fysieke knelpunten in logica, geheugen en stroom.</li> </ul> </div> </div> </article> Wat ISO 42001 van een organisatie vraagt Mik Nijhuis — Sun, 06 Sep 2026 00:00:00 +0000 Leveranciersvragenlijsten kregen er dit jaar een regel bij: zijn jullie ISO/IEC 42001-gecertificeerd, en zo niet, wanneer wel? De norm achter die vraag telt 51 pagina's. Deze gids legt in bedrijfstaal uit wat die pagina's van een organisatie vragen en wat het certificaat wel en niet bewijst.</p> Het bredere beeld bespraken we in de spelregels die rond AI ontstaan</a>. Hier behandelen we de norm zelf, op basis van het gratis gepubliceerde deel, de gedeelde structuur van ISO-managementsysteemnormen, geaccrediteerde certificeringsinstanties en auditors en aankondigingen van gecertificeerde organisaties.</p> ISO/IEC 42001:2023</a>, gepubliceerd in december 2023, stelt eisen aan een AI-managementsysteem. Dat is het geheel van beleid, rollen, processen en vastlegging waarmee een organisatie iets bewust bestuurt in plaats van uit gewoonte. ISO 9001 doet dit voor kwaliteit, ISO 27001 voor informatiebeveiliging en ISO 42001 voor ontwikkeling, aanbod en gebruik van AI.</p> Het certificaat zegt dus iets specifieks: een geaccrediteerde auditor stelde vast dat de organisatie heeft bepaald welke AI zij bestuurt, risico's en impact beoordeelt, controls kiest, gegevens vastlegt, zichzelf controleert en bevindingen corrigeert. Het zegt niet dat een model nauwkeurig of eerlijk is, of dat de organisatie aan de EU AI Act voldoet. Over AI buiten de vastgelegde scope zegt het niets.</p> ISO 42001 is bedoeld voor het verschil: risico's die specifiek zijn voor AI. Denk aan bias, transparantie, verantwoord gebruik, ethiek en veiligheid. Danny Manimbo, Schellman</b> · ISO 42001 certification FAQ, February 2025</cite> </blockquote> De norm noemt drie rollen: producent, aanbieder en gebruiker. Eén organisatie kan er meerdere hebben. Een bedrijf dat agents runt op een gekocht platform is gebruiker van het platform en mogelijk aanbieder van de agent. De rollen vormen de scope en die bepaalt wat de audit omvat.</p> Het certificaat dekt een scope, geen heel bedrijf</p> Het certificaat van AWS noemt vier diensten. Dat van Microsoft negen Copilot- en Foundry-producten. Dat van IBM één modelfamilie. Zegt een leverancier gecertificeerd te zijn, vraag dan: voor welke systemen, en valt wat wij kopen binnen die scope?</p> </div> 02</span>Hoe is de norm opgebouwd?</h2> Pagina's 1 tot en met 16 bevatten de scope, 26 definities en de eisen in clausules 4 tot en met 10. Bijlage A telt vier pagina's en noemt 38 controls onder negen doelstellingen. De normatieve Bijlage B telt 25 pagina's en geeft implementatierichtlijnen per control. Bijlagen C en D zijn informatief.</p> De helft van het document bestaat uit richtlijnen voor de 38 controls.</b> De eisen beslaan 16 pagina's, grotendeels de structuur die elke ISO-managementsysteemnorm deelt. Paginanummers uit de gepubliceerde inhoudsopgave.</figcaption> </figure> Clausules 4 tot en met 10 gebruiken de geharmoniseerde ISO-structuur: dezelfde nummering, titels en kerntekst in alle managementsysteemnormen. Wie ISO 27001 heeft gerund, herkent bijna alles. Het nieuwe AI-deel zit in enkele subclausules, gemarkeerd in de figuur, en in de bijlagen. De volledige Engelstalige tekst kost CHF 225 bij ISO of circa EUR 250 exclusief btw bij NEN. De gratis preview stopt na clausule 4.</p> 03</span>Wat vereisen clausules 4 tot en met 10?</h2> De tabel beschrijft elke clausule in gewone taal, met de vastlegging waar een auditor naar zoekt. De rechterkolom telt meer dan de middelste. Een map vol beleid zonder bewijs erachter faalt de audit.</p> Clausule</th> Wat wordt gevraagd</th> Wat je moet kunnen aantonen</th></tr> </thead> 4 Context</th> Bepaal wat jullie AI-gebruik beïnvloedt en welke AI-systemen onder het managementsysteem vallen</td> Een geschreven scope, belanghebbenden en hun verwachtingen. Clausule 4.1 vraagt ook of klimaatverandering relevant is</td></tr> 5 Leiderschap</th> Topmanagement committeert zich, stelt AI-beleid vast en wijst verantwoordelijkheden toe</td> AI-beleid goedgekeurd aan de top. Benoemde eigenaren voor AI-risico, impactbeoordeling en het systeem</td></tr> 6 Planning</th> Definieer beoordeling en behandeling van AI-risico en impact op mensen. Stel meetbare AI-doelen</td> Een risicomethode met vooraf vastgestelde criteria, behandelplan, Statement of Applicability, impactproces en doelen met eigenaren</td></tr> 7 Support</th> Zorg voor middelen en competente mensen, bewustzijn, communicatie en documentbeheer</td> Bewijs van competentie en beheerde documenten met versies</td></tr> 8 Operatie</th> Voer processen en beoordelingen uit op geplande momenten en bij belangrijke wijzigingen</td> Resultaten van elke beoordeling en bewijs dat processen en wijzigingsreviews zijn uitgevoerd</td></tr> 9 Evaluatie</th> Monitor en meet, voer interne audits uit en laat management resultaten beoordelen</td> Monitoringsresultaten, intern auditprogramma met bevindingen en managementreviewrecords</td></tr> 10 Verbetering</th> Herstel afwijkingen, pak oorzaken aan en verbeter doorlopend</td> Vastlegging van elke afwijking, corrigerende actie en het effect ervan</td></tr> </tbody> </table> </div> Hier is objectief bewijs nodig dat jullie AI-managementsysteem werkelijk werkt en niet alleen uit intenties bestaat. Ali Moshayedi, ISO 42001 auditor, BSI</b> · on clause 9, BSI webinar, March 2026</cite> </blockquote> 04</span>Wat is specifiek voor AI?</h2> Drie processen, gedefinieerd in clausule 6 en uitgevoerd in clausule 8.</p> AI-risicobeoordeling (6.1.2, 8.2).</b> Bepaal wat de AI-systemen van de organisatie met haar eigen doelen kunnen doen, op basis van vooraf vastgestelde criteria. Bijlage C geeft mogelijke risicobronnen.</p> AI-risicobehandeling (6.1.3, 8.3).</b> Kies welke controls de risico's behandelen en leg dit vast in een Statement of Applicability, inclusief onderbouwing van opgenomen en uitgesloten controls. Dit is het eerste wat een auditor leest.</p> AI-systeemimpactbeoordeling (6.1.4, 8.4).</b> Beoordeel de gevolgen van het ontwikkelen, aanbieden of gebruiken van een AI-systeem voor individuen, groepen en de samenleving. Een risicobeoordeling kijkt naar binnen, naar de organisatie. Een impactbeoordeling kijkt naar buiten, naar de mensen die het systeem raakt.</p> De impactbeoordeling is de naar buiten gerichte toevoeging.</b> De meeste managementsysteemnormen kennen al een risicobeoordeling. ISO 42001 voegt een tweede toe, gericht op getroffen mensen. ISO/IEC 42005:2025</a> geeft richtlijnen voor doel, betrokkenen, voorzienbare impact en maatregelen.</figcaption> </figure> De negen controledoelstellingen</h3> Bijlage A groepeert 38 controls onder negen doelstellingen. Je selecteert wat de risicobehandeling vereist, kunt eigen controls toevoegen en onderbouwt elke opname en uitsluiting in de Statement of Applicability.</p> Doelstelling</th> Controls</th> Wat er in gewone taal onder valt</th></tr> </thead> A.2 Beleid voor AI</th> 3</td> AI-beleid dat aansluit op ander beleid en volgens planning wordt beoordeeld</td></tr> A.3 Interne organisatie</th> 2</td> Wie waarvoor verantwoordelijk is en hoe medewerkers zorgen over AI melden</td></tr> A.4 Middelen</th> 5</td> Data, tools, rekenkracht en mensen waarvan elk AI-systeem afhankelijk is</td></tr> A.5 Impactbeoordeling</th> 4</td> Een proces om impact op individuen, groepen en samenleving te beoordelen en vast te leggen</td></tr> A.6 Levenscyclus</th> 9</td> Verantwoord ontwerp, verificatie, validatie, inzet, operatie, monitoring, documentatie en eventlogs</td></tr> A.7 Data</th> 5</td> Herkomst, kwaliteit, provenance en voorbereiding van data</td></tr> A.8 Informatie voor belanghebbenden</th> 4</td> Informatie aan gebruikers, externe rapportage en communicatie over incidenten</td></tr> A.9 Gebruik van AI</th> 3</td> Processen voor verantwoord gebruik en een beoogd doel per systeem</td></tr> A.10 Derden en klanten</th> 3</td> Verantwoordelijkheden in de keten, leveranciersbeheer en plichten aan klanten</td></tr> </tbody> </table> </div> Vijf van de negen zijn nieuw ten opzichte van een informatiebeveiligingsnorm: A.5 tot en met A.9 over impact, levenscyclus, data, informatie en gebruik. Daar zit het meeste nieuwe werk.</p> 05</span>Wat houdt certificering in?</h2> Certificering komt van een certificeringsinstantie die zelf voor ISO 42001 is geaccrediteerd onder ISO/IEC 42006:2025</a>. In Nederland accrediteerde de RvA BSI en DNV in januari 2025</a> en TÜV NORD in februari 2026. Sommige vroege certificaten kwamen onder andere schema's tot stand. Controleer daarom het accreditatiemerk.</p> De audit volgt het ISO 27001-patroon: Stage 1 beoordeelt documentatie in één of twee dagen, Stage 2 test in één tot drie weken of het systeem werkt, gevolgd door een driejarig certificaat met jaarlijkse surveillance. Dit zijn gepubliceerde ervaringen van Schellman</a>. Het bedrijf noemt auditkosten in het eerste jaar van enkele tienduizenden dollars. Stage 2 zoekt naar records, dus het systeem moet vóór de audit hebben gedraaid. Implementers noemen zes tot twaalf maanden vanaf nul en drie tot zes maanden bij een bestaand ISO 27001-systeem. Behandel dit als ervaringscijfers, niet als universele norm. De grootste kosten zitten intern in inventarisatie, beoordelingen en vastlegging.</p> Als jullie scope niet volledig helder is, falen de governance en de audit. Fran Caballero, ISO 42001 auditor, BSI</b> · BSI webinar with Darktrace, May 2026</cite> </blockquote> Caballero noemt drie terugkerende fouten bij BSI: een scope die niet zegt waar AI begint en eindigt, metrics uit gewone IT die niets zeggen over drift, eerlijkheid of datanauwkeurigheid en gedownload beleid dat alleen voor de audit dient. Daaraan vooraf gaat de inventaris: de eerste vraag van een auditor is een lijst van AI-systemen in scope met hun beoogde gebruik.</p> 06</span>Hoe pakten de eerste gecertificeerde organisaties het aan?</h2> Organisatie</th> Gecertificeerd</th> Scope</th> Wat opvalt</th></tr> </thead> AWS</a></th> Nov 2024, Schellman</td> Bedrock, Q Business, Textract, Transcribe</td> Governance langs de zeven AI-lifecyclefasen van ISO/IEC 22989. Eerste surveillanceaudit in nov 2025 zonder bevindingen</td></tr> Anthropic</a></th> Jan 2025, Schellman</td> AI-producten en -diensten, inclusief de Claude-modellen</td> Koppelt het managementsysteem aan het Responsible Scaling Policy</td></tr> Microsoft</a></th> Mrt 2025, hercertificeerd mei 2026</td> Negen benoemde Copilot- en Foundry-producten</td> Risicogestuurde review zodat senior controle naar systemen met meer impact gaat. Scope groeide in jaar twee van twee naar drie systemen</td></tr> Darktrace</a></th> Jul 2025, BSI</td> De AI-gedreven securityproducten</td> Gebouwd op een bestaand ISO 27001- en 27018-systeem. Elke AI-wijziging doorloopt nu vóór productie een impactbeoordeling</td></tr> Metyis, Amsterdam</a></th> Jul 2025, DNV</td> Het AI-managementsysteem</td> Eerste in Nederland uitgegeven ISO 42001-certificaat onder RvA-accreditatie</td></tr> </tbody> </table> </div> Ook Google Cloud, Workday, Snowflake, Salesforce, SAP, IBM voor de Granite-modellen, KPMG in de VS en BCG kondigden certificaten aan. BCG rekende zichzelf in januari 2026 tot de eerste honderd organisaties wereldwijd</a>. Voor zover wij konden vaststellen, had in september 2026 nog geen Nederlandse bank, verzekeraar of overheidsinstantie een certificaat aangekondigd.</p> Wanneer we een AI-systeem wijzigen, doorloopt het nu vóór productie een AI-impactbeoordeling van datakwaliteit, bias, risico en klantimpact. Darktrace compliance team</b> · BSI webinar, May 2026</cite> </blockquote> Drie patronen keren terug. De scope is smal en benoemd. Het systeem bouwt voort op bestaande ISO 27001-processen, aangevuld met AI-beoordelingen en vijf nieuwe controlgebieden. Darktrace benadrukte dat het ISO 42001 niet vanaf nul bouwde. De zichtbare operationele verandering is een controlepoort: een impactbeoordeling vóór een AI-systeem of wijziging productie bereikt.</p> Het commerciële effect is al zichtbaar. Volgens Schellman vereist Microsofts leveranciersprogramma SSPA ISO 42001-certificering van leveranciers waarvan het AI-gebruik als gevoelig of high-risk geldt. Zonder certificaat of gedateerd plan krijgt een leverancier nu een langere vragenlijst en later mogelijk uitsluiting van werk. Voor een inkoper is ernaar vragen een goedkope toets of de leverancier een inventaris bijhoudt, impact beoordeelt en na release monitort.</p> 07</span>Hoe verhoudt de norm zich tot de EU AI Act?</h2> ISO 42001 is geen geharmoniseerde norm onder de AI Act en certificering geeft geen vermoeden van conformiteit. CEN-CENELEC JTC 21 schreef voor artikel 17 de eigen kwaliteitsmanagementnorm EN 18286, goedgekeurd in juli 2026. Artikel 17 geldt per high-risksysteem als product, terwijl 42001 een organisatie bestuurt. In september 2026 was nog geen geharmoniseerde AI Act-norm in het Publicatieblad genoemd. 42001 werd in 2026 als Europese norm overgenomen; overname is geen harmonisatie.</p> </th> EU AI Act</th> ISO/IEC 42001</th></tr> </thead> Wat het is</th> Wet, gefaseerd van kracht van 2025 tot 2028</td> Een vrijwillige norm waarvoor je je kunt laten certificeren</td></tr> Wie gebonden is</th> Aanbieders en gebruiksverantwoordelijken, naar rol en risiconiveau</td> Wie ervoor kiest, binnen de eigen gedefinieerde scope</td></tr> De eenheid</th> Elk AI-systeem, geclassificeerd naar beoogd doel</td> Het managementsysteem van de organisatie</td></tr> Wat het bewijst</th> Dat aan de verplichtingen voor dat systeem is voldaan</td> Dat een geaccrediteerde auditor een werkend managementsysteem aantrof</td></tr> Waar ze overlappen</th> Risicomanagement, datagovernance, documentatie en logging, menselijke controle, monitoring na release, leveranciersbeheer en communicatie over incidenten</td></tr> Wat 42001 niet dekt</th> Conformiteitsbeoordeling, CE-markering en conformiteitsverklaring; registratie in de EU-databank; grondrechteneffectbeoordeling uit artikel 27; incidentmeldtermijnen uit artikel 73; technisch dossier uit Bijlage IV per systeem</td></tr> </tbody> </table> </div> Het betekent niet dat je automatisch compliant bent. Het is wel de eerste trede op de ladder, de eerste stap richting compliance. Will Booth, Director of Cybersecurity Compliance, Darktrace</b> · on the AI Act, BSI webinar, May 2026</cite> </blockquote> Voor een organisatie die met beide te maken heeft, werkt één managementsysteem plus één dossier per AI-systeem praktisch. Het managementsysteem bevat beleid, beoordelingen, audits en reviews. Het systeemdossier bevat wat de wet voor dat systeem vraagt, zoals uitgewerkt in wat de AI Act van een gebruiksverantwoordelijke vraagt</a>.</p> Wat Control voor een auditor bewaart</h3> Per agentrol · zes soorten bewijs</p> Beoogd gebruik en scope.</b>Elke agent heeft een gedefinieerde taak, een benoemde menselijke eigenaar en expliciete grenzen. De Scan inventariseert werk en systemen vóór de eerste run. (A.9.4; clausule 4.3.)</span></li> Menselijke controle.</b>Elke capaciteit draait op een supervision level: Suggests, Drafts of Auto. Bewijs verhoogt het niveau; regels verlagen het. Elke goedkeuring en reden wordt vastgelegd. (A.9.2; clausule 5.3.)</span></li> Operatie, monitoring en eventlogs.</b>Elke handeling in productie wordt met controles, reviewer en uitkomst vastgelegd. Governancewijzigingen staan in dezelfde historie. (A.6.2.6; A.6.2.8; clausule 9.1.)</span></li> Verificatie en validatie.</b>Een modelwijziging stuurt de agent terug naar de apart gehouden testcases voordat hij zijn niveau behoudt. Uitzonderingen, beleidsovertredingen en kwaliteitspoorten worden gevolgd. (A.6.2.4.)</span></li> Modellen van derden.</b>Elke rol gebruikt een goedgekeurd model van een vervangbare aanbieder. Elke koppeling met jullie systemen toont hoe die is beveiligd. (A.10.3; A.4.)</span></li> Correctie en verbetering.</b>Geaccepteerde menselijke correcties worden voorgestelde wijzigingen aan de rol. Elke doorgevoerde wijziging is zichtbaar en omkeerbaar. (Clausule 10.)</span></li> </ol> </div> Control schrijft niet het managementsysteem. AI-beleid, scope, beoordelingen, interne audit, managementreview en Statement of Applicability blijven documenten van de organisatie. Die leest een certificeringsinstantie als eerste. Is vóór go-live een impactbeoordeling nodig, dan bereiden wij de operationele input voor: doel, geraakte data, grenzen en supervision. De verantwoordelijke proceseigenaar bij de klant besluit of de impact wordt geaccepteerd. Aitonomy heeft geen ISO 42001-certificaat en certificeert niemand. De mapping hierboven is van ons, niet van een auditor.</p> Neem één AI-systeem dat jullie al runnen en stel de vragen uit de norm. Waarvoor dient het? Wie is eigenaar? Wat kan het doen met de mensen aan de andere kant? Wat deed het vorige week en wie controleerde dat? Bestaan de antwoorden als records, dan is certificering een vraag van scope en auditdatum. Bestaan ze niet, dan ligt daar het werk. Ook als geen vragenlijst er ooit om vraagt.</p> Veelgestelde vragen</h2> Wat is ISO 42001 in gewone taal?+</span></summary> ISO/IEC 42001:2023 is de internationale norm voor een AI-managementsysteem: beleid, rollen, beoordelingen, vastlegging en reviews waarmee een organisatie de AI bestuurt die zij ontwikkelt, aanbiedt of gebruikt. De structuur lijkt op ISO 27001, aangevuld met AI-risico- en impactbeoordelingen en 38 mogelijke controls. Een geaccrediteerde instantie kan een organisatie hiervoor certificeren.</div> </details> Betekent ISO 42001-certificering dat je aan de EU AI Act voldoet?+</span></summary> Nee. ISO 42001 is geen geharmoniseerde norm onder de AI Act en geeft geen vermoeden van conformiteit. Er is veel overlap, maar productplichten zoals conformiteitsbeoordeling, CE-markering, registratie en de grondrechteneffectbeoordeling vallen erbuiten. De norm is een bruikbare basis voor werk aan de AI Act</a>, geen vervanging.</div> </details> Heb je ISO 27001 nodig vóór ISO 42001?+</span></summary> Nee. De norm vereist niet dat eerst een ander managementsysteem is ingevoerd of gecertificeerd. In de praktijk bouwden de meeste vroege gebruikers voort op een bestaand ISO 27001-systeem en voegden ze AI-specifieke beoordelingen en controls toe.</div> </details> </div> Bronnen en reikwijdte</h4> ISO/IEC 42001:2023</a>, Information technology, Artificial intelligence, Management system. Read in the public preview. Companion standards ISO/IEC 42005:2025</a> (AI system impact assessment) and ISO/IEC 42006:2025</a> (requirements for certification bodies).</li> Annex A control titles cross-checked against the NIST AI RMF to ISO/IEC 42001 crosswalk</a>.</li> Schellman, lessons learned from auditing ISO 42001</a> and its certification FAQ</a> (fees, Microsoft SSPA).</li> Accreditation: RvA</a> (January 2025), UKAS</a> (January 2026), TÜV NORD</a> (February 2026).</li> Certifications: the organisations’ own announcements, linked in the table, plus AWS’s first surveillance audit</a>, Microsoft’s May 2026 recertification</a>, Google Cloud</a>, Salesforce</a> and IBM</a>.</li> AI Act: Cloud Security Alliance on EN 18286 and ISO 42001</a> (April 2026); CEN-CENELEC on EN 18286</a> (July 2026).</li> Sources checked 6 September 2026. A practical guide, not legal advice, and not a substitute for the standard itself; the plain-language descriptions are ours.</li> </ul> Kijk en luister</h4> Watch:</b> BSI, “Unlocking value with ISO/IEC 27001 and ISO/IEC 42001”</a> (May 2026): a BSI auditor on where audits fail, and Darktrace on what certification changed.</li> Watch:</b> BSI, “AI governance and assurance”</a> (March 2026): an ISO 42001 auditor on the clauses, the impact assessment and EN 18286.</li> Watch:</b> INCITS and NIST, “Unlocking the power of AI management systems”</a> (2024): the workshop at the standard’s launch, with Microsoft’s Kim Lucy on why the impact assessment was added.</li> </ul> </div> </div> </article> Wat de EU AI Act van een gebruiksverantwoordelijke vraagt Mik Nijhuis — Thu, 03 Sep 2026 00:00:00 +0000 Een agent die leveranciersfacturen koppelt en een agent die sollicitanten filtert, kunnen op hetzelfde platform draaien. Toch gelden voor hen niet dezelfde verplichtingen onder de EU AI Act. Het doel van het werk telt, net als de rol van jullie organisatie bij het aanbieden of gebruiken van het systeem.</p> Voor een operationeel team zijn de eerste vragen praktisch. Zijn we gebruiksverantwoordelijke, aanbieder of allebei? Is dit gebruik high-risk? Wat moeten we nu doen en welk bewijs hebben we nodig wanneer de overige regels gaan gelden?</p> Het bredere beeld bespraken we in de spelregels die rond AI ontstaan</a>. Dit artikel kiest het perspectief van de gebruiksverantwoordelijke: de organisatie die een AI-systeem onder haar verantwoordelijkheid gebruikt. De focus ligt op terugkerend bedrijfswerk, niet op specialistische regels voor rechtshandhaving of alle productveiligheidsregimes.</p> Een aanbieder ontwikkelt een systeem of laat het ontwikkelen en brengt het onder eigen naam of merk op de markt of stelt het in gebruik. Daarvoor hoef je het onderliggende model niet zelf te trainen of software aan andere bedrijven te verkopen. Ook opdracht geven voor een systeem voor eigen gebruik kan relevant zijn. Dit zijn de definities uit artikel 3</a>.</p> De rollen horen bij het systeem en de activiteit. Een organisatie kan gebruiksverantwoordelijke zijn voor het ene systeem en aanbieder van het andere. De aankoop van een agentplatform bepaalt niet vanzelf de status van alles wat erop wordt gebouwd.</p> Artikel 25</a> noemt drie situaties waarin een gebruiksverantwoordelijke of andere partij de verplichtingen van een aanbieder van een high-risksysteem overneemt:</p> Een eigen naam of merk op een bestaand high-risksysteem zetten, met inachtneming van de bepaling over contractuele verdeling van verplichtingen.</li> Een bestaand high-risksysteem wezenlijk wijzigen, waarbij het high-risk blijft.</li> Het beoogde doel van een niet-high-risksysteem zo veranderen dat het high-risk wordt.</li> </ul> Routineconfiguratie is niet automatisch een wezenlijke wijziging. Omgekeerd kan iets dat intern “alleen een nieuwe workflow” heet, het beoogde doel wel veranderen. Breid je een documentassistent uit naar sollicitantenscreening, beoordeel de classificatie dan opnieuw vóór go-live.</p> Leg het vast in het contract</p> Het contract moet benoemen wie het systeem aanbiedt, wat het beoogde doel is, welke wijzigingen zijn toegestaan, wie toegang krijgt tot documentatie en wat er gebeurt bij een andere rol of classificatie. Artikel 25 erkent contractuele verdeling in het geval van naam en merk. Dat is geen algemeen recht om de wet contractueel buiten werking te zetten.</p> </div> Artikel 6</a> kent twee hoofdroutes. De eerste betreft bepaalde producten en veiligheidscomponenten onder de wetgeving in Bijlage I, wanneer de relevante conformiteitsbeoordeling door een derde vereist is. De tweede betreft toepassingen uit Bijlage III, waaronder specifieke vormen van inzet bij werk, onderwijs, essentiële diensten, biometrie en kritieke infrastructuur.</p> Voor veel operationele teams is Bijlage III de meest directe vraag. Sollicitanten screenen, de kredietwaardigheid van personen beoordelen en risico of prijs bepalen voor levens- en zorgverzekeringen staan op de lijst. Leveranciersfacturen koppelen of achter een leverdatum aangaan valt op basis van die omschrijving normaal gesproken niet in die categorieën.</p> Artikel 6(3) bevat beperkte uitzonderingen voor sommige systemen uit Bijlage III, waaronder bepaalde smalle procedurele of voorbereidende taken zonder significant risico. Dit zijn voorwaarden om zorgvuldig te toetsen, geen labels om losjes toe te passen. Systemen uit Bijlage III die natuurlijke personen profileren, worden onder deze bepaling altijd als high-risk behandeld.</p> Vraag de aanbieder om het beoogde doel en de classificatie en vergelijk die met wat jullie werkelijk van plan zijn. Leg de beslissing en redenen vast. Verandert het werk, beoordeel dan opnieuw.</p> Dit hangt samen met, maar staat los van, de geschiktheid van het werk voor een AI-agent</a>. Een proces kan juridisch toegestaan zijn en toch te duur om te controleren of te moeilijk om te begeleiden.</p> De Digital Omnibus voor AI, Verordening (EU) 2026/1744</a>, wijzigde de AI Act in juli 2026. Specifieke high-riskbepalingen zijn uitgesteld, niet de hele wet. De door de Raad aangenomen tekst</a> beschrijft de wijzigingen in artikelen 111 en 113.</p> Bepaling</th> Geldt vanaf</th> Wat te controleren</th></tr> </thead> Artikel 4 AI-geletterdheid</th> 2 feb 2025</td> Tekst gewijzigd in juli 2026. Maatregelen die AI-geletterdheid ondersteunen van medewerkers en anderen die namens jullie AI gebruiken</td></tr> Artikel 5 verboden</th> 2 feb 2025</td> Of een praktijk verboden is, vóórdat controls of openbaarmaking worden overwogen</td></tr> Artikel 50 transparantie</th> 2 aug 2026</td> Welke plicht geldt en of die bij jullie of de aanbieder ligt. Sommige kennen uitzonderingen</td></tr> Hoofdstuk III Afdelingen 1 t/m 3</th> 2 dec 2027</td> High-risksystemen uit Bijlage III, behalve artikel 6(5). Classificatie, systeemeisen en plichten uit artikelen 26 en 27</td></tr> Hoofdstuk III Afdelingen 1 t/m 3</th> 2 aug 2028</td> Dezelfde bepalingen voor artikel 6(1) en systemen uit Bijlage I, met de toepasselijke productregels</td></tr> </tbody> </table> </div> Dit zijn algemene data. Het gewijzigde artikel 111 bevat overgangsregels voor high-risksystemen die vóór de relevante datum uit Hoofdstuk III al op de markt of in gebruik waren, met voorwaarden rond ingrijpende ontwerpwijzigingen. Stel per systeem vast welke regels gelden. Behandel december 2027 niet als universele deadline voor elke bestaande inzet.</p> AI-geletterdheid vraagt nu al actie</h3> Het gewijzigde artikel 4 vereist maatregelen die de ontwikkeling van AI-geletterdheid ondersteunen. Het eist geen gegarandeerd niveau voor ieder individu. Training en begeleiding moeten passen bij de mensen, systemen en gebruikscontext. Leg vast wat is aangeboden en waarom dat passend was. De vragen en antwoorden over AI-geletterdheid</a> van de Commissie lichten de gewijzigde aanpak toe.</p> Transparantie hangt af van gebruik en rol</h3> Artikel 50 scheidt plichten van aanbieders en gebruiksverantwoordelijken. Aanbieders moeten systemen voor rechtstreekse interactie met mensen zo ontwerpen dat duidelijk is dat zij met AI te maken hebben, tenzij dat uit de omstandigheden al vanzelf spreekt. Ook dragen aanbieders de plicht voor machineleesbare markering van synthetische content.</p> Gebruiksverantwoordelijken hebben specifieke plichten voor emotieherkenning en biometrische categorisering, deepfakes en door AI gegenereerde of gemanipuleerde tekst die het publiek informeert over zaken van algemeen belang. Voor die laatste categorie geldt een uitzondering bij menselijke review of redactionele controle, mits een persoon of organisatie redactioneel verantwoordelijk is. Voor duidelijk artistieke, creatieve, satirische of fictieve deepfakes gelden bijzondere regels. Zie artikel 50</a>.</p> Voor een bestaand generatief systeem dat vóór 2 augustus 2026 op de markt kwam, is de markeringsdeadline voor de aanbieder uit artikel 50(2) 2 december 2026. Die overgang stelt de eigen openbaarmakingsplichten van de gebruiksverantwoordelijke niet uit.</p> De Omnibus voegt per 2 december 2026 ook verboden toe voor bepaalde seksuele of intieme content zonder toestemming en materiaal van seksueel misbruik van kinderen. Openbaarmaking maakt verboden gebruik niet rechtmatig.</p> De AVG, arbeidsregels en toepasselijke sectoreisen blijven naast de AI Act gelden. Het high-riskuitstel schort die niet op.</p> 04</span>Wat vereist artikel 26 van een high-riskgebruiksverantwoordelijke?</h2> Zodra artikel 26 op jullie systeem van toepassing is, gaan de belangrijkste eisen over gebruik, menselijke controle en monitoring. Hieronder staat een praktische samenvatting, geen vervanging van de volledige bepaling of sectorspecifieke voorwaarden.</p> Gebied</th> Wat de gebruiksverantwoordelijke moet doen</th> Artikel</th></tr> </thead> Gebruik</th> Technische en organisatorische maatregelen nemen om het systeem volgens de instructies van de aanbieder te gebruiken</td> 26(1)</td></tr> Menselijke controle</th> Die beleggen bij mensen met de competentie, training, bevoegdheid en ondersteuning om haar uit te oefenen</td> 26(2)</td></tr> Inputdata</th> Waar de gebruiksverantwoordelijke de inputdata beheert, zorgen dat die relevant en voldoende representatief is voor het beoogde doel</td> 26(4)</td></tr> Monitoring</th> De werking monitoren, handelen bij relevante risico's, gebruik waar vereist opschorten en de nodige meldingen doen</td> 26(5)</td></tr> Logs</th> Automatisch gegenereerde logs onder eigen controle passend en minstens zes maanden bewaren, tenzij toepasselijk recht anders bepaalt</td> 26(6)</td></tr> Werknemers</th> Betrokken werknemers en hun vertegenwoordigers vóór gebruik op de werkplek informeren dat zij aan het high-risksysteem worden onderworpen</td> 26(7)</td></tr> Registratie</th> Als overheidsinstantie of namens een overheid, de toepasselijke registratie- en databankcontroles uitvoeren</td> 26(8)</td></tr> Gegevensbescherming</th> Bij een verplichte DPIA de informatie van de aanbieder gebruiken ter ondersteuning</td> 26(9)</td></tr> Betrokken personen</th> Bij relevante systemen uit Bijlage III die beslissingen over personen nemen of ondersteunen, die personen informeren over het gebruik</td> 26(11)</td></tr> Autoriteiten</th> Meewerken met bevoegde autoriteiten aan maatregelen rond het systeem</td> 26(12)</td></tr> </tbody> </table> </div> De volledige tekst staat in artikel 26</a>. Iemand beschikbaar hebben om output goed te keuren is niet genoeg als die persoon de beperkingen niet begrijpt, de relevante informatie niet kan verkrijgen of het werk niet kan stoppen.</p> Artikel 27 voegt voor bepaalde gebruiksverantwoordelijken en toepassingen een grondrechteneffectbeoordeling toe. Dit geldt voor publiekrechtelijke instellingen, private partijen die publieke diensten leveren en gebruiksverantwoordelijken van de genoemde systemen voor kredietwaardigheid en levens- of zorgverzekeringen. De categorie kritieke infrastructuur uit Bijlage III is uitgezonderd. Niet elke private organisatie met high-risk-AI hoeft deze beoordeling uit te voeren.</p> Waar vereist, vindt de beoordeling vóór het eerste gebruik plaats, blijft ze actueel en worden de resultaten zoals voorgeschreven gemeld. De Omnibus staat kruisverwijzingen naar relevante delen van een bestaande DPIA toe, of opname daarvan in de grondrechtenbeoordeling. De beoordeling zelf vervalt niet. Zie artikel 27</a> en de wijzigingen</a>.</p> Zes maanden is een bewaartermijn</h3> Artikel 26(6) bepaalt hoelang relevante logs moeten worden bewaard zodra de plicht geldt. Het vereist niet dat op de eerste dag al zes maanden historie bestaat.</p> Eerder beginnen kan helpen monitoring te testen en fouten te onderzoeken, maar moet een bewuste operationele beslissing zijn. Stel bewaartermijn, toegangsrechten en verwijderregels samen vast, rekening houdend met toepasselijke eisen voor persoonsgegevens.</p> 05</span>Wat gebeurt er wanneer een incident wordt ontdekt?</h2> Wanneer artikel 26(5) geldt, moet een gebruiksverantwoordelijke die een ernstig incident vaststelt onmiddellijk de aanbieder informeren, vervolgens de importeur of distributeur en de relevante markttoezichtautoriteiten. Is de aanbieder niet bereikbaar, dan geldt artikel 73 met de nodige aanpassingen voor de gebruiksverantwoordelijke.</p> Bij een risico zoals genoemd in artikel 26(5) omvat de plicht het zonder onnodige vertraging informeren van de relevante partijen en het opschorten van gebruik. Niet elke onjuiste output is juridisch een ernstig incident. Het team heeft wel een route nodig om dat direct te beoordelen, zonder op de maandelijkse review te wachten.</p> Artikel 73</a> bevat vooral de meldingsplichten van de aanbieder. De algemene uiterste termijn is 15 dagen na kennisname, met kortere termijnen van tien dagen bij overlijden en twee dagen bij een wijdverbreide inbreuk of de genoemde ernstige verstoring van kritieke infrastructuur. Deze termijnen staan naast plichten om bij de relevante trigger onmiddellijk te melden. Ze geven een gebruiksverantwoordelijke geen toestemming om met een melding onder artikel 26 te wachten.</p> Het materiaal van de Commissie over incidentmeldingen omvat conceptrichtlijnen</a>. Baseer de incidentprocedure op de wettelijke triggers en controleer de status van richtlijnen voordat je erop vertrouwt.</p> Spreek vóór de lancering af wie een waarschuwing ontvangt, wie het systeem kan opschorten, hoe de aanbieder wordt bereikt en wie verplichte meldingen doet. Test die route. Logs kunnen vaststellen wat er gebeurde, maar nemen niet zelfstandig contact op met de juiste mensen.</p> Artikel 86</a> geeft getroffen personen onder bepaalde omstandigheden recht op een duidelijke en betekenisvolle uitleg. Het gaat om beslissingen op basis van output van high-risksystemen uit Bijlage III, behalve kritieke infrastructuur, met juridische of vergelijkbaar aanzienlijke gevolgen die volgens de persoon nadelig zijn voor gezondheid, veiligheid of grondrechten.</p> De uitleg moet de rol van het AI-systeem en de belangrijkste elementen van de beslissing omvatten. De bepaling kent uitzonderingen en geldt alleen voor zover dat recht niet al uit ander EU-recht volgt.</p> Artikel 86 is niet uitdrukkelijk opgenomen in het uitstel van Hoofdstuk III, Afdelingen 1 tot en met 3. Alleen op basis van die wijziging blijft de algemene datum van 2 augustus 2026 dus staan. Hoe de bepaling samenwerkt met uitgestelde classificatieregels en overgangsrecht moet per systeem worden beoordeeld. Neem niet aan dat de latere datum voor artikel 26 ook elke uitlegplicht uitstelt.</p> Bewaar operationeel de informatie die nodig is om de beslissing uit te leggen: relevante feiten, criteria, systeemoutput en menselijke betrokkenheid. Een technisch eventlog kan helpen dat bewijs te vinden, maar is niet vanzelf een betekenisvolle uitleg voor de getroffen persoon.</p> Wat aantoonbaar moet zijn</h3> Eén agentrol · zes controles</p> Doel en rollen.</b>Waarvoor de agent wordt gebruikt, de classificatie en wie hem aanbiedt en inzet.</span></li> Menselijke controle.</b>Wie toezicht houdt, welke training die persoon kreeg en welke bevoegdheid er is om in te grijpen.</span></li> De case.</b>Wat in een specifieke case gebeurde, welke controles liepen en wat een mens goedkeurde of wijzigde.</span></li> Informatie en beoordelingen.</b>Welke vereist waren en of ze zijn afgerond.</span></li> Incidenten.</b>Wat gebeurde nadat een risico of incident werd ontdekt, inclusief opschorting en meldingen waar nodig.</span></li> Wijzigingen.</b>Wat veranderde in het systeem of doel en wat vóór inwerkingtreding is beoordeeld.</span></li> </ol> </div> Dit is een operationele checklist, geen claim dat de wet één standaardbestand met alle zes onderdelen eist. Sommige records horen bij het agentplatform, andere bij de proceseigenaar of teams voor HR, privacy en legal.</p> Hier past het werk van Aitonomy. De Scan</a> en ons team stellen het beoogde werk, de betrokken systemen en gaten in het bewijs vast. Waar classificatie of een gewijzigde juridische rol moet worden beoordeeld, bereiden we de technische en operationele informatie voor de klant en adviseurs voor.</p> In productie bewaart Aitonomy Control het operationele bewijs: agentactiviteit, goedkeuringen, controles en de historie van wijzigingen en supervision-beslissingen. Ons team gebruikt die vastlegging om problemen te onderzoeken en beslissingen voor te leggen aan de verantwoordelijke proceseigenaar. De supervision levels</a> bepalen hoe bevoegdheid wordt verdiend en verlaagd. Ze ondersteunen menselijke controle, maar vervangen artikel 26 niet.</p> Control voert niet zelfstandig een effectbeoordeling uit, informeert geen werknemers en bepaalt niet of een configuratie iemand tot aanbieder maakt. Ook vereiste logs, toegang en bewaartermijnen moeten voor de daadwerkelijke inzet worden gecontroleerd. Wijs die verantwoordelijkheden toe; neem niet aan dat de aankoop van een platform ze afdekt.</p> Begin bij de agent die jullie al runnen of overwegen. Leg het doel en de rollen van partijen vast, bepaal welke plichten gelden en test of de verantwoordelijke mensen het bewijs kunnen vinden en erop kunnen handelen. Dat werk is al vóór een deadline nuttig, omdat het ook nodig is om een agent verantwoord in productie te runnen</a>.</p> Veelgestelde vragen</h2> Geldt de EU AI Act ook voor een organisatie die AI alleen gebruikt?+</span></summary> Ja, als de organisatie en het gebruik binnen de reikwijdte van de wet vallen. AI onder eigen verantwoordelijkheid gebruiken maakt je doorgaans gebruiksverantwoordelijke. AI-geletterdheid, verboden en relevante transparantieplichten gelden al. De aanvullende plichten uit artikel 26 gaan over high-risksystemen en hebben eigen ingangsdata en overgangsregels.</div> </details> Kan een organisatie zowel AI-aanbieder als gebruiksverantwoordelijke zijn?+</span></summary> Ja. De rollen hangen af van systeem en activiteit. Een organisatie kan het systeem van een leverancier gebruiken en een ander systeem onder eigen naam aanbieden. Ontwikkeling laten uitvoeren, een high-risksysteem onder eigen merk brengen of het doel wijzigen kan de analyse veranderen. De aankoop van een platform bepaalt de rol niet.</div> </details> Zijn AI-agents automatisch high-risk onder de AI Act?+</span></summary> Nee. De classificatie hangt af van het beoogde doel en de voorwaarden uit artikel 6, niet van het label agent of het autonomieniveau</a>. Sollicitantenscreening en bepaalde krediet- of verzekeringstoepassingen staan in Bijlage III. Routinematige factuurmatching meestal niet, alleen op basis van die omschrijving. Menselijke goedkeuring neemt de high-riskstatus niet automatisch weg.</div> </details> Welke plichten voor gebruiksverantwoordelijken zijn uitgesteld?+</span></summary> De relevante plichten uit Hoofdstuk III, Afdelingen 1 tot en met 3, waaronder artikel 26, gelden vanaf 2 december 2027 voor high-risksystemen uit Bijlage III en vanaf 2 augustus 2028 voor artikel 6(1)- en Bijlage I-systemen, met overgangsregels. Het uitstel geldt in het algemeen niet voor AI-geletterdheid, bestaande verboden of transparantieplichten uit artikel 50.</div> </details> Hoelang moet een gebruiksverantwoordelijke AI-systeemlogs bewaren?+</span></summary> Wanneer artikel 26(6) geldt, moeten automatisch gegenereerde logs onder controle van de gebruiksverantwoordelijke passend en minstens zes maanden worden bewaard, tenzij toepasselijk EU- of nationaal recht anders bepaalt. Dit is een bewaartermijn, geen eis om vóór ingang van de plicht al zes maanden historie te hebben.</div> </details> </div> Bronnen en reikwijdte</h4> Regulation (EU) 2024/1689, the Artificial Intelligence Act</a>, as amended by Regulation (EU) 2026/1744</a>.</li> Council of the EU, adopted Digital Omnibus text</a>, particularly the amendments to Articles 4, 25, 27, 111 and 113, and its adoption announcement</a>.</li> European Commission AI Act Service Desk, the article texts linked above. Some pages carry an explicit warning that they have not yet incorporated the Omnibus amendments; those passages must be read with the amending text.</li> European Commission, AI literacy questions and answers</a> and draft serious-incident reporting guidance</a>.</li> Sources checked 4 September 2026. This is an operational guide, not legal advice or an exhaustive compliance checklist. Application to a particular system depends on its purpose, the parties’ roles, transitional provisions and other applicable law. The interpretation of Article 86’s timing is identified separately above.</li> </ul> </div> </div> </article> Autonomie moet je verdienen: supervision levels voor agents in productie Mik Nijhuis — Tue, 01 Sep 2026 00:00:00 +0000 Het gebruikelijke advies klopt voor zover het gaat. Laat een agent beginnen met intensieve review. Verruim wat hij mag doen zodra hij zich bewijst. Houd een mens verantwoordelijk voor de uitkomst. We schreven zelf een versie daarvan en stelden dat bewijs autonomie moet kunnen verlagen én verhogen</a>, zonder uit te werken wat dat in de praktijk betekent.</p> Dat werken we hier uit. Niet de exacte cijfers, die horen in beleid dat we met een specifieke klant vastleggen, maar de opzet: welke niveaus er zijn, hoeveel reviewtijd elk niveau kost, welk bewijs een agent laat bewegen en wat autonomie terugneemt zonder te wachten tot iemand het opmerkt.</p> Een supervision level voor een AI-agent bepaalt wat de agent mag doen, hoeveel van zijn werk een mens moet beoordelen en welk bewijs de autonomie kan verhogen of verlagen.</p> Dat autonomie in stappen moet worden toegekend en niet simpelweg aangezet. Dat inzicht is niet nieuw. Thomas Sheridan en William Verplank beschreven in 1978</b> al een tienpuntsschaal voor menselijke controle</a>. Die loopt van een mens die alles zonder hulp doet, via een machine die opties beperkt en er één voorstelt, tot een machine die handelt zonder iemand te informeren. Later werk van Parasuraman, Sheridan en Wickens verdeelde automatisering in vier functies</a>: informatie verzamelen, interpreteren, een handeling kiezen en die uitvoeren.</p> Een ladder met gradaties bestaat dus al bijna vijftig jaar. Huidige richtlijnen over agents en hun operationele loops</a> komen uit bij hetzelfde brede principe: autonomie moet stapsgewijs toenemen. De discussie gaat niet over de ladder.</p> Die gaat over de treden. Veel voorgestelde promotiecriteria zijn kwalitatief: het correctiepercentage wordt acceptabel, de uitzonderingslijst stabiliseert, reviewers veranderen steeds minder. Ze beschrijven een gevoel over de agent. Iemand die niet bij het gesprek was, kan ze niet controleren. Later auditen kan dus evenmin. Daarmee beslist uiteindelijk degene die in de vergadering het meeste vertrouwen uitstraalt of de scope wordt verruimd.</p> Raja Parasuraman en Dietrich Manzey beoordeelden het empirische onderzoek hierover in 2010 in Human Factors</a>. Hun bevindingen zijn ongemakkelijk als een mens die output controleert de enige control is. Automation complacency komt voor bij experts én beginners en verdwijnt niet door simpelweg te oefenen. Training of instructies voorkomen automation bias niet betrouwbaar. Het veroorzaakt beide soorten fouten: accepteren wat de machine fout deed en missen wat de machine nooit signaleerde.</p> Een eerder experiment laat het onderliggende effect zien. In een gesimuleerde vliegtaak uit 1999</a> presteerden deelnemers zonder geautomatiseerd hulpmiddel beter op monitoring dan deelnemers met een zeer, maar niet volledig betrouwbare tool. De groep met ondersteuning maakte omissiefouten wanneer de automatisering een gebeurtenis niet markeerde, en commissiefouten wanneer ze een slecht advies volgden terwijl andere geldige informatie beschikbaar was.</p> Dit onderzoek stamt van vóór AI-agents in productie en gaat over geautomatiseerde beslisondersteuning, grotendeels in de luchtvaart. Het stelt geen foutpercentage voor agentreview vast. Het laat wel zien waarom menselijke review niet de enige control moet zijn: aandacht is begrensd en betrouwbare automatisering verandert waar mensen die aandacht aan besteden.</p> Menselijke review blijft nodig. Het reviewpercentage, de steekproef en de escalatieregels moeten structureel zijn. Leg in beleid vast hoeveel van de agentoutput een mens moet zien en laat het systeem dat afdwingen. Laat het niet afhangen van het oordeel van de reviewer op die dag.</p> 03</span>Wat zijn de drie niveaus?</h2> Elke agent die we runnen staat op een van drie niveaus. Het niveau is een instelling in Aitonomy Control. Iedereen met toegang ziet op welk niveau een agent vandaag staat en welk bewijs hem daar heeft gebracht.</p> </th> Wat de agent doet</th> Wat een mens doet</th></tr> </thead> Suggests</th> Doet een aanbeveling en verandert niets</td> Beoordeelt elk resultaat inhoudelijk en voert de handeling uit of keurt die goed</td></tr> Drafts</th> Rondt het werk af en zet de handeling klaar</td> Keurt elke handeling goed, met gerichte review van uitzonderingen en geselecteerde details</td></tr> Auto</th> Rondt afgesproken routinecases af en handelt binnen de scope</td> Beoordeelt een steekproef en elke escalatie, en kan de agent pauzeren</td></tr> </tbody> </table> </div> Elke agent begint bij Suggests. Er is geen versnelde route voor een proces waar iemand veel vertrouwen in heeft. Een agent begint ook niet bij Auto omdat een vergelijkbare agent elders dat niveau heeft verdiend.</p> De derde kolom is de belangrijkste. Een niveau is een afspraak over hoeveel menselijke aandacht het werk verbruikt. Dat maakt het onderdeel van de operationele kosten</a> én van de controls. Een agent van Suggests naar Drafts verplaatsen kan tijd vrijmaken, mits goedkeuring minder inspanning kost dan het oorspronkelijke werk en de vrijgekomen capaciteit wordt benut. Daarom verruimen we een niveau nooit achteloos.</p> 04</span>Wat laat een agent een niveau stijgen?</h2> Vijf soorten bewijs, in een vaste combinatie. Control meet ze alle vijf voortdurend aan drempels die vóór de eerste run zijn vastgesteld.</p> Tijd op het huidige niveau.</b> Lang genoeg om de variatie van het proces zichtbaar te maken, ook in delen van de maand of het kwartaal die anders verlopen.</p> Volume.</b> Genoeg afgeronde cases om de interventiegraad betekenis te geven. Een handvol foutloze resultaten is geen bewijs.</p> Interventiegraad.</b> Het aandeel van de agentoutput dat een mens wijzigde voordat het effect kreeg. Dat aandeel moet dalen en onder de norm van het niveau blijven.</p> Blijvende kwaliteit.</b> Het aandeel dat na de afgesproken periode nog standhoudt. Dat is een ander cijfer dan het aandeel dat op de dag zelf werd geaccepteerd. Het verschil tussen beide</a> is werk dat iemand opnieuw opende, corrigeerde of terugdraaide. Een agent die alleen op acceptatie van dag één promoveert, promoveert op het verkeerde signaal.</p> Geen kritieke fouten.</b> Een kritieke fout is een uitkomst die een vooraf bepaalde grens voor die agent overschrijdt. Het beleid beschrijft welke uitkomsten hieronder vallen, welk bewijs nodig is en wie een fout mag vastleggen. Tijdens de kwalificatieperiode mag er geen optreden.</p> We beginnen met standaardbeleid en spreken de drempels per agent af. Daarna laden we ze in Control, zodat altijd het afgesproken getal wordt afgedwongen. Ook een processpecifieke afwijking wordt daar geconfigureerd, met de reden erbij. De cijfers blijven in het ondertekende beleid. De juiste drempel voor factuurmatching is niet de juiste drempel voor werk waarbij fouten een klant bereiken. Wat niet varieert: de drempels staan vast vóór de agent draait en blijven de maatstaf voor latere beoordeling.</p> Waarom je ze vooraf vastlegt</p> Een drempel die je afspreekt nadat de resultaten binnen zijn, is geen drempel. Als het getal kan meebewegen met het bewijs, verliest het bewijs zijn functie. De promotiebeslissing ligt dan stilletjes weer bij degene met het meeste zelfvertrouwen in de vergadering.</p> </div> 05</span>Wat zet de agent weer een niveau lager?</h2> Dezelfde cijfers. Een ladder die alleen omhooggaat, beschrijft een lancering. De weg omlaag maakt het supervision. Juist die blijft vaak onbeschreven.</p> Een kritieke fout verlaagt het niveau direct.</b> Zodra een fout volgens de afgesproken definitie is vastgelegd, verlaagt Control het niveau. Eén fout is genoeg. Het systeem wacht niet op de maandelijkse review en weegt de fout niet af tegen hoe goed de agent verder draaide.</p> Een stijgende interventiegraad bevriest de scope.</b> Dat is op zichzelf geen verlaging, maar de agent breidt niet verder uit totdat de oorzaak bekend is. De scope groeit niet terwijl mensen steeds vaker corrigeren.</p> Een modelwijziging stuurt de agent terug naar de testset.</b> Een ander model maakt het bewijs bij de vorige configuratie ongeldig totdat de apart gehouden cases opnieuw zijn gedraaid. De agent behoudt zijn niveau alleen als de nieuwe configuratie dezelfde norm haalt.</p> Control voert de geconfigureerde reactie uit zodra het bewijs aan een van deze voorwaarden voldoet. Het systeem vertrouwt er niet op dat een reviewer tijdens routinegoedkeuring afwijkingen opmerkt. Dan zou juist de zwakte terugkeren die de niveaus moeten verkleinen.</p> In Aitonomy Control. Daar staan voor elke agent het huidige niveau, het onderliggende bewijs, de afgedwongen drempels en de beslisgeschiedenis. Een mens keurt een stijging goed. Bereikt het vastgelegde bewijs een geconfigureerde verlagingsvoorwaarde, dan bevriest of verlaagt Control de autonomie zonder op de maandelijkse review te wachten. Zo ontstaat een traceerbare operationele vastlegging</a> die een auditor of toezichthouder kan beoordelen, geen reconstructie achteraf.</p> Elke agent krijgt maandelijks een besluit: verruimen, behouden, terugzetten of stoppen. Het bewijs ligt al klaar. De vergadering gaat dus over het oordeel, niet over het verzamelen van de onderbouwing. Behouden hoort een normale uitkomst te zijn. Als elke agent in een portfolio wordt verruimd, moet je je afvragen of de interventiegraad en blijvende kwaliteit wel genoeg gewicht krijgen.</p> Met een korte toets zie je of dit binnen een organisatie werkelijk bestaat. Toegang tot het systeem is niet nodig. Vraag wanneer een agent voor het laatst een niveau omlaag ging. Vraag wie daartoe bevoegd is en of die persoon daarvoor toestemming nodig heeft. Kan niemand uitleggen hoe een verlaging werkt of heeft niemand de bevoegdheid, dan zijn de niveaus slechts labels.</p> Een agent wordt niet betrouwbaar doordat hij al een tijd draait. Betrouwbaarheid ontstaat doordat de agent bewijs levert tegen een norm die is vastgesteld vóór iemand wist of hij die zou halen. En doordat dezelfde norm dat vertrouwen ook weer kan terugnemen.</p> Veelgestelde vragen</h2> Wat zijn supervision levels voor AI-agents?+</span></summary> Ze bepalen hoeveel van het werk van een agent door een mens moet worden beoordeeld. Bij Suggests beveelt de agent een handeling aan maar verandert niets. Bij Drafts rondt hij het werk af en wacht op goedkeuring. Bij Auto handelt hij binnen de goedgekeurde scope, terwijl escalaties en een steekproef nog steeds worden beoordeeld.</div> </details> Hoe verdient een AI-agent meer autonomie?+</span></summary> Door drempels te halen die vooraf zijn vastgesteld. Het bewijs omvat tijd en volume op het huidige niveau, de menselijke interventiegraad, of resultaten na een afgesproken periode standhouden en of er kritieke fouten optraden. Elke agent begint op het niveau met de meeste review.</div> </details> Kan menselijke review elke fout van een AI-agent onderscheppen?+</span></summary> Nee. Mensen worden minder alert wanneer een geautomatiseerd systeem meestal gelijk heeft. Dit goed gedocumenteerde effect heet automation complacency. Menselijke review blijft nodig, maar mag niet de enige control zijn. Reviewpercentages, escalatieregels, automatische controles en een leesbare vastlegging van wat de agent deed</a> moeten in het operationele model zijn ingebouwd.</div> </details> Wanneer moet een AI-agent autonomie verliezen?+</span></summary> Een kritieke fout moet de autonomie direct verlagen en de vereiste review verhogen. Een stijgende interventiegraad stopt elke uitbreiding tot de oorzaak bekend is. Een modelwijziging leidt tot nieuwe tests voordat de agent zijn bestaande niveau behoudt. Deze regels horen bij een agent in productie runnen</a> en moeten worden afgedwongen, niet aan iemands geheugen worden overgelaten.</div> </details> </div> Bronnen</h4> Thomas Sheridan and William Verplank, Human and Computer Control of Undersea Teleoperators</a>, MIT Man-Machine Systems Laboratory (1978), the ten-point scale of human supervisory control that later levels-of-automation work is built on</li> Raja Parasuraman, Thomas Sheridan and Christopher Wickens, A Model for Types and Levels of Human Interaction with Automation</a>, IEEE Transactions on Systems, Man, and Cybernetics</i> 30:3 (2000), separating automation into information acquisition, analysis, decision selection and action implementation</li> Linda Skitka, Kathleen Mosier and Mark Burdick, Does Automation Bias Decision-Making?</a>, International Journal of Human-Computer Studies</i> 51:5 (1999), comparing monitoring with and without a highly but imperfectly reliable automated aid</li> Raja Parasuraman and Dietrich Manzey, Complacency and Bias in Human Use of Automation: An Attentional Integration</a>, Human Factors</i> 52:3 (2010), reviewing automation complacency, automation bias and the limits of practice, training and instructions</li> De drie niveaus, het bewijs voor verhoging en de regels voor verlaging zijn van Aitonomy zelf. Ze komen uit het autonomiebeleid dat we per agent ondertekenen en in Aitonomy Control afdwingen. De drempels zelf staan in dat beleid en publiceren we hier niet.</li> </ul> </div> </div> </article> Zo bouw je de businesscase voor een AI-agent Joep — Wed, 26 Aug 2026 00:00:00 +0000 De meeste adviezen over AI-businesscases richten zich op de presentatie van de uitkomst: vertaal voordelen naar geld, toon een bandbreedte en bereken de terugverdientijd. Dat telt, maar veronderstelt dat de onderliggende cijfers kloppen.</p> Een businesscase voor een AI-agent vergelijkt na met voor. Begin met één proces en leg het huidige volume, de inspanning, kwaliteit, wachttijd en kosten vast. Schat vervolgens welk deel van die inspanning bij een agent past</a>, trek review- en operationele kosten af, benoem of de uitkomst cash, vermeden kosten of vrijgekomen capaciteit is en maak één vaste eigenaar verantwoordelijk.</p> Houd elke schatting zichtbaar. Na go-live gebruik je dezelfde case om te toetsen of de agent de investering waard was.</p> Voor McKinsey’s State of AI</a>-onderzoek, gepubliceerd in augustus 2026, reageerden 1.719 deelnemers. 80 procent zei dat AI hun individuele productiviteit had verbeterd. 37 procent schreef minstens enig effect op het bedrijfsresultaat vóór rente en belasting toe aan AI. Zes procent voldeed aan McKinsey’s veel hogere norm voor een AI high performer: minstens 5 procent van de EBIT toegeschreven aan AI én naar eigen zeggen aanzienlijke impact.</p> Die cijfers spreken elkaar niet tegen. Ze meten individuele ervaring, enige financiële impact op organisatieniveau en een veeleisende prestatiedrempel. Wie ze samenvoegt tot één succespercentage, verwijdert precies het onderscheid dat een businesscase nodig heeft: wat veranderde, voor wie en ten opzichte van welk vertrekpunt?</p> Gartner voorspelt</a> dat eind 2027 meer dan 40 procent van de agentic-AI-projecten is stopgezet. Genoemde redenen zijn oplopende kosten, onduidelijke bedrijfswaarde en gebrekkige risicocontroles. Elk daarvan hoort vóór de bouw in de case.</p> Een onderzoek uit 2026 in California Management Review</a> onder 24 professionals vond een vergelijkbaar patroon. Tien noemden het ontbreken van een succesmaatstaf vóór aankoop als grootste belemmering voor het meten van financiële impact. Slechts twee gebruikten een controlegroep of A/B-test. Zestien vertrouwden op zelfgerapporteerde tijdwinst, terwijl maar negen werkelijk vertrouwen hadden in dat bewijs.</p> Je kunt verbetering niet meten aan een doel dat niet bestaat. Mahboubeh Cheraghian</b> · California Management Review</a>, August 2026</cite> </blockquote> De steekproef was klein en doelgericht en onderzocht AI op de werkvloer, niet agents in productie. Ze kan dus geen algemeen percentage vaststellen. Wel illustreert ze het meetprobleem dat een businesscase moet oplossen.</p> 02</span>Wat is een nulmeting?</h2> Een nulmeting legt vast hoe het werk presteert voordat het operationele model verandert. De periode moet lang genoeg zijn om normale variatie te omvatten. Bij seizoensgebonden vraag kan dat een volledige cyclus zijn. Bij stabiel werk met veel volume kan een kortere periode volstaan.</p> De nuttige maatstaven hangen af van de geclaimde waarde. Meestal omvatten ze volume, behandelinspanning, doorlooptijd, ouderdom van de wachtrij, herstelwerk, afwijzingen, uitzonderingen, escalaties en de kosten van betrokken mensen en systemen. Alleen gemiddelden zijn zelden genoeg. Als de moeilijkste 20 procent van de cases de helft van de inspanning vraagt, verbergt de gemiddelde behandeltijd juist het werk dat overblijft.</p> Ook de uurkosten bepalen wat het getal betekent. Een volledig kostentarief kan een capaciteitsequivalent voordeel beschrijven, maar bewijst geen cashbesparing. Het onderscheid tussen cash, vermeden kosten en vrijgekomen capaciteit bepaalt wat de case werkelijk mag claimen.</p> Bij de meeste organisaties ontbreken enkele van deze maatstaven. De case kan nog steeds worden gebouwd, zolang duidelijk is welke cijfers op bewijs rusten en welke aannames blijven.</p> </th> Gemeten nulmeting</th> Gemodelleerde nulmeting</th></tr> </thead> Vertrekt vanuit</th> De eigen vastgelegde historie van de organisatie</td> Beschikbare records plus een benchmark of expliciete aanname</td></tr> Beantwoordt</th> Wat het werk aantoonbaar deed</td> Wat het werk waarschijnlijk deed, binnen een aangegeven bandbreedte</td></tr> Bevat</th> Grenzen aan datakwaliteit en normale variatie</td> Aannames, bandbreedtes en een betrouwbaarheidsniveau</td></tr> Faalt wanneer</th> Onvolledige records als volledig worden behandeld</td> Een schatting als meting wordt gepresenteerd</td></tr> </tbody> </table> </div> Na go-live kan een historische nulmeting soms nog worden hersteld, maar mogelijk is die niet meer vergelijkbaar. Proces, volumes, team en gedrag kunnen al zijn veranderd. De nulmeting vooraf vastleggen verkleint hindsight bias en bewaart de omstandigheden waaronder de beslissing is genomen.</p> Onze vaste regel</p> Een eerlijk gelabelde gemodelleerde nulmeting is beter dan een verzonnen nulmeting die stilzwijgend als feit geldt. Laat het label staan wanneer het getal opnieuw wordt gebruikt. Wordt een schatting later door een meting vervangen, dan moet de vastlegging tonen</a> wat veranderde en waarom.</p> </div> De andere vijf velden hangen af van de nulmeting.</b> Dit is ook het enige veld dat je op twee manieren kunt bepalen. Daarom legt de pagina vast welke route is gebruikt.</figcaption> </figure> Het werk en de bedrijfsuitkomst.</b> Het operationele probleem, het gewenste resultaat en de grens van de voorgestelde verantwoordelijkheid van de agent. Begin bij de uitkomst en bepaal daarna wat bij mensen, een agent en bestaande automatisering hoort.</p> Kwaliteit en gevolgen.</b> De norm waaraan het werk moet voldoen, wat er gebeurt als het fout is en waar menselijke goedkeuring of escalatie nodig blijft</a>.</p> De nulmeting.</b> Huidig volume, inspanning, kwaliteit, wachttijd en kosten. Elk belangrijk getal krijgt het label gemeten of gemodelleerd, met periode en bron.</p> Investering en operationele kosten.</b> Bouw en integratie, plus de doorlopende kosten: model- en toolgebruik, menselijke review, uitzonderingsafhandeling, monitoring, governance, onderhoud, procesverandering en de kosten van stoppen of fouten herstellen.</p> Het doel en meetplan.</b> De primaire uitkomst die moet verbeteren, de verwachte bandbreedte, hoe het effect wordt toegeschreven en welk bewijs nodig is om door te gaan, de scope te verkleinen of te stoppen. Waar het proces dit toelaat, is een gefaseerde uitrol, matched comparison of holdout sterker dan een simpele voor-en-nameting.</p> De benoemde eigenaar en het conversieplan.</b> Eén persoon bij de klant is verantwoordelijk voor het resultaat en bepaalt wat vrijgekomen capaciteit wordt. Een afdeling kan geen tijd herverdelen en geen verantwoording afleggen voor een gemist doel.</p> Kosten, verwachte waarde en beslismoment moeten samen leesbaar zijn. Het doel beschrijft hoe het wordt gemeten. Elke capaciteitsclaim legt uit hoe de vrijgekomen tijd wordt gebruikt.</p> 04</span>Waarom overschat theoretische capaciteit de waarde?</h2> Theoretische capaciteit wordt meestal berekend als volume maal gemiddelde behandeltijd maal het aandeel cases dat een agent kan overnemen. Dat geeft een bruikbaar plafond, niet het verwachte voordeel. Voor een bruikbare schatting zijn drie verdere correcties nodig.</p> Dekking moet naar inspanning worden gewogen.</b> Agents beginnen vaak met het werk dat het eenvoudigst te herkennen en controleren is. Daarmee kan een groot aandeel van de cases verdwijnen, terwijl een veel groter aandeel van de inspanning blijft.</p> Crediteurenadministratie biedt een bruikbaar voorbeeld. De benchmark van Ardent Partners uit 2025, gepubliceerd door Medius</a>, rapporteert gemiddeld 22 procent factuuruitzonderingen. Voor de berekening hieronder nemen we aan dat een uitzondering vier keer zoveel inspanning vraagt als een factuur die rechtstreeks wordt verwerkt.</p> </th> Rechtstreeks verwerkt</th> Uitzonderingen</th></tr> </thead> Aandeel cases</th> 78 procent</td> 22 procent</td></tr> Aangenomen relatieve inspanning per case</th> 1</td> 4</td></tr> Aandeel totale inspanning</th> 47 procent</b></td> 53 procent</b></td></tr> </tbody> </table> </div> In dit vereenvoudigde voorbeeld verwijdert het overnemen van alle rechtstreekse facturen 78 procent van het volume, maar slechts 47 procent van de inspanning. De factor vier is illustratief en geen bevinding van Ardent Partners. Gebruik voor een echte case de eigen behandeldata.</p> Review en restwerk blijven bestaan.</b> Een mens moet mogelijk nog resultaten controleren, uitzonderingen afhandelen en genoeg context behouden om in te grijpen. Bainbridge beschreef dit operationele probleem in Ironies of Automation</a>: routinewerk automatiseren kan mensen achterlaten met afwijkende situaties én een nieuwe monitoringtaak. Zij schreef over industriële automatisering, niet over AI-agents, maar dezelfde workloadvraag hoort in deze case. Menselijke controle kost tijd en die tijd moet worden gemeten.</p> Vrijgekomen capaciteit moet bruikbaar zijn.</b> Dertig minuten uit één wachtrij halen kan de service direct verbeteren. Twee minuten verspreid over vijftien mensen worden mogelijk nooit cash of extra output. De businesscase moet zeggen welke uitkomst wordt verwacht.</p> Customer support geeft nog een voorbeeld. Een deflected case eindigde zonder een mens te bereiken. Een resolved case eindigde omdat het probleem van de klant was opgelost. Beide als dezelfde uitkomst tellen, maakt van een systeemevent een waardeclaim zonder te controleren wat er werkelijk gebeurde.</p> 05</span>Met welk getal moet je plannen?</h2> Gebruik het beschikbare bewijs om een bandbreedte te plannen, in plaats van te beginnen met een universele kortingsfactor.</p> Potentieel vrijgekomen capaciteit</p> Huidig casevolume × huidige inspanning × naar inspanning gewogen dekking</b>, minus review, herstelwerk en resterende inspanning voor uitzonderingen.</p> </div> Classificeer daarna de uitkomst. De vier regels zijn niet onderling uitwisselbaar.</p> Classificatie</th> Wat de case mag meetellen</th></tr> </thead> Cashbesparing</th> Uitgaven die werkelijk uit de kostenbasis verdwijnen</td></tr> Vermeden kosten</th> Een specifieke hire, contractor of dienst die niet langer nodig is</td></tr> Vrijgekomen capaciteit</th> Capaciteitsequivalente uren, los van cash totdat ze een gemeten uitkomst opleveren</td></tr> Operationele waarde</th> Verbetering van kwaliteit, beschikbaarheid, output of risico, met een eigen nulmeting</td></tr> </tbody> </table> </div> Trek ten slotte de volledige eigendomskosten af: bouw, integratie, gebruik, review, control, onderhoud en verandering. Is een belangrijke input onbekend, toon die dan als bandbreedte en maak het verkleinen daarvan een beslismoment.</p> Workday’s onderzoek uit januari 2026</a> laat zien waarom review in de berekening hoort. In een enquête onder 3.200 actieve AI-gebruikers op de werkvloer ging bijna 40 procent van de gerapporteerde tijdwinst terug naar herstelwerk. Slechts 14 procent meldde consequent een duidelijk positief nettoresultaat. Het bewijs is zelfgerapporteerd en gaat niet over productie-agents. Het levert dus geen kortingsfactor voor een specifiek proces, maar toont wel het risico van bruto tijdwinst als waarde behandelen zonder het herstelwerk te bekijken.</p> Laat in de lage, verwachte en hoge scenario's de aannames variëren die ertoe doen: naar inspanning gewogen dekking, verificatiekosten, uitzonderingslast, operationele kosten en het aandeel capaciteit dat kan worden omgezet. Gebruik scenario's om onzekerheid zichtbaar te maken, niet om dezelfde ongefundeerde schatting drie labels te geven.</p> Is de bandbreedte te groot voor een beslissing, meet dan vóór de bouw wat ontbreekt. Afhankelijk van de uitkomst moet de voorgestelde rol mogelijk worden verkleind of gestopt.</p> 06</span>Wat als de waarde niet in uren zit?</h2> Uren worden vaak gebruikt omdat ze gemakkelijk te tellen zijn, maar vormen lang niet altijd de sterkste waardemaatstaf.</p> Kwaliteit.</b> Bij een meetbaar fout- of herstelpercentage kan waarde ontstaan door minder correcties, creditnota's, klachten of heropende cases. Een agent kan een regel consistenter toepassen. Behandel dat als een te bewijzen doel, niet als gegarandeerde eigenschap.</p> Beschikbaarheid.</b> Werk dat een nacht of in een wachtrij blijft liggen, heeft servicekosten. De nulmeting bestaat uit wachtrijleeftijd, tijd tot eerste reactie en het aandeel cases dat een serviceniveau overschrijdt. Meet het resultaat in doorlooptijd en serviceprestatie, niet automatisch in headcount.</p> Capaciteit zonder nieuwe mensen.</b> Bij groeiende vraag kan het handhaven van het serviceniveau terwijl het volume stijgt een geplande hire of externe dienst voorkomen. De case heeft de volumetrend, de personeelstrigger en het moment nodig waarop de uitgave anders zou ontstaan.</p> Het werk dat overblijft.</b> Routineadministratie wegnemen kan mensen meer ruimte geven voor uitzonderingen en afwegingen. Dat is pas waardevol wanneer de organisatie benoemt waar die tijd naartoe gaat en meet wat verbetert.</p> Waardelijn</th> Nulmeting</th> Bewijs na go-live</th></tr> </thead> Kwaliteit</th> Fout-, herstel- en afwijzingspercentages</td> Correcties, klachten en creditnota's</td></tr> Beschikbaarheid</th> Wachtrijleeftijd en reactietijd</td> Doorlooptijd en serviceniveau</td></tr> Vermeden hire</th> Volumetrend en personeelstrigger</td> Service behouden zonder de geplande uitgave</td></tr> Restwerk</th> Achterstand, overwerk en leeftijd van uitzonderingen</td> Moeilijke cases sneller of beter afgehandeld</td></tr> </tbody> </table> </div> Snellere afhandeling, vrijgekomen capaciteit en vermeden hires kunnen dezelfde onderliggende verandering beschrijven. Ze apart optellen overschat de case. Kies één primaire financiële claim, behoud de operationele maatstaven die hem bewijzen en ken geen geld toe aan andere verwachte effecten tenzij die onafhankelijk meetbaar zijn.</p> 07</span>Hoe ziet een gemodelleerde nulmeting eruit?</h2> In een geanonimiseerde case was geen gemeten nulmeting van de behandeltijd beschikbaar, terwijl een beslissing nodig was voordat die kon worden gemaakt.</p> We combineerden de vastgelegde volumes met aannames over de behandeltijd in de kandidaatprocessen. De uitkomst was een schatting van ongeveer 5.800 capaciteitsequivalente uren per jaar. We behandelden die als vertrekpunt, niet als besparing.</p> Herinzetbaarheid was de enige factor met steviger bewijs, omdat het bezettingspatroon liet zien hoeveel vrijgekomen tijd realistisch kon worden benut. We stelden dat op ongeveer twee derde. Zo ontstond een verwacht scenario van circa 3.750 capaciteitsequivalente uren.</p> Dekking en verificatie waren nog niet op echte cases gemeten. In plaats van vaste kortingspercentages kreeg de case een bandbreedte van 2.000 tot 6.000 uur. De bovengrens lag iets boven de startsom omdat ook de behandeltijd onzeker bleef. Elk cijfer kreeg het label hypothese.</p> De bandbreedte maakte zichtbaar wat de beoordeling nog moest meten: behandelinspanning per casetype, haalbare dekking op apart gehouden werk en de tijd om een resultaat te controleren. Met elke bevinding werd de bandbreedte kleiner en kon de bouwbeslissing veranderen.</p> Zo maakt een gemodelleerde nulmeting onzekerheid toetsbaar zonder haar als feit te presenteren.</p> 08</span>Hoe blijft de case leven na goedkeuring?</h2> De nulmeting, het doel en het meetplan blijven na go-live aan het werk gekoppeld. Elke rapportageperiode vergelijkt live bewijs met de voorwaarden die vóór de beslissing zijn vastgelegd en voedt de operationele vastlegging</a>.</p> Voor een stabiel proces met veel volume kan een simpele voor-en-navergelijking genoeg zijn. Kunnen seizoenen, bezetting of veranderende vraag het resultaat verklaren, gebruik dan waar mogelijk sterkere attributie: een gefaseerde uitrol, matched team, holdout-wachtrij of gedocumenteerde trendvergelijking.</p> De cijfers mogen veranderen wanneer de werkelijkheid verandert, zolang de wijziging traceerbaar blijft. Worden nulmeting, scope of doel herzien, dan toont de vastlegging de oude waarde, de nieuwe waarde, de reden en wie goedkeurde.</p> Een businesscase moet ruimte laten voor nee. Als het bewijs geen haalbare bandbreedte ondersteunt, de volledige operationele kosten de waarde wegnemen, de gevolgen van falen te groot zijn of niemand eigenaar is, kan eerst voorbereiden, de rol verkleinen of het werk bij mensen laten de juiste beslissing zijn. Anders dan een voorstel moet de case ook een besluit om niet door te gaan ondersteunen.</p> 09</span>Waar passen de Scan en Aitonomy Control?</h2> De Scan en ons team stellen de nulmeting vast vóór de bouwbeslissing. Met goedgekeurde toegang tot de betrokken systemen reconstrueren we het vastgelegde proces, toetsen we de kwaliteit van het bewijs en onderzoeken we de gaten met de mensen die eigenaar zijn van het werk. Samen labelen we wat gemeten is, wat gemodelleerd is en wat nog moet worden bewezen.</p> Het resultaat is een case van één pagina die openstaande aannames toont en vier mogelijke beslissingen ondersteunt.</p> Beslissing</th> Wat die betekent</th></tr> </thead> Bouwen</th> Het bewijs ondersteunt doorgaan met de voorgestelde rol en controls</td></tr> Eerst voorbereiden</th> Kansrijk, maar data, proces, eigenaarschap of controls vragen werk vóór de bouw</td></tr> Scope verkleinen</th> Slechts een deel van de voorgestelde rol is waardevol, haalbaar en veilig genoeg</td></tr> Stoppen</th> De verwachte waarde, haalbaarheid of het risico rechtvaardigt doorgaan niet</td></tr> </tbody> </table> </div> Gaat het werk door, dan levert Aitonomy Control de runtime, monitoring, governance en traceerbaarheid in productie. De operationele vastlegging vergelijkt live prestaties met de afgesproken nulmeting en het doel.</p> Voor een eerste test heb je geen Scan nodig. Neem het proces dat jullie al overwegen en probeer de zes velden in te vullen. Kun je de nulmeting, totale operationele kosten of vaste eigenaar niet invullen, dan weet je waar je moet beginnen. Het bewijs achter die velden produceren is waar wij beginnen</a>.</p> Bouw de businesscase vóór de agent en blijf haar na go-live gebruiken. Alleen dan kun je de verwachte waarde toetsen aan wat werkelijk gebeurde.</p> Veelgestelde vragen</h2> Hoe bereken je de ROI van een AI-agent?+</span></summary> Begin met werk dat geschikt is voor een AI-agent</a> en leg huidig volume, inspanning, kwaliteit, wachttijd en kosten vast. Schat hoeveel inspanning de agent kan overnemen en trek review- en operationele kosten af. Benoem de waarde eerlijk als cashbesparing, vermeden kosten of vrijgekomen capaciteit. Die zijn niet hetzelfde.</div> </details> Wat als er geen data voor een nulmeting is?+</span></summary> Bouw een gemodelleerde nulmeting uit een vergelijkbaar proces, externe benchmark of expliciete aanname en label die duidelijk. Houd aannames zichtbaar, zodat ze kunnen worden betwist en vervangen wanneer echte data beschikbaar komt. Een schatting is bruikbaar als iedereen ziet dat het een schatting is.</div> </details> Waarom kan theoretische tijdwinst de waarde overschatten?+</span></summary> Casevolume en menselijke inspanning zijn niet gelijk verdeeld. Een agent kan veel eenvoudige cases afhandelen terwijl de tragere uitzonderingen bij het team blijven. Zo verdwijnt veel volume zonder dat hetzelfde aandeel werk verdwijnt. Baseer waarde op inspanning die werkelijk verdwijnt of elders bruikbaar wordt.</div> </details> Wat hoort in de businesscase voor een AI-agent?+</span></summary> Zet zes zaken op één pagina: werk en beoogde uitkomst, vereiste kwaliteit en gevolgen van fouten, nulmeting, investering en operationele kosten, doel en meetplan en een vaste eigenaar. Hangt de case af van vrijgekomen capaciteit, zeg dan hoe die wordt gebruikt. Het bewijs moet vier beslissingen ondersteunen: bouwen, eerst voorbereiden, scope verkleinen of stoppen. Bij bouwen blijft de case in gebruik terwijl de agent in productie draait</a>.</div> </details> Is vrijgekomen capaciteit hetzelfde als een kostenbesparing?+</span></summary> Nee. Vrijgekomen capaciteit betekent dat mensen tijd beschikbaar hebben voor ander werk. Het wordt pas een cashbesparing wanneer uitgaven uit de kostenbasis verdwijnen, en vermeden kosten wanneer een geplande hire of uitgave niet meer nodig is. Houd deze drie waardevormen in de case apart.</div> </details> </div> Bronnen</h4> McKinsey & Company, The state of AI in 2026: On the road to ROI</a> (August 2026), a survey of 1,719 participants, on individual productivity, EBIT attribution and the high-performer threshold</li> Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027</a> (June 2025), naming escalating costs, unclear business value and inadequate risk controls</li> Mahboubeh Cheraghian, Beyond AI Licenses: How to Measure Whether Your AI Is Actually Working</a>, California Management Review</i> (August 2026), a structured study of 24 practitioners on measurement barriers and attribution</li> Workday, Beyond Productivity: Measuring the Real Value of AI</a> (January 2026), a survey of 3,200 active workplace AI users, fielded in November 2025</li> Ardent Partners, Accounts Payable Metrics that Matter in 2025</a>, on an average invoice exception rate of 22 percent. The four-times effort multiplier used above is illustrative and is not an Ardent Partners finding</li> Lisanne Bainbridge, Ironies of Automation</a>, Automatica</i> 19:6 (1983), on the residual work and monitoring duty left to people after automation</li> The six-field business case, the measured and modelled baseline labels, and the anonymised example are part of Aitonomy’s Scan method. The example has its organisation, sector and commercial terms removed.</li> </ul> </div> </div> </article> Welk werk is geschikt voor een AI-agent? Joep — Thu, 13 Aug 2026 00:00:00 +0000 Vraag welk werk geschikt is voor een AI-agent en je krijgt meestal hetzelfde antwoord. Herhaalbaar. Veel volume. Duidelijke regels. Digitale input. Een heldere definitie van klaar, met iemand beschikbaar voor uitzonderingen.</p> Dat is allemaal nuttig. Het beschrijft wat een agent kan</a>. Dat is iets anders dan welk werk de moeite waard is om over te dragen. Een proces kan aan de hele lijst voldoen en toch financieel onaantrekkelijk zijn, of meer controle vragen dan de opbrengst rechtvaardigt.</p> Het korte antwoord: werk past wanneer het vaak genoeg terugkeert om te meten, een correct resultaat betaalbaar te controleren is, fouten begrensd of omkeerbaar zijn en een vaste persoon uitzonderingen kan afhandelen. Volume en duidelijke regels bepalen de haalbaarheid. Verificatiekosten en de gevolgen van fouten bepalen of overdracht waarde creëert.</p> 01</span>Wat ziet het gebruikelijke advies goed?</h2> Best veel. De gebruikelijke lijst is een echte filter en verwijdert veel zwakke kandidaten. Werk dat op papier binnenkomt, vier keer per jaar voorkomt of afhangt van regels die niemand kan uitleggen, is moeilijker over te dragen. Daarmee beginnen maakt een toch al onzekere bouw duurder.</p> De beperking is dat de lijst alleen de inputkant beschrijft. Is het werk leesbaar? Is er genoeg volume? Zijn de systemen bereikbaar? De lijst vraagt niet wat het werk kost zodra een agent het uitvoert.</p> Twee aanvullende vragen bepalen dat. Wat kost het om één resultaat te controleren? En wat gebeurt er als een fout resultaat doorglipt? Beide kun je onderzoeken voordat er iets wordt gebouwd.</p> Aanpalend onderzoek naar AI op de werkvloer laat zien hoeveel schijnbare productiviteit daarin kan verdwijnen. Workday ondervroeg in november 2025 3.200 fulltime medewerkers bij organisaties met meer dan 100 miljoen dollar jaaromzet, allemaal actieve AI-gebruikers. De resultaten verschenen in januari 2026</a>. 85 procent meldde een besparing van één tot zeven uur per week. Workday rapporteerde ook:</p> Bijna 40 procent van de tijdwinst door AI gaat verloren aan herstelwerk, zoals fouten corrigeren, content herschrijven en output controleren. Workday</b> · Beyond Productivity</a>, January 2026</cite> </blockquote> Slechts 14 procent van de respondenten rapporteerde consequent een duidelijk positief nettoresultaat. Van de frequente gebruikers zei 77 procent AI-gegenereerd werk minstens zo zorgvuldig te controleren als mensenwerk.</p> Dit is zelfgerapporteerd onderzoek naar AI op de werkvloer, geen meting van agents in productie. Het bewijst niet wat verificatie in een specifiek proces kost. Het laat wel zien waarom die kosten vanaf het begin in de businesscase horen.</p> Een systematische review en meta-analyse</a> uit 2024 van 106 experimenten kwam tot een verwante conclusie. Gemiddeld presteerde de combinatie mens en AI slechter dan de beste van de twee afzonderlijk. Waar mensen beter waren dan AI, hielp de combinatie. Waar AI beter was dan mensen, werkte de combinatie juist nadelig. Het onderzoek ging niet over productie-agents, maar onderstreept hetzelfde punt vanuit een andere hoek: een mens in de loop maakt het resultaat niet automatisch beter.</p> Behandel verificatie daarom als terugkerende operationele kosten, totdat bewijs laat zien dat minder controle verantwoord is. Betere kwaliteit, deterministische controles, gerichtere steekproeven en verdiende autonomie kunnen de benodigde review verminderen. Nauwkeurigheid alleen neemt verantwoordelijkheid niet weg.</p> De nuttige vraag is dus niet of controle verdwijnt. Vraag wat één controle kost, wie die kan uitvoeren en welk bewijs minder controle zou rechtvaardigen.</p> </th> Een factuur aan een order koppelen</th> Zes maanden notities samenvatten</th></tr> </thead> De controle is</th> Komen de drie documenten overeen?</td> Geeft dit het dossier eerlijk weer?</td></tr> Tijd tot zekerheid</th> Seconden</td> Mogelijk even lang als het oorspronkelijke werk</td></tr> Wie kan het doen</th> Iedereen die de regel kent</td> Iemand die het bronmateriaal kent</td></tr> Een fout wordt zichtbaar</th> Direct</td> Wanneer iemand op de samenvatting vertrouwt</td></tr> </tbody> </table> </div> Dezelfde organisatie, dezelfde systemen, vergelijkbaar volume. Een totaal andere economie.</p> De toets is of je een correct antwoord goedkoop kunt herkennen. Is dat zo, dan kan een agent meer werk dragen terwijl een mens zicht houdt op het resultaat. Zo niet, dan kies je tussen uitgebreide review, een beperktere scope of een vertrouwensniveau dat de mogelijke gevolgen misschien niet toelaten.</p> 03</span>Wat gebeurt er als het fout gaat?</h2> De tweede vraag bepaalt hoeveel bewijs nodig is voordat een agent met meer autonomie mag handelen. Het vertrekpunt is niet hoe capabel het model lijkt, maar wat er stukgaat als de output niet klopt.</p> Dit is niet alleen een regelgevingsprincipe. Het vrijwillige AI Risk Management Framework</a> van NIST verbindt het beoogde gebruik, verwachte voordelen, foutkosten, menselijke controle en doorlopende meting aan de beslissing of een systeem überhaupt moet worden ingezet. De EU AI Act</a> past in omschreven gevallen een vergelijkbare risicogebaseerde logica toe als wet. Verplichtingen hangen af van het beoogde doel, de getroffen personen, de rol van elke partij in de waardeketen en de risicoclassificatie. Over het operationele bewijs daarachter schreven we apart in laat zien wat elke agent deed en wie het goedkeurde</a>.</p> Roosterplanning laat zien waarom het detail telt. Een systeem kan onder de high-riskcategorieën voor werk vallen wanneer het beslissingen neemt die arbeidsrelaties beïnvloeden, of taken toewijst op basis van individueel gedrag of persoonlijke kenmerken. Dat maakt niet elke roostertool automatisch high-risk. De classificatie hangt af van het beoogde doel, de invloed op de beslissing en de voorwaarden uit artikel 6.</p> De Scan legt het beoogde gebruik vast, de betrokken data, de beslissingen die de agent beïnvloedt, de geraakte personen en de rol van elke partij. Dat vormt de technische en operationele input voor een classificatie met de klant en diens adviseurs. Het is geen juridisch oordeel van ons.</p> Onze eigen operationele controls kunnen strenger zijn dan het wettelijke minimum. Bij werk met grotere gevolgen kan dat een langere shadowperiode betekenen, alleen concepten laten maken en vaste goedkeuringen vóór go-live. Dat zijn operationele keuzes voor een specifiek proces, geen universele eisen.</p> Dit sluit het proces niet uit. Het maakt vóór de bouwbeslissing wel de kosten en voorwaarden van beheerste inzet zichtbaar.</p> Dat is wat de Scan</a> doet. We reconstrueren het vastgelegde proces, scoren acht gebieden en onderzoeken de gaten met de mensen die het werk bezitten. Het resultaat is niet automatisch een agentvoorstel. Het is een lijst met hiaten en een beslissing: bouwen, eerst voorbereiden, de scope verkleinen of het werk bij mensen laten.</p> Gebied</th> Waar het antwoord begint</th></tr> </thead> Volume</th> Aantallen in eventlogs</td></tr> Geraakte systemen</th> Eventlogs en systeeminventaris</td></tr> Datatoegang</th> Verbindings- en rechtentest</td></tr> Datakwaliteit</th> Steekproef van records</td></tr> Aansluiting op procedure</th> Conformance checking tegen het gedocumenteerde proces</td></tr> Kosten van controle</th> Hersteldata, steekproeven en observatie</td></tr> Reviewcapaciteit</th> Wachtrijdiepte, achterstand en eigenaarschap</td></tr> Gevolgen van een fout</th> Oordeel van proceseigenaar, risk en legal</td></tr> </tbody> </table> </div> Waar systemen redelijk complete eventlogs met stabiele case-ID's produceren, kan process mining reconstrueren hoe het werk stroomt. Het is een gevestigd vakgebied</a> voor het ontdekken, monitoren en verbeteren van operationele processen.</p> Vier gebieden worden vooral in de systemen geobserveerd. Volume is een telling. Geraakte systemen vormen een inventaris. Datatoegang wordt getest met de goedgekeurde rechten. Datakwaliteit beoordelen we door de records te bekijken die de agent werkelijk zou ontvangen.</p> Ook de aansluiting op de procedure is meetbaar als de logs volledig genoeg zijn. Conformance checking vergelijkt het gedocumenteerde proces met de volgorde in het log. Wordt een vastgelegde stap regelmatig overgeslagen, dan is dat zichtbaar voordat het een fout van de agent wordt.</p> Het vastgelegde proces is bewijs, geen blauwdruk. De Scan begint bij de gewenste bedrijfsuitkomst en bepaalt daarna welke verantwoordelijkheden bij mensen, agents en bestaande systemen horen. We automatiseren het huidige proces niet simpelweg omdat dat in het log staat.</p> De kosten van controle en de reviewcapaciteit beginnen bij bewijs en eindigen bij mensen. Heropende cases, gecorrigeerde invoer en herhaalde stappen laten zien waar al herstelwerk zit. Wachtrijdiepte, ouderdom van de achterstand en eigenaarschap laten zien of iemand de uitzonderingen van de agent kan beoordelen. De mensen die het werk doen, verklaren wat niet in het record staat.</p> De gevolgen van een fout vragen vanaf het begin om een oordeel. Ze landen meestal buiten het systeem dat de case vastlegde: een klant die niet terugkwam, een vraag van de toezichthouder of een correctie per e-mail.</p> Zeven van de acht beginnen bij vastgelegd bewijs.</b> De gevolgen van falen beginnen bij een verantwoordelijk oordeel. Gesprekken verklaren de gaten en gevolgen, in plaats van mensen te vragen een heel proces uit hun geheugen te reconstrueren.</figcaption> </figure> De eerlijke beperking is werk dat geen bruikbaar spoor achterlaat. Een spreadsheet op een tweede scherm, een bericht aan een collega, kopiëren en plakken tussen systemen die nooit aan elkaar zijn gekoppeld. Een deel is vast te leggen via observatie of desktopevidence. De rest moet worden besproken. Juist daar zitten vaak de belangrijkste uitzonderingen.</p> Dat verandert het gesprek. In plaats van iemand te vragen het hele proces te beschrijven, kan de Scan vragen waarom een bepaalde stap in vier van de tien vastgelegde cases ontbreekt. Bewijs brengt de discussie terug tot de uitzonderingen en beslissingen die werkelijk tellen.</p> 05</span>Hoe ziet een echte beoordeling eruit?</h2> Neem een illustratief proces voor de intake van claims. Veel volume, regelgestuurd, digitale input. Het doorstaat de gebruikelijke geschiktheidstoets ruimschoots.</p> De Scan vindt drie tegenstrijdige signalen. Volume en systeemtoegang scoren goed. De aansluiting op de procedure niet, omdat het vastgelegde proces regelmatig afwijkt van het beschreven proces. Ook de reviewcapaciteit scoort slecht, omdat geen eigenaar genoeg tijd heeft om de voorgestelde output te controleren.</p> Claims intake</p> Readiness · 8 areas scored</span> </div> Three of the eight, and the three that decide what happens next.</p> Data access</span> 78</p> </i>clean API</span> </i>three years of history</span> </div> </div> Documentation</span> 40</p> </i>SOP four years stale</span> </i>team works around it</span> </div> </div> Review capacity</span> 25</p> </i>one team lead</span> </i>200 cases a day</span> </div> </div> </div> Illustratief</span> Rewrite the SOP before building</span> Find a second reviewer, or narrow the scope</span> </div> </div> De scores zijn niet de uitkomst. De lijst met hiaten is dat wel.</b> Niets zegt hier dat het proces moet worden afgewezen. Het laat zien wat moet veranderen, zolang aanpassen nog goedkoop is.</figcaption> </figure> Samen vertellen de signalen iets wat de standaardchecklist mist. Het werk is bereikbaar en ruim aanwezig. De gedocumenteerde procedure beschrijft het niet meer. En er is geen capaciteit om de output te beoordelen. Direct bouwen zou een proces reproduceren dat al is veranderd, om de resultaten vervolgens te geven aan iemand die geen tijd heeft om dat op te merken.</p> De bruikbare uitkomst is de lijst met hiaten. Werk de procedure bij en creëer daarna reviewcapaciteit, of beperk de eerste agentrol tot het deel waar één persoon zicht op kan houden. Beide zijn vóór de bouw goed te organiseren en na go-live duur om alsnog te ontdekken.</p> 06</span>Welk werk kun je beter met rust laten?</h2> Een deel. Dat benoemen hoort bij het werk. Tegelijk staat er een financiële prikkel tegenover. Volgens Michael Birshan, een van de managing partners van McKinsey, kwam in november 2025 ongeveer een kwart van de wereldwijde omzet uit outcome-based pricing in plaats van tijd. Dat zei hij tegen Business Insider</a>. Als de vergoeding volgt op de bouw, moet een beoordeling met als uitkomst “niet bouwen” op zichzelf waardevol genoeg zijn om voor te betalen. Anders verdwijnt die conclusie stilletjes. Een scan die alleen “ja” oplevert, is een offerte met extra stappen.</b> Hij moet ook bruikbaar zijn als het antwoord luidt: nog niet, niet met deze scope of niet bouwen.</p> Dit zijn de duidelijkste stopsignalen.</p> Een correct antwoord is alleen te herkennen door het werk opnieuw te doen.</b> Onderzoekssamenvattingen, oordelen zonder referentie om tegen te toetsen en elke taak die de reviewer moet herhalen om te weten of die klopt. De agent kan een goed resultaat leveren. Het proces kan dat niet economisch verifiëren.</p> Niemand heeft ruimte om het te beoordelen.</b> Als de beoogde reviewer al vol zit, verklein dan de scope tot review wel past of los eerst de bezetting op. Een agent toevoegen aan een wachtrij waar niemand zicht op kan houden, verplaatst de bottleneck in plaats van hem op te lossen.</p> De regels veranderen sneller dan ze kunnen worden onderhouden.</b> Uitzonderingen zijn normaal. Het wordt anders wanneer het onderliggende beleid elke paar weken verandert en niemand kan zeggen welke versie nu geldt.</p> Het proces draait te weinig om betrouwbaar te meten.</b> Een proces dat enkele keren per maand voorkomt, levert mogelijk nooit genoeg cases op voor een stabiele nulmeting, om afwijkingen te signaleren of de eigen controle te rechtvaardigen. Een mens met een goede checklist is vaak goedkoper.</p> Het pad is volledig deterministisch.</b> Als elke stap en vertakking vooraf te specificeren is, is gewone workflowautomatisering waarschijnlijk goedkoper en betrouwbaarder. Een agent verdient zijn plek waar werkelijk enige begrensde interpretatie of aanpassing nodig is.</p> Wat dit je niet vertelt</p> Een goede score betekent niet dat een agent zal slagen. Het betekent dat het werk het proberen waard is</b> en dat de operationele risico's bekend zijn. Bewijzen dat het in productie standhoudt is een apart vraagstuk. Daarover schreven we in wat er werkelijk nodig is om een agent in productie te runnen</a>.</p> </div> 07</span>Welk werk past goed bij een AI-agent?</h2> Werk past wanneer een correct antwoord betaalbaar te herkennen is, de gevolgen van een fout begrensd of omkeerbaar zijn, er genoeg volume is om prestaties te meten en iemand de ruimte en bevoegdheid heeft om uitzonderingen af te handelen. Het werk moet ook genoeg variatie of oordeelsvorming bevatten om een agent te rechtvaardigen in plaats van gewone automatisering.</p> Facturen koppelen aan orders en ontvangstbewijzen. Gestructureerde velden uit documenten overnemen in een registratiesysteem. Eerstelijnstriage waarbij de routeringsbeslissing in één oogopslag is te controleren. Het werk is begrensd, maar niet altijd identiek.</p> Terug naar de claimsintake. Tweehonderd cases per dag en één teamlead. De meeste cases zijn eenduidig en in enkele seconden te bevestigen. Het overdragen van dat begrensde deel verandert de rekensom. De teamlead houdt meer tijd over voor de kleinere groep die werkelijk onzeker is.</p> Het werk verdwijnt niet. Voor uitzonderingen was altijd al een mens nodig. Tegelijk kregen juist die het minste aandacht, omdat dezelfde persoon ook al het routinevolume droeg.</p> De winst is dus niet automatisch een besparing. Het is capaciteit die vrijkomt uit routinewerk. Die wordt waarde wanneer een benoemde eigenaar haar inzet voor meer output, betere service, beter oordeel of een concrete kostenverbetering. Die omzetting hoort in de businesscase en moet na go-live worden gemeten.</p> Onthoud de twee vragen. Neem het proces dat jullie al overwogen. Vraag hoe lang iemand nodig heeft om te weten dat één resultaat klopt. Vraag daarna wat er gebeurt als een fout resultaat doorglipt. Is een van beide antwoorden onbekend, dan is dat de eerste bevinding.</p> Het vastgelegde proces lezen vraagt goedgekeurde toegang tot de systemen waarop het werk draait. Daarvoor is de Scan bedoeld en daar beginnen we</a>. Voor de twee vragen is geen tooling nodig. Stel ze voordat je met een leverancier praat en de businesscase staat direct steviger.</p> Geschiktheid is geen eigenschap van het werk alleen. Het is de combinatie van het werk, de kosten van verificatie en de gevolgen van een fout. Een geschikte agent neemt meetbaar volume over binnen grenzen waar een mens grip op houdt.</p> Veelgestelde vragen</h2> Welke processen zijn geschikt voor een AI-agent?+</span></summary> Zoek werk waarbij een correct resultaat betaalbaar te controleren is, de gevolgen van een fout begrensd zijn, er genoeg volume is om prestaties te meten en iemand de uitzonderingen kan afhandelen. Het werk moet ook genoeg variatie bevatten om een agent te rechtvaardigen in plaats van gewone workflowautomatisering.</div> </details> Past herhaalbaar werk met veel volume altijd goed?+</span></summary> Nee. Die kenmerken beschrijven werk dat een agent mogelijk kan doen, maar niet of het de moeite waard is om over te dragen. Als de controle van elk resultaat evenveel inspanning vraagt als het werk zelf, blijft de businesscase zwak, hoe capabel de agent ook lijkt.</div> </details> Waarom tellen de kosten van controle van agentwerk mee?+</span></summary> Controle is onderdeel van de operationele kosten. Als het verifiëren van een resultaat evenveel inspanning vraagt als het maken ervan, is het werk naar review verplaatst in plaats van verdwenen. Neem verificatie op als terugkerende kosten in de businesscase</a> totdat productiebewijs minder controle rechtvaardigt.</div> </details> Welk werk kun je beter niet aan een AI-agent geven?+</span></summary> Vermijd werk waarbij controle even lang duurt als uitvoering, een fout een klant of toezichthouder kan bereiken voordat iemand ingrijpt, of niemand de uitzonderingen kan afhandelen. Is het pad volledig voorspelbaar, dan is gewone automatisering meestal eenvoudiger en goedkoper.</div> </details> Hoe beoordeel je of een proces klaar is voor een AI-agent?+</span></summary> Begin bij het werk zoals het werkelijk gebeurt. Eventlogs, caserecords en steekproeven laten zien waar tijd heen gaat, hoe vaak uitzonderingen voorkomen en wat mensen later corrigeren. Onderzoek de gaten daarna met de mensen die eigenaar zijn van het proces. Alleen een workshop legt vooral de procedure vast die mensen dénken te volgen. Gaat het werk door, dan moet apart bewijs laten zien dat het in productie standhoudt</a>.</div> </details> </div> Bronnen</h4> Workday, Beyond Productivity: Measuring the Real Value of AI</a> (January 2026), a survey of 3,200 active AI users across North America, APAC and EMEA, fielded November 2025</li> Michelle Vaccaro, Abdullah Almaatouq and Thomas Malone, When combinations of humans and AI are useful: a systematic review and meta-analysis</a>, Nature Human Behaviour</i> 8 (2024), covering 106 experiments and 370 effect sizes</li> National Institute of Standards and Technology, AI Risk Management Framework (AI RMF 1.0)</a> (2023), on intended context, error costs, human oversight and deployment decisions</li> European Union, Regulation (EU) 2024/1689, the Artificial Intelligence Act</a>, including Article 6 and Annex III on high-risk classification</li> IEEE Task Force on Process Mining, Process Mining Manifesto</a> (2011), on process discovery, monitoring and conformance checking</li> Michael Birshan of McKinsey on outcome-based fees, reported by Business Insider and syndicated here</a> (November 2025)</li> The eight readiness areas, the Scan method and the claims-intake example are Aitonomy’s own. The example and its scores are illustrative.</li> </ul> </div> </div> </article> Een AI-agent bouwen is het eenvoudige deel Mik Nijhuis — Thu, 23 Jul 2026 00:00:00 +0000 In bijna elk agentproject valt de ruimte op een gegeven moment op een goede manier stil. De agent leest het document, roept het systeem aan, schrijft het record en iedereen ziet dat het werkt.</p> Dat moment is waardevol. Tegelijk is het de minst representatieve run die de agent ooit zal uitvoeren. Een demo is één zorgvuldig gekozen case, terwijl iemand meekijkt. Productie is elke case die binnenkomt, ook de lastige, lang nadat de ruimte leeg is.</p> Een agent bouwen is eenvoudiger geworden doordat de tooling is verbeterd. De moeilijkheid is verschoven, niet verdwenen.</p> Gartner verwacht dat meer dan 40 procent van de agentic-AI-projecten eind 2027 is stopgezet</a>. De belangrijkste redenen zijn oplopende kosten, onduidelijke bedrijfswaarde en gebrekkige risicocontroles. Capaciteit en de aansluiting op de use case blijven relevant. Maar capaciteit alleen brengt een werkende agent niet naar productie.</p> Het DORA-onderzoek uit 2025 kwam voor softwaredelivery tot een vergelijkbare conclusie: AI versterkt het systeem eromheen</a>. Sterke workflows, platforms en feedbackloops vergroten het effect. Zwakke worden zichtbaarder.</p> Een pilot beantwoordt één vraag: kan de agent dit één keer? Productie stelt vier andere. Houdt het werk volgende maand nog stand? Wat kost het bij de echte casemix? Wie is verantwoordelijk als het fout gaat? Kun je reconstrueren wat de agent deed en waarom?</p> In ons artikel over wat een agent werkelijk is</a> maakten we hetzelfde punt over zijn anatomie: het model is één onderdeel; de lagen eromheen maken het werk bruikbaar. Dit artikel gaat over de volgende laag. Niet waaruit een agent bestaat, maar wat nodig is om AI-agents in productie te runnen.</p> Het werk wordt ongemerkt teruggedraaid</h3> De meeste systemen kunnen acceptatie op de dag zelf meten: kwam de output door de controle, keurde iemand hem goed en is het record geschreven? Of dat werk een maand later nog overeind staat, weet je pas later. Het venster waarin iets kan misgaan is langer dan het meetvenster.</b></p> Een creditnota wordt aangemaakt en twee weken later teruggedraaid. Een leveranciersrecord wordt bijgewerkt en daarna gecorrigeerd door de eigenaar. Op het dashboard lijken beide runs op de dag zelf geslaagd. In werkelijkheid veroorzaakten ze allebei herstelwerk.</p> Als de correctie de operationele loop niet bereikt, leert de agent er niets van. Erger nog: het team kan instructies en evals blijven aanpassen op basis van wat op de dag zelf werd geaccepteerd, in plaats van wat later standhield. Het systeem rond de agent optimaliseert dan voor het verkeerde signaal.</p> Softwaredelivery geeft een goed gemeten voorbeeld van dat risico, omdat wijzigingen en terugdraaiingen worden gelogd. Bill Harding, CEO van codeanalysebedrijf GitClear, beschreef de prikkel helder.</p> AI schrijft bij voorkeur code die niet als defect wordt aangemerkt. Bill Harding, GitClear</b> · LeadDev</a>, July 2026</cite> </blockquote> Uit het onderzoek van GitClear uit 2026 naar 623 miljoen codewijzigingen</a> bleek dat werk dat binnen twee weken werd herzien met 15 procent toenam. Constructies die fouten maskeren namen tussen 2023 en 2026 met 47 procent toe. Dat is bewijs over software, geen bewijs dat elke zakelijke agent zich hetzelfde gedraagt. Het laat wel zien waarom directe acceptatie geen vervanging is voor blijvende kwaliteit.</p> </th> De demo</th> Productie</th></tr> </thead> De case</th> Gekozen en afgebakend</td> Alles wat binnenkomt</td></tr> Toezicht</th> Er kijken mensen mee</td> Monitoring moet zijn ontworpen</td></tr> Succes is</th> De output zag er goed uit</td> De uitkomst houdt later nog stand</td></tr> Meting</th> Direct</td> Over het hele faalvenster</td></tr> Kosten per case</th> Een eerste observatie</td> Een spreiding bepaald door echte cases</td></tr> Stopt wanneer</th> De vergadering eindigt</td> Een benoemde eigenaar beslist</td></tr> </tbody> </table> </div> Context verandert de kostencurve</h3> In een loop die bij elke stap een groeiende historie opnieuw meestuurt, kunnen de inputkosten sneller stijgen dan het aantal stappen. Instructies, voorbeelden, opgehaalde documenten en toolbeschrijvingen strijden allemaal om dezelfde context. Uitzonderingen voegen vaak meer materiaal toe. Die toevoegingen stapelen zich op als niemand ze verwijdert of herstructureert.</p> Louis-François Bouchard mat dit bij een tutoring agent in productie. Zijn diagnose is het onthouden waard.</p> Het model werd niet dommer. Zijn context wel. Louis-François Bouchard</b> · Context engineering in 2026</a>, August 2026</cite> </blockquote> Zijn resultaten laten ook zien dat dit geen onvermijdelijke ontwikkeling in één richting is. In zijn workload verlaagde een limiet op tooloutput de kosten per beurt met 38 procent, zonder meetbaar geheugenverlies. Prompt caching, retrieval, outputlimieten, bewust snoeien en modelrouting kunnen de curve allemaal veranderen.</p> De pilotkosten zijn dus niet per definitie het laagste bedrag dat de agent ooit zal halen. Het is simpelweg geen productieprognose. De productie-economie moet per case worden gemeten, tegen de werkelijke spreiding van het werk.</p> Bij weinig volume is het gemiddelde minder stabiel</h3> De kosten per case zijn vaak rechts-scheef verdeeld. De meeste cases zijn gewoon; een klein aantal duurt lang. Bij weinig volume kunnen die uitschieters het maandelijkse gemiddelde sterk beïnvloeden. Bij veel volume is het gemiddelde doorgaans stabieler, ook als de totale rekening hoger is.</p> Dat verschil telt. Een financeproces met duizenden vergelijkbare cases kan in totaal duur zijn, maar per case voorspelbaar. Een analistenproces met vijf diepgaande onderzoeken kan goedkoper zijn en toch elke maand verrassen.</p> In ons eigen werk vonden we dit patroon in kostenmodellen, niet in een universele productiebenchmark. Het veranderde welke processen we economisch onzeker noemen en welk bewijs we vragen voordat we ze goedkeuren.</p> 03</span>Wat spreken we af vóór de bouw?</h2> Een proces heeft een businesscase nodig voordat de agents een architectuur nodig hebben. Zonder businesscase ontbreekt een stabiele uitkomst, nulmeting en beslisregel waaraan je het systeem kunt houden.</p> Het onderscheid tussen proces en agent is belangrijk. Een organisatie draagt een procesuitkomst over. Eén agent kan die dragen, of meerdere kleinere agents kunnen eronder samenwerken. Dat is een architectuurkeuze die tijdens de bouw kan veranderen. De businesscase en commerciële eenheid blijven het proces. Het splitsen of combineren van agents verandert dus niet stilletjes wat de klant heeft gekocht.</p> Voor elk proces dat we in productie brengen, past de businesscase op één pagina. Die legt zes zaken vast: het werk, kwaliteit en risico, de nulmeting, investering en waarde, het prestatiedoel en de benoemde eigenaar.</p> Twee details bepalen of de rest bruikbaar is.</p> De nulmeting krijgt een label.</b> Waar de historie van de organisatie voldoende basis biedt, wordt de nulmeting berekend en als gemeten gemarkeerd. Anders wordt ze gemodelleerd op basis van een vergelijkbaar proces, een externe benchmark of een expliciete aanname, met het label gemodelleerd. Een gemodelleerde nulmeting kun je ter discussie stellen en vervangen. Een verborgen aanname niet.</p> Capaciteit wordt niet als waarde gepresenteerd.</b> De businesscase maakt onderscheid tussen tijd die als capaciteit vrijkomt en gerealiseerde waarde. Vrijgekomen tijd wordt pas waarde wanneer een benoemde eigenaar die omzet in meer output, betere dienstverlening, lagere externe uitgaven of een concrete personeelsbeslissing. Tot dat moment is het beschikbare capaciteit, geen besparing.</p> De businesscase moet negatief mogen uitvallen. Anders is het een rechtvaardigingsdocument in plaats van een beslisinstrument.</p> We gebruiken een methode met vier fasen</a>. De opbouw telt meer dan de namen.</p> Scan</b> stelt de gewenste uitkomst en de huidige nulmeting vast, en bepaalt of het werk geschikt is. Onboard</b> definieert de agentrollen, systeemtoegang, grenzen en verantwoordelijke eigenaar. Earn trust</b> test de agents op echte cases voordat ze zelfstandig handelen. Grow</b> meet het proces zolang het draait aan de businesscase.</p> Elke fase levert bewijs dat de volgende nodig heeft.</b> Grow keert terug naar Scan wanneer het proces, de systemen of het beoogde gebruik verandert. Latere prestaties worden gemeten aan de nulmeting uit Scan.</figcaption> </figure> De pijl terug is belangrijk. Bronsystemen krijgen updates. Regels veranderen. Modellen worden vervangen. Een configuratie die een jaar niet is beoordeeld, is niet bewezen stabiel alleen omdat ze nog draait.</p> In de dagelijkse operatie staan vier signalen naast elkaar: benutting, blijvende kwaliteit, effect op de procescapaciteit en kosten per case. Ze voeden de drie maatstaven uit de businesscase waarmee de rol wordt beoordeeld: kwaliteit, capaciteit en waarde.</p> De kwaliteitsmeting moet langer duren dan het faalvenster. First-time-right op de dag zelf is een vroeg signaal. First-time-right na de afgesproken periode is het blijvende resultaat. Het verschil bestaat uit werk dat iemand opnieuw opende, corrigeerde of terugdraaide.</p> Dat cijfer is de meting, niet de oplossing. De oplossing is elke correctie opvangen en terugbrengen in de operationele loop: wat deed de agent, wat veranderde een mens en waarom? Een terugkerende correctie wordt een kandidaat-regel. Die komt pas in de vaste context van de agent nadat hij de tests en evals van die agent doorstaat.</p> De loop is het antwoord, niet het dashboard.</b> Sluit je de loop, dan baseer je toekomstige wijzigingen op de uitkomst die werkelijk standhield. Laat je hem open, dan kan de kwaliteitsscore verbeteren terwijl de organisatie het werk blijft terugdraaien.</p> Binnen Aitonomy runnen we code review, QA, security checks, documentatie, infrastructuurcontroles en interne rapportage als agents op verschillende autonomieniveaus. Daar werden verschillende faalpatronen uit dit artikel voor ons voor het eerst zichtbaar.</p> 05</span>Wat hebben we veranderd?</h2> We veranderden twee onderdelen van onze eigen methode.</p> We gebruiken het aantal agents niet langer als eenheid.</b> We hadden al geconcludeerd dat de inspanning afhangt van de complexiteit van het proces, niet van het aantal agents. Die conclusie hadden we nog niet doorgevoerd in de manier waarop we het werk beschreven en prijsden. Een lezer van ons eigen document wees ons op de inconsistentie.</p> Het proces is nu de bedrijfsmatige en commerciële eenheid. De agents daaronder blijven architectuurrollen. Hun aantal kan veranderen zonder dat de beloofde uitkomst of de prijs stilletjes verandert.</p> We veranderden onze omgang met kostenrisico bij weinig volume.</b> Eerst namen we aan dat processen met veel volume het moeilijkst te voorspellen waren, omdat daar de totale uitgaven het hoogst zijn. Onze modellering liet zien dat de gemiddelde maandelijkse kosten per case bij weinig volume minder stabiel zijn. Een paar lange cases kunnen het resultaat dan sterk verschuiven.</p> We ontdekten dat tijdens de modellering, voordat het een live businesscase raakte. Het waardevolle was niet dat we de fout voorkwamen, maar dat een meetwaarde ons dwong de methode te veranderen.</p> 06</span>Hoe houden we grip op een agent?</h2> Dit is het werk dat Aitonomy voortzet nadat een agent live gaat. Aitonomy Control legt het bewijs uit de operatie vast. Ons operationele team runt de control loop en gebruikt dat bewijs om afwijkingen te onderzoeken en de inzet van de agent aan te passen. De proceseigenaar bij de klant blijft verantwoordelijk voor de uitkomst en bekrachtigt elke maand het besluit om de scope te verruimen, gelijk te houden, te verkleinen of de agent te stoppen.</p> Grip begint vóór de bouw. We spreken af wat wordt gemeten, stellen de nulmeting vast, definiëren de grenzen van de agent en bepalen welk bewijs nodig is voordat hij met meer autonomie mag handelen.</p> De faalpatronen in dit artikel delen die eis. Directe acceptatie vervangt geen blijvende kwaliteit. Pilotkosten vervangen geen productiekosten per case. Een theoretische capaciteitsschatting vervangt geen gerealiseerde waarde. En een autonomieniveau mag niet alleen omhoog kunnen.</p> Wanneer dit niet van toepassing is</p> Als werk maar een paar keer per maand voorkomt, of de regels bij elke uitvoering veranderen, kan een groot deel van dit besturingssysteem onnodige overhead zijn.</b> Het is bedoeld voor processen die vaak genoeg terugkeren om te meten. Onder die grens kan een mens met een goede checklist goedkoper en beter zijn. Een Scan die tot die conclusie komt, heeft zijn werk gedaan.</p> </div> Aitonomy Control houdt dat bewijs vervolgens bij elkaar: wat elke agent deed, wat een mens goedkeurde, of het werk standhield en hoe kwaliteit, capaciteit, waarde en kosten zich verhouden tot de afgesproken nulmeting.</p> Kwaliteit, capaciteit en waarde</p> Kai · finance operations</span> </div> Eén agent, gemeten aan de nulmeting die vóór de bouw is afgesproken. De cijfers zijn illustratief.</p> Na 30 dagen nog correct</span> 91%</small></p> </i>96% op de dag geaccepteerd</span> </i>1 onder de norm</span> </i>82% vóór de agent</span> </div> Deze maand vrijgekomen</span> ≈374 h</small></p> </i>houdt stand</span> </i>zelfstandig ≈291u</span> </i>nulmeting 240u</span> </div> Waarde-equivalent rendement</span> ≈7.5×</small></p> </i>houdt stand</span> </i>ca. €39,3k</span> </i>1× is break-even</span> </div> Illustratief</span> Nulmeting akkoord 12 jun</span> Laatste 12 weken</span> Besluit: verruimen</span> Volgende review 1 sep</span> </div> </div> Directe acceptatie naast blijvende kwaliteit</b>, gemeten na het afgesproken faalvenster. Het verschil is werk dat later opnieuw werd geopend, gecorrigeerd of teruggedraaid.</figcaption> Illustratief, geen klantresultaat.</b> Dit laat de vorm van een maandelijkse review zien: één finance-operationsagent over twaalf weken, afgezet tegen een maandelijkse nulmeting van 240 uur vóór de bouw. Vrijgekomen uren zijn capaciteit die teruggaat naar het team. Het is geen directe kostenbesparing. De waarde hangt af van wat het team met die capaciteit doet. Het rendement waardeert de uren tegen het eigen tarief van de organisatie en vergelijkt dat met de runkosten van de agent. Vervang alle cijfers door jullie eigen nulmeting, tarief en kosten voordat je dit model in een businesscase gebruikt.</p> </figure> Dat bewijs moet beslissingen veranderen. We kunnen de context aanpassen, overstappen op een lichter model als dat dezelfde norm haalt, de autonomie verkleinen of verruimen, of de rol stoppen. Veranderen het beoogde doel, de scope of het gebruik van een agent, dan moeten ook de relevante classificatie, documentatie, menselijke controls en verantwoordelijkheden opnieuw worden beoordeeld. De formele juridische beoordeling blijft losstaan van het technische bewijs dat Aitonomy Control levert. Dit is ook het operationele uitgangspunt achter laten zien wat elke agent deed en wie het goedkeurde</a>.</p> Agents kunnen veel monitoringwerk voorbereiden: scoreboards lezen, afwijkingen markeren en relevante runs verzamelen. Ons operationele team beoordeelt dat materiaal en brengt het bewijs naar de proceseigenaar. Het besluit zelf blijft mensenwerk.</p> Er is een eenvoudige toets voor echte governance. Vraag wanneer een agent voor het laatst een autonomieniveau omlaag ging. Vraag wanneer een maandbesluit voor het laatst een agent stopzette. Vraag wat er vorige maand veranderde door het scoreboard.</p> Als het antwoord op alle drie “nooit” is, rapporteert het systeem alleen. Het stuurt niet. Een control die nooit een beslissing verandert, is slechts een dashboard.</b></p> Een agent het werk één keer laten doen wordt steeds eenvoudiger. Goed runnen begint daarna: een nulmeting vóór de bouw, een benoemde eigenaar, bewijs dat autonomie kan verlagen én verhogen en een maandelijks besluit dat de agent ook mag stoppen.</p> Veelgestelde vragen</h2> Waarom slagen pilots met AI-agents en lopen ze daarna vast?+</span></summary> Een pilot laat zien dat een agent het werk kan afronden. Productie stelt moeilijkere vragen: houdt de kwaliteit stand, wat kost elke case en levert het proces werkelijk capaciteit op? Teams lopen vast wanneer ze de taak één keer hebben bewezen, maar geen businesscase</a> hebben gedefinieerd of geen besturingssysteem rond de agent hebben gebouwd.</div> </details> Wat bepaalt de kosten van een AI-agent?+</span></summary> De kosten hangen af van de werkelijke casemix, het aantal stappen, de hoeveelheid context, de gebruikte modellen en tools en het controle- en uitzonderingswerk dat bij mensen blijft. Meet in productie de spreiding van de kosten per case. Een pilotrun is geen betrouwbare voorspelling.</div> </details> Wat meet je zodra een AI-agent live is?+</span></summary> Meet benutting, blijvende kwaliteit, het effect op de procescapaciteit en de kosten per case. Samen laten die signalen zien of de agent kwaliteit, capaciteit en waarde creëert. Veel activiteit is niet genoeg. Een agent kan druk zijn zonder het omliggende proces te verbeteren.</div> </details> Waarom kan first-time-right misleidend zijn?+</span></summary> Werk kan op de dag zelf correct lijken en later toch opnieuw worden geopend, gecorrigeerd of teruggedraaid. Meet first-time-right opnieuw na een afgesproken periode. Het verschil tussen beide cijfers laat zien of het resultaat in het echte proces standhield.</div> </details> Wie is verantwoordelijk voor een AI-agent in productie?+</span></summary> Een benoemde persoon bij de klant. Die blijft verantwoordelijk voor de uitkomst en bepaalt op basis van het bewijs uit de operatie of de scope wordt verruimd, gelijk blijft, wordt verkleind of de agent stopt. Het supervision policy</a> definieert welk bewijs voor die beslissingen nodig is. Een afdeling of stuurgroep vervangt geen eigenaar.</div> </details> </div> Bronnen</h4> Gartner, Over 40% of agentic AI projects will be cancelled by the end of 2027</a></li> DORA, State of AI-assisted software development 2025</a></li> GitClear, The Maintainability Gap</a>, and Bill Harding interviewed in LeadDev</a></li> Louis-François Bouchard, Context engineering in 2026</a></li> European Union, Regulation (EU) 2024/1689, the Artificial Intelligence Act</a></li> Uitspraken over Aitonomy’s eigen kostenmonitoring en modellering zijn in het artikel als zodanig benoemd. Ze worden niet gepresenteerd als externe benchmarks.</li> </ul> </div> </div> </article> De spelregels voor agents komen eraan. Ze vragen om één ding: laat je werk zien Mik Nijhuis — Wed, 08 Jul 2026 00:00:00 +0000 De Europese AI Act, de ISO-managementnorm waar inkopers nu naar vragen en de soevereiniteitsvraag wie jullie stack beheert, komen tegelijk op organisaties af. Ze lijken los van elkaar te staan. Dat doen ze niet. Uiteindelijk vragen ze allemaal om hetzelfde: een vastlegging van wat jullie AI deed en op welke basis. Bij agents, die zelfstandig meerdere stappen uitvoeren, is juist die vastlegging het moeilijke deel.</p> De meeste teams krijgen een agent wel aan het werk. Achteraf bewijzen wat hij deed, op welke basis en wie het goedkeurde, is waar het misgaat. Precies dat bewijs beginnen de regels nu te eisen.</p> De grote boodschap in 2026 is dat de EU pas op de plaats maakte. Op 19 november 2025 publiceerde de Commissie haar Digital Omnibus. Na de triloogonderhandelingen kwamen de instellingen in mei 2026 overeen om de high-riskverplichtingen uit de AI Act uit te stellen. Zelfstandige hoog-risicosystemen uit Bijlage III verschuiven van 2 augustus 2026 naar 2 december 2027. Voor AI in gereguleerde producten wordt dat 2 augustus 2028. Advocatenkantoren die de ontwikkelingen volgen, zoals Gibson Dunn</a>, zien het uitstel als reactie op onvoltooide geharmoniseerde normen en nationale autoriteiten die nog niet klaar waren.</p> Dat kun je gemakkelijk lezen als: “compliance kan wachten”. Dat kan niet. Het AI-rechtsteam van Jones Walker</a> benadrukt dat 2 augustus nog steeds telt, omdat de meeste transparantieverplichtingen uit artikel 50 ongewijzigd bleven. Artikel 50 geldt vanaf 2 augustus 2026 en verdeelt de plichten naar rol, in plaats van iedereen dezelfde op te leggen. Aanbieders moeten systemen die rechtstreeks met mensen interacteren zo ontwerpen dat duidelijk is dat het om AI gaat, tenzij dat al vanzelf spreekt. Ook dragen zij de verantwoordelijkheid voor machineleesbare markering van synthetische content. Gebruiksverantwoordelijken hebben beperktere, eigen plichten rond emotieherkenning en biometrische categorisering, deepfakes en AI-gegenereerde tekst die het publiek informeert over zaken van algemeen belang. Voor die laatste categorie geldt een uitzondering wanneer een mens de tekst heeft beoordeeld en iemand redactioneel verantwoordelijk is. Niet elk door AI gemaakt beeld, fragment of tekstdeel legt dus dezelfde verplichting op aan de organisatie die het gebruikt. De regels voor general-purpose modellen gelden al sinds augustus 2025. De eerste last is daarom niet het zware high-riskpapierwerk. Het begint met weten welke plichten bij jullie rol horen</a> en kunnen aantonen wat de machine produceerde en op welke basis.</p> Onafhankelijk analist Luiza Jarovsky</a> volgde in haar nieuwsbrief elke wijziging tot en met de goedkeuring door de Raad. Haar punt verdient herhaling: het uitstel is geen pauzeknop.</p> De tweede set spelregels is helemaal geen wet. ISO/IEC 42001</a>, gepubliceerd in december 2023, is de eerste managementsysteemnorm voor AI. Zie het als de tegenhanger van ISO 27001, maar dan voor de manier waarop een organisatie haar AI beheerst. De norm wordt een selectiecriterium in inkoop. Anthropic behoorde tot de eerste frontier labs met certificering</a>, geldig vanaf januari 2025. AWS en Microsoft volgden. Inkopers bij Fortune 500-bedrijven vragen leveranciers inmiddels om het certificaat of om een geloofwaardige route ernaartoe. De norm toetst iets weinig spectaculairs maar veelzeggend: hebben jullie beleid, risicobeoordelingen en monitoring, en kunnen jullie dat aantonen? Opnieuw draait het om vastlegging.</p> De Amerikaanse wetgeving kijkt niet zozeer naar waar data staat. Bepalend is of een Amerikaanse partij de data beheert en controleert. Frank Karlitschek, Nextcloud</b> · Holistic Sovereignty podcast</cite> </blockquote> In november 2025 ondertekenden alle 27 EU-lidstaten een verklaring om de digitale soevereiniteit te versterken en strategische afhankelijkheden te verkleinen. Voor organisaties die agents laten werken met hun eigen code en data, en die van klanten, is de vraag welk rechtsgebied afgifte kan afdwingen nu een volwaardige ontwerpkeuze. Geen voetnoot.</p> Dit is de zakelijke kern. Agents vermenigvuldigen het aantal geautomatiseerde beslissingen in jullie organisatie. Elke set regels hierboven maakt het duurder als je daar geen verantwoording over kunt afleggen. Gartner verwacht dat meer dan 40 procent van de agentic-AI-projecten vóór 2027 wordt stopgezet</a>, onder meer door onduidelijke waarde en gebrekkige controls. Teams die hun werk kunnen laten zien, komen door audits, winnen gereguleerde klanten en blijven leveren. Teams die dat niet kunnen, lopen vast.</p> Wat alle drie de sets regels vragen, is niet zozeer juridisch als wel bestuurlijk. Ethan Mollick schrijft in One Useful Thing: “als je kunt uitleggen wat je nodig hebt, effectieve feedback kunt geven en manieren kunt ontwerpen om werk te beoordelen, kun je met agents werken.”</a> Grip houden op een agent is hem managen: specificeer het werk, beoordeel het en leg beide vast. De regels maken die vastlegging verplicht.</p> Dat is de laag die wij bouwen. Aitonomy werkt rond de coding agent die jullie gebruiken en maakt diens activiteit beheersbaar en aantoonbaar.</p> Wat het platform biedt</h3> Eén uitgangspunt · een leesbare vastlegging</p> Controlepoorten.</b>Een wijziging van een agent geldt pas als afgerond wanneer die de controles voor die stap doorstaat. Dezelfde poort geldt voor een pull request van een mens of een agent.</span></li> Goedkeuring.</b>Waar beleid menselijke goedkeuring vereist, wordt die vastgelegd. Zo heeft autonomie een benoemde eigenaar en geen anonieme geautomatiseerde commit.</span></li> Audittrail.</b>Elke stap, specificatie, controle en beslissing wordt vastgelegd en is maanden later nog terug te lezen. Dat is de vastlegging waar de transparantieplichten uit de AI Act, een ISO 42001-audit en een soevereiniteitsbeoordeling uiteindelijk allemaal om vragen.</span></li> </ol> </div> Geen van deze onderdelen maakt een agent op zichzelf compliant. Ze zorgen wel dat het bewijs bestaat. Teams ontdekken meestal pas dat juist dat ontbreekt wanneer iemand erom vraagt.</p> De eerlijke kanttekening: het omnibusuitstel geeft lucht, maar trekt de regels niet in. Wie het als afstel behandelt, komt in 2027 alsnog in tijdnood. Ook een certificaat staat niet gelijk aan veiligheid. ISO 42001 toetst of er een systeem is, niet of dat systeem goed werkt. Governance verwordt tot toneel wanneer de vastlegging alleen wordt geproduceerd om een auditor tevreden te stellen en niet om het werk daadwerkelijk te sturen.</p> Het doel is niet meer papierwerk. Het doel is dat je snel en naar waarheid kunt antwoorden wat jullie agents deden en waarom.</p> Welke van deze drie komt als eerste op jullie bureau terecht? En kunnen jullie de vraag beantwoorden?</p> Veelgestelde vragen</h2> Is de EU AI Act uitgesteld?+</span></summary> Voor een deel. De verplichtingen voor hoog-risicosystemen zijn in 2026 uitgesteld, maar andere plichten volgen nog steeds de oorspronkelijke planning. Dat geldt onder meer voor de meeste transparantieverplichtingen uit artikel 50. Het uitstel geeft meer voorbereidingstijd, maar neemt de noodzaak niet weg om vast te leggen wat een AI-systeem produceerde en op welke basis.</div> </details> Wat is ISO 42001 en waarom is het relevant?+</span></summary> ISO/IEC 42001 is een managementsysteemnorm voor AI. De norm vraagt of een organisatie beleid, risicobeoordelingen, monitoring en bewijs heeft voor de manier waarop zij AI beheerst. Nu inkopers de norm meenemen in hun selectie, wordt het naast een compliancevraag ook een commerciële vraag.</div> </details> Maakt hosting in de EU een AI-systeem soeverein?+</span></summary> Niet vanzelf. De locatie van de server telt, maar ook wie de stack beheert en aanstuurt. De praktische vraag is onder welk rechtsgebied die organisatie kan worden gedwongen data af te staan. Een Europees datacenter beantwoordt die vraag niet op zichzelf.</div> </details> Welk bewijs moet je bewaren over het werk van een AI-agent?+</span></summary> Bewaar genoeg om te reconstrueren wat de agent deed, waarom, welke controles hij doorliep en wie het resultaat goedkeurde. Die vastlegging maakt de agent op zichzelf niet compliant of veilig. Ze levert wel het bewijs dat nodig is om de agent in productie te runnen</a> en geeft operators, inkopers en auditors iets concreets om te beoordelen.</div> </details> </div> Bronnen</h4> EU AI Act Digital Omnibus, deferral of high-risk obligations. Gibson Dunn, Omnibus Agreement: postponed high-risk deadlines</a>; Jones Walker, Yes, August 2 Still Matters</a></li> Luiza Jarovsky, Changes to the AI Act Approved by the Council of the EU</a> (independent AI Act analyst)</li> ISO/IEC 42001:2023, AI management systems</a>; Anthropic, ISO 42001 certification</a></li> Ethan Mollick, Management as an AI superpower</a> (One Useful Thing)</li> The Lawfare Podcast, Itsiq Benizri on the EU AI Act</a></li> Gartner, Over 40% of agentic AI projects will be canceled by 2027</a></li> </ul> </div> </div> </article> Wat een agent werkelijk is Mik Nijhuis — Wed, 24 Jun 2026 00:00:00 +0000 Als mensen zeggen dat ze “AI gebruiken”, bedoelen ze meestal een chat: je typt, een model antwoordt, jij leest. Nuttig, maar het blijft één modelcall. Een agent is iets anders. Het verschil zit niet in het model, maar in alles eromheen. Precies dat is wat wij bouwen.</p> Twee jaar lang kon de sector het niet eens worden over wat “agent” precies betekende. Die discussie is grotendeels beslecht. Na honderden definities te hebben verzameld, kwam Simon Willison tot een heldere omschrijving: “een LLM-agent gebruikt tools in een loop om een doel te bereiken.”</a> Anthropic gebruikt vrijwel dezelfde woorden, “LLM's die zelfstandig tools gebruiken in een loop”, en trekt in het veelgelezen Building Effective Agents</a> een scherpe grens: een workflow volgt vooraf gedefinieerde codepaden, terwijl bij een agent het model zelf zijn proces en toolgebruik aanstuurt en bepaalt hoe het de taak uitvoert.</p> Een chat is vraag en antwoord. Een agent is doel, plan, handelen, observeren en herhalen. Het model bepaalt de volgende stap, niet jij.</p> Een systeem is meer agentgestuurd naarmate een LLM meer bepaalt hoe het systeem zich kan gedragen. Harrison Chase, LangChain</b> · “Wat is een AI-agent?”</cite> </blockquote> Chase ziet het als een schaal, niet als een keurmerk. Andrew Ng zegt vanuit de andere kant hetzelfde: systemen kunnen in verschillende mate agentgestuurd zijn. Een kale chat staat op nul. Geef het model tools, geheugen en een loop en het schuift op.</p> Een chat is de stip in het midden. Een agent is het hele diagram.</b> “Introduction to Agents” van Google en Kaggle beschrijft de binnenkant: model, tools en orchestration. Lilian Weng van OpenAI voegt planning en geheugen toe. De buitenste ring is wat wij bouwen.</figcaption> </figure> De whitepaper vat de binnenkant helder samen: een model</strong> (het brein), tools</strong> (de handen die de buitenwereld bereiken) en een orchestration layer</strong> (de loop van denken, handelen en observeren). Weng voegt twee onderdelen toe die inmiddels vanzelfsprekend zijn: planning</strong> (het doel opdelen in stappen, reflecteren en bijsturen) en geheugen</strong> (context vasthouden over meerdere stappen, niet alleen binnen één bericht). Het model is noodzakelijk, maar bij lange na niet voldoende.</p> </th> Een chat</th> Een agent</th></tr> </thead> Interactie</th> Jij vraagt, de chat antwoordt en jij zet de volgende stap</td> Je draagt een doel over; de agent plant, handelt en observeert in een loop</td></tr> Controle</th> Jij bepaalt wanneer het verdergaat</td> De agent gaat door tot een stopvoorwaarde is bereikt</td></tr> Bevoegdheid</th> Werkt in een eigen sessie en geeft je het resultaat</td> Heeft toegewezen toegang en handelt in jullie systemen</td></tr> Geheugen</th> Een gemak binnen het gesprek</td> Wordt bewust meegenomen, omdat de volgende stap afhangt van de vorige</td></tr> Verantwoordelijk voor</th> Het antwoord dat voor je staat</td> De uitkomst, met een benoemde eigenaar en vastlegging</td></tr> </tbody> </table> </div> Het verschil tussen de twee kolommen zit niet in wat het systeem kan. Een goede chatassistent kan geheugen gebruiken, code uitvoeren, bestanden lezen en het web doorzoeken. Het verschil is delegatie: keur je elke stap zelf goed of draag je een doel over? Werkt het systeem in een eigen sessie of heeft het toegang tot die van jullie? En is iemand eigenaar van het resultaat zodra het stopt?</p> 02</span>De ladder die we zelf beklommen</h2> Dit ontstond niet uit één beslissing. Net als de meeste teams beklommen we een ladder. Het helpt om de treden te benoemen, zodat je ziet waar jullie zelf staan.</p> Van links naar rechts neemt de autonomie toe. Jij blijft betrokken; alleen je plek in het proces verandert.</b> Op trede vier typ je de wijziging niet meer zelf, maar keur je de pull request van de agent goed of af.</figcaption> </figure> Trede één was kopiëren en plakken: het antwoord kwam uit de chat, de code ging de editor in en de mens verbond alles. Trede twee was inline aanvulling, waarbij de editor de regel afmaakt. Op trede drie staan de meeste teams nu: heen en weer met het model tot de wijziging klopt. Trede vier wordt interessant. Je geeft een agent een doel en laat hem uitvoeren, schrijven, toetsen aan de specificatie, het resultaat lezen, corrigeren en herhalen tot de eindvoorwaarde is bereikt. Dat is de loop. Calvin French-Owen, die aan OpenAI Codex werkte, benoemt de beperking die daarbij bepalend is: “de agent voorspelt telkens het volgende token en elk token moet binnen een context window passen. Wie coding agents goed wil gebruiken, moet context begrijpen.”</a></p> We hebben deze ladder geformaliseerd omdat dit is wat we leveren. Intern lopen onze niveaus van Supervised naar Co-Author, Spec-First, Autonomous Routine en tot slot een beperkte Selective Autonomy. Teams doorlopen die ontwikkeling in kwartalen, niet in weken. Op elke trede blijf je betrokken. Alleen je positie verandert.</p> 03</span>Waarom de lagen juist het verschil maken</h2> Dit bepaalt of je een agent veilig binnen een organisatie kunt inzetten. Een fout antwoord van een chat kost een minuut. Een agent die handelt, kan een pull request openen, data verplaatsen of productie raken. Zodra een model iets kan doen</em>, zijn er lagen nodig die bij een chat nooit nodig waren: grenzen aan wat het mag aanraken, bewijs dat het werkt en een vastlegging van wat het heeft gedaan.</p> Die buitenste ring is wat wij bouwen. Niet het model en niet de coding agent. We bouwen de skill</strong> (de capaciteit die een agent krijgt), het beleid</strong> (wat hij wel en niet mag doen), de evals</strong> (bewijs dat hij het werk aankan) en de audittrail</strong> (achteraf bewijs van elke handeling). Op ons platform is een agent letterlijk de verbinding van die onderdelen: een ondertekend pakket van skill, beleid, evals, manifest en trigger. Een generieke runtime bevat die niet.</p> Het product bestaat uit de grenzen en de controls. Rechten, goedkeuringen, begrensde API-integraties, audits, rapportages, logs en waarschuwingen. Jake Stauch, Serval</b> · Sequoia Training Data, May 2026</cite> </blockquote> Dat is geen eigenzinnige opvatting. James Everingham, voormalig Meta en nu bouwer van een AI control plane, zei bij Dev Interrupted hetzelfde: “je moet kunnen begrijpen wat deze agents in je infrastructuur doen, in plaats van ze overal toegang toe te geven en ze maar hun gang te laten gaan.”</a> Simon Willison is in zijn stuk over het ontwerpen van agent loops</a> duidelijk over de reden: “agents zijn van zichzelf riskant. Laat je agent in een beveiligde sandbox draaien en stel een strakke budgetlimiet in als credentials geld kunnen uitgeven.” Dat is precies wat wij doen. Elke werkeenheid draait in een eigen tijdelijke sandbox, vóór elke toolcall wordt het beleid getoetst en een call die het budget overschrijdt stopt.</p> De loop is de agent. Dankzij de controlepoorten kun je hem laten doorwerken.</b> Een beleidstoets vóór een handeling, een evaltoets vóór iets onomkeerbaars, een auditstempel op elke stap en menselijke goedkeuring of afwijzing bij de pull request.</figcaption> </figure> Het eerste is onboarding: welke context je meegeeft. Harrison Chase noemt dit context engineering en beschrijft het probleem helder: “als een agent niet betrouwbaar presteert, komt dat meestal doordat de juiste context, instructies en tools niet aan het model zijn doorgegeven.”</a> Voor ons betekent een capaciteit onboarden dat we een skill schrijven in het open Agent Skills-formaat. Elke feature krijgt vóór het schrijven van code een verificatiespecificatie. Voor routine-agents neemt een evalsuite die rol over. De domeinexpert van een partner kan die via een wizard opstellen: skill, evals, beleid, connectors, autonomieniveau en publiceren. Vóór ondertekening controleert het systeem of het beleid en het autonomieniveau elkaar niet tegenspreken.</p> Het tweede is actueel blijven. Anthropic beschrijft in zijn werk over context engineering</a> “context rot”: naarmate het context window voller raakt, haalt een model informatie minder goed terug. De oplossingen zijn compactie en gestructureerde notities, of agentgeheugen, buiten het window.</p> De grootste beperking om deze modellen nuttiger te maken is tegenwoordig niet hun ruwe intelligentie, maar hun begrip van nieuwe en veranderende context. Jessy Lin, Engram</b> · Sequoia Training Data, June 2026</cite> </blockquote> Onze agents bouwen over verschillende runs een geheugen op. Na elke run zet een consolidatiestap de uitkomst om in geheugen en kandidaat-skills. Een kandidaat wordt pas een echte skill nadat die de evalnorm haalt. Leren betekent hier informatie opbouwen en terughalen, nooit het model opnieuw trainen. Verandert een skill of evalsuite, dan wordt de agent vóór ingebruikname opnieuw gecertificeerd voor zijn niveau.</p> 05</span>Context is meer dan de organisatie</h2> De context die een agent vormt, bestaat niet alleen uit jullie codebase en huisstijl. Ook de wet- en regelgeving waarbinnen hij opereert is een volwaardige input, geen voetnoot. In ons pakket voor personeelsplanning in de zorg toetst de agent direct aan de geldende arbeidsregels: de geldigheid van registraties en de rust- en urengrenzen uit de cao. Elke koppeling die een blokkerende regel raakt, krijgt de status “controle nodig” en wordt nooit automatisch bevestigd. Een gereguleerde tenant kan als beleid een strengere ondergrens instellen die overal geldt.</p> Hier bewijst de auditlaag zijn waarde. Harrison Chase schrijft over agent observability</a> dat governance begint bij een ongemakkelijke waarheid: je weet pas wat agents doen wanneer je ze daadwerkelijk laat draaien; hun gedrag ontstaat tijdens runtime. Daarom leggen we het juist dan vast. Elke beslissing bij een controlepoort en elke handeling wordt een onveranderbaar, contentblind record: welk veld veranderde en welke beleidsversie gold, nooit de privédata zelf. Zo kan bij een high-risk audit onder de EU AI Act worden gereconstrueerd wat er is gebeurd.</p> Waarom dit ertoe doet</p> Voor een klein team zit hierin de hele businesscase voor deze lagen: ze stellen één persoon in staat om veilig werk te runnen waarvoor eerder een team nodig was, zonder het spoor te verliezen waar een klant of toezichthouder om vraagt.</b></p> </div> Succes is niet: “we hebben AI ingevoerd”. In de benchmark van LinearB uit 2026 werd 32,7 procent van de AI-ondersteunde pull requests gemerged, minder dan de helft van het percentage bij menselijke pull requests. Het team vat de waarschuwing helder samen: “verwar adoptie niet met impact.”</a> CEO Ori Keren scherpt dat aan: “we produceren twee keer zoveel code, maar de winst ligt ergens tussen de 10 en 15 procent.” Succes is een agent waarvan het werk daadwerkelijk in productie komt en standhoudt. De evalrichtlijnen van Anthropic</a> geven een bruikbare toets voor “goed”: een taak waarbij twee domeinexperts onafhankelijk tot hetzelfde oordeel slagen of zakken komen, en waarbij fouten eerlijk aanvoelen. Harrison Chase schetst het eerlijke beeld: agents zijn niet tot negen negens betrouwbaar. Maar voor langlopend werk dat een eerste versie oplevert, zijn ze uitzonderlijk waardevol.</p> Een eenvoudige manier om te beginnen</h3> In deze volgorde · eerst omkeerbaar, dan autonoom</p> Kies één afgebakende, waardevolle en omkeerbare taak.</b>Iets dat kan uitmonden in een concept-pull request of voorstel, waarbij een fout goedkoop te onderscheppen is.</span></li> Leg eerst het doel en de toets vast.</b>Wat moet de agent doen en hoe weet je dat het gelukt is? De toets is de specificatie.</span></li> Geef de agent een strakke scope en een budget.</b>Een sandbox, een korte lijst met tools en een bestedingslimiet. Minimaal noodzakelijke rechten, geen “toegang tot alles”.</span></li> Laat een mens de pull request beoordelen.</b>Goedkeuren of afwijzen. Autonomie wordt verdiend wanneer de acceptatiegraad standhoudt, niet vooraf toegekend.</span></li> Leg vanaf dag één elke handeling vast.</b>Wat je niet kunt terugspelen, kun je niet beheersen.</span></li> Laat de agent leren en toets opnieuw.</b>Geef terug wat werkte en draai de evals opnieuw voordat je de scope verruimt.</span></li> </ol> </div> Een eerlijke kanttekening hoort erbij. Logan Kilpatrick van Google DeepMind stelt dat “het model de harness opeet”</a>: hulpmiddelen die vandaag voor het model uit lopen, worden er morgen in opgenomen. Voor mechanische scaffolding heeft hij gelijk. Maar het model neemt jullie grenzen aan bevoegdheden, het bewijs dat het aan jullie norm voldeed en de vastlegging waar een toezichthouder om vraagt niet over. Die lagen overleven het volgende model. De harness rond productie-agents wordt dan ook groter, niet kleiner.</p> Dus wanneer iemand zegt een “AI-agent” te hebben, is de relevante vraag niet welk model erachter zit. Vraag welke tools, welk geheugen, welke loop en wie de regie houdt. Het model is het eenvoudige deel. De agent is alles eromheen.</p> Welke laag is volgens jou het moeilijkst om goed te krijgen in productie?</p> Veelgestelde vragen</h2> Wat is het verschil tussen een AI-agent en een chatbot?+</span></summary> Een chatbot reageert op een vraag. Een agent werkt naar een doel toe: hij plant, handelt, bekijkt het resultaat en bepaalt de volgende stap. Door die loop, samen met tools en geheugen, kan een agent werk afronden in plaats van er alleen vragen over te beantwoorden.</div> </details> Wat maakt een AI-systeem agentgestuurd?+</span></summary> Agentgestuurd is geen ja of nee, maar een schaal. Hoe meer het model zelf bepaalt hoe het werk wordt gepland, welke tools het gebruikt en wat de volgende stap is, hoe meer agentgestuurd het systeem is. De nuttige vraag is niet welk label erop zit, maar hoeveel controle het model heeft.</div> </details> Wat heeft een AI-agent naast een model nodig?+</span></summary> Een agent heeft tools, geheugen, planning en een loop nodig die het werk voortzet. Binnen een organisatie zijn daarnaast een gedefinieerde skill, duidelijke rechten, tests die aantonen dat de agent het werk aankan en een audittrail nodig. Het model is maar één onderdeel van het systeem.</div> </details> Hoe houd je grip op een AI-agent?+</span></summary> Geef de agent een gedefinieerde skill, beperk waartoe hij toegang heeft en wat hij mag doen, toets het werk aan duidelijke evals en leg elke stap vast</a>. Laat een mens goedkeuren</a> waar een fout kostbaar of onomkeerbaar zou zijn. De agent mag de volgende stap bepalen, maar scope, budget en stopvoorwaarden blijven begrensd.</div> </details> </div> Bronnen</h4> Simon Willison, a widely agreed definition of “agent”</a> and designing agentic loops</a></li> Anthropic, Building Effective Agents</a>, Effective context engineering</a> & Demystifying evals</a></li> Harrison Chase / LangChain, What is an AI agent?</a>, The rise of context engineering</a> & agent observability</a></li> Google & Kaggle, Agents whitepaper</a>; Lilian Weng, LLM Powered Autonomous Agents</a></li> Jake Stauch, Rebuilding IT for the AI Age</a>; Jessy Lin, Memory and Continual Learning</a>; Logan Kilpatrick, Why the Model Eats the Harness</a> (Sequoia Training Data)</li> LinearB Dev Interrupted, 2026 Benchmarks</a> & an AI control plane</a>; Calvin French-Owen, Coding Agents in Feb 2026</a></li> </ul> </div> </div> </article>

Wat ISO 42001 van een organisatie vraagt

Wat de EU AI Act van een gebruiksverantwoordelijke vraagt

Autonomie moet je verdienen: supervision levels voor agents in productie

Zo bouw je de businesscase voor een AI-agent

Welk werk is geschikt voor een AI-agent?

Een AI-agent bouwen is het eenvoudige deel

De spelregels voor agents komen eraan. Ze vragen om één ding: laat je werk zien

Wat een agent werkelijk is

Aitonomy Insights

Van elektriciteit naar tokens: wat AI-rekenkracht kost

Aitonomy Insights

Van elektriciteit naar tokens: wat AI-rekenkracht kost

Wat ISO 42001 van een organisatie vraagt

Wat de EU AI Act van een gebruiksverantwoordelijke vraagt

Autonomie moet je verdienen: supervision levels voor agents in productie

Zo bouw je de businesscase voor een AI-agent

Welk werk is geschikt voor een AI-agent?

Een AI-agent bouwen is het eenvoudige deel

De spelregels voor agents komen eraan. Ze vragen om één ding: laat je werk zien

Wat het platform biedt</h3> Eén uitgangspunt · een leesbare vastlegging</p>

Wat een agent werkelijk is