TL;DR
The EU AI Act reached general application on 2 August 2026, and with it the Article 50 transparency duties that bind agritech AI regardless of risk tier. Most agronomic decision-support AI is not Annex III high-risk by default, because the food sector is absent from Annex III, though three named edge cases and a profiling carve-out can change that. The heaviest high-risk obligations now fall due on 2 December 2027 and 2 August 2028, which is real runway but not an exemption. The artefacts the Act asks for, logging, human oversight, technical documentation and transparency, are properties of a well-built AI harness, not paperwork bolted on after ship.
Does the EU AI Act Apply to Your Agritech AI Product?
2 August 2026 is the date the EU AI Act stopped being a legal memo and became an engineering backlog. That is when the Regulation reached general application, and with it the transparency duties that bind AI systems regardless of their risk tier.
If you build farm-management software, an agronomy copilot, or a crop-insights model for the EU or UK market, the first question about how the EU AI Act applies to agritech AI is the plain one: does it apply to you? Yes. It applies. The more useful question is which tier you land in. Most agronomic decision-support and recommendation AI is not Annex III high-risk by default. The food sector is absent from Annex III's list of high-risk use cases, so scoring a field, recommending a spray rate, or flagging disease pressure does not, on its own, put you in the heavy regime.
Two conditions sit on that "by default": three named edge cases can pull a feature into high-risk, and a profiling carve-out can override the exception entirely. The next section names those edge cases with their Annex references; the one after pins the dates. The thesis underneath the whole piece is that the artefacts the Act asks for are properties of a well-built AI harness, not paperwork bolted on after ship.
High-Risk Classification Under the EU AI Act: Three Edge Cases for Agritech
High-risk status arises two ways under the Act. A system is high-risk either as a safety component of a product covered by Annex I harmonisation law that already requires third-party conformity assessment (Article 6(1)), or as one of the enumerated Annex III use cases (Article 6(2)). Three edge cases put agritech features into those brackets, and two of them are the ones a software vendor is most likely to meet.
The first is employment and worker management, an Annex III point 4 use case under Article 6(2). It covers recruitment and selection, task allocation based on individual behaviour, and monitoring or evaluating performance. A farm-labour scheduling or performance feature lands here, which makes it high-risk under the AI Act for agriculture, regardless of how routine it feels.
The second is credit, subsidy or benefit eligibility scoring, an Annex III point 5 case. Point 5(a) covers AI used by or for public authorities to decide eligibility for essential public benefits, so a CAP-style subsidy model qualifies; point 5(b) covers scoring the creditworthiness of natural persons, so agri-credit scoring qualifies, though fraud detection is excluded. Both are Annex III high-risk AI.
The third binds machinery builders rather than most software vendors: an AI safety component embedded in autonomous machinery, high-risk under Article 6(1) via Annex I instruments such as the Machinery Regulation (EU) 2023/1230 and Regulation (EU) No 167/2013 for agricultural and forestry vehicles. There is no separate AI approval track. Article 103 folds the AI Act obligations for such an Annex I safety component into the existing 167/2013 type-approval, assessed under Article 8.
One guardrail holds the "not high-risk" claim honest. The Article 6(3) exception never applies to a system that profiles natural persons, which is always high-risk. So: not high-risk by default, provided you have checked these three cases and you are not profiling people.
AI Act Transparency Requirements 2026: Article 50 Duties That Apply Regardless of Tier
This obligation does not wait for the classification question to resolve. Article 50 transparency obligations apply to whole categories of AI system independent of their risk tier, so they can bind a product that is not high-risk at all.
Article 50 sets three duties:
- A provider of a system meant to interact directly with people must design it so those people are told they are dealing with an AI system.
- A provider of a system that generates synthetic audio, image, video or text must mark the output in a machine-readable form that is detectable as artificially generated.
- A deployer of a system that produces deepfakes or AI-generated text must disclose that the content is artificially generated or manipulated.
These AI Act transparency requirements 2026 govern the specified categories whether or not the system is high-risk.
The timing is settled. Article 50 sits inside general application from 2 August 2026 and was not deferred by the Digital Omnibus, which left the 2 August 2026 general application and these transparency duties untouched.
Split the engineering work honestly. Duty one mostly maps onto disclosure a product already shows in its interface. Duty two is different: machine-readable marking of synthetic output is a provenance build at the generation layer, not a relabel of the UI.
The AI Act Compliance Timeline: What's Due Now and What Has Runway
Three dates set the AI Act risk tiers on a calendar, and each is settled law. General application began on 2 August 2026. That date carries the Article 50 transparency duties and the classification work every provider has to do, and the Digital Omnibus left it untouched.
The two high-risk triggers then fall on different days, and they should not be blurred into one deadline. Annex III standalone high-risk systems under Article 6(2), which is where the worker-management and eligibility-scoring edge cases sit, apply from 2 December 2027. Annex I embedded safety components under Article 6(1), the autonomous-machinery case, apply from 2 August 2028.
The Digital Omnibus AI Act amendment moved those two dates because the harmonised technical standards were not ready in time. It did not soften the obligations. This is runway on the heaviest work, not an exemption, and it does not touch the transparency duties already in force.
So the honest reading is straightforward. Classification and transparency are due now; the high-risk build has a defined finite runway of December 2027 or August 2028, depending on which trigger applies to you.
Four AI Act Requirements, Four Harness Components
When the high-risk regime does apply, its Chapter III requirements read like a description of a well-built AI harness. Four of them map onto components I have argued for in my own writing.
AI Act record-keeping and logging under Article 12 maps onto sensors and traces: the run-time record of what the system saw and did. The retention obligation is worth pinning precisely, because it is easy to misattribute: logs must be kept for at least six months, and that duration lives in Article 19(1), not in Article 12. If you built the harness I have written about, the sensors-and-traces and escalation layer already produces this record as a matter of course.
Human oversight under Article 14 maps onto guides and escalation paths: the routes by which a person can review, intervene in, or stop the system. Human oversight in the AI Act is a design property, and that same harness engineering write-up is where I set out those paths.
Technical documentation under Article 11 and Annex IV maps onto the eval and metrics discipline. Technical documentation for the AI Act is far easier to assemble from evals you already run than from a blank page, which is the case I make in my Season 1 pilot-metrics write-up.
Transparency to deployers under Article 13, which is distinct from the Article 50 duties covered earlier, maps onto the disclosure surface already built into the product's interface.
Record-Keeping at the Field Edge: A Preview
Record-keeping changes shape the moment the agent runs offline. In the field, connectivity is a design constraint from day one, not an edge case you discover in production - it is one of the places agritech AI pilots fail at the field gate, as I have written elsewhere. Keeping a compliant record when the network is not there is its own architecture, and the subject of the next piece in this series. This is the preview, not the treatment.
The AI Act Engineering Checklist for Agritech
This checklist runs against one feature that is live or in EU-market pilot. Each line is an action, what to look for, and an agritech example. The shape is vertical-agnostic, so a reader outside agritech can reuse it and swap the examples.
1. Classification (yes/no/depends). Is the feature an Annex III use case, or a safety component of an Annex I product? If neither, it is not high-risk by default. Example: a yield-recommendation model is normally neither; a farm-labour scheduling feature is Annex III point 4.
2. Profiling carve-out (yes/no). Does the feature profile natural persons? If yes, it is high-risk regardless of any exception. Example: scoring individual workers on behaviour.
3. Transparency duties (yes/no). Does the feature talk to a person, or generate synthetic content? If yes, Article 50 disclosure and marking apply now, whatever the tier. Example: a copilot assistant needs an "you are talking to an AI" disclosure string.
4. Record-keeping (yes/depends). Do you log what the system saw and did, retained for at least six months? Example: traces for every agronomic recommendation the agent issued.
5. Human oversight (yes/depends). Can a person review, override, or stop the system? Example: an agronomist can reject a spray-rate suggestion before it reaches the sprayer.
6. Technical documentation (yes/depends). Can you produce the Annex IV pack from evidence you already hold? Example: your existing eval and metrics runs.
7. Autonomous machinery (flag for review). Does the feature act as a safety component in an Annex I machine? If so, route it to product-level type-approval, not a separate AI track. Example: an AI function governing an autonomous tractor's stop behaviour.
This kind of pass is what precision agriculture AI regulation rewards: most EU AI Act agritech features clear lines 1 to 3 quickly and leave only a few "depends" rows for the close of this piece.
What This Is, and What It Is Not
The proof behind this piece is class-level. We have built at the FMS and machine-guidance integration layer, and a geospatial ML crop-insights web application - our own Spyrosoft Innovo work, not client casework. The harness and pilot-metrics posts linked above are my own writing on Athru IT.
The limit is just as plain. This is an engineering translation of a live regulation, written to help you turn compliance with the AI Act for AI systems in agriculture into tickets you can act on. It is not legal advice. If you have an actual compliance decision in front of you, one where the answer changes what you ship or how you are exposed, that decision belongs with your own counsel.
Your Harness Already Does Most of This
Now that the evidence is in, the thesis holds in its earned form. A team that built the harness I have argued for, with its sensors and traces, its guides and escalation paths, and its eval and metrics discipline, already holds most of what the Act asks of a high-risk system. The Act becomes a forcing function for that discipline rather than a new project.
So here is the one thing to do with this piece. Run the checklist above against one AI feature you already have in production or pilot this week, and flag anything that lands in a "depends" row to your own counsel before you file it as decided.
FAQ
Does the EU AI Act apply to agriculture?
Yes. The Act applies across sectors from its general application date of 2 August 2026, so agricultural AI is in scope. What it does not do is place most food-system and agronomic AI in the high-risk tier, because the food sector is absent from the Annex III list of high-risk use cases.
What AI systems are high-risk under the EU AI Act?
A system is high-risk in one of two ways: as a safety component of an Annex I product that needs third-party conformity assessment under Article 6(1), or as one of the enumerated Annex III use cases under Article 6(2). For agritech, the Annex III cases that bite are worker management (point 4) and eligibility scoring (point 5).
When does the EU AI Act apply to high-risk systems?
General application began on 2 August 2026. Under the Digital Omnibus timeline, Annex III standalone high-risk systems apply from 2 December 2027, and Annex I embedded safety components from 2 August 2028.
What are the transparency obligations under the EU AI Act?
Article 50 sets three duties: tell people when they are interacting with an AI system, mark synthetic audio, image, video or text so it is machine-readable and detectable as artificial, and disclose AI-generated or manipulated content when you deploy it. These bind the specified system categories regardless of risk tier.
Is farm management software covered by the AI Act?
It is in scope, but it is usually not high-risk. Ordinary farm-management features such as field scoring or input recommendations are not Annex III use cases. The exception is a feature that manages workers, scores eligibility, or profiles natural persons, which pulls it into the high-risk tier.
Does the AI Act apply to autonomous tractors?
Where an AI function is a safety component of the machine, yes: it is high-risk under Article 6(1) as an Annex I product, via Regulation (EU) No 167/2013 for agricultural vehicles. Article 103 then folds those obligations into the existing type-approval rather than a separate AI track.