Designing an AI-Ready Enterprise Data Architecture

Five key takeaways

1. AI-ready data is governed data with usable context, not simply data in a new platform.
2. A data product needs an owner, contract, quality evidence, lifecycle and supported interface.
3. Warehouses, lakehouses, streams, document repositories, semantic layers, vectors and graphs are complementary.
4. Retrieval must enforce the same permissions as the source; embeddings are not a security bypass.
5. Start with a valuable, bounded use case and use its gaps to drive a reusable modernisation backlog.

Introduction

Most organisations already have more data than they can reliably use. Transaction systems contain customers, orders, assets and financial events. Warehouses support reporting. File shares and content systems hold procedures, contracts, drawings, policies and correspondence. Streaming platforms carry events from applications, machines and devices.

The difficulty is that this information is fragmented, inconsistently defined, poorly documented and governed by permissions that do not follow the data when it is copied. AI magnifies those weaknesses. A report may be inconveniently wrong; an automated agent can repeat the error at speed, disclose information to the wrong person or take an action that cannot easily be reversed.

It is a socio-technical system of data services, definitions, owners, policy controls, identity, operations and evidence. NIST’s AI Risk Management Framework 1.0 describes trustworthy AI through properties including validity, security, accountability, explainability, privacy and fairness. ISO/IEC 42001 structures AI management, while ISO/IEC 27001 provides the information-security baseline. The data architecture is where many of those properties must be implemented.

The design question is not “Which AI database should we buy?” It is:

Can we provide the right data, with the right meaning and evidence, to the right consumer, for the right purpose, under the right policy, and prove what happened afterwards?

Business context and problem definition

Enterprise data estates often grow through local optimisation. Business units select systems for immediate needs, add integrations when projects require them and create extracts or spreadsheets for reporting. A data lake is later introduced to retain raw information, while a document repository becomes a broad knowledge base. The result is a collection of individually useful assets that are collectively hard to understand.

Typical symptoms are conflicting customer or asset identifiers, competing definitions of measures, reports with unclear lineage, documents without owners or review dates, sensitive information copied into uncontrolled extracts, pipelines that fail silently after schema changes, and AI pilots that manually upload production documents.

These are business problems before they are AI problems. Poor data slows decisions, duplicates work, weakens compliance evidence and increases operational cost. AI adds retrieval errors, stale evidence, data poisoning, prompt injection, unsupported answers and unsafe tool calls.

The business case should combine better decisions, better operations and safer automation. The target is fitness for purpose, not perfect data everywhere.

Core concepts and terminology

Structured data, unstructured content and enterprise knowledge

Structured data follows a defined schema—typed fields, keys, constraints and relationships—and is suited to SQL, aggregation and deterministic rules. Unstructured content includes documents, email, images, scans, audio and free text. It is not necessarily without structure: a contract has parties and obligations, while a procedure has steps and conditions; those structures simply may not be explicit in the storage format.

An embedding is a numerical representation generated by a machine-learning model. It places text, images or other items in a vector space where distance approximates similarity. An embedding is a retrieval aid, not the authoritative source, business meaning or permission model. It may be stale, model-dependent and difficult to interpret.

Semantic search retrieves by meaning rather than exact keywords. Enterprise search should usually be hybrid: use lexical search for identifiers, names and exact terms, and vector similarity for paraphrases and related concepts. Metadata and access filters must constrain the candidate set.

Enterprise knowledge is the combination of governed facts, documents, definitions, relationships, rules, decisions, provenance and access context that an organisation is willing to make usable for a purpose. A folder of files is not automatically knowledge.

Data products, platforms and semantic services

A data product is a reusable data capability offered with a product mindset. It has a purpose, owner, documentation, interface, quality expectations, lifecycle, support path and access rules. It may expose a table, API, stream, document collection, semantic model or combination.

A data contract states what producers and consumers expect about schema, semantics, quality, freshness, compatibility, security and terms of use. It should make schema changes and quality failures explicit and testable. The Open Data Product Standard v1.0 is an emerging reference; the principle of discoverable, supported and governed products matters more than the chosen specification.

Service	Primary use	AI-readiness contribution	Main caution
Operational data store	Current, controlled read model	Gives applications a safe view of operational state	Do not overload transaction systems or hide ownership problems
Warehouse	Curated structured history and metrics	Reliable SQL, reporting and semantic measures	Less suited to raw multimodal content
Lake or lakehouse	Scalable raw and refined data	Preserves source fidelity for analytics and AI	Without metadata and lifecycle controls it becomes a swamp
Streaming platform	Publish and process events	Fresh features, monitoring and event-driven triggers	Needs event contracts, replay and failure handling
Document repository	Authoritative files, records and versions	Source content for search and RAG	Do not discard ACLs, versions or retention metadata
Semantic layer	Business entities, measures and calculations	Gives humans and AI a consistent vocabulary	Requires accountable metric owners
Vector index/database	Similarity retrieval	Supports semantic and multimodal search	Must retain source identity, ACLs and deletion semantics
Knowledge graph	Explicit entities and relationships	Enables multi-hop questions, impact analysis and reasoning	High modelling and maintenance cost

Lakehouse implementations commonly use open table formats such as Apache Iceberg, whose documented capabilities include schema evolution and snapshots. Those features improve reproducibility; they do not create business definitions or access policies. Similarly, Apache Kafka provides event-streaming capabilities, but each domain still needs event definitions and controls for sensitive fields.

Metadata, lineage, semantics and ontologies

Metadata describes an asset’s name, definition, owner, source, schema, classification, quality, freshness, retention, location, cost and permitted use. ISO/IEC 11179-1:2023 provides a foundation for metadata registries, and W3C DCAT 3 provides an interoperable vocabulary for dataset catalogues.

Lineage records where data came from, how it was transformed, which assets consume it and which version was used. For AI it should include dataset, field or document provenance and the chain from source document to passage, embedding, prompt and answer. W3C PROV-O and OpenLineage are useful reference points.

A semantic layer translates physical structures into business concepts—for example, defining “active customer” or “on-time delivery” consistently. An ontology is a more formal model of concepts, properties, relationships and constraints. RDF, OWL 2 and SPARQL are mature standards for representing and querying such relationships. Use them when a bounded domain has stable vocabulary and relationship-centric questions, not because AI requires an ontology by default.

Architecture principles

1. Design for purpose. Start with a business decision or process, its required facts, latency, uncertainty and decision authority.
2. Treat data as a product. Assign business ownership, a contract, quality rules, versioning, support and a lifecycle.
3. Preserve context. Keep source IDs, document versions, timestamps, jurisdiction, status and access metadata with derived assets.
4. Separate data from instructions. Retrieved content is untrusted data. The application, policy layer and tool gateway enforce permissions.
5. Secure the whole data path. Controls must follow ingestion, transformation, retrieval, prompts, outputs, caches, logs and deletion.
6. Use the simplest suitable store. A relational database and hybrid search may be enough; add graphs or standalone vectors only when a measured requirement justifies them.
7. Make freshness and uncertainty explicit. Declare update time, limitations and abstention behaviour.
8. Operate data and AI together. Pipelines, indexes, models, prompts, evaluation sets and agent tools form one production system.

What makes data genuinely AI-ready?

AI-ready data has sufficient evidence and control for its intended purpose. A practical minimum includes:

Capability	Evidence
Purpose and ownership	Use case, risk tier, named business owner, steward and escalation path
Discoverability and meaning	Catalogue entry, glossary, examples, semantic definitions and identifier mappings
Quality and provenance	Automated checks, thresholds, freshness, source, transformations, version and limitations
Security and privacy	Classification, purpose, rights, residency, policy tags and identity-aware access
Technical usability	Stable table/API/stream/repository interface, contract, latency and availability
Lifecycle and operations	Retention, deletion, reprocessing, monitoring, alerts, runbooks and support

Assess readiness per product and use case. The same source may produce different products with different quality, freshness and access requirements.

Detailed reference architecture

The architecture is intentionally not “user to model”. Users reach an application that authenticates requests and invokes approved retrieval or business tools through orchestration. Governed data services return only authorised information. IAM and policy services provide the decision context; observability records what happened; infrastructure supplies compute, storage, network, keys and resilience.

Component responsibilities

• Users and channels pass identity, tenant or business-unit context, purpose and correlation ID.
• Business applications remain systems of record. AI should call approved APIs rather than become a second transaction system.
• Integration and orchestration manages APIs, change-data capture, batch, events, retrieval and tool calls. It validates schemas, rate-limits access and normalises identifiers.
• Data and knowledge services provide ODS views, warehouse/lakehouse tables, streams, document repositories, catalogues, semantic models, optional graphs and policy-aware search indexes.
• IAM authenticates users and workloads and supplies narrowly scoped entitlements. Agents need distinct identities, not administrative credentials.
• Security and policy controls enforce classification, purpose, row/column/document security, regional routing, DLP, encryption, secrets, content filtering, output validation and approvals.
• Observability and audit record identities, policy decisions, retrieved sources and versions, model/prompt versions, tool calls, approvals and failures, with minimised logs.
• Infrastructure provides isolation, backup, disaster recovery, CI/CD, key management and policy-as-code. It does not replace business governance.
• Governance and operations define standards and decision rights, run quality and service monitoring, respond to incidents and retire products.

RAG, vector databases and knowledge graphs in context

Retrieval-augmented generation (RAG) retrieves external content and supplies it to a language model at answer time. The original Lewis et al. research paper described RAG as combining model memory with an external non-parametric memory such as a dense vector index. In enterprise use, that memory should be an approved source set with citations, access controls and freshness rules.

A governed document path is: identify authoritative repositories; extract content while retaining document ID and location; classify it; inherit or map permissions; split it into meaningful passages; create lexical and vector indexes; register lineage; retrieve with identity and metadata filters; and return a context package containing evidence references. If a document is withdrawn, its passages, embeddings, summaries and caches need a defined quarantine or deletion path.

A vector database is useful for large-scale similarity, recommendations, duplicate detection or multimodal search. It is not the source of truth for balances, current inventory, contractual totals or authorisation decisions. A relational database with an embedding extension, such as pgvector, may be enough for a bounded use case. A dedicated platform needs a measurable case for scale, latency, modality, isolation or operational features.

A knowledge graph is useful for questions that traverse stable relationships—asset to site to contract to procedure, for example—plus entity resolution, dependency analysis and impact assessment. It adds cost when relationships are sparse, identifiers unstable, ontology ownership absent or relational data and search already solve the problem. Start with a relationship inventory and a query test before creating one.

End-to-end process and data flow

The retrieval layer, not the model, decides which source material the user is authorised to receive. Exact figures should come from structured queries or business APIs and show definition and freshness. Document answers should cite source, version and location. Consequential agent actions should separate planning from execution and require human approval or bounded policy thresholds.

Security, privacy and governance considerations

Classification, purpose and privacy

Classify records, fields, documents, events and derived assets as public, internal, confidential, restricted personal, regulated or high-value intellectual property as appropriate. “Available to the company” is not “available to every AI application”. Record the purpose for which a product may be used.

The NIST Privacy Framework offers a sector-neutral approach to privacy risk. New Zealand organisations should consider the Privacy Act 2020 principles, including reasonable safeguards and retention. Organisations operating in the European Economic Area must also consider the GDPR, including lawful basis or consent where relevant, purpose limitation, minimisation, accuracy, storage limitation and individual rights.

Access, residency and intellectual property

Use least privilege, role-based controls where appropriate, and attribute- or purpose-based controls where access depends on project, case, region or contract. Propagate identity and policy claims to retrieval; do not copy an entire repository into a shared index. Treat embeddings, extracted text, summaries, graph triples, caches and prompt logs as derived data whose sensitivity must be assessed.

Document where source data, embeddings, prompts, logs, backups, support access and subprocessors are processed. Procurement should ask about regional routing, tenant isolation, training use, key management, deletion evidence and breach handling. Record whether content is owned, licensed, confidential or third-party. A user’s ability to view a document does not automatically grant permission to train a model on it, send it to an external provider or expose it in a new product.

AI-specific threats and evidence

The OWASP Top 10 for LLM Applications 2025 includes prompt injection, sensitive information disclosure, supply-chain risks, poisoning, improper output handling and excessive agency. Treat retrieved text as untrusted data; keep policy instructions outside it; validate outputs; allowlist tools; limit transactions; require approvals; and provide rollback.

An audit trail should answer who requested access, what purpose was declared, which policy allowed or denied it, which source versions were retrieved, which model and prompt ran, what tools were called, who approved an action and what changed afterwards. OpenTelemetry can provide application traces, metrics and logs, while OpenLineage provides lineage metadata for jobs, datasets and runs.

Quality must cover validity, completeness, uniqueness, consistency, timeliness and fitness for purpose. ISO 8000-1:2022 provides data-quality principles. For RAG, evaluate retrieval and answer quality separately: correct evidence retrieved, citations accurate, sensitive content excluded and abstention appropriate.

Architecture options and trade-offs

Approach	Strengths	Risks	Good fit
Centralised platform and ownership	Consistent standards and simpler operations	Central team bottleneck; weak domain accountability	Smaller or early-maturity organisations
Federated platform with domain ownership	Shared controls plus local meaning	Requires strong contracts and common metadata	Most enterprises progressing beyond central reporting
Domain-oriented data products/data mesh	Scales ownership with business domains	High product, engineering and governance maturity required	Large, multi-domain organisations
Hybrid evolution	Central control plane and selected domain products	Responsibilities can become ambiguous	Practical default for incremental modernisation

Data mesh is more than distributed storage. Its commonly cited principles are domain ownership, data as a product, self-service platform and federated governance, as described in AWS Prescriptive Guidance. Centralise capabilities that benefit from scale—IAM, policy, catalogue standards, quality tooling, observability and platform engineering—while distributing business ownership.

Capability	Build selectively when…	Buy or consume managed when…	Procurement test
Catalogue and lineage	Metadata is unusual and open interfaces already exist	Connectors and stewardship workflows are the bottleneck	Can metadata and lineage be exported?
Lakehouse/warehouse	Portability or specialised processing is strategic	A managed service meets residency and workload needs	What are exit, table-format and cost options?
Search/vector	Existing database meets bounded scale	Scale, multimodal search or isolation justifies it	Can it enforce per-user filters and deletion?
Graph	Graph modelling is core capability	Managed operations reduce burden without hiding the model	Who owns identifiers, ontology and updates?
Policy/identity	Authorisation logic is organisation-specific	IAM, DLP and policy services meet controls	Are decisions testable, observable and revocable?

Enterprise use cases

The following are illustrative patterns, not claims about named organisations.

Financial services: investigation assistant

Combine governed transaction measures, current case state, approved procedures and a graph linking customers, accounts, counterparties, alerts and cases. Hybrid retrieval produces cited evidence and a draft investigation summary. Strict purpose limitation, segregation of duties, regional processing and human approval are essential; the assistant must not freeze an account or file a report autonomously.

Government: policy and caseworker assistant

Use a semantic model for programme, application, person, decision and entitlement concepts; a versioned policy repository; and a purpose-limited case-data API. Return section-level citations and flag expired or conflicting guidance. Privacy impact assessment, accessibility, public-records retention, protected case-data separation and human accountability are required.

Healthcare: clinical operations retrieval

Keep the clinical system as source of record, expose a minimum-necessary operational read model and index approved guidelines with version and access controls. Combine structured filters with search for history and guidance. Apply consent and health-information controls, break-glass audit, clinical safety review and a prohibition on unreviewed diagnosis or treatment changes.

Manufacturing: production and maintenance copilot

Combine streaming machine events, lakehouse history, current asset status, quality results, maintenance procedures and a semantic model for plant, product, batch, asset and work order. A graph may connect components and failure modes. Keep operational technology isolated, validate sensor quality and require approval before creating or changing consequential work orders.

AI data-readiness assessment

Score each dimension from 0 (no evidence) to 4 (strong evidence). Calculate (score ÷ 4) × weight and sum to 100.

Dimension	Weight	Evidence for a 3–4 score
Purpose and risk tier	10	Outcome, users, harms, authority and evaluation defined
Inventory and ownership	10	Catalogue, business owner, steward and escalation path
Quality and contracts	15	Automated thresholds, issue handling and compatible change process
Metadata and lineage	10	Source, transformation and derived-asset provenance usable
Semantics and identity	10	Glossary, definitions, mappings and entity resolution
Privacy, classification and IP	15	Purpose, rights, licence, residency and retention evidenced
Access enforcement	10	Identity-aware filtering, revocation and negative access tests
Platform and integration	10	Repeatable pipelines, APIs, events and schema evolution
Unstructured/RAG readiness	5	Versioned content, ACL inheritance, citations and deletion tested
Operations and skills	5	SLOs, alerts, runbooks, on-call and continuous evaluation

Interpret 0–39 as unready, 40–59 as exploratory, 60–79 as pilot-ready and 80–100 as scale-ready for the assessed scope. Ownership, privacy/IP, access, deletion and auditability are gates: a high average cannot compensate for failure in one of them.

Implementation roadmap

Phase	Activities and outputs	Exit criteria
Discovery	Select two or three use cases; inventory sources, owners, risks, definitions and flows; score readiness	Sponsor, product owner, data owners and outcomes agreed
Design	Define products, contracts, identifiers, semantics, policy model, retrieval pattern, NFRs and threat model	Bounded design and control gates approved
Pilot	Build one structured and/or document use case with ACL-aware retrieval, citations, evaluation and observability	Safety, quality, latency, cost and human-review thresholds met
Controlled rollout	Automate onboarding; integrate IAM, DLP, records management and operations; train domains	Production service is supportable, auditable and revocable
Continuous improvement	Monitor quality, drift, permissions, retention, search, cost and adversarial tests	Reusable products improve without weakening controls

Key artefacts are a use-case canvas, source/product inventory, glossary and identifier map, data contracts, lineage map, data-flow and trust-boundary diagram, ADRs, threat model, privacy/IP assessment, evaluation set, NFRs, cost model, runbook, incident playbook and retirement procedure.

Roles should be explicit: the executive sponsor owns outcome and risk appetite; the AI product owner owns workflow and human oversight; the domain data owner owns meaning, quality and access; architects own boundaries and decisions; platform teams own pipelines and resilience; security/IAM own authorisation; privacy, legal and records teams own regulatory and rights assessments; AI engineers own retrieval and model evaluation; and operations owns SLOs, incidents and change.

Relevant NFRs include freshness, quality, availability, RTO/RPO, p95 latency, encryption, least privilege, residency, deletion SLA, reproducibility, citations, cost limits, portability, approval thresholds and rollback. Metrics should cover business cycle time, quality pass rate, freshness, lineage coverage, retrieval precision/recall, grounded-answer rate, citation correctness, abstention rate, policy denials, deletion completion, tool-call success, rollback rate, incident MTTR and cost per completed task.

Common mistakes and anti-patterns

• “Put everything in the lake.” Storage without ownership and lifecycle creates a larger swamp.
• “The vector index is enterprise memory.” Vectors are derived retrieval aids, not current truth or permission decisions.
• “Copy every repository into a shared index.” This discards ACLs, versions, retention and context.
• “Let the model enforce permissions.” Authorisation belongs in IAM, policy services, repositories, databases and tool gateways.
• “Use semantic search for exact facts.” Use typed queries and approved metrics for balances, totals and regulatory values.
• “Build the ontology first.” Start with a bounded relationship problem and an accountable domain owner.
• “Fine-tune before fixing retrieval.” Model tuning does not repair stale policies, broken permissions or conflicting definitions.
• “Pilot with sensitive data for convenience.” Use synthetic, masked or low-risk data until purpose, supplier terms and deletion are approved.
• “Agents are chatbots with more tools.” Agents need identities, narrow tools, limits, approval, monitoring and a kill switch.

Architecture Review Board decision checklist

Ask: What decision or process improves? Which sources are authoritative? Who owns the product? What definitions and identifiers are required? What proves quality and freshness? What personal, regulated, confidential or licensed content is involved? What is the approved purpose? Where are source, derived data, prompts, logs, backups and subprocessors located? How is per-user access enforced and revoked? How are exact facts separated from semantic retrieval? What happens when evidence is stale, conflicting or absent? How are prompt injection, poisoning, leakage and unsafe tools tested? What requires human approval? What are the NFRs, costs, exit path and retirement plan?

Warning signs include no accountable owner, unclear purpose, unrevocable access, manual uploads of sensitive content, unreliable document versions, unclear vendor data-use terms, no derived-data deletion, no audit trail, no operations team or an expectation of fully autonomous high-impact decisions without a control model.

Conclusion

AI readiness is the ability to turn enterprise data into trusted, reusable and policy-aware products. The winning architecture is not necessarily the one with the biggest lake or newest vector service. It is the one that can discover approved data, interpret it consistently, enforce access, cite evidence, respect lifecycle rules and fail safely.

Choose the simplest architecture that meets a valuable use case. Centralise identity, policy, catalogue standards, quality tooling, observability and platform engineering where scale helps; distribute business ownership to the domains that understand the data. Measure readiness, improve the minimum viable data path and generalise what works. That is how an organisation moves from AI experimentation to dependable enterprise capability.

Frequently asked questions

Is a lakehouse required for AI readiness?

No. A warehouse, operational store, repository and search service may be sufficient. A lakehouse helps when scalable mixed-format history and repeated analytics or AI workloads justify it.

Should every enterprise create a data mesh?

No. Use it when domains can own supported products and the organisation can operate federated governance. A hybrid central-platform/domain-product model is often safer.

Are embeddings anonymous?

Not automatically. Treat them as derived data, classify them, restrict access and define source references and deletion behaviour.

When should we use RAG rather than fine-tuning?

Use RAG for current, changing or source-cited enterprise information. Fine-tuning may improve behaviour or style, but it does not replace authoritative retrieval or access controls.

Does a knowledge graph replace a semantic layer?

No. A semantic layer defines business concepts and metrics; a graph represents explicit entities and relationships. They can complement each other.

What is the first practical step?

Select one bounded use case, name its owners, classify its data, identify authoritative evidence and score readiness. Turn the gaps into a modernisation backlog.

References

1. Artificial Intelligence Risk Management Framework (AI RMF 1.0) — National Institute of Standards and Technology, January 2023.
2. Generative Artificial Intelligence Profile — NIST, 26 July 2024.
3. ISO/IEC 42001:2023 — Artificial intelligence — Management system — ISO/IEC, December 2023.
4. ISO/IEC 27001:2022 — Information security management systems — ISO/IEC, October 2022.
5. Privacy Framework — NIST, January 2020; current materials accessed 8 August 2026.
6. Privacy Act 2020: Privacy principles — Office of the New Zealand Privacy Commissioner, 2020; current guidance accessed 8 August 2026.
7. Regulation (EU) 2016/679 (GDPR) — European Parliament and Council of the European Union, 27 April 2016.
8. ISO 8000-1:2022 — Data quality: Overview — ISO, April 2022.
9. ISO/IEC 11179-1:2023 — Metadata registries: Framework — ISO/IEC, January 2023.
10. Data Catalog Vocabulary (DCAT) Version 3 — W3C, 22 August 2024, Recommendation.
11. PROV-O: The PROV Ontology — W3C, 30 April 2013, Recommendation.
12. RDF 1.1 Concepts and Abstract Syntax — W3C, 25 February 2014, Recommendation.
13. OWL 2 Web Ontology Language Document Overview — W3C, 11 December 2012, Recommendation.
14. SPARQL 1.1 Query Language — W3C, 21 March 2013, Recommendation.
15. Shapes Constraint Language (SHACL) — W3C, 20 July 2017, Recommendation.
16. Apache Iceberg Documentation — Apache Software Foundation, continuously maintained; accessed 8 August 2026.
17. Apache Kafka Documentation — Apache Software Foundation, current documentation updated 22 May 2026.
18. OpenLineage Documentation — OpenLineage project, continuously maintained; accessed 8 August 2026.
19. OpenTelemetry Documentation — CNCF OpenTelemetry project, continuously maintained; accessed 8 August 2026.
20. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Patrick Lewis et al., 22 May 2020; NeurIPS 2020.
21. OWASP Top 10 for Large Language Model Applications — OWASP GenAI Security Project, 2025.
22. Strategies for building a data mesh-based enterprise solution — Amazon Web Services, 16 April 2024; current guidance accessed 8 August 2026.
23. Announcing ODPS v1.0.0 — Bitol, 2 October 2025.
24. What is a data lakehouse? — Databricks, updated 28 July 2026.
25. Microsoft Fabric decision guide: choose a data store — Microsoft, 1 May 2026.
26. pgvector: Open-source vector similarity search for Postgres — pgvector project, continuously maintained; accessed 8 August 2026.

This article is an architecture guide, not legal, privacy or regulatory advice. Organisations should obtain jurisdiction-specific advice for their data, industry and AI use cases.