Waar haalt jouw AI zijn data vandaan?

Beslissing één: bekijk hoe de gegevens het model bereiken
Er zijn eigenlijk maar drie leveringspatronen, waarbij je een afweging moet maken tussen actualiteit, historisch overzicht en de hoeveelheid infrastructuur die je bereid bent te beheren.

1. Batchgewijs naar een datawarehouse, data lake of objectopslag. Je integratielaag haalt op gezette tijden gegevens uit bronsystemen en slaat het resultaat op op een plek waar je embedding- of opvraagtaak het al kan lezen. Dit is de standaardinstelling voor RAG-corpora, fine-tuning-sets en elke opvraagtaak waarbij over een langere periode moet worden geredeneerd.

• Voordelen: de meest uitgebreide historiek, zodat het model periodes kan vergelijken en kan zien hoe iets is veranderd. Elke tool die SQL ondersteunt of bestanden kan lezen, kan de data verwerken, en je behoudt de controle over het corpus.

• Nadelen: de actualiteit is nooit beter dan het extractieschema, dus tussen de runs door is het model ongetwijfeld verouderd. Je beheert de opslag zelf en betaalt er ook voor.

2. Een operationele replica die actueel wordt gehouden door middel van Change Data Capture ( CDC ). Log-gebaseerde CDC leest het transactielogboek van de database in plaats van herhaaldelijk de productiedatabase te bevragen, waardoor een replica continu dicht bij de live-status blijft. Dit is het patroon voor latentiegevoelige operationele AI: een ondersteunende assistent die de status van een bestelling moet weten op het moment dat de klant ernaar vraagt.

• Voordelen: een bijna realtime status zonder dat het registratiesysteem wordt belast met query’s, en verwijderingen worden vastgelegd in plaats van ongemerkt te verdwijnen.
• Nadelen: je krijgt de huidige status van de gerepliceerde tabellen, geen uitgebreide geschiedenis. Log-gebaseerde vastlegging is voornamelijk beschikbaar voor de grote relationele databases en vereist configuratie aan de bronzijde, en de replica is nog een database die moet draaien.
  

3. Directe opvraging zonder enige opslaglaag. Het integratieplatform bewaart de laatste extractie en levert deze via een REST-interface (JSON of CSV) of een kolomgeoriënteerd formaat zoals Apache Arrow, dat steeds vaker aan assistenten wordt aangeboden via het Model Context Protocol, de opkomende standaard voor het koppelen van AI-clients aan externe systemen.

• Voordelen: er is niets te beheren en het is de snelste route van vraag naar antwoord, waardoor het de logische keuze is voor assistenten die alleen actuele cijfers nodig hebben en verder niets.

• Nadelen: alleen recente extracties, dus geen lange geschiedenis en geen complexe koppelingen tussen bronnen. Je bent gebonden aan de tarieflimieten en quota van de aanbieder, en de gegevens staan in de cache van iemand anders.
  

Deze laten zich goed combineren. Een ondersteuningsmedewerker kan vragen over de bestelstatus beantwoorden vanuit de replica terwijl de kennisbank opnieuw wordt ingelezen vanuit het datawarehouse, en een marketingmedewerker haalt de campagnecijfers van gisteravond direct op. Wat je niet moet doen, is er per ongeluk één kiezen en vervolgens verrast worden door het actualiteitsprofiel ervan.

Beslissing twee: bekijk waar persoonlijke gegevens worden verwijderd
Hiervoor geldt een deadline, en die deadline is voordat er iets wordt ingebed.

Zodra een waarde in een vectorindex is geschreven of in modelgewichten is opgenomen, is het verwijderen ervan geen ‘delete’-opdracht. Het Europees Comité voor gegevensbescherming heeft de regelgevende versie van dit punt vastgelegd in Advies 28/2024, aangenomen op 17 december 2024: een model dat is getraind met persoonsgegevens kan in geen enkel geval als anoniem worden beschouwd, en elke bewering van anonimiteit moet per geval worden beoordeeld, inclusief de waarschijnlijkheid dat persoonsgegevens via query’s kunnen worden geëxtraheerd.

Het praktische antwoord is om dit bij de extractie aan te pakken, waarvoor twee doeltreffende en betrouwbare instrumenten beschikbaar zijn. Bij uitsluiting wordt de kolom simpelweg nooit opgehaald: namen, adressen en identificatiegegevens blijven in het bronsysteem en kunnen niet uitlekken vanaf een plek waar ze nooit zijn aangekomen. Bij deterministische hashing wordt de waarde vervangen door een eenrichtingshash, zodat dezelfde invoer altijd dezelfde uitvoer oplevert. Je pijplijn kan nog steeds op die kolom samenvoegen, ontdubbelen en matchen zonder dat iemand stroomafwaarts het origineel te zien krijgt.

Doe het één keer, in de pijplijn, en je lost geen privacyprobleem op. Je voorkomt er een, voorgoed. Elk systeem dat die bestemming leest, neemt deze beslissing over: het datawarehouse, de index, de assistent die je team dit kwartaal test, en de systemen die nog door niemand zijn ontworpen.

Beslissing drie: wat gaat mee met de gegevens
Bij elke rij horen twee dingen: een garantie dat deze intact is, en voldoende context om uit te leggen wat deze betekent.

Het eerste is een validatiecontrole op het niveau van de gegevensstroom, in plaats van een controle achteraf. Fouten in de gegevenskwaliteit zijn erger voor AI dan voor dashboards, omdat een grafiek die platloopt door een mens wordt opgemerkt, terwijl een retrieval-systeem dat een tabel vol null-waarden en nullen krijgt, deze feilloos zal weergeven. Regels op kolomniveau voor null-waarden, nullen en afwijkingen kunnen in twee modi worden uitgevoerd. In de blokkeringsmodus komen records die niet voldoen nooit terecht in de tabel die uw inbeddingstaak leest, zodat een defecte export stroomopwaarts de index niet stilletjes kan vervuilen. In de bewakingsmodus gaan de gegevens door en krijgt u een melding, wat ook een nuttig signaal is om te beslissen wanneer u opnieuw moet indexeren. Controleer of dezelfde regels gelden voor handmatige backfills, met een bewuste overschrijving in plaats van een stille omzeiling.

De tweede is degene die stilletjes bepaalt of je AI-project drie weken of drie kwartalen duurt: de zakelijke context, gedragen door de pijplijn zelf.

Denk eens aan een CRM. Je integratielaag levert een kolom op met de naam ‘dealstage’, die waarden bevat als ‘qualifiedtobuy’ en ‘closedwon’, naast een aangepast veld met de naam ‘f_status_c’. Voor een model zijn dat strings. Voor je omzetteam is een daarvan het verschil tussen een prognose en een fantasie. Iemand moet uitleggen dat ‘f_status_c’ de vlag voor verlengingsrisico is, dat deze alleen wordt bijgehouden voor enterprise-accounts en dat de fasenamen afgelopen voorjaar zijn gewijzigd. Hetzelfde geldt voor elke bron die je koppelt: het advertentieplatform waar ‘conversies’ iets specifieks betekenen, de supporttool met drie verschillende tijdstempels voor hetzelfde ticket.

Je kunt dat allemaal handmatig invoeren, in een semantische laag die door één persoon wordt onderhouden en waar alle anderen stilletjes wantrouwig tegenover staan, en het werk telkens opnieuw doen wanneer een CRM-beheerder een veld toevoegt.

Of de pijplijn kan het overnemen, omdat de connector het al weet: datasetbeschrijvingen van wat een tabel vertegenwoordigt, veldbeschrijvingen van wat elke kolom betekent, en gevoeligheidsvlaggen die aangeven welke velden persoonsgegevens bevatten.

Voeg ook de technische metadata toe: een tijdstempel voor de extractie, zodat taken alleen nieuwe gegevens verwerken, en een stabiele rij-hash die als natuurlijke sleutel dient voor het verwijderen van dubbele gegevens en updates.

Dat is het verschil tussen een agent die je schema raadt en een die de definitie leest, en tussen governance-controles die iemand handmatig uitvoert en controles die automatisch worden uitgevoerd op basis van wat er daadwerkelijk is binnengekomen. Het kost slechts een vinkje bij de configuratie van de bron. Het bespaart een gegevenswoordenboek dat niemand wilde onderhouden.

Zes vragen die je je eigen stack zou moeten stellen

1. Hoe actueel is een antwoord, eerlijk gezegd? Actualiteit is het extractieschema plus indexvernieuwing, niet een eigenschap van het model.

2. Waar worden persoonsgegevens verwijderd? Als het antwoord “in de vectordatabase” is, is het al te laat.

3. Wat gebeurt er als een upstream-export mislukt? Komt de onjuiste data terecht, of wordt deze geblokkeerd voordat de index deze ziet?

4. Kan de pijplijn zichzelf uitleggen: tijdstempels, stabiele sleutels, veldbeschrijvingen, gevoeligheidsvlaggen?

5. Als een assistent je gegevens rechtstreeks opvraagt, waar heeft die toegang dan nog meer toegang toe?

6. Hoeveel afzonderlijke tools zijn er vandaag de dag nodig om al het bovenstaande te dekken: één voor extractie, één voor het vastleggen van wijzigingen, één voor maskering, één voor validatie en één voor de catalogus? Elke overdracht tussen deze tools is een naad waar actualiteit, context of governance stilletjes verloren gaat, en een stack die dit alles op één plek afhandelt, is meer waard dan de som van zijn functies.

Dit is allemaal niet het spannende deel van een AI-programma, en hiermee zul je geen applaus oogsten in een stuurgroep. Maar het is meestal wel het verschil tussen de pilot die iedereen tijdens de demo indruk maakte en de pilot die daadwerkelijk in productie is genomen, een beveiligingsbeoordeling heeft doorstaan en zes maanden later nog steeds het vertrouwen van het bedrijf geniet. Als jij degene bent die verantwoordelijk is voor dat resultaat, is het datapad geen detail dat je kunt uitstellen tot de laatste sprint.

Deze blogpost is bijgedragen door Dataddo, een modern data-integratieplatform dat is gebouwd voor het AI-tijdperk. Dataddo helpt organisaties om gegevens uit een breed scala aan bronnen veilig te koppelen voor AI, analytics en rapportage, terwijl ze de volledige controle over hun gegevens behouden en vendor lock-in vermijden. Lees meer op www.dataddo.com of bezoek Dataddo op Data Expo.