Skip to main content
All posts

Your AI Read the Wrong Price List. Who Catches It?

The real risk in AI automation is almost never the AI reasoning incorrectly — it's the AI reading from a price list, inventory count, or customer record that's out of date or conflicts with another copy of the same data elsewhere, and confidently acting on it anyway. The fix isn't smarter AI; it's clear source ownership, version checks, and a defined stop condition when the data looks wrong.

Why Does "Garbage In, Garbage Out" Matter More With AI Than With People?

A person doing the same task often has a gut check — "that price seems off, let me ask" — built from years of context an AI system doesn't have by default. Without an explicit rule telling it what "seems off" means, an AI system will use whatever number it's given exactly as instructed, with full confidence, even if that number is a year stale.

What Is Source Ownership, and Why Does It Matter?

Source ownership means one person or one system is the designated, authoritative version of a piece of data — your price list, your inventory count, your customer contact record — and every automation reads from that single source, never from a duplicate spreadsheet or a cached export. The moment two "current" versions of the same list exist, an automation reading the wrong one becomes a matter of time, not luck.

What Does a Version Check Actually Look Like?

Check What It Catches
Last-updated timestamp on source dataFlags data that hasn't been refreshed in longer than expected
Checksum or version number on price/rate filesConfirms the automation is reading the exact file it thinks it's reading
Cross-reference against a second sourceCatches drift between systems that should agree but don't

What Should a Stop Condition Actually Trigger On?

Define, in advance, the specific conditions where the automation should pause and escalate to a person instead of proceeding: a price that's more than a set percentage different from the last known value, a customer record with conflicting contact information across two systems, or source data older than an agreed freshness window. Without a defined stop condition, "the AI should have known better" isn't a real fix — it's a wish.

How Do You Build This Without Slowing Every Task Down?

Most tasks won't hit a stop condition, because most data is current and consistent most of the time. The check only needs to add friction on the exceptions — which, done right, is a small fraction of total volume. Building the check once, at the data layer, is cheaper than debugging every downstream mistake it would have caught. This is core to how we scope every Agentic AI build — the data layer gets designed before the automation logic does.

What's the First Thing to Audit in Your Own Systems?

List every piece of data your current or planned automations depend on, and for each one, ask: is there exactly one authoritative source, or are there two? If there are two, that's the highest-priority fix, before adding any new automation on top of data that might silently disagree with itself.

How do I know if my business already has this 'two sources of truth' problem?

Ask whether the same piece of information — a price, a customer address, an inventory count — exists in more than one spreadsheet, tool, or system that isn't automatically synced. If yes, that's the gap, and it exists whether or not you've automated anything yet.

Does this only matter for AI automation, or for manual processes too?

It matters for both, but AI automation makes it worse because a person might notice a number looks wrong; an unmonitored automation will act on it without hesitation unless you've explicitly built in a check.

What's a reasonable freshness window for price or inventory data?

It depends entirely on how often your real prices or stock actually change. A business with weekly pricing updates needs a much tighter freshness check than one that updates prices twice a year — set the window to match your real update cadence.

Who should get the escalation when a stop condition triggers?

Whoever owns that data source in practice — the person who'd know immediately whether a flagged discrepancy is a real problem or an expected one-off change, not a generic support inbox that has to investigate from scratch.

Is this an argument against using AI automation at all?

No — it's an argument for building the data foundation correctly first. Automation on top of a single, well-maintained source of truth is reliable; automation on top of fragmented, conflicting data is where the real risk lives.