Hoe AI-ready data er echt uitziet: een praktische checklist

In veel organisaties is op dit moment een AI-project goedgekeurd, een leverancier gekozen en staat er ergens op een roadmap een go-live-datum. Zes maanden later is het team met iets anders bezig dan gepland: het bouwt de data-infrastructuur opnieuw op in plaats van erop voort te bouwen.

Made with AI

Het verschil tussen waar AI-initiatieven beginnen en waar ze werkelijk uitkomen, heeft meestal dezelfde oorzaak: de data was niet in de staat die het project nodig had, en niemand had dat systematisch beoordeeld voordat de scope werd vastgesteld.

AI-readiness gaat niet over de meest geavanceerde tools. Het komt neer op vijf dingen, en de meeste daarvan zijn eerst organisatorisch en pas daarna technisch.

Schone data, en weten waar die niet schoon is

"Schone data" wordt vaak als een ja-neevraag behandeld: data is schoon of niet, en het antwoord is meestal "grotendeels". Belangrijker is of het team weet waar de gaten in de kwaliteit zitten en welke gevolgen die verderop hebben voor de AI-use case in kwestie.

Kwaliteitsproblemen die niet gedocumenteerd zijn, zijn lastiger te beheersen dan bekende. Een dataset met erkende gaten, waarover het team heeft afgesproken hoe het ermee omgaat, is een veel betrouwbaarder fundament dan een dataset die als correct wordt beschouwd omdat niemand er goed naar heeft gekeken. AI-uitkomsten die op dat tweede type zijn gebaseerd, gaan stil mis: het model blijft resultaten leveren zonder zichtbaar teken dat de input onbetrouwbaar was.

In de praktijk betekent dit dat je de specifieke datasets waar je AI-use case van afhangt controleert voordat de scope van het project vastligt. Geen volledig datakwaliteitsprogramma, maar een gerichte controle van volledigheid, duplicaten en actualiteit van juist die input.

Een duidelijke eigenaar per dataset

Elke dataset waar een AI-systeem op leunt, heeft een eigenaar nodig die er verantwoordelijk voor is: iemand van wie de verantwoordelijkheid ook de kwaliteit, de definitie en de beschikbaarheid op de lange termijn omvat, niet alleen iemand wiens naam in een systeem staat.

Gaten in het eigenaarschap komen in AI-projecten op herkenbare manieren naar boven: een trainingsdataset waar testaccounts in bleken te zitten, een churnmodel dat getraind was op contractdata inclusief geannuleerde pilots, een aanbevelingssysteem dat gevoed werd door een veld dat niemand meer bijhoudt. In al die gevallen deed het model wat het moest doen. Het probleem zat in de data die het vertrouwde.

Eigenaarschap toewijzen geeft wrijving, en teams verzetten zich er vaak tegen. Dat verzet is begrijpelijk: er komt verantwoordelijkheid bij waar die er eerst niet was. Maar wat het kost als data zonder eigenaar door een AI-systeem in productie stroomt, is meer dan wat het gesprek kost om vast te leggen wie waarvoor verantwoordelijk is.

Gedocumenteerde pipelines

Als je niet helder kunt uitleggen welke weg data aflegt van bronsysteem tot modelinput, kun je de uitkomsten van dat model niet volledig vertrouwen. Niet omdat het model fout zit, maar omdat de input niet goed genoeg begrepen wordt om te weten wanneer die verandert op een manier die ertoe doet.

Het meest voorkomende gat is hier niet dat documentatie overal ontbreekt, maar dat ze ontbreekt op de punten waar data wordt getransformeerd. Wat is er met dit veld gebeurd tussen het bronsysteem en het warehouse? Is het ergens gefilterd, geaggregeerd of aangevuld met geschatte waarden? Als één data engineer de enige is die het antwoord weet, heeft het systeem een afhankelijkheid die vroeg of laat een probleem oplevert.

Lineage-tools, zoals de ingebouwde data lineage van BigQuery, Dataplex of een lichte catalogustool, maken deze transformatiepaden zichtbaar en controleerbaar. Voor AI-systemen die je in de loop van de tijd moet monitoren en debuggen, is die zichtbaarheid geen optionele infrastructuur. Het maakt het verschil tussen een systeem dat je kunt onderhouden en een systeem dat je alleen kunt vervangen.

Made with AI

Een manier om te zien wanneer uitkomsten verslechteren

De meeste AI-projecten plannen de lancering zorgvuldig. Minder projecten plannen wat er zes maanden later gebeurt, wanneer da, wanneer bronsystemen verderop in de keten veranderen, of wanneer de aannames van het model over de wereld geleidelijk niet meer kloppen met de werkelijkheid.

Een feedbacklus betekent hier een gemonitord signaal dat iemand waarschuwt als er iets mis is gegaan: detectie van data drift, monitoring van de verdeling van de uitkomsten, of bedrijfsmetrics verderop die samenhangen met de prestaties van het model. Zonder zo'n lus verslechtert het systeem ongemerkt. Het model blijft uitkomsten leveren, het team blijft ze vertrouwen, en het eerste zichtbare teken van een probleem is vaak een zakelijke beslissing die niemand kan verklaren.

Dit vanaf het begin in het projectontwerp opnemen is makkelijker dan het achteraf toevoegen. Het vraagt ook om een duidelijk antwoord op de vraag wie verantwoordelijk is voor de monitoring, en daarmee komen meestal dezelfde vragen over eigenaarschap boven als bij de rest van deze lijst.

De discipline om eerst te repareren en dan pas uit te breiden

In evaluaties van AI-projecten keert een patroon steeds terug: er dook een kwaliteitsprobleem op, en in plaats van het direct aan te pakken, werkte het team eromheen. Er kwam een transformatie bij om het te compenseren. Er werd een aparte pipeline toegevoegd. De workaround werkte goed genoeg om het project door te laten gaan, en het onderliggende probleem bleef eronder gewoon bestaan.

Na verloop van tijd stapelen die compensaties zich op. Het datafundament wordt complexer, het aantal mensen dat het begrijpt neemt af, en de kosten om de oorzaak uiteindelijk op te lossen stijgen. AI-readiness vraagt vaak om een periode van bewust herstelwerk voordat je er een nieuwe toepassing bovenop bouwt: pipelines uitfaseren die hun oorspronkelijke doel hebben overleefd, definities vastleggen waar meerdere teams het echt over eens zijn, kwaliteitsproblemen oplossen in plaats van workarounds in te bouwen.

Deze fase staat meestal niet in projectvoorstellen, en daar loopt de planning vaak als eerste uit. Organisaties die haar als noodzakelijk accepteren, er expliciet ruimte voor maken en haar zien als investering in het fundament in plaats van als vertraging, staan er duidelijk anders voor als het model uiteindelijk live gaat.

Waar je begint

Deze vijf voorwaarden hoeven niet perfect te zijn voordat een project begint, maar je moet ze wel eerlijk beoordelen. Een data readiness review voordat de scope vastligt, waarin je bekijkt welke datasets erbij betrokken zijn, wie de eigenaar is, hoe de data stroomt en welke kwaliteitsproblemen bekend zijn, is een veel kleinere investering dan de gaten pas twaalf maanden na de start van een project ontdekken.

Wil je weten hoe je data er echt voor staat voor je volgende AI-initiatief? Dan zoeken we dat graag samen met je uit.

Laten we praten.