Here's the verdict up front: when an AI project fails in a warehouse, at least half the time it's not the model's fault — the data wasn't cleaned up first. I've seen this pitfall three times. Every time it blew up on go-live eve, and every time the team had to stop and go back to data homework. AI data preparation comes before go-live: three data types must be cleaned up — master data, transaction data, and labeled data. What "clean enough" means, and how to check and fix each one — that's what this article spells out, item by item.
Why Data Preparation Is the First Gate
Think of it this way: the model is the student, the data is the textbook. Hand a student a textbook with half the pages misprinted, and even the best student fails the exam. Everything AI does in a warehouse — recognizing locations, forecasting replenishment, answering customer questions — rests on one premise: the data in the system matches what's actually on the floor. And the reality is, most warehouses have a gap between the two: SKUs sharing one barcode, duplicate location labels, inbound and outbound transactions entered hours after the fact. A human glancing at the floor can self-correct those gaps. AI can't — it just learns the errors more convincingly.
So data preparation isn't a "while we're at it" preliminary. It is the project. In the AI-related projects I've worked on, data preparation has consumed more than half of total project hours on average, and three to four tenths of the budget needs to be ring-fenced for data governance. Put that math on the table at kickoff, so nobody budgets only for the model and discovers mid-project that the data gate can't be passed.
Cleaning Up, One Data Type at a Time
Type one: master data — one code, one thing, no exceptions
Master data is the "dictionary": SKUs, locations, suppliers. The first requirement for AI adoption: one barcode maps to exactly one thing.
How to find the dirt: export the full SKU master and run three checks. First, empty codes (blank barcode fields or all zeros). Second, duplicate codes (one barcode pointing at multiple SKUs). Third, one-code-many-items (walk the floor and scan — is one label stuck on two different products?). Locations get the same treatment: export the location master, check for duplicate labels, and hunt "ghost locations" that exist in the system but can't be found on the floor.
How to fix it: for empty or duplicate codes, freeze inbound and outbound for the affected SKUs, verify each one on the floor, and reassign codes. For one-code-many-items, split them down to one-code-one-item — there is no shortcut. For supplier masters, the classic mess is "one supplier, three names" — the same vendor entered three ways, which AI reconciliation will treat as three different companies.
Acceptance bar: randomly sample 500 SKUs, scan them on the floor, and every scan must match the system exactly. Sample 200 locations the same way. If a sample fails, expand to a full recount and don't move on until two consecutive samples pass clean.
Type two: transaction data — timestamps are AI's eyes
Inbound and outbound records, cycle-count records, task records — this is the textbook AI learns "how the warehouse runs" from. The minimum requirement for the textbook: complete timestamps, no gaps in the record.
How to find the dirt: pull the last 90 days of inbound/outbound transactions and check three things. First, missing timestamps or defaults like 1970. Second, future timestamps (someone changed the system clock). Third, negative inventory (negative on-hand means missed outbound transactions). Then check the "after-the-fact entry rate": how many documents were created more than 24 hours after the actual operation — back-entered documents carry fake timestamps, and AI learning "peak and valley" patterns from them learns crooked.
How to fix it: for missing timestamps, backfill only where the original record can be recovered; where it can't, cut the whole segment and mark it — never "estimate a time and fill it in." Negative inventory must be counted and zeroed out before any AI discussion. For high back-entry steps (usually returns and cross-docking), change the process to real-time scanning first, then accumulate data.
Acceptance bar: 90 consecutive days of transaction records with no gaps, 100% timestamp completeness, zero negative inventory, and after-the-fact entries under 5%. Below this bar, don't deploy forecasting AI (demand prediction, replenishment suggestions) — it will just compound the errors.
Type three: labeled data — the ammunition for AI adoption
Vision systems need "anomaly images" (damaged packaging, mislabeled cartons, empty pallets); customer-service AI needs Q&A pairs (real customer questions plus approved answers). Warehouses don't naturally have this data — it has to be labeled from scratch.
How to assess it: ask three questions. Is the volume enough (vision tasks need at least several thousand usable images to start; Q&A needs at least a thousand pairs)? Is the coverage complete (are the anomaly photos all daytime shots from one zone)? Is the labeling accurate (have two people label the same batch independently, and sample 200 items for agreement)?
How to fix it: if volume is short, run targeted collection — have floor staff photograph against a checklist for two weeks. If coverage is thin, add the easily missed scenarios (night shifts, the outdoor dock in rainy season). If accuracy is off, write a one-page labeling spec defining exactly "what counts as damaged versus normal," then re-inspect samples and rework any batch that fails.
Acceptance bar: sample 200 labeled items; two independent labelers must agree at the target rate (I suggest 95%+ for vision, 90%+ for Q&A), with all major scenarios and shifts covered. Put labeling quality standards in a contract appendix, not in a verbal promise.
I've Seen This Pitfall Three Times: A Rescue Story
Mid-2025, a 3PL warehouse in East China launched AI-assisted cycle counting: AGVs carrying cameras down each aisle, AI reading location labels and goods, auto-reconciling against book inventory. Great idea. In the first week of go-live, the count variance rate went up instead of down, the floor team was furious, and the project nearly got killed.
Where was the problem? A week of digging traced it to data type one: nearly one in ten location labels in that warehouse were duplicates. The zones had been rearranged twice over the years; old labels were never fully removed, new ones pasted on top — one slot, two codes. Add SKUs sharing barcodes, and the AI kept reading location A's goods as location B's. The more it counted, the messier it got. Human counters seeing a duplicate label would use judgment. AI doesn't.
The rescue took three steps and a full two-week shutdown. Step one: warehouse-wide one-code-one-thing cleanup — tear off every duplicate label, reassign codes, and route all inbound/outbound through manual double-check during the freeze. Step two: SKU master cleanup, splitting every one-code-many-items case. Step three: retrain the recognition model on the cleaned data, pilot in a small area for two weeks, and only roll out fully once variance dropped below the manual-counting level.
Data preparation consumed 60% of that project's total hours. The lesson is one sentence: at AI project kickoff, data-governance hours must be listed and scheduled as their own line item — don't hide them inside the word "implementation." I've seen this pitfall three times, and the script is identical every time: it was never the wrong model. Nobody went to the floor to scan those 500 codes before kickoff.
Go-Live Eve Checklist: Data Edition
One counterintuitive note first: don't wait for "perfect" data before launching AI. Perfect data doesn't exist — launch, then iterate, and the model will surface new data problems in operation. But the floor-level standards for the three data types are non-negotiable: one code one thing in master data, complete transaction timestamps, inspected labeling. Below those floors, the model drifts further the longer it runs — better not to launch at all.
On go-live eve, walk this list and check every box. One unchecked box, no production cutover:
- Master data: 500 randomly sampled SKUs scanned on the floor, all matching the system
- Locations: 200 randomly sampled locations, no duplicates, no ghosts
- Transaction data: last 90 days of records gap-free, timestamps complete, negative inventory zeroed
- Back-entry rate: documents created 24+ hours late under 5%
- Labeled data: 200-item sample passes independent-labeler agreement, all major scenarios covered
- Dirty-data handling rules documented: who owns it, how often it runs, who exceptions escalate to
Check them all, then go live. The one thing you can do tomorrow: randomly sample 100 SKUs and scan them on the floor. Whatever share doesn't match — that's the true starting point of your data preparation.
By Lin Xiao, WMS Implementation Consultant
