Technisch succes kan operationeel falen verbergen
Een AI-workflow levert geldige JSON op. Alle actieblokken bestaan. De interface toont het resultaat correct. De validatie slaagt en de uitvoering eindigt met de status succesvol. Technisch ziet alles er gezond uit.
Maar heeft de workflow ook gedaan wat de gebruiker vroeg?
Een nieuw onderzoek van IBM-onderzoekers laat zien hoe ver die twee antwoorden uit elkaar kunnen liggen. De onderzoekers vergeleken zes taalmodellen in een operationeel low-code automatiseringsplatform, aan de hand van 29 realistische scenario's voor IT en compliance. Iedere combinatie van opdracht, model en pipeline werd acht keer uitgevoerd: in totaal 2.784 proeven.
Het team verbeterde eerst de generatiearchitectuur. In plaats van een model in één keer een complete workflow te laten maken, splitste het de bouw op in variabelen, hoofdblokken en geneste blokken. Het structurele slagingspercentage — geldige JSON, geldige verwijzingen en een correct getoonde interface — steeg bij de geteste modellen van 31,5–82,8% naar 74,1–97,8%.
Dat is een nuttig engineeringresultaat. Tegelijk maakte het een belangrijker risico zichtbaar: een workflow kan technisch perfect en operationeel waardeloos zijn.
De beste technische score leverde het slechtste taakresultaat
De onderzoekers toetsten apart of technisch geldige workflows ook voldeden aan de oorspronkelijke opdracht. Het model met het hoogste structurele slagingspercentage, 97,8%, had in de vernieuwde pipeline juist het laagste percentage taakvervulling: 6,9%.
De terugkerende fout was veelzeggend. Het model maakte geldige maar niet-uitvoerbare lege workflows die alleen meldden dat de benodigde handelingen niet beschikbaar waren. Ze kwamen door de schemavalidatie omdat de structuur klopte. Voor de gebruiker faalden ze, omdat het gevraagde werk niet werd uitgevoerd.
Zelfs het beste model op taakvervulling slaagde volgens de meerderheidsmethode van het onderzoek bij slechts 55,2% van de opdrachten. Het paper adviseert daarom menselijke controle vóór uitvoering.
De exacte percentages zijn niet één op één toepasbaar op ieder bedrijfsproces. Alle auteurs werken bij IBM, de scenario's gaan over IT- en complianceautomatisering, de inhoudelijke kwaliteit werd beoordeeld door een ander taalmodel en niet aan de hand van een door mensen gemaakte gouden standaard, en het paper rapporteert nog geen betrouwbaarheidsintervallen per testcel. Het foutpatroon is wel breed relevant: technische geldigheid is noodzakelijk, maar niet voldoende.
Onafhankelijk onderzoek van Princeton komt vanuit een andere invalshoek tot dezelfde bredere conclusie. In een evaluatie van veertien modellen stellen de onderzoekers dat de betrouwbaarheid van een agent niet uit één gemiddeld slagingspercentage is af te leiden. Consistentie over herhaalde uitvoeringen, robuustheid bij veranderde invoer, voorspelbaarheid van fouten en de ernst van die fouten moeten afzonderlijk worden gemeten.
Accepteer het resultaat, niet het verhaal van de agent over het resultaat
Veel acceptatietests voor AI stoppen te vroeg. Ze bevestigen dat een antwoord het juiste formaat heeft, een toolaanroep zonder foutmelding terugkwam of de agent meldt dat de taak klaar is. Die controles zijn nodig, maar bewijzen alleen dat het softwarepad is doorlopen.
Bij een documentworkflow is succes niet: ‘de extractie leverde JSON op’. Succes betekent dat de juiste waarden zijn gevonden, onbewezen waarden zijn afgewezen, uitzonderingen naar de juiste persoon zijn gestuurd en het doelsysteem de correcte gegevens bevat. Bij een serviceworkflow is succes niet: ‘er is een antwoord opgesteld’. Het antwoord moet de juiste dossiercontext gebruiken, binnen het beleid blijven en bij de juiste beoordelaar terechtkomen. Bij een operationele agent is succes niet: ‘de update-aanroep gaf status 200’. De bedoelde systeemtoestand moet precies één keer, bij de juiste relatie en met een controleerbare reden zijn gewijzigd.
De lege workflow uit het onderzoek is alleen het duidelijkste voorbeeld. Gevaarlijkere fouten kunnen er technisch net zo geldig uitzien: de verkeerde klant selecteren, een goedkeuring overslaan, een verouderde regel toepassen, twee dossiers bijwerken in plaats van één of afronding melden na een gedeeltelijke handeling.
Een praktische acceptatieset voor AI-workflows
Een workflow voor productie heeft een kleine, expliciete acceptatieset nodig voordat hij betekenisvolle rechten krijgt. Test minimaal zes zaken:
- Uitkomst: beschrijf voor representatieve situaties het waarneembare bedrijfsresultaat, niet alleen het verwachte uitvoerformaat.
- Toestand na uitvoering: controleer bron- en doelsystemen achteraf. Zie de afrondingsmelding van de agent niet als bewijs.
- Verboden uitkomsten: test wat nooit mag gebeuren, zoals een verkeerde ontvanger, dubbele mutatie, onbevoegde handeling of verzonnen onderbouwing.
- Herhaling: voer belangrijke situaties meermaals uit en varieer formulering, volgorde en ontbrekende informatie. Een workflow die één keer werkt is een demo, geen operationele capaciteit.
- Foutafhandeling: controleer of de workflow zich onthoudt, escaleert of veilig stopt wanneer zekerheid, rechten of bewijs ontbreken.
- Regressie: maak van iedere fout en ieder bijna-incident een test die de volgende versie van model, prompt of integratie moet doorstaan.
Kosten en doorlooptijd horen naast deze kwaliteitscontroles. Het opsplitsen van een moeilijke taak kan kleinere modellen technisch bruikbaar maken, maar extra stappen voegen ook aanroepen, tokens en mogelijke foutpunten toe. De relevante maatstaf is daarom niet de prijs per modelantwoord, maar de kosten per correct afgeronde en veilig afgehandelde praktijksituatie.
Dit verandert hoe een AI-project live moet gaan
Een modelvergelijking is geen acceptatietest. Een overtuigend prototype evenmin. De acceptatiegrens hoort om de complete workflow te liggen: brondata, redenering, rechten, hulpmiddelen, menselijke beslissingen en de uiteindelijke toestand van het doelsysteem.
Daarom begint een beheerste lancering met één begrensde workflow en een afgesproken acceptatieset. Voor livegang zijn representatieve praktijksituaties, expliciete stopvoorwaarden, een beoordelaar voor uitzonderingen en zicht op de werkelijke uitkomsten nodig. Na livegang moeten bevindingen uit productie terugvloeien naar evaluaties en regressietests.
De praktische conclusie is eenvoudig: vraag niet alleen of de AI iets geldigs heeft geproduceerd. Vraag of het bedrijfsproces in de juiste toestand is geëindigd, of dat veilig gebeurde en of het morgen opnieuw lukt.
Bronnen: Evaluating LLM Trade-offs for Enterprise Automation: Lessons from Workflow Generation in a Production Enterprise Platform en Towards a Science of AI Agent Reliability.