Datagereedheid voor AI-agents: test 1 workflow, niet je hele datalandschap

Vraag de meeste consultants of je data klaar is voor een AI-agent en je krijgt hetzelfde antwoord. Repareer eerst het datalandschap. Bouw de catalogus, schrijf de datacontracten, zet een semantische laag neer, leg eigenaarschap vast over alle systemen, en kom over 9 maanden terug om over agents te praten. Dat advies is niet fout. Het is alleen onbetaalbaar voor bijna elk bedrijf dat het krijgt, en het maakt stilletjes meer agentprojecten kapot dan zwakke modellen ooit hebben gedaan.

Dit is de omkering die verandert wat je maandag doet. Datagereedheid is geen eigenschap van je bedrijf. Het is een eigenschap van 1 workflow. Het goedkeuren van terugbetalingen bij een SaaS-bedrijf met 60 mensen kan volledig agent-klaar zijn terwijl de rapportagekant van datzelfde bedrijf een moeras is waar sinds de laatste migratie niemand aan heeft gezeten. Het moeras testen zegt niets nuttigs over terugbetalingen. Toch test de brede beoordeling juist dat moeras, geeft een rode score terug, en sterft het agentproject aan een oordeel dat technisch klopte en praktisch niets betekende.

Dit artikel is geschreven voor oprichters, CTO's en operationeel leidinggevenden bij bedrijven van ruwweg 20 tot 500 mensen die een echte workflow hebben die automatisering waard is en geen zin hebben in een datagovernanceprogramma. Run je een gereguleerde onderneming met 400 bronsystemen en een chief data officer, dan zijn die brede programma's wel degelijk voor jou en zal dit stuk te klein aanvoelen.

Je krijgt een werkbare definitie van datagereedheid voor AI-agents, waarom de aanpak waarbij het landschap eerst komt zo betrouwbaar mislukt, de 7 checks die je vertellen of 1 workflow klaar is, hoe je ze eerlijk scoort, wat je in dagen in plaats van kwartalen doet als een check zakt, en een uitgewerkt voorbeeld met echte cijfers.

‍

Belangrijkste punten

• Datagereedheid voor AI-agents is een eigenschap van 1 workflow, niet van je hele datalandschap.

• De landschap-eerst-aanpak duurt 6 tot 12 maanden en verliest meestal zijn opdrachtgever voordat er iets ligt waar een agent mee kan werken.

• Je scoort 1 workflow in 3 tot 5 dagen met 7 checks: toegang, betekenis, actualiteit, ground truth, actie, omkeerbaarheid, toestemming.

• Ground truth is de check die vrijwel iedereen overslaat. Kun je geen 50 oude cases met bekende juiste antwoorden leveren, dan kun je niet vaststellen of de agent werkt.

• Agents hebben een smaller stuk data nodig dan een warehouse, maar wel een schrijfpad en een manier om terug te draaien, en dat had BI nooit nodig.

• Gartner verwacht dat meer dan 40 procent van de agentic AI-projecten voor eind 2027 wordt gestopt, vooral door kosten, onduidelijke waarde en zwakke risicobeheersing.

• Scoor 6 of 7 en bouw nu. Scoor 5 en dicht de gaten in 2 tot 4 weken. Scoor 4 of lager en kies een andere workflow, want het herstel duurt langer dan de bouw.

• Het werk aan het landschap gebeurt alsnog. Het wordt gefinancierd door een workflow die al resultaat oplevert, en dat is een veel makkelijker budgetgesprek.

‍

Wat datagereedheid voor AI-agents echt betekent

Datagereedheid voor AI-agents is de situatie waarin een agent de data kan bereiken die 1 specifieke workflow nodig heeft, begrijpt wat die data betekent, ermee kan handelen, en gecontroleerd en gecorrigeerd kan worden als hij fout zit. Het is een eigenschap van een workflow plus de systemen die die workflow raakt. Het is geen score voor je organisatie.

Die definitie doet ertoe, want agentgereedheid is niet hetzelfde als analyticsgereedheid, en teams blijven de oude maatstaf gebruiken. Een dashboard leest. Een agent leest en doet daarna iets: hij verstrekt de creditnota, past het record aan, stuurt het bericht, boekt het slot. Data klaarmaken voor een dashboard betekent cijfers kloppend en consistent maken over het hele bedrijf. Data klaarmaken voor een agent betekent 1 pad van begin tot eind betrouwbaar maken, inclusief het deel waarin er iets verandert in een bronsysteem.

De lat beweegt dus twee kanten op tegelijk, en dat is het deel waar mensen over struikelen. Op breedte ligt hij veel lager. Een agent die leveranciersfacturen verwerkt maakt het niet uit dat je marketingattributie rommelig is of dat finance en sales het oneens zijn over wat een gesloten deal is. Hij raakt misschien 4 tabellen en 2 systemen. De brede beoordeling scoort al je 40 systemen en geeft rood licht op basis van 36 systemen die de agent nooit zal zien.

Op dat smalle stuk ligt de lat juist een stuk hoger. Mensen repareren de hele dag stilletjes slechte data. Iemand van operations ziet een leveranciersnaam op 3 manieren gespeld en weet dat het 1 bedrijf is. Ze zien dat de factuurdatum overduidelijk fout is en checken de mailwisseling. Ze weten dat een status van in behandeling in het oude systeem eigenlijk goedgekeurd betekent, door een migratie in 2023 die niemand heeft vastgelegd. Een agent heeft daar niets van. Hij behandelt wat hij leest als waar en handelt ernaar, op machinesnelheid, zonder het moment waarop een mens denkt dat ziet er raar uit.

Dat is het echte werk van datagereedheid voor AI-agents. Niet alles opschonen, maar precies weten welke reparaties een mens in deze ene workflow stilzwijgend uitvoerde, en per reparatie besluiten of je de data repareert, de regel vastlegt, of de case naar een mens stuurt.

‍

Waarom eerst het datalandschap repareren de verkeerde eerste stap is

De landschap-eerst-aanpak mislukt om een reden die niets te maken heeft met de vraag of het werk waardevol is. Hij mislukt omdat hij 6 tot 12 maanden kosten vooraf laat gaan aan het eerste bewijs, en de meeste organisaties overleven dat gat politiek niet.

Kijk hoe het loopt. Er komt een beoordeling over het hele bedrijf. Die levert een echt goed document op: versnipperd eigenaarschap, niet vastgelegde definities, geen lineage, gaten in toegangsbeheer. Het herstel wordt als programma opgezet. Ergens in maand 5 wisselt de opdrachtgever van rol, of verschuift een financieringsronde de prioriteiten, of levert een concurrent iets en gaat de aandacht daarheen. Het programma wordt teruggeschroefd. Twee jaar later stelt hetzelfde bedrijf dezelfde vraag en krijgt hetzelfde document, want er is niets aan het landschap verbeterd en die agent is er ook nooit gekomen.

De tweede manier van mislukken is subtieler en schadelijker, omdat hij op zorgvuldigheid lijkt. De beoordeling zegt niet klaar, en dat oordeel wordt behandeld als een feit over het bedrijf in plaats van als een gemiddelde over systemen van totaal verschillende kwaliteit. Gemiddelden verbergen precies wat je moet weten. Ergens in dat landschap zitten meestal 2 of 3 workflows op prima data met duidelijk eigenaarschap, en die workflows zijn zojuist geblokkeerd door de staat van een CRM dat je toch nooit ging aansluiten.

Het is eerlijk om te benoemen waarom dit advies zo gangbaar is. Deels is het het veilige antwoord, want niemand is ooit bekritiseerd omdat hij betere governance aanraadde. Deels ligt het aan wie het advies geeft: een groot deel van de luidste content over AI-ready data komt van bedrijven die catalogi, contracten en semantische lagen verkopen, en de aanbevolen eerste stap is steevast precies wat zij verkopen. En deels klopt de onderliggende analyse gewoon. De voorspelling van Gartner dat meer dan 40 procent van de agentic AI-projecten voor eind 2027 wordt gestopt wijst op oplopende kosten, onduidelijke bedrijfswaarde en onvoldoende risicobeheersing. Zwakke datafundamenten voeden alle 3. De diagnose klopt. De voorgeschreven volgorde richt de schade aan.

Dit betekent niet dat het werk aan het landschap voor altijd optioneel is. Wil je zien hoe het volledige plaatje eruitziet als een organisatie er wel voor kiest, dan schreef het team van Martin Fowler een grondige behandeling van je data klaarmaken voor agentic AI, over contracten, lineage, een contextlaag en agent-klare toegang. Het is serieus engineeringdenken en het klopt grotendeels. Ons meningsverschil gaat alleen over volgorde. Dat werk financier je nadat de eerste agent draait, met die draaiende agent als argument.

‍

‍

Download de AI-blueprint die wij hiervoor gebruiken

Ben je nu een eerste workflow aan het kiezen, dan behandelt onze SaaS founder's AI Blueprint dezelfde stof in een vorm die je meeneemt naar een planningssessie: hoe je een eerste AI-workflow afbakent, wat je meet, en waar teams stelselmatig te veel uitgeven. Hij is gratis en kost ongeveer 20 minuten.

‍

De 7 checks die je vertellen of 1 workflow agent-klaar is

Doe deze tegen 1 workflow, niet tegen het bedrijf. Elke check heeft een test die je in een middag afrondt, en elke check heeft een ja of nee. Weersta de neiging om iets oranje te scoren, want oranje is precies hoe een project zichzelf overtuigt om te bouwen op grond die het niet houdt.

1. Kan de agent bij de data zonder mens ertussen?

De agent heeft programmatische toegang nodig tot elk systeem dat de workflow raakt, onder eigen inloggegevens, met de rechten die hij in productie krijgt. Geen CSV die iemand maandags exporteert. Geen screenshot. Geen collega die op verzoek een query draait.

Test het door een engineer de laatste 20 echte cases in een uur via de echte koppeling op te halen. Lukt dat, dan slaagt deze check. Gaat het antwoord over een persoon, een spreadsheet of een gesprek met een leverancier over API-tarieven, dan zakt hij, en heb je de echte kosten van het project gevonden voordat je er geld aan uitgaf.

2. Is er 1 afgesproken definitie van het centrale object?

Elke workflow heeft een centraal object: een order, een claim, een dienst, een consult, een ticket. De check is of de mensen die de workflow draaien het op dezelfde manier definieren, en of de systemen het met ze eens zijn.

Vraag 3 mensen die het werk doen om het los van elkaar op te schrijven. Krijg je 3 verschillende antwoorden op wanneer een order een order wordt, dan krijgt de agent alle 3 en kiest hij slecht. Deze check is goedkoop en hier zitten de meeste verrassingen. Je hebt geen semantische laag voor de hele onderneming nodig. Je hebt 1 opgeschreven definitie per workflow nodig waar het team zijn handtekening onder zet.

3. Is de data actueel genoeg voor het besluit, niet alleen juist?

Actualiteit beoordeel je tegen het besluit, niet tegen een algemene norm. Een maandprognose kan prima met data van een dag oud. Een agent die beslist of een zending vrijgegeven wordt kan niet werken met een voorraadcijfer dat 's nachts synchroniseert, want dan belooft hij vol overtuiging goederen die vanochtend het magazijn uit zijn gegaan.

Schrijf op hoeveel vertraging het besluit verdraagt, en meet daarna de echte vertraging op de slechtste bron in de keten. Is die groter dan wat het besluit aankan, dan zakt deze check totdat je de synchronisatie repareert of het besluit versmalt.

4. Kun je 50 oude cases met bekende juiste antwoorden leveren?

Dit is de check die projecten die opleveren scheidt van projecten die discussieren. Je hebt een set echte historische cases nodig waarvan je weet wat de juiste uitkomst was, zodat je de agent kunt meten in plaats van er indrukken over te vormen.

Vijftig is meestal genoeg om te beginnen. Het moeten echte cases zijn met hun echte rommeligheid, inclusief de vervelende, geen opgepoetste demoset. Kan niemand 50 zulke cases samenstellen, dan heeft de workflow ofwel geen stabiel begrip van juist, en is het dus een oordeelskwestie en een slechte eerste kandidaat, ofwel zijn de uitkomsten nooit vastgelegd, en dat is een oplosbaar probleem van 2 dagen werk waard. Behandel dit als een harde poort.

5. Is er een manier voor de agent om te handelen, niet alleen te antwoorden?

Een agent die alleen tekst produceert heeft het werk verplaatst in plaats van weggenomen. Iemand moet de uitvoer nog steeds lezen en overtypen in het systeem waar het om gaat. De workflow heeft een schrijfpad nodig: een API die de creditnota maakt, het record bijwerkt of het ticket verplaatst, en een serviceaccount dat die mag gebruiken.

Controleer of dat schrijfpad bestaat en of iemand goedkeurt dat de agent het gebruikt. Het technische antwoord en het politieke antwoord verschillen vaak, en het politieke duurt langer.

6. Kun je zien wat hij deed en het terugdraaien?

Elke agent zit er soms naast. Gereedheid gaat er niet over dat te voorkomen, maar of een foute actie zichtbaar en omkeerbaar is. Je hebt een log nodig van wat de agent las, besloot en wijzigde, plus een manier om een wijziging terug te draaien zonder database-restore.

Vraag wat er gebeurt als de agent 's nachts 200 cases verkeerd verwerkt. Is het eerlijke antwoord dat je het van een klant zou horen en het met de hand zou herstellen, dan zakt deze check. De oplossing is meestal klein: schrijf naar een tussenstatus die een mens vrijgeeft, of bouw een terugdraaipad voordat je autonomie toevoegt.

7. Mag je deze data zo gebruiken?

De laatste check is juridisch en contractueel, en het is de andere harde poort. Raakt de workflow persoonsgegevens of bijzondere categorieen, dekt je privacyverklaring geautomatiseerde verwerking, staat het klantcontract toe deze data naar een modelleverancier te sturen, en heeft het besluit gevolgen voor een persoon die verplichtingen onder de EU AI Act oproepen.

Het antwoord is meestal ja, met voorwaarden: verwerking in een bepaalde regio houden, besluiten loggen, of een mens in de goedkeuringsstap laten. Zet die voorwaarden op papier voor de bouw, want ze achteraf inbouwen is waar AI-projecten maanden verliezen. Wil je een gestructureerde manier om te zien welke workflows deze aandacht uberhaupt waard zijn, dan sluit onze gids over het in kaart brengen van AI-kansen in je workflow hier goed op aan.

‍

‍

Hoe je scoort, en de eerlijke ondergrens

Tel de geslaagde checks. De scoring is bewust bot, want botte scoring levert besluiten op en genuanceerde scoring levert nog een overleg op.

• 7 van 7: bouw nu. Zet een eerste versie op 6 tot 10 weken en leg hem vroeg voor aan echte gebruikers.

• 6 van 7: bouw nu, terwijl je dat ene gat dicht, tenzij het gat check 4 of check 7 is.

• 5 van 7: besteed eerst 2 tot 4 weken aan het dichten van de gaten. Op dit niveau gaat het meestal om toegang of omkeerbaarheid, en dat is gewoon engineering.

• 4 of lager: kies een andere workflow. Het herstel duurt langer dan de bouw, en je verbrandt het politieke krediet van het project aan leidingwerk.

Check 4 en 7 gaan boven de telling. Zonder ground truth kun je niet aantonen dat de agent werkt, dus discussieer je in elke evaluatie over indrukken, en dat is precies hoe projecten stilvallen. Zonder toestemming bouw je iets dat juridisch later wordt gestopt, op een veel slechter moment. Een workflow die 6 checks haalt maar zakt op ground truth is geen 6, het is een nee.

Nog iets dat gewoon gezegd moet worden. Een zakkende score is een goede uitkomst. Je bent 4 dagen kwijt en weet dat deze workflow het niet is, en dat is goedkoop. De dure versie van die les komt in maand 5 van een bouwtraject.

‍

Wat je doet als een check zakt

De meeste problemen kosten dagen om op te lossen. Dit zijn de 3 die we het vaakst zien en wat ze echt kosten.

Geen programmatische toegang

Een oud systeem zonder bruikbare API is de meest voorkomende blokkade, en de meest voorkomende overreactie is voorstellen het te vervangen. Dat hoeft zelden. Een read replica van de database, een geplande export naar een kleine tussentabel, of een dunne service voor het oude systeem geeft een agent meestal binnen een of twee weken alles wat hij nodig heeft. Automatisering op schermniveau is een laatste redmiddel, werkbaar maar kwetsbaar, en alleen de moeite waard als de waarde van de workflow het onderhoud duidelijk rechtvaardigt.

Geen ground truth

Zijn de uitkomsten nooit vastgelegd, bouw de set dan met de hand. Haal 50 tot 100 oude cases op, ga 2 sessies zitten met de persoon die het werk doet, en laat die per case de juiste uitkomst benoemen met een zin toelichting. Dit zijn de 2 waardevolste dagen van het hele project. Je krijgt een evaluatieset, en je krijgt de beslisregels die het team in zijn hoofd had en nooit opschreef, en dat is meestal waardevoller dan de set zelf.

Geen manier om terug te draaien

Kan een wijziging niet worden teruggedraaid, begin dan niet met een autonome agent. Laat hem een voorgestelde actie in een wachtrij schrijven die een mens vrijgeeft, en log elk veld dat hij zou hebben gewijzigd. Je levert in de eerste weken wat tijdwinst in en je houdt alle leerwinst. Houden de evaluatiecijfers stand over een paar honderd echte cases, zet dan de categorieen met laag risico en hoge zekerheid op automatisch en laat de rest in de wachtrij.

‍

Een uitgewerkt voorbeeld: terugbetalingen bij een SaaS-bedrijf met 60 mensen

Neem een supportteam dat ongeveer 400 verzoeken om terugbetaling per maand verwerkt. Elk verzoek kost ruwweg 9 minuten: ticket lezen, abonnement en betaalhistorie checken, beleid toepassen, toekennen of afwijzen, antwoord schrijven. Het is repetitief, het is duur, en het team heeft er een hekel aan. Een schoolvoorbeeld van een kandidaat.

Het scoren kostte 4 dagen. Toegang slaagde, want de betaalprovider en de helpdesk hebben allebei degelijke API's en een engineer haalde 20 echte cases er binnen een uur doorheen. Betekenis slaagde na een korte discussie: 3 mensen definieerden een terechte terugbetaling vrijwel identiek, met alleen verschil over jaarabonnementen die halverwege werden opgezegd, en dat was in 1 gesprek opgelost en opgeschreven. Actualiteit slaagde ruim, want betaaldata is binnen minuten actueel en het besluit verdraagt uren. Actie slaagde, want de betaal-API maakt creditnota's en support had al een serviceaccount.

Drie checks hadden werk nodig. Ground truth zakte eerst, omdat uitkomsten in vrije tekst in ticketantwoorden stonden in plaats van in een veld. Twee middagen met de supportlead leverden 80 gelabelde cases met toelichting op, waaronder 11 echt dubbelzinnige die de nuttigste voorbeelden in de set bleken. Omkeerbaarheid zakte, want een onterecht verstrekte creditnota moest handmatig door iemand van finance worden teruggedraaid. Toestemming slaagde met voorwaarden: alleen verwerking in de EU, geen kaartgegevens in prompts, en een gelogde menselijke goedkeuring voor alles boven 250 euro.

Score bij de start: 4 van 7. Score 9 dagen later: 7 van 7, na het bouwen van de labelset en het toevoegen van een goedkeuringswachtrij voor terugbetalingen boven 250 euro. De bouw duurde daarna 7 weken. De agent handelt ruwweg 70 procent van de verzoeken volledig af en escaleert de rest met een samenvatting en een advies. Ook de doorlooptijd van de geescaleerde cases daalde, omdat de context al samengesteld binnenkomt.

Wat opvalt is dat er niets veranderde aan het bredere datalandschap van het bedrijf. Het CRM is nog steeds inconsistent. Productanalytics en finance spreken elkaar nog steeds tegen. Niets daarvan deed ertoe, want niets daarvan zat in het pad van de terugbetalingen.

‍

Wat er na de eerste workflow gebeurt

De tweede workflow is veel goedkoper dan de eerste, en dat is het argument waarmee je het werk aan het landschap later wel gefinancierd krijgt.

Tegen de tijd dat de eerste agent draait heb je dingen gebouwd die meeverhuizen. Serviceaccounts en toegangspatronen voor 2 of 3 kernsystemen. Een log- en evaluatieharnas. Een patroon voor een goedkeuringswachtrij. Een opgeschreven definitie van 1 centraal bedrijfsobject. Een juridische toets die de algemene vragen over modelleveranciers, regio's en bewaartermijnen al beantwoordde. De volgende workflow hergebruikt het grootste deel daarvan en scoort in de eerste ronde meestal 5 of 6 in plaats van 3.

Doe dit 4 of 5 keer en je komt op een interessante plek uit. Je hebt vastgelegde definities voor je belangrijkste objecten, beheerde programmatische toegang tot je hoofdsystemen, beslislogs en evaluatiesets. Dat is een flink deel van wat het brede programma zou opleveren, alleen is het gebouwd in de volgorde die bij elke stap waarde opleverde, en werd elke stap betaald door het resultaat van de vorige. De volgorde is het hele punt. De bestemmingen verschillen niet zo veel.

Het is ook het verschil tussen een pilot die doorgroeit en een die stilletjes doodgaat, waar we uitgebreider over schreven in waarom de meeste AI-pilots vastlopen op weg naar productie.

‍

Hoe wij datagereedheid aanpakken bij Codelevate

Als een klant ons vraagt of hun data klaar is voor een agent, doen we geen beoordeling over het hele bedrijf. We vragen welke workflow, doen daarna deze 7 checks tegen die workflow samen met hun team, meestal binnen een week, en geven een eerlijk antwoord, inclusief het antwoord dat niemand leuk vindt: dat een favoriete workflow een 3 scoort en iets minder spannends een 6.

Twee gewoontes zijn belangrijker dan het raamwerk. Ten eerste scoren we tegen echte cases, niet tegen beschrijvingen van het proces. Wat mensen denken dat de workflow doet en wat de laatste 20 tickets laten zien zijn verschillende documenten, en in dat gat wordt het project of een succes of duur. Ten tweede bouwen we de evaluatieset voordat we de agent bouwen, want een team dat het ding kan meten kan het zonder ons verbeteren, en een team dat dat niet kan blijft afhankelijk van wie het bouwde.

Wil je zien hoe dat als traject loopt, dan neemt onze pagina over ons AI automation agency je mee door het proces, de teamsamenstelling en hoe een eerste workflow wordt afgebakend.

‍

De korte versie

Datagereedheid voor AI-agents is een eigenschap op workflowniveau, niet een score op bedrijfsniveau, en het als dat laatste behandelen is waarom zoveel agentprojecten nooit beginnen. Kies 1 workflow, doe de 7 checks, en neem het antwoord serieus in beide richtingen: bouwen als hij slaagt, weglopen als hij zakt. Je hebt binnen een week een echt antwoord, voor de prijs van een paar dagen engineeringtijd, in plaats van een programma dat een document oplevert.

Wil je een gestructureerd startpunt, neem dan de SaaS founder's AI Blueprint mee naar je volgende planningssessie en gebruik hem om die eerste workflow goed af te bakenen.

‍

‍

En heb je al een workflow in gedachten en wil je een tweede mening over of de data eronder standhoudt, plan dan een gratis gesprek met ons team en doen we de checks samen met je.