'
Every vendor pitching food companies right now is promising AI will transform the operation. Demand forecasting that predicts spoilage. Automated replenishment. Dashboards that see everything.
Here's the number they leave out. A 2026 study of food sector supply chains found that only 12% of companies actively use generative AI in their operations. Another 44% are stuck in test phase. And 28% openly admit they don't know how to apply it.
That's not a technology gap. The tools work. It's a data gap, and almost nobody selling AI wants to talk about it, because the fix isn't something you can license.
The pattern is consistent across midsize food operations. A company runs an AI pilot. The demo, built on the vendor's clean sample data, looks great. Then the pilot needs the company's real data, and the real data lives in an ERP that doesn't talk to the warehouse system, a planning spreadsheet one person maintains, and a receiving log that's still partly on paper.
The pilot stalls. Six months later everyone concludes AI isn't ready for their business.
The AI was ready. The data wasn't. And in food, the data problem is harder than in almost any other industry. That's worth understanding in detail, because it's also the reason generic fixes don't work here.
Why food data is uniquely messy
If you run operations in food, none of this will surprise you. But it's rarely said plainly, so here it is.
Catch weights break clean math: A case of chicken breasts is not a case of screws. Nominal weight and actual weight differ on every single case, which means your inventory can be simultaneously correct in cases and wrong in pounds. Any forecasting or costing model that assumes fixed unit weights inherits that error on day one. If your ERP tracks cases and your customer orders in pounds, someone or something is converting, and every conversion is a chance to drift.
One product, five identities: A single SKU typically carries your internal item number, the supplier's item number, a GTIN on the case, the customer's item number in their portal, and sometimes a legacy code that survived the last ERP migration. When these don't map cleanly, people build crosswalk spreadsheets. Those spreadsheets become load-bearing. Nobody documents them. The person who built the crosswalk leaves, and now a hand-typed translation sits in the middle of your order flow. Every AI use case that touches product data hits this wall first.
Lot and date coding is inconsistent by default: One supplier stamps a pack date, another an expiry date, a third a Julian code. Your receiving team interprets and keys these in, sometimes the same day, sometimes Thursday for Tuesday's receipts. Downstream, that means your system's picture of shelf life is an approximation. A model built to predict spoilage or optimize rotation is only as good as those keyed dates, and it has no way of knowing which ones were guessed.
Units of measure multiply quietly: Eaches, cases, pallets, pounds, kilograms for imported product. A warehouse that picks in eaches from a system that plans in cases produces rounding noise on every transaction. Small individually. Compounding in aggregate.
Perishability punishes latency: In most industries, data that's two days stale is an inconvenience. In food, two days is a meaningful fraction of the product's remaining life. A batch-synced integration that updates inventory overnight was tolerable when a human planner sanity-checked everything. Feed that same delayed data into automated decisions and the automation confidently acts on a world that no longer exists.
None of these problems is exotic. Every one of them is fixable. But no forecasting model, however sophisticated, fixes any of them. It just processes the errors faster and presents them with more confidence.
Three checks to run before any AI conversation
You don't need a consultant to find out where you stand. You need an afternoon and three honest questions.
Check one: count your sources of truth: How many places hold an inventory number right now? ERP, WMS, the planning spreadsheet, the customer portal. If the answer is more than one, which one wins when they disagree? For technical readers, the sharper version: is there a system of record for each data domain, and is that designation written down anywhere, or is it tribal knowledge? Most operations can't answer in one sentence. That sentence is the foundation everything else stands on.
Check two: measure one week of lag: Pick last Tuesday. When did Tuesday's receipts, shipments, adjustments, and production consumption actually land in the system? Same day? Thursday? For the technical team: is the ERP-to-WMS sync event-driven or batch, how often does the batch run, and what happens to transactions that fail validation? Whatever the honest lag is, that's how stale every automated decision would be. In perishables, that number matters more than any model's accuracy score.
Check three: trace one product code end to end: Follow a single SKU from the supplier's paperwork through receiving, putaway, inventory, the customer order, and the invoice. Does it keep one consistent identifier the whole way, or does a person translate it somewhere in the middle? While you're at it, trace the lot number on the same journey. If either one passes through a spreadsheet or a memory, you've found the exact point where traceability, forecasting, and automation all break at once.
If all three checks come back clean, you're genuinely ahead of most of the industry, and an AI conversation is worth having. If they don't, you've just found your real project. It's less glamorous than an AI initiative. It's also cheaper, and it pays off whether or not you ever deploy a model.
What fixing the plumbing actually looks like
Plumbing sounds vague, so here's the concrete version, roughly in order of leverage.
It starts with the item master. One canonical product record, with every external identifier (supplier codes, GTINs, customer item numbers) mapped to it as attributes rather than living in someone's crosswalk file. This is unglamorous data work, and it's the highest-return project most food operations haven't done.
Then data capture at the edge. Lot numbers and dates scanned or validated at receiving, not keyed from memory at end of shift. The goal isn't more data entry. It's less, done once, at the moment the physical event happens.
Then integration. The ERP, WMS, and any planning tools exchanging data automatically, ideally as events happen rather than in overnight batches. This is where custom work usually enters, because midsize food companies run system combinations that off-the-shelf connectors don't cover cleanly, especially once catch weights and lot attributes have to survive the trip between systems intact.
Notice what this list produces even before AI enters the picture: faster recalls, cleaner customer compliance reporting, inventory counts your planners actually trust, and fewer end-of-month reconciliation fires. The AI readiness is almost a side effect.
The honest conclusion
The companies getting real value from AI in food right now are not the ones with the biggest budgets. They're the ones that did the boring work first, usually a year or two ago, often for reasons that had nothing to do with AI. Traceability pressure. A painful recall. A customer mandate.
If you're being pitched AI right now, run the three checks first. In our opinion, that afternoon of honesty will tell you more about your next twelve months than any vendor demo.
And if you run them and want a second opinion on what you find, that's a conversation we're always glad to have. Talk to an engineer at Platsera.
