Data foundations for GenAI that actually ship
Garbage in, hallucination out
A generative AI application can produce a fluent answer even when its evidence is incomplete, outdated, or wrong. That makes weak data foundations more dangerous, not less. In a conventional dashboard, a missing field may create an obvious blank. In a language interface, the same gap can be hidden inside a confident explanation. The model is often blamed because it is the visible component, but many failures begin earlier: documents are duplicated, permissions are inconsistent, definitions conflict, metadata is absent, or source systems refresh at different times. Prompt changes cannot reliably repair these structural problems. If the application cannot identify trusted information and retrieve it with the right context, polished language only makes the weakness harder to notice.
The phrase garbage in, hallucination out is useful but incomplete. Quality is not simply a property of raw data. It depends on the question, the user, the time, and the action that follows. A policy assistant needs current versions and effective dates. A support assistant needs product, customer, and entitlement context. An analytics copilot needs consistent metric definitions and access to the correct semantic layer. The foundation must therefore connect quality with purpose. Teams should define which sources are authoritative, how freshness is measured, which exceptions are acceptable, and what the system should do when evidence is weak. This turns data quality from a generic clean-up effort into an explicit part of product behaviour.
The governed foundation
A governed foundation begins with visibility. Teams need an inventory of sources, owners, classifications, access policies, lineage, and known limitations. Metadata should describe not only what a dataset or document contains, but also how it may be used. Identity and permission rules must carry through retrieval so the application never exposes information a user could not access at the source. Sensitive content needs appropriate masking, retention, and audit treatment. Versioning matters for policies, contracts, procedures, and product documentation because the most relevant passage is not always the most current one. These controls are easier to establish as shared platform capabilities than to recreate inside every AI project.
Governance should make safe delivery faster. Clear source onboarding, reusable permission patterns, standard document processing, and common evaluation tools reduce the number of decisions each product team must invent. Data stewards and domain owners remain essential, but their role becomes more actionable when issues are linked to specific products and outcomes. For example, a retrieval failure can be traced to a stale source, poor metadata, an unsuitable chunk, or a permission mismatch. Each cause has a different owner and remedy. A governed foundation makes this path visible. It also provides evidence for audits and reviews without forcing teams to reconstruct how an answer was produced after the fact.
Pipelines built for production
Production pipelines must handle more than ingestion. They need to extract content, preserve useful structure, enrich metadata, remove duplicates, apply permissions, create retrieval units, generate indexes, and refresh them when sources change. The right chunking strategy depends on the material. A policy manual, a table, a customer case, and a source code repository should not be split in the same way. Retrieval may combine keyword search, vector similarity, metadata filters, graph relationships, and re-ranking. The pipeline should preserve links back to the source so the application can cite evidence and users can inspect it. These choices should be tested against real questions, not assumed from a generic benchmark.
Operations are equally important. Teams need to know whether a source failed to refresh, an index is missing records, retrieval latency increased, or a new document format reduced extraction quality. Data contracts can make upstream expectations explicit, while observability can detect volume, schema, freshness, and distribution changes. Evaluation sets should include normal questions, ambiguous wording, permission boundaries, outdated information, and cases where the correct response is to say that evidence is insufficient. Monitoring production behaviour then reveals where the evaluation set must grow. A good pipeline is not one that runs once. It is one that can explain its state, recover from failure, and improve as the underlying information changes.
Foundation first, magic second
Strong foundations do not eliminate the need for good models, prompts, or interfaces. They make those investments productive. When trusted context is available, teams can compare models fairly, improve prompts with evidence, and design responses that show citations, confidence, or missing information. When access rules are consistent, new channels can reuse the same governed layer. When metadata and lineage are available, domain experts can correct a source instead of patching individual answers. This reduces the temptation to solve every failure inside the application. It also makes cost easier to manage because teams can retrieve smaller, more relevant context and avoid repeated processing of the same material.
The practical sequence is foundation first, then magic in controlled increments. Choose a bounded use case and define the information it requires. Identify authoritative sources, owners, permissions, freshness expectations, and quality checks. Build the ingestion and retrieval path with traceability. Create an evaluation set before broad rollout, and include failure cases as carefully as success cases. Release to a limited audience, monitor what the system retrieves and how users act on it, then strengthen the shared platform with what is learned. This approach may feel slower than a polished demo, but it reaches dependable production sooner. The result is not only a better application. It is a reusable information foundation for the AI products that follow.
Teams can assess readiness with a short evidence review. For every source, confirm ownership, permission propagation, update frequency, failure alerts, and a path for correcting errors. For every important answer, confirm that an evaluator can trace the retrieved passages and reproduce the application state. For every release, compare quality, latency, and cost against a stable test set. These checks turn an abstract foundation programme into visible product criteria. They also make it easier to expand because new use cases can inherit proven controls instead of negotiating the same requirements again.
