Data-classificatie als startpunt
Voordat we ook maar een pipeline aanraken, classificeren we uw datadomeinen op gevoeligheid en doel. Welke datasets bevatten persoonsgegevens, welke vallen onder bijzondere categorieën van GDPR artikel 9, welke zijn bedrijfskritisch, welke mogen op publieke clouds, welke alleen on-premise. Het resultaat is een datacatalogus met labels die door alle volgende pipelines wordt geërfd. Zonder deze classificatie eindigen pipelines onvermijdelijk met dataset-vervuiling: persoonsgegevens in een trainingsset waar ze niet horen, gevoelige documenten in een vector store zonder de juiste ACLs.
Pipelines voor batch én streaming
Klassieke ML-modellen worden meestal gevoed door batch-pipelines (dagelijks of uurlijks). LLM- en RAG-toepassingen vragen vaak streaming of incrementele updates: een nieuw beleidsdocument moet binnen uren in de vector store staan, een nieuwe transactie binnen seconden in het fraudemodel. Wij ontwerpen hybride architecturen — bijvoorbeeld op basis van Databricks of Snowflake voor analytische workloads, gecombineerd met streaming via Kafka of Pub/Sub voor real-time signalen. Elke pipeline heeft data quality gates: schemavalidatie, distributiechecks en outlier-detectie. Bij overschrijding van drempels wordt de pipeline gepauzeerd in plaats van vuile data door te laten.
Feature stores en document-pijplijnen
Voor klassieke ML implementeren we feature stores (Feast, Tecton of platform-native zoals in Databricks) waarin features eenmaal worden gedefinieerd en door alle modellen hergebruikt. Voor LLM- en RAG-toepassingen bouwen we het analoge: document-pijplijnen met geversioneerde chunking, embeddingsmodellen en metadata. Beide mechanismen leveren dezelfde winst: train-serve consistentie, hergebruik over teams en projecten heen, en een audit-spoor van waar elke feature of elke vector vandaan komt.
Lineage en governance ingebed in metadata
Lineage tracking — welke ruwe data, via welke transformatie, leidde tot welke feature, in welk model, in welke productie-output — is geen luxe maar een EU AI Act-vereiste voor hoog-risico systemen (artikel 10). Wij implementeren lineage op basis van OpenLineage of platform-native (Unity Catalog, Snowflake Horizon), met automatische capture van transformatiestappen. Elke kolom in elke tabel weet waar hij vandaan komt en wie hem mag zien. Dit maakt artikel 15-inzageverzoeken (GDPR) afhandelbaar in uren in plaats van weken.
Retention en de verwijderingsroute
Een GDPR-conforme dataplatform vereist dat een artikel 17-verwijderverzoek propageert door alle lagen: brontabellen, transformaties, feature stores, vector stores en zelfs trainingsdata-snapshots. Wij ontwerpen deze "right to be forgotten"-route expliciet en testen hem geautomatiseerd: een testgebruiker wordt aangemaakt, doorloopt de pipeline, wordt verwijderd, en het systeem verifieert dat geen spoor achterblijft. Retention-policies — typisch zeven jaar voor financieel, vijftien jaar voor medisch, korter voor marketing — zijn ingebakken in elke laag, met automatische verwijdering en logging. Geen handmatige opruim-acties die altijd vergeten worden.
