AI voor Data Engineers

Introductie

Monitoring & Observeerbaarheid sloot af met een observatie: dezelfde anomaliedetectie die datawaarden en pipeline-metrics bewaakt, leunt inmiddels vaak op AI-modellen om patronen te herkennen die met vaste regels lastig te vangen zijn. Dat is één van meerdere plekken waar AI het vak van de data engineer raakt — en dit hoofdstuk brengt ze samen. Niet als losse hype-onderwerpen, maar als twee structureel verschillende rollen die AI in je werk kan spelen.

Twee Aparte Rollen: AI Als Gereedschap versus AI Als Onderdeel van het Platform

Het is de moeite waard deze twee rollen scherp te onderscheiden, omdat ze andere vaardigheden en andere risico's met zich meebrengen:

• AI als gereedschap: je gebruikt een AI-assistent (Claude Code, GitHub Copilot, ChatGPT) om zelf sneller en met minder fouten SQL, dbt-modellen of Python-pipelines te schrijven. De output is code die jij reviewt, test en beheert — het eindresultaat verandert niet fundamenteel van aard.
• AI als onderdeel van het platform: je bouwt en onderhoudt infrastructuur die zelf AI-systemen voedt of bevat — een feature store voor een ML-model, een ingestion-pipeline voor een RAG-systeem, een productiepipeline die een LLM aanroept als transformatiestap. Hier wordt AI een systeemcomponent met eigen operationele eisen: latency, kosten, evaluatie, monitoring.

De eerste rol is vandaag al mainstream; de tweede is waar het vak van de data engineer structureel verandert. De rest van dit hoofdstuk behandelt beide, met het zwaartepunt op de tweede — want de eerste rol is grotendeels een kwestie van gewoon beginnen.

AI-Assisted Development: Code Generation in de Praktijk

AI-codeassistenten zijn inmiddels goed genoeg om een aanzienlijk deel van boilerplate-werk over te nemen: een dbt-staging-model opzetten op basis van een brontabel-schema, een eerste SQL-query schrijven voor een nieuwe vraag, een Python-functie voor een bekend patroon zoals incrementele extractie.

# Prompt-patroon dat werkt: specifiek, met context, met expliciete constraints
prompt = """
Schrijf een dbt-staging-model voor de brontabel raw.orders met kolommen:
order_id (int), customer_id (int), order_ts (timestamp), amount_cents (int), status (varchar)

Eisen:
- Hernoem amount_cents naar amount_euros (deel door 100, cast naar decimal(10,2))
- Filter rijen waar status = 'test_data' eruit
- Gebruik {{ source('raw', 'orders') }}, geen hardcoded tabelnaam
- Voeg een dbt-test toe: order_id moet uniek en not-null zijn

Geef alleen de .sql en de bijbehorende schema.yml terug.
"""

Het cruciale verschil met AI als platformcomponent: hier blijft een mens in de loop vóórdat de code ooit productie raakt. De code review uit Git & Branch-strategieën en de CI-pipeline uit CI/CD for Data Engineering veranderen hierdoor niet — een AI-gegenereerd model doorloopt exact dezelfde pull request, dezelfde tests, dezelfde review als code die een mens vanaf nul typte. De valkuil is niet de generatie zelf, maar het overslaan van die stappen omdat de code er overtuigend uitziet.

Feature Stores: de Brug Tussen Data Engineering en ML

Zodra een organisatie machine learning-modellen in productie draait, ontstaat een probleem dat specifiek is voor ML-workloads: een model trainen op features die anders berekend worden dan de features die het model in productie te zien krijgt — training/serving skew. Als "gemiddelde orderwaarde van de laatste 30 dagen" in een trainingsnotebook anders wordt berekend dan in de realtime serving-laag (net iets andere tijdzone-afhandeling, een net iets ander afkappunt), presteert een model in productie structureel anders dan tijdens validatie, vaak zonder duidelijke foutmelding.

Een feature store lost dit op door featureberekening en -opslag te centraliseren: één definitie van een feature, hergebruikt voor zowel training (batch, historische data) als serving (realtime of near-realtime lookup).

# Feature-definitie in Feast — één bron van waarheid voor training én serving
from feast import Entity, FeatureView, Field
from feast.types import Float32
from datetime import timedelta

customer = Entity(name="customer_id")

customer_features = FeatureView(
    name="customer_order_features",
    entities=[customer],
    ttl=timedelta(days=30),
    schema=[
        Field(name="avg_order_value_30d", dtype=Float32),
        Field(name="order_count_30d", dtype=Float32),
    ],
    source=orders_batch_source,  # dezelfde bron voedt training én serving
)

Dit is voor een data engineer feitelijk een vertrouwd probleem in een nieuwe jas: dezelfde discipline als bij Data Vault of Medallion Architecture — één canonieke berekening, hergebruikt door meerdere consumers in plaats van los, inconsistent gedupliceerde logica. Het verschil is dat de twee consumers hier niet twee BI-dashboards zijn, maar een offline trainingsjob en een online serving-endpoint met een latency-eis van milliseconden.

De Data Engineer's Rol in de RAG-stack

Retrieval-Augmented Generation verdient een eigen, uitgebreide behandeling die buiten de scope van dit hoofdstuk valt — zie Generative AI voor Data Engineers voor de volledige architectuur: chunking, embeddings, vector databases en een vergelijking van pgvector, Pinecone, Weaviate, Snowflake Cortex Search en Databricks Vector Search. Kort samengevat voor de context van dit handbook: de ingestion-pipeline die een RAG-systeem voedt — documenten ophalen, chunken, embedden, opslaan — is functioneel een ETL/ELT-pipeline zoals elke andere in dit handbook, met een embeddingmodel en vector store als extra componenten in plaats van een traditioneel warehouse. Dezelfde principes uit ETL vs ELT en incrementele verwerking zijn hier onverkort van toepassing.

AI-Ondersteunde Datakwaliteit en Monitoring

Datakwaliteit & Testen introduceerde anomaliedetectie als alternatief voor vaste regels; AI-modellen zijn waar die anomaliedetectie in de praktijk vandaan komt. Twee concrete toepassingen die verder gaan dan alleen afwijkingen signaleren:

• Natuurlijke-taalverklaringen bij afwijkingen: in plaats van alleen "kolom X wijkt 3 standaarddeviaties af", een LLM laten samenvatten wélke rijen het patroon veroorzaken en of dat overeenkomt met een bekend seizoenspatroon — sneller te interpreteren voor wie niet de hele dag in de data zit.
• Testassertie-generatie: een LLM een schema.yml laten voorstellen op basis van een steekproef van de data, inclusief plausibele not_null- en accepted_values-tests — een startpunt, geen vervanging voor het testdekking-denken uit Datakwaliteit & Testen.

De valkuil is dezelfde als bij code generation: een AI-voorgestelde test of verklaring is een hypothese, geen waarheid. Behandel de output als een eerste concept dat een engineer beoordeelt, niet als een autoriteit die tests automatisch goedkeurt.

Governance en Kosten van AI-gebruik

AI-gebruik in een pipeline introduceert twee risico's die al eerder in dit handbook zijn behandeld, nu toegepast op een nieuw type component:

Data leakage via prompts. Een prompt die productiedata naar een externe LLM-API stuurt, is functioneel een dataflow naar een derde partij — precies het scenario dat de classificatie uit Data Governance zou moeten vlaggen. Restricted-geclassificeerde data hoort niet ongemaskeerd in een prompt naar een externe API, ongeacht hoe nuttig het antwoord zou zijn; combineer waar nodig met de maskerings- en tokenisatietechnieken uit Databeveiliging vóórdat data een prompt in gaat.

Kosten als doorlopend signaal, niet als jaarrekening-verrassing. LLM- en embedding-API's rekenen per token, en een pipeline die bij elke run de volledige dataset opnieuw naar een AI-model stuurt in plaats van alleen gewijzigde records, herhaalt exact de fout van een volledige herberekening in plaats van incrementele verwerking. Monitor AI-gerelateerde kosten per pipeline, net zoals Monitoring & Observeerbaarheid aanraadt voor compute-kosten in het algemeen — een sluipende kostenstijging is met AI-API's makkelijker te missen dan met warehouse-compute, omdat de kosten buiten je eigen platform vallen en dus buiten je gebruikelijke kostendashboards.

AI-Agents in Pipelines: Waar de Grens Ligt

Een recentere ontwikkeling gaat verder dan code generation met een mens in de loop: AI-agents die zelfstandig meerdere stappen uitvoeren — een foutmelding lezen, een oorzaak diagnosticeren, een fix voorstellen én toepassen, zonder dat een mens elke tussenstap goedkeurt. Voor data engineering duikt dit concreet op als "self-healing pipelines": een agent die een gefaalde run detecteert, de logs analyseert (vergelijkbaar met het runbook-proces uit Monitoring & Observeerbaarheid) en automatisch een herstelactie onderneemt, zoals een taak herstarten met aangepaste parameters.

Dit is aantrekkelijk voor bekende, goed-begrepen faalmodi — een tijdelijke netwerktimeout herstarten heeft weinig risico. Het wordt riskant zodra een agent de bevoegdheid krijgt om schema's, transformatielogica of toegangsrechten aan te passen zonder menselijke review: dat is precies het type wijziging waarvoor CI/CD for Data Engineering een pull-request-proces met verplichte review bepleit, en een autonome agent die dat proces omzeilt — hoe goedbedoeld ook — ondermijnt dezelfde waarborgen. De praktische vuistregel: laat agents autonoom handelen binnen een smal, vooraf gedefinieerd mandaat (herstart, retry, schalen), en houd elke wijziging die code, schema of rechten raakt binnen hetzelfde reviewproces dat voor menselijke wijzigingen geldt.

Best Practices

• Behandel AI-gegenereerde code identiek aan menselijk geschreven code — dezelfde review, dezelfde tests, dezelfde CI-pipeline, geen uitzondering omdat de code "al gegenereerd correct oogt".
• Centraliseer featureberekening in een feature store zodra een model in productie draait, om training/serving skew structureel te voorkomen in plaats van per model te riskeren.
• Classificeer data vóór het een prompt in gaat, niet erna — een prompt die restricted data naar een externe API stuurt, is niet meer terug te draaien zodra die verstuurd is.
• Monitor AI-API-kosten per pipeline als doorlopend signaal, niet pas zichtbaar bij de maandfactuur.
• Gebruik AI-voorgestelde tests en verklaringen als startpunt, beoordeeld door een engineer — nooit als autoriteit die automatisch wordt overgenomen.

Veelgemaakte Fouten

• AI-gegenereerde SQL of Python direct naar productie pushen zonder de gebruikelijke code review, omdat het "toch door AI is nagekeken".
• Features los per model herberekenen in plaats van via een gedeelde feature store, wat training/serving skew onvermijdelijk maakt zodra de twee berekeningen uit elkaar groeien.
• Ongemaskeerde productiedata in prompts naar externe API's sturen, zonder de classificatie- en maskeringsstappen die voor elke andere externe dataflow al gelden.
• De volledige dataset bij elke run opnieuw naar een AI-model sturen in plaats van incrementeel alleen gewijzigde records te verwerken, met onnodig oplopende kosten als gevolg.
• AI-voorgestelde datakwaliteitstests blind overnemen zonder te beoordelen of ze daadwerkelijk de juiste businessregels vastleggen.

Performance Tips

• Cache AI-gegenereerde resultaten voor ongewijzigde input — een herhaalde aanroep met dezelfde prompt en data hoeft niet opnieuw langs een externe API, net zoals embeddings van ongewijzigde chunks niet herberekend hoeven worden.
• Batch prompts waar mogelijk in plaats van één API-aanroep per rij — de meeste providers zijn aanzienlijk goedkoper en sneller per eenheid bij batchverwerking.
• Houd feature store-lookups laag-latency door serving-features in een key-value store te houden (Redis, DynamoDB) in plaats van rechtstreeks op het warehouse te bevragen, dat niet ontworpen is voor milliseconden-latency op enkele rijen.
• Stel een tokenbudget per pipeline-run in zodat een onverwachte lus of retry-storm niet ongemerkt een veelvoud van de verwachte API-kosten veroorzaakt.

Interviewvragen

"Wat is het verschil tussen AI als gereedschap en AI als onderdeel van het platform?" Let op: als gereedschap genereert AI code die een engineer reviewt en beheert — het eindresultaat blijft gewone, door mensen gecontroleerde infrastructuur; als platformcomponent wordt AI zelf een systeemonderdeel met eigen eisen aan latency, kosten en evaluatie.

"Wat is training/serving skew, en hoe voorkomt een feature store dat?" Let op: het ontstaat wanneer een feature anders wordt berekend tijdens training dan tijdens serving, wat een model in productie structureel anders laat presteren dan tijdens validatie; een feature store centraliseert de berekening zodat beide dezelfde definitie gebruiken.

"Waarom is een ingestion-pipeline voor een RAG-systeem in de kern hetzelfde als een gewone ETL-pipeline?" Let op: beide halen data op, transformeren die (chunken/embedden versus traditionele transformaties) en slaan het resultaat op in een doorzoekbare vorm — dezelfde incrementele-verwerkingsprincipes uit ETL vs ELT zijn onverkort van toepassing.

"Welk governance-risico ontstaat er specifiek wanneer data in een prompt naar een externe LLM-API gaat?" Let op: dit is functioneel een dataflow naar een derde partij; restricted-geclassificeerde data hoort daar niet ongemaskeerd in terecht te komen, net als bij elke andere externe dataflow.

"Waarom zou je AI-gegenereerde code niet anders behandelen dan menselijk geschreven code in je CI/CD-proces?" Let op: overtuigend ogende code is niet hetzelfde als correcte code; dezelfde review, tests en pipeline-stappen blijven nodig omdat de risico's (bugs, edge cases, security-issues) niet verdwijnen alleen omdat de code sneller is gegenereerd.

Relevante Documentatie

• Feast: Feature Store Overview — open-source feature store, referentie-implementatie voor de concepten in dit hoofdstuk.
• Databricks Feature Store — platform-native feature store, geïntegreerd met Delta Lake.
• Generative AI voor Data Engineers — de volledige RAG-architectuur, vector database-vergelijking en synthetic data generation.
• Wat is een LLM? — de basis van de modellen die dit hoofdstuk als gegeven aanneemt.

Samenvatting

AI raakt het vak van de data engineer op twee structureel verschillende manieren: als gereedschap dat dezelfde review- en CI-disciplines blijft vereisen als menselijk geschreven code, en als platformcomponent — feature stores, RAG-ingestion — met eigen eisen aan latency, kosten en evaluatie die bovenop de bestaande data engineering-fundamenten komen, niet in plaats daarvan. Governance en kostenbewaking van AI-gebruik zijn geen nieuwe disciplines, maar bestaande principes (classificatie, incrementele verwerking, kostenmonitoring) toegepast op een nieuw type dataflow. Met de technische kant van het vak nu compleet behandeld, verschuift de aandacht in het volgende hoofdstuk van wát je bouwt naar hoe je er daadwerkelijk data engineer voor wordt: Data Engineer Worden.