Pilots connect a model to data. Production maintains a data product the model depends on. The distance between those two statements is where most generative AI programmes lose trust.
Teams celebrate launch day. Six weeks later answers cite retired policies, miss the new product line or leak information across access boundaries nobody tested. Users stop asking. Leadership concludes the model "does not work."
The model often works. The data work was skipped.
Retrieval is not "connect the folder"
Uploading PDFs to a vector index is a weekend project. Operating a retrieval corpus is ongoing work:
- Curation — which documents belong, which are superseded, which are draft
- Chunking and metadata — sections, product, region, effective date, access class
- Access filters — the agent retrieves only what the user may see
- Refresh — schedules and triggers when sources change
- Quality monitoring — failed ingestions, empty chunks, duplicate conflicts
Skip any layer and the system looks fine in demo questions while failing in production.
Lineage is how you debug Tuesday's wrong answer
When a user or auditor asks why the agent said X, you need a path: source document version, retrieval timestamp, chunk ID, model version, prompt version.
Without lineage, debugging is guesswork. Compliance teams cannot sign off. Engineering cannot reproduce.
Lineage belongs in the foundation build — documented from source to agent action — not in a ticket labelled "tech debt."
Feature stores and structured data matter too
Not every AI system is RAG over documents. Forecasting assistants, scoring copilots and operational agents mix structured features with text.
Training-serving skew still happens: a feature defined one way in a notebook and another in production. A feature store with consistent definitions is boring infrastructure that prevents silent wrong decisions.
Discovery includes a data readiness assessment precisely because these gaps kill timelines.
Data quality is workflow, not a one-time cleanse
Enterprises hope for a migration that fixes quality forever. Reality is continuous: new sources, manual overrides, acquisitions, policy exceptions.
AI magnifies quality problems because it speaks confidently. Monitoring needs rules beyond "is the pipeline green?" — sample retrievals, spot checks on answers against gold sources, alerts when corpus size or freshness diverges from expectation.
Residency and access are data decisions
Where embeddings live, which region serves inference, who can query which index — these are architecture choices made with data owners and legal, then enforced in infrastructure.
Pilots that run on a vendor sandbox bypass the conversation. Production cannot.
India, UAE, Australia, EU, US — we configure residency by requirement, documented in the discovery pack.
The CDO's legitimate question
"Why is AI my problem?" Because the model is a consumer of your estate. If AI succeeds, your catalogue, quality rules and access patterns improve. If AI fails on data, your team inherits the firefight anyway.
Better to design the retrieval corpus and evaluation datasets as products with owners, SLAs and change control — the same as any analytics asset with higher visibility.
What discovery surfaces
For the chosen use case, we document:
- Sources and owners
- Known quality issues and mitigations
- PII and classification
- Lineage gaps and plan to close them
- Refresh cadence and responsibility
- Residency constraints
If the gap is too large for week-twelve production, discovery says so and sequences work — foundations increment first, agent increment second. Honest sequencing beats a launch that erodes trust.
Checklist before you call data "ready"
- Who owns the retrieval corpus after go-live?
- How do policy updates propagate to embeddings — automatically, on schedule, on ticket?
- What access filters apply per role or tenant?
- What evaluation cases fail if the corpus is stale?
- Where is lineage visible for a single agent answer?
Weak answers mean the pilot is not ready to scale.
Data mesh and domain ownership
In mesh or fabric programmes, domains own datasets. AI use cases must respect domain boundaries and access patterns — not bypass them with a central dump.
Discovery maps which domains supply which sources and who approves corpus changes. AI success strengthens mesh discipline when retrieval products have named domain owners.
Monitoring retrieval health
Dashboards should show: corpus size over time, last successful refresh, ingestion error rate, average chunks per document, sample retrieval latency. Alerts when freshness SLA misses.
Ops teams familiar with pipeline monitoring adapt quickly; the gap is treating embeddings as production data, not cache.
Contract with the business on staleness
Agree maximum acceptable age for policy and product content. Publish internally. When exceeded, agent may refuse or escalate rather than guess — behaviour tested in evaluation.
Access control in retrieval
Users must not receive answers sourced from documents they cannot access directly. Retrieval filters enforce entitlements — tested in evaluation with users in different roles.
Failure here is a security incident, not a quality nit.
Embedding model changes
When embedding model changes, re-embed corpora in planned window with validation — retrieval quality samples before cutover. Treat embedding upgrades like database migrations.
Data debt explicit in discovery pack
If catalogue, quality or lineage debt blocks production, discovery lists it with owner and sequence. Sponsors accept debt consciously or fund foundation increment — no silent hope.
Build the data layer once, use it for many use cases
Foundations cost time upfront and amortise across agents, copilots and analytics. Vector stores, quality monitoring and evaluation harnesses are shared infrastructure — not one-off per pilot.
Incubics's Data & AI Foundations service exists for estates where every new AI idea hits the same wall. Discovery tells you if you are there.
Data work is not glamorous. It is why the system still answers correctly in month six.
Organisational ownership for data products
Name data product owners on org chart, not only RACI slide. Owners approve corpus changes and prioritise quality fixes.
Budget for corpus maintenance — ingestion jobs, steward time, eval dataset updates — alongside model spend.
Cross-functional data council monthly for AI corpora prevents silent rot.
Acquisition integrations must include AI corpus impact assessment — new docs, retired products, conflicting policy.
Deletion and retention — right to erasure applies to vectors derived from personal data in many regimes — plan erasure paths.
Synthetic data rarely replaces domain corpus for regulated answers — be sceptical of shortcuts.
Data work is unglamorous and decisive. Skipping it guarantees glamorous demo failure in production.
Invest accordingly in discovery and foundation increments.
Read How we work, Engagements and FAQ for process and commercials. Select your region — India, Middle East, ANZ or Other — when you write.
Closing note
Production AI is a programme of small disciplined choices: discovery before build, evaluation before users, APIs before agents, runbooks before scale, adoption alongside code. Skip any one and the demo survives while the business outcome does not.
Incubics works that way by design — two-week discovery, production by week twelve, optional managed run. Offices in Bengaluru, Pune and the USA. Legal entity IQLEXA Technologies Private Limited.
If this piece matches a problem you are living, the next step is a conversation, not another pilot.
hello@incubics.com for a discovery conversation that includes an honest data readiness read — not a folder upload and hope.