PRACTICAL GUIDE
Data readiness checklist before connecting AI to your business systems
A practical guide to reviewing sources of truth, quality, permissions, documents, privacy, contradictions and testing before connecting AI to CRM, ERP, email or custom systems.
· IA Empleado
Connecting AI to CRM, ERP, email or document repositories can create substantial value, but it also amplifies existing data problems. An outdated field, duplicate record or contradictory source becomes more than an inconvenience when an automated system starts making decisions or preparing actions from that information. The solution is not to wait until every corporate data source is perfect. It is to define the minimum data set needed by the selected process, prepare that set and establish clear rules for what remains incomplete. This checklist provides a practical way to do that.
01
1. Define the process you are automating first
Do not begin by cleaning databases without an objective. Document what starts the process, what decision is made, which systems are consulted and what outcome is expected. That sequence determines which data are genuinely necessary.
For example, classifying sales requests may require sender, company, product, opportunity and owner; automating invoicing will require entirely different fields. Preparing data without this scope leads to oversized projects that are difficult to justify.
02
2. Create a minimum data inventory
List every field, document or reference used by the process. Mark whether it is required, optional, derived or sensitive. Add where it is stored and which system keeps it current.
This inventory avoids sending unnecessary context to the model and helps design permissions. It also reveals data that currently lives in conversations, personal spreadsheets or informal knowledge and should be structured before automation.
03
3. Assign a source of truth
For every critical value, define which system has authority. Order status may belong to ERP, opportunity state to CRM, incidents to helpdesk and availability to calendar or booking systems. Avoid allowing the agent to blend versions without a rule.
When multiple sources exist, document hierarchy and update timing. If a contradiction cannot be resolved automatically, escalation is the correct outcome. Silently choosing the most convenient value can create errors that are difficult to detect.
04
4. Measure critical-field completeness
Calculate the percentage of records containing each required field. Not every missing value matters equally. A missing address may be irrelevant for email classification and completely block a delivery.
Define thresholds by process. If a critical field is missing too often, the source may need to be fixed before automation. If it happens rarely, the workflow can treat it as an exception and request the missing information.
05
5. Find duplicates and identity conflicts
Duplicate customers, suppliers and products can cause the agent to query or update the wrong record. Review unique identifiers, matching rules and cases where similar names represent different entities.
Do not rely only on textual similarity to merge records. Candidates may be grouped for review, but final changes should follow master-data rules. Fast automation over ambiguous identities can multiply the problem.
06
6. Normalise dates, currencies, phone numbers and categories
Structured fields should reach the agent in consistent formats. Dates, amounts, country codes, statuses, SKUs, identifiers and phone numbers are good candidates for deterministic validation before any reasoning.
Normalisation reduces tokens, ambiguity and errors. It also makes agent outputs easier to write back into systems without improvised conversion. The model can interpret variable input, but persisted data should follow a stable schema.
07
7. Identify stale data
A complete value can still be wrong when it is old. Review modification dates, current catalogues, owners who have left the team, retired products and superseded documents.
Where freshness matters, add a recency rule. For example, policy may require the current version or availability may need a real-time lookup. Not every piece of information should be loaded from a static copy.
08
8. Classify sensitive information
Mark personal data, financial information, credentials, trade secrets, contractual documents and any category requiring special controls. Then decide whether the agent needs full, partial or no access.
Minimisation is one of the strongest security measures. If the process only needs a status and identifier, do not send the entire record. Redaction, tokenisation, pseudonymisation or local processing can reduce exposure.
09
9. Review permissions by system and operation
Define what the agent's technical identity can read, create, modify or delete. Avoid broad scopes for convenience. An integration that only reads orders should not have permission to cancel them.
Also separate agent and user permissions. The fact that a person can access certain information does not necessarily mean every automated process should inherit that access. Sensitive actions may require approval linked to a human identity.
10
10. Organise documents and versions
If AI will query documentation, identify which files are current, which are duplicated and which permissions must be respected. Inconsistent answers often originate from contradictory sources rather than the model.
Retain metadata such as date, version, owner and category. When an answer relies on a policy or contract, exposing the source makes review easier and reduces the risk of using an obsolete document.
11
11. Define what AI may infer
Some processes allow useful inference: likely category, priority, language or intent. Other fields, such as bank account, tax identifier, contractual amount or legal status, should come from a confirmed source.
Label inferences explicitly. A proposal should not become master data merely because the model has high confidence. Decide what threshold allows progress and what requires human validation or another source.
12
12. Design handling for missing values
For each required field, define an action: stop, request information, query another source, apply an authorised default or escalate. This prevents the agent from creatively filling gaps.
Policy can vary by risk. A missing postal code may be requested automatically; a missing bank account should never be invented. Missing-data rules should form part of the process contract.
13
13. Design handling for contradictions
Document what to do when two systems disagree. Some contradictions can be resolved through source hierarchy; others require a person. The workflow should preserve both values and explain the conflict.
Frequent contradictions are a process-quality signal, not merely an AI issue. Record them and fix the cause where possible. Automating around the conflict without improving the source perpetuates data debt.
14
14. Build a representative test set
Include easy cases, boundaries and real exceptions: duplicates, long documents, incomplete records, multiple languages, stale values and unexpected formats. Do not build confidence using only perfect examples.
For each case, define the expected outcome or correct behaviour: answer, propose, reject or escalate. This allows accuracy and regressions to be measured when prompts, models, connectors or rules change.
15
15. Record provenance and transformations
When the system normalises, combines or extracts data, retain enough information to reconstruct the path. It should be possible to know which source produced a value and which transformation occurred before the agent used it.
This traceability supports debugging and auditability. It does not require storing complete sensitive information in logs; references, identifiers and structured events are often enough to investigate an outcome.
16
16. Monitor quality after launch
Data readiness does not end in production. New fields, campaigns, products, integrations and teams continuously change the sources. Measure data-caused exceptions, missing fields, format errors and human corrections.
When a metric deteriorates, determine whether the solution belongs in the source, integration, policy or agent. This cycle turns data quality into a continuous practice and makes additional processes easier to add without repeating a complete cleanup.
TAKEAWAYS
Key ideas
Prepare only the data required by the first process.
Define one source of truth for every critical data type.
Measure completeness, duplicates, staleness and contradictions.
Normalise structured fields before reasoning.
Minimise personal and sensitive data.
Apply least privilege by system and operation.
Separate confirmed facts from inference.
Define explicit rules for missing and contradictory data.
Test with real exceptions, not only clean examples.
Preserve provenance and traceability.
Monitor quality after launch.
Expand scope only when the minimum data set operates reliably.
GO DEEPER
Enterprise AI data readiness: connect business systems without turning imperfect data into automated errors.
A company does not need perfect data to begin using AI, but it does need to know which data is reliable, where each source of truth lives, what information an AI Employee may access and what should happen when a field is missing or two systems disagree. Preparing data for AI automation means organising access, quality, permissions, formats, documents, retention and validation rules before execution capability is granted. The goal is not an endless enterprise-wide cleanup project, but to make the minimum data set required by the first process sufficiently ready.
APPLY IT