Table of contents
Share This Article
- Why Most Enterprise AI Initiatives Fail Before the First Sprint
- What an Enterprise AI Data Foundation Actually Is
- The Six Layers of a Production-Ready AI Data Foundation
- How to Assess Your Current Data Readiness
Most enterprise AI initiatives do not fail because the model was wrong. They fail because the data foundation underneath them was never ready, and nobody told the steering committee until quarter four. By mid-2026, the pattern is visible enough that it has become a board-level concern: the average enterprise has launched between fourteen and twenty AI use cases in the past eighteen months, and only one to three are still running in production at the end of that period.
This is the practitioner’s guide to the data foundation enterprise AI actually needs. It is written for CTOs, Heads of Data, Heads of AI, and Chief Data Officers in mid-market and enterprise organisations across APAC, the UK, and the US. It assumes you have already paid for a few failed pilots, you have a shortlist of new use cases waiting on infrastructure decisions, and you are tired of vendors selling you the next model when the bottleneck is what you are feeding the model. We will cover what an AI data foundation actually consists of, the six layers every production-grade foundation needs, how to assess your current readiness, a 24-week implementation roadmap, and the specific regulatory expectations that MAS, HKMA, IMDA, the FCA, the ICO, and the EU AI Act now place on your data layer.
Why Most Enterprise AI Initiatives Fail Before the First Sprint
The headline numbers are sobering. Gartner’s 2025 research shows that at least 30% of GenAI projects will be abandoned after proof of concept by the end of 2025, with a further wave projected through 2026 as enterprises run out of patience with pilots that never reach production. MIT Sloan and Boston Consulting Group’s joint research, now in its fifth iteration, continues to find that the dominant barrier between pilot and production is not model selection, not infrastructure cost, and not regulatory uncertainty. It is data. RAND’s 2024 study of AI project failures found data-related issues as the top cited cause across 65 enterprise interviews, ahead of talent gaps, leadership turnover, and vendor risk.
The mechanism is consistent enough that it has become a cliche, and the cliche is still true. A team builds a proof of concept on a clean, hand-curated dataset of five hundred documents. The demo lands well. The board funds a production rollout. Six months later, the team is still trying to ingest the actual document estate, and the answers in production are worse than the demo because the underlying corpus is messier, the metadata is missing, the entitlements are inconsistent, and nobody knows which copy of a regulation document is the current one.
There are five structural reasons this keeps happening, and none of them go away by choosing a different model provider.
The first is that AI workloads expose data quality problems that traditional analytics tolerated. A dashboard with 5% missing rows is still useful. A retrieval-augmented generation pipeline that retrieves a five-year-old policy document with no version stamp can return a confidently wrong answer to a regulator. The cost of bad data goes from “slightly inaccurate report” to “compliance incident” the moment a model starts generating text on top of it.
The second is that most enterprise data estates were built for transactional or analytical workloads, not for retrieval. The schemas are normalised for joins, not chunked for semantic search. The metadata describes table provenance, not document semantics. The access controls assume row-level queries, not vector similarity. Bolting a vector layer on top of a data warehouse without rebuilding the metadata layer underneath is the most common architectural mistake of 2025ā2026, and it is the one that produces the “the demo worked but production does not” failure mode.
The third is that data ownership is fragmented across business units, and AI initiatives expose that fragmentation in ways that BI tools never did. Building a unified customer copilot requires reconciling identity, consent, and history across CRM, support, billing, and product analytics. Every one of those systems has a different owner, a different schema, and a different update cadence. The AI team becomes the de facto data integration team, which is not the role they were hired for and not a role they have authority to execute.
The fourth is that compliance dates are arriving faster than data programmes are landing. The EU AI Act’s high-risk obligations on data governance and quality (Article 10) are now scheduled to apply from 2 December 2027 following the Digital Omnibus deferral confirmed in mid-2026. Singapore’s MAS AI Risk Management Guidelines (AIRG) are tracking toward Q1 2027 enforcement. Hong Kong’s HKMA SA-2 framework expects banks to demonstrate data lineage and quality controls for any AI-influenced decision. The UK’s FCA has signalled that operational resilience expectations under SS1/23 extend to AI data dependencies. Each of these frameworks demands evidence that your data foundation is documented, controlled, and auditable, not just functional.
The fifth is that the talent market for foundational data work has not caught up with the talent market for model work. Hiring a prompt engineer is easier than hiring a data steward, even though the steward delivers more durable value. Enterprises that under-invest in data engineering, governance, and stewardship roles end up with eye-catching demos and unreliable production systems.
The good news is that the playbook for fixing this is well understood by 2026. The bad news is that it requires sustained engineering investment over two to four quarters, and there is no shortcut.
What an Enterprise AI Data Foundation Actually Is
An AI data foundation is the set of systems, controls, and operating practices that make enterprise data reliably useful to AI workloads at production scale and under regulatory scrutiny. It is not a data lake. It is not a vector database. It is not a single product you can buy. It is the layered set of capabilities that sits between your raw operational systems and every model, agent, or RAG pipeline you deploy.
A useful working definition for an enterprise team is this: an AI data foundation is production-ready when (a) any approved AI workload can request the data it needs through a stable interface, (b) every piece of data returned has known provenance, freshness, and access controls, (c) the workload’s use of that data is logged in a form a regulator or internal auditor would accept, and (d) changes to the underlying source systems flow through the foundation without breaking the workload.
That definition has four operational consequences worth dwelling on.
First, “stable interface” means an internal API or catalogue layer that abstracts source systems from AI consumers. Without this layer, every new AI workload becomes a direct integration project, and the cost of building the eleventh use case is the same as building the first. Sthambh’s recommended pattern is a thin “AI data services” layer that exposes well-described retrieval endpoints, embedding pipelines, and identity-aware access controls.
Second, “known provenance” means lineage that traces every retrieved chunk back to a source document, a source system, a version stamp, and an author or owner. This is what makes audit defensible. A bank that cannot tell a regulator which policy version the AI agent retrieved when it advised a customer is not in compliance with most reasonable interpretations of MAS AIRG or HKMA SA-2.
Third, “logged in an audit-acceptable form” means structured tracing that captures the prompt, the retrieved context, the model output, the model version, and the downstream action, with retention aligned to the regulator’s expected window. Most AI teams discover this requirement after launch, when their first internal audit finds that the relevant evidence does not exist.
Fourth, “changes flow through without breaking” means schema and source-of-truth changes propagate to embeddings, indexes, and prompt templates through controlled pipelines, not through ad-hoc rebuilds. This is where most teams underestimate the operational tax of running production AI: an upstream schema change in your CRM should not require an engineer to spend a sprint regenerating the customer-history index.
With that definition in place, the next section maps the six layers that make it real.
The Six Layers of a Production-Ready AI Data Foundation
A complete enterprise AI data foundation has six layers. They are not optional, and they are not sequential. They are six concurrent capabilities that must all exist at a minimum maturity level before AI workloads can scale beyond pilot.
The following table summarises the layers, their purpose, the typical owners, and the minimum maturity required to support a production AI use case.
| Layer | Purpose | Typical Owner | Minimum for Production |
|---|---|---|---|
| 1. Inventory and Lineage | Know what data you have, where it lives, who owns it, where it came from | Chief Data Officer | 80%+ of in-scope sources catalogued with owner and refresh cadence |
| 2. Quality and Governance Controls | Define and enforce what "good" data looks like; remediate when it is not | Head of Data Governance | Quality SLAs defined and monitored for all AI-feeding sources |
| 3. Metadata and Semantic Layer | Make data discoverable and meaningful to non-author consumers (and models) | Head of Data Architecture | Business glossary, entity definitions, and semantic tagging in place |
| 4. Pipelines and Orchestration | Move, transform, embed, and refresh data on a defensible cadence | Head of Data Engineering | Versioned, observable pipelines with rollback paths |
| 5. Retrieval and Vector Infrastructure | Serve embeddings and structured retrieval to AI workloads at low latency | Head of AI Platform | Production vector store with monitoring and tenant isolation |
| 6. Access, Identity, and Audit | Enforce who can retrieve what, and log every retrieval for review | Head of Information Security | Identity-aware retrieval, structured audit, retention policy in force |
The rest of this section walks each layer with the design decisions that matter most.
1. Inventory and Lineage
You cannot govern, retrieve, or audit data that nobody knows exists. The first capability of an AI data foundation is a living inventory of every data source in scope for AI workloads, with explicit ownership, refresh cadence, sensitivity classification, and lineage to upstream systems.
Most enterprises have a partial data catalogue covering structured warehouse tables and treat the document estate (SharePoint, Confluence, Notion, Box, Google Drive, internal wikis, email archives) as someone else’s problem. For RAG and agentic workloads, the document estate is often more important than the warehouse. The inventory must extend to it. A useful threshold is “80% of in-scope sources catalogued with owner and refresh cadence” before the first production AI workload depending on retrieval is approved.
Lineage is the second half of this capability. Every retrieved chunk in production must trace back to a source object, a version, and an authoritative owner. When a regulator asks why the AI agent advised a customer to take a particular action, the answer must include “based on policy document X version Y dated Z, last reviewed by owner W.”
2. Quality and Governance Controls
Quality controls answer the question “is this data good enough to feed the model?” and governance controls answer the question “who decided what good enough means?” Both questions need explicit owners, written SLAs, and automated monitoring.
A practical minimum for production includes accuracy thresholds for each source (e.g. customer contact data must be 95% accurate at the time of retrieval), freshness SLAs (e.g. policy documents must be refreshed within 24 hours of source update), completeness checks (e.g. mandatory metadata fields must be present), and uniqueness controls (e.g. deduplication policy for the same regulation appearing in multiple repositories). When a source falls below SLA, the retrieval layer should know, and downstream AI workloads should either degrade gracefully or refuse to answer.
Governance also has to answer harder questions about data appropriateness, not just quality. Can this customer-conversation transcript be used to train an agent that customers will see? Has consent been recorded for that use? Has personal data been redacted in line with PDPA or the UK GDPR? These are decisions a data governance committee makes once, encodes in policy, and the engineering layer enforces by default.
3. Metadata and Semantic Layer
Models, like new employees, need context to interpret raw data. The semantic layer is the set of business definitions, entity descriptions, and tags that make data interpretable without the original author in the room.
For structured data, this looks like a business glossary that defines what “active customer” means across the CRM, the billing system, and the analytics warehouse, with mappings to the underlying physical fields. For unstructured data, it looks like a tagging schema applied at ingestion that captures document type (policy, procedure, marketing collateral, customer correspondence), jurisdiction, owner, effective date, supersession status, sensitivity, and intended audience.
Without a semantic layer, two things go wrong. First, retrieval returns the right document for the wrong reason and the wrong document for the right reason at roughly equal rates. Second, every new AI workload reinvents its own ad-hoc taxonomy in prompts, which is unmaintainable beyond two or three use cases.
4. Pipelines and Orchestration
The pipeline layer is where source data becomes retrieval-ready data. It covers ingestion, extraction (especially for PDFs and structured documents), chunking, embedding, indexing, refresh, and versioned rebuilds. By 2026 the engineering patterns are reasonably mature, but the operational discipline around them is often not.
Three pipeline disciplines separate production-grade foundations from pilot-grade ones. First, pipelines are versioned and reproducible ā re-embedding the same corpus with the same code should produce the same vectors, and the version of the embedding model is part of the index metadata. Second, pipelines are observable ā every ingestion run has visible throughput, error rate, source coverage, and downstream impact on retrieval quality. Third, pipelines have rollback paths ā if a bad ingestion run pollutes the index, the operations team can revert to a known-good snapshot in under thirty minutes.
For a deep walkthrough of the pipeline patterns we recommend for regulated industries, see our GenAI pilot-to-production playbook, which covers ingestion, evaluation, and observability in production detail.
5. Retrieval and Vector Infrastructure
The retrieval layer is the runtime interface between AI workloads and the data foundation. It includes the vector store, hybrid retrieval (combining semantic and keyword search), reranking, and the metadata filters that make tenant, jurisdiction, and entitlement constraints enforceable at retrieval time.
The design choices here have material implications for cost, latency, and compliance. APAC enterprises operating under MAS, HKMA, or IMDA data-residency requirements often have to choose a regional or in-tenancy vector store, which narrows the option space. UK firms have more flexibility but still need to evaluate the operational resilience of any SaaS vector platform against FCA SS1/23 expectations. US enterprises in regulated sectors (healthcare under HIPAA, financial services under SEC and FINRA rules) face similar trade-offs.
Our vector database architecture guide for regulated industries covers the specific decisions teams in Singapore, Hong Kong, and the UK face when picking a production-grade vector platform.
6. Access, Identity, and Audit
The final layer is what keeps the foundation defensible under audit. Every retrieval call in production must carry identity (which user or service initiated it), context (what was retrieved), and outcome (what the model did with it). That information must be logged in a structured form with retention aligned to regulator expectations, and access to the logs must itself be controlled.
The access model needs to enforce entitlements at retrieval time, not afterwards. If a user does not have permission to read a document, the AI workload should never see that document in the retrieval result. Filtering after the fact is both slower and more dangerous: a single misconfiguration in the post-retrieval filter can leak sensitive content. Identity-aware retrieval bakes the access check into the vector query.
The audit layer also needs to handle the regulator’s likely questions in advance: which agent took which action on which customer on which date, based on what data, using which model version. Building this on the way up costs a fraction of retrofitting it later.
How to Assess Your Current Data Readiness
Most enterprises that hire Sthambh to assess AI data readiness already suspect the answer is “not ready.” The value of a formal assessment is not the verdict but the prioritised gap list and the cost-and-time estimate to close it. A useful assessment scores each of the six layers on a 1-to-5 maturity scale, identifies the lowest-scoring layer that is blocking the highest-value workload, and produces a quarterly roadmap.
The scoring rubric we use looks roughly like this. A score of 1 means the capability is absent or ad-hoc. A score of 2 means it exists for a single use case but is not generalisable. A score of 3 means it exists across major use cases but is not consistently governed. A score of 4 means it is consistently governed and observable. A score of 5 means it is production-grade, audit-defensible, and reusable across new use cases without rebuilding.
For a production AI workload in a regulated industry, every layer should be at 3 or above, and at least four of the six should be at 4 or above. Enterprises with a single layer at 1 or 2 should expect that layer to dominate their incident reports until it is upgraded.
The most common failure pattern we see is enterprises with a score of 4 on pipelines and retrieval (because the AI platform team has invested heavily there) and a score of 1 or 2 on inventory and governance (because the data office has not been resourced to keep pace). That gap is what produces the “the model is fine but we keep getting wrong answers” story.
Cost ranges for a foundational uplift programme depend on the scope and the starting maturity. For a mid-size enterprise (1,000ā5,000 employees) with average starting maturity, a programme to bring all six layers to a score of 3 typically runs USD 800,000 to USD 1.8 million over six months, including consulting, tooling, and internal time. The lower end assumes existing data engineering capability that can absorb the work. The upper end assumes a fresh build.
For an enterprise considering whether to start, our AI readiness assessment scorecard (linked from our LLM cost optimisation guide) is a useful self-evaluation before bringing in external help.
Implementation Roadmap: From Audit to Production Foundation
A realistic data foundation programme is a 24-week effort for a mid-size enterprise, longer for a large one. The roadmap below is the cadence Sthambh has refined across APAC, UK, and US engagements. Each phase has explicit exit criteria, not just deliverables.
Phase 1: Audit and Inventory (Weeks 1ā3)
The first phase is rapid and intensive. It produces a complete inventory of in-scope sources, an owner map, a sensitivity classification, and a current-state maturity score across the six layers. It also produces a shortlist of two to three near-term AI use cases against which the foundation will be sized. Without this anchoring, foundation work has a tendency to become a science project.
Exit criteria: at least 80% of in-scope sources catalogued with owner, refresh cadence, and sensitivity; current-state maturity scored for each of the six layers; shortlist of target workloads agreed with business sponsors.
Phase 2: Govern and Catalogue (Weeks 4ā10)
Phase 2 closes the lowest-maturity gaps in inventory, governance, and metadata. It is the most political phase, because it requires data-owner sign-off on quality SLAs, consent and use policies, and the semantic taxonomy. Engineering work in this phase is mostly catalogue tooling, metadata pipelines, and governance workflow.
Exit criteria: business glossary and entity definitions agreed; data quality SLAs published for all sources feeding the shortlisted workloads; governance committee meeting cadence operational; consent and use policy approved.
Phase 3: Operationalise (Weeks 11ā16)
Phase 3 is where the pipeline, retrieval, and access layers come online. It is the most engineering-intensive phase. Pipelines are built and versioned, the vector store is provisioned with tenant isolation, identity-aware retrieval is wired up, and the audit logging stack is deployed. The shortlisted workloads from phase 1 begin running against the new foundation in shadow mode.
Exit criteria: pipelines versioned and observable; vector store and retrieval layer in production with monitoring; identity-aware retrieval enforcing entitlements; audit logging operational with agreed retention; shortlisted workloads running in shadow.
Phase 4: Optimise and Scale (Weeks 17ā24)
Phase 4 takes the shortlisted workloads from shadow to live, captures cost and quality baselines, and admits the next two or three workloads onto the foundation. By the end of phase 4, the marginal cost of admitting a new workload is significantly lower than the cost of building the foundation, and the time-to-production for use case number five is measured in weeks rather than quarters.
Exit criteria: shortlisted workloads live with measured cost and quality; foundation cost-per-workload baseline established; second-wave workload backlog scored and queued; foundation runbook and operating model documented.
This 24-week roadmap is a guideline, not a contract. Enterprises with strong existing data engineering capability can collapse phases 1 and 2 by two to four weeks. Enterprises with weak existing capability often need 32 to 36 weeks to reach the same exit criteria. The variance is driven by data ownership disputes and governance committee cadence, not by engineering velocity.
Regulatory Context: What Your Data Layer Now Has to Demonstrate
By mid-2026, the regulatory expectations on enterprise AI data foundations have firmed up enough that the relevant frameworks can be mapped to the six layers directly. The geography of your business determines which frameworks bite hardest, but most multi-region enterprises end up engineering to the union of them.
In Singapore, the MAS AI Risk Management Guidelines (AIRG), tracking toward Q1 2027 enforcement, require regulated financial institutions to demonstrate data lineage, quality controls, and access governance for any AI-influenced decision. The MAS Notice 644 and Technology Risk Management Guidelines extend that expectation to the underlying technology stack. IMDA’s Model AI Governance Framework places similar expectations on auditability and traceability across all sectors. For practitioners, see our Singapore agentic AI governance implementation guide for the controls map.
In Hong Kong, HKMA’s SA-2 module on AI risk and the related Supervisory Policy Manual expect lineage, data quality controls, and human accountability for AI-driven decisions in banking. Insurance regulators (IA) and securities regulators (SFC) have signalled similar expectations for their domains. The HKMA’s GenAI sandbox programme has effectively become a stress test of these expectations against live deployments.
In the UK, the FCA’s operational resilience expectations under SS1/23 increasingly extend to AI data dependencies, and the ICO’s guidance on AI and data protection requires demonstrable controls on personal data flowing into AI systems. The PRA’s expectations for banks are aligning with the FCA’s. The UK government’s pro-innovation regulatory approach (under continuous evolution through 2026) does not relieve firms of these expectations; it distributes them across existing sector regulators.
In the EU, the AI Act’s Article 10 (data and data governance) places explicit obligations on high-risk system providers and deployers around training, validation, and testing data quality, bias examination, and data management practices. Following the Digital Omnibus deferral confirmed in mid-2026, the high-risk obligations now apply from 2 December 2027. APAC and UK enterprises supplying or operating AI systems used inside the EU remain in scope regardless of where their data is hosted.
In the US, sector-specific regimes dominate. Healthcare deployments under HIPAA require demonstrable controls on protected health information flowing into AI systems. Financial services deployments under SEC, FINRA, and OCC supervisory guidance need lineage and explainability for AI-influenced advice and decisions. State-level frameworks (CCPA in California, the Colorado AI Act, New York’s Local Law 144) layer additional obligations on top.
The practical takeaway is that the six layers map cleanly to regulator expectations. Inventory and lineage answer “what data went into the decision.” Quality and governance answer “was the data fit for purpose.” Metadata answers “what does the data mean.” Pipelines answer “was the process controlled.” Retrieval answers “did the system access only what it was entitled to.” Access and audit answer “can we prove all of the above.” A foundation that scores 4+ on each layer is a defensible answer to every regulator’s first three questions.
Real-World Examples From Enterprises Getting Foundations Right
The pattern recognition value of this section is high enough that it is worth two extended examples, both anonymised but drawn from live engagements and public case material.
A Singapore-headquartered bank with operations across Southeast Asia spent twelve weeks in early 2026 attempting to ship a customer-advisor copilot before pausing for a foundation rebuild. The original architecture put a generic vector store in front of a mixed estate of policy documents, product collateral, and customer-correspondence templates, with no consistent metadata layer. Retrieval quality was acceptable on the demo subset and unreliable on the full estate. The pause cost the team a quarter of momentum but produced, in the next twenty weeks, a six-layer foundation that now supports three production workloads (the original copilot, a compliance research assistant, and an internal policy Q&A) at predictable cost. The board’s eventual reaction was not anger at the pause; it was a request to formalise the foundation as a shared capability for the next twelve workloads.
A UK insurer with around 4,000 employees and a strong actuarial data culture assumed its existing data warehouse and governance discipline would translate directly to a production GenAI claims-triage workload. The first production incident ā a hallucinated coverage reference traced back to an out-of-date policy document in the document estate ā exposed the gap. The remediation programme added an unstructured-document inventory, a semantic tagging pipeline, identity-aware retrieval against the entitlement system, and a structured audit log aligned to FCA expectations. The insurer’s own retrospective concluded that the structured-data foundations they trusted had given them a false sense of confidence about the unstructured estate they had not built for. The lesson generalises: warehouse maturity does not transfer to retrieval maturity without explicit work.
Public case material reinforces both patterns. DBS Bank’s widely cited 800+ models in production, generating SGD 1 billion in measurable economic impact, is regularly attributed to a multi-year data foundation programme, not to a single AI breakthrough. McKinsey’s 2024 State of AI report continues to find that the companies extracting outsized value from AI invest several times more in data, governance, and integration capabilities than in models themselves. The gap between the median enterprise and the top quartile is largely a foundation gap.
How Sthambh Helps Enterprises Build AI Data Foundations
Sthambh works with mid-market and enterprise teams across APAC, the UK, and the US to assess current data readiness, design the six-layer foundation, and run the 24-week implementation programme alongside internal engineering. Our engagements are deliberately structured around exit criteria, not deliverables, because the goal is a foundation that supports the next twelve workloads, not a binder that documents the current one.
Typical engagement shapes include a four-week data readiness assessment (with a scored maturity report and prioritised roadmap), a twelve-week foundation accelerator (focused on the lowest-maturity layers blocking the highest-value workload), and a full 24-week foundation programme delivered alongside the client’s data and platform teams. We also augment internal teams with senior data architects, RAG engineers, and AI platform engineers under our staff augmentation model, particularly where a client has the strategy but not the capacity.
Across engagements, we make three commitments. First, we leave behind a foundation the client’s own engineering team can own and extend, not a black box dependent on our continued involvement. Second, we map every control we build to the regulator’s likely audit questions in the client’s geography, so the foundation is defensible from day one. Third, we measure success by the marginal cost and time-to-production of the next workload after the engagement, because that is the only number that matters to a CTO twelve months later.
If your team is sitting on a backlog of AI use cases that will not ship because the data layer is not ready, the right next step is a structured readiness assessment. Book a discovery call with Nikhil’s team at Sthambh to scope an assessment for your environment, or read our LLM cost optimisation guide for APAC enterprises for the cost lever inventory once your foundation is live.
FAQs
Q. How long does it take to build an enterprise AI data foundation?
A. A typical mid-size enterprise programme runs 24 weeks from initial audit to a foundation that supports two to three production workloads. Enterprises with strong existing data engineering capability can compress this to 18ā20 weeks. Enterprises with weak inventory, fragmented data ownership, or no governance committee should plan for 32ā36 weeks. The single biggest variance driver is governance cadence, not engineering capacity.
Q. What does an AI data foundation actually cost for a mid-size enterprise?
A. Direct costs for a mid-size enterprise (1,000ā5,000 employees) bringing all six layers to a maturity score of 3 typically run USD 800,000 to USD 1.8 million over six months, including consulting, tooling licences, cloud spend, and internal time. The marginal cost of admitting the next AI workload after the foundation is live is usually one tenth of building the first workload without a foundation. The ROI compounds from workload three onwards.
Q. Do we need a data foundation if we are only running one AI use case?
A. Partly. For a single, narrow use case with a small, well-owned corpus you can sometimes ship to production on a use-case-specific data stack. The moment you add a second workload, or the corpus expands, or the regulator asks for lineage, the foundation work becomes unavoidable. Most enterprises underestimate how quickly they reach the second workload, and the cost of retrofitting a foundation is two to three times higher than building it from the start.
Q. Where should responsibility for the AI data foundation sit organisationally?
A. The most durable pattern places overall accountability with a Chief Data Officer or Head of Data Platform, with delivery shared between data engineering, AI platform engineering, and information security. A single-team model rarely works because the layers cut across data, AI, and security organisations. A joint operating model with clear RACI per layer, a steering committee that meets fortnightly, and an executive sponsor who can resolve cross-team disputes is the pattern we recommend.
Q. How does the EU AI Act affect our data foundation if we are headquartered in APAC?
A. If you supply, deploy, or operate any AI system that is used inside the EU, the AI Act’s Article 10 data governance obligations apply regardless of where your data is hosted or your company is headquartered. Following the Digital Omnibus deferral confirmed in mid-2026, high-risk system obligations now apply from 2 December 2027. APAC enterprises with European customers, partners, or operations should engineer their foundation to the EU Act’s expectations as a baseline.
Q. How does an AI data foundation interact with our existing data warehouse and lakehouse investments?
A. The foundation is additive, not replacement. Your warehouse or lakehouse remains the source of truth for structured analytical data. The foundation adds the metadata, retrieval, semantic, and audit layers needed to make that data (plus your unstructured estate) safely consumable by AI workloads. In most engagements we estimate 60ā70% of the foundation cost goes to capabilities that did not previously exist (catalogue extensions, semantic tagging, vector infrastructure, identity-aware retrieval, audit logging) and 30ā40% extends or hardens existing platforms.
Q. What is the single biggest mistake enterprises make when building an AI data foundation?
A. Treating the foundation as a one-off project rather than an operating capability. Foundations that ship and then are not staffed, governed, and continuously evolved decay back to the original starting point within twelve months. The teams that win treat the foundation as a product with a roadmap, an internal customer base of AI workloads, a quarterly review cadence, and a dedicated operating team. Foundations are built by projects and sustained by products.
Nikhil Khandelwal
Co-founder & CTO, Sthambh
