Data Architecture for AI

Part II begins at the lowest layer of the reference architecture of Chapter 4, the data foundation. This chapter explains why data products and data contracts are the unit of trust between data owners and model teams, how lineage makes a model's claims about its data verifiable, where feature stores and vector stores fit, why synthetic data has sharp limits, and how the GDPR, the Data Act, and the Data Governance Act shape what the architecture may do.

Data products for AI: source systems feed contracted data products, which feed feature stores, vector indexes and training sets, and then models, under a governance plane

Figure 6.1: Domain-owned data products publish contracted, documented data that AI consumers assemble into features, indexes, and training sets, while a governance plane records lawful basis, lineage and policy.

Why the data layer is the architecture

In classical systems the architect designs the behaviour and the data supports it. In an AI system the relationship inverts, because the behaviour is derived from the data. Kleppmann's distinction between systems of record and derived data frames this (77, Kleppmann, 2017): a trained model is a lossy, cached transformation of its training set that can be regenerated only if the inputs are known, versioned, and still available.

The quality, legality, and reproducibility of the model are therefore bounded by those of the data. The architectural response is to make data a product with an accountable owner, to make its interface a testable contract, and to record lineage and lawful basis when a dataset enters the AI estate rather than when a regulator asks. AI Governance, Chapter 5 names what its data readiness assessment looks for: named data owners, known quality and lineage, and a lawful basis for each purpose. This chapter describes the architecture that closes them.

Data products and the data mesh in large organisations

Four principles and what they mean for AI

Dehghani's data mesh rests on four principles: domain ownership of data, data as a product, a self-serve data platform, and federated computational governance (76, Dehghani, 2022). They matter for AI because a model team cannot own the data it trains on; that data comes from business processes the team does not control, so a domain owner must be accountable for its meaning, quality, and legal status. The self-serve platform keeps governance from fragmenting, and federated computational governance lets the platform enforce global rules, such as personal data classification, retention, and lawful basis, as policy as code while domains decide schema and quality thresholds. Data mesh arrived at policy as code from the data side and Architecture as Code from the architecture side (72, Nordqvist, 2025); they meet in the governance plane of Figure 6.1.

The data product descriptor

A data product that AI can consume needs a descriptor the platform can read, which the pipelines in Chapter 7 check before they train.

data_product:
  name: customer-events
  domain: retail
  owner: retail-data-team@example.org
  version: 2026.02
  outputs:
    - {name: events, format: parquet, contract: contracts/customer-events.yaml}
  classification:
    personal_data: true
    special_categories: false
    pseudonymised: true
  lawful_basis:
    operational_use: GDPR Article 6(1)(b) contract
    model_training: GDPR Article 6(1)(f) legitimate interest
    legitimate_interest_assessment: lia/customer-events-2025-11.md
  retention_days: 730
  datasheet: data/customer-events/datasheet.md
  lineage:
    sources: [web-tracking, app-tracking, order-service]

The lawful_basis block separates operational use from model training because the GDPR does. The datasheet link follows Gebru and colleagues, whose template asks why a dataset was created, what it contains, how it was collected, which uses are recommended and discouraged, and how it is maintained (42, Gebru et al., 2021).

Worked example: a datasheet excerpt

Illustrative example. The model card for the claims ranker in Nordvik Region's benefits-triage system (Chapter 5) points to data/claims-register/datasheet.md, excerpted below.

# Datasheet: claims register, version 2025-12 (Nordvik Region, illustrative)
Lawful basis: GDPR Article 6(1)(e); regional social assistance act

## Composition
- 1.9 million closed claims, January 2021 to November 2025.
- Removed: nationality, ethnicity, health details, fine-grained postcode, free text.

## Known gaps and skews
- Paper claims digitised before 2024 have incomplete completeness flags
  (about 7 per cent of rows).
- Claims from the two northern municipalities are under-represented
  (4 per cent of rows against 9 per cent of population).

## Uses
- Recommended: workload planning and queue ordering.
- Discouraged: any use that predicts the outcome of an individual claim.

## Maintenance
Monthly immutable, hashed release. Erasure requests are applied under rule RET-04.

The known gaps section is the one that changes model design: the northern under-representation becomes a slice in the fairness evaluation of Chapter 20, and the digitisation gap becomes a stated limitation in the model card, so the defect stays visible downstream.

Data contracts

A descriptor says what the product is; a data contract says what the consumer may rely on, in a form a test can check. The platform verifies the producer's schema, quality, and change-policy commitments on every publication, so that when the contract breaks the producer's pipeline fails, not the consumer's model. For AI consumers the contract adds two kinds of field: the distribution of numeric columns, because a model served on a different distribution has silently changed behaviour, and permitted purposes, because data collected under one lawful basis cannot be repurposed by the consumer.

contract:
  product: customer-events
  version: 3
  schema:
    - name: basket_value_eur
      type: decimal
      constraints: [not_null]
      distribution: {p50_range: [18.0, 32.0], p99_max: 2500.0}
  permitted_purposes: [personalisation-ranking, demand-forecasting]
  prohibited_purposes: [creditworthiness-assessment]
  change_policy:
    breaking_changes: new_major_version_with_90_day_overlap
  tests:
    - freshness_within_minutes: 90
    - distribution_drift_psi_max: 0.2

The prohibited_purposes entry is the data-side counterpart of the prohibited uses in an AI Decision Record from Chapter 5, so the pipeline can refuse a training job that combines a dataset with a purpose its owner never agreed to. The population stability index test catches input drift at publication, before it reaches production.

Worked example: a contract for a retrieval corpus

Illustrative example. A retrieval corpus needs a contract too, although its guarantees concern document metadata, entitlements, and freshness rather than distributions. Hansa Mutual's policy-wordings contract, which grounds the claims assistant of Chapter 5, requires every section to carry an entitlement and valid_from and valid_to dates, prohibits personal data, and lists model fine-tuning as a prohibited purpose because AIDR-0021 rejected it. The dates let the retriever return the wording that applied on the date of loss, which is the question a claims handler is actually asking.

Lineage and provenance

Lineage answers where a value came from; provenance answers how an artefact came to exist. A model card that claims training on dataset version 2025-12 is only a claim until the lineage graph shows the training job that read that version and produced that model. Hutchinson and colleagues argue that dataset development should borrow software engineering's requirements, design documents, tests, and maintenance plans (70, Hutchinson et al., 2021). The architectural implication is that the platform captures lineage rather than teams declaring it, so that "which models consumed this dataset version" can be answered when an erasure request arrives or a dataset turns out to lack a valid basis.

Lineage stops at the organisation's boundary, however. A licensed foundation model arrives with the provider's documentation and the public summary of training content that Article 53(1)(d) of the AI Act requires of every provider of a general-purpose AI model (1, European Union, 2024); AI Governance, Chapter 6 treats the assessment of model origin. Such a model becomes an external node in the lineage graph, so that its dependants can still be found when the provider announces a defect or a withdrawal.

Worked example: a retention and erasure rule

Illustrative example. Retention for AI data has to follow personal data into every derived store. Nordvik Region states the rule once, as code, and the platform applies it through lineage.

# policies/retention/RET-04.yaml - Nordvik Region (illustrative)
rule:
  id: RET-04
  title: Retention and erasure for claims data used in AI systems
  owner: data-protection-officer
  applies_to:
    data_products: [claims-register, claims-correspondence]
  retention:
    training_releases: 3 most recent releases, maximum 36 months
    feature_store_rows: 24 months
    vector_index_chunks: lifetime of the source document version
    prompt_and_response_logs: 12 months, minimum 6 months for high-risk systems
    semantic_cache_entries: 24 hours
  on_erasure_or_restriction:
    propagate_via: lineage://nordvik/claims
    actions:
      - {store: training_releases, action: exclude from next release}
      - {store: vector_index_chunks, action: delete and re-index within 72 hours}
      - {store: semantic_cache_entries, action: purge immediately}
      - {store: models, action: record affected versions and retrain at next cycle}
  evidence:
    test: synthetic erasure request executed quarterly end to end

The rule does not promise to delete a person from a trained model at once, because that is rarely technically possible; it records the affected model versions and removes the data at the next retraining, a position the DPO must document in line with the anonymity analysis of EDPB Opinion 28/2024 (17, EDPB, 2024). The quarterly synthetic request exists because a retention rule that has never been exercised is a statement of intent, not a control.

Feature stores and vector stores

Two specialised stores appear in most AI estates, and they are often confused because both hold derived representations of source data.

Aspect Feature store Vector store
Holds Engineered features keyed by entity and time Embedding vectors of content, with metadata
Primary consumer Training and serving of predictive models Retrieval for RAG, see Chapter 10
Typical failure Training-serving skew; leakage from the future Stale index; chunks that outlive their documents

A feature store addresses two problems of the kind Sculley and colleagues catalogued as hidden technical debt: the entanglement of input signals, and the pipeline jungles that grow up around data preparation (43, Sculley et al., 2015). Its defining capability is the point-in-time join, which keeps future information out of a training set. A vector store's problem is access control: a chunk is still its source document, so the index carries its sources' access attributes and the retriever filters on the caller's entitlements before similarity search. Both are rebuildable caches with lineage, never systems of record.

Synthetic data and its limits

Synthetic data fills gaps where real data is scarce, stands in for personal data in testing, and rebalances under-represented classes. However, Shumailov and colleagues demonstrated that indiscriminate training on data generated by earlier models causes irreversible defects, an effect they call model collapse (53, Shumailov et al., 2024): first the tails of the distribution disappear, so rare but valid cases vanish, and later the output converges on a point estimate with very small variance. Synthetic data is therefore labelled as such in lineage, its proportion is recorded in the datasheet and the model card, and its freedom from personal data is assessed by the data protection officer rather than assumed.

Personal data and lawful basis for training

The GDPR provisions that bind the design

The GDPR applies wherever personal data is processed, and training a model is processing (2, European Union, 2016). Four provisions shape the architecture. Among the principles of Article 5, purpose limitation is the one AI programmes break most often, because data collected to run a service is later used for training, which is a new purpose.

Under Article 6, a private organisation rarely stretches contract under Article 6(1)(b) to model training, so legitimate interest under Article 6(1)(f), with a documented balancing assessment, is the realistic basis. A public authority, by contrast, cannot use legitimate interest for processing in the performance of its tasks, under the final sentence of Article 6(1); it relies on public task under Article 6(1)(e), laid down in law, so its descriptor points to the authorising provision and a dataset without one cannot be used for training.

Article 9 prohibits processing of special categories, such as health and ethnicity, unless an Article 9(2) exception applies, so such columns are excluded by default and their proxies watched for in fairness evaluation, as AI Governance, Chapter 10 describes. Article 22 restricts decisions based solely on automated processing with legal or similarly significant effects; a system that ranks or drafts for a human decider is designed so that Article 22 is not engaged, with the oversight path of Chapter 5 as evidence.

EDPB Opinion 28/2024

Opinion 28/2024 of the European Data Protection Board, adopted in December 2024, addresses three questions (17, EDPB, 2024). A model is anonymous only, case by case, when the likelihood of extracting personal data from it is insignificant. Legitimate interest can be a lawful basis for developing and deploying a model, subject to the three-step test, with measures such as pseudonymisation and excluding data from training affecting the balance. The consequences of developing a model with unlawfully processed data depend on the circumstances. For the architect this fixes the evidence: anonymity claims need documented memorisation and extraction tests, legitimate interest claims need an assessment listing the measures actually implemented, and lineage from data to model is preserved.

The Data Act and the Data Governance Act as enablers

Two regulations open access to data and define how it may be shared. The Data Act gives users of connected products the right under Chapter II to access the data those products generate and share it with third parties (5, European Union, 2023), so machine data previously locked in a vendor's cloud becomes accessible training data; its Chapter VI on switching between data processing services bears on the sovereignty choices of Chapter 13. The Data Governance Act sets conditions in Chapter II for re-use of protected public-sector data, typically in secure processing environments, regulates neutral data intermediation services in Chapter III, and establishes data altruism in Chapter IV (6, European Union, 2022). Cross-boundary data sharing is thus becoming a regulated activity in which only contracted, documented, lineage-tracked data products can take part.

European data spaces

The Commission's 2020 strategy for data proposed common European data spaces in strategic sectors (12, European Commission, 2020), common data infrastructures and governance frameworks in which data holders control the data they generate (13, European Commission, n.d.). The European Health Data Space, Regulation (EU) 2025/327, provides for secondary use of electronic health data, including for training AI, through secure processing environments (11, European Union, 2025). Its pattern applies to any platform: the model goes to the data, not the data to the model.

Practical consideration: where to start

Do not turn the whole estate into data products before the first model goes live. Start from the use cases: datasets that feed a high-risk system or ground a widely used assistant become data products first, with an owner, descriptor, datasheet, and contract. Lineage capture is the exception, because it is cheap when the pipeline framework emits it from the start and expensive to reconstruct, so the platform enables it for every pipeline on the first day.

Across the usage modes

What data leaves the organisation, and which control governs it, differs sharply across the usage modes of Chapter 2 (usage-mode matrix).

Mode What leaves the organisation Data architecture control
Mode 0 – Ambient AI Whatever the feature processes, often unreviewed Contract change control; DPIA update
Mode 1 – Conversational assistants Everything a person pastes into the chat Enterprise tier without training use; data loss prevention
Mode 2 – Embedded workplace assistants Tenant content within the assistant's reach Residency settings, labels, permission clean-up
Mode 3 – Agentic work tools Code, configuration, anything the tool reads Repository scoping, secrets scanning, egress rules
Mode 4 – Built AI applications Only what the gateway forwards Data contracts, entitlement-filtered retrieval
Mode 5 – Autonomous production agents As Mode 4, plus tool results As Mode 4, with classification of tool output

Mode 2 turns existing permission debt into a data protection issue, because an embedded assistant reads whatever the user can read. Only in Modes 4 and 5 do the contracts and retention rules of this chapter apply in full.

Nordvik Region and Hansa Mutual

Nordvik Region's data questions are about lawful basis, minimisation and residents' rights. The claims register is processed under the public task of GDPR Article 6(1)(e), its known gaps shape the fairness evaluation, and RET-04 follows personal data into every derived store while respecting archives law (2, European Union, 2016). The provider trains inside Nordvik's platform, so applicants' data never leaves the authority.

Hansa Mutual's questions, by contrast, are about borders. The Polish service centre processes claims for the German, Dutch, Swedish and Norwegian entities, and the UK and Swiss entities use the group platform in Germany; transfers from the EU back to them rely on the Commission's adequacy decisions (243, European Commission, 2025), (245, European Commission, 2000), while transfers from them are governed by UK and Swiss law (248, UK Parliament, 2018), (244, Swiss Confederation, 2020). Because national rules on health data differ, Hansa's data products carry the jurisdiction of origin as metadata, so the lineage graph can show which market's data reached which model.

Summary

A trained model is derived data, bounded in quality, legality, and reproducibility by its data. The data architecture for AI therefore starts with domain-owned data products, readable descriptors, and honest datasheets; contracts make ownership testable, platform-captured lineage makes model cards verifiable, and synthetic data is useful but prone to model collapse. The GDPR binds the design through purpose limitation, lawful basis, special categories, and Article 22, more strictly for public authorities, and EDPB Opinion 28/2024 defines the evidence expected. The Data Act, the Data Governance Act, and the data spaces open data supply to organisations with contracted data products. Chapter 7 follows the data into the model lifecycle and its gates.

Sources

  1. Kleppmann, M. (2017). Designing Data-Intensive Applications. Sebastopol, CA: O'Reilly Media. ISBN 978-1-4493-7332-0. (77, Kleppmann, 2017)
  2. Dehghani, Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. Sebastopol, CA: O'Reilly Media. ISBN 978-1-4920-9239-1. (76, Dehghani, 2022)
  3. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1, published at aac.geon.se. (72, Nordqvist, 2025)
  4. Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H. & Crawford, K. (2021). Datasheets for Datasets. Communications of the ACM, 64(12), pp. 86–92. (42, Gebru et al., 2021)
  5. Hutchinson, B., Smart, A., Hanna, A., Denton, E., Greer, C., Kjartansson, O., Barnes, P. & Mitchell, M. (2021). Towards Accountability for Machine Learning Datasets: Practices from Software Engineering and Infrastructure. Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency (FAccT '21), pp. 560–575. (70, Hutchinson et al., 2021)
  6. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  7. European Data Protection Board. Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models. Adopted 17 December 2024. (17, EDPB, 2024)
  8. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F. & Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015). (43, Sculley et al., 2015)
  9. Shumailov, I., Shumaylov, Z., Zhao, Y., Papernot, N., Anderson, R. & Gal, Y. (2024). AI models collapse when trained on recursively generated data. Nature, 631, pp. 755–759. (53, Shumailov et al., 2024)
  10. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)
  11. European Parliament and Council of the European Union. Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act). Official Journal of the European Union, 22 December 2023. (5, European Union, 2023)
  12. European Parliament and Council of the European Union. Regulation (EU) 2022/868 on European data governance (Data Governance Act). Official Journal of the European Union, 3 June 2022. (6, European Union, 2022)
  13. European Commission. A European strategy for data. COM(2020) 66 final, 19 February 2020. (12, European Commission, 2020)
  14. European Commission. Common European Data Spaces. Shaping Europe's digital future policy pages. (13, European Commission, n.d.)
  15. European Parliament and Council of the European Union. Regulation (EU) 2025/327 on the European Health Data Space. Official Journal of the European Union, 5 March 2025. (11, European Union, 2025)
  16. European Commission (2025). Commission Implementing Decision (EU) 2025/2574 amending Implementing Decision (EU) 2021/1772 on the adequate protection of personal data by the United Kingdom. Official Journal of the European Union, 23 December 2025. (243, European Commission, 2025)
  17. European Commission (2000). Commission Decision 2000/518/EC on the adequate protection of personal data provided in Switzerland. Official Journal of the European Communities, L 215, 25 August 2000. (245, European Commission, 2000)
  18. United Kingdom (2018). Data Protection Act 2018 (c. 12), with the UK General Data Protection Regulation. (248, UK Parliament, 2018)
  19. Swiss Federal Assembly (2020). Federal Act of 25 September 2020 on Data Protection (Data Protection Act, FADP), SR 235.1. Fedlex, in force 1 September 2023. (244, Swiss Confederation, 2020)