Het Model AI Governance Framework for Agentic AI is een richtlijn van de Infocomm Media Development Authority (IMDA) van Singapore voor het verantwoord inzetten van AI-agents. Het kader vraagt organisaties de risico’s vooraf te beoordelen en af te bakenen, mensen betekenisvol verantwoordelijk te maken, technische controles en processen in te voeren en eindgebruikers in staat te stellen hun eigen verantwoordelijkheid te nemen. Voor support betekent dat afgebakende rechten, goedkeuringsmomenten, testen, monitoring en openheid over AI.
In het kort
- IMDA lanceerde het kader op 22 januari 2026; de huidige tekst is versie 1.5, gepubliceerd op 20 mei 2026 en bijgewerkt op 5 juni 2026.
- Het is een richtlijn, geen wet: het beschrijft “emerging best practices”, noemt zichzelf een levend document en kent geen sancties.
- Het noemt klantenservice-agents uitdrukkelijk als agents die met gebruikers communiceren, en vraagt om de AI kenbaar te maken in de interface, op het moment van interactie.
- De koppeltabel hieronder zet elk onderdeel om in een stap voor een AI-agent in support en het bewijs dat je bewaart.
- Bedien je klanten in de EU, dan is de AI-verordening de bindende laag daarbovenop; de twee overlappen het meest op het kenbaar maken van AI.
Deze uitleg is geschreven op basis van de primaire bron en is geen juridisch advies. Hij valt onder onze gids over AI-agent governance.
Wat is het Model AI Governance Framework for Agentic AI?
Het Model AI Governance Framework for Agentic AI is een document van 53 pagina’s van IMDA dat organisaties “a structured overview of the risks of agentic AI and emerging best practices in managing these risks” geeft. Het is geschreven voor organisaties die AI-agents inzetten, of ze die nu zelf bouwen of agentische oplossingen van derden gebruiken.
| Onderdeel | Wat de bron zegt |
|---|---|
| Exacte titel | Model AI Governance Framework for Agentic AI |
| Uitgever | Infocomm Media Development Authority of Singapore (IMDA) |
| Lancering | Aangekondigd door minister Josephine Teo op het World Economic Forum in Davos, 22 januari 2026 (persbericht van MDDI) |
| Huidige versie | Versie 1.5, gepubliceerd op 20 mei 2026, bijgewerkt op 5 juni 2026 (pdf van IMDA) |
| Wat 1.5 veranderde | Feedback van meer dan 60 bedrijven, nieuwe risicofactoren, risico’s van multi-agentsystemen, monitoring van het override-percentage, wijzigingsbeheer, casestudy’s |
| Bouwt voort op | Het Model AI Governance Framework van IMDA (2020) |
Deel 1 legt uit wat een agent is en wat er mis kan gaan. Deel 2 is het kader zelf, in vier dimensies:
- 2.1 Beoordeel en begrens de risico’s vooraf: geschikte use cases (2.1.1); grenzen, identiteit en rechten van de agent (2.1.2).
- 2.2 Maak mensen betekenisvol verantwoordelijk: verantwoordelijkheden binnen en buiten de organisatie (2.2.1); betekenisvol menselijk toezicht (2.2.2).
- 2.3 Voer technische controles en processen in: controles in het ontwerp (2.3.1), testen vóór de inzet (2.3.2), uitrol, monitoring en wijzigingsbeheer daarna (2.3.3).
- 2.4 Stel eindgebruikers in staat verantwoordelijkheid te nemen: transparantie voor gebruikers die met agents communiceren (2.4.2); training voor gebruikers die met agents werken (2.4.3).
Is het kader van Singapore voor agentische AI verplicht?
Nee. Het kader presenteert zich als richtlijn: het biedt “emerging best practices”, de meeste aanbevelingen luiden “organisations should consider”, en het noemt zichzelf “a living document”. Het persbericht bij de lancering zegt dat het “provides guidance to organisations on how to deploy agents responsibly”. Het kent geen sancties en geen eigen handhavingsmechanisme.
Het document gebruikt het woord “voluntary” niet, dus omschrijf het intern precies: niet-wettelijke richtlijnen van een toezichthouder. Je wettelijke plichten op het gebied van gegevensbescherming, consumentenrecht en sectorregels gelden hoe dan ook, en het kader is duidelijk: “the organisations that deploy agents and the humans who oversee them remain accountable for the agents’ actions.”
Welke risico’s creëren AI-agents volgens het kader?
Het kader noemt vijf soorten schade door agents: foute acties, ongeautoriseerde acties, bevooroordeelde of oneerlijke acties, datalekken en verstoring van gekoppelde systemen. Daarbij komen systemische risico’s door snelheid en volume, doorwerkende fouten en opstellingen met meerdere agents. Elk risico heeft een eenvoudig voorbeeld uit de support.
| Risico in het kader | In de klantenservice |
|---|---|
| Foute acties | De agent betaalt de verkeerde bestelling terug |
| Ongeautoriseerde acties | De agent scheldt kosten kwijt terwijl het beleid daarvoor een supervisor vereist |
| Bevooroordeelde of oneerlijke acties | Tegoeden uit coulance worden vaker aan één groep klanten aangeboden |
| Datalekken | De agent onthult het adres van een andere klant of overschrijft een record |
| Verstoring van gekoppelde systemen | De agent overspoelt het ordersysteem met herhaalde zoekopdrachten |
| Snelheid en volume | Eén gebrekkige instructie herhaalt zich in duizenden gesprekken |
Het eigen voorbeeld van IMDA van een conflict tussen agents is een supportcase: “a customer support agent may offer refunds to resolve complaints quickly, while a revenue protection agent may block refunds above a certain threshold.” Beweeg je richting agentische klantenservice met agents die werk aan elkaar overdragen, dan is dat conflict een ontwerpvraag.
Hoe past elk onderdeel van het kader op een AI-agent in de klantenservice?
Elke dimensie wordt een paar beslissingen voor het supportteam: welke intenties de agent mag afhandelen en met welke rechten, wie eigenaar is en wat goedkeurt, hoe de agent wordt getest en bewaakt, en wat klanten en medewerkers te horen krijgen. De stappen volgen de volgorde van de onderdelen in het kader zelf.
2.1 Beoordeel en begrens de risico’s vooraf
Het kader beoordeelt risico op impact (domein en use case, gevoelige data, externe systemen, lezen of schrijven, omkeerbaarheid) en waarschijnlijkheid (autonomie, complexiteit van de taak, blootstelling aan externe systemen, levering door derden, complexiteit van het systeem). Pas het toe per intentie, niet per bot:
- Deel je intenties in niveaus in. Bestelstatus is alleen lezen. Een terugbetaling is een schrijfactie waar geld aan vastzit. Een account sluiten is moeilijk terug te draaien.
- Pas minimale rechten toe: “the minimum tools and data access needed.” Leesrechten voor de bestelstatus, geen beheerdersrechten in de helpdesk.
- Begrens procestaken met een SOP in plaats van met vrij oordeel. Flows voor terugbetalingen en annuleringen zijn daar precies voorbeelden van.
- Plan hoe je de agent offline haalt voor één intentie of één kanaal, benoem wie dat mag doen en test het.
- Geef de agent een eigen identiteit, gekoppeld aan een menselijke eigenaar, met rechten die nooit groter zijn dan die van de persoon die hem autoriseert.
2.2 Maak mensen betekenisvol verantwoordelijk
Benoem een eigenaar voor use cases en grenzen, een team voor ontwerp, testen en monitoring, en een securityeigenaar voor guardrails en red teaming. Komt de agent van een leverancier, dan vraagt het kader je om security, prestaties en gegevensbescherming in het contract te regelen, en om openheid en logging van het gebruik van tools en de toegangshistorie te vragen. Onze beveiligingschecklist voor AI-QA bevat inkoopvragen die je kunt hergebruiken.
Vereis goedkeuring op “significant checkpoints”: acties met veel op het spel, onomkeerbare acties (het kader noemt het versturen van berichten en het doen van betalingen), afwijkend gedrag en grenzen die de gebruiker zelf heeft gesteld. Controleer vervolgens de goedkeurders met twee indicatoren: het menselijke override-percentage, waarbij “a low rate may signal rubber-stamping”, en de reactietijd, waarbij een korte tijd “may signal automation bias or review fatigue”.
2.3 Voer technische controles en processen in
Geef de voorkeur aan controles die het systeem afdwingt boven controles in de prompt. Het voorbeeld van het kader: “rather than instructing an agent not to use specific tools, access controls can be implemented at the tool layer.” Zet het maximum voor terugbetalingen in de API voor terugbetalingen, niet in de systeemprompt.
Test vóór de lancering de uitvoering van taken, de naleving van beleid (inclusief het doorsturen naar menselijke goedkeuring), het aanroepen van tools en de robuustheid, over de hele workflow, herhaaldelijk en op gevarieerde data. Onze gids over AI-agents testen maakt daar een testplan van. Rol na de lancering geleidelijk uit, monitor doorlopend, stel alertdrempels in met een vastgelegde interventie per drempel, bewaar logs die niet te verwijderen zijn en beoordeel wijzigingen aan modellen, tools en beleid op risico. De gids over AI-agent monitoring behandelt het ontwerp van alerts.
2.4 Stel eindgebruikers in staat verantwoordelijkheid te nemen
Dit onderdeel noemt de klantenservice rechtstreeks. Het kader vraagt je om “declare upfront in the user interface that the users are interacting with agents at the point of interaction, rather than writing it only in separate documentation”, en gebruikers te vertellen wat de agent mag doen, hoe hun gegevens worden gebruikt en met welke mens ze contact kunnen opnemen. Voor medewerkers voegt het training over typische fouten toe en een waarschuwing voor “loss of tradecraft”: houd genoeg mensen in huis die het proces kunnen draaien als de agent uitvalt.
Welk bewijs bewaart een supportteam voor elk onderdeel van het kader?
Bewaar bewijs dat iemand kan controleren zonder het jou te vragen: een register, een ondertekend besluit, een testresultaat, een log, een screenshot. Het kader schrijft geen documenten voor, dus deze tabel is onze vertaling van elk onderdeel naar het record dat een supportteam kan tonen aan een auditor, een toezichthouder of zijn eigen raad van bestuur.
| Onderdeel van het kader | Wat het betekent voor een AI-agent in support | Bewijs om te bewaren |
|---|---|---|
| 2.1.1 Geschikte use cases | Elke intentie ingedeeld op impact en waarschijnlijkheid voordat de agent hem afhandelt | Register van use cases: intentie, niveau, risicofactoren, goedkeurder, datum |
| 2.1.2 Grenzen van de agent en restrisico | Lezen of schrijven per tool, maximumbedragen, SOP’s, een geteste uitschakeling, geaccepteerd restrisico | Rechtenmatrix, versie van de SOP, laatste test van de uitschakeling, ondertekende risicoacceptatie |
| 2.1.2 Identiteit en autorisatie | Eigen inloggegevens, een benoemde eigenaar, geen ruimere rechten dan de autoriserende persoon | Identiteitsregister van agents met eigenaar en reikwijdte van de inloggegevens |
| 2.2.1 Verantwoordelijkheden intern | Eigenaren voor use cases, ontwerp en testen, security, dagelijkse review | RACI, herzien bij elke wijziging |
| 2.2.1 Verantwoordelijkheden extern | Plichten van de leverancier op security, prestaties en data; zicht op het gebruik van tools | Contractbepalingen, verklaringen van de leverancier, bewijs dat je logs kunt exporteren |
| 2.2.2 Menselijk toezicht | Goedkeuringen voor acties met veel op het spel en onomkeerbare acties, telkens met risico en zekerheid erbij | Goedkeuringslog; maandelijks override-percentage en mediane reactietijd per goedkeurder |
| 2.3.1 Technische controles | Grenzen afgedwongen in het systeem; gevoelige data zoals wachtwoorden ingevoerd door de klant, niet verwerkt door de agent | Lijst met controles en waar elke controle wordt afgedwongen |
| 2.3.2 Testen vóór de inzet | Uitvoering van taken, naleving van beleid, aanroepen van tools, robuustheid; volledige workflow; herhaalde runs | Testset, slaagdrempels, resultaten per run, goedkeuring |
| 2.3.3 Uitrol, monitoring, wijzigingen | Gefaseerde uitrol; elk gesprek getoetst aan het beleid; alerts; wijzigingen beoordeeld op risico | Drempels voor de uitrol, QA-scores en alerthistorie, incidentlog, wijzigingslog |
| 2.4.2 Gebruikers die met agents communiceren | AI kenbaar gemaakt in de chat, wat de agent kan doen, gebruik van gegevens, een menselijk contact | Screenshot van de AI-melding per kanaal en taal; pagina in het helpcenter; escalatiepad |
| 2.4.3 Gebruikers die met agents werken | Supervisors getraind in typische fouten; handmatige terugvaloptie behouden | Trainingsregistratie; een oefening met de handmatige terugvaloptie |
Het meeste van dit bewijs veroudert, omdat het kader monitoring als doorlopend werk ziet. En een kleine steekproef is zwak bewijs voor een agent die één gedrag duizenden keren herhaalt. Dat pleit ervoor om elk gesprek aan het beleid te toetsen met een scorecard voor AI-agents.
Hoe stel je goedkeuringsmomenten in zonder alertmoeheid?
Stel goedkeuringen in per risiconiveau, niet per aantal acties, en controleer daarna of goedkeurders nog nadenken. Het kader waarschuwt dat doorlopende menselijke goedkeuring “can also lead to automation bias and alert fatigue”, en noemt twee signalen: een laag override-percentage en korte reactietijden. Het geeft geen drempels, dus die stel je zelf vast.
Een illustratie, met cijfers die we kozen om de rekensom te laten zien (geen data van een bedrijf). De AI-agent van een retailer handelt 40.000 gesprekken per maand af:
| Niveau | Voorbeelden van intenties | Aandeel | Per maand | Rol van de mens |
|---|---|---|---|---|
| 1 | Bestelstatus, levering, adreswijziging vóór verzending | 70% | 28.000 | Geen op het moment zelf; achteraf gescoord |
| 2 | Terugbetalingen en kwijtschelding van kosten | 25% | 10.000 | Goedkeuring alleen boven een terugbetaling van 50 dollar |
| 3 | Account sluiten, juridische klachten, chargebacks | 5% | 2.000 | Agent draagt over; een mens handelt |
Elke terugbetaling op niveau 2 goedkeuren betekent 10.000 verzoeken per maand, ongeveer 455 per werkdag over 22 dagen. Niemand beoordeelt er zoveel met zorg. Ligt 20% van de terugbetalingen boven 50 dollar, dan dalen de goedkeuringen naar 2.000 per maand, ongeveer 91 per dag.
Controleer ze nu. Stel dat goedkeurders 14 van de 2.000 verzoeken afwezen of aanpasten, een override-percentage van 0,7%, met een mediane beslistijd van 3 seconden. Samen passen die bij de beschrijving van afstempelen in het kader. Een beslisregel die wij voorstellen: ligt het override-percentage onder 2% en de mediane beslistijd onder 10 seconden, beoordeel dan een blinde steekproef van 50 goedgekeurde verzoeken opnieuw. Zouden reviewers er meerdere veranderen, maak de verzoeken dan korter, voeg het risico en de zekerheid toe waar het kader om vraagt, of verschuif het maximum.
Niveau 1 heeft helemaal geen goedkeurder, dus het achteraf scoren van elk gesprek is de enige controle op 70% van het volume. De gids over AI-agents evalueren behandelt hoe je die uitkomsten scoort.
Hoe verhoudt het kader zich tot de AI-verordening voor de klantenservice?
De AI-verordening van de EU is bindend recht; het kader van Singapore is een richtlijn. Voor een AI-agent in support overlappen ze het meest op het kenbaar maken van AI: artikel 50, lid 1, van de AI-verordening vereist sinds 2 augustus 2026 dat mensen te horen krijgen dat ze met een AI communiceren, en het kader vraagt hetzelfde op het moment van interactie.
| Onderwerp | MGF for Agentic AI van Singapore | AI-verordening |
|---|---|---|
| Juridische status | Richtlijn, een levend document | Verordening (EU) 2024/1689, bindend in de EU |
| Klanten vertellen dat het een AI is | Kenbaar maken in de interface op het moment van interactie | Een plicht van de aanbieder, vanaf de eerste interactie, tenzij het evident is (FAQ van de Europese Commissie) |
| Benadering van risico | Je eigen beoordeling per use case | Vaste risiconiveaus; een supportagent die met klanten praat valt meestal in het transparantieniveau |
| Menselijk toezicht, testen, monitoring | Uitgewerkt voor elke agent die acties uitvoert | Gedetailleerde plichten vooral voor systemen met een hoog risico; de regels voor bijlage III gelden vanaf 2 december 2027 (pagina van de Europese Commissie over de AI-verordening) |
In de praktijk legt de AI-verordening het minimum in de EU vast, voor een agent die met klanten praat vooral het kenbaar maken van AI, terwijl het kader van Singapore je vertelt hoe je een agent die acties uitvoert beheert. Bouw in beide markten één set controles die aan de AI-verordening voldoet en gebruik de structuur van het kader voor de rest. Ons artikel over de AI-verordening in de klantenservice behandelt de data, risiconiveaus en boetes.
Wanneer dit kader niet goed past
Antwoordt je bot alleen vanuit je eigen helpcenter en voert hij geen acties uit, dan is het meeste van het kader licht werk. De risicofactoren beoordelen alleen-lezen toegang en een intern onderhouden kennisbank als lager risico, dus je hebt vooral de AI-melding nodig, een menselijk contact en kwaliteitscontroles op de antwoorden.
Het kader beschrijft ook geen certificering, dus “voldoet aan het MGF” is geen bewering die iemand voor je kan verifiëren; het bewijs uit de tabel hierboven is wat je kunt laten zien.
Waar past kwaliteitscontrole in het kader?
Kwaliteitscontrole dekt de delen die bewijs uit echte gesprekken vragen: naleving van beleid na de lancering, regelmatige audits, de AI-melding en de terugkoppeling waar het kader om vraagt, “to feed monitoring insights back into training datasets and evaluation frameworks”. Logs laten zien wat de agent deed; een kwaliteitsscore laat zien of hij gelijk had.
Kaizo is één manier om dat deel te doen. Het scoort 100% van de gesprekken van je AI-agent met je eigen scorecard, dezelfde waarop je team wordt beoordeeld, en koppelt elke score aan het bewijs in het gesprek; zie kwaliteitscontrole van AI-agents. Boek een afspraak om het op je eigen gesprekken te zien.
Zo begin je deze week
Je kunt de eerste dimensie en een deel van de vierde in vijf werkdagen afdekken zonder nieuwe tools: wat de agent kan aanraken, wie eigenaar is, wat klanten zien en een eerste controle van je goedkeurders.
- Dag 1: maak een lijst van elke intentie die de agent afhandelt en elke tool die hij kan gebruiken; markeer elke tool als lezen of schrijven.
- Dag 2: deel elke intentie in op impact en omkeerbaarheid; markeer elke schrijfactie met geld of accounts.
- Dag 3: benoem een eigenaar voor de agent en voor elk niveau; schrijf op wie hem kan uitschakelen, en test het.
- Dag 4: open een gesprek in elk kanaal en elke taal; maak een screenshot van de AI-melding en de route naar een mens.
- Dag 5: bereken het override-percentage en de mediane reactietijd van vorige maand per goedkeurder.
Veelgestelde vragen
Is er een pdf van het kader?
Ja. IMDA publiceert het als pdf op imda.gov.sg, met de titel “Model AI Governance Framework for Agentic AI”, versie 1.5. Het telt 53 pagina’s, inclusief casestudy’s, verdere bronnen in bijlage A en een oproep tot feedback in bijlage B.
Geldt het kader voor bedrijven buiten Singapore?
Het kader legt geen territoriale reikwijdte vast. Het is geschreven voor elke organisatie die agentische AI wil inzetten, zelf gebouwd of ingekocht. Bedrijven elders kunnen de structuur gebruiken, maar hun eigen wetgeving bepaalt wat verplicht is.
Vereist het kader dat een mens elk antwoord van een AI-agent goedkeurt?
Nee. Het vraagt om goedkeuring op belangrijke momenten, zoals bij acties met veel op het spel, onomkeerbare of ongebruikelijke acties, en merkt op dat doorlopend toezicht op elke workflow op schaal onpraktisch wordt. Goedkeuringen gaan samen met geautomatiseerde monitoring en alertdrempels.
Wat is er nieuw in versie 1.5?
Versie 1.5 verwerkt feedback van meer dan 60 bedrijven sinds versie 1.0. Het voegt risicofactoren toe zoals de complexiteit van het systeem en oplossingen van derden, risico’s van multi-agentsystemen, werkwijzen tegen automation bias zoals het bijhouden van override-percentages, richtlijnen voor wijzigingsbeheer en casestudy’s.
Kan een bedrijf gecertificeerd worden volgens het kader?
Het document beschrijft geen certificerings- of auditregeling. Het is een set aanbevolen werkwijzen, dus het sterkste wat een bedrijf kan laten zien is zijn eigen bewijs: risiconiveaus, goedkeuringslogs, testresultaten, monitoringrecords en screenshots van de AI-melding.
