AI Implementation Data Readiness Checklist: What to Fix Before Build

AI Implementation Data Readiness Checklist: What to Fix Before Build

AI implementation fails when the workflow is ready but the operating data is not. Before a company builds an agent, automation, or AI workflow, it should prove that the source data is owned, current, permissioned, and mapped to the decision the AI system is expected to support.

Most AI projects do not stall because the model is weak. They stall because the business cannot answer basic questions about the data feeding the system. Which record is the source of truth? Who is allowed to change it? What happens when two systems disagree? Which fields are optional in the app but mandatory for the workflow?

This checklist is for operators preparing a real AI implementation, not a demo. Use it before scoping an AI agent, workflow automation, lead qualification system, customer service assistant, or internal knowledge tool.

1. Name the decision the AI system must support

Do not begin with every dataset the company owns. Begin with the operating decision.

Good decision statements sound like this:

• Decide whether a new lead should be routed to sales, nurture, or ignored.
• Decide which support tickets need escalation before the SLA is missed.
• Decide whether an invoice exception needs finance review.
• Decide which customer account needs a renewal action this week.

Weak decision statements sound like this:

• Use our CRM data.
• Analyze customer information.
• Automate reporting.
• Add AI to operations.

A decision statement keeps the data review honest. If a field does not change the decision, it may not belong in the first version.

2. Identify the source of truth for each critical field

Every AI workflow has fields it cannot safely guess. For a lead routing workflow, those fields might be company size, budget signal, region, requested service, and last human touch. For a support workflow, they might be customer tier, product area, open incidents, contract SLA, and previous escalation history.

For each critical field, write down:

• System of record
• Field name
• Owner
• Update frequency
• Allowed values
• Known failure pattern

The owner matters. If nobody owns a field, the AI system will inherit drift. A stale lifecycle stage, wrong account owner, or missing contract flag can create confident but incorrect actions.

3. Check whether the data is current enough for the workflow

AI readiness is not only about whether data exists. It is about whether the data is fresh enough for the action.

A weekly finance report may tolerate yesterday's data. A lead routing agent cannot. A customer support escalation workflow may need contract and incident data that is updated within minutes.

Set a freshness requirement for every input:

• Real time
• Hourly
• Daily
• Weekly
• Manual before review

Then compare that requirement to the actual update pattern. If a field is updated by humans once a week but the workflow will act daily, do not hide that gap inside the AI scope. Fix the operating process first or reduce the action the system is allowed to take.

4. Map permissions before connecting tools

A safe AI implementation needs a permission model before integrations start.

Ask four questions for every source system:

1. Who can read the data?
2. Who can write or update the data?
3. Which records should the AI system never expose to some users?
4. Which actions require human approval?

This is where many internal AI pilots become risky. A chatbot connected to documents, CRM records, support tickets, and finance exports may answer correctly while exposing information to the wrong person. The risk is not only hallucination. It is unauthorized retrieval.

The first version should use the narrowest access needed to complete the workflow. Broad admin access is convenient during a prototype and dangerous in production.

5. Find duplicates and conflict rules

Most business data has conflicts. The CRM says one owner. The billing system says another. A spreadsheet has an old price. A support ticket has the latest customer complaint.

AI systems need conflict rules. Without them, the system may blend records and create a plausible answer that nobody can audit.

Write conflict rules in plain language:

• Billing status comes from the billing system, not the CRM.
• Contract SLA comes from the signed contract record, not the account notes.
• Latest support severity comes from the incident system, not email summaries.
• Account owner comes from CRM unless the implementation tracker has an active handoff.

The goal is not perfect data. The goal is predictable resolution when data is messy.

6. Define minimum viable data quality

A data readiness checklist should not become a six month cleanup project. Define the minimum quality threshold needed for the first production workflow.

Useful thresholds include:

• 95 percent of target records have the mandatory fields filled.
• No critical field has more than one active source of truth.
• Every automated action has a visible source record.
• High-risk actions require human approval until error rates are known.
• Exceptions are routed to a named owner, not a shared inbox.

This lets the team move without pretending the database is perfect.

7. Create an audit trail for AI-assisted actions

Any AI system that changes work queues, drafts messages, routes leads, updates records, or recommends decisions needs an audit trail.

At minimum, log:

• Input records used
• Output generated
• Confidence or rule path where available
• User who approved or rejected the action
• Final action taken
• Timestamp

Audit trails are not bureaucracy. They are how operators debug the workflow when a customer asks why something happened. They also create training data for improving the next version.

8. Decide what the AI system is not allowed to do

Data readiness includes boundaries. Before build starts, define prohibited actions.

Examples:

• Do not update contract terms.
• Do not send customer-facing messages without approval.
• Do not change billing status.
• Do not override security or access rules.
• Do not use fields marked as manually verified until the verifier is named.

Clear limits make production safer and make the first build easier to test.

A practical readiness score

Score each workflow from 0 to 2 on seven areas:

1. Decision clarity
2. Source of truth
3. Data freshness
4. Permission model
5. Conflict rules
6. Minimum field completion
7. Audit trail

A score of 12 to 14 means the workflow is ready for implementation planning. A score of 8 to 11 means build can begin only with limited actions and human approval. Below 8 means the project needs operating cleanup before AI work starts.

What to do next

Pick one workflow, not the whole company. Write the decision statement, list the critical fields, and mark each field as ready, questionable, or blocked. If more than two critical fields are blocked, the next task is not model selection. It is data ownership and process cleanup.

TWOHUNDRED builds AI systems around workflows that can survive production. The useful first move is not adding more AI. It is proving that the data behind the workflow is trustworthy enough to act on.