Define the process and its minimum required data set.
DATA READINESS FOR AI · DATA QUALITY · ENTERPRISE SYSTEMS
Data readiness for AI: prepare the data your automation needs without amplifying errors.
Data readiness for AI means the workflow knows which information it needs, which system is authoritative, which fields are reliable, what the agent may read or write and what happens when data is missing or systems disagree. It does not require cleaning the entire enterprise before starting. It requires making the minimum data set for the chosen workflow sufficiently reliable, normalising what can be verified, limiting permissions and keeping traceability and human review where inconsistency could cause a consequential action.
Decision-oriented reading
12 sectionsStart with the process, review controls, then move to metrics, related routes and sources.
Connect this topicOperational guide →
01
1. Start with the process and its minimum data set
AI data preparation should begin with a specific process. If the objective is to classify email and update CRM, the workflow may only need sender, customer, opportunity, status and owner. Cleaning the entire commercial, accounting and document history before starting would be expensive and would delay learning.
Define which fields are required, which are optional and which should never reach the agent. This inventory reduces unnecessary context and simplifies testing. When a required value is missing, the workflow needs an explicit response: request information, query another source, use an allowed default or escalate.
02
2. Define the source of truth for each data type
Many companies store the same value in several places. A customer name may exist in CRM, ERP, spreadsheets and email; order status may exist in ecommerce and logistics systems. Before automation, decide which system has authority for each category.
An agent should not resolve important contradictions by choosing the value that appears most likely. If CRM and ERP show different registered addresses, policy should state which source prevails or require review. This hierarchy turns data ambiguity into a verifiable operational rule.
DOES IT FIT YOUR PROCESS?
Move from the idea to a diagnosis of your current operation.
Identify what to automate first, which data the workflow needs and where human control must remain.
03
3. Measure data quality with concrete metrics
Data quality should not be a vague belief that information is 'good enough'. Measure completeness, duplicates, invalid formats, out-of-catalogue values, ownerless records, expired documents and contradictions between sources. These metrics show which problems actually affect the workflow.
Not every defect has the same priority. A missing phone number may be irrelevant to invoicing and critical to customer service. Prioritise quality according to how the data is used. This focuses cleanup investment where inconsistency could produce a wrong answer or failed action.
04
4. Normalise formats before delegating decisions
Dates, currencies, identifiers, phone numbers, countries, statuses and categories should follow defined formats. AI can interpret variation, but continuously using it to repair structured data increases cost and makes the process less reproducible.
Whenever possible, normalise in the integration layer. For example, map different statuses into a common catalogue and validate amounts before passing them to the model. AI then receives cleaner context and can focus on what genuinely requires interpretation.
05
5. Separate confirmed data from inference
A model may infer that an email belongs to a customer or that a document appears to match a category, but that inference should not be stored as fact without its origin being clear. Business systems need to distinguish confirmed, proposed and pending-review values.
This separation allows automation without contaminating master data. A proposal can help complete a draft or prioritise a queue, while the final write into CRM or ERP occurs only when a rule or person validates the value.
VALIDATE THE IMPACT
Before expanding automation, calculate whether volume and time justify a pilot.
Compare current manual work with an automated scenario and use that baseline to decide the next step.
06
6. Design read and write permissions by field or action
Connecting AI to a system does not mean granting full access. An AI Employee may need to read orders but not change prices, view one customer record without exporting the entire database, or create a draft without being allowed to send it automatically.
Least privilege should apply to data as well. The smaller the accessible set, the easier it is to demonstrate governance and limit the impact of an error. Permissions can expand later when a specific need exists and metrics justify the capability.
07
7. Classify personal, confidential and sensitive data
Before deciding what information may enter a prompt or leave for an external provider, identify sensitive categories: personal data, financial information, credentials, trade secrets, contracts or regulated information. They do not all require the same treatment.
The workflow can minimise context, redact fields, use identifiers instead of full content or keep selected operations in private infrastructure. Data readiness includes deciding where each category may travel, how long it is retained and who may access it.
08
8. Prepare documents for retrieval and extraction
Policies, manuals, contracts, records and procedures often contain knowledge the agent needs. Uploading entire folders is not enough: current versions, duplicates, permissions and obsolete documents must be identified. A knowledge base can answer badly even with a strong model when the underlying source is outdated.
For document extraction, define file types, expected fields, validation and rules for unreadable or incomplete content. Extracted data should retain a reference to the original document so a person can quickly verify anything with meaningful impact.
09
9. Design rules for missing or contradictory data
Real-world data will always contain gaps. Architecture must decide what can continue without a field, what value may use a fallback and what forces the process to stop. Asking a model to fill what it does not know is a poor strategy when the value affects a real action.
Contradictions also need handling. If a customer appears active in CRM but blocked in ERP, the agent should follow a documented business rule. When no rule exists, escalating with full context is better than improvising.
10
10. Record provenance, version and traceability
When a decision depends on data, it should be possible to reconstruct where the information came from. Record the source system, identifier, document version or retrieval time where relevant. This makes errors easier to investigate and avoids later uncertainty about what the agent actually saw.
Traceability does not mean copying all data into logs. It is better to retain references and enough events to reconstruct the workflow while minimising sensitive content. A useful record shows which source was queried, which validation ran, which approval existed and what result was produced.
11
11. Test with a representative data set before production
Tests should include normal cases as well as duplicates, missing fields, unusual characters, long documents, different languages, old values and contradictions. A pilot using only clean examples does not reveal how the system will behave with real data.
Measure accuracy by case type. A global average may look strong while a critical category fails frequently. Test results help refine normalisation, rules, permissions and escalation before autonomy is granted.
12
12. Make data readiness a continuous practice
Quality changes after launch. New products, fields, suppliers, teams and policies modify the sources. Completeness, duplicates, integration errors and data-related exceptions should therefore be monitored continuously.
Each new process should review its own minimum data set. The organisation can reuse catalogues, controls and connectors, but should not assume that readiness for one use case means readiness for every use case. AI data readiness becomes an operational capability rather than a one-time project.
DESIGN A PILOT
Turn these rules into a controlled pilot with your data, systems and owners.
We can define scope, integrations, human approvals and the metrics that will show whether automation should expand.
WORKFLOW
Data readiness checklist before connecting an AI Employee
Assign a source of truth to each critical value.
Measure completeness, duplicates, formats and contradictions.
Normalise structured fields in the integration layer.
Classify personal, confidential and sensitive data.
Configure minimum read and write permissions.
Define rules for missing, inconsistent or inferred values.
Test with representative cases and real exceptions.
Record provenance and decisions without duplicating sensitive data.
Monitor quality and exceptions after launch.
METRICS
What to measure
Critical-field completeness
Duplicate rate
Format errors
Cross-source contradictions
Data-caused exceptions
Percentage of corrected inferences
Ownerless records
Data-incident resolution time
RELATED GUIDE
How to prepare data for AI: a practical data-quality checklist before connecting business systems
A practical checklist for preparing the data used by the workflow you want to automate without turning readiness into an endless enterprise-wide cleanup project.
TOPIC CONNECTIONS
Explore related product roles, use cases and integrations.
FAQ
Frequently asked questions
Do I need to clean all company data before using AI?
No. Prepare the minimum data set required by the selected process first. Cleaning the entire company before a pilot usually delays learning without immediate value.
What is a source of truth?
It is the system or repository with authority for a specific data type. For example, ERP may be the source of truth for order status and CRM for the sales owner.
Can AI fill missing data?
It can propose an inference in allowed cases, but it should remain marked as a proposal. Critical data should not become fact or trigger actions without a verifiable source or validation.
Which data should an AI Employee not see?
Any data not required for the process. Especially sensitive information may also require redaction, local processing, specific controls or complete exclusion depending on the case.
How should documents be prepared for AI?
Identify current versions, remove duplicates, preserve permissions, define document types and retain references to originals. For extraction, validate critical fields after automated reading.
How do I know whether my data is ready enough?
When the process's minimum data set has clear sources, defined permissions, measurable quality, rules for gaps and contradictions, and representative tests showing an acceptable error rate.
NEXT STEP
Turn this approach into a concrete proposal for your business.
We review the process, required integrations and the scope of a first pilot with you before proposing a broader implementation.