AI Reality Checks #18 · Part of Binary and Beyond. LinkedIn newsletter edition follows.
A competent analyst can survive bad data.
They see a stale last_contacted field and ask someone in Slack. They notice that "active" means something different in the portal than in billing, and they adjust the slide. They leave a note in the margin: "treat this cohort carefully." The spreadsheet still ships. The meeting still happens. The organisation limps forward on judgment, context, and hallway questions.
That is not a bug in the people. It is how most enterprises have always absorbed ambiguity.
AI workflows do not absorb ambiguity that way.
They read the field. They treat the label as settled. They draft, score, route, and write back without the social layer that used to catch the mismatch. What was "good enough for the spreadsheet" becomes policy at machine speed.
The usual pitch says AI will tolerate imperfect data because models are flexible.
In production, the opposite is true.
AI needs better data than humans do. Cleaner definitions. Stronger contracts. Fresher fields. Explicit ownership. Not because the model is precious, but because the human workaround is gone.
The report that was "fine" until nothing was
Picture a mid-market manufacturer with a dealer portal, an ERP, and a CRM that have not agreed on inventory language for years.
available_qty in the portal means sellable on the website tonight. In the ERP export, the same-looking number often includes stock reserved for wholesale holds. CS uses a third sheet that subtracts open RMA lines by hand. Everyone knows this. Nobody wrote it down as a contract. Analysts reconcile on Fridays. Dealers get answers that are "close enough" because a human can say "let me check the warehouse."
Leadership funds an AI assistant for dealer support: answer stock questions, draft order notes, flag accounts that look at risk of stockout. The training set is last year's tickets. The eval looks fine because the tickets already contain human-resolved language.
Then the assistant goes live (labeled fictional scenario, not a case study).
A dealer asks whether forty units of SKU-4412 can ship Monday. The model reads portal available_qty of 52, drafts a confident yes, and logs a promise-shaped note on the account. Warehouse holds had already reserved thirty of those units. A human CS lead would have opened the ERP tab, or pinged ops, or hedged. The model had no hallway. It had a field.
The failure is not that the data was "garbage" in the dramatic sense.
The data was good enough for humans who knew which clock to distrust.
It was not good enough for automated decisions that treat a column as truth.
AI Reality Checks #17 argued that messy definitions become expensive once generation scales and writes back. This essay is the complementary point: even when the organisation has already decided that the data is "usable," AI often needs a higher bar than the humans who were using it.
What humans do that models cannot
People are poor databases and excellent patch layers.
When a field is wrong, a senior operator does several things a model will not:
Detect unease. A number that "feels off" for this account triggers a second look. Models do not feel off. They complete the pattern.
Ask the room. "Is this the portal qty or the ERP qty?" is a one-message fix. Models do not send that message unless you built the tool, the permission, and the escalation path.
Carry tribal exceptions. "Ignore West region stages after the Q2 rename" lives in memory. It rarely lives in a schema description the agent will read.
Refuse politely. A human can say "I don't know yet" and buy time. Many AI paths are designed to always produce an answer, which turns uncertainty into fluent fiction.
Repair socially. After a bad call, a person apologises and rebuilds trust. An agent that mass-updated fifty accounts leaves a forensic trail without a relationship.
None of this means humans are magically accurate.
It means human-operated processes were designed around humans as the consistency layer. Spreadsheets, CRM notes, and weekly reports assume someone will notice when two systems disagree. Production Notes #03 already argued that truth is owned, not shared. Ownership used to include a person who could be interrupted.
Remove that person from the hot path and the same data quality suddenly looks like negligence.
The bar moved. Most programmes did not.
Teams often set "AI-ready data" as a volume and connectivity problem: more history, more connectors, denser embeddings.
Those help retrieval. They do not raise the operational bar.
What raises the bar is the shift from interpretive consumption to automated commitment.
| Dimension | Good enough for a human analyst | Required for an AI workflow |
|---|---|---|
| Field meaning | Implied; ask a colleague if unsure | Named in one sentence; null defined |
| Freshness | "Recent enough for the weekly deck" | Explicit max age per decision type |
| Conflict | Human picks a source in the moment | Authority map before the agent runs |
| Exceptions | Held in Slack and memory | Encoded as rules, flags, or out-of-scope |
| Uncertainty | Hedge in prose or delay the answer | Escalation path, not forced completion |
| Side effects | Person owns the email they send | Validation before write-back or outbound |
| Drift | Noticed in the next meeting | Monitored like an API contract break |
That table is the whole essay in one place.
Humans needed data that was navigable.
Models need data that is decidable.
Architecture Files #13 made the case that an API without a data contract is a suggestion. AI is the consumer that stops politely ignoring suggestions. It invents a reading and proceeds. If your contract was "we'll clarify in standup," you do not have a contract that can survive an agent.
Why "the model is flexible" is the wrong comfort
Flexibility in a language model is not the same as robustness to contested enterprise state.
A model can paraphrase a messy note into clean prose. That looks like forgiveness. It is compression. Compression without authority turns ambiguity into a single narrative that travels farther than the underlying disagreement (AI Reality Checks #16). The complexity did not leave. It left the analyst's head and entered the paragraph executives will quote.
Teams also comfort themselves with "we'll keep a human in the loop."
Human-in-the-loop is real governance when the human has time, context, and a clear veto. It becomes theatre when the queue is thousands of drafts a day and the reviewer only spot-checks fluency. At that point you have reintroduced the human as a bottleneck without restoring the human as a data patch layer. The model still needed decidable inputs. You only slowed the blast radius.
Another wrong comfort: "our data was good enough for BI, so it is good enough for AI."
BI mostly produces decisions in rooms. AI workflows produce decisions in systems. A wrong cohort in a dashboard is embarrassing. A wrong cohort in an automated sequence, a pricing suggestion, or a stock promise is operational. The same CSV can be acceptable for one and catastrophic for the other.
Where the higher bar actually shows up
I keep seeing the same four gaps when a programme tries to put generation on top of "working" enterprise data.
1. Freshness that humans papered over.
An analyst knew the ERP lag was fifteen minutes on Mondays and waited. An agent answers now. If freshness is not a first-class field attribute, "available" is a coin flip wearing a number.
2. Nulls that meant three different things.
Empty churn_risk meant "not scored yet" to CS and "low risk" to a rushed dashboard. Humans argued it out. Models need a single reading, or an explicit "unknown → escalate" path.
3. Soft enums and overloaded statuses.
Stage names that drifted after a UI rename, or active that covers trials, paid seats, and grace periods. Humans remembered the politics. Agents treat the string as ontology.
4. Write paths that assume read-quality data.
Summarising a messy account is one risk class. Updating the account from that summary is another. If the inputs were only good enough for a human to narrate carefully, they are not good enough for an agent to mutate.
None of these require perfect data lakes.
They require admitting that the spreadsheet standard was never the automation standard. It was the standard for people who could still ask questions.
What to raise before you scale the agent
Use this checklist when someone says the data is "fine" because analysts already use it.
- List decisions the agent may make or imply. Promises to customers, money movement, record updates, routing that changes SLA. If a decision needs a hallway question today, it needs a contract or an escalation before it is automated.
- For every field that feeds those decisions, write the human workaround. Who do people ask? Which tab do they open second? What do they ignore? That workaround is the missing product requirement.
- Replace each workaround with a rule, an authority, or an out-of-scope. "Ask ops" becomes a tool call with an owner, or the agent must refuse. Do not leave "ask ops" as folklore.
- Set freshness budgets per decision. Stock promises, credit decisions, and weekly summaries do not share a clock. Encode the max age. Stale should block action, not inspire confident prose.
- Define unknown as a first-class outcome. Prefer escalate / defer / ask over invent. If the UI only rewards a complete answer, you trained the system to lie politely.
- Separate narrative assistants from commitment agents. Reading and drafting with citations is a different bar from writing fields or sending external language. Promote only after the decidability bar is met.
- Run a "human would have asked" drill. Take twenty historical tickets or analyses where a person hesitated. If the agent would not hesitate on the same inputs, you are not ready.
- Name who owns raising the bar. Data quality for AI is not a one-time cleanse. It is contract maintenance under change, the same discipline as any load-bearing integration.
If the checklist feels like more work than the model integration, believe that feeling. The integration was never the scarce resource. Decidable meaning was.
AI raises the bar. It does not lower it.
Vendors sometimes imply that smarter models reduce the need for clean inputs.
Smarter models reduce the need for brittle string matching. They do not reduce the need for owned definitions, freshness rules, and authority under conflict. If anything, better fluency raises the cost of being wrong, because the wrong answer looks finished.
AI Reality Checks #17 is about amplification and ownership: garbage scaled by generation becomes a million-dollar problem. The companion truth is comparative: the quality threshold for safe automation sits above the quality threshold for competent human analysis.
Humans could work around messy data with context, judgment, and hallway questions.
Models cannot.
They need cleaner definitions, stronger contracts, fresher fields, and explicit ownership than a competent analyst required. "Good enough for the spreadsheet" is not good enough for automated decisions at scale.
When we help teams put AI into production workflows, the early conversations are rarely about model choice. They are about which fields are decidable today, which still depend on a person who "just knows," and which decisions must stay human until the contract catches up.
That is not anti-AI.
It is respect for what the humans were quietly doing all along.
Raise the inputs, or keep the diplomat
You can keep humans as the patch layer and use AI for drafts behind a narrow scope.
Or you can remove the diplomat and keep the database. Then the database has to earn a higher grade than it needed for Friday's deck.
What you cannot do honestly is delete the hallway questions and keep the same data bar.
The model will not call the person who just knows.
It will call the field.
Make the field worthy of that trust, or do not automate the decision.
AI raises the data bar; it does not lower it.
Related reading
- Garbage In, Garbage Out Is Now a Million-Dollar Problem: amplification, ownership, and validation before write-back
- AI Doesn't Eliminate Complexity. It Moves It.: where the hard work goes after the demo
- Data Contracts Matter More Than APIs: meaning and compatibility under change
- The Myth of a Single Source of Truth: owned authority instead of shared wishful thinking
AI Reality Checks #18 · Part of Binary and Beyond. LinkedIn newsletter edition follows. Building AI workflows where decidable data comes before scaled generation? Start a conversation.