In een door ons uitgevoerde enquête onder 500 Amerikaanse professionals in documentintensieve functies, zei 88% dat ze vertrouwen hadden in de nauwkeurigheid van de data die hun analyses en AI-systemen voedt. Diezelfde 88% meldde op zijn minst soms fouten te vinden in van documenten afgeleide data. Beide cijfers zijn tegelijkertijd waar, en die tegenstrijdigheid vormt de hele basis voor gestructureerde data voor AI-agents.
Het is geen afrondingsfout. Het is een beschrijving van hoe de meeste teams tegenwoordig werken: vol vertrouwen, en vaak genoeg fout om problemen te veroorzaken. Jouw agents bevinden zich stroomafwaarts van die data, en geen enkele agent heeft ooit gedacht: 'wacht even, dat totaalbedrag klopt niet'.
Dus als er een vastloopt, de verkeerde leverancier betaalt of een claim indient onder het verkeerde polisnummer, is de eerste reactie om het model de schuld te geven en op zoek te gaan naar een beter exemplaar. Het model was meestal prima in orde. Wat ontbrak was de stap ervoor, de stap die een binnenkomend document omzet in benoemde velden die daadwerkelijk door iemand zijn gecontroleerd.
Zes fasen. Geen developer. Hier zijn ze.
Belangrijkste punten
- Gestructureerde data voor AI-agents betekent benoemde velden met voorspelbare types, niet een document dat de agent runtime moet interpreteren.
- Agents falen op documenten op vier specifieke manieren: geen OCR-laag voor scans, lay-outverschuiving tussen afzenders, het stilzwijgend weglaten van velden, en het ontbreken van een betrouwbaarheidssignaal om tegen te controleren.
- Gartner verwacht dat meer dan 40% van de agentic AI-projecten tegen eind 2027 geannuleerd zal zijn. Een andere voorspelling van hen: 60% van de AI-projecten die niet worden ondersteund door AI-ready data zal voor het einde van 2026 worden stopgezet. Beide mislukkingen beginnen stroomopwaarts van het model.
- De pijplijn heeft zes fasen: vastleggen, classificeren, schema maken, extraheren, valideren, afleveren. Het overslaan van valideren is wat een demo verandert in een incident.
- Filteren op betrouwbaarheid (confidence gating) is het verschil tussen een agent waarnaar je kijkt en een agent die je vertrouwt. Teams die alleen de onzekere minderheid handmatig controleren, bereiken 99,9% nauwkeurigheid terwijl ze tot vijf keer sneller verwerken.
- Voor niets hiervan is een developer nodig. n8n, Make en Zapier voeren de orkestratie uit, en de extractielaag doet het zware werk.
Wat gestructureerde data voor AI-agents eigenlijk betekent
Gestructureerde data voor AI-agents is documentinhoud die is omgezet in benoemde velden met voorspelbare types en bekende eenheden, zodat de agent invoice_number, due_date, total en line_items ontvangt in plaats van een pdf die hij nog moet interpreteren. De agent leest waarden. Hij leest geen documenten.
In de praktijk is het zó compact:
{
"invoice_number": "INV-4821",
"supplier": "Northwind Supplies",
"due_date": "2026-08-14",
"currency": "USD",
"total": 1340.0,
"source_document": "https://files.example.com/inv-4821.pdf"
}
Zes regels waarop jouw workflow logica kan toepassen, tegenover een pdf van drie pagina's en een prompt die zegt "vind het totaal". Elk veld heeft een naam, een type en een verwijzing terug naar de pagina waar het vandaan kwam.
Dat klinkt als een technisch detail, maar het is het verschil tussen een agent die in jouw demo werkte en eentje die in november nog steeds werkt. Een model dat twee keer dezelfde factuur krijgt, kan twee net iets andere antwoorden geven. Dat is charmant in een chatvenster, maar catastrofaal in een loop die om 3 uur 's nachts draait. Een model dat een gevalideerd JSON-object krijgt, gedraagt zich telkens hetzelfde, omdat er niets meer over is om te interpreteren.
Dit blijft mensen in de problemen brengen omdat het bronmateriaal nooit voor machines is gemaakt. Ergens tussen de 80 en 90% van de bedrijfsdata is ongestructureerd: e-mails, pdf's, scans, bijlagen, formulieren, allemaal gebouwd voor een mens om naar te kijken. De meeste teams hebben die kloof ook nog niet gedicht. In een onderzoek naar factuurverwerking, verwerkt 34% van de bedrijven de data nog steeds handmatig terwijl slechts 17% het volledig automatisch vastlegt.
Ruw materiaal in menselijk formaat. Een agent die een machineformaat verwacht. Niemand in het organogram is eigenaar van de conversie. Die kloof is het onderwerp van de ontbrekende laag in agentic AI als je de langere discussie wilt lezen, en van ongestructureerde data omzetten naar gestructureerde data als je de algemene casus zoekt. Dit artikel focust zich op de agent-specifieke versie.
Waarom AI-agents falen bij documenten
Bijna elke hallucinatie van een AI-agent bij een document is terug te voeren op een van deze vier dingen. Vier oorzaken, vier verschillende oplossingen.
Geen OCR-laag voor scans. Een scan is een afbeelding van woorden, geen woorden. Een model dat de afbeelding krijgt en geen tekstlaag, zal lezen wat het kan en de rest zelf vol vertrouwen verzinnen, zonder je ooit te vertellen welk deel wat was.
Lay-outverschuiving tussen afzenders. Veertig leveranciers, veertig factuurontwerpen, en een pijplijn gebouwd tegen de drie die je in maart hebt getest. Wanneer leverancier twaalf het totaalbedrag in een ander vakje zet, geeft er niets een foutmelding. De extractie begint stilletjes de verkeerde cel terug te geven.
Stilzwijgend weglaten van velden. Er staat geen PO-nummer op het document, dus het veld komt leeg terug en de agent gaat toch verder. Niets lijkt stuk. Het komt twee weken later aan het licht, in een reconciliatie waar niemand blij van wordt.
Geen zekerheidssignaal. Niets in de output zegt "Ik ben 60% zeker over dit totaal", dus elke waarde krijgt hetzelfde vertrouwen, inclusief de verzonnen waarden.
De kosten hiervan zijn niet theoretisch. Bijna zeven op de tien respondenten uit die enquête meldde soms, vaak of zeer vaak fouten te vinden. Dit maakt slechte documentdata tot een normale operationele situatie in plaats van een incident. En specifiek bij de crediteurenadministratie liggen de foutpercentages bij betalingen tussen 0,1% en 0,4% van de totale uitbetalingen aan leveranciers. Kleine percentages, maar grote bedragen: haal $20 miljoen aan leveranciersuitgaven door die berekening en het is $20.000 tot $80.000 per jaar die naar een plek gaan die jij niet hebt gekozen.
Gartner komt vanuit een andere hoek tot dezelfde conclusie: 63% van de organisaties heeft niet de juiste datamanagementpraktijken voor AI of weet niet zeker of ze die hebben. Dat is een beleefde manier om te zeggen dat de meeste agent-projecten op een fundering staan die niemand heeft geïnspecteerd. Als het OCR-gedeelte hiervan is waar jouw pijn zit, zijn we dieper ingegaan op waarom AI OCR faalt.
Waarom de pdf rechtstreeks naar het model sturen niet meer werkt
Het ruwe bestand naar GPT, Claude of Gemini sturen werkt goed, totdat het ineens misgaat. De grens tussen die twee staten is afhankelijk van de vraag of een mens de output leest.
De nauwkeurigheidscijfers leggen uit waarom. Op schone tekst-pdf's komt veldextractie uit op ongeveer 96 tot 98%. Op gescande documenten dalen dezelfde modellen tot ruwweg 90 tot 94%. Die kloof is op zichzelf niet het probleem. Het probleem is dat het antwoord er in beide gevallen identiek uitziet. Geen waarschuwing, geen voorbehoud, geen hint dat dit specifieke document de moeilijke variant was.
In een chatvenster overleef je dat, omdat je het zou merken als een totaalbedrag wordt gelezen als $1.340 terwijl er $13,40 op de factuur staat. In een onbeheerde workflow is er niemand om dat op te merken, en loopt het verkeerde nummer regelrecht door naar de volgende stap.
Er zit een ontwerpprincipe onder verborgen, wat we uitgebreid hebben besproken in waarom documentverwerking met één model dood is: één modelaanroep is geen pijplijn. Een pijplijn heeft fasen, en fasen kunnen worden gecontroleerd. Een enkele aanroep is simpelweg een muntje opgooien en besluiten de uitkomst te vertrouwen.
De document-naar-agent pijplijn, in zes fasen
Document parsing voor AI-agents is niet één stap, het zijn er zes. Elke betrouwbare opzet die we hebben gezien, doorloopt ze allemaal. Of het team dit nu zo op een whiteboard had uitgedacht, of er na een slechte maand vanzelf achter kwam.
1. Leg het document vast en bewaar het origineel
Houd in de gaten waar documenten daadwerkelijk binnenkomen: een gedeelde inbox, een Drive- of SharePoint-map, formulier-uploads, een SFTP-drop of bijlagen op helpdesktickets. Sla het originele bestand op een stabiele plek op voordat je het aanraakt.
Het bronbestand bewaren is geen administratieve klus. Het is wat je in staat stelt om zes maanden later de vraag "waar kwam dit getal vandaan?" te beantwoorden, en het is het eerste waar een auditor naar vraagt.
2. Classificeer voordat je extraheert
Bepaal wat het document is voordat je beslist welke velden je eruit wilt halen. Factuur, inkooporder, contract, leveringsbon, bankafschrift, cv, of onbekend.
Dit is belangrijker dan het lijkt, want facturen en inkooporders delen veldnamen, hoewel ze verschillende dingen betekenen. Voeg ze samen en je krijgt records die elke validatiecheck doorstaan, maar stiekem toch fout zijn. Hier concentreert zich ook het risico: respondenten in de enquête noemden facturen (21%), inkooporders (18%) en klantgerichte documenten (17%) als de meest foutgevoelige types.
Alles wat onder "onbekend" valt, gaat naar een mens, niet naar een blinde gok van de AI.
3. Definieer één schema per documenttype
Een schema is het contract tussen jouw documenten en jouw agent. Het benoemt elk veld, geeft het een type en markeert welke verplicht zijn.
Definieer velden op basis van betekenis in plaats van positie, zodat total_amount altijd het totaalbedrag van de factuur is, waar het ook op de pagina staat. Moderne AI-extractie leest lay-outs die het nog nooit eerder heeft gezien zonder template setup. Dit betekent dat één schema veertig leveranciers kan afdekken. Weersta de verleiding om een schema per afzender te bouwen. Dat is een weg zonder einde.
Markeer de velden zonder welke jouw achterliggende systeem niet kan functioneren. Dat worden jouw 'harde stops' in fase vijf.
4. Extraheer met een specifieke laag, niet zomaar een modelaanroep
Dit is waar de nauwkeurigheid vandaan komt. Goed uitgevoerd, is data-extractie voor AI-agents niet zomaar een prompt, het is een service. Het verschil is terug te zien in de cijfers: OCR-only systemen landen op 85 tot 95% nauwkeurigheid en worstelen met inconsistente lay-outs, terwijl AI- en machine learning-extractie ruwweg 99% bereikt en zich aanpast aan nieuwe lay-outs zonder dat je templates hoeft te herbouwen.
Wat een specifieke laag je geeft wat een losse modelaanroep niet doet: OCR voor scans, tabel- en line-item-extractie, normalisatie en validatie tegen jouw schema, paginareferenties terug naar de bron, retry handling (opnieuw proberen bij fouten), een optionele menselijke controlestap en geversioneerde schema's die je kunt wijzigen zonder eerdere records te breken. Sommige lagen voegen daar betrouwbaarheidsscores per veld aan toe. Dat is handig als je het hebt, maar je moet er niet je hele filter op baseren.
De meeste productie-pijplijnen anno 2026 combineren benaderingen in plaats van er eentje te kiezen. Ze gebruiken goedkope, deterministische extractie voor de documenten die dat toelaten en op modellen gebaseerde extractie voor de rest. Voor een diepgaandere blik op dit onderwerp, zie agentic document extraction.
5. Valideer en filter voordat iets de agent bereikt
Controleer het geëxtraheerde record tegen het schema. Zijn de verplichte velden aanwezig, kloppen de types, tellen de totalen op, zijn datums goed te parsen en vallen waarden binnen logische bandbreedtes? Pas daarna jouw betrouwbaarheidsregels toe.
Records die hier doorheen komen, gaan naar de agent. Records die afgekeurd worden, gaan naar een mens. Bouw dat tweede pad als een omweg in plaats van een doodlopende weg, zodat een handmatig gecontroleerd record gewoon weer in dezelfde workflow stroomt zodra iemand het goedkeurt. Zo houdt één lastig document nooit de wachtrij erachter op.
Deze specifieke aftakking is het enige echte veiligheidsmechanisme, en krijgt hieronder een eigen sectie, omdat dit het onderdeel is dat teams het vaakst overslaan én het vaakst spijt van krijgen.
6. Lever het schone record af bij de agent
Push het gevalideerde object naar de plek waar de agent zijn werk oppakt: een webhook naar jouw automatiseringsplatform, een rij in een database, een record in jouw CRM of ERP. De agent ontvangt een afgewerkt object en krijgt het originele document nooit te zien.
Hoe de data jouw agent daadwerkelijk bereikt
Vier mechanismen dekken bijna elke AI-agent integratie die je ooit zult bouwen. Ze zijn geen echte concurrenten van elkaar. Elk beantwoordt een andere vraag over timing en eigenaarschap.
| Mechanisme | Hoe het werkt | Gebruik het wanneer | Let op |
|---|---|---|---|
| Webhook | De extractietool pusht het record op het moment dat het klaar is | Documenten continu binnenkomen en je wilt dat de agent direct handelt | Je retry handling nodig hebt en een plek waar mislukte afleveringen terechtkomen |
| REST API-pull | Jouw workflow vraagt op vaste tijden om records | Batchverwerking, of wanneer het ontvangende systeem geen inkomende calls kan accepteren | Voegt vertraging toe, en jij bent verantwoordelijk voor de polling-logica |
| Gedeelde database | Records landen in een tabel waar de agent uit leest | Meerdere agents of systemen dezelfde data nodig hebben, en je historie wilt behouden | Iemand de verantwoordelijkheid moet nemen voor schema-wijzigingen en het opschonen |
| Tool-aanroep | De agent vraagt runtime om documentdata, vaak via MCP | De agent tijdens een taak beslist welk document hij nodig heeft | Het moeilijkst te debuggen, en zelden wat een documentworkflow daadwerkelijk nodig heeft |
Die laatste rij verdient een voetnoot, omdat het Model Context Protocol (MCP) de laatste tijd enorm veel aandacht opslokt. MCP is een echte en bruikbare manier om een databron bloot te stellen aan een agent als een aanroepbare tool. Het is alleen meestal niet de juiste vorm voor documenten. Die komen namelijk aan op hun eigen schema en dragen velden met zich mee waarvan je al weet dat je ze nodig hebt. Een webhook die gestructureerde data jouw workflow in pusht, is simpeler om te bouwen, makkelijker te debuggen en doet hetzelfde werk.
Wat tevens de waarheid is die zich in alle vier de rijen verbergt: er is geen speciale API voor AI-agents. Er is gewoon een standaard API die velden aanlevert waarop een agent kan acteren. Parseur verstuurt geëxtraheerde data via elk van de eerste drie opties, en de volledige lijst met bestemmingen vind je op de pagina met exports en integraties.
Hoe je zeker weet dat je agent niet reageert op een verkeerd nummer als er niemand kijkt
Dat weet je omdat je van tevoren hebt besloten waar de agent op mag acteren, en al het andere stopt voor controle door een mens.
Dat is het eerlijke antwoord. Geen enkel nauwkeurigheidscijfer laat die vraag verdwijnen, want zelfs uitstekende extractie zit er weleens naast en die fouten zijn niet gelijkmatig verdeeld. Wat de zorgen wegneemt, is een filter (gate) dat je doelbewust hebt ontworpen.
Een gate is een kleine set regels, die wordt gecontroleerd voordat het record de agent bereikt:
- Betrouwbaarheid onder jouw drempel (threshold) voor een bepaald veld: routeer naar menselijke controle. Dit hangt af van een extractielaag die de betrouwbaarheid per veld publiceert. Velen doen dat niet, wat de reden is waarom de rest van deze lijst belangrijk is.
- Een verplicht veld ontbreekt: laat het record falen. Geef nooit een lege string door alsof het een waarde is.
- De waarde overschrijdt een goedkeuringslimiet: vereis goedkeuring door een mens, ongeacht de betrouwbaarheid. Een perfect geëxtraheerde factuur van $80.000 verdient nog steeds dat een mens ernaar kijkt.
- De leverancier, afzender of het documenttype is nieuw: controleer de eerste paar tot het patroon is vastgesteld.
- Classificatie gaf 'onbekend' terug: stuur het naar een triage-stap in plaats van een schema te gokken.
- Een totaalbedrag komt niet overeen met de line-items: laat het falen. Rekenen is de goedkoopste leugendetector die je hebt.
Over de drempel zelf: er is geen universeel getal, en iedereen die jou er een vertelt, heeft jouw documenten niet gezien. Kalibreer dit met een steekproef van je eigen productiebestanden en leg de grens op het punt waar de fouten die erdoorheen glippen, degene zijn die jouw achterliggende systeem nog kan opvangen. Een factuur die een betalingsrun voedt, en een leveringsbon die een dashboard voedt, verdienen niet dezelfde lat.
De beloning is meetbaar. Teams die dit patroon uitvoeren, waarbij AI de overgrote meerderheid van documenten met hoge betrouwbaarheid afhandelt en mensen de onzekere rest controleren, bereiken 99,9% nauwkeurigheid terwijl ze tot vijf keer sneller verwerken. Een Noordse verzekeraar die claims automatiseert, verwerkt ongeveer 70% van de documenten volledig automatisch, waarbij medewerkers zich concentreren op de complexe gevallen. En bij crediteurenadministratie is het verschil tussen goed en gemiddeld direct hier zichtbaar: toppresteerders hebben een uitzonderingspercentage van 9% tegenover 22% voor de rest.
Let op wat deze cijfers beschrijven. Het is geen agent die nooit een lastig document tegenkomt, maar eentje die wéét welke documenten lastig waren. Voor de praktische kant van het ontwerpen van zo'n controlestap, zie onze gidsen over human-in-the-loop AI, HITL best practices en data validation.
De AI-agent workflow bouwen zonder code te schrijven
Voor niets hiervan is een developer nodig, wat vaak mensen verrast die het woord 'pijplijn' horen en zich direct een kwartaal aan engineeringtijd voorstellen.
De verdeling is simpel. De extractielaag doet het zware werk: documenten lezen, het schema toepassen, en de velden normaliseren en valideren. Jouw automatiseringsplatform voert de orkestratie uit: triggeren op nieuwe documenten, de extractor aanroepen, het resultaat ontvangen, de regels controleren, uitzonderingen routeren en het afgewerkte object overhandigen aan de agent. Die werkverdeling is precies hoe een AI-agent workflow eruitziet als deze productie overleeft.
In n8n bestaat dit geheel uit vier nodes: een webhook trigger die het geëxtraheerde record ontvangt, een IF-node die jouw regels controleert, één vertakking naar de agent, en één vertakking naar een mens. Alles wat hierboven staat over 'gating' past in die IF-node, en de regels die het meeste vangen zijn de meest simpele, zoals een ontbrekend verplicht veld of een totaalbedrag dat niet overeenkomt met de onderliggende regels.
n8n past goed bij teams die vertakkingslogica, foutafhandeling en self-hosting willen. Dit is dan ook waar de meeste agents momenteel gebouwd worden. Make is het meest gebruiksvriendelijk voor het visueel bouwen van een workflow met meerdere stappen zonder ook maar iets aan te raken dat op code lijkt. Zapier zorgt ervoor dat je vanmiddag nog live bent als de flow ruwweg lineair is. We gaan dieper in op deze afweging in onze n8n vs Zapier vs Make vergelijking.
Wat geen van hen op zichzelf goed kan, is een gescande pdf lezen. Hun ingebouwde bestandsnodes kunnen schone, op tekst gebaseerde documenten aan en daar stopt het. Dat is precies de kloof die de extractielaag overbrugt, en waarom beide helften bij elkaar horen in plaats van met elkaar concurreren.
Extractielaag, RAG, of gewoon een LLM: welke heb je nodig?
Deze drie worden vaak besproken als alternatieven voor elkaar, terwijl ze in werkelijkheid allemaal een ander probleem oplossen.
| Benadering | Waar het goed in is | Gebruik het wanneer | Waar het tekortschiet |
|---|---|---|---|
| Extractielaag | Dezelfde benoemde velden uit elk document van een bepaald type halen | Je weet welke velden je wilt, en een agent of systeem gaat erop acteren | Niet gebouwd voor open vragen over de betekenis van een document |
| RAG | Open vragen beantwoorden over een hoeveelheid tekst | "Wat zegt onze raamovereenkomst over beëindiging?" | Moeilijk te valideren, en de kwaliteit van retrieval (opvraging) is bepalend voor alles |
| Alleen een LLM-aanroep | Prototypes, eenmalige projecten en echt ongebruikelijke documenttypes | Je aan het verkennen bent, en een mens elke output leest | Geen zekerheidssignaal, geen audit trail, geen manier om te filteren (gate) |
De meest gemaakte fout is om voor RAG te kiezen wanneer een schema het werk had kunnen doen. Als je de velden van tevoren kunt opschrijven, is extractie sneller, goedkoper en veel makkelijker te bewijzen als correct. Bewaar RAG voor de vragen die je niet vooraf kunt opsommen.
Dit is ook het punt waarop AI data readiness niet meer zomaar een slide is in een presentatie, maar een checklist wordt. De meeste artikelen over dit onderwerp hebben het over datawarehouse-tabellen en governance-beleid. Voor documentworkflows betekent het echter vier concrete dingen: velden met namen, velden met types, elke waarde gevalideerd tegen een schema voordat deze verplaatst wordt, en een link terug naar de pagina waar de waarde vandaan kwam. Voor de bredere categorie waar dit in valt, zie intelligente documentverwerking (IDP).
Hoe je dit bouwt met Parseur
Parseur is de extractielaag in de pijplijn hierboven. Het bestaat omdat twee engineers het beu waren om te zien hoe mensen overtypten wat een computer al kon lezen.
De installatie kost je slechts vier stappen:
- Maak een mailbox aan en stuur je documenten daarheen. Stuur e-mails van leveranciers door, sleep bestanden erin of koppel de map waar ze nu al binnenkomen.
- Parseur's AI extraheert de velden automatisch. De Text AI-engine handelt e-mails en tekstdocumenten af, de Vision AI-engine zorgt voor pdf's, scans en afbeeldingen. Je hoeft geen templates te bouwen, en er valt dus ook niets te onderhouden op de dag dat een leverancier het factuurontwerp aanpast.
- Valideer, en controleer wat jij wilt controleren. Elk veld wordt genormaliseerd en gevalideerd tegen jouw mailboxschema, zodat datums, getallen en keuzelijsten in de vorm aankomen die jouw achterliggende tools verwachten. Zet de optionele handmatige controlestap aan en een mens bekijkt het record voordat het wordt geëxporteerd. Parseur scoort velden niet op betrouwbaarheid, dus jij bepaalt zélf welke documenten door een mens bekeken moeten worden in plaats van een drempel (threshold) die dit voor je beslist.
- Exporteer het gestructureerde resultaat naar jouw agent, jouw automatiseringsplatform, jouw database, jouw CRM, of rechtstreeks naar een API.
Het leest pdf's, e-mails, scans, spreadsheets en bijlagen, en doet dat al sinds 2016. Er zijn tot nu toe meer dan 100 miljoen documenten doorheen gegaan, zonder een cent aan externe investeringen. Dat is exact het saaie soort stabiliteit dat je wilt hebben onder een pijplijn die je van plan bent te laten draaien.
Voordat dit alles jouw ERP bereikt, komen er meestal twee vragen binnen, vaak van IT en finance in dezelfde week. Waar gaat de data heen? Documenten worden nooit gebruikt om modellen te trainen, de verwerking volgt de AVG/GDPR, en de rest vind je op de security-pagina. Wat kost het? Er is een gratis plan. Dat maakt het ook de enige verstandige manier om dit alles te evalueren: gooi er vijf van jouw eigen slechtste documenten in en kijk naar de velden die eruit komen.
De reden om hier überhaupt tijd in te steken, is simpel rekenwerk. Handmatige data-invoer kost Amerikaanse bedrijven ongeveer $28.500 per medewerker per jaar. Dat is de begrotingspost waar jouw AI-agent project daadwerkelijk mee concurreert. En dat is ook wat er stilletjes terugkeert in de week dat jouw team besluit dat de pijplijn niet vertrouwd kan worden en alle records weer met de hand gaat controleren.
Verdwijnt deze laag als modellen beter worden?
De extractie wordt elk jaar beter. De noodzaak voor een gecontroleerde grens tussen een document en een systeem dat geld uitgeeft, niet.
Dit is het rekenwerk dat niet verandert: bij een veldnauwkeurigheid van 99% bevat één op de honderd documenten een verkeerde waarde. Laat tienduizend documenten per maand draaien en je hebt honderd verkeerde waarden, die er stuk voor stuk exact uitzien als de juiste. Verhoog je de nauwkeurigheid naar 99,5%, dan heb je er vijftig. Beter, maar nog steeds geen nul, en 'nul' is waar de aanname "de agent kan onbeheerd draaien" stilletjes vanuit gaat.
Wat wél echt verandert, is de verhouding. Minder documenten vereisen een mens, degene die wel gemarkeerd worden kloppen beter met de regels, en de controlewachtrij krimpt van een hele afdeling naar een namiddagje werk. Dat is een flinke verbetering en absoluut de moeite waard. Maar het is niet hetzelfde als een laag die volledig verdwijnt.
De teams die in 2028 zorgeloos met agents werken, zijn niet de teams die een model vonden dat goed genoeg was om de validatie over te slaan. Het zullen de teams zijn die hun 'gate' vroeg hebben gebouwd, hebben gezien hoe deze fouten opving, en zo langzaam het recht hebben verdiend om die poort wat wijder open te zetten.
Laatst bijgewerkt op
