# Is Your Data Ready for Gen AI in Production?

> A practical data-readiness decision for CTOs: check source authority, usable evidence, permissions and updates before funding a production Gen AI application.

- AI-drafted | Reviewed & approved by: [Muhammed Shakir](https://www.linkedin.com/in/muhammed-shakir-gen-ai-trainings-and-consulting), Founder · Architect, engineer and trainer
- Published: 2026-11-03
- Last updated: 2026-11-03
- Topic: Gen AI in Production
- Written for: CTOs and delivery heads
- Web page: https://infomovertech.com/articles/enterprise-gen-ai-data-readiness

**At a glance:** Assess data readiness for one business task: can the application find authoritative, current evidence while respecting each user's access? Before approving production, require a source register, tests for missing and restricted information, and named owners for updates. Release only the scope that passes, with a safe hand-off when evidence is insufficient.

## The short answer

Your data is ready for a Gen AI application when, for a defined business task, the application can find authoritative, current evidence and respect each user's access. Before approving production, require a source register, tests for missing and restricted information, and named owners for updates. Release only the scope that passes, with a safe hand-off when evidence is insufficient.

---

## Start with the decision the application must support

A CTO should be able to approve a specific workflow without first commissioning a clean-up of every repository. Define whose work the application supports, which questions it may answer and what happens when it cannot answer safely.

Consider an illustrative internal assistant that helps purchasing staff interpret supplier-onboarding policies. It may explain the approved process and show supporting passages; approving a supplier remains a person's responsibility. Its first release might cover one business unit whose policy owner can resolve conflicting documents.

For this use case, ask the team for a source register:

| Record for each source | Decision it enables |
| --- | --- |
| Business owner and authoritative location | Who resolves a disputed rule? |
| Approved version, effective date and scope | Which policy applies to this question? |
| Permitted readers and processing locations | May this content enter this application? |
| Update, withdrawal and deletion path | How does a change reach every derived copy? |
| Covered questions and known gaps | What must the assistant hand off? |

Build this register around the workflow. Microsoft's [RAG preparation guidance](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-preparation-phase) similarly connects business requirements, source analysis and representative questions. A repository's size says little about whether it contains the evidence this task needs.

---

## Check that business meaning survives preparation

A correct policy can still produce a wrong answer if its exception disappears during preparation. Ask the team to demonstrate the journey from an original document to the passages supplied to the model.

Applications using retrieval-augmented generation, or RAG, search selected material and provide the retrieved passages to a language model. Splitting documents into passages can separate information that needs to stay together, as Microsoft's [chunking guidance](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-chunking-phase) explains.

In the illustrative policy, a table might define a standard approval route while a footnote changes that route for a particular supplier category. Losing that exception could send purchasing staff down the wrong approval route, bypass a required review and force them to repeat the onboarding work. Test that category explicitly. Inspect whether the extracted text retains the table headings, the exception and the link back to the approved version.

Ask a business reviewer to compare the original and prepared evidence across the formats you intend to support, including scans where relevant. If one format cannot be processed reliably, exclude it from the first release and explain that boundary to users. Record the resulting manual workload before treating the narrower release as a success.

---

## Prove access and freshness through changes

Information control must survive copying into a search index. In the supplier example, an access failure could expose restricted negotiated terms to staff who should see only the general policy, prompting containment and a review of who received the information. Require the application to exclude unauthorised evidence before supplying context to the model; an instruction asking the model to keep a secret is insufficient as an access control.

Microsoft's [document-access guidance for Azure AI Search](https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview) describes filtering results by user permissions. It also explains that source permission changes appear in indexed results only after the relevant metadata is synchronised. For your chosen architecture, make the propagation behaviour an acceptance test.

Ask for a short evidence pack showing that permitted users receive the right policy, restricted material stays excluded, and withdrawn access and obsolete versions stop being used. Have the team demonstrate this with two identities, an access withdrawal, a policy replacement and a policy withdrawal, inspecting both retrieved passages and answers. Require the agreed hand-off when no valid replacement exists. Include saved responses, caches and other derived copies in the design review, with an explicit decision to bypass, invalidate or exclude them for sensitive content.

Agree how long each kind of change may take to propagate, who monitors failures and which queries must be suspended during a delay. These are workload decisions; a daily refresh may suit one document collection and be unacceptable for another.

---

## Diagnose the failure before funding the fix

The next investment should follow the observed failure. A business owner correcting a policy, an engineer repairing extraction and a team changing model behaviour are different assignments.

![Three checks follow a business question from source evidence through retrieved passages to the final answer, with an owner for each failure.](https://infomover-public-content.s3.ap-south-1.amazonaws.com/prod/infomover/enterprise-gen-ai-data-readiness/437fea903e2b-evidence-checks.svg "Find the failed step before assigning the fix; keep access and update controls across the whole path.")

*Find the failed step before assigning the fix; keep access and update controls across the whole path.*

For each failed test, retain the question, relevant source version, permitted retrieved evidence and answer in an appropriately protected trace. Use this diagnosis:

| Observation | First investigation and owner |
| --- | --- |
| The approved source omits or contradicts the rule | Business owner resolves the content or removes the question from scope. |
| The rule exists, but preparation loses its exception | Data engineer checks extraction and passage boundaries. |
| Prepared evidence is correct, but search misses it | Retrieval engineer checks search, filters and query handling. |
| Correct evidence reaches the model, but the answer adds an unsupported claim | Application owner checks answer generation and hand-off behaviour. |

This is a starting point for investigation. The [Azure Databricks quality guide](https://learn.microsoft.com/en-us/azure/databricks/agents/tutorials/ai-cookbook/quality-overview) explains that retrieval depends on both data preparation and runtime choices. Failures can cross those boundaries.

Also check whether the source itself is correct. An answer can follow an outdated document faithfully and still mislead the user. Microsoft's [evaluation guidance](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-llm-evaluation-phase) treats grounding in supplied evidence and factual correctness as separate considerations.

---

## What this means for your production decision

Ask for a bounded release proposal with three possible outcomes: proceed with the tested scope, narrow it with explicit exclusions, or hold while a named owner resolves the blocking issue.

For the supplier-policy assistant, the acceptance pack should include routine questions, policy exceptions, conflicting versions, unavailable evidence and restricted content. For each case, record the expected source or expected hand-off. Have the business owner agree the quality threshold before reviewing results, and report the costly exceptions separately from the overall score.

For an initial assessment of this one workflow, use five working days and roughly four to six person-days across a business owner, engineer and reviewer as a planning allowance. That assumes a testable prototype, a small source collection and owners who can answer questions promptly. Use the first two days to map sources and agree test cases, the next two to inspect evidence and exercise changes, and the fifth to agree proceed, narrow or hold. This is a proposed assessment budget, not a benchmark or delivery promise; it excludes remediation and release work. Re-estimate if access approvals, scans or policy disputes dominate the task.

Hold release for an unresolved access leak or an untested withdrawal path. A missing low-priority document may instead justify an explicit exclusion, provided users can recognise the gap and reach the responsible team. These are proposed decision criteria, rather than a universal certification of readiness.

Assign ongoing ownership and budget for source corrections, access changes, failed imports and repeated checks after updates. Track the human effort per accepted outcome as well as system quality. If purchasing staff must reopen the policy and recheck every answer, their work includes both using the assistant and verifying it; any time saved drafting an answer may disappear in that second check.

---

## Questions to ask before approving production

- Which approved source supports each important answer, and who can resolve a conflict?
- Can we see an exception survive extraction and retrieval?
- What happens when a user loses access or a policy is withdrawn?
- Which questions must go to a person, and how will users know?
- Who owns the next failed update, and what work stops until it is fixed?

If those answers are unclear, define a consulting engagement around one workflow and its readiness evidence. [Discuss your project](https://infomovertech.com/contact).

## Related

- Consulting: [Gen AI Architecture & Engineering](https://infomovertech.com/services/ai-engineering), [Enterprise AI Adoption](https://infomovertech.com/services/enterprise-ai-adoption)