Data voorbereiden voor AI: waarom een AI-project vaak al slaagt of faalt voordat er een model is

Veel AI-projecten die tegenvallen, zaten al in de problemen voordat iemand een model koos, omdat de data niet klaar was. Data voorbereiden voor AI is het werk dat dit voorkomt. Het komt erop neer dat je de data voor een usecase zo op orde brengt dat het AI-systeem erop kan bouwen, en dat die op orde blijft. Sla je dat over, dan geeft ook een uitstekend model onbetrouwbare antwoorden.

Dit zien we bij projecten van elke omvang. Een proof of concept draait op een schone steekproef en maakt indruk. Daarna gaat het team over op het echte CRM, de gedeelde schijven en een e-mailarchief van jaren. Dan kloppen de antwoorden steeds minder vaak. Het model is niet veranderd. De data wel.

Daarom hoort datavoorbereiding thuis in je AI-strategie, niet in een opschoonfase achteraf. Deze gids legt uit waarom, en laat zien hoe een team het werk doet: de workflow, de tools en een dataset vóór en na de voorbereiding.

In het kort:

• AI is maar zo betrouwbaar als de data erachter, welk model je ook kiest.
• Of je data klaar is, hangt af van de usecase, dus je bereidt alleen de data voor waar die usecase op steunt.
• Voorbereiden stopt niet bij de livegang, omdat de data blijft veranderen.

Waarom bepaalt datavoorbereiding of een AI-project slaagt?

Een AI-systeem kan alleen werken met de data die het krijgt, dus gaten, dubbelingen en tegenstrijdigheden komen terug in de output. Het model weet niet welk van twee adressen actueel is. Het kiest er toch een en presenteert dat vol overtuiging.

Onderzoek wijst dezelfde kant op. RAND interviewde 65 ervaren data scientists en engineers over mislukte AI-projecten. Een van de vijf hoofdoorzaken die ze vonden, is dat de organisatie de data mist om een goed werkend AI-model te trainen. In februari 2025 voorspelde Gartner dat organisaties tot en met 2026 zouden stoppen met 60 procent van de AI-projecten zonder AI-ready data.

De schade komt vaak laat aan het licht. Onderzoekers van Google spraken met 53 AI-professionals in domeinen waar veel op het spel staat. Van hen had 92 procent te maken gehad met een datacascade: een dataprobleem waarvan de gevolgen zich verderop in de keten opstapelen. De onderzoekers zeggen het in de titel van hun paper zonder omwegen: iedereen wil aan het model werken, niemand aan de data.

Een geavanceerder model lost een dataprobleem zelden op. Een leverancier kan het model verbeteren, maar alleen je eigen organisatie kan je data verbeteren.

Wat houdt datavoorbereiding voor AI precies in?

Datavoorbereiding voor AI bestaat uit vier taken: de data vinden, herstellen, geschikt maken voor het AI-systeem en blijvend beheren. Veel organisaties denken alleen aan de tweede taak, het opschonen, maar de andere drie wegen even zwaar.

De data vinden betekent weten wat er is, waar het staat en welke bron je voor elk gegeven vertrouwt. In vrijwel elk AI-assessment dat wij doen, blijkt minstens één afdeling al met een abonnement te werken waar IT niet van weet. De data in die tool ontbreekt dan ook in het overzicht van IT.

De data herstellen begint met profileren: je meet hoe volledig, consistent en actueel de data is voordat je iets verandert. Meestal vind je ontbrekende waarden, dubbele records, verouderde gegevens en verschillende schrijfwijzen voor hetzelfde, zoals “B.V.” naast “BV”. Uitschieters vragen aandacht, want sommige zijn fouten en andere zijn juist de zeldzame gevallen die het systeem moet kunnen verwerken. Dat klopt met onze eigen projecten voor documentverwerking: de hoofdroute is snel gebouwd, en het laatste stuk nauwkeurigheid komt volledig uit het afhandelen van de lastige gevallen.

Hoe je de data geschikt maakt, hangt af van het type AI. Machine learning heeft features nodig, zoals het aantal orders in de afgelopen 90 dagen in plaats van een ruwe ordertabel. Voor generatieve AI zet je pdf’s, e-mails en wikipagina’s om in schone tekst, met metadata zoals eigenaar, datum, versie en toegangsrechten. Moet een model iets leren beoordelen, bijvoorbeeld welke supporttickets urgent zijn, dan heb je eerst gelabelde voorbeelden nodig.

De vierde taak, beheer, gaat over privacy, rechten, herkomst (waar elk gegeven vandaan komt) en kwaliteitscontroles. Beheer maakt de andere drie ook herhaalbaar.

Waarom is bedrijfsdata zo lastig klaar te maken voor AI?

Bedrijfssystemen delen zelden data, toegangsrechten zijn doorgaans te ruim en datakwaliteit heeft vaak geen eigenaar. Elk systeem is aangeschaft voor één proces, met eigen nummers en definities. Sales telt een klant misschien als actief na één order in twee jaar, terwijl finance alleen klanten met een lopend contract meetelt. Een assistent die beide systemen leest, kan twee verschillende antwoorden op dezelfde vraag geven.

Problemen met toegangsrechten ontdek je vaak pas als een assistent live is. Volgens de privacydocumentatie van Microsoft toont Microsoft 365 Copilot alleen data waarvoor een gebruiker al leesrechten heeft. Dat ontwerp klopt. Maar daardoor kan de assistent ook alles tonen uit een map die jaren geleden te breed is gedeeld.

Dan is er het eigenaarschap. In veel organisaties is niemand verantwoordelijk voor de kwaliteit van de klantdata zelf, alleen voor de processen waarin die data ontstaat. Ervaren medewerkers vangen dat op, want zij weten welke spreadsheet actueel is. Een AI-systeem heeft die kennis niet, dus komen de kwaliteitsproblemen in zijn antwoorden terecht.

Hoe werkt een workflow voor datavoorbereiding in de praktijk?

Datavoorbereiding voor AI verloopt als een pipeline van acht fasen, van de bronsystemen tot de monitoring na de livegang. De tabel volgt één usecase: de klantassistent in de volgende sectie. De tools tussen haakjes zijn voorbeelden van een categorie, geen vereisten.

Fase	Wat er gebeurt (en de output)	Gangbare aanpak	Wat er mis kan gaan
1. Bronsystemen	Inventariseer de systemen die de usecase nodig heeft en de leidende bron per veld (broninventaris)	Spreadsheet of datacatalogus (Microsoft Purview, DataHub)	De eigen tool van een afdeling wordt gemist
2. Extractie	Kopieer data ongewijzigd naar een ruwe laag, in batches of bij elke wijziging (ruwe tabellen met laaddatum)	Connectorpipelines (Azure Data Factory, Fabric Data Factory), exports, API’s	Rijen die ongemerkt wegvallen, of een handmatige export die niemand herhaalt
3. Profileren	Meet per veld volledigheid, uniciteit, geldigheid en actualiteit (problemen en hun omvang)	SQL; profileringsbibliotheken voor Python (fg-data-profiling); kolomprofilering in Power Query	Profileren op een steekproef, zoals de standaard van Power Query: de eerste 1.000 rijen
4. Opschonen	Herstel notaties, breng varianten terug tot één waarde en markeer regelovertredingen (opgeschoonde dataset en wijzigingslog)	SQL- of dbt-modellen; Python (pandas)	Overschreven waarden die niemand kan herleiden
5. Transformatie	Voeg klantrecords samen onder vaste nummers en zet contracten om in tekstpassages met metadata (gebruiksklare tabellen en passages)	dbt-modellen; Python; bibliotheken voor entity resolution (Splink); documentparsers (Azure Document Intelligence, Docling)	Twee bedrijven samengevoegd, of features met informatie uit de toekomst
6. Validatie	Toets elke batch aan afgesproken regels en drempels (geslaagd of mislukt; mislukte batches worden tegengehouden)	dbt data tests en model contracts; datakwaliteitstools (Great Expectations, Soda)	Wel de structuur controleren, maar niet de waarden
7. Ontsluiten of indexeren	Publiceer de data waar het AI-systeem die leest (een tabel, een API of een zoekindex met embeddings en rechten)	Views, featuretabellen en API’s; alleen voor RAG: zoekindexen of vectordatabases (Azure AI Search, pgvector)	Documenten geïndexeerd zonder hun toegangsrechten
8. Monitoren	Controleer actualiteit, volumes en kwaliteit, en draai de vragen met bekende antwoorden opnieuw (meldingen aan de data-eigenaar)	Geplande controles in de orchestrator; source freshness checks in dbt	Meldingen naar een gedeelde inbox, of drift die niemand opmerkt

Een paar termen vragen om uitleg. dbt draait SQL-transformaties als code onder versiebeheer en test de resultaten, en een model contract legt vast welke kolommen en datatypes een dbt-model moet opleveren. Entity resolution bepaalt welke records bij dezelfde werkelijke klant horen. Een embedding is een reeks getallen die de betekenis van een passage vastlegt, zodat een assistent op betekenis kan zoeken. Een orchestrator (Airflow, Dagster of Fabric Data Factory) plant alle acht fasen in en draait ze opnieuw. Veel teams noemen de ruwe laag bronze, de opgeschoonde laag silver en de gebruiksklare laag gold.

Hoe maak je datakwaliteit meetbaar?

Je meet datakwaliteit per veld met vier maatstaven, elk met een drempel die je met de data-eigenaar afspreekt:

• Volledigheid: het aandeel records met een waarde.
• Uniciteit: het aandeel sleutels dat één keer voorkomt.
• Geldigheid: het aandeel waarden dat aan de notatieregel voldoet.
• Actualiteit: de tijd sinds de laatste update.

Wat gebeurt er als je een AI-assistent koppelt aan je klantdata?

Een AI-assistent die je rechtstreeks op versnipperde klantdata aansluit, geeft wisselende en soms foute antwoorden, zoals dit samengestelde scenario laat zien. Het is gebaseerd op situaties die we regelmatig tegenkomen, niet op één klant. Een bedrijf wil een assistent die accountmanagers een compleet beeld van elke klant geeft. De data staat in een CRM, een ERP-systeem, supporttickets, SharePoint, e-mail, Excel-bestanden en een productdatabase.

De assistent op alles aansluiten gaat snel, maar levert vier soorten fouten op. De eerste gaat over identiteit. Dezelfde klant staat in het CRM onder de statutaire naam en in het ERP onder een afkorting, dus een deel van de historie valt weg. Twee bedrijven met een vergelijkbare naam kunnen ook samensmelten tot één klant.

De tweede is tegenstrijdige informatie, zoals twee contractversies naast elkaar. De derde is toegang: een stagiair krijgt in een antwoord de margeanalyse van een klant te zien. De vierde is ontbrekende inhoud: belangrijke feiten zitten in een persoonlijke mailbox of in een gescand contract dat de assistent niet kan lezen.

In een paper uit 2024 noemen Barnett en collega’s ontbrekende inhoud het eerste van zeven punten waarop retrieval-augmented generation (RAG) kan falen. Met die techniek antwoordt een assistent op basis van je eigen documenten.

Datavoorbereiding pakt alle vier de problemen aan in zeven stappen:

1. Bepaal per soort informatie welk systeem leidend is. Leg dat per veld vast, bijvoorbeeld het adres uit het ERP en de contractstatus uit SharePoint.
2. Voeg dubbele klanten samen onder één vast klantnummer. Match eerst op het KvK-nummer. Ontbreekt dat, dan zoekt fuzzy matching naar namen en adressen die sterk op elkaar lijken, en beoordeelt een medewerker de twijfelgevallen.
3. Corrigeer verouderde en foute records in het bronsysteem, zodat de correctie de volgende synchronisatie overleeft. Afgekeurde records gaan als taak naar de eigenaar van dat systeem.
4. Haal de belangrijkste feiten uit pdf’s, scans en e-mails. Een documentparser met optische tekenherkenning (OCR) zet ze om in tekst, en elke passage krijgt klantnummer, versie, status en eigenaar mee.
5. Controleer per bronsysteem wie wat mag zien, en neem die toegangsregels daarna over in de assistent. Elke passage krijgt de groepen mee die hem mogen lezen, en elke zoekvraag wordt op de identiteit van de gebruiker gefilterd voordat het model tekst ziet. Dat heet security trimming.
6. Test het resultaat met echte vragen waarvan je het juiste antwoord al kent. Neem ook vragen op die sommige gebruikers niet beantwoord mogen krijgen, en draai de set na elke wijziging opnieuw.
7. Automatiseer deze stappen in een pipeline die alarm slaat zodra de kwaliteit daalt. De data-eigenaar krijgt een melding als een afgesproken drempel wordt overschreden, bijvoorbeeld bij verouderde records of nieuwe dubbelingen.

De kortingsmatching die we voor Friesland Lease bouwden, laat zien wat werkt als de data niet perfect is. De applicatie koppelt zo’n 2.900 auto’s in het wagenbestand aan kortingslijsten die per merk verschillen. Elke match krijgt een confidence-score, en matches met een lage score gaan naar een verificatiescherm waar het team ze controleert. Dat is het realistische doel: data die betrouwbaar genoeg is voor de beslissing, plus een duidelijke route voor de gevallen waarin dat niet zo is.

Hoe ziet de klantdata eruit voor en na de voorbereiding?

Vóór de voorbereiding is één klant verspreid over vier records die elkaar tegenspreken. Daarna is het één gevalideerd record, gekoppeld aan één geldend contract. De data is illustratief en komt uit het samengestelde scenario, niet van een klant:

Bron	CRM-klantnummer	Klantnaam	Land	Startdatum contract	Gekoppeld contract
CRM	C-1042	Acme B.V.	NL	03-02-2024	Contract_Acme_def.pdf
ERP	(geen)	ACME BV	Netherlands	2024-02-03	(geen)
Excel-bestand	(geen)	Acme	Nederland	3 feb 2024	Contract_Acme_def_v2.pdf
CRM	C-2291	ACME B.V.	NL	01/06/2021	Contract_Acme_2021.pdf

De naam heeft vier schrijfwijzen, het land drie en de datums vier notaties. Hetzelfde bedrijf heeft twee CRM-nummers, en twee rijen hebben er geen. Er zijn drie contractbestanden, en uit geen ervan blijkt welk bestand geldt. Na de voorbereiding is de klant één record:

Klantnummer	Statutaire naam	Land	Startdatum contract	Leidende bron	Validatie
K-000417	Acme B.V.	NL	2024-02-03	Naam: CRM · Contract: SharePoint	Geslaagd: uniek nummer, geldige landcode, geldige datum

De vier rijen hebben hetzelfde KvK-nummer (niet getoond), en daarom zijn ze samengevoegd. Een koppeltabel verbindt elke bronrij met K-000417. Elk contractbestand krijgt nu dat nummer mee, plus versie, status, eigenaar en toegangsrechten. Alleen het geldende contract, Contract_Acme_def_v2.pdf, wordt geïndexeerd. De assistent haalt dus alleen dat contract op, koppelt het aan één klant en toont het alleen aan de groepen die het mogen lezen.

Hoe verschilt datavoorbereiding voor generatieve AI, machine learning en AI-agents?

Elk type AI vraagt iets anders: generatieve AI actuele documenten, machine learning consistente records en agents data die klopt op het moment van handelen.

Type AI	Waar de data aan moet voldoen	Typische fout
Generatieve AI-assistenten en RAG	Actuele, ontdubbelde documenten met metadata en toegangsregels	Een stellig antwoord op basis van een verouderd of afgeschermd document
Machine learning	Volledige, consistente en representatieve records, zonder informatie uit de toekomst	Sterke testscores die in productie instorten
Predictive analytics	Lange historie met definities die in de tijd gelijk blijven	Een voorspelling die een systeemmigratie aanziet voor een trend
AI-agents en automatisering	Juiste, gevalideerde data op het moment van handelen	De juiste actie bij de verkeerde klant, de verkeerde order of het verkeerde bedrag

Machine learning kent een specifieke valkuil: leakage. Daarbij bevat de trainingsdata informatie die het model op het moment van voorspellen niet heeft. Kapoor en Narayanan inventariseerden 294 gepubliceerde wetenschappelijke artikelen uit 17 vakgebieden waarin leakage was vastgesteld. Soms leidde dat tot veel te rooskleurige conclusies. Bij data met een tijdsdimensie voorkom je leakage meestal door de data op datum te splitsen in plaats van willekeurig, en features alleen te bouwen uit data die er op het moment van voorspellen al was.

Bij agents staat er meer op het spel, omdat ze op basis van data handelen in plaats van die alleen te beschrijven. Een fout adres leidt tot een levering op de verkeerde plek.

Ook een systeem dat alleen informatie geeft, kan je organisatie aansprakelijk maken. De chatbot van Air Canada ging in tegen de eigen regels van de maatschappij voor kortingstickets bij een overlijden in de familie. Een Canadees tribunaal oordeelde dat Air Canada verantwoordelijk is voor alle informatie op haar website, de chatbot inbegrepen.

Wat zijn de meest gemaakte fouten bij datavoorbereiding?

De meest gemaakte fouten ontstaan al bij de afbakening van het werk, voordat iemand de data aanraakt. De eerste twee komen uit dezelfde misser voort: alle data tegelijk willen aanpakken.

Sommige organisaties willen eerst alles opschonen. Zonder usecase weet dan niemand wanneer het goed genoeg is, en heeft het werk geen einddatum. Andere sluiten al hun bronnen aan, in de veronderstelling dat meer data beter is. Maar twee bronnen die elkaar tegenspreken, maken een assistent minder betrouwbaar dan één bron die klopt.

Een derde fout is datavoorbereiding zien als een eenmalig project. Zonder automatische controles gaat een systeem dat bij oplevering klopte, ongemerkt achteruit naarmate de data verandert.

De vierde is rechten, privacy en eigenaarschap voor je uit schuiven. Persoonsgegevens vallen vanaf de eerste dag onder de AVG. Voor AI-systemen met een hoog risico eist artikel 10 van de EU AI Act daarnaast dat het databeheer de datavoorbereiding omvat, zoals labelen, opschonen en verrijken. Die regels gelden vanaf 2 december 2027 voor de hoogrisicosystemen uit bijlage III. Dat is de stand van zaken in september 2026, zoals ons overzicht van de AI Act uitlegt.

Is je data klaar voor AI?

Je data is klaar voor AI als je tien vragen over één specifieke usecase kunt beantwoorden met bewijs in plaats van aannames. Volgens het persbericht van Gartner uit februari 2025 moet AI-ready data representatief zijn voor de usecase, fouten en uitschieters inbegrepen.

Vraag	Een goed antwoord	Waarschuwingssignaal
1. Weten we welke bronnen ertoe doen voor deze usecase?	Een korte lijst systemen en documentverzamelingen, elk met een reden	“Alles, voor de zekerheid”
2. Kunnen we bij de data die we nodig hebben?	Technische toegang, plus toestemming om de data voor dit doel te gebruiken	Data die vastzit in een leverancierssysteem of alleen via een handmatige export beschikbaar is
3. Zijn onze systemen het eens over de belangrijkste definities?	Één vastgelegde definitie voor begrippen als “klant” en “actieve klant”	Elke afdeling hanteert een eigen definitie
4. Is de data volledig en actueel genoeg?	Gemeten volledigheid en ouderdom van de velden die ertoe doen	Niemand weet hoe oud de records zijn
5. Is er voor elk gegeven een leidende bron?	Een benoemd bronsysteem per data-element	Meerdere systemen die allemaal als leidend worden gezien
6. Zijn documenten gestructureerd en doorzoekbaar?	Bestanden met doorzoekbare tekst, plus versie, datum, status en eigenaar	Scans, dubbelingen en bestanden met namen als “definitief_v3_def”
7. Gaan we goed om met rechten en persoonsgegevens?	Rechten gecontroleerd, persoonsgegevens in kaart gebracht en tot het nodige beperkt	Breed gedeelde mappen en persoonsgegevens die niemand in kaart heeft gebracht
8. Kunnen we datakwaliteit meten?	Automatische controles met drempelwaarden en meldingen	Kwaliteit op gevoel
9. Kunnen we de voorbereiding herhalen voor nieuwe data?	Een geplande, gedocumenteerde pipeline	Een eenmalig script op iemands laptop
10. Wie is eigenaar van de data en de kwaliteit ervan?	Een benoemde eigenaar uit de business per dataset	“IT”, of niemand

De proceseigenaren horen de vragen mee te beantwoorden, niet alleen IT. Elke vraag die je niet met bewijs kunt beantwoorden, wordt een werkpunt. Zitten er gaten bij rechten, persoonsgegevens of eigenaarschap, leg de ontwikkeling dan stil: juist die gaten kunnen van een tegenvallende pilot een incident maken. Je kunt de vragen downloaden als werkblad van één pagina en dat per usecase invullen.

Waar begin je met data voorbereiden voor AI?

Het beste startpunt is één duidelijk afgebakende usecase in plaats van je complete datalandschap.

1. Kies een usecase met een meetbaar resultaat en een eigenaar uit de business. Door je usecases eerst te scoren op waarde en complexiteit, begin je minder snel waar de data het zwakst is.
2. Zet op een rij welke velden, documenten en historie de usecase nodig heeft, met de leidende bron voor elk onderdeel.
3. Profileer alleen die data, en verzamel echte testgevallen met bekende antwoorden.
4. Herstel wat de uitkomst wezenlijk beïnvloedt, en zet voor de rest waarborgen in, zoals menselijke controle.
5. Bouw de pipeline, de datatests en de monitoring vóór de livegang, en laat de volgende usecase daarna op hetzelfde fundament voortbouwen.

Je eigen historie is vaak de beste testset. Bij een project voor het automatisch verwerken van inkoopfacturen hebben we een heel jaar aan facturen als benchmark gedraaid, ongeveer 7.000 stuks. Het systeem verwerkte 88 procent volledig automatisch. Facturen zonder annotatie werden in 93,5 procent van de gevallen op basis van boekhistorie op de juiste grootboekrekening geboekt.

Wat moet je regelen voordat je een AI-model of -platform kiest?

Voordat je een model of platform kiest, moet je weten of je data de usecase aankan die je voor ogen hebt. Dat uitzoeken kost nu minder dan na een mislukte pilot.

Naar onze ervaring is er bij de AI-projecten die in productie komen meestal iemand die weet welke data te vertrouwen is, en waarom.

We hebben de afgelopen 18 maanden ruim 40 AI-assessments gedaan, bij gemeenten, maakbedrijven, bouwers, zorgorganisaties en investeringsmaatschappijen. Voor je eerste usecase laat een assessment zien welke data je nodig hebt, waar die staat en wat er beter moet voordat je gaat bouwen.

Veelgestelde vragen over data voorbereiden voor AI (FAQ)