From maps to a daily decision

A small agritech company had a specific goal—not to “implement AI in general,” but to take the next step in an existing service: move from descriptive vegetation and soil-moisture maps to recommendations on how much to irrigate a particular field today. The company already had domain expertise and datasets: satellite observations, meteorological information, soil data, and crop information. What it lacked was confidence that these inputs could be combined reliably and that the result would be useful, explainable, and economically viable.

In July 2026, the European Digital Innovation Hubs Network described this case. The Italian SME approached ER2Digit to assess a path from an initial idea to a measurable project and determine whether it made sense to bring in more advanced AI/HPC resources from IT4LIA. It is important to be precise about what was achieved: this was feasibility assessment and project design, not a publicly confirmed launch of a finished service that has already reduced water consumption.

What was assessed before development

The team began with the operational need, available data, digital maturity, and expected outcome. It then compared alternatives: AI models, physical and agronomic models, data-pipeline architecture, and possible access to high-performance computing. The resulting concept was a hybrid approach: satellite, weather, soil, and crop data would jointly support daily irrigation recommendations.

The roadmap included a modular architecture, data ingestion and preprocessing, validation logic, possible forecasting and anomaly-detection modules, as well as requirements, risks, and next experiments. According to the published case, the service for this specific company lasted six months and was valued at €4,255.33. This is the value of an expert “test before invest” service—not the budget for a complete product and not a proven amount of savings. The wider programme provides support of up to €4,500 per beneficiary; the public-aid intensity depends on company size.

Why this sequence helps a small business

A process owner may be tempted to start with a model and user interface. In this case, however, the bottleneck was not the lack of a fashionable algorithm. It was whether the data was sufficiently complete and aligned to support a field-level decision. If satellite imagery, a weather forecast, and a soil-moisture reading refer to different dates, resolutions, or field boundaries, a polished dashboard will only display inconsistent results faster.

Before development, define what counts as a recommendation and how it will be checked:

  • the decision unit: a field, plot, or zone with similar conditions;
  • the time horizon: the next irrigation, the next day, or several days;
  • input data: source, update frequency, delay, coverage, and usage rights;
  • ground truth: actual soil moisture, rainfall, the agronomist’s decision, and irrigation outcome;
  • benefit metric: for example, recommendation accuracy, timely adjustments, or water consumption for a comparable plot;
  • safe behavior: what to do when an image is missing, sensors conflict, or no forecast is available.

Metrics should not be chosen merely because they are available in an analytics dashboard. Reducing water use without considering yield or quality may be a false economy. For an initial pilot, it is more reasonable to compare plots or periods with similar conditions, record a baseline, and separately account for weather, crop type, and specialist actions.

A first-pilot architecture

An SMB in Russia can simplify the sequence into a few understandable components without buying a compute cluster upfront:

1. **Data layer.** Ingest satellite products, weather data, and information about soil and crops. Standardize coordinates and field boundaries, and record observation times and source versions.
2. **Quality checks.** Mark cloud cover and missing data, stale forecasts, outliers, and misaligned periods. Do not turn missing data into zero soil moisture.
3. **Baseline calculation.** Compare a simple agronomic model or current rule with the AI candidate. Added complexity should earn its place through greater accuracy or usefulness.
4. **Explainable recommendation.** Show not just a number, but the factors behind it: rainfall, soil condition, crop, input-data quality, and uncertainty. At first, this is advice for a specialist—not an automatic command to pumps.
5. **Validation and feedback.** Record whether the agronomist accepted the recommendation, what they changed, and what outcome followed. Otherwise, the team cannot distinguish a model error from a change in practice or weather.

The test set should be split by time and farm so that near-identical measurements from one field do not end up in both training and validation. Otherwise, a system may look convincing on familiar conditions and perform much worse in a new season. Check common crops, regions, seasons, and incomplete-data scenarios separately.

Does this require a local model and HPC?

Not necessarily. Information about a field and farm may be sensitive, but weather forecasts and some satellite products do not by themselves require running a neural network locally. First determine which data cannot be sent externally, which services allow its processing, and what requirements apply to the specific company and market.

Compute infrastructure is justified when experiments confirm the need—for example, processing large volumes of imagery, complex modelling, or parallel scenarios. If the problem is limited to scheduled ingestion, geospatial operations, a tabular model, and a report, a standard cloud or local server may be sufficient. The EDIH case describes preparation for possible future experiments with IT4LIA; it does not claim that the SME has already deployed workloads on a supercomputer.

A local setup would also need fresh data copies, regular imports, source logs, and an operations plan. Local deployment does not fix poor labeling or automatically make recommendations more accurate; it primarily addresses requirements for data control, availability, and location.

Economics: cost the next step, not a promised return

The published case provides a confirmed value for the preparatory service and its duration, but no measured reduction in water use, yield increase, revenue, or company savings. The page explicitly says those indicators require follow-up. These figures therefore cannot be used as an ROI promise for another farm.

For your own project, calculate a modelled pilot threshold. Estimate the cost of data collection and cleaning, integrations, support, and specialist review, then compare it with the cost of each decision cycle. Count water or labor savings only after measuring them in a comparable process. If there is not yet enough data to verify the outcome, the pilot’s job is to produce that evidence—not to manufacture a precise ROI from assumptions.

A “test before invest” programme is useful because it separates a modest spend on validating a hypothesis from a much larger commitment to a finished product. But subsidy amounts, eligibility, and infrastructure access belong to a specific programme; they do not automatically apply to a Russian business.

What a manager can reuse

Before commissioning development, write a one-page pilot brief:

  • what decision employees make today and what should change;
  • what data is available, who owns it, and how often it is refreshed;
  • what simple baseline will be used for comparison;
  • how results will be tested on new fields or periods;
  • which action remains with the specialist;
  • what the assessment costs and what conditions will stop the project or move it to the next stage.

Then run a short feasibility review with the process owner and a technical specialist. The outputs should be a data map, a non-AI baseline, test criteria, and an infrastructure estimate. Only after that decide whether the project needs ML/HPC, additional data integrations, or a pilot across several farms.

The main lesson is not that every company needs a supercomputer. The Italian SME first turned a business question into a testable plan: what data, methods, costs, and skills are needed to solve the irrigation problem. That is a reusable approach for a Russian business—provided that any specific savings and impact are validated with its own measurements.

*The photograph is illustrative: it shows agricultural irrigation in Ghana’s Volta Region and is not a photograph of the company in the case.*