PRACTICAL 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.
· IA Empleado
Preparing data for AI does not mean fixing every enterprise record. It means identifying the workflow to automate, defining its minimum data set, assigning sources of truth, measuring completeness and duplicates, normalising formats, limiting permissions and designing rules for missing or contradictory values. This guide focuses on that practical work. The data-readiness landing retains the evaluation intent; this article explains how to prepare and test the data set before an agent receives operational capability.
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
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.
APPLY IT