If you develop AI systems for radio equipment, software-defined radio platforms, cognitive radio networks, or emergency radio beacons placed on the EU market, Article 109 of the EU AI Act directly governs your compliance obligations. EU AI Act Art.109 amends Directive 2014/53/EU — the EU Radio Equipment Directive (RED) — to formally integrate EU AI Act requirements into the radio equipment conformity framework, extending the high-risk AI pathway to AI-enabled spectrum management, adaptive radio, and emergency radio systems carrying CE marking under the RED.
The amendment follows the same Annex I bridge mechanism as Art.105 (agricultural vehicles), Art.106 (two/three-wheel vehicles), Art.107 (motor vehicles), and Art.108 (marine equipment): AI systems embedded in radio equipment that qualify as spectrum management, interference control, or safety-of-life radio components under Directive 2014/53/EU now sit within EU AI Act Annex I, activating the Art.6(1) high-risk pathway and triggering the full Title III EU AI Act compliance stack. For radio AI developers and radio equipment manufacturers, this creates dual obligations spanning both RED CE marking and EU AI Act technical documentation, QMS, conformity assessment, and post-market monitoring.
What Directive 2014/53/EU Covers
Directive 2014/53/EU (the Radio Equipment Directive, RED) governs radio equipment placed on the EU market, defining essential requirements for health and safety, electromagnetic compatibility, and the efficient use of the radio spectrum. The directive applies to any product that intentionally emits or receives radio waves — from consumer Wi-Fi routers to professional-grade software-defined radio platforms, from 5G base station equipment to GNSS receivers and maritime emergency radio beacons.
The RED scope covers the following equipment categories:
| Category | Examples | Key Standards | AI Relevance |
|---|---|---|---|
| Short-range devices | IoT sensors, Zigbee, Z-Wave, LoRa | ETSI EN 300 220, ETSI EN 300 440 | AI channel selection, adaptive power |
| Wi-Fi / WLAN | Access points, mesh systems | ETSI EN 301 893 (5 GHz), EN 300 328 (2.4 GHz) | AI channel management, interference avoidance |
| Cellular / IMT | 4G/5G UE, base stations | ETSI TS 138 series, ITU-R M.2150 | AI beamforming, spectrum slicing, handover |
| GNSS receivers | GPS/Galileo/GLONASS devices | EN 303 413, ETSI TS 103 246 | AI spoofing detection, jamming mitigation |
| Software-defined radio | Reconfigurable platforms | ETSI TR 103 031, ETSI EN 303 387 | AI reconfiguration, adaptive waveform |
| Cognitive radio | Dynamic spectrum access devices | ETSI EN 303 387, ITU-R SM.1448 | AI spectrum sensing, interference classification |
| Emergency radio (GMDSS) | EPIRB, SART, DSC radio | ITU-R M.493, IMO MSC/Circ.803 | AI distress detection, false-alert filtering |
| Aviation ELT | Emergency locator transmitters | EUROCAE ED-62B, TSO-C91a | AI impact detection, AI distress classification |
| Public safety radio | TETRA, P25, DECT | ETSI EN 300 392, ETSI EN 300 175 | AI priority channel allocation, voice AI |
| Satellite terminal | VSAT, LEO terminals | ETSI EN 301 444, ITU-R S.1714 | AI link adaptation, beam steering |
RED essential requirements are set out in Art.3 of Directive 2014/53/EU. Art.3(1) covers health, safety, and EMC. Art.3(2) covers efficient spectrum use — the provision directly relevant to AI spectrum management systems. Delegated acts under Art.3(3) extend specific requirements to categories including IoT (cybersecurity under Art.3(3)(i)) and network protection (Art.3(3)(g)), both of which have direct AI compliance touchpoints.
What Art.109 Actually Changes
Article 109 is a targeted legislative amendment. Like Art.105–108, it inserts EU AI Act references into the conformity framework of an existing sector regulation — here, Directive 2014/53/EU.
The operative mechanism is the Annex I bridge. EU AI Act Annex I lists the Union harmonisation legislation whose product scope intersects with the AI Act's high-risk classification pathway. Before Art.109, Directive 2014/53/EU was not listed in Annex I. After Art.109 amends the regulation, radio equipment AI systems that function as safety components, spectrum management controllers, or emergency detection systems under RED scope become Annex I radio equipment AI — and therefore follow Art.6(1)'s high-risk classification rule when the AI system performs a safety function within the product.
Three conditions determine whether a radio AI system becomes high-risk under Art.109:
- The host product is radio equipment within the scope of Directive 2014/53/EU
- The AI system functions as a safety component of that product or is itself the radio equipment in AI-enabled form
- The product with embedded AI is required to undergo third-party conformity assessment under RED (Module B+C, Module H, or notified body involvement)
Where all three conditions are met, the developer faces dual compliance: the RED conformity process plus the full EU AI Act Title III stack.
Definitively High-Risk Radio AI Systems
AI Spectrum Management for Safety-of-Life Services
Spectrum management AI that allocates, prioritises, or protects spectrum for emergency services, aeronautical communication, or maritime distress frequencies is definitively high-risk. AI systems that dynamically manage spectrum access in bands reserved for GMDSS, aeronautical VHF (118–137 MHz), or public protection and disaster relief (PPDR) under ECC Decision (15)05 must not misallocate spectrum in ways that block distress calls.
Applicable standards: ETSI EN 303 387 (Reconfigurable radio systems), ITU-R SM.1448 (Spectrum management principles), CEPT ECC Report 185 (Cognitive radio spectrum access). An AI spectrum management system failing to protect priority channels meets the safety-criticality threshold for high-risk classification under Art.6(1) read with Annex I.
Cognitive Radio with AI Dynamic Spectrum Access
Cognitive radio systems that use machine learning to sense the spectrum environment, identify unused channels, and adapt transmission parameters are high-risk when they operate in bands adjacent to safety-of-life services. The AI system's spectrum sensing decisions directly affect whether other users — including emergency responders and distress beacons — can transmit without interference.
ETSI EN 303 387 defines the technical framework for reconfigurable radio. AI cognitive radio systems performing dynamic frequency selection, adaptive modulation, or interference avoidance in coexistence scenarios with safety-critical spectrum users sit within the Art.6(1) high-risk pathway under the Art.109 amendment.
AI Emergency Radio Systems (EPIRB, ELT, DSC)
Emergency Position-Indicating Radio Beacons (EPIRBs) for maritime distress and Emergency Locator Transmitters (ELTs) for aviation distress are among the most safety-critical applications of radio equipment. AI systems integrated into these devices — for example, AI false-alert filtering, AI activation-confidence scoring, or AI signal classification that determines whether to transmit a distress message — are definitively high-risk.
An EPIRB or ELT that fails to activate due to an AI classification error — or that generates a false alert taxing SAR resources — directly endangers human life. The RED conformity framework for GMDSS equipment under IMO MSC/Circ.803 already imposes strict type-approval requirements. AI systems embedded in these devices add the Art.109 EU AI Act high-risk overlay.
AI GNSS Spoofing Detection and Jamming Mitigation
GNSS receivers that embed AI to detect radio frequency interference, identify spoofing attacks, or select authenticated signals are high-risk when deployed in safety-critical applications: aviation navigation, maritime positioning, precision agriculture autopilots, or emergency services vehicle routing. These AI systems perform a safety component function within GNSS radio equipment covered by RED and ETSI EN 303 413.
The AI system's ability to correctly classify a spoofed or jammed GNSS signal determines whether the platform navigates correctly. Failure modes include accepting a spoofed position fix, alerting on a legitimate signal, or failing to alert on a genuine spoofing attack.
Conditionally High-Risk Radio AI Systems
Software-Defined Radio (SDR) AI Reconfiguration
Software-defined radio platforms whose radio parameters — frequency, modulation, bandwidth, power — are controlled by AI software are conditionally high-risk. The condition is whether the SDR operates in spectrum bands or applications where a misconfiguration creates safety risk: interfering with aeronautical communications, affecting emergency service channels, or reconfiguring to illegal transmission parameters.
SDR platforms performing AI-driven waveform selection, cognitive channel adaptation, or protocol switching in public safety networks (TETRA/P25) or aeronautical applications are within the high-risk scope. General-purpose SDR test equipment without safety-critical deployment context is not.
| SDR System | Application | High-Risk Trigger | Notes |
|---|---|---|---|
| AI waveform selector | Public safety TETRA | Misselection blocks emergency comms | High-risk |
| AI channel adapter | 5G private network | Interference with safety spectrum | Conditional |
| AI protocol switcher | Aeronautical VHF | Disrupts ATC communication | High-risk |
| AI power controller | Consumer Wi-Fi | No safety-of-life overlap | Not high-risk |
| AI band scanner | Defence spectrum management | Dual-use, national security scope | Art.2(3) exclusion |
AI Adaptive Beamforming in 5G Safety Applications
Fifth-generation network equipment that uses AI to manage beam direction, multiple-input multiple-output (MIMO) configuration, and interference nulling is conditionally high-risk when deployed for safety-critical industrial automation, autonomous vehicle connectivity, or mission-critical communication services under EU regulation 2018/1971 (BEREC). AI beamforming decisions that degrade connectivity for an autonomous vehicle in a safety-critical manoeuvre, or that interrupt a factory robot safety stop signal, trigger high-risk classification.
Standard consumer-grade 5G Wi-Fi AI beamforming — optimising throughput between devices without safety-of-life implications — does not meet the Art.6(1) threshold.
AI Public Safety Radio Network Management
TETRA and P25 radio network management systems that use AI to allocate channels, prioritise traffic, or reconfigure talkgroups during incidents are conditionally high-risk. The condition depends on whether the radio network serves emergency response operations where communication failure has life-safety consequences. AI systems managing radio networks for police, fire, or EMS dispatch sit within the high-risk scope under Art.109.
The Dual Conformity Assessment Path
For AI systems that become high-risk under the Art.109 amendment, the developer must navigate two parallel conformity regimes:
Radio Equipment Directive (RED) path:
- Identify applicable essential requirements under Art.3(1), 3(2), 3(3) of Directive 2014/53/EU
- Apply harmonised standards (ETSI, CENELEC) for the equipment category
- Conduct conformity assessment: self-declaration under Annex II RED (for Art.3(1)/(2)) or notified body assessment under Annex III (for certain Art.3(3) requirements)
- Issue EU Declaration of Conformity (DoC) and affix CE marking
- Register in EUDAMED for EPIRB/GMDSS equipment subject to additional tracking
EU AI Act path (Title III, Art.9–46):
- Establish risk management system (Art.9) addressing spectrum failure modes, false activation/non-activation scenarios, adversarial interference inputs
- Prepare technical documentation (Art.11, Annex IV) including training data provenance, model architecture, performance metrics across spectrum conditions
- Implement data governance (Art.10) for spectrum sensing training data, adversarial RF datasets, field performance data
- Deploy technical accuracy measures and robustness testing (Art.15): accuracy across frequency, power, modulation variations; adversarial resilience against jamming/spoofing inputs
- Implement human oversight mechanisms (Art.14): operator override for spectrum allocation decisions affecting safety channels
- Conduct conformity assessment (Art.43): for Annex I radio equipment AI, Module B+C or Module H equivalent, potentially requiring a notified body designated under both RED and EU AI Act frameworks
- Register in the EU AI Act database (Art.71)
- Affix CE marking with EU AI Act compliance overlay (Art.48)
- Implement post-market monitoring (Art.72) for field performance against spectrum KPIs
The OTA Software Update Recertification Challenge
A distinctive and commercially significant challenge for radio AI compliance under Art.109 is the interaction between AI model updates delivered over-the-air (OTA) and the RED concept of "substantial modification." Under RED Art.4 and Commission guidance on substantial modification:
A software update to a radio AI system that changes the radio's transmission behaviour — its frequency range, modulation, power level, or AI-driven spectrum decisions — may constitute a substantial modification that requires a new conformity assessment, voidance of the existing CE marking, and reissue of the EU Declaration of Conformity.
For AI-enabled radio equipment, this creates a compliance lifecycle challenge that does not exist for static radio firmware:
| OTA Update Type | Substantial Modification? | EU AI Act Impact | Action Required |
|---|---|---|---|
| AI spectrum policy update (new frequency bands) | Likely yes | Technical doc update, new conformity assessment | Pre-deployment assessment |
| AI interference threshold recalibration | Borderline — depends on spectrum scope | Risk management update, testing logs | Documentation update |
| AI model retrain (same task, better accuracy) | Likely no if behaviour unchanged | Art.9 monitoring data, Art.72 post-market | Monitoring log |
| AI feature addition (new waveform type) | Yes | Full Art.43 reassessment, new DoC | Pre-deployment |
| Security patch (no RF behaviour change) | No | Incident monitoring update | Log only |
Radio AI developers deploying cognitive or adaptive systems must establish OTA governance processes that assess each update against both the RED substantial modification threshold and the EU AI Act change management requirements before deployment.
Provider-Deployer Split in Radio AI
The EU AI Act provider-deployer split applies directly to radio AI systems, and the industry structure creates several distinct compliance configurations:
Configuration 1: Component AI provider + radio OEM Qualcomm, MediaTek, Intel produce AI-enabled modem chipsets with embedded spectrum management intelligence. The modem OEM is the AI provider under Art.3(3) EU AI Act; the radio equipment manufacturer incorporating the chipset is a downstream provider or deployer depending on whether they substantially modify the AI component. For chipset-integrated AI, the OEM-manufacturer relationship must be formalised under Art.25(4) and Art.26(2) EU AI Act obligations.
Configuration 2: Radio OEM as integrated provider Ericsson, Nokia, and Huawei develop radio equipment with AI-integrated network management: AI massive MIMO, AI interference coordination, AI energy optimisation. These OEMs are providers under EU AI Act Art.3(3), responsible for the full Title III compliance stack for their AI-enabled base stations, small cells, and network elements placed on the EU market.
Configuration 3: Network operator as deployer Deutsche Telekom, Vodafone, Orange, and other MNOs deploy AI-enabled radio networks as deployers under Art.3(4). They are responsible for Art.26 deployer obligations: ensuring use in accordance with provider instructions, monitoring for significant risks, and reporting incidents to providers and market surveillance authorities.
Configuration 4: Enterprise / critical infrastructure deployer Utilities, transport operators, and industrial facilities deploying private 5G networks with AI spectrum management are deployers. Where they integrate AI models into the radio management layer themselves, they cross into the provider role for that AI component.
| Actor | Example | EU AI Act Role | Primary Obligations |
|---|---|---|---|
| Chipset AI developer | Qualcomm AI modem | Provider (component) | Art.25(4), supply chain docs |
| Radio OEM | Ericsson, Nokia | Provider (system) | Art.9–46 full Title III |
| Network operator | Deutsche Telekom | Deployer | Art.26, Art.29 |
| Enterprise network owner | Siemens Industry | Deployer / Provider | Art.26 + Art.25 if self-integrated |
| Emergency radio OEM | Iridium, Cobham | Provider | Art.9–46, GMDSS safety req. |
The GPAI Intersection: Foundation Models in SDR
The Art.109 amendment creates a two-layer compliance obligation for radio AI developers using general-purpose AI (GPAI) foundation models — large pre-trained models — as the AI core of SDR or cognitive radio systems.
A GPAI model embedded in an SDR system that controls spectrum access decisions faces dual classification:
- As a GPAI model: obligations under EU AI Act Title VI (Art.51–56), including model cards, technical documentation, copyright compliance for training data, and for systemic-risk GPAI models, adversarial testing and incident reporting to the AI Office
- As a high-risk AI system (if Art.109 conditions are met): the full Title III stack for the spectrum management function
EU AI Act Art.51(2) clarifies that a GPAI model integrated into a high-risk AI system must satisfy both the GPAI obligations and the high-risk system obligations. For radio AI, this means a foundation model-powered SDR must undergo the GPAI transparency stack and the RED/AI Act dual conformity path simultaneously.
The practical implication: SDR developers using open-source foundation models (e.g., AI waveform detection models from Hugging Face) as the inference backbone for cognitive radio must evaluate whether those models carry systemic-risk designation and what that means for their AI Act compliance posture.
CLOUD Act and Radio Spectrum Data Sovereignty
Radio AI systems generate and depend on spectrum data that frequently flows to US-based cloud infrastructure:
Spectrum monitoring telemetry: AI-driven spectrum sensing platforms upload interference measurements, channel quality reports, and spectrum occupancy data to cloud analytics services (AWS CloudWatch, Azure Monitor, Google Cloud Monitoring). This data may include geolocation — where interference was detected — which combined with device identifiers constitutes personal data under GDPR.
SDR configuration databases: AI-managed SDR platforms pull waveform definitions, frequency policies, and operational parameters from cloud configuration services. Many SDR cloud backends (GNU Radio Cloud, commercial SDR-as-a-Service platforms) run on US infrastructure subject to CLOUD Act compelled access.
AI model MLOps pipelines: Radio AI models are retrained on spectrum performance data collected from deployed equipment. MLOps platforms (AWS SageMaker, Azure ML, Google Vertex AI) processing field spectrum data from EU-deployed radio equipment are subject to CLOUD Act jurisdiction if operated by US cloud providers.
GMDSS distress data: AI systems in maritime emergency radio that log test activations, false alerts, and distress signal analytics upload that data to vendor cloud platforms. Distress location data combined with vessel identity is sensitive from both a GDPR and an EU sovereignty perspective.
For EU operators in critical infrastructure, public safety, or government radio networks, cloud sovereignty requirements under NIS2 Art.21, CER Directive, and national critical infrastructure frameworks may prohibit use of CLOUD Act-subject cloud for spectrum AI training or real-time inference.
from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
class RiskLevel(Enum):
DEFINITELY_HIGH_RISK = "definitely_high_risk"
CONDITIONALLY_HIGH_RISK = "conditionally_high_risk"
NOT_HIGH_RISK = "not_high_risk"
EXCLUDED = "excluded_art_2_3"
@dataclass
class RadioAISystem:
system_id: str
description: str
red_category: str
standard: str
risk_level: RiskLevel
safety_of_life: bool
ota_update_risk: str
cloud_sovereignty_issue: bool
notes: str = ""
class RadioAIComplianceTracker:
def __init__(self):
self.systems: list[RadioAISystem] = []
self._populate_default_systems()
def _populate_default_systems(self):
self.systems = [
RadioAISystem(
system_id="RED-AI-001",
description="AI spectrum management for PPDR / emergency services spectrum",
red_category="Cognitive radio / spectrum management",
standard="ETSI EN 303 387, ECC Decision (15)05",
risk_level=RiskLevel.DEFINITELY_HIGH_RISK,
safety_of_life=True,
ota_update_risk="High — spectrum policy changes trigger RED substantial modification",
cloud_sovereignty_issue=True,
notes="Misallocation blocks emergency comms. Art.3(2) RED + Art.109 EU AI Act.",
),
RadioAISystem(
system_id="RED-AI-002",
description="Cognitive radio AI dynamic spectrum access (commercial bands)",
red_category="Cognitive / reconfigurable radio",
standard="ETSI EN 303 387, ITU-R SM.1448",
risk_level=RiskLevel.DEFINITELY_HIGH_RISK,
safety_of_life=True,
ota_update_risk="High — waveform/frequency changes = substantial modification",
cloud_sovereignty_issue=True,
notes="Adjacent-band interference with safety radio triggers Art.6(1).",
),
RadioAISystem(
system_id="RED-AI-003",
description="AI EPIRB false-alert filtering and activation confidence",
red_category="GMDSS emergency radio",
standard="ITU-R M.628, IMO MSC/Circ.803",
risk_level=RiskLevel.DEFINITELY_HIGH_RISK,
safety_of_life=True,
ota_update_risk="Medium — activation logic changes require type-approval re-assessment",
cloud_sovereignty_issue=True,
notes="Zero-tolerance failure mode: false negative = no SAR activation.",
),
RadioAISystem(
system_id="RED-AI-004",
description="AI ELT impact detection and distress signal classification",
red_category="Aviation emergency radio",
standard="EUROCAE ED-62B, TSO-C91a",
risk_level=RiskLevel.DEFINITELY_HIGH_RISK,
safety_of_life=True,
ota_update_risk="High — aviation safety approval (EUROCAE/TSO) required per change",
cloud_sovereignty_issue=False,
notes="Aviation safety overlay from EASA in addition to RED + EU AI Act.",
),
RadioAISystem(
system_id="RED-AI-005",
description="AI GNSS spoofing/jamming detection in safety-critical receivers",
red_category="GNSS receiver",
standard="ETSI EN 303 413, ETSI TS 103 246",
risk_level=RiskLevel.DEFINITELY_HIGH_RISK,
safety_of_life=True,
ota_update_risk="Medium — detection threshold changes need testing, not full recert",
cloud_sovereignty_issue=True,
notes="Aviation/maritime GNSS: failure = navigation hazard.",
),
RadioAISystem(
system_id="RED-AI-006",
description="AI SDR waveform selector for public safety TETRA network",
red_category="Software-defined radio",
standard="ETSI EN 300 392, ETSI TR 103 031",
risk_level=RiskLevel.DEFINITELY_HIGH_RISK,
safety_of_life=True,
ota_update_risk="High — new waveform = substantial modification per RED Art.4",
cloud_sovereignty_issue=True,
notes="TETRA police/fire: AI misselection interrupts emergency voice.",
),
RadioAISystem(
system_id="RED-AI-007",
description="AI 5G beamforming for industrial safety automation (private network)",
red_category="Cellular / IMT base station",
standard="ETSI TS 138.series, ITU-R M.2150",
risk_level=RiskLevel.CONDITIONALLY_HIGH_RISK,
safety_of_life=False,
ota_update_risk="Low — beamforming update within approved frequency/power envelope",
cloud_sovereignty_issue=True,
notes="High-risk if robotics safety-stop depends on connectivity. Not high-risk for consumer 5G.",
),
RadioAISystem(
system_id="RED-AI-008",
description="AI consumer Wi-Fi channel management (smart home AP)",
red_category="WLAN / RLAN",
standard="ETSI EN 301 893",
risk_level=RiskLevel.NOT_HIGH_RISK,
safety_of_life=False,
ota_update_risk="Low — AI channel selection within self-declared limits",
cloud_sovereignty_issue=False,
notes="No safety-of-life overlap. Standard AI-assisted channel selection.",
),
]
def compliance_summary(self) -> dict:
definitely = [s for s in self.systems if s.risk_level == RiskLevel.DEFINITELY_HIGH_RISK]
conditional = [s for s in self.systems if s.risk_level == RiskLevel.CONDITIONALLY_HIGH_RISK]
not_high = [s for s in self.systems if s.risk_level == RiskLevel.NOT_HIGH_RISK]
cloud_risk = [s for s in self.systems if s.cloud_sovereignty_issue]
ota_high = [s for s in self.systems if "High" in s.ota_update_risk]
return {
"total": len(self.systems),
"definitely_high_risk": len(definitely),
"conditionally_high_risk": len(conditional),
"not_high_risk": len(not_high),
"cloud_sovereignty_issues": len(cloud_risk),
"high_ota_recert_risk": len(ota_high),
"dual_compliance_required": len(definitely) + len(conditional),
}
tracker = RadioAIComplianceTracker()
summary = tracker.compliance_summary()
# {"total": 8, "definitely_high_risk": 6, "conditionally_high_risk": 1,
# "not_high_risk": 1, "cloud_sovereignty_issues": 6, "high_ota_recert_risk": 5,
# "dual_compliance_required": 7}
The Art.104–112 Amendment Series
Article 109 is the fifth in the Art.104–112 series of EU AI Act sector amendments, each inserting the high-risk pathway into existing EU product regulation frameworks:
| Article | Directive / Regulation | Sector | Key AI Systems |
|---|---|---|---|
| Art.104 | Directive 2006/42/EC | Machinery | Safety-critical controllers, guarding AI |
| Art.105 | Regulation (EU) 167/2013 | Agricultural vehicles | Autonomous guidance, obstacle detection |
| Art.106 | Regulation (EU) 168/2013 | L-category vehicles | ABS/CBS controllers, rider monitoring |
| Art.107 | Regulation (EU) 2019/2144 | Motor vehicles (M/N) | ALKS, AEB, ISA, DDAW, eCall |
| Art.108 | Directive 2014/90/EU | Marine equipment | ECDIS, autopilot, ARPA, BNWAS, VDR |
| Art.109 | Directive 2014/53/EU | Radio equipment (RED) | Cognitive radio, SDR, spectrum AI, EPIRB/ELT |
| Art.110 | Directive 2006/66/EC | Batteries | AI state-of-health estimation |
| Art.111 | Directive 2014/68/EU | Pressure equipment | AI structural integrity monitoring |
| Art.112 | Regulation (EU) 305/2011 | Construction products | AI structural assessment systems |
The Art.109 RED amendment has an additional layer absent from the other articles in this series: the OTA update proliferation challenge. Radio equipment is uniquely subject to over-the-air software reconfiguration, and AI-driven radio systems receive model updates, policy updates, and waveform updates continuously. The intersection of RED's substantial modification framework with EU AI Act change management under Art.9 and post-market monitoring under Art.72 creates the most operationally complex compliance lifecycle in the Art.104–112 series.
25-Item Radio AI Compliance Checklist (Art.109)
Product Scoping
- Confirm the radio equipment falls within Directive 2014/53/EU scope (intentional radio transmitter/receiver)
- Identify all AI systems embedded in or controlling the radio equipment
- Determine applicable RED essential requirements (Art.3(1), 3(2), 3(3))
- Map AI systems to safety-of-life spectrum bands or emergency radio functions
- Assess whether third-party notified body involvement is required under RED
High-Risk Classification 6. Apply Art.6(1) test: is the AI a safety component of RED-scoped product requiring notified body assessment? 7. Confirm Art.109 Annex I bridge applies to your specific radio equipment category 8. Check for Art.2(3) national security / defence exclusions for any military/dual-use radio AI 9. Assess GPAI foundation model integration: dual Title VI + Title III classification if applicable 10. Document the classification decision with regulatory basis in AI Act technical documentation
Dual Conformity Assessment 11. Plan RED conformity path: Annex II self-declaration or Annex III notified body route 12. Identify designated notified body competent for both RED and EU AI Act assessment 13. Establish EU AI Act technical documentation (Art.11, Annex IV) for each high-risk radio AI system 14. Implement AI risk management system (Art.9) with spectrum-specific failure mode analysis 15. Define human oversight mechanisms (Art.14) for spectrum allocation and emergency radio decisions
OTA Update Governance 16. Establish OTA change classification process: which updates are substantial modifications under RED? 17. Define AI model update governance: retrain triggers, performance drift thresholds, approval workflow 18. Integrate OTA update assessment into Art.72 post-market monitoring plan 19. Maintain version-controlled technical documentation for each OTA-delivered AI model version 20. Train field support teams on recertification triggers for radio AI updates
Data and Cloud 21. Inventory spectrum monitoring data flows to cloud platforms: identify CLOUD Act exposure 22. Assess GNSS spoofing detection data and personal data under GDPR Art.9 (location + device identity) 23. Evaluate cloud sovereignty requirements for PPDR / public safety radio AI deployments 24. Map GMDSS distress data flows (EPIRB/ELT cloud analytics) against EU data localisation requirements 25. Register high-risk radio AI systems in EU AI Act database (Art.71) before August 2026 application deadline
See Also
- EU AI Act Art.110: Amendment to Directive 2006/66/EC — AI Battery Management, SoH Estimation and EV BMS High-Risk Classification
- EU AI Act Art.108: Amendment to Directive 2014/90/EU — Marine Equipment ECDIS and Autopilot AI
- EU AI Act Art.107: Amendment to Regulation (EU) 2019/2144 — ALKS, ADAS and Motor Vehicle AI High-Risk Classification
- EU AI Act Art.106: Amendment to Regulation (EU) 168/2013 — L-Category Vehicles Motorcycle ABS and Rider AI
- EU AI Act Art.105: Amendment to Regulation (EU) 167/2013 — Agricultural Vehicles Autonomous Guidance AI