Menselijke goedkeuring van AI in finance begint bij het goedkeuringsverzoek

Veertig goedkeuringen kostten iets meer dan drie minuten. We zaten naast een controller terwijl ze de ochtendwachtrij van een nieuwe factuurworkflow afwerkte, en vroegen haar daarna wat ze bij elke post had gecontroleerd. Ze dacht even na en was eerlijk: het bedrag, en of de naam van de leverancier haar bekend voorkwam.

Ze was niet slordig. Het scherm toonde de volledige factuur als afbeelding, twintig uitgelezen velden, de voorgestelde codering en een knop om goed te keuren. Nergens stond waarom een post in haar wachtrij terecht was gekomen, dus controleerde ze wat snel te controleren viel. In de auditlog stonden veertig goedkeuringen door een bij naam genoemde controller. In werkelijkheid had het model veertig facturen goedgekeurd, met de naam van een medewerker eronder.

Palantir beschrijft in "Connecting Agents to Decisions" (april 2026) het patroon dat de meeste platforms inmiddels gebruiken: een AI zet een actie klaar en een mens voert haar door. Of dat werkt, wordt bepaald door het moment daartussen. Wat ziet de mens als hem wordt gevraagd de actie door te voeren, en hoe lang kijkt hij echt?

Eén goedkeuringsverzoek per reden voor beoordeling

Een goedkeuringsscherm dat het hele record toont, laat de beoordelaar zelf het probleem zoeken. Maar het probleem vinden was de taak van het systeem. We vervangen de recordweergave daarom door een goedkeuringsverzoek dat om één vraag draait.

Het verzoek begint met één regel die zegt welk besluit nodig is en waarom het geval is tegengehouden: "De prijs op regel 3 ligt boven de contractprijs voor deze leverancier." Daaronder staan naast elkaar het veld dat de beoordeling veroorzaakte, de aangetroffen waarde en de verwachte waarde. Dan volgt de onderbouwing voor alleen dat punt: de contractbepaling, de inkooporderregel en de laatste drie facturen van deze leverancier voor dit artikel. Het volledige record is één klik verder, maar niet het eerste wat op het scherm staat.

Is een geval om twee redenen tegengehouden, dan zijn er twee verzoeken. Is een geval tegengehouden omdat een document onleesbaar was, dan toont het verzoek het onleesbare deel, niet de hele pagina.

Laat zien wat anders is, niet wat er staat

Beoordelaars werken sneller en nauwkeuriger als ze vergelijken dan als ze lezen. Elk verzoek zet het geval daarom naast het meest vergelijkbare eerdere geval: het laatst goedgekeurde geval van dezelfde leverancier voor hetzelfde type document. Velden die niet zijn veranderd, zijn ingeklapt. Velden die wel zijn veranderd, zijn gemarkeerd. Een nieuw bankrekeningnummer, een andere eenheid, een verschoven prijs: precies wat een controller op papier zou opvallen als ze er de tijd voor had, staat op de plek waar haar blik het eerst valt.

De confidencescore van het model laten we weg. Een beoordelaar die een hoog getal ziet, controleert minder.

Of gevallen samen mogen, hangt af van de gevallen zelf

Posten één voor één goedkeuren is traag, en binnen een week vragen controllers om een knop voor bulkgoedkeuring. Bij bulkgoedkeuring houdt de beoordeling ongemerkt op, dus het scherm biedt die knop niet aan. Gevallen moeten het samen goedkeuren verdienen.

Gevallen kunnen alleen samen worden goedgekeurd als ze om dezelfde reden zijn tegengehouden, op elk veld behalve het veld dat wordt goedgekeurd overeenkomen met hetzelfde eerdere geval, en binnen een bedragsgrens vallen die de controller heeft vastgesteld. Tien facturen van één leverancier met elk dezelfde prijsverhoging op hetzelfde contract zijn één besluit. Dezelfde leverancier met tien verschillende redenen zijn tien besluiten.

Elke afwijking krijgt een reden

Past een beoordelaar de voorgestelde actie aan, dan vraagt het systeem waarom, met een korte keuzelijst die met finance is afgesproken: verkeerde codering, prijs buiten het contract om afgesproken, dubbele factuur, fout van de leverancier, overig met toelichting. Een vrij tekstveld wordt genegeerd. Een korte keuzelijst wordt wel gebruikt.

Deze redenen zijn de waardevolste gegevens die het systeem na de livegang oplevert. Ze laten zien welke regels niet kloppen, welke leveranciers veranderen en voor welke segmenten verwerking zonder tussenkomst niet langer verantwoord is.

De beoordelingsinspanning wordt gemeten

We meten de beoordeling zelf: de tijd per verzoek, of de onderbouwing is geopend, hoe vaak de voorgestelde actie wordt aangepast en hoe vaak een goedkeuring later wordt teruggedraaid. Niets daarvan wordt gebruikt om mensen te beoordelen. Het dient om de beheersmaatregel te beoordelen.

Een beoordelingsmoment waarop week na week elk geval binnen een paar seconden ongewijzigd wordt goedgekeurd, voegt geen oordeel toe. Ofwel hebben de gevallen geen mens nodig en kan het beoordelingsmoment worden vervangen door een geautomatiseerde controle, ofwel laat het verzoek niet zien wat de mens nodig heeft. In beide gevallen is het een ontwerpprobleem, en in geen van beide gevallen helpt het om beoordelaars te vragen beter op te letten.

Voor de livegang behandelen beoordelaars in een schaduwomgeving ook gevallen waarvan het juiste antwoord al bekend is, waaronder een paar die moeten worden afgewezen. Zo blijkt, voordat er echt geld mee gemoeid is, of het verzoek een fout antwoord zichtbaar maakt.

Goedkeuring wordt vastgelegd zoals elke financiële beheersmaatregel

Wie goedkeurt, is nooit het systeem dat het geval heeft voorbereid, en bij betalingen en crediteurenstamgegevens nooit de persoon die de wijziging heeft aangevraagd. Elke goedkeuring wordt vastgelegd met de beoordelaar, het tijdstip, het verzoek zoals het werd getoond, de geopende onderbouwing en de reden voor een eventuele aanpassing. Vraagt een auditor hoe de beheersmaatregel heeft gewerkt, dan is het antwoord wat de beoordelaar te zien kreeg, niet alleen dat er is geklikt.

Om dezelfde reden bieden we geen goedkeuring aan via een antwoord op een e-mail of een knop in een chat. Dan verdwijnt de onderbouwing uit het besluit en blijft alleen de handtekening over.

De naam in de log moet iets betekenen

Een beoordelingsmoment waar niemand echt naar kijkt, is erger dan geen beoordelingsmoment, want het levert een vastlegging op die zegt dat iemand heeft gecontroleerd. Ontwerp het goedkeuringsverzoek zo dat de naam in de auditlog weergeeft wat er werkelijk is gebeurd.