If you work in agriculture or agritech, you’ll know that the last few years have brought a continuous stream of amazing technology announcements. Tiny, embedded devices that watch machinery and animals in motion or sense environmental factors. An array of low-earth orbit satellites continuously imaging our earth. Artificial intelligence (AI) applications that will identify disease, calculate emissions, or tell you which seed variety to plant. A common thread is the greater collection and use of data, by sophisticated computer software operating in the cloud.
For many farmers, this might sound like an Orwellian nightmare: their farm and activities under continuous observation; remote decision making; and the threat of a remote “big brother” making judgements.
It’s fair to ask whether the benefits that technology promises are worth the loss of privacy and control. Farmers, their suppliers, and their downstream customers won’t make widespread use of sensing, AI, automation, and other technology trends unless the questions of trust, control, and security can be satisfied.
Fortunately, in the same way that technology is bringing us new solutions for collecting and interpreting data, progress is being made in the components needed to support digital trust across the industry.
One of the key needs is a coordinated model for data permissions. Those who create data in their business (or more precisely, about whose business the data is collected) need to control how that data is used.
This is not just a case of restricting access. Indeed, it may be one of extending access – being able to give appropriate data access to staff and co-workers, or to vets and agronomists. Farmers and growers may want to provide subsets of data to supply chain partners, input suppliers, or software tools of their choice. They may need to control the types of data accessed, agree the purpose of access, and even change their mind and remove access.
The solutions are likely to be a mixture of organisational and technical.
- At the organisational level, initiatives such as the NZ and UK Farm Data Codes of Practice, or the USA Farm Bureau Federation’s privacy and security principles help to establish the mandate for farmer and grower control of their data and to provide the principles that will underpin future data access agreements. There are opportunities for industry organisations and farming unions to ensure that farmers, growers, and their partners all understand their rights and responsibilities when it comes to digital data.
- Existing Internet frameworks such as access tokens (there’s a common scheme called OAUTH), and user-managed authentication (UMA) provide a partial solution, and new agritech platforms are starting to make use of this technology.
- Digital Data Access Agreements take this a step further – documenting, and potentially enforcing access agreements between organisations that create data and organisations which can use that data.
- There is potential for distributed ledger technology to enable these data access agreements. Distributed Ledger technology is the cryptographic engine that underpins blockchain and crypto currencies: but you can use distributed ledgers without speculating on digital coins. This technology might allow digital signing of structured data access agreements – in a way that the signatures can’t be lost or fraudulently generated, and all changes and approvals recorded over time.
While the underpinning technologies are still evolving, trusted industry data hubs and controls are starting to provide farmers with the control and delegation they need. Our Pure Farming platform is among them. It allows farmers to define data access permissions at a variety of scales, to other software systems, organisations, and individuals.
Are you a farmer, a developer of agritech software, or using farm data to support farmers or supply chains? We’re interested in your experience with accessing ag data, and the codes and agreements around the use of data. Drop us a line at the link below, and we’ll anonymise and summarise the responses in a future post.