“Fix the data first” sounds like responsible advice.
Every company has reasons to believe it. Customer records are duplicated. Required fields are empty. Permissions reflect an organization chart from three years ago. The CRM, billing platform, contract repository, and support system all use different identifiers for the same company.
So the safe sequence appears obvious.
Clean the data. Standardize the systems. Resolve the ownership. Then deploy AI.
It is also how many AI programmes disappear into a multi-year transformation before one useful workflow reaches production.
The problem is not that data quality is unimportant.
The problem is that “the data” has no natural boundary.
Start With One Decision
The first question should not be, “Is our data ready for AI?”
It should be narrower.
What is this system allowed to decide?
Name one decision.
A quote may be approved below a threshold. A claim may be routed to a specialist team. An invoice may be held before payment. A customer credit exception may be recommended to a manager. A service ticket may be assigned to a field technician.
Each of those decisions has an edge.
We can identify its owner. We can describe the evidence it needs. We can define which systems are authoritative. We can decide whether AI advises, acts, or stays out. We can name the approval point, the write-back target, and the exception path.
Once authority has a boundary, the data work gets one too.
The scope of the cleanup follows the scope of the authority.
Data Quality Is Always for Something
Data is not simply clean or dirty.
It is fit or unfit for a particular action.
A missing marketing preference may not affect a credit decision. A missing legal-entity identifier can make the same decision unsafe. An address may be good enough for correspondence and insufficient for determining tax treatment. A payment status that is one day old may be acceptable for weekly reporting and too stale for releasing a large order.
The same record can therefore be usable in one workflow and dangerous in another.
Enterprise-wide data programmes often hide this distinction. They create general completeness targets, duplicate-reduction targets, and quality scores without connecting them to the decision that makes a missing field expensive.
A bounded workflow creates a stronger test.
Can the system identify the correct legal entity?
Can it retrieve current exposure from the authoritative source?
Can it distinguish a posted payment from a promised payment?
Can it tell which contract terms are currently active?
Can it produce enough evidence for the approving person to understand the recommendation?
Now data quality has an operational meaning.
Authority Defines the Required Context
Consider a customer credit exception.
The organization may hold hundreds of fields about the customer across several systems. The agent does not need all of them. It may need the legal entity, current balance, overdue amount, credit limit, payment status, active disputes, and the policy threshold for escalation.
Those fields need sources of truth.
The legal entity may come from the contract system. The balance may come from accounts receivable. The credit limit may come from the ERP. The active dispute may live in a service platform. The policy threshold may be a versioned procedure approved by finance.
The agent also needs an action boundary.
Below one threshold, perhaps it may recommend approval. Above that threshold, perhaps it may only assemble evidence and route the case. If an active dispute exists, perhaps the normal path must stop. If two systems disagree on the legal entity, perhaps no recommendation should be generated at all.
That is a real implementation map.
It tells the data team what must be reconciled. It tells security which records the agent may read. It tells operations which person owns the exception. It tells engineering what must be written back and what evidence belongs in the audit trail.
Without the decision boundary, every data problem looks equally urgent.
With it, priority becomes visible.
Permission Is Part of Data Readiness
Many readiness programmes treat permissions as a security workstream that arrives after the data has been prepared.
For agents, permission is part of the data definition.
A record is not ready merely because it is complete and current. The system must know whether this agent, acting for this person, in this workflow state, may read it and what action may follow.
Read is not write.
Suggest is not approve.
A normal case is not an exception.
An agent handling a customer credit request should not inherit a broad service account that can update every customer record. Its credential should be short-lived, limited to the exact tools, records, and actions required for the task, attributable to a sponsoring person or business owner, and revocable without dismantling the workflow.
This is where governance becomes operational.
Frameworks such as SAIL 2.0 catalog dozens of agent-specific risks across the lifecycle, including memory poisoning, delegated authority, tool misuse, and agent decommissioning. That mapping is useful, but a framework still has to reach the Monday-morning workflow.
Who can the agent act for?
What may it decide?
Which data may it use?
What must it never change?
Where does it stop?
The Approval Point Is Not a Human-Shaped Decoration
Adding a human reviewer does not automatically make an AI workflow safe.
The reviewer needs the right evidence, at the right moment, with enough time and authority to challenge the system.
If the agent presents only a conclusion, the human may become a rubber stamp. If it presents every raw field and document, the reviewer may be buried in context. If the review queue grows faster than the team can process it, automation has only moved the bottleneck.
A bounded decision lets us design the review deliberately.
The system can present the recommendation, the source values, the policy rule, the uncertainty, and any exception that changed the normal path. The reviewer can accept, reject, or return the case with a reason. That outcome becomes evidence for improving the workflow without allowing the model to rewrite the rules silently.
The human decision remains accountable.
The system’s contribution remains inspectable.
Write-Back Is Where the Process Becomes Real
Many AI pilots end with an answer on a screen.
Operations begin after that.
If a claim was routed, did it enter the correct queue? If an invoice was held, did the ERP record the hold and its reason? If a quote was approved, did the customer-facing system receive the decision? If a reviewer changed the recommendation, was the correction attached to the case?
The write-back target is part of the decision boundary.
Without it, the AI produces commentary beside the process. Someone still copies the output, updates the system, sends the message, and remembers which queue should move next.
That manual bridge hides errors and destroys auditability.
A production workflow needs completion criteria. It needs to know whether the action reached the system of record, whether downstream checks passed, and whether the case is now closed or waiting for an exception owner.
That is why defining one decision is more useful than declaring the enterprise data ready.
The decision reveals the whole path.
Exceptions Determine the Real Scope
Normal flow is usually easy to automate.
The scope becomes clear when the case does not fit.
What happens when the customer identifier matches two legal entities? When the invoice total differs from the purchase order? When the policy changed yesterday but the cached procedure did not? When the requested action is above the agent’s authority? When the source system is unavailable?
Those are not edge cases to postpone until after launch.
They are the cases that define where automation must stop.
For each exception, the workflow needs an owner, an escalation destination, a record of what failed, and a way to continue the business without inventing authority for the agent.
The data required for exception handling may be different from the data required for normal flow. That is another reason not to begin with a generic cleanup. The workflow tells us which contradictions, absences, and stale values actually matter.
Let Business Value Pay for the Next Cleanup
The most practical advantage of the bounded approach is financial.
An enterprise-wide cleanup consumes budget before it produces a visible operating result. A decision-sized implementation can create value earlier, then fund the next boundary.
Clean the fields needed for one credit decision. Put the workflow into production. Measure completion, exceptions, correction rate, and cost per accepted outcome. Then expand to the next decision with evidence about what worked.
The company still improves its data.
It improves it in the order the business can pay for.
Over time, shared entities, definitions, and controls can become reusable foundations. The legal-entity mapping built for credit may support contracting. The identity model built for invoice approval may support procurement. The audit pattern built for claims may support customer service exceptions.
The architecture grows from working boundaries rather than from an abstract promise that everything will eventually be clean.
Data Readiness Needs an End Condition
“Fix the data first” fails because nobody can say when first is finished.
A decision boundary gives the programme an end condition.
The required sources are named.
The fields are defined.
The permissions are explicit.
The approval path is tested.
The write-back completes.
The exception has an owner.
The evidence can be inspected afterward.
That is enough to ship one governed workflow. It is not a declaration that the enterprise has solved data quality forever.
It is something more useful.
A working boundary.
If someone asked today what your agents are not allowed to decide, would that be written down anywhere, or is the whole control model still living in the word “understood”?