EU Drone Regulation
Autonomous Drones in the EU — Part II: Where Aviation Certification Ends and Product Regulation Begins
Part I mapped the boundary between EU aviation certification and the Cyber Resilience Act. Part II moves beyond that boundary to examine the wider regulatory architecture governing autonomous UAS — from the AI Act and data rules to cybersecurity, product liability and dual-use controls — and how these regimes interact across a single drone system.
Complex law. Clear action.
Reviewed by Oleksandr Sobovyi, Founder & CEO of CORVUS AI — editorial responsibility statement below.
The first part of this analysis addressed the boundary between EU aviation certification and the Cyber Resilience Act.
That boundary is only the beginning.
Once an autonomous UAS incorporates machine-learning functionality, computer vision, biometric identification, radio communications, cloud infrastructure or dual-use technology, a second set of regulatory questions emerges.
The key issue is no longer whether one additional regulation applies.
It is how several legal regimes attach to different functions, products and actors within the same system.
13. Why autonomous flight changes the assurance problem
Traditional aviation software assurance works most comfortably where system behaviour can be specified, tested and verified against relatively deterministic requirements.
Machine-learning systems complicate that model.
An AI-enabled UAS may use neural networks for:
object recognition;
landing-zone identification;
obstacle avoidance;
target or asset recognition in civilian inspection;
visual navigation;
sensor fusion;
trajectory optimisation;
anomaly detection;
mission replanning;
or adaptive control.
The manufacturer may need to consider:
training-data quality;
representativeness;
robustness outside the training distribution;
adversarial manipulation;
sensor spoofing;
model substitution;
poisoned training or update data;
model drift;
explainability;
validation coverage;
human oversight;
and safe behaviour under uncertainty.
This creates an emerging AI assurance problem inside aviation assurance.
On 3 June 2026, EASA published Proposed Issue 3 of its Artificial Intelligence Concept Paper, continuing the development of its aviation AI assurance framework.
Advanced aviation AI is therefore entering a certification environment whose assurance methodology continues to develop.
14. The AI Act can apply through several independent routes
Where autonomous functionality qualifies as an AI system, the AI Act must be analysed separately from the aviation and CRA classifications.
One route is Article 6(1).
Article 6(1) provides a high-risk classification mechanism for AI systems intended to be used as a safety component of a product — or themselves constituting a product — covered by specified Union harmonisation legislation where that product is required to undergo third-party conformity assessment.
For aviation AI, the analysis may therefore proceed through the regulated-product route:
UAS function
→ determine whether it constitutes an AI system;
→ determine whether it performs a safety-related function;
→ identify the relevant aviation product legislation;
→ determine whether third-party conformity assessment is required;
→ assess Article 6(1) high-risk classification;
→ determine the applicable AI Act obligations;
→ separately determine CRA applicability or exclusion.
There is, however, a separate route under Article 6(2) and Annex III.
Annex III, point 1, covers specified AI systems intended to be used for biometric identification and categorisation of natural persons, subject to the qualifications and exclusions laid down in the AI Act.
This high-risk classification does not depend on the aviation product route under Article 6(1).
An AI-enabled drone used to identify natural persons can therefore raise an Annex III high-risk issue even where the biometric function is not part of a safety component and irrespective of whether the aircraft itself follows an aviation conformity-assessment route.
This distinction is particularly relevant outside law enforcement.
For example, a drone deployed by a private security operator for perimeter control or access monitoring may use biometric identification without falling within the law-enforcement prohibition in Article 5(1)(h). The biometric AI function may nevertheless require a separate assessment under Article 6(2) and Annex III.
The classification should therefore distinguish three scenarios:
computer vision / object detection
→ does not, by itself, amount to biometric identification;
AI intended for biometric identification of natural persons
→ assess Article 6(2) and Annex III independently of the aviation-product route;
real-time remote biometric identification in publicly accessible spaces for law-enforcement purposes
→ analyse Article 5(1)(h), its exceptions and applicable safeguards.
The intended use of the AI functionality is therefore as important as its technical architecture.
Aviation classification alone cannot resolve the AI Act position.
15. Computer vision also creates a GDPR perimeter
A drone equipped with high-resolution cameras, thermal sensors or other computer-vision systems may process personal data where individuals are identifiable directly or indirectly.
Depending on the use case, relevant data may include:
images of individuals;
vehicle registration plates;
location information;
movement patterns;
identifiable property or behavioural information;
and, in some circumstances, biometric data.
The GDPR therefore requires a separate assessment of:
lawful basis;
purpose limitation;
data minimisation;
transparency;
retention;
controller/processor allocation;
security of processing;
international transfers;
and, where relevant, special-category data.
A Data Protection Impact Assessment is not automatically mandatory for every camera-equipped drone.
Article 35 GDPR requires a DPIA where the envisaged processing, particularly using new technologies and considering its nature, scope, context and purposes, is likely to result in a high risk to individuals' rights and freedoms.
A DPIA is expressly required, among other cases, for systematic monitoring of a publicly accessible area on a large scale.
Systematic or large-scale drone surveillance, infrastructure monitoring in populated environments or persistent computer-vision operations can therefore require a DPIA even where the underlying UAS has completed its aviation and product-conformity route.
16. Autonomy creates security threats that cross regulatory categories
A conventional cybersecurity attack may seek unauthorised access to a flight-control system.
An AI-related attack may instead manipulate the system's perception of reality.
Examples include:
adversarial visual patterns causing misclassification;
GNSS or sensor spoofing affecting model inputs;
poisoned training data;
compromised model-update packages;
unauthorised model replacement;
manipulation of remote inference services;
attacks against the integrity of mission-planning data.
The consequences can simultaneously affect:
cybersecurity, because system integrity is compromised;
airworthiness, because flight safety is affected;
AI robustness, because the model fails under manipulated conditions;
and potentially product liability, where the resulting behaviour causes damage.
The more integrated the autonomy stack becomes, the less useful it is to analyse each EU regulation in isolation.
17. Product liability changes the consequences of technical complexity
Directive (EU) 2024/2853 modernises the EU product-liability framework for digital products and expressly accommodates software and AI-related technologies.
This matters particularly for autonomous UAS because the technical chain leading to damage may be extremely difficult for an injured person to reconstruct.
A failure might arise from:
software;
a sensor;
a machine-learning model;
a corrupted update;
interaction between several components;
remote processing;
cybersecurity compromise;
or an unsafe change introduced after market entry.
Where a claimant faces excessive difficulties in proving defectiveness or causation because of the technical or scientific complexity of the case, the Directive permits presumptions under specified conditions.
The Directive expressly identifies machine learning and situations requiring a claimant to explain the internal workings of an AI system as examples relevant to this complexity assessment.
Technical opacity should therefore not be treated as a litigation shield.
For a complex autonomous UAS, poor documentation of:
system architecture;
software versions;
risk assessments;
updates;
model changes;
supplier dependencies;
cybersecurity events;
and conformity decisions
may become relevant both to regulatory compliance and to the manufacturer's ability to defend a subsequent product-liability claim.
Before moving further into market-entry timing and cross-border regulatory consequences, it is worth closing two remaining CRA-scope questions that affect the architecture of every regime discussed above.
18. The CRA aviation exclusion should not be overextended
Article 2(3) CRA excludes products with digital elements certified in accordance with Regulation 2018/1139.
Its wording attaches the exclusion to products with digital elements that have been certified.
Suppose an autonomous aircraft is aviation-certified, while the manufacturer separately offers:
fleet-management software;
a ground-control application;
a cloud mission-planning service;
a separately marketed communications module;
or a software development kit.
Those products should not automatically be treated as excluded merely because they interact with a certified aircraft.
The key question remains:
Was the relevant product itself certified within the aviation regime, or is it a separate product with digital elements?
19. Export control can be the first market-entry gate
For dual-use or defence-derived UAS, the first legal question may arise before CRA, aviation certification or AI Act classification.
Regulation (EU) 2021/821 establishes the Union regime for control of exports, brokering, technical assistance, transit and transfer of dual-use items.
Manufacturers should determine whether the UAS, relevant components, software or technology fall within Annex I or another applicable export-control mechanism before assuming that technology can be transferred into or out of the Union without authorisation.
Not every autonomous UAS is automatically a controlled dual-use item.
The EU Dual-Use List nevertheless expressly includes certain UAVs. Entry 9A112, for example, covers UAVs meeting specified technical criteria.
Other UAS technologies can also raise classification issues under categories dealing with:
navigation;
sensors;
telecommunications;
information security;
propulsion;
aerospace technologies;
software;
and technical data.
For defence-derived platforms, a separate military-list analysis may be necessary.
For a non-EU or Ukrainian developer, the sequence may therefore begin with:
technology and product classification
→ military / dual-use determination
→ export, transfer and technical-assistance analysis
→ EU industrial or importer structure
→ aviation and product market-access analysis.
20. Dual-use and defence drones require a separate analysis
The CRA expressly excludes products with digital elements developed or modified exclusively for national-security or defence purposes, as well as products specifically designed to process classified information.
The word exclusively matters.
A drone platform initially designed for military use does not necessarily remain outside the CRA if a civilian or commercial variant is subsequently marketed in the Union.
Likewise, a dual-use product cannot automatically rely upon the defence exclusion merely because defence customers use it.
The manufacturer's:
intended purpose;
product configuration;
marketing;
contractual restrictions;
technical specification;
and actual placement on the market
may all become relevant when defining the regulatory perimeter.
For Ukrainian and other non-EU UAS manufacturers entering the European market, a civilian version of an existing defence platform therefore requires a fresh regulatory analysis.
21. 11 September 2026 is an immediate CRA date — but not the full compliance date
The CRA generally applies from 11 December 2027.
Article 14 reporting obligations apply from 11 September 2026, while the conformity-assessment-body provisions in Chapter IV have applied since 11 June 2026.
Article 14 introduces reporting obligations concerning, among other matters, actively exploited vulnerabilities and severe incidents affecting product security.
From September 2026, this does not mean that every UAS manufacturer must already demonstrate full CRA product conformity.
Nor should December 2027 be treated as the date on which preparation begins.
For manufacturers developing products now, architecture decisions being taken in 2026 may determine whether compliance in 2027 is manageable or requires significant redesign.
22. The real bottleneck is regulatory architecture
The harder questions are architectural and organisational:
Which legal entity is manufacturer of which product?
What is aviation-certified?
What remains under CRA?
What remains subject to RED?
What is high-risk AI under Article 6(1)?
What falls independently under Article 6(2) and Annex III?
Does the use case trigger Article 5?
Does the payload process personal data?
Is the operator independently subject to NIS2?
Is the technology controlled for export?
Which cloud services form part of the regulated product?
Which supplier controls are required?
Which conformity-assessment route applies?
Which modifications create a new regulatory event?
A technically secure product can still have a poor EU market-access strategy if the manufacturer cannot map its technical evidence onto the correct legal regime.
23. Software updates create a particularly difficult UAS issue
Autonomous UAS evolve rapidly.
AI-enabled products may evolve through frequent software or model updates.
This raises several questions.
When does an update merely maintain cybersecurity?
When does it change functionality?
When does it modify the safety case?
When does it affect an existing aviation approval?
When can it amount to a substantial modification for CRA purposes?
When does changing an AI model require renewed AI Act conformity work?
This makes change classification a critical governance function.
Manufacturers should therefore develop a regulatory change-control mechanism alongside technical configuration management.
24. Rapid development and EU compliance are not necessarily incompatible
A major source of delay is often late regulatory integration.
A developer may reach a technically mature prototype before discovering that:
the product architecture does not match the intended certification route;
supplier contracts do not provide necessary evidence;
software dependencies cannot be documented;
model-training records are incomplete;
cloud architecture creates unexpected CRA exposure;
radio components follow a separate RED route;
the operating model creates NIS2 obligations;
computer vision requires a GDPR DPIA;
export-control restrictions affect technology transfer.
At that stage, compliance becomes expensive because the evidence must be reconstructed after the engineering decisions have already been made.
The stronger model is:
classify → design → generate evidence → validate → assess → deploy → monitor.
For autonomous UAS, regulatory engineering should start at system architecture.
25. What this means for non-EU manufacturers
For manufacturers outside the Union, including Ukrainian UAS companies, EU market access should begin with a Regulatory Architecture Review.
The manufacturer should establish:
Trade architecture
Can the product, software and technology legally be transferred, exported or imported?
Product architecture
What exactly will be placed on the EU market?
Operational architecture
How and where will the UAS operate?
Legal architecture
Which rules govern each product and function?
Conformity architecture
Which evidence and external assessments will be required?
Data and cybersecurity architecture
Which CRA, GDPR and NIS2 obligations attach to the manufacturer, product and operator respectively?
Contractual architecture
Which entity carries which responsibility?
Without that exercise, the manufacturer risks optimising its product for a regulatory route that does not actually apply.
Conclusion
The regulatory challenge facing autonomous drone manufacturers in Europe is often described as a cybersecurity certification problem.
That understates it.
The central issue is determining which EU regime applies to which part of the autonomous system, at which stage of its lifecycle, and through which conformity route.
The AI Act creates several distinct routes. Safety-related aviation AI may become high-risk through Article 6(1). Separately, biometric identification systems may enter the high-risk regime through Article 6(2) and Annex III even without relying on the aviation-product route. Real-time remote biometric identification for law-enforcement purposes in publicly accessible spaces requires a separate Article 5(1)(h) analysis.
GDPR may apply to computer-vision and sensor operations involving identifiable persons.
NIS2 may independently regulate the operator and its digital infrastructure.
For dual-use and defence-derived systems, export-control classification may arise before the remaining market-access questions.
Under the new Product Liability Directive, the technical complexity of autonomous AI systems does not necessarily protect manufacturers from liability.
The consequence is not a simple requirement to audit code before entering Europe.
It is a need to design the product, certification strategy, cybersecurity framework, AI governance, data architecture, export-control strategy and contractual supply chain as one coherent regulatory architecture.
For developers of autonomous UAS, the critical question is:
Which legal regime must establish the safety and security of which component, through which conformity-assessment route?
That boundary should be identified before the product reaches the certification stage.
By then, changing it may already be expensive.
Disclaimer
This article has been prepared by CORVUS AI for general informational and educational purposes only. It is intended to make complex legal and regulatory developments easier to understand.
It does not constitute legal advice and does not create a professional adviser–client relationship. The information should not be relied upon as a substitute for advice based on the specific facts, circumstances and applicable law relevant to your organisation or project.
The article reflects our understanding of the law and regulatory framework as of the date of publication. Legislation, case law, regulatory guidance and administrative practice may subsequently change. While reasonable care has been taken in preparing this article, CORVUS AI does not warrant that the information is complete or remains current after the date of publication. We do not undertake to update this content.
To the fullest extent permitted by applicable law, CORVUS AI excludes liability for loss arising from reliance on this article. Nothing in this article constitutes an offer or solicitation to provide regulated legal services in any jurisdiction where doing so would be unlawful.
AI-assisted preparation: This article was prepared with the assistance of AI tools. Its legal analysis, conclusions and final text were subject to human review and editorial control and were reviewed and approved prior to publication by Oleksandr Sobovyi, Founder & CEO of CORVUS AI. CORVUS AI retains editorial responsibility for the published content.
For advice tailored to your organisation, project or specific circumstances, please contact CORVUS AI.
Key sources
Appendix — EU Autonomous UAS Regulatory Architecture Checklist
Step 1 — Define the intended product and use
Document:
intended operational environment;
users;
payload;
level of autonomy;
BVLOS/VLOS operation;
geographic environment;
human intervention capability;
civilian, dual-use or defence purpose.
Step 2 — Perform export-control classification where relevant
Determine:
whether the UAS, components, software or technology are controlled;
whether military-list classification applies;
whether Regulation 2021/821 applies;
whether export, transfer, brokering or technical-assistance authorisation may be required.
Step 3 — Determine the aviation route
Analyse:
Regulation 2018/1139;
Implementing Regulation 2019/947;
Delegated Regulation 2019/945;
relevant SORA requirements;
Special Condition Light-UAS;
applicable EASA means of compliance.
Determine whether the system falls into:
open → specific → certified
and whether design verification or certification is required.
Step 4 — Define the system boundary
Map:
aircraft;
flight controller;
communications;
payload interfaces;
embedded software;
ground-control system;
cloud;
APIs;
mobile applications;
update infrastructure;
AI components.
Step 5 — Perform CRA product classification
For every relevant element determine:
whether it is a product with digital elements;
whether it is separately placed on the market;
whether remote data processing is part of it;
whether an Article 2 exclusion applies;
whether it is standard, important or critical under the CRA.
Step 6 — Map the aviation exclusion
Identify exactly which products have been or will be certified under Regulation 2018/1139.
Step 7 — Determine the RED route
For radio-enabled components determine:
whether Directive 2014/53/EU applies;
which essential requirements apply;
how the RED cybersecurity transition affects the product;
whether separate conformity evidence is required.
Step 8 — Analyse AI Act classification
For every autonomous function determine:
whether it qualifies as an AI system;
whether it performs a safety function;
whether Article 6(1) applies;
whether Article 6(2) and Annex III apply independently;
whether biometric identification is involved;
whether Article 5 restrictions are engaged.
Step 9 — Analyse data protection
Determine:
lawful basis;
controller/processor allocation;
transparency;
data minimisation and retention;
biometric-data implications;
whether a DPIA is required;
whether international-transfer restrictions apply.
Step 10 — Determine whether NIS2 applies to the operator
Map:
relevant network and information systems;
incident-reporting responsibilities;
supply-chain dependencies;
ground-control and cloud infrastructure;
governance and cybersecurity-risk-management obligations.
Step 11 — Build cybersecurity evidence into development
Create evidence covering:
cybersecurity risk assessment;
threat modelling;
secure development;
component inventory;
SBOM;
authentication and access controls;
secure communications;
update integrity;
vulnerability handling;
incident management;
supplier dependencies.
Step 12 — Align supplier contracts
Ensure suppliers can provide the technical and regulatory evidence required for:
aviation assurance;
CRA conformity;
RED compliance;
AI Act documentation;
GDPR compliance;
NIS2 supply-chain governance where relevant;
vulnerability remediation;
post-market monitoring.
Step 13 — Establish regulatory change control
Before major software, firmware, model or architecture updates, determine whether the change affects existing conformity, certification, data-protection, export-control or liability conclusions.
Step 14 — Preserve the evidence
Maintain traceable:
design decisions;
version control;
test results;
risk assessments;
model changes;
cybersecurity records;
supplier documentation;
conformity decisions.
