Je besteedt weken aan het afstellen van een AI-chatbot. De antwoorden zijn accuraat. Stakeholders geven hun akkoord en je zet hem live. Drie maanden later geeft het systeem met volle overtuiging verkeerde antwoorden op ongeveer een derde van de vragen van gebruikers. Niemand heeft het model aangepast en niemand heeft aan de prompts gezeten. De wereld is veranderd, prijzen zijn gewijzigd, een beleid is bijgewerkt, een productspecificatie heeft een nieuwe versie gekregen, en de onderliggende kennisopslag is niet mee veranderd.

Dit is geen hypothetisch scenario. Het is op dit moment een van de meest voorkomende faalmodi in productieomgevingen voor enterprise-AI, en de meeste data-engineeringteams beschikken niet over de juiste tooling om dit te signaleren, ongeacht hoe het AI-systeem de data ophaalt. Naarmate ondernemingen van AI-pilots overstappen naar productie-implementaties op schaal — Gartner heeft datakwaliteit consequent aangemerkt als een van de grootste barrières voor AI-adoptie — verschuift dit type falen van incidentele hinder naar systematisch risico.

De fout die er niet uitziet als een fout

Een AI-applicatie maakt het niet uit of die informatie ophaalt uit een vector store, een documentindex of via een API-call. Wat het mechanisme ook is, niets in een standaard retrieval-pijplijn controleert of wat wordt aangeleverd nog steeds correct is. Een verouderd prijsdocument wordt met net zoveel vertrouwen opgehaald als een actueel document, omdat het systeem relevantie of beschikbaarheid beoordeelt, niet juistheid. Om dezelfde reden gaat een record waarin ongemerkt een veld ontbreekt net zo probleemloos door als een volledig record.

Daardoor is de fout per ontwerp onzichtbaar. Verouderde of onvolledige data scoort nog steeds hoog op relevantie, of doorstaat elke controle waarvoor een datapijplijn is gebouwd. Het model antwoordt vol vertrouwen omdat de opgehaalde context gezaghebbend lijkt. Elk dashboard dat je in de gaten houdt blijft groen. Het systeem lijkt te werken. Het is alleen fout.

Ik heb een vergelijkbare variant hiervan buiten de AI-context zien gebeuren, in een fintech-pijplijn. Een upstream-systeem wijzigde een veld zonder downstream-gebruikers daarvan op de hoogte te stellen. De pijplijn faalde niet; die verspreidde simpelweg onjuiste waarden naar dashboards, omdat het systeem alleen controleerde of de taak was voltooid, niet of de data nog steeds correct was. Het probleem kwam pas aan het licht toen een klant iets inconsistent vond. Tegen die tijd was de slechte data al downstream terechtgekomen.

Of het nu gaat om een document dat verouderd is geraakt of een veld dat ongemerkt ontbreekt, de vorm van het falen is dezelfde: de afwezigheid van een foutmelding is niet hetzelfde als de aanwezigheid van juistheid, en zonder goede validatielagen in te bouwen kan niets in de pijplijn het probleem identificeren. De inzet wordt bovendien groter nu AI-agenten verschuiven van vragen beantwoorden naar acties uitvoeren — een agent die handelt op basis van verouderde prijzen of een ingetrokken beleid kan een verkeerde transactie uitvoeren, niet alleen een verkeerd antwoord geven.

Waarom dit een data-engineeringprobleem is

Teams die met dit falen te maken krijgen, diagnosticeren het vaak verkeerd, en meestal twee keer.

Het model de schuld geven: De eerste reflex is om het model de schuld te geven, een andere LLM te proberen of de prompt aan te passen. Het echte probleem ligt verder stroomopwaarts, in de data-engineeringlaag — dezelfde reflex als bij de fintech-fout hierboven: monitoring die is gebouwd voor de pijplijn, niet voor de data.

De retrieval-laag de schuld geven: Zodra het model is uitgesloten, is de volgende reflex om de retrieval- of contextlaag de schuld te geven en een betere te kopen. De timing is geen toeval. Naarmate ondernemingen deze systemen de echte productiewereld in duwen, komt precies deze kloof aan het oppervlak, en leveranciers reageren overal. AWS is net toegetreden tot de race om de "context layer" met een kennisgrafiek die leert van agentgebruik. Snowflake's nieuwe Horizon Context en Cortex Sense richten zich op exact het symptoom waarmee dit stuk begon: agenten die met overtuiging verkeerde antwoorden geven omdat niets de onderliggende bedrijfslogica beheert.

Beide zijn echte reacties op een echt probleem, maar ze zitten één laag erboven; een kennisgrafiek blijft afhankelijk van wat hem voedt. Het echte probleem ligt verder stroomopwaarts, in de data-engineeringlaag. Teams controleren of een taak heeft gedraaid, niet of de data die is verplaatst nog steeds klopt — een reflex die al jaren ouder is dan AI. Monitoring is gebouwd voor de pijplijn, niet voor de data.

Wat daadwerkelijk ontbreekt: data-observability

Data-observability is een bekend concept dat te weinig aandacht krijgt in de manier waarop het daadwerkelijk wordt geïmplementeerd. De categorie zelf is de afgelopen jaren volwassen geworden — bedrijven als Monte Carlo Data en andere hebben er gespecialiseerde platforms voor gebouwd, en IBM nam Databand in 2022 over om zijn eigen mogelijkheden op het gebied van data-observability te versterken — maar adoptie blijft ongelijk, vooral bij teams die pas recent AI-applicaties zijn gaan bouwen bovenop bestaande data-infrastructuur.

De relevante maatstaf is geen percentage — het is dekking: welk deel van de kritieke datasets heeft lineage die daadwerkelijk bevraagbaar is, in plaats van alleen in iemands hoofd te bestaan.

Uber bouwde een speciaal platform voor datakwaliteit en observability lang voordat retrieval-augmented generation bestond. Hun Unified Data Quality-platform ondersteunt meer dan 2,000 kritieke datasets en detecteert ongeveer 90% van de datakwaliteitsincidenten voordat die downstream-consumenten bereiken.

Netflix loste een ander deel van hetzelfde probleem op, door een bedrijfsbreed data-lineagesysteem te bouwen, zodat iedereen kon achterhalen waar een dataset vandaan kwam en wat ermee is gebeurd onderweg. Het brengt afhankelijkheden in kaart over Kafka topics, ML-modellen en experimenten heen, niet alleen over warehouse-tabellen. Net als bij Uber werd het platform gebouwd voor mensen, en nu is het belangrijker geworden door de opkomst van AI/LLM-applicaties.

Samen dekken Uber en Netflix twee van de vier zaken waarvoor het de moeite waard is om te bouwen. In de praktijk beschouw ik het als vier dimensies, elk meetbaar op eigen voorwaarden.

Juistheid: Voldoet elk record aan de vorm en regels waaraan het moet voldoen — de juiste veldtypen, geen onverwachte nulls, waarden binnen bereik. Tools zoals Great Expectations en Soda doen dit goed: geautomatiseerde validatie op rij- en kolomniveau in plaats van handmatige controles nadat er iets is misgegaan. Houd per run het percentage records bij dat de validatie doorstaat.

Actualiteit: Is de data nog actueel ten opzichte van de bron, niet alleen actueel op het moment van de laatste controle. Houd per bron bij hoeveel tijd is verstreken sinds de laatste succesvolle update, met een SLA per dataset in plaats van één algemene drempel, omdat sommige bronnen elk uur moeten worden ververst en andere niet.

Consistentie: Wordt hetzelfde feit overal waar het is opgeslagen of geïndexeerd op dezelfde manier gelezen. Dit faalt geruisloos — het wordt pas zichtbaar wanneer twee systemen die door dezelfde bron worden gevoed elkaar beginnen tegen te spreken. Een periodieke kruiscontrole tussen downstream-bestemmingen, waarbij een mismatchpercentage boven een drempel wordt gemarkeerd, is voldoende om dit vroeg te signaleren.

Lineage: Kun je elke output herleiden naar de bron en naar elke transformatie die die heeft doorlopen — dezelfde vraag waarvoor Netflix zijn systeem heeft gebouwd.

Niets hiervan vereist infrastructuur die de meeste datateams niet al hebben. Dat weet ik omdat ik het heb gebouwd, niet alleen omdat ik ervoor heb gepleit.

Bij Socure kwam klantdata binnen in welke vorm de klant die ook wilde aanleveren, en soms was die stilletjes verkeerd. De uitdaging was een systeem te bouwen waarin onjuiste data kon worden geïdentificeerd voordat die downstream werd verspreid. Dezelfde principes golden: valideer wat binnenkomt, begrijp waar het vandaan komt en voorkom dat slechte data het probleem van iemand anders wordt.

Great Expectations werd onderdeel van die basis: schema- en bereikvalidatie bij ingestie, SLA's per bron voor actualiteit, controles tussen systemen voor consistentie en lineage op bestandsniveau. Dit alles zat achter een write-audit-publish-patroon, waarbij data in staging terechtkwam, werd gevalideerd en alleen downstream ging als die de vereiste controles doorstond.

Het resultaat was downstream zichtbaar: betere nauwkeurigheid over de hele linie, in rapportages, in ML-modellen en in AI-retrieval die bovenop dezelfde data was gebouwd.

Wat je maandagochtend moet doen

Als je op retrieval gebaseerde AI-systemen in productie draait, is de diagnostische vraag niet welk model je hierna moet proberen of naar welke retrieval-architectuur je moet migreren. Het zijn vier specifiekere vragen:

1. Wordt de onderliggende data gevalideerd tegen de standaarden die de afnemers ervan vereisen?
2. Wat is het oudste stuk content dat momenteel met hoog vertrouwen wordt aangeboden?
3. Zouden twee stukken uit dezelfde bron elkaar ooit kunnen tegenspreken in hetzelfde retrieval-resultaat?
4. Kun je herleiden waar het vandaan kwam als het onjuist blijkt te zijn?

Als je die vragen niet kunt beantwoorden, dan zit de kloof in de pijplijn tussen je bronsystemen en datgene waaruit je agent leest. Dat vraagt om een data-engineeringoplossing, niet om een modelwissel of een migratie naar een andere leverancier.

Of je nu rapportagepijplijnen, ML-systemen of AI-agenten bouwt: juistheid, actualiteit, consistentie en lineage maken data betrouwbaar. AI legt simpelweg zwakke plekken bloot die altijd al in data-engineering hebben bestaan.