Data before agents: what to check before AI can act

An AI agent can read information, propose a response, and take an action. Each step raises the cost of using the wrong data. Before choosing an agent, decide which source it may use, what each field means, what permissions it has, and when it must ask a person for help.

This distinction is familiar from my work with data and operations in Latin America. A demo can join hand-prepared tables and produce a convincing answer. In daily operations, sources change, teams use different definitions, and some cases do not fit the rule. The data work determines whether the system can handle them.

McKinsey's analysis of AI data readiness argues that scaling requires reliable, traceable, governed information, both structured and unstructured. Its qualification matters: companies need not wait for perfect data, but should define what quality is good enough for each use case and its risks. Here is how I would apply that idea to a pilot.

Define the action before choosing the agent

“We need agents for sales” leaves too many questions unanswered. “We want to prepare a weekly list of accounts that need follow-up, for a person to review before contacting them” defines an output, a frequency, and a human control.

Separate the work into three levels:

1. Read and summarize. The system gathers background information and shows its sources. When it makes a mistake, a person can still check the source.
2. Recommend. It prioritizes or drafts a proposal. The team needs to record the criteria and how a poor recommendation is corrected.
3. Act. It sends a message, changes a price, or updates a record. An error can now affect someone outside the team; permissions and stop conditions must be explicit.

Not every use case needs to reach the third level. If preparing information removes the main delay, that may be the best first version. My guide to moving an AI pilot into operations explains how to choose the decision and measure whether the work changed.

Five data questions to ask before a pilot

You do not need to rebuild the entire data architecture. Take one real use case and check these points with the process owner:

• Which source is authoritative? Identify the system, document, or table that wins when two figures disagree.
• What does each field mean? Agree on the definition of a date, status, currency, customer, or metric across the teams that will use it.
• When is it updated? Set an expected refresh frequency and show when information is missing or stale.
• Who may see or change it? Give the agent specific permissions and assign a person to approve changes that affect others.
• Can you reconstruct an answer? Keep the source and version used, the result produced, and any correction made after an error.

A missing answer does not automatically mean “the company is not ready for AI.” Narrow the scope: use a controlled source, limit the agent to reading, and record exceptions. Summarizing a meeting and changing a quote do not require the same quality threshold.

An example of the less visible layer

The WBR dashboard I built brings sales, operations, and targets into one view so a weekly review can start from a shared understanding of deviations. It is not an agent. It does show an important prerequisite: before asking a system to explain or act on a metric, the team must agree on its definition and work from a consistent base.

Imagine, as a hypothetical example, two countries recording “weekly sales” with different time cutoffs or currencies. An agent could calculate a variation perfectly on an invalid comparison. A better prompt alone will not fix that; the team must define the cutoff, conversion, and owner who validates the figure before it drives a decision.

Documents create a similar problem. If a policy changes, the system must distinguish the current version from the previous one and show which it consulted. Making a file searchable does not guarantee that its content is correct for an action.

A careful sequence for granting permissions

For a pilot, I would start with a small set of real cases and a person who knows the process:

1. Establish a baseline. How long does the decision take today, and how many corrections does it need?
2. Run in read-only mode. Show sources, the proposed answer, and missing data without writing to operational systems.
3. Review disagreements. Classify whether the problem came from the source, definition, retrieval, or model proposal.
4. Allow one bounded action. After a person has reviewed repeated results, define what the system may do and what needs approval.
5. Measure use and errors. Compare eligible cases, time to decision, corrections, and exceptions against the baseline.

The exit criterion should not be that the demo “worked.” It should be that the workflow produces a useful result in real cases, lets the team see why, and has someone accountable when it fails. Then expanding the scope makes sense. Otherwise, the unfinished work may be in the data or process rather than a more sophisticated agent.