AI data readiness becomes a business problem the moment an assistant finds two refund policies and cannot tell which one applies. Consider a hypothetical Indian distributor testing a support assistant. Its shared drive holds an old policy, a newer policy, and a customer-specific exception in a sales email.
The demo answers routine questions well. However, a customer asks about an exception, and the assistant uses the wrong rule. Before changing the model, the team needs to examine what information it supplied.
Data infrastructure includes the systems and processes that store, move, protect, and update business information. For an AI pilot, the aim is to give the system the right evidence for a defined task. Buying more storage alone will not settle which policy is current.
Our enterprise AI guide explains how to choose a task before choosing a tool. Once that task is clear, use these five checks to decide whether its data is ready.
1. Define AI data readiness for one task
Start with the questions the system must answer. For example, the distributor might limit its pilot to standard return requests for one product range. That scope gives the team a clear way to choose source material.
List the records each answer needs. A return query may require the order date, product code, applicable policy, and approval limits. Customer payment details may add no value to that task, so leave them out of the pilot.
Next, name the system that holds the authoritative record for each item. An order system may own purchase dates, while the support team owns published return rules. If two sources disagree, establish who resolves the conflict before the assistant uses either.
Assess AI data readiness by business area. Clean order records do not prove that return policies are equally reliable. You do not need to clean every company file before a narrow pilot, but each source you use needs an owner.
2. Check meaning as well as missing fields
A spreadsheet can contain no empty cells and still mislead the system. For instance, one branch may record sales in rupees while another records them in thousands. Both columns might carry the same label.
Check units, date formats, identifiers, and business definitions against real examples. Does “delivery date” mean planned dispatch or confirmed receipt? Can the team link a customer record to the right order without relying on a name alone?
Documents need similar care. Keep effective dates, product scope, and exceptions attached to the relevant rules. Otherwise, an extracted paragraph may lose the condition that makes it valid.
This matters when using retrieval-augmented generation, or RAG. In this approach, the system retrieves source material to help a model answer a question. MongoDB’s technical-document architecture illustrates why document structure and context matter during retrieval. Retrieval can supply evidence; it does not guarantee a correct answer.
3. Test access before connecting more sources
An assistant should not expose a document merely because the account it uses to connect to other systems can read it. Decide which users may access each source, then check that the AI application enforces those limits.
For the distributor, a support agent may need standard return rules but not a confidential pricing agreement. Therefore, test the same question through accounts with different roles. Check that each account retrieves only the evidence its user may access.
AWS’s reference design for secure RAG demonstrates document-level permission checks during retrieval. Enforce permissions in the application before passing evidence to the model. A prompt asking the model to keep a secret cannot replace these controls.
Also inspect copies made for search, testing, and logging. A secure source folder is not enough if a later export loses its access restrictions. Ask who can read those copies and how the team removes them when access changes.
4. Give AI data readiness an update owner
A pilot can pass its first test and fail after a policy changes. Set a refresh rule for each source based on how quickly outdated information could cause harm.
For example, an order-status query may need a current system lookup. A product guide may change less often. The business owner should define acceptable delay; the technical team should show how it detects a failed update.
Separate accountability from daily upkeep. The business owner decides whether the data is fit for the task. A named steward handles checks, resolves routine defects, and raises issues that need the owner’s decision.
Record the team’s agreement on field definitions, quality checks, update timing, and change alerts. This is a data contract: a shared set of expectations between the team supplying data and the team using it. It gives both teams a clear response when a feed breaks.
Track the source versions used in each answer where practical. This trace, called data lineage, helps the team work back from an answer to its inputs. Then test a policy change: can the assistant find the new rule, stop using the old one, and cite the correct source?
Include deletions and withdrawn documents in this test. Adding new information is only part of maintenance. If the team cannot reliably withdraw an obsolete rule, keep the affected questions outside the pilot.
5. Run an AI data readiness test with difficult cases
Build a small test set with staff who handle the work. Include routine questions, conflicting records, missing facts, and requests for restricted information. Keep some cases separate from those used to tune the system.
For each case, record the expected evidence and acceptable response. Sometimes the correct response is to ask for an order number or refer the case to a person. A confident answer is not always a successful answer.
Measure whether the system finds the right source and whether its answer matches that source. Also track outdated evidence, access failures, and the time staff spend checking replies. These checks help distinguish a retrieval problem from a writing problem.
Before the pilot begins, agree on release conditions and who can stop it. Any confirmed disclosure of restricted information should trigger investigation before wider use. Set other thresholds to match the task’s risk. For example, test whether the assistant escalates a refund exception that requires a manager’s approval.
The distributor’s next step is a bounded pilot with named source owners, tested permissions, and an update process. If one check fails, fix that part of the data flow before adding more users. For the wider oversight decisions, read our responsible AI governance guide.
