Het AI-project begon veelbelovend. De use case was helder, het model draaide in een pilot, de eerste demo’s zagen er goed uit. En toen kwam de productiefase — en liep alles vast. De voorspellingen klopten niet, gebruikers vertrouwden de uitkomsten niet, en niemand kon precies aanwijzen waar het misging.
Wie een tijdje meeloopt in dit vak, herkent het patroon. Het probleem zit zelden alleen in het model: doelstelling, adoptie, integratie en beheer bepalen net zo goed of iets slaagt. Maar de data is in onze ervaring het hardnekkigst, en het minst zichtbaar zolang je in de pilotfase zit. Hieronder lees je waarom dat zo is, hoe je het herkent vóórdat het geld kost, en wat een realistische aanpak is.
Waarom datakwaliteit AI-projecten laat stranden
Het onderliggende principe is oud en onverbiddelijk: garbage in, garbage out. Een systeem dat leert van verkeerde, onvolledige of inconsistente informatie, produceert uitkomsten die je bedrijfsvoering eerder schaden dan verbeteren.
Het verraderlijke: dit zie je vaak pas laat. In de pilots die wij tegenkomen draait het model op een geselecteerde of deels opgeschoonde dataset, waardoor het in die fase prima lijkt te presteren. De overgang naar productie — waar het model de volledige werkelijkheid van je organisatie te verwerken krijgt — is in onze ervaring het moment waarop de gaten zichtbaar worden.
Daar komt bij dat AI datakwaliteitsproblemen kan versterken. Een verkeerd cijfer in een rapportage kan een oplettende analist opvallen. Output van een model wordt vaak op grotere schaal en met minder menselijke tussenkomst gebruikt — waardoor fouten in de onderliggende data verder kunnen doorwerken voordat iemand ze opmerkt.
Vier problemen die we vaak tegenkomen
Datakwaliteit is een containerbegrip. De onderstaande vier categorieën zien we in de praktijk geregeld terug. Ze zijn niet uitputtend — ook zaken als representativiteit, bias en herleidbaarheid van data spelen mee — maar het zijn goede plekken om te beginnen met kijken.
1. Versnipperde data en silo’s
Klantgegevens in het CRM, transacties in het ERP, contactgeschiedenis in een servicedesksysteem — en nergens één consistent beeld. Dat kost dubbel werk en leidt tot besluiten op een half beeld. Voor AI komt daar iets bij: verbanden tussen gegevens die niet verantwoord gekoppeld of gezamenlijk ontsloten kunnen worden, blijven buiten het bereik van het model — hoe goed dat model verder ook is.
2. Inconsistente definities
Wat is een “actieve klant”? Wanneer telt een aanvraag als “afgehandeld”? Als drie afdelingen drie antwoorden geven, krijgt het model drie tegenstrijdige waarheden voorgeschoteld. De oorzaak kan technisch zijn, organisatorisch, of beide — en juist omdat het niemands exclusieve probleem is, blijft het vaak liggen.
3. Onvolledige en verouderde gegevens
Lege velden, records die nooit zijn bijgewerkt, dubbele registraties van dezelfde persoon of hetzelfde object. Een medewerker die de context kent, kan daaromheen werken. Een model heeft die context doorgaans niet, en hoe het met ontbrekende of foute waarden omgaat, hangt af van keuzes die iemand bewust moet maken.
4. Geen eigenaarschap
Het meest structurele probleem: niemand is aanwijsbaar verantwoordelijk voor de data. Fouten worden dan wel gezien, maar er is geen route om ze te melden of op te lossen. Zonder belegd eigenaarschap is de kans groot dat een opgeschoonde dataset na verloop van tijd weer verslechtert.
Hoe je weet of je data AI-klaar is
Je hoeft geen groot assessment af te wachten om een eerste indicatie te krijgen. Een eenvoudige lakmoesproef die in onze praktijk goed werkt: toets je data-infrastructuur eerst met gewone analyses, vóórdat je er AI op zet.
Kun je betrouwbare rapporten maken over het proces waar je AI op wilt zetten? Kloppen de cijfers als je ze naast elkaar legt vanuit verschillende systemen? Vertrouwen de proceseigenaren de dashboards die er nu al zijn?
Als basisrapportages al discussie opleveren — “dat cijfer klopt niet, in mijn systeem staat iets anders” — dan is je data nog niet klaar voor AI. Dat is geen diskwalificatie, maar wel een duidelijke volgorde: eerst dit oplossen, dan pas modellen bouwen.
Een paar aanvullende vragen die snel inzicht geven:
- Herkomst: weet je waar de data vandaan komt en hoe die is vastgelegd?
- Volledigheid: hoe groot is het aandeel lege of duidelijk foutieve velden in de kernattributen?
- Actualiteit: wanneer zijn de gegevens voor het laatst gecontroleerd of bijgewerkt?
- Eigenaarschap: kun je per databron één expliciete rol of functionaris aanwijzen die verantwoordelijk is?
Een praktische vuistregel: blijf je op meerdere van deze vragen het antwoord schuldig, dan heb je je startpunt gevonden.
Wat werkt: datakwaliteit als proces, niet alleen als project
De reflex bij een datakwaliteitsprobleem is een opschoonactie: een team dat een paar weken data poetst, waarna het project doorgaat. Zo’n actie kan nuttig zijn — maar als eenmalige exercitie is die zelden voldoende. De reden is simpel: zonder processen voor datakwaliteit verslechtert je data weer, omdat de bron van de vervuiling — het dagelijkse werkproces — ongewijzigd blijft.
Wat in onze ervaring wél houdbaar is: datakwaliteit inrichten als doorlopend proces. De kern daarvan:
Afspraken over vastlegging. Bepaal hoe nieuwe informatie wordt geregistreerd: verplichte velden, gestandaardiseerde waarden, geen vrije tekstvelden waar gestructureerde data hoort. Veel vervuiling ontstaat bij de invoer — al kunnen ook migraties, koppelingen en veroudering een bron zijn.
Belegde verantwoordelijkheid. Wijs per databron of datadomein een eigenaar aan die verantwoordelijk is voor controles en voor het afhandelen van gemelde afwijkingen. In veel organisaties hoeft dat geen fulltime rol te zijn; het belangrijkste is dat de rol een naam heeft en dat duidelijk is wie hem vervult.
Omgaan met afwijkingen. Spreek af wat er gebeurt als iemand een fout vindt: waar meld je het, wie pakt het op, binnen welke termijn. Ontbreekt zo’n route, dan is het risico groot dat meldingen blijven liggen en de meldingsbereidheid afneemt.
Monitoring op de kernvelden. Je hoeft niet alles te meten. Kies de datavelden die het meest bepalend zijn voor je AI-toepassing en houd daar de volledigheid en consistentie van bij. Verslechtering wil je zien voordat het model het merkt.
Begin klein: scope op de use case, niet op het datalandschap
Een veelgemaakte fout is de conclusie omdraaien: “onze data moet eerst helemaal op orde, dus we starten een organisatiebreed dataprogramma van drie jaar.” Dat is de andere manier om een AI-ambitie te laten stranden — nu niet op slechte data, maar op een traject zonder einde.
De pragmatische route: begin bij één concrete use case en breng alleen de data op orde die dáárvoor nodig is. Dat is een overzichtelijke scope, en de lessen die je onderweg leert — over definities, eigenaarschap, invoerdiscipline — neem je mee naar het volgende domein.
Wees daarbij eerlijk over de doorlooptijd. Hoeveel tijd het op orde brengen van data kost, verschilt sterk per use case, organisatie en bestaande infrastructuur — maar het wordt in onze ervaring vaker onderschat dan overschat. Wie daar vooraf realistisch over is, voorkomt de druk om met gebrekkige data toch maar live te gaan.
Vergeet de randvoorwaarden niet: vertrouwen en regelgeving
Datakwaliteit gaat uiteindelijk over vertrouwen. Gebruikers die evident foute uitkomsten uit een AI-systeem zien, verliezen vertrouwen in dat systeem — en dat vertrouwen herstellen kost doorgaans meer moeite dan het vooraf goed regelen.
Er is ook een compliance-kant. De AVG kent een juistheidsbeginsel (artikel 5 lid 1 onder d): persoonsgegevens moeten juist zijn en waar nodig worden geactualiseerd. Wat dat concreet betekent, hangt af van onder meer je rol, het doel, de grondslag en het risico van de verwerking. De Autoriteit Persoonsgegevens publiceert hier uitleg over; wie AI toepast op persoonsgegevens doet er goed aan dit beginsel expliciet mee te nemen in de afweging.
De Europese AI-verordening stelt daarnaast in artikel 10 eisen aan data governance voor bepaalde AI-systemen met een hoog risico, onder meer aan relevante kwaliteitsaspecten van trainings-, validatie- en testdatasets. Welke verplichtingen op jouw organisatie van toepassing zijn, hangt af van je rol, het type systeem en de toepassing. Dit is geen juridisch advies; laat je hierover adviseren door een specialist. De algemene richting is wel duidelijk: grip op je data helpt ook bij het voldoen aan dit soort eisen.
Voor organisaties die besluiten nemen die mensen raken — zeker in de (semi-)publieke sector — geldt bovendien: welke uitleg je ook moet of wilt geven over een besluit waar AI aan bijdraagt, die uitleg begint bij de vraag of de onderliggende data klopt.
De eerste stap: een nulmeting op één use case
Je hoeft niet te wachten op een groot programma om te beginnen. Doe dit:
- Kies één AI-use case die je serieus overweegt of waar je in vastloopt.
- Benoem de vijf tot tien datavelden die daarvoor bepalend zijn.
- Meet de kwaliteit van precies die velden: volledigheid, consistentie tussen systemen, actualiteit.
- Beantwoord de eigenaarschapsvraag: welke rol is per bron verantwoordelijk? Als het antwoord “niemand” is, is dát je eerste actie.
Hoeveel tijd zo’n nulmeting kost, hangt af van hoe toegankelijk je data is — maar door de scope bewust klein te houden, blijft het behapbaar. Het resultaat is een concrete verbeterlijst in plaats van een vaag gevoel dat “de data niet op orde is”.
En als de uitkomst tegenvalt? Dan heb je die les geleerd vóórdat er een model op gebouwd is. Dat is precies het verschil tussen AI-projecten die stranden en projecten die een reële kans maken.