Een van de meest gehoorde zinnen in een intake-workshop met een klant: "We hebben duizenden documenten, databases, een geschiedenis van servicelogboeken, e-mails van klanten — data hebben we zeker." Technisch gezien klopt dat. Maar zodra we vragen hoe een representatief record eruitziet en waar het precies vandaan komt, beginnen de details naar boven te komen: bestanden opgeslagen in drie verschillende versies van SharePoint, records vol duplicaten met onderling tegenstrijdige waarden, documenten gescand als afbeeldingen zonder OCR, Excel-tabellen met kolomnamen die alleen begrijpelijk zijn voor degene die ze in 2018 aangemaakt heeft.
Data-gereedheid is, volgens meerdere onderzoeken, de doorslaggevende factor tussen AI-projecten die meetbare waarde hebben opgeleverd en projecten die zijn geëindigd als verlaten pilots. Dit artikel gaat niet over welke modellen u moet inzetten. Het gaat over wat er gedaan moet worden vóórdat u überhaupt bij de modellen uitkomt.
Waarom "we hebben data" ≠ "data is klaar"
Data-gereedheid voor AI heeft een andere definitie dan "de data staat ergens opgeslagen". Een model — of het nu gaat om een RAG-pipeline of fine-tuning — heeft data nodig in een specifieke staat:
- Machineleesbaar: tekst geëxtraheerd uit PDF's, afbeeldingen en tabellen in gestructureerde vorm
- Consistent: dezelfde entiteiten consequent benoemd (klant "ACME s.r.o." vs. "Acme SR" vs. "ACME Slovakia" zijn voor het model drie verschillende entiteiten)
- Relevant en schoon: zonder duplicaten, zonder verouderde versies, zonder interne "ruis" (testrecords, sandboxdata, conceptdocumenten)
- Correct geannoteerd of gestructureerd: het model moet weten wat de data representeert, niet alleen ruwe tekst zien
- Toegankelijk en beheersbaar: duidelijk eigenaarschap, versie, geldigheidsdatum, toegangsrechten
De Cisco AI Readiness Index rapporteert dat slechts ~34 % van de bedrijven de eigen data-gereedheid als voldoende beoordeelt voor AI-inzet. Vanuit onze praktijkervaring klinkt dat zelfs optimistisch — de meeste projecten besteden het eerste derde deel van het totale engagement aan data-voorbereiding, niet aan modellen.
Fase 1: Inventarisatie — wat hebben we eigenlijk
Vóór elke technische beslissing is het noodzakelijk de bestaande databronnen in kaart te brengen. In de praktijk betekent dat antwoorden vinden op de volgende vragen:
Waar bevindt de data zich fysiek?
- Databases (PostgreSQL, MySQL, MSSQL, Oracle)
- Gedeelde schijven en documentmanagementsystemen (SharePoint, Google Drive, NAS)
- ERP / MES / SCADA-systemen (SAP, Infor, Siemens WinCC, Ignition)
- E-mail en communicatietools
- Papieren documentatie gescand als afbeeldingen
- Machine- en sensordata (MQTT, OPC-UA, industriële databases zoals InfluxDB)
Elke bron heeft een ander formaat, een andere updatefrequentie, een andere mate van structuur en andere toegangsrechten. Een overzicht van alle bronnen is het eerste artefact van een datapipeline-project.
Hoe is de kwaliteit?
Schat per bron in:
- Procentuele volledigheid van kernvelden (hoeveel records hebben alle verplichte velden ingevuld?)
- Consistentie van het formaat (staan datums altijd in hetzelfde formaat? Komen categorieën uit een vaste codelijst of is het vrije tekst?)
- Duplicatie (bestaan er records die dezelfde entiteit meerdere keren vertegenwoordigen?)
- Actualiteit (wanneer is een record voor het laatst geverifieerd? Bestaan er verouderde versies?)
Deze audit hoeft niet perfect te zijn — het doel is kritieke problemen identificeren die het project zouden blokkeren, niet honderd procent zuiverheid bereiken vóór de start.
Wie is eigenaar van de data?
Per bron: wie is verantwoordelijk voor de inhoud? Wie heeft de bevoegdheid toegang te wijzigen? Wie kan uitleggen wat een record betekent? Zonder helder data-eigenaarschap kan een AI-project vastlopen in interdepartementale discussies over wie toestemming geeft dat zijn database gebruikt mag worden voor training of retrieval.
Fase 2: Extractie en normalisatie
Zodra de bronnen bekend zijn, volgt het technische werk: de data in een uniforme vorm brengen waarmee de pipeline kan werken.
Extractie uit gestructureerde bronnen
Uit relationele databases en ERP-systemen is extractie relatief rechttoe rechtaan — SQL-queries, API-calls, CSV-export. Cruciaal is het definiëren van:
- 1.Welke tabellen / velden relevant zijn voor de betreffende use-case (niet het hele ERP exporteren)
- 2.Hoe frequent updates plaatsvinden (batch één keer per dag, of streaming van wijzigingen via CDC — Change Data Capture)
- 3.Hoe technische veldnamen worden gemapt naar begrijpelijke omschrijvingen (kolom
ord_stat_cd→ "bestelstatus")
Extractie uit ongestructureerde bronnen
Documenten, e-mails, technische tekeningen en gescande formulieren zijn lastiger. Benodigde stappen:
- OCR voor gescande documenten: tools als Tesseract, Azure AI Document Intelligence of Google Document AI kunnen tekst extraheren uit afbeeldingen en PDF's. De kwaliteit van de OCR-output beïnvloedt direct de kwaliteit van de antwoorden van het model.
- Chunking: lange documenten moeten vóór vectorisatie worden opgedeeld in kleinere segmenten. Naïeve chunking op 512 tokens met een harde knip midden in een zin is een veelvoorkomende oorzaak van problemen in RAG-pipeline kwaliteit. Beter is chunken op logische eenheden (alinea's, secties, tabellen).
- Metadata-extractie: elk chunk moet metadata meekrijgen — waar het vandaan komt, aanmaakdatum, actualiteit, auteur en eventueel categorie. Deze metadata dienen voor filtering bij retrieval en voor het tonen van de bron in het antwoord.
Normalisatie van entiteiten
Hetzelfde bedrijf in drie verschillende schrijfwijzen is voor een vectormodel drie verschillende entiteiten met vergelijkbare embeddings, maar voor fuzzy zoeken of filtering is dat een probleem. Entity resolution — het samenvoegen van verschillende schrijfwijzen van dezelfde entiteit — is werk dat soms handmatig gedaan wordt (klantnummerlijsten), soms semi-automatisch (fuzzy matching op bedrijfsnamen) en soms met behulp van een LLM (als records in natuurlijke taal zijn opgesteld).
Fase 3: Reiniging en kwaliteitsvalidatie
Data reinigen is een iteratief proces. Het is onmogelijk dit eenmalig perfect te doen — er ontstaat voortdurend nieuwe data, formats wijzigen, nieuwe foutpatronen duiken op.
Concrete stappen die we in de praktijk zien
- Verwijderen van duplicaten: records identificeren die dezelfde informatie bevatten maar verschillende identifiers hebben
- Corrigeren van formaatfouten: datums in verschillende formaten, numerieke waarden met de eenheid meegeschreven in het veld, telefoonnummers met verschillende prefixnotaties
- Omgaan met ontbrekende waarden: aanvullen waar mogelijk, expliciet markeren waar het ontbreekt, uitsluiten waar een record zonder verplicht veld onbruikbaar is
- Filteren van irrelevante data: testrecords, sandboxomgevingen, interne notities, documenten met de classificatie "concept" of "archief"
- Verificatie van actualiteit: voor kennisbanken en RAG-pipelines kan verouderde informatie soms erger zijn dan helemaal geen informatie. Prijslijsten van twee jaar geleden, technische databladen van afgeschafte producten — die moeten ofwel een expliciete datum in de metadata hebben, of worden uitgesloten.
Reiniging voor de voorbereiding van een fine-tuning dataset heeft bovendien een extra laag: elk trainingsvoorbeeld moet de juiste invoer-uitvoerstructuur hebben, de uitvoer moet correct zijn (niet "ons best-effort schattinkje"), en de dataset moet de kernonderwerpen van het domein gelijkmatig dekken. Blinde vlekken in de dataset vertalen zich rechtstreeks in blinde vlekken van het model.
Fase 4: Structuur en toegangsrechten
Een van de meest onderschatte aspecten van data-voorbereiding is wie wat mag zien. In enterprise-omgevingen bestaan er lagen van toegangsrechten:
- Commerciële contracten en prijzen die alleen het verkoopteam mag inzien
- HR-dossiers die alleen de HR-afdeling mag inzien
- Technische documentatie die intern openbaar is maar niet naar klanten mag
- Regelgevingsdocumentatie die auditeerbaar moet zijn en niet zonder vastlegging gewijzigd mag worden
Als u een RAG-systeem inzet dat toegang heeft tot de volledige kennisbank zonder rekening te houden met deze rechten, en een medewerker van de verkoopafdeling vraagt naar de productiekosten (die alleen de productiedirecteur mag inzien) — dan antwoordt het systeem gewoon. Dat is geen feature, dat is een beveiligingsincident.
De juiste aanpak: toegangsrechten moeten ook in de vectordatabase worden overgenomen. Elk document of chunk moet metadata bevatten over wie er toegang toe heeft. Bij retrieval wordt niet alleen gefilterd op relevantie, maar ook op de vraag of de aanroepende gebruiker toegangsrecht heeft. Dit is een niet-triviale architectuur, maar bij inzet in gereguleerde sectoren (AVG, bedrijfsgeheimen) is het verplicht.
Fase 5: Pipeline en actualiteit
Een AI-datapipeline is geen eenmalige actie — het is een continu proces. Bedrijfsdata verandert elke dag. Nieuwe orders, nieuwe documenten, gewijzigde prijzen, bijgewerkte technische databladen.
Typen pipeline-architecturen
- Batch-pipeline (eenmaal per dag / per week): extractie, reiniging en herindexering van de kennisbank op vaste intervallen. Geschikt voor de meeste documentgebaseerde RAG-systemen — een tolerantie van 24 uur "staleness" is bij de meeste use-cases acceptabel.
- Streaming / near-real-time: wijzigingen in het bronsysteem worden binnen minuten doorgevoerd naar de vectordatabase. Noodzakelijk voor use-cases waarbij data snel veroudert (ticketingsystemen, live voorraad, handelssignalen). Vereist een CDC-architectuur (Change Data Capture).
- Human-in-the-loop verificatie: voor gevoelige data (medische protocollen, juridische documenten, veiligheidsmanualen) doorloopt elke wijziging in de kennisbank een menselijke goedkeuringsstap vóórdat die verschijnt in de retrieval-index.
De keuze voor een architectuur hangt af van de wijzigingsfrequentie in de brondata en de tolerantie van de use-case voor veroudering. Voor de meeste B2B-bedrijfsuse-cases volstaat een batch-pipeline — eenvoudiger te beheren, goedkoper en voldoende actueel.
Monitoring van datakwaliteit
De pipeline moet alerting hebben op data-anomalieën: een plotselinge daling van het aantal documenten (mogelijk verwijdering van de bronrepository), een stijging van het aandeel lege velden (formaatwijziging vanuit het bronsysteem), duplicaten boven een drempelwaarde (storing in de deduplicatie). Zonder monitoring worden dataproblemen pas zichtbaar wanneer het model slechte antwoorden begint te geven — en het is niet altijd triviaal om de oorzaak terug te herleiden naar de bron.
Fase 6: Governance en documentatie
Dit is het onderdeel dat technische teams het liefst overslaan, maar zonder hetwelk een AI-project bij opschaling uiteenvalt.
Wat gedocumenteerd moet worden
- Data dictionary: voor elke databron en elk relevant veld — wat het is, in welk formaat, wie het beheert, wanneer het voor het laatst geverifieerd is
- Lineage: waar de data vandaan komt, welke transformaties ze heeft ondergaan, waar ze nu staat — het vermogen om een specifieke modeluitvoer te herleiden tot een specifiek brondocument
- Wijzigingslog van de kennisbank: elke wijziging in de retrieval-index moet worden vastgelegd — wat is toegevoegd, wat gewijzigd, wat verwijderd en wanneer
- Toegangsrechten en hun geschiedenis: voor AVG-compliance en bij audits is een historisch overzicht nodig van wie toegang had tot wat en wanneer
Deze vereisten zijn niet AI-specifiek — het zijn data-governance-standaarden die volwassen organisaties hanteren voor elk kritisch systeem. AI maakt ze alleen zichtbaarder, omdat modeluitvoer direct zichtbaar is en beslissingen beïnvloedt.
Veelgemaakte fouten die we in de praktijk zien
Voordat we naar de conclusie gaan, een aantal patronen die steeds terugkomen:
- "We laden de hele SharePoint erin": volume is niet het probleem, relevantie wel. Een model dat 50.000 documenten indexeert — inclusief presentaties uit 2015, testbestanden en notulen van interne vergaderingen — zal een lagere retrieval-nauwkeurigheid hebben dan een model dat 2.000 zorgvuldig geselecteerde en schone documenten indexeert. Minder en beter is bijna altijd beter dan meer en kwalitatief slecht.
- "Dat lossen we later op": datakwaliteit wordt in AI-projecten niet "later" opgelost. Als u een RAG-systeem met slechte data in productie brengt, verliezen gebruikers er snel het vertrouwen in — en vertrouwen herwinnen is veel moeilijker dan het van het begin af aan opbouwen.
- "Onze data is gevoelig, maar dat deert ons niet": de AVG en de wet op bedrijfsgeheimen gelden ook voor AI-systemen. Als uw kennisbank persoonsgegevens, contracten met NDA of vertrouwelijke bedrijfsinformatie bevat, moet u een juridisch consistente grondslag hebben voor de verwerking daarvan in de AI-pipeline.
- "We fine-tunen op wat we hebben": zoals we beschreven hebben in het artikel over voorbereiding van een fine-tuning dataset, produceert een onvoldoende volume of slechte domeindekkking in de trainingsdata een model dat met overtuiging foute antwoorden geeft — wat erger is dan een model dat zegt "ik weet het niet". Datavoldoende is een voorwaarde voor fine-tuning, geen wenselijke aanname.
Praktische stappen om te beginnen
Als u wilt starten zonder te verdwalen in theorie:
- 1.Kies één use-case, niet "het hele bedrijf". Één concreet probleem (antwoorden op technische klantvragen, zoeken in servicedocumentatie, offertegeneratie vanuit de catalogus) heeft een afgebakend databereik.
- 2.Breng de databronnen voor die use-case in kaart — waar ze staan, welk formaat, wie de eigenaar is, hoe actueel ze zijn.
- 3.Voer een data-audit uit op een steekproef — neem 100 willekeurige records en beoordeel de kwaliteit handmatig. De meeste problemen worden dan zichtbaar.
- 4.Definieer minimale kwaliteit voor productie-inzet — niet "perfect", maar "goed genoeg voor deze use-case".
- 5.Ontwerp de pipeline — batch of streaming, toegangsrechten, monitoring.
- 6.Itereer: de eerste index zal onvolmaakt zijn. Evalueer de kwaliteit van RAG-antwoorden, identificeer de meest voorkomende oorzaken van slechte antwoorden, corrigeer de data of de pipeline en herhaal.
Veelgestelde vragen
Hoeveel data hebben we nodig voor een RAG-systeem?
Voor een functioneel RAG-systeem bestaat er geen ondergrens voor het aantal documenten — zelfs 50 goed voorbereide documenten kunnen uitstekende resultaten geven als ze het relevante domein afdekken. Kritischer dan kwantiteit is dekking: als gebruikers vragen stellen waarop de kennisbank geen antwoord heeft, zal het model dat ofwel erkennen (goed ingestelde guardrail) ofwel een antwoord verzinnen (slechte toestand). Inventariseer de vragen die het systeem moet kunnen beantwoorden en verifieer of die beantwoordbaar zijn vanuit de beschikbare data.
Kunnen we interne data gebruiken voor fine-tuning zonder juridische risico's?
Dat hangt af van de aard van de data. Interne technische manualen, SOP-documenten en historische records zonder persoonsgegevens zijn doorgaans in orde — ze zijn eigendom van het bedrijf en bevatten geen PII. Records met klantdata, contracten of persoonsgegevens van medewerkers vereisen een juridische grondslag onder de AVG (toestemming, gerechtvaardigd belang, uitvoering van een overeenkomst) ook voor verwerking in een AI-pipeline. Wij raden aan dit te bespreken met de DPO vóórdat u begint met het opbouwen van een trainingsdata set uit gereguleerde data.
Hoe lang duurt data-voorbereiding?
In de praktijk zien we een spreiding van twee weken (één goed gedefinieerde bron, goede interne documentatie, meewerkende data-eigenaren) tot zes maanden (gefragmenteerde data in drie verschillende systemen, geen bestaande data governance, interne politieke obstakels bij toegang). Een gemiddeld project besteedt 30–40 % van de totale doorlooptijd aan data-voorbereiding. Als een klant zegt dit in een week te kunnen doen, is het ofwel een heel kleine scope, ofwel een onderschatting van de omvang van het probleem.
Hebben we een data-engineer nodig of kan een AI-developer dit aan?
Voor eenvoudigere use-cases (PDF-documenten, een eenvoudige SharePoint-export) kan een AI-developer de basisextractie en chunking voor zijn rekening nemen. Voor complexere scenario's — een streaming-pipeline vanuit ERP-systemen, CDC-architectuur, entiteitsnormalisatie over meerdere bronnen, AVG-conforme lineage — is een ervaren data-engineer nodig. Het onderschatten van deze rol is een van de meest voorkomende oorzaken van vertraging in AI-projecten.
Moet de data in het Nederlands zijn, of werkt het ook in het Engels?
Voor een RAG-systeem op bedrijfsdocumenten is de taal van de documenten leidend — embedding-modellen worden meertalig gebruikt (modellen als BGE-M3 dekken 100+ talen), retrieval werkt goed in beide talen. Voor fine-tuning is de taal van de trainingsdata cruciaal — als u een model wilt dat antwoordt in professioneel Nederlands met bedrijfseigen terminologie, moeten de trainingsvoorbeelden in het Nederlands zijn met die terminologie.
*Worstelt u met de voorbereiding van bedrijfsdata voor een AI-project en wilt u onnodige valkuilen vermijden? We lopen graag samen met u een data-audit door en stellen een pipeline-architectuur voor die past bij uw use-case. Neem contact op voor een vrijblijvend gesprek.*