Why a machine maker cannot simply “add AI”

Italy's Rayonics International designs and manufactures food-quality inspection machines, including X-ray inspection equipment. A small manufacturer has several plausible AI directions: monitor whether installed equipment is operating correctly, analyse accumulated machine data, or identify early signs of failure. The list sounds attractive, but projects with different data and risks should not be bundled into a single purchase of an “artificial intelligence platform.”

The EXPAND hub's case study describes work with Rayonics in 2024–2025. The company received staff training, feasibility studies and a technology roadmap. One applied outcome was an edge-level AI model created to monitor the correct functioning of an installed inspection machine. At the time of the case report, it was ready for field testing. This is not a claim of verified deployment across customer sites, reduced rejects or fewer service visits: the source does not publish those metrics.

What was actually done

The project split uncertainty into several parts. Staff took AI fundamentals training, developers studied practical Python, and specialists assessed what data could be collected from installed machines for future predictive maintenance. Separately, they examined quality analysis with an edge-level model, located close to the equipment. The work ended with a roadmap for possible product and process development.

That sequence matters more than the model's fashionable name. First determine what a machine already measures, which events it records and which maintenance mistakes are costly. Only then can a team test whether a model adds useful information beyond existing sensors and rules. The source does not disclose the model architecture, dataset, computing device, processing frequency or accuracy metrics. Attributing a particular neural network, GPU or finished predictive-maintenance system to Rayonics would be invention.

A second idea, a model analysing machine data collected in the cloud, was still under study at the time of the case. It should not be conflated with the edge application already built. Field-testing the first model and selecting the architecture for a second are different gates, budgets and data permissions. Our little robot intern would eagerly run a cloud cable to every machine, but the list of necessary signals matters more than cable length at this stage.

Where a local deployment makes sense

Edge processing is useful when a decision must arrive near the production line, connectivity is unreliable, or raw production data should not leave the site. Local does not automatically mean safe or inexpensive. A site still needs power, compatible computing hardware, model version control, secure updates and decision logs. If the model only advises a technician, it can begin in shadow mode. If it stops a line or changes equipment settings, testing and human-approval requirements are much higher.

For a similar pilot in a Russian SME, draw two data flows. The first is local: machine signals or images enter an on-site service, a model produces an assessment, and an operator sees it alongside the original measurements. The second is analytical: de-identified or otherwise permitted events go to storage for retrospective analysis. Decide on any cloud component separately, after checking data composition, access rights, latency, connectivity and storage cost. The Rayonics case does not prove its whole installed fleet uses this architecture; it is a transferable pilot design.

How to test the model in the field

Ready for field testing means the laboratory stage has been passed, not that the system is robust on every line. Moving toward production requires at least four checks:

  • Technical fit: which machine and sensor versions are supported, how data is collected, and what happens when connectivity is lost or the compute device restarts.
  • Decision quality: false alarms and missed events by product, shift, site and equipment mode. A single overall “accuracy” number is insufficient.
  • Operational effect: whether detection time, unnecessary service visits, downtime or manual checks actually fall, without a compensating rise in work caused by false signals.
  • Change management: who approves a new model version, what test set compares it with the old one, and how an update can be rolled back without interrupting primary quality control.

NIST's AI risk-management materials recommend comparing live performance with pre-deployment results and accounting for changes in conditions, data and model behaviour. In industrial AI, that is practical rather than ceremonial: new packaging, a different production batch, a repaired sensor or another shift can alter the input. A pilot report should preserve both the average score and the conditions under which the model failed.

If the system participates in food inspection, a missed problem and an unnecessary stoppage have different costs. The threshold cannot be chosen for developer convenience: a process engineer, quality team and business owner must agree on it. Until then, shadow mode is safer—the model records its prediction and rationale but does not change machine behaviour. This is our editorial recommendation, not a claim about Rayonics' actual operating mode.

Economics: cost of outcomes, not demos

The public case does not provide the edge device's price, integration expenses or achieved payback. For your own project, count the entire lifecycle: data collection and labelling, equipment adapters, compute hardware, updates, monitoring, tests on new batches and engineers' work on alerts. Count the cost of a missed issue separately from that of an unnecessary stop.

A modelled example, not a Rayonics result: suppose ten machines each need one unplanned service investigation per month, costing RUB 6,000 including labour and downtime. The potential monthly pool is RUB 60,000. If a model prevents only one quarter of those events, the gross effect is RUB 15,000 before development, hardware and support. If ongoing support costs more, the project does not pay back from service visits alone. Lower scrap or fewer failures might justify it, but those benefits must be measured independently. Every number here is an assumption illustrating the calculation method, not a company metric.

A next step without an expensive experiment

A small manufacturer can start with one machine and one measurable problem. Record event history, operating conditions and the cost of errors. Run the model alongside existing control across normal and adverse conditions. Each week, compare its signals with the engineer's judgement and the eventual outcome. Expand to the fleet only after an agreed quality threshold, a clear rollback plan and a full cost estimate.

The Rayonics lesson is not that an edge model has already produced spectacular savings. The public record confirms a narrower, useful result: the company worked methodically toward a model ready for field testing and did not mistake a parallel study of cloud analytics for a finished system. That discipline usually protects a budget better than an impressive demo.