Agricultural AI: the data test it must pass before reaching the farm

A disease alert that arrives after treatment has been applied is not useful. An irrigation recommendation trained on a different variety, soil or season can be accurate in a table and wrong in the field. On 24 June 2026, a European Commission sectoral dialogue brought together experts, farmers, industry and public authorities to examine artificial intelligence adoption in agriculture. Its report, published on 3 July, identified four practical barriers: limited digital infrastructure, uncertain returns, insufficiently interoperable systems and difficulty integrating AI tools into existing farm-management software.

The important finding is not that “data is missing” in the abstract. A farm may accumulate millions of readings and still be unable to answer the decision that matters. Readiness begins in the opposite direction from a sales demonstration: define a decision first, identify the required evidence next, and choose a model only then. Readers can apply a five-layer audit — decision, sample, meaning, rights and validation — before trusting any agricultural AI promise.

Layer one: start with the decision, not the device

“Predict yield” is not yet a use case. Specify who will act, with how much lead time, between which alternatives and at what cost if the system is wrong. For irrigation, an estimate must arrive before the operational window, cover the relevant area and improve on an existing rule. For pest detection, it also matters whether a false alarm leads to a visit, a laboratory sample or an unnecessary application.

This contract turns a promise into a test. A technical metric — mean error, precision or sensitivity — should sit beside an agronomic and an economic one: water saved without yield loss, incidents detected in time or cost per hectare. The Commission dialogue itself called for measurable farm-level value, affordability and support for farmers’ decisions rather than replacement. It also preserved an important limitation: many developments remained pre-market and their impact was difficult to quantify.

On 1 July 2026, FAO defined smart farming as the combination of data, digital technologies and scientific knowledge to improve decisions about water, fertiliser, pesticides, energy and other inputs. The full formulation blocks two shortcuts: data does not replace agronomic knowledge, and technology makes sense only within a production decision.

Layer two: check what the sample represents

Quality is not the same as resolution. A sharp image may be mistimed; a calibrated sensor may cover only the most uniform area; a long history may contain no severe drought. Before training, inventory crop and variety, soil, terrain, management, season, weather, machinery, measurement frequency and the method used to create the label the model will predict.

The central question is where it will stop working. Training on large, connected farms cannot be assumed to represent small plots with different machinery. If disease labels come from visual inspections, record who diagnosed them and when confirmation occurred. If readings disappear during equipment failures, heavy rain or poor coverage, the missingness is not random: it describes the conditions in which the tool will be most fragile.

The divide is not merely statistical. The Commission’s inventory of agricultural digitalisation lists land, crop, livestock, climate, machinery, financial and compliance data, and warns of divides linked to remoteness, farm turnover, skills and age. An easy-to-assemble dataset may overrepresent people who already have sensors, connectivity and staff to maintain them. A responsible evaluation documents that selection instead of presenting the model as universal.

Layer three: make two systems mean the same thing

Interoperability means more than exporting a CSV file. Two columns labelled “moisture” may contain volumetric content or a relative reading; a date may mean sample collection or upload; a plot may acquire different identifiers in the field log, machine and subsidy system. Without units, time zone, coordinates, method, sensor version and provenance, combining data creates syntactic matches and semantic errors.

The minimum record for each variable should state its definition, unit, spatial resolution, frequency, source, transformation and steward. It also needs basic controls: plausible ranges, duplicates, gaps, calibration changes and lags between events. Traceability lets a user travel back from a recommendation to the observation that produced it. If that path is unavailable, correcting a failure or defending a decision becomes difficult.

Research offers promising architectures, but its limits matter. The AgriTrust framework, indexed by FAO AGRIS in 2026, proposes federated governance, ontologies and verifiable provenance for cross-platform data sharing. Its demonstration used simulated cases and a proof-of-concept graph; the authors leave real deployment, scalability and performance validation for future work. It is a design worth studying, not evidence that farms already have a solved system.

Layer four: define rights before sharing

Agricultural data can reveal machinery routes, yields, costs or practices that constitute sensitive information or trade secrets. Before connecting a provider, write down who can access the data, for which purpose, for how long, whether it may train other models, whether it may be transferred and how it will be exported or deleted when the contract ends.

Control is not an obstacle added to utility; it is a condition for obtaining continuous, reliable data. The Commission links trust to sovereignty, security and consent, and describes the Common European Agricultural Data Space as infrastructure for sharing without stripping control from the generator. A pilot that demands the full historical record but cannot return it in a documented format creates lock-in, not interoperability.

A degraded mode is also necessary. If connectivity fails, a sensor breaks or the supplier changes the model, the farm needs a known operating rule. AI advises within a sociotechnical system: responsibility, correction and the final decision do not disappear because an interface displays a percentage.

Layer five: validate on another season and against a real alternative

Randomly splitting rows from the same field can leave training and test sets with nearly identical conditions. A harder evaluation holds out entire farms, areas or seasons. It then compares the recommendation with current practice: the farmer’s judgement, an adviser or a simple rule. The model must win where it will be used, not merely against another version of itself.

Local validation is work, not a formality. Agriculture and Agri-Food Canada announced on 9 July a three-year project to integrate satellite, drone and field data for crop monitoring and yield prediction. Its release explicitly says public scientists will collect field data and validate models. This is a funded pre-commercial project intended to produce evidence; it does not yet demonstrate the expected benefits.

After deployment, monitor drift: new crops, replaced sensors, weather outside the historical range or changed management. Record the model version, inputs, recommendation, human action and outcome. That makes it possible to determine whether the system still adds value and when it should be withdrawn or recalibrated.

An audit that fits on one page

Before buying or expanding a system, a farm can demand five answers. Which decision changes and by what deadline; which farms and conditions the data represents; how meaning and provenance survive integration; who controls use and exit; and which local comparison will test benefit, cost and harm. If one is missing, the product is still a demonstration rather than an operational tool.

Agricultural AI need not wait for a perfect database. It can start with a bounded problem, a known source, human review and stopping criteria. What it cannot safely do is hide uncertainty beneath a persuasive interface. The transferable skill is to turn “we have data” into five documented tests: decision, representativeness, interoperability, rights and out-of-sample validation.