Governance

Governance als onderdeel van finance automation

Finance is gebouwd op eenduidigheid. Een bedrag is geboekt of niet geboekt. Een betaling is wel of niet vrijgegeven. Een medewerker is wel of niet bevoegd om een leverancier te wijzigen. AI werkt anders. Een model herkent patronen, interpreteert context en leidt daaruit een waarschijnlijke uitkomst af.

Dat verschil hoeft geen probleem te zijn. Het wordt een probleem wanneer een waarschijnlijke uitkomst zonder duidelijke begrenzing doorwerkt in een financieel proces.

AI-governance wordt daarom vaak vertaald naar beleid, commissies en principes als transparantie, veiligheid en eerlijkheid. Die zijn nodig, maar op zichzelf onvoldoende. Controle ontstaat pas wanneer algemene principes worden omgezet in de inrichting van iedere concrete toepassing: welke bronnen mogen worden gebruikt, wat mag AI afleiden, welke regels mogen nooit worden gepasseerd, welke acties zijn toegestaan en wie draagt verantwoordelijkheid voor de uitkomst?

Dat wordt belangrijker naarmate AI meer kan dan een voorspelling of tekstvoorstel geven. Een AI-agent kan informatie ophalen, hulpmiddelen gebruiken, vervolgstappen plannen en andere agents inschakelen. Daarmee groeit niet alleen de functionaliteit, maar ook de afstand tussen een oorspronkelijke opdracht en de uiteindelijke handeling.

Goede governance moet die afstand overbruggen. Niet door iedere modeluitkomst alsnog in een vaste beslisboom te dwingen, maar door rond de probabilistische AI-laag een controleerbare structuur te bouwen.

De kern daarvan is:

AI mag afleiden wat waarschijnlijk is, maar een deterministische basis bepaalt welke feiten gelden, welke grenzen niet mogen worden overschreden en hoe iedere actie kan worden gereconstrueerd.

Governance gaat over het systeem, niet alleen over het model

Een AI-model verwerkt nog geen financiële transactie. Het ontvangt input en produceert output. De werkelijke werking ontstaat pas wanneer dat model wordt verbonden met documenten, bedrijfsdata, instructies, workflows, gebruikers, integraties en financiële systemen.

Daarom is een beoordeling van alleen het model te beperkt. Eenzelfde model kan in de ene toepassing een tekst samenvatten en in een andere toepassing gegevens wijzigen of een externe communicatie starten. De technische kern kan vergelijkbaar zijn, terwijl het risicoprofiel sterk verschilt.

De relevante eenheid voor governance is dus de volledige toepassing binnen haar procescontext:

• met welk doel wordt AI ingezet;
• welke bronnen en persoonsgegevens zijn toegankelijk;
• welke output kan het model produceren;
• welke procesregels toetsen die output;
• welke handelingen kan het systeem uitvoeren;
• welke gevolgen kan een fout hebben;
• hoe vaak en op welke schaal kan die fout optreden;
• wie kan ingrijpen, corrigeren en verantwoording afleggen?

NIST ordent AI-risicomanagement in vier functies: govern, map, measure en manage. Governance loopt daarbij dwars door de andere functies heen. Binnen het kader worden doel, context en risico’s afgebakend, prestaties en risico’s gemeten en passende maatregelen toegepast. Dat is geen eenmalige toelatingscontrole, maar een doorlopende cyclus gedurende de hele levensduur van de toepassing.

Voor finance sluit die benadering aan op bestaande interne beheersing. Processen hebben al functiescheidingen, autorisaties, toleranties, goedkeuringsroutes, controles en audit trails. AI vraagt niet om een volledig afzonderlijk universum van toezicht. Het vraagt wel om uitbreiding van die beheersing met de specifieke eigenschappen van afgeleide, veranderlijke en soms moeilijk voorspelbare output.

Een deterministische basis

In het vorige artikel is het onderscheid gemaakt tussen regels en AI. Regels leggen vast wat zeker of verplicht is; AI leidt af wat waarschijnlijk of relevant is. Voor governance vormt dat onderscheid het belangrijkste architectuurprincipe.

Niet alles wat technisch door AI kan worden behandeld, moet ook aan AI worden overgelaten. Waar een uitkomst exact berekend, rechtstreeks opgehaald of eenduidig volgens beleid bepaald kan worden, blijft een deterministische verwerking sterker.

Tot die basis behoren onder meer:

• brongegevens: bedragen, valuta, entiteiten, boekingen en andere feiten komen uit aangewezen bronsystemen of documenten;
• berekeningen: totalen, belastingen, saldi en toleranties worden met controleerbare logica berekend;
• beleid en bevoegdheden: limieten, functiescheidingen, verplichte goedkeuringen en toegestane handelingen zijn expliciet vastgelegd;
• processtatus: de workflow bepaalt in welke toestand een transactie zich bevindt en welke overgang mogelijk is;
• identiteit en toegang: iedere gebruiker, integratie of agent handelt met herkenbare en begrensde rechten;
• registratie: uitgevoerde controles, besluiten, wijzigingen en acties worden duurzaam vastgelegd.

AI kan binnen die structuur wel degelijk een belangrijke rol krijgen. Het kan een leverancier herkennen, een boekingsvoorstel doen, mogelijke matches rangschikken of een afwijking signaleren. De AI-uitkomst mag echter niet stilzwijgend de onderliggende feiten of normen vervangen.

Een model kan bijvoorbeeld afleiden dat twee omschrijvingen waarschijnlijk naar dezelfde bestelling verwijzen. De definitieve match kan vervolgens deterministisch worden gecontroleerd op entiteit, valuta, bedrag, openstaand saldo en toegestane tolerantie. Het model brengt context in; de vaste controles bewaken de financiële geldigheid.

De deterministische basis is daarmee niet slechts een noodoplossing voor wanneer AI uitvalt. Zij is de blijvende ruggengraat waaraan de AI-laag haar betekenis en bevoegdheid ontleent.

Wanneer een model geen bruikbare uitkomst levert, hoort het systeem bovendien terug te vallen op een vooraf gedefinieerde veilige toestand. Dat kan een bestaande regelroute, een wachtrij voor beoordeling of het uitblijven van een actie zijn. Een open plek in de proceslogica mag niet door een plausibele modeluitkomst worden opgevuld alleen omdat die beschikbaar is.

Uitlegbaarheid is niet hetzelfde als herleidbaarheid

Bij AI-governance wordt veel nadruk gelegd op uitlegbaarheid. Dat begrip omvat meerdere vragen die voor finance van elkaar moeten worden onderscheiden.

Transparantie gaat over inzicht in het bestaan, doel en gebruik van de AI-toepassing.
Uitlegbaarheid gaat over de werking van het model en de factoren die een uitkomst beïnvloeden.
Interpreteerbaarheid gaat over wat de output in de concrete context betekent.
Herleidbaarheid gaat over het kunnen reconstrueren van de volledige route van bron naar actie.

Voor een financiële controle is vooral die laatste route essentieel. Niet iedere interne relatie in een complex model kan worden teruggebracht tot een beslisregel in gewone taal. Dat hoeft ook niet om het proces als geheel controleerbaar te maken.

Een transactie moet wel kunnen worden herleid tot:

1. de ontvangen brongegevens en hun herkomst;
2. de gegevens en documenten die als context beschikbaar zijn gesteld;
3. de gebruikte model-, instructie- en configuratieversie;
4. de door AI geproduceerde output, score of aanbeveling;
5. de vaste controles en beleidsregels die daarop zijn toegepast;
6. de identiteit en bevoegdheden van het systeem, de agent of de gebruiker;
7. eventuele goedkeuringen, correcties en uitzonderingsbesluiten;
8. de uiteindelijk uitgevoerde handeling en wijziging in het bronsysteem.

Dat is meer dan een technisch logbestand. De registratie moet voldoende betekenis hebben om achteraf te begrijpen welke informatie gold, welke bevoegdheid is gebruikt en waarom het proces een bepaalde route heeft gevolgd.

Een door het model zelf gegenereerde toelichting is daarbij geen sluitend bewijs van zijn werkelijke redeneerproces. Zo’n toelichting kan helpen om een uitkomst te beoordelen, maar blijft zelf gegenereerde output. Een betrouwbare audit trail bewaart daarom de feitelijke input, output, versies, controles en acties. Zij probeert geen zekerheid te creëren door achteraf een overtuigend verhaal te laten formuleren.

Guardrails zijn afdwingbare grenzen

Het woord guardrails wordt veel gebruikt, maar kan gemakkelijk een verzamelnaam worden voor goede bedoelingen. Een instructie als “voer alleen veilige en toegestane acties uit” is geen effectieve beheersmaatregel. Het systeem moet technisch en organisatorisch verhinderen dat een niet-toegestane actie toch wordt uitgevoerd.

Guardrails kunnen op verschillende lagen worden aangebracht:

Deze lagen vullen elkaar aan. Een AI-model kan worden geïnstrueerd om geen bankrekeningnummer te wijzigen, maar het is sterker wanneer de agent technisch geen toegang heeft tot die functie. Een model kan worden gevraagd een bedrag exact over te nemen, maar het is sterker wanneer het bedrag rechtstreeks uit de financiële administratie wordt opgehaald en na generatie opnieuw wordt gecontroleerd.

Dit leidt tot een eenvoudig ontwerpprincipe:

Een prompt kan gedrag sturen; een externe controle moet bevoegdheid begrenzen.

Daarbij hoort het principe van minimale bevoegdheid. Een AI-toepassing krijgt alleen toegang tot de gegevens en handelingen die nodig zijn voor haar afgebakende doel. Leesrechten, schrijfrechten en goedkeuringsrechten worden niet gemakshalve samengevoegd. Tijdelijke taken kunnen tijdelijke rechten krijgen, en rechten kunnen per entiteit, processtap, bedrag of gegevenstype worden beperkt.

Guardrails mogen ook niet uitsluitend rond de uiteindelijke output staan. Een document of e-mail die door een agent wordt gelezen, kan tekst bevatten die probeert de oorspronkelijke opdracht te beïnvloeden. NIST noemt indirecte prompt injection als een specifiek beveiligingsrisico bij agents. Externe inhoud moet daarom als data worden behandeld, niet als nieuwe bevoegdheid of procesinstructie. Een ontvangen factuur kan informatie aanleveren, maar mag niet bepalen welke systeemrechten de verwerkende agent gebruikt.

Van model naar agent

Bij traditionele AI is de kleinste bestuurlijke eenheid vaak een afzonderlijke uitkomst: een classificatie, score of gegenereerde tekst. Bij een agent verschuift die eenheid naar een reeks handelingen.

Een agent kan bepalen welke informatie nodig is, een bron raadplegen, een hulpmiddel gebruiken, het resultaat beoordelen en een vervolgstap kiezen. Een multi-agentsysteem kan die taak verder verdelen. De ene agent verzamelt gegevens, een andere beoordeelt een afwijking en een derde bereidt een procesactie voor.

Dat maakt de oplossing flexibeler, maar introduceert nieuwe vragen:

• welke agent heeft de opdracht geïnitieerd;
• welke agent heeft welke informatie toegevoegd of gewijzigd;
• met welke identiteit en rechten is iedere actie uitgevoerd;
• mag een agent zijn opdracht of rechten aan een andere agent delegeren;
• hoe wordt voorkomen dat meerdere afzonderlijk toegestane stappen samen een niet-toegestane uitkomst opleveren;
• wie bewaakt lussen, onverwachte routes en opstapelende acties;
• welke agentversies en instructies waren tijdens de uitvoering actief?

De interactie tussen agents mag geen zwart gat in de audit trail worden. Iedere agent heeft daarom een eigen technische identiteit, een afgebakend doel en expliciete rechten nodig. Een gedeeld systeemaccount maakt niet zichtbaar welke schakel een handeling initieerde en vergroot de kans dat bevoegdheden onbedoeld worden doorgegeven.

Ook delegatie moet begrensd zijn. Een agent kan een deeltaak aan een andere agent geven, maar mag daarbij niet meer bevoegdheid overdragen dan hij zelf voor die taak bezit. De ontvangende agent krijgt evenmin automatisch toegang tot alle bronnen die voor de initiërende agent beschikbaar zijn. Iedere overdracht bewaart de oorspronkelijke opdracht, het toegestane doel, de gedelegeerde rechten en de resultaten die terugkomen.

Zo ontstaat een herleidbare actieketen:

opdracht → agent → bron of hulpmiddel → tussenresultaat → volgende agent → controle → procesactie

De keten mag dynamisch zijn, maar de bevoegdheden en registratie eromheen zijn dat niet onbeperkt.

Een agent kan handelen, maar geen verantwoordelijkheid dragen

De term agent nodigt uit om software als een zelfstandige medewerker te beschouwen. Technisch kan een agent inderdaad een rol vervullen en handelingen uitvoeren. Organisatorisch kan hij echter geen verantwoordelijkheid aanvaarden, beleid vaststellen of verantwoording afleggen.

Dat blijft het werk van mensen en organisaties.

Naarmate meer onderdelen samenwerken, kan eigenaarschap gemakkelijk versnipperen. De proceseigenaar verwijst naar het technische team, het technische team naar het gebruikte model en de leverancier naar de manier waarop de organisatie de toepassing heeft ingericht. Juist dan is vooraf duidelijk eigenaarschap nodig.

Een werkbare verdeling bevat verschillende verantwoordelijkheden:

De precieze functienamen verschillen per organisatie. Belangrijker is dat voor iedere toepassing één herkenbare eigenaar verantwoordelijk blijft voor de toegestane inzet en de end-to-end uitkomst. Componentverantwoordelijkheid mag niet leiden tot een proces zonder eindverantwoordelijke.

Ook de leverancier van een model of platform neemt het eigenaarschap van de toepassing niet automatisch over. Een derde partij is verantwoordelijk voor de overeengekomen dienst en informatie, maar de organisatie bepaalt in welke context het systeem wordt gebruikt, welke data het ontvangt en welke handelingen eraan worden gekoppeld. Contracten moeten daarom duidelijkheid geven over wijzigingen, beveiligingsincidenten, datagebruik, beschikbaarheid, ondersteuning en aansprakelijkheid.

Leg niet alleen het model vast, maar de toepassing

Een modelregister is niet voldoende wanneer hetzelfde model in tientallen processen wordt gebruikt. De relevante risico’s ontstaan vooral door het doel, de context, de verbonden bronnen en de toegestane acties.

Een AI-inventaris moet daarom op toepassingsniveau ten minste vastleggen:

• het doel en het bedoelde gebruik;
• expliciet uitgesloten gebruik;
• de proces- en systeemeigenaar;
• het gebruikte model en de actuele versie;
• gebruikte gegevensbronnen en categorieën gegevens;
• mogelijke outputs en toegestane acties;
• de mate van autonomie;
• vaste controles, guardrails en menselijke controlemomenten;
• prestatie- en risicomaatstaven;
• afhankelijkheden van leveranciers en andere agents;
• procedures voor incidenten, terugval en beëindiging.

Zo’n inventaris is geen administratieve bijzaak. Zonder overzicht is niet bekend waar een modelwijziging doorwerkt, welke toepassingen dezelfde bron of leverancier delen en waar risico’s zich kunnen opstapelen. Een ogenschijnlijk kleine wijziging in een algemeen model kan meerdere financiële processen tegelijk raken.

Ook schaduwgebruik hoort daarbij. Wanneer medewerkers zelfstandig AI gebruiken met financiële gegevens of gegenereerde output overnemen in rapportages, ontstaat procesinvloed buiten de formeel ingerichte toepassingen. Governance moet daarom niet alleen goedgekeurde systemen registreren, maar ook duidelijk maken welk gebruik toegestaan is en hoe nieuwe toepassingen kunnen worden aangemeld en beoordeeld.

Autonomie volgt uit risico, niet uit intelligentie

Een model dat zeer nauwkeurig presteert, hoeft niet automatisch meer handelingsvrijheid te krijgen. De toegestane autonomie wordt bepaald door de gevolgen van de handeling, niet alleen door de kwaliteit van de voorspelling.

Daarbij zijn onder meer relevant:

• de financiële materialiteit van een fout;
• de mogelijkheid om de handeling terug te draaien;
• het effect op klanten, leveranciers of medewerkers;
• de gevoeligheid van de gebruikte gegevens;
• de snelheid en schaal waarop acties kunnen worden herhaald;
• de mate waarin een benadeelde de uitkomst kan begrijpen en betwisten;
• de afhankelijkheid van andere modellen, agents en externe diensten.

Het genereren van een interne samenvatting heeft een ander risicoprofiel dan het wijzigen van leveranciersgegevens. Een boekingsvoorstel dat nog deterministisch wordt gecontroleerd, heeft een ander risicoprofiel dan een externe betaling. Dezelfde modelkwaliteit kan dus tot een andere toegestane autonomie leiden.

Een organisatie kan die autonomie stapsgewijs indelen:

1. signaleren: AI maakt informatie zichtbaar;
2. adviseren: AI doet een voorstel, zonder de processtatus te wijzigen;
3. voorbereiden: AI zet een handeling klaar binnen een gecontroleerde workflow;
4. uitvoeren binnen grenzen: het systeem handelt automatisch wanneer alle vaste voorwaarden zijn vervuld;
5. zelfstandig orkestreren: een agent bepaalt meerdere stappen en voert deze uit binnen een strikt afgebakend mandaat.

Een hoger niveau is niet per definitie beter. Het passende niveau hangt af van doel, impact en beheersbaarheid. Een proces kan bovendien verschillende niveaus combineren: zelfstandig informatie verzamelen, een voorstel voorbereiden en voor een materiële handeling terugkeren naar een vaste goedkeuringsroute.

De precieze rol en effectiviteit van menselijke tussenkomst komt uitgebreider aan bod in het volgende artikel. Voor governance is hier vooral van belang dat autonomie expliciet wordt toegekend en niet ongemerkt ontstaat doordat steeds meer hulpmiddelen aan een agent worden gekoppeld.

Test de procesuitkomst, niet alleen de AI-output

Een model kan op een testset goed presteren en toch een onbetrouwbaar proces opleveren. De kwaliteit van de toepassing hangt ook af van de brondata, instructies, controles, integraties en manier waarop gebruikers met de output omgaan.

Testen vóór ingebruikname moet daarom meerdere niveaus omvatten:

• werkt het model voor het afgebakende doel en de relevante procesvarianten;
• zijn foutpositieven en foutnegatieven afzonderlijk beoordeeld;
• blijven vaste controles en bevoegdheden effectief bij onverwachte output;
• kan onjuiste, onvolledige of manipulatieve input de agent tot een niet-toegestane actie brengen;
• functioneren terugval, blokkade en veilige stop;
• blijft de volledige actieketen reconstrueerbaar;
• begrijpen gebruikers de betekenis en beperkingen van de output?

Daarna blijft monitoring nodig. De verdeling van documenten, klanten, leveranciers en transacties kan veranderen. Brondata kan van structuur of betekenis veranderen. Een model, prompt, koppeling of achterliggende kennisbron kan worden aangepast. Ook gebruikers kunnen steeds meer op een systeem gaan vertrouwen wanneer het meestal goed functioneert.

Relevante signalen zijn daarom breder dan gemiddelde nauwkeurigheid. Denk aan prestaties per categorie, de aard van fouten, correcties door gebruikers, afwijkingen van vaste controles, onverwachte toolaanroepen, geweigerde acties, procesuitval, doorlooptijd en incidenten. Bij agents komen daar afgebroken taken, herhalende lussen, ongebruikelijke delegaties en snel oplopend verbruik bij.

Iedere materiële wijziging hoort onder change management te vallen. Niet alleen een nieuw model, maar ook een andere prompt, databron, autorisatie, drempelwaarde, tool of agentrelatie kan het gedrag van de toepassing veranderen. Versiebeheer en gerichte hertesten maken zichtbaar welke verandering aan een nieuwe uitkomst voorafging.

Governance eindigt evenmin bij ingebruikname. Er moeten criteria bestaan om de toepassing te beperken, terug te zetten, tijdelijk te stoppen of definitief uit te faseren. Een noodstop is pas bruikbaar wanneer het systeem daarna in een veilige en uitvoerbare toestand terechtkomt.

Regelgeving is een ondergrens, geen ontwerpmodel

De Europese AI Act gebruikt een risicogebaseerde benadering. Niet iedere toepassing van AI binnen finance is een hoog-risicosysteem. Het gebruik voor het beoordelen van de kredietwaardigheid van natuurlijke personen is bijvoorbeeld expliciet als hoog risico aangemerkt, met een uitzondering voor fraudedetectie. Veel operationele toepassingen binnen finance vallen niet automatisch in die categorie.

Voor hoog-risicosystemen bevat de AI Act eisen rond onder meer risicomanagement, datagovernance, logging, informatie voor gebruikers, menselijke controle, nauwkeurigheid, robuustheid en cybersecurity. Die onderwerpen zijn ook buiten de formele hoog-risicocategorie bruikbaar als ontwerpvragen, maar de precieze wettelijke verplichtingen hangen af van de toepassing en de rol van de organisatie als aanbieder of gebruiker.

AI-governance kan daarom niet worden gereduceerd tot één classificatie of compliancecheck. Een toepassing die volgens de AI Act niet als hoog risico geldt, kan nog steeds materiële financiële, privacy-, beveiligings- of reputatierisico’s veroorzaken. Bestaande eisen rond gegevensbescherming, informatiebeveiliging, financiële verslaggeving, fiscale verplichtingen en interne beheersing blijven eveneens van toepassing.

Omgekeerd is maximale beheersing niet voor iedere toepassing nodig. NIST en financiële modelrisicokaders benadrukken beide een risicogebaseerde aanpak: zwaardere gevolgen vragen om strengere toetsing, monitoring en verantwoordelijkheid. De herziene Amerikaanse richtlijn voor modelrisicomanagement uit 2026 sluit generatieve en agentic AI expliciet uit van haar formele reikwijdte, maar illustreert wel een relevant onderscheid: doel, gebruik en materialiteit bepalen hoeveel beheersing gerechtvaardigd is.

Regelgeving geeft dus een ondergrens. De organisatie moet daarboven zelf bepalen welk gedrag zij verantwoord vindt en welke mate van onzekerheid past bij een financieel proces.

Governance maakt schaalbare AI mogelijk

Governance wordt soms tegenover snelheid en innovatie geplaatst. In finance geldt eerder het omgekeerde. Zonder heldere kaders blijft AI steken in losse pilots, omdat niemand precies weet welke data gebruikt mogen worden, welke uitkomsten vertrouwd kunnen worden en wie een toepassing naar productie mag brengen.

Een deterministische basis, herbruikbare guardrails, een toepassingsregister en vaste eigenaarschapspatronen maken nieuwe toepassingen juist eenvoudiger te beoordelen. Niet iedere use case hoeft dan opnieuw te beginnen met fundamentele vragen over toegang, logging, testen en incidenten.

Dat ondersteunt de drie doelen van intelligente finance automation:

Performance vraagt om de mogelijkheid om AI veilig op grotere schaal en met minder ad-hoccontrole in processen te gebruiken.

Compliance vraagt om aantoonbare regels, bevoegdheden, controles, registratie en verantwoordelijkheid.

Intelligence vraagt om ruimte voor modellen om context en patronen af te leiden zonder die waarschijnlijkheden als vaststaande feiten te behandelen.

De balans ontstaat niet door AI volledig vrij te laten of juist terug te brengen tot klassieke regels. Zij ontstaat door beide soorten logica hun eigen rol te geven.

Regels bepalen wat geldt en wat mag. AI interpreteert wat waarschijnlijk en relevant is. Workflows toetsen en regisseren hoe die uitkomst doorwerkt. Financiële systemen bewaren de feiten. Mensen en organisaties blijven verantwoordelijk voor het ontwerp, de bevoegdheden en de gevolgen.

Dat is de essentie van AI onder controle:

Niet iedere AI-uitkomst hoeft deterministisch te zijn, maar iedere financiële actie moet begrensd, herleidbaar en aan een verantwoordelijke eigenaar gekoppeld zijn.