2026-04-26·14 min read·

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:

CategoryExamplesKey StandardsAI Relevance
Short-range devicesIoT sensors, Zigbee, Z-Wave, LoRaETSI EN 300 220, ETSI EN 300 440AI channel selection, adaptive power
Wi-Fi / WLANAccess points, mesh systemsETSI EN 301 893 (5 GHz), EN 300 328 (2.4 GHz)AI channel management, interference avoidance
Cellular / IMT4G/5G UE, base stationsETSI TS 138 series, ITU-R M.2150AI beamforming, spectrum slicing, handover
GNSS receiversGPS/Galileo/GLONASS devicesEN 303 413, ETSI TS 103 246AI spoofing detection, jamming mitigation
Software-defined radioReconfigurable platformsETSI TR 103 031, ETSI EN 303 387AI reconfiguration, adaptive waveform
Cognitive radioDynamic spectrum access devicesETSI EN 303 387, ITU-R SM.1448AI spectrum sensing, interference classification
Emergency radio (GMDSS)EPIRB, SART, DSC radioITU-R M.493, IMO MSC/Circ.803AI distress detection, false-alert filtering
Aviation ELTEmergency locator transmittersEUROCAE ED-62B, TSO-C91aAI impact detection, AI distress classification
Public safety radioTETRA, P25, DECTETSI EN 300 392, ETSI EN 300 175AI priority channel allocation, voice AI
Satellite terminalVSAT, LEO terminalsETSI EN 301 444, ITU-R S.1714AI 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:

  1. The host product is radio equipment within the scope of Directive 2014/53/EU
  2. The AI system functions as a safety component of that product or is itself the radio equipment in AI-enabled form
  3. 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 SystemApplicationHigh-Risk TriggerNotes
AI waveform selectorPublic safety TETRAMisselection blocks emergency commsHigh-risk
AI channel adapter5G private networkInterference with safety spectrumConditional
AI protocol switcherAeronautical VHFDisrupts ATC communicationHigh-risk
AI power controllerConsumer Wi-FiNo safety-of-life overlapNot high-risk
AI band scannerDefence spectrum managementDual-use, national security scopeArt.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:

EU AI Act path (Title III, Art.9–46):

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 TypeSubstantial Modification?EU AI Act ImpactAction Required
AI spectrum policy update (new frequency bands)Likely yesTechnical doc update, new conformity assessmentPre-deployment assessment
AI interference threshold recalibrationBorderline — depends on spectrum scopeRisk management update, testing logsDocumentation update
AI model retrain (same task, better accuracy)Likely no if behaviour unchangedArt.9 monitoring data, Art.72 post-marketMonitoring log
AI feature addition (new waveform type)YesFull Art.43 reassessment, new DoCPre-deployment
Security patch (no RF behaviour change)NoIncident monitoring updateLog 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.

ActorExampleEU AI Act RolePrimary Obligations
Chipset AI developerQualcomm AI modemProvider (component)Art.25(4), supply chain docs
Radio OEMEricsson, NokiaProvider (system)Art.9–46 full Title III
Network operatorDeutsche TelekomDeployerArt.26, Art.29
Enterprise network ownerSiemens IndustryDeployer / ProviderArt.26 + Art.25 if self-integrated
Emergency radio OEMIridium, CobhamProviderArt.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:

  1. 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
  2. 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:

ArticleDirective / RegulationSectorKey AI Systems
Art.104Directive 2006/42/ECMachinerySafety-critical controllers, guarding AI
Art.105Regulation (EU) 167/2013Agricultural vehiclesAutonomous guidance, obstacle detection
Art.106Regulation (EU) 168/2013L-category vehiclesABS/CBS controllers, rider monitoring
Art.107Regulation (EU) 2019/2144Motor vehicles (M/N)ALKS, AEB, ISA, DDAW, eCall
Art.108Directive 2014/90/EUMarine equipmentECDIS, autopilot, ARPA, BNWAS, VDR
Art.109Directive 2014/53/EURadio equipment (RED)Cognitive radio, SDR, spectrum AI, EPIRB/ELT
Art.110Directive 2006/66/ECBatteriesAI state-of-health estimation
Art.111Directive 2014/68/EUPressure equipmentAI structural integrity monitoring
Art.112Regulation (EU) 305/2011Construction productsAI 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

  1. Confirm the radio equipment falls within Directive 2014/53/EU scope (intentional radio transmitter/receiver)
  2. Identify all AI systems embedded in or controlling the radio equipment
  3. Determine applicable RED essential requirements (Art.3(1), 3(2), 3(3))
  4. Map AI systems to safety-of-life spectrum bands or emergency radio functions
  5. 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