Picture an agribusiness that has spent several years using a digital platform to manage its fields. It has accumulated yield history, soil condition data, fuel consumption records, machinery routes, and completed operations. When the business decides to switch to a different program, it discovers that only finished reports can be exported — the underlying accumulated data cannot be transferred, either for technical reasons or because of the platform's terms of use.
This is a hypothetical example, but it illustrates the legal side of digitalisation. A business is not just paying for a convenient interface. It is gradually handing part of its production knowledge to an external system and making its daily operations dependent on that system's availability. That is precisely why questions about data, liability, and the ability to switch platforms should be asked before deployment begins, not after a dispute arises.
In this article, a digital platform means a program or online service through which an agribusiness collects, stores, and analyses production data or manages specific processes. A digital solution provider is a company that, under a contract, grants the right and technical ability to use the platform and, depending on the agreed terms, also configures it, enables data exchange with other systems, stores information, and provides technical support. The agribusiness that orders such a solution is referred to below as the customer. The relevant contract is referred to as the agreement for the deployment and use of a digital platform. It may cover the right to use the software, configuration services, data storage, and technical support at the same time; the exact scope depends on the terms agreed by the parties.
Digital technologies can help farmers plan operations more precisely, use resources more efficiently, and trace the origin of produce. The European Commission itself highlights these opportunities. However, the expected benefit does not depend solely on the quality of the software or equipment. It is also important to understand what rights the business receives, what obligations the provider takes on, and how to retain control over information if the cooperation ends.
The rest of this article covers four interconnected levels of risk: control over data, the content of the digital platform agreement, the evidentiary strength and resilience of operations, and EU market-entry rules. This order matters: a business first determines what it processes and on what legal basis, then embeds that in the contract and technical procedures, and only after that assesses specific regulatory requirements.
Farm data: why «it's ours» is not enough
Behind the general word «data» lie very different kinds of information. Some of it is entered manually by staff: which crops were sown, when treatment was carried out, how much material was used. Other data is collected automatically by machinery, which records location, speed, fuel consumption, operating time, and technical condition. Such remote collection and transmission of readings is called telematics.
Based on this information, the program generates new outputs: a yield forecast, a map of plots that need extra irrigation, or a fertiliser-application recommendation. These are no longer the business's original records but the results of processing them. The provider may also pool information from different clients for statistical, comparative, or other purposes within its own program. The system separately stores service-level records of who changed what and when.
That is why a contract clause stating that «all data belongs to the customer» does not answer the key practical questions. Will the business receive only the records it entered itself, or also sensor readings? Will it keep the right to use the maps that were built? Is the provider allowed to train its own algorithms on the farm's data? Will it retain copies after the cooperation ends? Legally, such information may simultaneously fall under personal-data regimes, trade-secret protection, copyright, or contractual access rules. So instead of the single word «belongs», it is worth explicitly defining who may access, use, copy, export, and delete the data in each category.
If the program runs as a cloud service, the business accesses it over the internet while the data is processed on remote servers. It is therefore important to establish not just the platform's name but who actually stores the information, in which countries the relevant capacity is located, and which third-party companies get access. These circumstances need to be reflected in confidentiality arrangements, data protection, and data return terms.
Legal protection and the way it is achieved should be distinguished. Information about cost structure, technological solutions, or contract terms may constitute a trade secret if it meets the statutory criteria. In particular, the information must have commercial value because it is secret, and the person who lawfully controls it must take reasonable steps to keep it secret. Simply labelling something «confidential» is not enough for full protection.
For a business, this means it needs to decide who sees production and financial figures, who is allowed to copy them, and under what conditions they are passed on to contractors. Non-disclosure obligations should go hand in hand with real access restrictions. A shared login used by every employee sits awkwardly with a claim that the business carefully guards its information.
A separate regime applies to personal data. For example, a tractor route linked to a specific employee may contain information not just about the machine but about the person. A legal basis for processing is the statutory reason that allows working with such information; depending on the circumstances, it may be, in particular, performance of a contract or statutory duty, a legitimate interest, or consent. It is also necessary to determine who sets the purpose and manner of processing and who acts on that party's instructions, and to fix the provider's obligations on confidentiality, protection, and incident notification. Transferring records to an external platform does not automatically remove the business's own responsibility.
The digital platform agreement: what the agribusiness actually gets
Before signing an agreement for the deployment and use of a digital platform, the provider may demonstrate automated record-keeping, machinery monitoring, yield analysis, and data exchange with other systems. However, the agreement itself sometimes provides only for access to the software, without a specific list of functions, performance requirements, or technical-support obligations. In that case, the capabilities demonstrated may never become contractual obligations of the provider. The agreement should therefore define not just access to the platform but the specific functions and outcome the agribusiness is meant to receive.
Reviewing the contract terms should start with its subject matter — that is, an exact description of what the provider must supply and ensure. If machinery record-keeping is being ordered, it is worth establishing which machines the system is compatible with, which readings it receives, how often it updates them, and what happens without an internet connection. If data exchange with warehouse or accounting records is required, that should be verified before the work is accepted. The mere appearance of a new personal account does not by itself confirm that the production task has been completed.
Equally important is an agreement on service quality and continuity. Specific timeframes matter here: when support will respond to a request, when it will start fixing a fault, and when it must restore a critical function. A function is critical in this context if, without it, an important production or accounting operation stops — for example, shipping produce or managing irrigation. Acknowledging a request, starting repairs, and restoring operation are three different obligations. A message saying «request received» does not, by itself, give the business back the ability to work.
It is also worth separately defining the procedure for scheduled downtime, backups, and data recovery. A backup is a copy of the data kept separate from the working system, from which the data can be restored after loss or damage. For seasonal production, it matters whether the provider can carry out technical work during peak load and how much advance notice it must give the client. It is also advisable to establish how the duration of an outage is recorded and what consequences follow from a breach of agreed service levels.
Liability terms need to be weighed against the possible consequences of a system failure. If the contract caps compensation at the amount of one month's access fee while the program is used in a critical production process, a significant share of the risk may stay with the business. This does not mean any such limitation is automatically unlawful. Its content, the governing law of the contract, the scope of obligations, and the real possibility of proving a breach and losses all need to be assessed.
If the agreement for the deployment and use of a digital platform is concluded with a foreign provider, it is also necessary to determine which state's law applies and where any dispute would be heard. Liability should not be assessed solely by the amount of compensation stated, without considering how it can actually be recovered.
Changing provider should not mean losing field history
Let us return to the situation described at the start of this article. A business may formally cancel a subscription — that is, stop paying for periodic access to the platform — while in practice being unable to keep operating without it. The reason need not be an outright ban on switching. It is enough for the data to be stored in a proprietary file format or structure that only the previous platform can fully read, for the export to be incomplete, or for the new program to be unable to use the exported materials.
A convenient report and a transferable dataset serve different purposes. A report can show total yield. But a new analysis may require individual measurements, their link to specific plots, dates, and the history of changes made. That is why the digital platform agreement should provide not simply for a «right to receive a copy», but for the composition of the information and a documented format that another program can automatically read and use.
A practical way to verify this condition is a trial transfer of part of the data before full-scale deployment. It is also worth agreeing on regular receipt of backups, the timeframe and cost of migration assistance, and the period of continued access to the previous system. It should be defined separately which copies the provider will delete after the cooperation ends and which it must retain temporarily on lawful grounds.
Similar attention is needed for programs, maps, and modules built specifically for the business. A distinction should be drawn between new development, a standard product that the provider supplies in similar form to many clients, and third-party components — libraries, maps, or modules of other rightholders — for which the provider itself only holds a licence to use. Economic copyright determines who may reproduce, modify, and distribute the created product; an ordinary licence to use the software does not automatically grant such powers. A subscription to a ready-made platform and an order for a bespoke program should not be assessed in the same way.
At the same time, copyright does not create a monopoly over the idea, method, or calculation principle itself. It protects the specific form in which they are expressed — for example, source code, text, graphics, or the structure of a created map — provided the statutory conditions are met. So control over a digital product is secured not only by rights in the source code but also by access to the necessary materials and documentation and by the ability to lawfully engage another contractor for further work.
A map on screen does not replace verifying land rights
A digital map is convenient for planning sowing, but it only shows the information that has been loaded into it. The actual cultivated boundary, the cadastral boundaries of a plot, and the area stated in the lease agreement or other document evidencing the right to use the land may differ. The software can help spot such a discrepancy, but it will not on its own establish the legal basis for it or correct the documents.
For dealings with the state, the State Agrarian Register is of separate importance. It is an information system for collecting data on agricultural producers and for electronic interaction, including in relation to receiving support. Its legal basis is Law No. 3980-IX and the Cabinet of Ministers procedure approved by Resolution No. 549 of 13 May 2025. A record in the agrarian register should not be treated as a substitute for checking the underlying land documents.
Several sources need to be cross-checked. The State Land Cadastre contains information on land plots. Registered ownership, lease, and other rights in rem, by contrast, are verified against the documents and records of the State Register of Property Rights to Immovable Property. The National Geospatial Data Infrastructure provides access to and exchange of location-linked datasets, but it does not replace checking the cadastre and the register of rights.
For example, before transferring a land bank to a new program, cadastral numbers, areas, contract terms, and their amendments should be reconciled. A land bank in this context means the set of plots the business works with. Without such reconciliation, a new system may simply reproduce the old error faster. In turn, identifying a discrepancy requires establishing its cause, not mechanically correcting a figure in the account.
AI makes recommendations. Who is liable for the outcome?
A program may suggest changing an irrigation schedule, identify a plot showing signs of plant disease, or forecast yield. Such recommendations are useful as an additional decision-support tool. At the same time, it is important to understand which data the program analyses, what conditions it was built for, and what exactly the provider is promising the user: an indicative forecast, risk detection, or execution of a specific operation.
Suppose a system recommended increasing the fertiliser application rate, after which the farm suffered losses. That sequence of events alone is not enough to identify the party at fault. The cause could have been faulty sensor data, a configuration error, a flaw in the program, applying the recommendation outside the conditions it was designed for, or some other circumstance. It will be necessary to establish what obligations each party had, exactly what was breached, and how that connects to the harm.
So the phrase «the algorithm advised it» does not substitute for justifying a production decision. At the same time, one should not swing to the other extreme and assume the agribusiness alone is always liable for any error. Grounds for claims against a developer, an equipment supplier, or another party depend on the specific circumstances and the applicable law.
Before using such a system, it is worth defining which recommendations an agronomist or engineer reviews, when automatic execution must be stopped, and who has the authority to stop it. In case of a potential dispute, it is advisable to keep the input readings, the recommendation, the software version, the time it was applied, and a record of the final decision. This makes it possible to reconstruct the sequence of events rather than argue only about the end result.
Drones: the right to fly and the right to the materials obtained
Filming fields with a drone raises two distinct questions. The first concerns the legality of the flight. The second is what materials and what rights the customer will receive under the contract for aerial photography and processing its results. The party performing this work is the person or company that organises the flight and delivers the agreed materials. Having such a contract, or a right to use the land plot, does not replace compliance with airspace-use rules. Before a flight, applicable permits, approvals, prohibitions, and restrictions for the specific place and time need to be checked, especially in light of the security regime in place.
As for the result of the work, the phrase «deliver a report on crop condition» may prove too narrow. Further analysis by the business may require the raw imagery, coordinates, capture date, and a description of the processing method. Digital maps built from the imagery must be fit for the purpose they were commissioned for. It is also worth establishing whether another specialist would be able to verify the final conclusions based on the materials provided.
The technical brief is part of the contract, or an annex to it, describing the expected results and the acceptance criteria. It should specify which materials will be delivered, in what format, with what accuracy, and whether they may be used in other programs. The retention period for the raw files held by the contractor should also be set separately. If the imagery or the maps built from it are protected by copyright, the contract should explain whether the customer may reproduce, modify, and pass them on to another specialist, and whether the contractor may reuse them for its own purposes. A finished conclusion and the materials needed to verify it are not interchangeable.
An electronic document must remain fit to serve as evidence
The shift from paper to electronic documents changes how they are created and stored, but it does not remove questions of authorship, authority, and the reliability of the content. The law expressly provides that a document's legal force cannot be challenged solely because of its electronic form. A qualified electronic signature has the same legal force as a handwritten one. However, having a signature does not mean nothing further needs to be checked.
For a completion certificate or a goods-acceptance document, it is important to establish who signed it, whether they had the relevant authority, and exactly which version was agreed. An electronic original is not a printout but a file with the mandatory document attributes that make it possible to verify its integrity and the electronic signature. Alongside it, it is advisable to keep the signatory's certificate and records of the time and outcome of the signature check. A screenshot can convey the content but does not always allow all properties of the electronic document to be verified.
At the same time, not all digital information should be reduced to a document that must bear a qualified signature. Requirements depend on the type of document, the operation, and the applicable rules. Correspondence, sensor readings, and user-action logs have a different nature than a signed contract, though they too can be important for establishing the circumstances of a dispute.
The legal force of an electronic document and the manner of submitting electronic evidence to a court are not the same thing. The Commercial Procedure Code distinguishes written and electronic evidence and sets out the forms for submitting them. It is therefore advisable to keep the electronic original together with its metadata — technical information on creation, author, time, changes, and transfer of the file — and with verification tools, rather than relying only on a printout or a screenshot.
A practical risk arises, for example, when several employees share a single account. The system records the action, but identifying the specific person who performed it becomes harder. So individual access, agreed authority, retained change history, and backups should be seen not as a formality but as preparation for a situation in which the business has to prove its own actions.
Cybersecurity begins with one question: how will the business operate after a breach?
A breach or a technical failure can affect more than just confidentiality of information. If warehouse records become unavailable, the business may struggle to ship produce. If an outsider gains access to a mailbox, they may try to substitute payment details. If machinery-operation history is lost, it becomes harder to establish which operations were actually carried out. These are possible risk scenarios, not a claim that every incident inevitably leads to these consequences.
Basic protective measures serve a clearly defined practical purpose. Individual access rights limit the circle of people who can change important data. Multi-factor authentication means that logging in requires not just a password but an additional confirmation, for example through a dedicated app or a security key. A backup makes it possible to restore information, but only if it can actually be used after a failure.
That is precisely why testing recovery is no less important than making copies. It is necessary to know how long it will take to resume operations, how much of the most recent records may be lost, and how the business will operate during that period. For critical operations, it is advisable to plan a temporary way of working without the main program.
The contract with the provider should specify the deadline for reporting an incident, the responsible persons, and the procedure for preserving digital traces. Digital traces here mean login and change logs, system notifications, technical reports, backups, and other records that allow the sequence of events to be reconstructed. It should also be agreed who collects them, how they are protected from alteration, and for how long they are kept. These are practical recommendations, not a uniform statutory list applying to everyone: specific obligations depend on the nature of the activity, the systems, and the information being processed. General cybersecurity principles are set out in Law of Ukraine No. 2163-VIII.
Why EU rules deserve a separate assessment
For a Ukrainian farm operating only in Ukraine, and for a company that sells digital solutions or produce on the market of the European Union (EU), the legal questions may differ. It is important to distinguish direct legal requirements addressed to the company itself from conditions its European counterparty sets while fulfilling its own obligations. The mere fact of cooperating with a foreign business does not automatically make all EU regulations applicable.
Access to machinery data: what the Data Act changes
The EU Regulation on harmonised rules on fair access to and use of data, known as the Data Act, applies, among other things, to connected products. These are machinery or other devices that collect or generate data about their use or environment and can transmit it over a network, a physical connection, or directly from the device. In the agricultural sector, such products can include tractors, combine harvesters, and sensors. The user may be the business that owns the equipment, leases it, or receives a related digital service. The logic of the Regulation is to let such a user, within set limits, obtain the data generated while using the equipment.
The Regulation generally applies from 12 September 2025. A separate obligation under Article 3(1), concerning data availability already at the design stage of the product and when providing a related service, applies to relevant products and services placed on the market after 12 September 2026. The Data Act defines a related service as a digital service without which the product would not perform one or more of its functions, or which adds to or changes those functions. These deadlines and concepts should not be confused.
A Ukrainian company first needs to determine whether the Regulation covers its activity and the specific relationship at issue. The European origin of the equipment does not, by itself, mean a user in Ukraine automatically obtains the full set of rights the Regulation provides. Likewise, access to data is not the same as a right to obtain any analytics or source code from the provider.
A separate set of Data Act rules concerns switching data-processing service providers. This refers to digital services that provide network-based access to computing resources, including cloud storage or processing. The contract should address the terms of switching, the timeframe for assistance, and the ability to export data. This is precisely where EU regulation directly intersects with the platform-dependency risk described at the beginning of this article.
Artificial intelligence: why the system's purpose and the company's role matter
The EU Regulation on artificial intelligence, known as the AI Act, sets different requirements depending on the level of risk, the purpose of the system, and the role of the company. A provider under the Regulation is a person who develops an AI system or model, or has one developed, and then places the resulting product on the market or puts it into service under its own name. A different role, the professional user (deployer), is a company that uses a ready-made system under its own management in its own activity. The AI Act can cover not only participants located in the EU but, under certain conditions, a company outside it as well, if the output of the system is used in the EU. The European origin of a program does not prove this on its own. The analysis should therefore start with the technology's actual function and each participant's role.
An ordinary yield forecast does not automatically become a high-risk system just because it uses artificial intelligence. «High risk» under the AI Act is a legal category for defined uses of AI, not a general assessment of a program's complexity. A different assessment is possible when the system performs a machine safety function that falls under specific EU product-market-access rules, or is such a component and meets the established criteria. Following the 2026 amendments, AI requirements for machinery are being aligned with sectoral product-safety rules. So a tractor or combine harvester does not become «high-risk» merely because it has an intelligent function: its purpose and its effect on safety need to be established.
General application of the Regulation began on 2 August 2026. Following the amendments introduced by EU Regulation 2026/1744, the requirements for the defined high-risk systems under Annex III, which lists specific AI use cases, will apply from 2 December 2027. For systems linked to products regulated under the acts listed in Annex I, the relevant date is 2 August 2028. Other deadlines apply to certain specific provisions.
Product origin: why the buyer needs data on a specific field
The EU regulation on deforestation-free products, known by the abbreviation EUDR, sets requirements not for the entire agricultural export sector but for defined commodities and products on an established list, including soy, cattle, timber, and certain derived products. Checking applicability requires the specific commodity and its code, not just the general name of the sector.
Direct obligations under the EUDR fall on defined EU-market participants. An operator is a person who, in the course of commercial activity, first places relevant products on the EU market or exports them, while a trader is another supply-chain participant who subsequently offers such products on that market. To confirm that a product is deforestation-free and legally produced, they may need information on the place of production, the origin of raw materials, and the link between a specific batch and particular plots of land. A Ukrainian producer may pass on such data under a supply contract with the buyer, even if it is not itself a direct addressee of all the requirements of this Regulation.
The main requirements will apply from 30 December 2026. A transitional period until 30 June 2027 is provided only for operators that are natural persons or micro- or small enterprises established in that status before 31 December 2024. This deferral does not extend to products that were already covered by the previous EU regulation on timber.
This is precisely where systems for tracking the origin and movement of produce become practically important. They should help link a batch to its sources, not merely store a scanned certificate. If batches of different origin are mixed, it is necessary to think in advance about how to maintain the required link between records. A digital system does not, on its own, confirm the legality of a product, but it can help gather and verify the relevant information.
Personal data: working only with companies does not remove the question
The EU General Data Protection Regulation, known as the GDPR, protects the data of natural persons. So an agribusiness's activity may involve data relating to employees as well as contact details of buyers, suppliers, or farmers. The mere presence of personal data, however, does not automatically mean this particular regulation applies: its territorial scope must be checked first.
Article 3 of the GDPR extends the Regulation, among other things, to processing in the context of the activities of an establishment of a company in the EU, such as its office or another unit. In defined circumstances, the Regulation also covers companies outside the EU if they offer goods or services to people in the EU or monitor their behaviour there. Neither an individual's nationality nor the presence of a European counterparty replaces this analysis. If the GDPR applies, it is necessary to determine the legal basis for processing, properly inform individuals, put in place arrangements with external processors that handle personal data on the customer's instructions, and address the transfer of data abroad.
Where an agribusiness owner or manager should start
Step one: map the real processes — which programs are needed daily, where information on fields, machinery, inventory, and calculations is stored, who has access, and what would stop working if a service became unavailable. This lets the business separate critical systems and data from auxiliary ones.
Step two: determine which legal rules apply to that information and to evidence. For each category, the basis for processing, rights of use, and access and storage rules need to be established, and land records and electronic documents should be verified against proper sources rather than relying solely on images shown in the system.
Step three: cross-check this picture against the contracts and technical procedures. They should clearly define service functionality, support, liability, cyber protection, backups, disaster recovery, and the terms for switching to another provider. Employees' expectations should match what the business has actually purchased.
Step four: separately check the requirements of target markets — access to connected-machinery data, the use of AI, product traceability, and personal-data protection. For one farm, the land bank will be the priority; for another, it will be migrating production history or preparing data for a European buyer. Legal support for digitalisation should ensure the availability of information, the lawfulness of its use, and a clear allocation of responsibility — ideally before a technology is launched, while terms can still be negotiated.
Disclaimer. This material is informational and explanatory in nature and is not individual legal advice. The regulatory provisions are stated as of 8 September 2026. The examples are hypothetical and do not describe specific clients or court cases. The applicability of the rules and contractual solutions depends on the actual circumstances.
Sources: European Commission — overview of the digitalisation of agriculture and rural areas; Civil Code of Ukraine; Law of Ukraine «On Personal Data Protection»; Law of Ukraine «On Copyright and Related Rights»; Law of Ukraine No. 3980-IX «On the Information and Communication System “State Agrarian Register”» and Cabinet of Ministers Resolution No. 549 of 13 May 2025; Law of Ukraine «On the State Land Cadastre»; Law of Ukraine «On the National Geospatial Data Infrastructure»; Air Code of Ukraine and Cabinet of Ministers Resolution No. 954; Law of Ukraine «On Electronic Documents and Electronic Document Flow»; Law of Ukraine «On Electronic Identification and Electronic Trust Services»; Law of Ukraine «On the Basic Principles of Ensuring Cybersecurity of Ukraine»; Regulation (EU) 2023/2854 (Data Act); Regulation (EU) 2024/1689 (AI Act) as amended by Regulation (EU) 2026/1744; Regulation (EU) 2023/1115 (EUDR) as amended by Regulation (EU) 2025/2650; Regulation (EU) 2016/679 (GDPR); Law of Ukraine «On State Registration of Property Rights to Immovable Property and Their Encumbrances»; Commercial Procedure Code of Ukraine.
This material is informational and analytical only, reflects a general overview of legislation and practice as of the publication date, and is not individual legal advice, a legal opinion, or a guarantee of any case outcome.