AI belongs inside the workflow, not beside it. A supplier's master-data check before the EDI send, where the work already happens
A pilot that passes its keep rules, as in step three, has proved the job can be done. It has not proved anyone will do it on a busy Thursday. The next failure is not technical. A useful tool that sits in a separate window gets used while it is new, then on quiet days, then not at all. This is step four of five, and it is about where the tool sits.
A typical case
Take a supplier to retail with one person who owns product data. Say forty new lines a month are set up in the ERP, each with its GTINs at unit, inner and carton level, a pack configuration, a cost, a price for each retailer and a start date. The numbers are illustrative; the shape is common. A few carry a fault that nobody sees until the retailer does: an inner GTIN where the order is for cartons, a carton quantity of twelve when the carton holds ten, a missing GLN for a new store, a price that does not match the retailer's file, a start date after the first order. Each comes back weeks later as a rejected document, on someone else's desk. I described that chain in Why your product master data breaks your EDI.
The job this business has chosen and piloted is narrow: read each new or changed item against the retailer's rules, the ones in its compliance guide and its price file, and say what looks wrong and why. Some of that is plain rules, such as check digits and pack arithmetic. The AI part is reading the retailer's guide and the odd cases, where a field is valid on its own but wrong for this retailer.
Beside the workflow
The easy way to run it is a separate chat window. The data person finishes setting up an item, copies the details across, pastes in the retailer's rules, reads the answer, goes back to the ERP and fixes what it found. In a pilot, with someone watching, that happens every time.
Afterwards it is a second job. It adds a few minutes per item, it depends on remembering, and it is the first thing dropped in a week with a range review and a price change at once. Nobody decides to stop. The check simply runs on fewer items each month, and the rejections come back.
The GenAI Divide, MIT NANDA's report dated July 2025, found that of the organisations that evaluated custom or vendor-sold AI systems, only a small fraction got one into production, and it put most failures down to brittle workflows, lack of contextual learning, and misalignment with day-to-day operations. Among the complaints it recorded was "too much manual context required each time". The standout vendors, it said, were those embedding themselves inside workflows and starting from narrow footholds.
Inside the workflow
The pattern I would build has five parts. A trigger: the item is saved, or the order response, ASN or invoice is about to leave; the second catches a store GLN missing from the customer master. A check: the item read against that retailer's rules. An exception, with its reason, shown in the screen the person already has open: "carton quantity 12, but the pack configuration for this retailer's order unit says 10". A person who decides: fix it, or accept it with a note, because sometimes the data is right and the rule is out of date. A record of that decision, who made it and when.
Wiring it in is usually ordinary work. Most ERPs have their own save hooks or validation events that can call a check and hold the record with a message. Most EDI translators have a pre-send step where a document can be stopped and put in a queue. Where neither exists, an inbox rule on the translator's error and acknowledgement mail can open the item for review: the weaker, after-the-fact option, since that mail arrives after the document has gone.
Checking automatically is not new. GS1 Australia runs an automated validation tool over the shared national product catalogue and sends suppliers detailed reports that identify data quality issues (page read October 2026). Useful, but it reads data already in the catalogue. The check I mean runs earlier, when the item is saved.
What changes for the person
Fewer surprises. The fault turns up at the moment the item is saved, with the item still open and the reason on screen, rather than as a retailer's rejection a month later. No second login, nothing to remember. And the measure is plain: the count of exceptions raised at save, how many were fixed and how many accepted, set against the count of rejected documents from the retailer each month. If the first count holds steady and the second falls, the check is doing its job. If it does not, the check is looking at the wrong things.
Checklist
- The trigger named: which save, or which document before it leaves.
- The exception shown where the work is, with its reason.
- A person decides, every time.
- The decision recorded, with who and when.
- No new login.
This is step four of five. Before it: A pilot is proven against the baseline, not in a demo. Next: Keeping AI honest: approvals, audit trail, change control. All five steps are on the AI page.