Layer 02 · AI governance
Data Foundation for AI
A model is only as trustworthy as the data beneath it.
Every model inherits the strengths, gaps, and biases of the data it was trained and prompted on, yet data is the layer most often taken on trust. This layer makes the data behind every AI system traceable, representative, and fit for use.
Live lineage
Data you can trace from source to decision
Every model runs on data. This layer maps where each dataset comes from, how it is transformed, and whether it is fresh, accurate and fit to decide with, catching bad data before it ever reaches a model.
*Illustrative figures for a representative estate.
01 · Where it begins
AI Data Foundation Challenges
Trustworthy AI starts with trustworthy data. Five questions decide whether your data foundation is solid or subtly compromised. Each points to a control in this layer.
02 · The controls, explained
The five controls that make data trustworthy
Each control is a distinct capability with a clear definition, a working mechanism, where the field is heading, and the consequence of skipping it. Together they turn data from a liability into an asset the rest of the stack can rely on.
Source tracking
Knowing where every dataset came from, before it reaches a model.
Definition
The practice of recording where every training and inference dataset originates, so provenance is established before data is ever used by a model: including who owns it, how it may be used, and whether it contains personal information. This data provenance tracking is what makes the rest of the layer possible.
How it works
At intake, each dataset is logged with its origin, licence terms, and a personal-data assessment. Sensitive or real-user data triggers a mandatory halt until legal sign-off is recorded. Provenance and permission are settled up front, not discovered in an audit.
How we help
We put an intake process around your data: a provenance record for every source, licensing and personal-data checks at the door, and a logged approval gate that keeps unvetted data out of training and prompting.
Without it
Models are trained on data no one can account for: unlicensed, personal, or poisoned. When a rights-holder or regulator asks where a dataset came from, there is no answer, and the model built on it is suddenly in question.
Latest regulatory news
2025Provenance moves to the front of the pipeline. As copyright and privacy scrutiny of training data intensifies, leading teams treat a logged provenance and licensing decision as a gate every dataset must pass before use, not a record reconstructed afterwards.
Lineage mapping
Tracing data from raw source to model input.
Definition
The practice of tracing how data flows and transforms from its raw source through to model input, so every downstream dependency is visible and every output can be traced back to the data that shaped it.
How it works
Each dataset and derived asset carries provenance metadata: a stable identifier, a hash back to its seed source, the transformation or generation method, modality tags, and a rationale. That metadata makes it possible to answer, for any model input, exactly where it came from and what was done to it.
How we help
We design a provenance metadata schema and wire lineage capture into your pipeline, so a change to a source, a licence, or a transformation can be traced to every model that depends on it. That is the difference between a targeted fix and a full re-training.
Without it
When a source turns out to be flawed, biased, or improperly licensed, no one can tell which models it touched. A single bad dataset becomes an untraceable, organisation-wide problem instead of a contained one.
Latest regulatory news
2025–26Lineage becomes a regulatory expectation. Data-governance duties for high-risk AI, including Articles 10 and 11 of the EU AI Act, increasingly assume you can show the path from raw data to model. That makes lineage metadata a compliance artefact, not just an engineering convenience.
Quality validation
Catching data errors at the source, not in production.
Definition
The practice of checking datasets for completeness, accuracy, and consistency before they are used, so errors are caught at the source rather than surfacing as unexplained model behaviour later.
How it works
Datasets are tested against explicit quality dimensions: missing values, format and schema conformance, duplicates, label accuracy, and internal consistency, with thresholds set before data is admitted. Failing data is quarantined and remediated rather than silently folded into a model.
How we help
We define the quality dimensions that matter for your use case, build automated validation into the pipeline, and set the thresholds and quarantine rules that stop bad data reaching a model in the first place.
Without it
Errors compound silently. A model learns from mislabelled or inconsistent data and behaves unpredictably, and the root cause, a quality problem upstream, is nearly impossible to diagnose from the output alone.
Latest regulatory news
2025Standardised data-quality measures arrive. Dedicated data-quality standards for machine learning, such as the ISO/IEC 5259 series for data quality in analytics and machine learning, help organizations assess and improve dataset quality, turning “the data looks fine” into a measurable, auditable claim.
Freshness monitoring
Flagging stale inputs before they degrade the model.
Definition
The practice of tracking how current each data source is and flagging inputs that have gone stale, catching the slow decay that steadily erodes model performance as the world moves on but the data does not.
How it works
Each source is given an expected refresh cadence and a freshness threshold. Monitoring watches the age of incoming data against that expectation and raises an alert when a source falls behind, before the model’s answers start drifting away from reality.
How we help
We map your sources to refresh expectations, instrument freshness checks, and set alerts tied to the systems that depend on each source, so a stale feed becomes a ticket, not an incident.
Without it
Models keep answering confidently from data that no longer reflects reality: prices, policies, or facts that have changed. The failure is invisible until a user or regulator notices the model is simply out of date.
Latest regulatory news
2025–26Freshness joins drift monitoring. As retrieval-augmented systems blur the line between data and model, freshness of the underlying sources is increasingly monitored alongside model drift as a single continuous-assurance signal. For example, a support chatbot pulling from an outdated policy document can look identical to a healthy system on every model-level metric, while it keeps citing a rule that changed last quarter, unnoticed. That is why leading teams now track source freshness on the same dashboard as drift.
Data bias screening
Testing whether the data represents the people the model affects.
Definition
The practice of testing datasets for skew and under-representation that would translate into unfair or unreliable model behaviour: the upstream complement to the outcome-level fairness testing in Layer 4.
How it works
Representativeness is judged against this product’s actual user base, not global balance. Statistical clustering reveals whether the data separates cleanly by demographic group and whether group proportions match the real world; persona coverage validates the finding by measuring what share of the data matches each user profile. Under-represented groups are then augmented or acquired.
How we help
We benchmark your datasets against the population the model will serve, quantify under-representation with clustering and persona coverage, and give you a targeted plan to close the gaps before bias is baked into a trained model.
Without it
A model works better for some users than others by design, because the data taught it to. The gap surfaces downstream as discrimination claims and failed fairness tests, far more expensive to fix once the model is trained.
Latest regulatory news
2025Bias screening shifts left. Rather than discovering skew only in model outputs, mature teams screen datasets for representativeness before training. That is the cheapest and most effective point to catch bias in the whole lifecycle.
Data quality profile
The six dimensions of trustworthy data
The same dataset scored across six quality dimensions, before and after a T3 data-foundation engagement.
03 · A practical reference
The dimensions of data quality
“Good data” is not one property but several. A credible validation regime names each dimension, what it catches, and how it is measured.
| Dimension | What it catches | Typical measure |
|---|---|---|
| Completeness | Missing values and gaps in coverage | % populated |
| Accuracy | Wrong or mislabelled values | error / label-accuracy rate |
| Consistency | Contradictions within and across sources | conflict count |
| Timeliness | Stale data past its refresh window | age vs threshold |
| Representativeness | Skew against the real user base | group proportion vs target |
| Provenance | Unknown origin or licence | % with logged source |
Prompt governance is not data governance. Cleaning, labelling, and quality-checking the prompts and evaluation sets used to test a model is a distinct discipline from governing the underlying training data. Both need provenance, versioning, and quality control, and a “golden dataset” of evaluation prompts should be expanded with cheap deterministic methods first, model generation second, and pruned in regular coverage audits.
03b · Standards mapping
Where each control satisfies a recognised obligation
Data governance is one of the most heavily specified parts of AI regulation. Each control maps to the references your auditors already use.
| Control | EU AI Act | NIST AI RMF | ISO / other |
|---|---|---|---|
| Source tracking | Art. 10(2)–(3) | Map 3 | ISO/IEC 42001 §7.5 |
| Lineage mapping | Art. 10 · 11 | Map 4 | ISO/IEC 5259 |
| Quality validation | Art. 10(3)–(4) | Measure 2 | ISO/IEC 5259 |
| Freshness monitoring | Art. 10 · 72 | Manage 4 | ISO/IEC 42001 §9 |
| Data bias screening | Art. 10(2)(f–g) | Measure 2.11 | ISO/IEC TR 24027 |
| Source | eur-lex.europa.eu → | nist.gov → | iso.org → |
04 · What a credible data foundation includes
The data checklist
A defensible data foundation covers the following, whether you build it in-house or with us.
- Provenance for every source. Origin, licence, and personal-data status logged before use, with a sign-off gate for sensitive data.
- End-to-end lineage. Any model input can be traced back to its raw source and every transformation in between.
- Quality thresholds. Explicit completeness, accuracy, and consistency bars that data must clear to be admitted.
- Freshness expectations. A refresh cadence and staleness alert for each source.
- Representativeness evidence. The data is measured against the real user base, not assumed to be balanced.
- Separate prompt governance. Evaluation prompts and golden datasets are versioned, provenance-tagged, and coverage-audited in their own right.
Privacy by design is cheaper than privacy by lawsuit.
Every model runs on data that someone has to stand behind: its provenance, its permission to be used, its freshness, and whether it represents the people it will affect. Bias enters at the dataset long before it ever shows up in a decision.
T3 AI risk white paper
Failure modes
How a data foundation fails
The gaps that surface once a model reaches production.
Untraceable training data
No provenance or permission record, so you cannot prove you were allowed to use it.
Fix · Source tracking with a permission and collection-date trail.Representative of no one
The data’s demographic mix is never checked against the real user base.
Fix · Statistical clustering, using whichever technique fits the dataset and use case, plus persona coverage, mapped against real-world demographics.“Trust me, no PII”
Memorisation is asserted, never tested.
Fix · Canary probes and membership-inference tests that gate release.Set-and-forget freshness
Static data drifts out of date unnoticed.
Fix · Freshness monitoring with real-time versus static SLAs.Go deeper
How the hard parts are actually done
The methods behind three of this layer’s controls.
TechniqueTesting data fairness+
Automated statistical clustering, with the technique chosen to fit the dataset and use case rather than defaulting to any one method, reveals whether the data separates into groups by gender or use case; that mix is then mapped against real-world demographics. Manual persona building (for example, every skin tone in a camera dataset) checks what share of the data meets each persona.
Under-represented? Acquire or synthesise more. A tailored “agile” safety classifier can be stood up from as few as 80 examples, in about a day. (Based on T3 internal project experience and internal benchmarking.)
TechniqueProving you didn’t train on PII+
Rather than asserting “we didn’t train on personal data”, a defined harness runs canary probes and membership-inference (MIA) against a severity taxonomy, with thresholds that gate release.
ChecklistThe five questions we put back to you+
- Source: do you have permission and provenance?
- Lineage: history, collection date, validation?
- Quality: clean and correctly labelled?
- Freshness: how old; real-time or static?
- Bias: representative of the actual user base?
05 · In practice
Real-world scenarios
Data foundation is not abstract. Each scenario shows a genuine challenge, the controls that addressed it, and the outcome, anonymised across regulated industries.
Challenge
A global insurer could not evidence the provenance or licensing of the third-party datasets behind a pricing model, days before a regulatory audit.
Controls applied
Source trackingLineage
Outcome
A provenance record and lineage map were reconstructed for every input, exposing two sources with unclear licensing that were replaced before the audit rather than discovered during it.
Key learning
Provenance you cannot produce on demand is provenance you do not have. Capturing it at intake would have turned a fire drill into a one-click export.
Challenge
A digital-health provider suspected its triage model underperformed for older patients but had no way to test whether its data represented them.
Controls applied
Bias screeningQuality validation
Outcome
Clustering and persona coverage confirmed a significant under-representation of older patients; targeted data acquisition closed the gap before the next model version shipped.
Key learning
Representativeness is measured against the real patient population, not a generic balance. Screening the data was far cheaper than remediating a biased model after launch.
Challenge
A retailer’s recommendation engine gradually degraded over a season as a key product feed fell behind, with no one aware until conversion dropped.
Controls applied
FreshnessLineage
Outcome
Freshness monitoring on every source, tied to the systems that depend on them, turned a silent seasonal decline into an alert the day a feed slipped, caught in hours, not months.
Key learning
Model quality can erode without any change to the model at all. Monitoring the freshness of the data is as important as monitoring the model.
Challenge
An AI-native firm’s test prompts had grown ad hoc, with no provenance or version control, so no two evaluations were truly comparable.
Controls applied
Source trackingLineageQuality validation
Outcome
A governed golden dataset, versioned, provenance-tagged, and coverage-audited, made evaluations reproducible and let the team expand coverage deliberately rather than randomly.
Key learning
Prompt governance deserves the same rigour as data governance. Without it, model assurance in Layer 4 is measuring against a moving target.
Disclaimer: illustrative use cases based on anonymised real-world scenarios.
06 · Questions leaders ask
Data foundation Q&A
Continue through the stack
Related layers
The inventory defines which systems need a trustworthy data foundation in the first place.
L03 · keeps this safeSecurity & access →Provenance and quality controls only hold if the data itself is secured against tampering and unauthorised access.
L04 · where this feedsModel testing & assurance →Quality, lineage, and representativeness evidence is the baseline every model evaluation builds on.
Next step
How solid is the data beneath your models?
Book a data-foundation review: a structured session that benchmarks your data provenance, quality, and representativeness against the five controls in this layer and pinpoints where a weak foundation is silently undermining everything above it. You keep the findings either way.
Book a review →Why T3
Why T3 for Data Foundation for AI?
T3 is an award-winning AI implementation partner for high-risk industries.
We support the adoption of trustworthy AI models across the entire lifecycle. We design and engineer bespoke data and AI controls, validate the provenance, lineage, and quality of the data behind every model, and implement end-to-end AI governance operating models, aligned to standards we helped write such as the EU AI Act, ISO/IEC 42001, and NIST AI RMF.
Where off-the-shelf GRC platforms stop, we build the custom controls, integrations, and assurance that fit your stack, your models, and your regulator.
Trusted by two-thirds of BigTech and Financial Services, this is where policy meets engineering.
