Voordat u een proces automatiseert met AI, bepaalt u hoe fout het mag zijn. Niet of het fout gaat. Dat gebeurt. Drie antwoorden beslechten het grootste deel van de discussie: welke foutmarge u accepteert, hoe snel een fout wordt opgemerkt, en wat één gemiste zaak kost om te herstellen. De meeste AI-automatiseringsprojecten schrijven dat nooit op en vallen terug op een onuitgesproken norm die niemand kan halen: het mag nooit fout gaan.
Hoe nauwkeurig moet een AI-systeem eigenlijk zijn?
Als ik dat in een eerste gesprek vraag, is het antwoord vrijwel altijd een variant op "nou, het moet gewoon kloppen." Begrijpelijk. Dat wil iedereen. Vraag één keer door en het schuift: "honderd procent hoeft natuurlijk niet, maar u snapt wel wat ik bedoel." Dat snap ik niet. De klant zelf ook nog niet. In dat gat verdwijnen opvallend veel projecten.
Het probleem met "het moet kloppen" is dat het geen specificatie is. Het is een stemming. U kunt niet testen tegen een stemming, u kunt het niet aftekenen, en het schuift het volledige risico naar degene die het gebouwd heeft. Een half jaar later vindt iemand drie verkeerde facturen op vierhonderd, en de vraag in de kamer is niet of 0,75% binnen de afspraak valt, want er is niets afgesproken. De vraag is: "dus het werkt niet."
Ik heb een systeem met een werkelijk goede foutmarge om precies die reden zien uitzetten, terwijl het handmatige proces dat het verving jarenlang méér fouten maakte, onzichtbaar. Die had nooit iemand geteld. Er was geen getal om op terug te vallen, dus was er geen verweer.
Wat leren de Nederlandse dijknormen u over AI-automatisering?
Er bestaat in dit land een denkgewoonte die dit in één middag zou oplossen, en die heeft niets met technologie te maken.
De kern van de Deltabeslissing Waterveiligheid is een getal. De kans om te overlijden door een overstroming mag voor iedereen achter de dijken uiterlijk in 2050 niet groter zijn dan 1 op 100.000 per jaar. Dat is het basisbeschermingsniveau. De normen voor de primaire waterkeringen zijn vastgelegd in de Waterwet en gelden sinds 1 januari 2017; de Waterwet zelf is op 1 januari 2024 opgegaan in de Omgevingswet. Het Deltaprogramma noemt het cijfer gewoon op zijn eigen site.
Lees dat eens als een bedrijfsdocument in plaats van een waterdocument. Een land waarvan het hele bestaan van die keringen afhangt, heeft niet opgeschreven "de dijken moeten het houden." Het heeft een faalkans opgeschreven. Hardop, in de wet, met een jaartal eraan.
En het ging verder. Het vereiste niveau is strenger waar de gevolgen erger zijn: waar veel slachtoffers kunnen vallen, waar de economische schade groot zou zijn, waar infrastructuur van nationaal belang achter de kering ligt. De norm is geen eigenschap van de dijk. Het is een eigenschap van wat achter de dijk ligt.
Dat is precies wat ik een klant mee wil geven in een AI-project. U bent niet roekeloos als u een acceptabele foutmarge benoemt. U bent roekeloos als u dat weigert, want de foutmarge is hoe dan ook wat hij is. Het enige verschil is dat niemand heeft besloten of die aanvaardbaar is, en dat niemand telt.
Nog één detail dat mij elke keer scherp houdt. De eerste Landelijke Beoordelingsronde liep van 2017 tot 2022, en de conclusie was dat een meerderheid van de normtrajecten, de stukken waarin de keringen voor de beoordeling zijn opgedeeld, nog niet aan de normen voldoet. Van de ongeveer negen miljoen mensen die achter een primaire kering wonen, had circa 80% in 2020 het basisbeschermingsniveau; naar verwachting is dat in 2029 gestegen tot ongeveer 82%. Dat is gewoon gepubliceerd. De norm is niet stilletjes bijgesteld naar de dijken die er toevallig lagen. Precies weten waar u onder uw eigen norm zit, is iets heel anders dan geen norm hebben, en het is een stuk bruikbaarder.
Wat gebeurt er als de AI het fout heeft?
Dit is de vraag die ongeveer de helft van de projecten waarover ik word gebeld beëindigt, en dat bedoel ik als compliment aan de vraag.
Niet alle fouten hebben dezelfde vorm. Het onderscheid dat het werk doet is niet ernst in het algemeen. Het is herstelbaarheid. Loop het proces dus stap voor stap door en sorteer.
- Een concept dat een medewerker bewerkt voordat het ergens heen gaat.
- Een prijsvoorstel dat iemand goedkeurt.
- Een classificatie die een document in de verkeerde wachtrij zet en die wordt verplaatst.
Dat is goedkoop. De fout komt binnen enkele minuten boven water en de kosten van de fout zijn de kosten van de correctie. Er gebeurt verder niets.
Daartegenover: een vrijgegeven betaling, een bericht dat een klant heeft bereikt, een voorraadcorrectie die is doorgerold naar drie systemen verderop, een boeking in een grootboek dat u maandelijks afsluit. Hier stopt de fout niet waar hij is gemaakt. Hij wordt invoer voor iets anders, en tegen de tijd dat u hem vindt corrigeert u niet één regel maar reconstrueert u een week.
Ik zeg mensen niet dat ze de tweede categorie niet moeten automatiseren. Ik zeg dat de acceptabele foutmarge daar een ander getal is dan bij de eerste, en dat u dat getal vrijwel nooit haalt met een beter model. U haalt het met een smaller proces. Beperk waar het systeem aan mag komen. Zet een grens op het bedrag waarover het zonder tweede paar ogen mag beslissen. Leer het de afwijkende zaak te weigeren in plaats van te gokken. Een systeem dat 12% van de gevallen weigert en over de andere 88% gelijk heeft, is veel meer waard dan een systeem dat overal een mening over heeft.
Over de technische kant hiervan schreven we eerder in een stuk over het vierogenprincipe, audit trails en idempotentie: de machinerie die een verkeerde stap terugdraaibaar maakt. Dit essay gaat over het besluit dat vóór die machinerie komt.
Wie vangt de fout op, en hoe snel?
Nauwkeurigheid krijgt alle aandacht. De snelheid waarmee u een fout opmerkt doet het meeste werk.
Een foutmarge van 3% waarbij elke misser dezelfde dag zichtbaar is, is een werkbaar bedrijf. Een foutmarge van 1% die pas bij de jaarcontrole opduikt, is een slecht kwartaal en een ongemakkelijk gesprek met uw accountant. Het tweede systeem is drie keer zo nauwkeurig en veel gevaarlijker, want die fouten hadden elf maanden de tijd om iets anders te worden.
In elke ontwerpsessie wil ik daarom weten wie de uitkomst ziet, in welke staat, en op welke dag. Is het antwoord "het systeem boekt het en wij kijken bij de maandafsluiting naar de totalen", dan voeren we eigenlijk geen automatiseringsgesprek. Dan voeren we een gesprek over interne beheersing, en dat wil ik liever eerst voeren, want automatisering veroorzaakt die zwakte niet. Ze versnelt hem alleen.
Het goedkoopste instrument is bijna altijd een steekproef. Geen volledige controle, die houdt geen enkel team langer dan drie weken vol. Een vaste, kleine, saaie steekproef: twintig gevallen per week, dezelfde dag, dezelfde persoon, vastgelegd op een plek die geen mailbox is. Binnen een maand hebt u een echt percentage, en u hebt iets wat bijna geen bedrijf heeft: een getal om volgend kwartaal mee te vergelijken.
Wat is een acceptabele foutmarge bij AI-automatisering?
Waar u ook op uitkomt, kom er niet op uit door te vergelijken met perfectie. Vergelijk met het proces dat u werkelijk hebt.
Vrijwel elk bedrijf waar ik zit vergelijkt een voorgesteld AI-systeem met een gedachte versie van het eigen werk, waarin niemand een cijfer omdraait, niemand ziek is en niemand dit om 17.40 uur op een vrijdag voor een vakantie zit te doen. Die versie bestaat niet. De echte heeft een foutmarge. Die is bijna nooit nul en bijna nooit bekend.
De eerste taak is dus uw eigen getal vinden, of een eerlijke bandbreedte eromheen. Soms ligt het al ergens in een systeem dat u zelf bezit: uitgestuurde creditnota's, herstelde orders, geboekte correcties, geregistreerde klachten, facturen waarover klanten belden. Soms is er helemaal niets en neemt u vier weken lang een steekproef. In beide gevallen hebt u daarna de enige vergelijking die iets betekent.
Leg de ondergrens vervolgens vast vóórdat u resultaten ziet. Ik heb elders geschreven over wat u in een AI-pilot moet meten, en juist die gewoonte beschermt u het meest. Een grens die achteraf wordt gekozen is geen norm. Het is een rechtvaardiging, en iedereen in de kamer voelt dat.
Houd er ook rekening mee dat het antwoord de andere kant op ongemakkelijk kan uitvallen. Ik heb in kamers gezeten waar de gemeten menselijke foutmarge veel hoger lag dan iedereen in het bedrijf had verwacht, en waar de eerlijke conclusie was dat het proces gerepareerd moest worden vóórdat er iets bovenop werd geautomatiseerd. Dat is geen mislukt project. Dat is een project dat iemand net veel geld heeft bespaard, en het is een van de redenen dat zoveel AI-pilots stranden op weg naar het dagelijkse werk om redenen die niets met het model te maken hebben.
Verandert het uitstel van de AI Act hier iets aan?
Kort iets over de regelgeving, want die wordt gelezen als ademruimte en dat is ze niet.
De Digital Omnibus verschoof de toepassingsdatum voor zelfstandige hoog-risicosystemen onder bijlage III van 2 augustus 2026 naar 2 december 2027, en voor hoog-risicosystemen die in gereguleerde producten zijn ingebouwd van 2 augustus 2027 naar 2 augustus 2028. De toepassingsdata van een aantal andere verplichtingen bewogen niet mee: de verboden van artikel 5, de transparantieverplichtingen van artikel 50, en de verplichtingen voor aanbieders van AI voor algemene doeleinden. De Raad en het Parlement beschrijven het vereenvoudigingspakket zelf.
Wacht u tot december 2027 met nadenken over menselijk toezicht, dan hebt u verkeerd begrepen waar een deadline voor dient. De verordening is een ondergrens, en dan nog alleen voor een deel van de systemen. Ze zegt helemaal niets over de offerte die uw systeem vorige dinsdag verkeerd prijsde. Uw klant kijkt niet eerst in bijlage III voordat hij besluit of hij u nog eens belt. De verplichtingen die een kleiner bedrijf werkelijk raken houden wij bij op onze AI Act-checklist voor het mkb, en geen daarvan vervangt het kennen van uw eigen foutmarge.
Moet u een proces automatiseren dat u niet kunt controleren?
Nee. Dat is het kortste advies dat ik geef, en het advies waarover mensen het vaakst een second opinion willen.
Als er geen praktische manier is om binnen een redelijke termijn vast te stellen of een uitkomst klopte, dan stapelt het systeem fouten op tegen een onbekend tempo gedurende een onbekende periode, en hoort u het uiteindelijk van een klant. Dat is geen AI-risico. Dat is een proces dat al kwetsbaar was en dat op het punt staat op snelheid te worden gedraaid.
De oplossing is niet het idee laten varen. De oplossing is eerst de controle bouwen. Soms blijkt die controle het hele project te zijn en is de automatisering daarna bijna triviaal. Ik heb opdrachten gehad waarin het werkelijk bruikbare resultaat een rapportage was die nog niemand had, die de huidige foutmarge voor het eerst zichtbaar maakte, waarna de klant besloot dat de automatisering een kwartaal kon wachten. Prima. Dan doet het werk precies wat werk hoort te doen.
Het is ook de reden dat ik wantrouwig word van een demo die indruk maakt. Een demo is een steekproef van één, gekozen door degene die hem laat zien, op een geval waarvan hij al weet dat het goed gaat. Het gat tussen dat moment en een dinsdag in november is het hele werk, en daarom bewijst een goede demo zo weinig over de implementatie.
De drie zinnen die ik een klant laat opschrijven
Voordat er iets wordt gebouwd, wil ik deze drie op papier, in de woorden van de klant en niet in de mijne.
- "Dit systeem mag er in ongeveer N van de honderd gevallen naast zitten."
- "Als het misgaat, ziet [naam] dat binnen [termijn], omdat [mechanisme]."
- "Eén fout geval kost ons [bedrag of inspanning] en is [wel of niet terug te draaien]."
Kunnen die drie worden ingevuld, dan heeft het project een ruggengraat. Elk meningsverschil daarna gaat over getallen in plaats van over gevoel, en dat is op een donderdagmiddag een aanzienlijk prettiger soort meningsverschil. Kunnen ze niet worden ingevuld, dan hebt u zojuist de werkelijke eerste taak gevonden, en daar komt geen bouwwerk aan te pas.
Dit land had er enkele decennia en één ramp voor nodig om tot hetzelfde principe voor zijn dijken te komen. Benoem het falen dat u accepteert. Weeg het naar wat er achter de kering ligt. Publiceer waar u eronder zit. Ga daarna aan het gat werken, in die volgorde. Het is geen comfortabele manier om een project te openen. Het is de enige die ik ken die een project goed afsluit.
Wilt u een tweede paar ogen op de vraag welke delen van een proces veilig uit handen kunnen en welke eerst een controle nodig hebben, dan is dat het grootste deel van waar ons werk aan AI-automatisering uit bestaat. Neem de foutmarge mee die u al hebt, ook als het een schatting is. Juist als het een schatting is.
