The small company's problem

The Netherlands-based FreezerData works with refrigeration-equipment monitoring. In the case published by the European Digital Innovation Hubs Network (EDIH) in 2024, it was a microbusiness with 1–9 employees. Its customers need to understand quickly when a cooling system is unstable and whether a technician should be dispatched. Experienced technicians, meanwhile, are interrupted by less experienced colleagues' questions, while sensor readings and equipment manuals usually live in separate places.

With its partners, the company developed a “virtual service mechanic”: a prototype assistant that answers technical questions using manuals and current sensor data. Selecting the right source proved particularly important. A question about how a component works calls for documentation; a question about the current condition of a specific installation calls for telemetry. EDIH reports a Proof of Value demonstrator and contributions of €10,000 from the programme and €50,000 from FreezerData. This is neither a standard deployment price in Russia nor a verified saving. The case gives no measured reduction in repair time, number of incidents prevented or payback period.

FreezerData's own website describes its cloud platform for monitoring temperature and other parameters. These are the vendor's product descriptions, not independent outcomes from the “virtual mechanic” project. The architecture proposed below for a Russian business is our editorial adaptation, not FreezerData's disclosed technical design.

Why RAG alone is not enough

Searching manuals can answer “how should this compressor model be checked?” It cannot know what is happening in a particular cold room right now. A sensor stream, conversely, can show temperature, pressure, door events or power status, but it does not explain the permitted operating range for that exact equipment model. The assistant needs both kinds of evidence while keeping their origins distinct.

A useful answer can be built from three separate layers:

  • **Document**: manual model and revision, page, procedure, permitted limits and validity date.
  • **Asset fact**: installation ID, timestamp of the latest reading, units, connectivity quality and recent alarms.
  • **Decision**: what should be checked, how urgently and who decides on a visit or shutdown.

If telemetry is stale, the system should say so explicitly. If the relevant procedure is absent from the manual, escalating to a senior engineer is more honest than inventing a plausible answer. A generative model can write a clear explanation, but it must not set a safety threshold on its own: thresholds come from approved documentation and operating rules.

Minimum pilot architecture

The first version for a small business does not need an autonomous agent with access to every system. It needs a small equipment catalogue, a repository of verified manuals and a safe read-only interface to sensor readings. Give each device a stable ID and link it to its model, serial number, sensors, site, service history and current documentation. Index manuals by model and revision; a random PDF for a similar installation must not enter the knowledge base without review.

A request such as “Why is cold room 17 warming up?” is first resolved to an asset. The telemetry service returns recent readings with timestamps and missing-data indicators. Document search retrieves only sections that apply to that equipment. A rule or router then checks whether there is enough evidence to answer. The model produces a draft with distinct references to the manual and the readings; an engineer confirms the conclusion and action. When the question concerns compressor operation, power shutdown or temperature-controlled goods, a single text answer must not trigger an automatic control action.

A local deployment makes sense if telemetry must not leave the premises, cloud connectivity is unreliable or the site needs offline access to instructions. The index and model can run on an owned server, while sensor data arrives through a read-only gateway. Locality alone is not a solution: manuals must be updated, backups maintained, access restricted by site and answers logged. At low volume, the model may run on a CPU or a shared server. Buy a powerful GPU only after measuring latency and concurrent demand.

Testing quality and safety

Ten well-analysed scenarios are more useful in a pilot than a hundred polished demos. Select common incidents from the service log: an open door, an unresponsive sensor, rising temperature while the compressor is running, an incorrect setpoint after maintenance, or conflicting manuals for different models. For each, record reference data, the expected action, prohibited recommendations and escalation criteria in advance.

Evaluate asset identification, telemetry freshness, document accuracy, answer completeness, unsafe or fabricated advice, and time to a useful decision separately. Test failure modes too: no connectivity, wrong ID, an empty index and conflicting documents. An answer without a reading timestamp or equipment model should not count as accepted. Initially, the assistant only advises; the technician retains the decision and responsibility.

Access control matters. A technician serving one customer must not see another customer's readings or service history. Document search and telemetry retrieval must check permissions before passing context to the model. Writing to a controller, changing a setpoint and closing a service ticket are separate operations requiring explicit approval and an audit trail, should they ever be enabled.

Economics without borrowed promises

The published case states demonstrator-development contributions, not customer savings. A Russian SME should start with its own figures: monthly requests that consume a senior engineer's time, repeat visits, the cost of an hour of downtime and how early a trustworthy signal arrives. Do not copy €60,000 into a local budget or book hypothetically saved goods as revenue.

An **illustrative model**: if 40 requests a month each save ten minutes of senior specialist time, about 6.7 hours a month are released. At an assumed fully loaded hourly cost of 1,500 roubles, that is roughly 10,000 roubles of gross monthly time value before implementation, support and quality-control costs. This is not a FreezerData result. If the assistant often makes errors that require rechecking, the saving disappears; if it prevents an expensive incident, the main effect may lie in a different cost line. That claim needs a log of actual events, not a presentation.

The next step

Choose one group of similar refrigeration units and collect their current manuals, sensor map and 20–30 historical technician queries. Define which questions may be answered automatically and which require immediate human escalation. Run a two-to-four-week shadow pilot without control commands, measuring accepted answers, unsafe errors, specialist time and escalation quality. Decide whether to expand only after those measurements.

The FreezerData case illustrates a useful principle: an AI service assistant creates value when it can distinguish “what the manual says” from “what is happening to this installation now.” What is confirmed is a demonstrator, not universal savings; that is an important boundary for business claims.