Data lineage

AI systems are only as trustworthy as the data behind them — and much of what goes wrong (bias, privacy violations, silent failure) originates in data, not the model. Data governance is AI governance's inseparable other half. For a governance leader, three data questions dominate: where did it come from, is it fit and fair, and are we allowed to use it this way?

Provenance & lineage

Lineage is the documented answer to 'where did this data come from and how did it get here?' — from source, through every transformation, to the model. It matters for governance because obligations flow backward through it: if a model shows bias, lineage points to the source dataset that caused it; if a customer exercises deletion rights, lineage finds every place their data landed (including derived embeddings and any fine-tune). Without lineage, these questions are unanswerable, and 'we don't know what data trained this' is not a defense a regulator accepts.

• Provenance — the origin and rights of every dataset: was it collected with consent, licensed, purchased, scraped? Each carries different obligations and risks (scraped data may carry copyright and privacy liabilities).
• Transformation lineage — how raw data became training or retrieval data. A bias introduced in a filtering step is invisible without it.
• Derived-data reach — embeddings, fine-tunes, and caches are derived personal data; deletion and retention obligations reach them too. This is the subtlety most programs miss.

Quality & bias at the source

• Representativeness — does the data reflect the population the system will affect? An HR tool trained on a historically skewed workforce learns the skew. The EU AI Act's data-governance obligation for high-risk systems is precisely this: examine training data for bias.
• Quality — accuracy, completeness, freshness. Bad data silently degrades every downstream decision (the exact problem Edova's Vigil monitors for — data observability is a governance control, not just an engineering one).
• Documentation — 'datasheets' for datasets: what's in it, how it was collected, known limitations. The record an auditor and a future team both need.

Privacy, consent & retention

Personal data in AI intersects GDPR/CCPA directly: a lawful basis for processing, purpose limitation (data collected for X can't freely train Y), data-subject rights (access, deletion, objection to automated decisions), and retention limits. The security course's redaction and minimization work is the technical control; here it's a legal obligation your governance program must ensure is met — and must be able to prove was met. Edova's Meld — which resolves customer identity, working directly with personal data (the reason its access model is read-only) — is the productized form of taking this seriously.