Put AI where a wrong answer costs a forecast miss, not a customer

I have delivered AI in two very different places. At Pluto7 I governed demand-forecasting and digital-twin programmes on Google Cloud for global consumer-goods and retail businesses. At Codilar I scoped and shipped a generative-AI content feature inside a Pimcore product-information system. Both worked. Neither was customer-facing. That was not an accident.

In both cases the model sat behind the glass: its output went to a trained person who could see it, judge it and change it before anything reached a customer, a supplier or an invoice. A forecast that is 8% off gets corrected by a planner in the next cycle. A product description that reads badly gets rewritten by a merchandiser before it is saved. The cost of a wrong answer is a little rework. That is a cost a business can absorb while the model gets better.

Compare that with a shopping assistant on the storefront that invents a return policy, or a support bot that promises a delivery date the warehouse cannot meet. The cost of the same kind of error is a lost order, a complaint, a chargeback, sometimes a legal problem. Same model quality, completely different risk.

Before I agree to scope an AI feature, I ask three questions. If the answers are uncomfortable, the feature either moves behind the glass or it waits.

The forecasting programmes improved forecast accuracy by about 22%, cut stock-outs by about 18% and lifted on-time-in-full delivery by about 12% for the businesses involved. Those numbers came from the model, but they were protected by the operating design around it. Planners kept the final say on every order. The model's recommendation, its confidence and the previous plan were shown side by side, so an override was a deliberate choice, not a fight with the system.

The biggest delivery risk was not the algorithm. It was data. Catalogue hierarchies that did not match between systems, promotions that were never recorded, stores that opened and closed without the history being cleaned. Every AI programme I have run was first a data-quality programme. If the inventory data is a mess, the model industrialises the mess at speed.

The Pimcore feature let merchandisers generate product meta descriptions and field content with one button per field. Nothing was saved automatically. Every suggestion opened in a review window, with character limits enforced, and the merchandiser accepted, edited or discarded it. Administrators controlled which fields had the button and which prompt each one used, so the business, not the developers, decided where AI was allowed.

We compared estimated effort with actual effort across the team to measure the time saved. The honest result was mixed, and that was useful. Short, structured fields improved a lot; long descriptive copy for technical products improved less, because the review took nearly as long as writing. That told the client where to expand the feature and where to stop.

I am not arguing that AI should never face a customer. I am arguing for sequence. Earn trust behind the glass first, where errors are cheap and measurable. Build the evaluation data, the guardrails and the human review habit. Then move outward, one bounded use case at a time, with a narrow scope, a clear fallback to a person and monitoring that someone actually reads.

For a delivery leader, this is also a commercial point. Behind-the-glass AI has a business case you can defend to a CFO: hours saved, error reduced, stock released. A storefront chatbot often has a business case built on engagement metrics that are hard to tie to revenue, plus a risk line that nobody has priced.