Een AI-workflow kan 95% goed gaan en toch onbruikbaar zijn

Een AI-workflow die negentien van de twintig gevallen goed verwerkt, kan alsnog onbruikbaar zijn. Niet iedere fout heeft namelijk dezelfde impact. Eén verkeerde klantmail, een dubbel verwerkte aanvraag of een gemist bedrag kan zwaarder wegen dan meerdere kleine tekstcorrecties. Betrouwbaarheid vraagt daarom om meer dan een succespercentage: je moet ook foutzwaarte, zichtbaarheid, menselijke controle en herstelbaarheid beoordelen.

Een percentage telt fouten, maar begrijpt hun gevolgen niet

Stel dat twee AI-workflows op dezelfde twintig synthetische aanvragen worden getest.

Workflow A levert zestien aanvragen direct bruikbaar op. Bij vier aanvragen moet een medewerker een kleine opmaakfout of formulering aanpassen.

Workflow B levert negentien aanvragen direct bruikbaar op. Bij één aanvraag neemt het systeem echter een verkeerd bedrag over en markeert het resultaat niet als onzeker.

Op basis van alleen het aantal goede uitkomsten lijkt workflow B beter. Operationeel kan workflow A juist veiliger en bruikbaarder zijn. De vier kleine fouten zijn snel zichtbaar en veranderen de betekenis niet. De ene fout van workflow B kan onopgemerkt een verkeerde vervolgstap veroorzaken.

Daarom zegt “95% correct” pas iets wanneer je ook weet:

• welke testgevallen in de set zaten;
• welk onderdeel verkeerd ging;
• wat de mogelijke impact daarvan is;
• of een medewerker de fout kon herkennen;
• hoeveel herstelwerk nodig was;
• wat de workflow na de fout deed.

Een percentage zonder deze context kan een onveilig gevoel van zekerheid geven.

Waarom dit juist nu relevant is

Het wordt steeds gemakkelijker om een eerste workflow te bouwen. De nieuwe n8n Assistant kan bijvoorbeeld vanuit gewone taal een workflow plannen, opbouwen, uitvoeren en helpen debuggen. n8n schrijft tegelijk dat zo’n eerste workflow niet gegarandeerd productieklaar is en adviseert gebruikers de workflow, toegangsgegevens en uitvoeringslogs te controleren voordat ze erop vertrouwen (n8n).

Dat is de verschuiving waar MKB-bedrijven rekening mee moeten houden. Een werkend prototype maken wordt toegankelijker. Bepalen of het prototype betrouwbaar genoeg is voor het gekozen bedrijfsproces blijft een aparte taak.

Een goede demonstratie bewijst bovendien nog geen tijdwinst. Dezelfde voorzichtigheid is nodig bij kwaliteitspercentages. Een indrukwekkend cijfer is nog geen bedrijfsbesluit.

Deel fouten vooraf in drie categorieën in

Een eerlijke test bepaalt vóór de uitvoering welke fouten kritiek, groot of klein zijn. Niet nadat de resultaten bekend zijn.

Foutzwaarte	Betekenis	Voorbeeld bij een aanvraagworkflow
Kritiek	Kan leiden tot een verkeerde externe actie, beslissing of onacceptabele verwerking	Verkeerde klant of prijs, gevoelige informatie bij de verkeerde bestemming, een verzoek buiten scope wordt toch vrijgegeven
Groot	De uitkomst is niet bruikbaar zonder een substantiële correctie	Verkeerde categorie, een verplichte vraag wordt gemist of meerdere velden zijn onjuist
Klein	De kern klopt en een korte correctie verandert de betekenis niet	Opmaakfout, overbodige tekst of een niet-kritische formulering

De precieze indeling hangt af van de workflow. Een verkeerde datum kan bij een interne notitie klein zijn, maar kritiek worden wanneer daardoor een wettelijke of contractuele deadline wordt gemist.

Leg daarom per proces vast:

1. Welke fouten nooit mogen worden doorgelaten?
2. Welke fouten door een medewerker moeten worden hersteld?
3. Welke kleine afwijkingen zijn acceptabel?
4. Bij welke fout stopt de test of workflow direct?

Het NIST AI Risk Management Framework koppelt risicotolerantie eveneens aan impact, menselijke controle en vooraf bepaalde besluiten zoals goedkeuren, voorwaardelijk goedkeuren of afwijzen. Voor een kleine MKB-test hoeft dat geen zwaar governanceprogramma te worden. De grens moet wel vóór de test duidelijk zijn. Hoe die grenzen in een volledige testopzet passen, staat in de PuraFact-testmethodiek van nulmeting tot go/no-go.

Meet ten onrechte doorlaten en tegenhouden apart

Niet alleen de zwaarte, maar ook de richting van een fout maakt verschil.

Een workflow kan iets ten onrechte doorlaten. Een onvolledige aanvraag wordt dan bijvoorbeeld als compleet gemarkeerd. Hierdoor kan een verkeerde vervolgstap beginnen.

De workflow kan ook iets ten onrechte tegenhouden. Een correcte aanvraag belandt dan onnodig bij een medewerker. Dat kost extra tijd, maar veroorzaakt mogelijk minder schade.

Welke fout het zwaarst weegt, verschilt per proces. Bij een eenvoudige interne categorisatie kan een extra controle acceptabel zijn. Bij een betaling, toezegging of klantbericht kan ten onrechte doorlaten veel grotere gevolgen hebben.

Een betrouwbare beoordeling noteert deze twee soorten fouten daarom afzonderlijk. Anders kan één gemiddelde score verbergen dat de workflow juist de gevaarlijkste fout te vaak maakt.

Menselijke goedkeuring werkt alleen als de fout zichtbaar is

“Er kijkt altijd een mens naar” klinkt veilig, maar is nog geen werkende controlemaatregel.

Een medewerker moet minimaal:

• de oorspronkelijke invoer kunnen bekijken;
• zien wat de workflow heeft voorgesteld;
• weten aan welke criteria de uitkomst moet voldoen;
• twijfel en ontbrekende informatie kunnen herkennen;
• voldoende tijd hebben om werkelijk te controleren;
• de uitvoering kunnen tegenhouden en corrigeren.

Wanneer een medewerker alleen snel op een goedkeuringsknop klikt, verschuift de verantwoordelijkheid naar de mens zonder dat die persoon de fout effectief kan ontdekken.

Meet daarom niet alleen óf menselijke controle aanwezig is. Meet ook hoeveel tijd de controle kost, hoeveel fouten ermee worden gevonden en of de medewerker genoeg context krijgt. NIST adviseert eveneens om rollen, verantwoordelijkheden en de werking van menselijk toezicht te definiëren en te beoordelen.

PuraFact gebruikt menselijke goedkeuring daarom als ontwerpkeuze, niet als laatste vinkje. Op de pagina over veilig testen met AI staan de grenzen die tijdens een eerste test gelden.

Een goed antwoord kan nog steeds in een slechte workflow zitten

De AI-uitvoer kan inhoudelijk kloppen terwijl de totale workflow faalt.

Denk aan situaties waarin:

• een aanvraag twee keer wordt verwerkt na een retry;
• een koppeling een verplicht veld niet opslaat;
• een timeout onzichtbaar blijft;
• de verkeerde medewerker om goedkeuring wordt gevraagd;
• een afgewezen resultaat alsnog verdergaat;
• de workflow blijft wachten zonder melding;
• een fout niet kan worden hersteld zonder alles opnieuw uit te voeren.

Daarom moet een test de volledige keten volgen: van invoer tot gecontroleerde uitvoer. Leg per geval vast wat er is ontvangen, welke stappen zijn uitgevoerd, wat de workflow heeft voorgesteld, wie heeft beoordeeld en wat uiteindelijk is vrijgegeven.

Betrouwbaarheid betekent niet dat er nooit iets misgaat. Het betekent ook dat een fout zichtbaar blijft, de workflow veilig stopt en herstel mogelijk is zonder een tweede probleem te veroorzaken.

Beoordeel betrouwbaarheid zonder alles op één hoop te gooien

PuraFact zou een workflow op afzonderlijke velden beoordelen:

Veld	Beslisvraag
Uitvoerkwaliteit	Hoeveel gevallen zijn bruikbaar volgens vooraf bepaalde criteria?
Foutzwaarte	Waren er kritieke, grote of kleine fouten?
Detecteerbaarheid	Werden afwijkingen door het systeem of de medewerker gezien?
Menselijke inspanning	Hoeveel review- en correctietijd bleef nodig?
Workflowgedrag	Waren er vastlopers, dubbele of incomplete uitvoeringen?
Herstelbaarheid	Kon de fout veilig worden gestopt en hersteld?
Procesimpact	Was de totale werkwijze werkelijk beter dan de nulmeting?

Deze velden worden niet opgeteld tot één totaalscore. Een kritieke fout kan niet worden gecompenseerd doordat de workflow snel was of veel eenvoudige gevallen goed verwerkte.

Google beschrijft bij evaluaties van generatieve AI eveneens het belang van taakgerichte testsets en specifieke, controleerbare criteria per uitkomst (Google Cloud). Voor een bedrijfsworkflow moet daar nog de werking van de volledige keten omheen worden beoordeeld.

Van uitkomst naar besluit

Na de test zijn vier uitspraken mogelijk.

Doorgaan

De test geeft voldoende bewijs om een afzonderlijke productieanalyse te rechtvaardigen. Dit is nog geen toestemming om de demonstratie direct live te zetten.

Doorgaan met voorwaarden

Vervolg is alleen logisch nadat een specifieke fout is opgelost, een extra controle is toegevoegd of een aangepaste test opnieuw is uitgevoerd.

Eerst het proces verbeteren

De invoer, verantwoordelijkheid of gewenste uitkomst is nog te onduidelijk om de techniek eerlijk te beoordelen.

No-go

De kritieke fouten, controlelast, herstelproblemen of beperkte proceswinst rechtvaardigen geen verdere investering binnen deze scope.

Een no-go is geen mislukte test. Het voorkomt dat een hoog percentage wordt gebruikt om een oplossing door te drukken die bij het werkelijke proces niet past.

Kijk verder dan “hoe vaak ging het goed?”

Een bruikbare AI-workflow hoeft niet foutloos te zijn. De organisatie moet wel weten welke fouten kunnen ontstaan, welke gevolgen ze hebben, wie ze kan zien en wat er daarna gebeurt.

Vraag bij de volgende demonstratie daarom niet alleen naar het succespercentage. Vraag ook:

Wat ging er mis, wat was daarvan de impact en waardoor weten we dat deze fout niet ongezien verdergaat?

Die antwoorden zeggen vaak meer over betrouwbaarheid dan het percentage op de eerste slide.

Is jouw workflow geschikt voor een gecontroleerde test?

Met zeven korte vragen krijg je een eerste indicatie: testen, eerst verder in kaart brengen of nu beter niet automatiseren. De check is geen formele audit en geeft geen garantie, maar helpt wel om de juiste eerste vraag te stellen. Doe de Workflow Check.

Bronnen

• n8n, Introducing n8n Assistant
• NIST, AI Risk Management Framework Playbook
• Google Cloud, Gen AI evaluation service overview