If you develop AI systems for ships' navigation equipment, collision avoidance, or integrated bridge systems installed on EU-flagged vessels, Article 108 of the EU AI Act directly governs your compliance obligations. EU AI Act Art.108 amends Directive 2014/90/EU — the EU Marine Equipment Directive (MED) — to formally integrate EU AI Act requirements into the ships' equipment conformity framework, extending the high-risk AI pathway to maritime navigation and safety AI systems carrying the wheelmark.

The amendment follows the same Annex I bridge mechanism as Art.105 (agricultural vehicles), Art.106 (two/three-wheel vehicles), and Art.107 (general motor vehicles): AI systems embedded in ships' equipment that qualify as navigation or safety components under Directive 2014/90/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 maritime AI developers and equipment manufacturers, this creates dual obligations spanning both MED wheelmark approval and EU AI Act technical documentation, QMS, conformity assessment, and post-market monitoring.

What Directive 2014/90/EU Covers

Directive 2014/90/EU (the Marine Equipment Directive, MED) governs ships' equipment placed on board EU Member State-flagged vessels, requiring it to meet international maritime standards and carry the MED conformity marking — the wheelmark — before installation. The directive covers equipment referenced in international maritime instruments adopted by the International Maritime Organization (IMO), including SOLAS (Safety of Life at Sea), MARPOL, and the Load Lines Convention.

The MED scope covers the following equipment categories:

The wheelmark (⚙) is the mandatory conformity marking for MED-covered equipment. It signals compliance with IMO performance standards, IEC electrical standards, and type-approval testing by a Recognised Organisation (RO) such as DNV, Lloyd's Register, Bureau Veritas, or RINA. Without the wheelmark, ships' equipment cannot be legally installed on EU-flagged vessels.

What Art.108 Actually Changes

Article 108 is a targeted legislative amendment. Like Art.105–107, it inserts EU AI Act references into the conformity framework of an existing sector regulation — here, Directive 2014/90/EU.

The operative mechanism: AI systems in ships' equipment that constitute navigation or safety systems covered by Directive 2014/90/EU now sit within EU AI Act Annex I, activating the Art.6(1) high-risk pathway. Compliance requires satisfying both:

1. Directive 2014/90/EU MED obligations — IMO performance standards (SOLAS, MSC Resolutions), IEC type-testing standards (IEC 60945, IEC 61174, IEC 62388), Recognised Organisation approval, wheelmark affixing
2. EU AI Act Title III obligations — technical documentation (Annex IV), QMS (Art.9), conformity assessment (Art.43), post-market monitoring (Art.72), incident reporting (Art.65)

The classification trigger is the wheelmark status. If the AI-based component is listed as MED-covered equipment in the ship's equipment certificate and bears or requires the wheelmark, it is high-risk under the EU AI Act.

Which Marine Equipment AI Systems Become High-Risk

Definitively High-Risk

ECDIS — Electronic Chart Display and Information System

ECDIS is the primary navigation system for SOLAS-compliant vessels. It integrates Electronic Nautical Charts (ENC) with GPS, AIS, and radar overlays to provide the officer of the watch (OOW) with a real-time navigational picture. IMO Resolution MSC.232(82) and IEC 61174 define ECDIS performance standards.

Modern ECDIS systems increasingly incorporate AI components: route optimisation algorithms that factor weather, current, and traffic separation schemes; anomaly detection that identifies chart data inconsistencies; and ML-driven passage planning tools that learn from historical voyage patterns. Where an ECDIS includes an AI module that influences route selection, hazard alerts, or watch officer decision-making, it constitutes an AI system under Art.3(1) and a safety component under Directive 2014/90/EU. High-risk classification is definitive.

The Art.9 QMS for ECDIS AI must address chart data currency dependencies (AVCS/PRIMAR update cycles), ENC quality variation across hydrographic offices, and the OOW situational awareness interaction model. Failure modes — failure to alert for shoal water, incorrect routing recommendations in complex TSS environments — are life-safety critical.

Autopilot and Track-Keeping Systems

Ship autopilots control helm movements to maintain heading or track, interfacing directly with the vessel's steering gear. Adaptive autopilot systems use ML to model the vessel's hydrodynamic response — varying with load condition, sea state, and current — to optimise rudder action. Adaptive neural-network autopilots that adjust steering gain parameters from voyage data are AI systems under Art.3(1).

Where the autopilot controls the steering gear directly (rather than merely providing advisory outputs to the helmsman), it is a safety component under SOLAS V/24 and Directive 2014/90/EU. High-risk classification applies. The failure mode — uncontrolled yaw leading to collision or grounding — is catastrophically severe.

ARPA/ARPAA Radar — Automatic Radar Plotting Aid

ARPA (Automatic Radar Plotting Aid) systems process radar returns to automatically acquire, track, and compute collision risk for targets in the vessel's vicinity. Advanced ARPA systems (ARPAA) use ML-based target classification to distinguish vessels, buoys, rain clutter, and sea clutter, improving target acquisition in degraded conditions.

IEC 62388 defines radar and ARPA performance requirements referenced by Directive 2014/90/EU. An ARPA system using ML for clutter suppression, target classification, or closest point of approach (CPA) threshold alerting is definitively high-risk: the failure mode — failure to acquire a vessel on collision course, or false CPA alert leading to unnecessary evasive manoeuvre — directly impacts collision risk. The COLREGS Rule 8 obligation to take early and substantial action to avoid collision depends on correct CPA computation.

BNWAS — Bridge Navigational Watch Alarm System

BNWAS (IEC 62616) detects inactivity on the bridge to identify incapacitation of the watch officer. A standard BNWAS uses a simple activity timer; advanced BNWAS systems use camera-based AI to detect watch officer position, eye closure, and attentiveness — analogous to DDAW in motor vehicles.

Where the BNWAS uses AI-based computer vision to classify watch officer alertness and trigger the alarm cascade (internal alarm → steering position alarm → captain alert → backup watch alarm), it is an AI system under Art.3(1) operating as a safety component under SOLAS V/15 and Directive 2014/90/EU. High-risk classification applies. Biometric data processing implications under GDPR Art.9 additionally apply when camera-based facial analysis is used.

VDR AI Analysis — Voyage Data Recorder

VDRs record bridge audio, radar, position, heading, speed, and key equipment parameters under IEC 61996 and SOLAS V/20. Post-incident, VDR data is reviewed by maritime investigation authorities. AI systems that automatically analyse VDR data to classify incident causes, identify contributing factor patterns, or generate automated investigation reports are AI systems under Art.3(1).

Where the AI analysis output is used in formal maritime safety investigations — determining fault, informing insurance decisions, or feeding classification society incident databases — it is a safety-relevant system. High-risk classification depends on the deployment context; in formal investigation use, the Art.6(2) pathway may also apply.

Conditionally High-Risk

Integrated Navigation Systems (INS)

INS platforms (IEC 61924) integrate ECDIS, radar, autopilot, AIS, and meteorological data into a unified bridge interface. Where the INS includes an AI decision-support layer — synthesising multi-sensor inputs to generate navigation recommendations or collision avoidance advisories — it may constitute a high-risk AI system. Classification depends on whether the AI output constitutes a safety-relevant decision (direct effect on navigation) or purely advisory display.

AIS Anomaly Detection

AIS (Automatic Identification System) broadcasts vessel position, identity, and voyage data under SOLAS V/19 and ITU-R M.1371. AI systems processing AIS data streams to detect anomalous behaviour — vessels entering exclusion zones, spoofed AIS signals, dark-vessel detection — are AI systems under Art.3(1). Port State Control (PSC) systems and vessel traffic service (VTS) platforms incorporating such AI qualify as high-risk where output directly triggers enforcement or access restriction decisions affecting safety of life.

Engine Condition Monitoring

AI-based predictive maintenance systems that monitor vibration, thermal, and performance parameters to predict machinery failure do not constitute ships' equipment under Directive 2014/90/EU but may fall under the Art.6(2) pathway if used in infrastructure management or transport logistics contexts.

The Dual Compliance Pathway

Recognised Organisation Side (Directive 2014/90/EU)

MED compliance involves:

1. IMO Performance Standard alignment — The AI system must meet the applicable IMO Resolution or IEC standard (e.g., IEC 61174 for ECDIS, IEC 62388 for radar/ARPA, IEC 62616 for BNWAS).
2. Type-testing by a Recognised Organisation — DNV, Lloyd's Register, Bureau Veritas, RINA, or ClassNK conduct electrical (IEC 60945) and performance testing of equipment samples.
3. Module B+D or Module H conformity assessment — Module B (type examination) plus Module D (production quality) or Module H (full quality assurance) are the primary MED routes.
4. Wheelmark affixing — The wheelmark plus the RO notified body number (e.g., DNV = 0575) appears on the equipment.
5. Declaration of Conformity — The manufacturer issues an EU Declaration of Conformity referencing the applicable IMO instruments and IEC standards.

EU AI Act Side (Title III)

For AI systems that become high-risk under the Art.108 amendment:

1. Technical Documentation (Annex IV) — Must include the AI system architecture, training data provenance, validation methodology, performance metrics against the applicable IEC standard, and the intended operational domain (vessel type, sea states, traffic density scenarios).
2. Quality Management System (Art.9) — Must cover the full AI lifecycle from design through deployment, with documented risk controls for AI-specific failure modes (sensor fusion failures, adversarial input, OOD detection, software update management).
3. Conformity Assessment (Art.43) — For most maritime AI systems, this is Module B+D or equivalent, with the EU AI Act documentation requirements added to the existing IEC type-testing dossier. The Recognised Organisation acting as MED notified body may also be appointed as an EU AI Act notified body.
4. Post-Market Monitoring (Art.72) — Requires field performance data collection from deployed vessels, with incident reporting to national market surveillance authorities when the AI system behaves unexpectedly in operational conditions.
5. Serious Incident Reporting (Art.65) — AI-related serious incidents (malfunction that could cause death, injury, or significant harm) must be reported within defined timescales. SOLAS Casualty Investigation obligations under MSC-MEPC.3/Circ.4 create an existing incident reporting framework that must be coordinated with Art.65 reporting.

Integration Challenge: IMO Update Cycles vs. EU AI Act Timelines

A distinctive challenge for maritime AI compliance is the IMO amendment cycle. IMO performance standards are adopted by MSC Resolutions, which typically take 2–4 years from proposal to adoption. Amendments to ECDIS, radar, or AIS standards affect the MED equipment scope. EU AI Act obligations take effect from August 2026 for high-risk systems. Maritime equipment manufacturers must map their product portfolios against both the current MED equipment annex and the Art.108 AI amendment, accounting for the possibility that new IMO instruments create new high-risk touchpoints mid-product lifecycle.

Provider-Deployer Split in Maritime AI

The EU AI Act's provider-deployer distinction creates important liability allocation challenges in the maritime sector:

The provider obligation to provide information for deployment (Art.13) is particularly important in the maritime context. The ISM Code (International Safety Management Code) requires shipping companies to maintain documented operating procedures for all safety-critical equipment. AI system providers must supply technical documentation compatible with ISM Code requirements — plain-language operating instructions, emergency procedures, known limitations — alongside Art.13 AI Act transparency obligations.

CLOUD Act Intersection for Maritime AI

EU-flagged vessel data sovereignty presents significant CLOUD Act exposure:

• Voyage data and VDR records processed or stored on US-cloud platforms (AWS, Azure, Google Cloud) are accessible to US authorities under the CLOUD Act without notification to EU shipowners or flag states. This affects post-incident investigation integrity and charter party dispute resolution.
• ECDIS cloud updates — ENC (Electronic Nautical Chart) updates delivered via cloud-connected ECDIS. Where the update infrastructure runs on US-cloud, the IMO chart data authentication chain may intersect with US law.
• Fleet management platforms — Vessel performance monitoring, fuel optimisation, and predictive maintenance SaaS platforms (e.g., Kongsberg Vessel Insight, Wärtsilä Eniram) typically process continuous sensor streams. CLOUD Act risk applies to all voyage performance data.
• GMDSS/Inmarsat and Iridium comms — GMDSS communications links (Inmarsat L-band, Iridium) are routed through US-headquartered satellite operators. AI systems that process GMDSS traffic for alert classification sit in a legally complex jurisdictional position.

For EU shipowners operating EU-flagged vessels, an EU-hosted maritime data platform — receiving VDR, ECDIS, AIS, and engineering data — eliminates CLOUD Act exposure while maintaining SOLAS compliance. Directive 2014/90/EU does not mandate cloud connectivity; the risk is introduced by vendor architectural choices.

IEC and IMO Standards Interface

Maritime AI compliance requires coordinating multiple standards layers:

The IEC 60945 environmental testing requirements — temperature, humidity, vibration, EMI — must be satisfied by all AI hardware components. AI-specific requirements — model robustness against sensor degradation, performance under adverse weather, OOD detection — are not addressed in current IEC standards and must be documented as EU AI Act Annex IV supplementary requirements until IMO/IEC standards are updated.

Python: MarineAIComplianceTracker

from dataclasses import dataclass, field
from enum import Enum
from datetime import date

class RiskLevel(Enum):
    DEFINITIVE_HIGH = "definitive_high_risk"
    CONDITIONAL_HIGH = "conditional_high_risk"
    LIKELY_NOT_HIGH = "likely_not_high_risk"

class IMOStandard(Enum):
    SOLAS_V_19 = "SOLAS_V_19"
    SOLAS_V_20 = "SOLAS_V_20"
    SOLAS_V_24 = "SOLAS_V_24"
    MSC_232_82 = "MSC_232(82)"
    IEC_61174 = "IEC_61174"
    IEC_62388 = "IEC_62388"
    IEC_62616 = "IEC_62616"
    IEC_61996 = "IEC_61996"
    IEC_61924 = "IEC_61924"

@dataclass
class MarineAISystem:
    name: str
    risk_level: RiskLevel
    imo_standards: list[IMOStandard]
    failure_mode: str
    cloud_act_risk: bool
    biometric: bool = False
    notes: str = ""

@dataclass
class MarineEquipmentComplianceTracker:
    vessel_name: str
    flag_state: str
    imo_number: str
    assessment_date: date = field(default_factory=date.today)
    systems: list[MarineAISystem] = field(default_factory=list)

    def register_system(self, system: MarineAISystem):
        self.systems.append(system)

    def high_risk_systems(self):
        return [s for s in self.systems if s.risk_level == RiskLevel.DEFINITIVE_HIGH]

    def cloud_act_exposure(self):
        return [s for s in self.systems if s.cloud_act_risk]

    def biometric_systems(self):
        return [s for s in self.systems if s.biometric]

    def compliance_summary(self):
        hr = self.high_risk_systems()
        return {
            "vessel": self.vessel_name,
            "flag_state": self.flag_state,
            "imo_number": self.imo_number,
            "assessment_date": str(self.assessment_date),
            "total_ai_systems": len(self.systems),
            "high_risk_count": len(hr),
            "high_risk_systems": [s.name for s in hr],
            "cloud_act_exposure_count": len(self.cloud_act_exposure()),
            "biometric_systems": [s.name for s in self.biometric_systems()],
            "requires_eu_ai_act_conformity_assessment": len(hr) > 0,
        }


def build_typical_vessel_inventory():
    tracker = MarineEquipmentComplianceTracker(
        vessel_name="MV Example Vessel",
        flag_state="DE",
        imo_number="9999999",
    )

    tracker.register_system(MarineAISystem(
        name="AI-Enhanced ECDIS Route Optimisation",
        risk_level=RiskLevel.DEFINITIVE_HIGH,
        imo_standards=[IMOStandard.MSC_232_82, IMOStandard.IEC_61174, IMOStandard.SOLAS_V_19],
        failure_mode="Incorrect routing recommendation → grounding or collision",
        cloud_act_risk=True,
        notes="ML route optimisation module on cloud backend = CLOUD Act exposure",
    ))

    tracker.register_system(MarineAISystem(
        name="Adaptive Neural Autopilot",
        risk_level=RiskLevel.DEFINITIVE_HIGH,
        imo_standards=[IMOStandard.SOLAS_V_24],
        failure_mode="Uncontrolled yaw → grounding, collision, or capsizing",
        cloud_act_risk=False,
        notes="Onboard embedded ML — no cloud dependency",
    ))

    tracker.register_system(MarineAISystem(
        name="ARPA ML Clutter Suppression",
        risk_level=RiskLevel.DEFINITIVE_HIGH,
        imo_standards=[IMOStandard.IEC_62388],
        failure_mode="Failure to acquire collision-course vessel → collision",
        cloud_act_risk=False,
        notes="IEC 62388 type-test must include ML performance validation",
    ))

    tracker.register_system(MarineAISystem(
        name="Camera-Based BNWAS Watch Officer Monitoring",
        risk_level=RiskLevel.DEFINITIVE_HIGH,
        imo_standards=[IMOStandard.IEC_62616],
        failure_mode="Failure to detect incapacitated OOW → unmanned bridge incident",
        cloud_act_risk=False,
        biometric=True,
        notes="GDPR Art.9 biometric processing + EU AI Act Art.108 high-risk dual obligation",
    ))

    tracker.register_system(MarineAISystem(
        name="VDR AI Incident Analysis",
        risk_level=RiskLevel.CONDITIONAL_HIGH,
        imo_standards=[IMOStandard.IEC_61996, IMOStandard.SOLAS_V_20],
        failure_mode="Incorrect incident cause attribution → flawed investigation findings",
        cloud_act_risk=True,
        notes="High-risk if used in formal safety investigations; check Art.6(2) pathway",
    ))

    tracker.register_system(MarineAISystem(
        name="AIS Anomaly Detection (VTS)",
        risk_level=RiskLevel.CONDITIONAL_HIGH,
        imo_standards=[IMOStandard.SOLAS_V_19],
        failure_mode="False positive → vessel denied port access; false negative → security breach",
        cloud_act_risk=True,
        notes="High-risk when output triggers enforcement or access restriction decisions",
    ))

    return tracker


if __name__ == "__main__":
    import json
    tracker = build_typical_vessel_inventory()
    print(json.dumps(tracker.compliance_summary(), indent=2))

The Art.104–112 Amendment Series

Article 108 is the fourth in the Art.104–112 series of EU AI Act sector amendments, each inserting the high-risk pathway into existing EU product regulation frameworks:

25-Item Marine AI Compliance Checklist

System Classification (Items 1–6)

• 1. Confirm the AI system is embedded in ships' equipment covered by Directive 2014/90/EU (check MED Annex A equipment schedule)
• 2. Verify the applicable IMO performance standard (SOLAS Chapter, MSC Resolution, or IEC standard series)
• 3. Confirm the equipment requires or carries the wheelmark on EU-flagged vessels
• 4. Apply Art.6(1) test: Does the AI system constitute or embed in a safety component or system under Directive 2014/90/EU?
• 5. Identify whether any Art.5 prohibited AI practices apply (e.g., biometric BNWAS with subliminal manipulation)
• 6. Map the provider-deployer split: OEM AI developer (provider) vs. shipping company (deployer)

Technical Documentation (Items 7–12)

• 7. Prepare Annex IV technical documentation including AI architecture, training data provenance, and validation protocol
• 8. Document intended operational domain (vessel type, sea area, sea state range, traffic density)
• 9. Identify AI-specific failure modes not covered by current IEC performance standards
• 10. Map IEC 60945 environmental requirements to AI hardware deployment conditions
• 11. Document model update management process (over-the-air updates, version control, regression testing)
• 12. Align Annex IV documentation with ISM Code SMS (Safety Management System) equipment procedures

Conformity Assessment (Items 13–17)

• 13. Select the applicable MED conformity assessment module (Module B+D or Module H)
• 14. Identify the Recognised Organisation (DNV, Lloyd's, Bureau Veritas, RINA, ClassNK) as both MED and EU AI Act notified body (where dual appointment applies)
• 15. Integrate EU AI Act QMS (Art.9) requirements into the ISO 9001/IATF 16949 or marine-sector QMS
• 16. Issue EU Declaration of Conformity referencing both Directive 2014/90/EU and EU AI Act
• 17. Affix wheelmark with notified body number and document EU AI Act conformity assertion

Deployment and Monitoring (Items 18–22)

• 18. Implement Art.72 post-market monitoring plan: vessel performance data collection, near-miss reporting, AI anomaly logging
• 19. Establish Art.65 serious incident reporting pathway coordinated with SOLAS Casualty Investigation obligations
• 20. Provide Art.13-compliant user information for ISM Code operating procedures
• 21. Define STCW crew competency requirements for AI navigation system operation
• 22. Assess CLOUD Act exposure: identify all voyage data, VDR data, and AI telemetry processed on US-headquartered cloud platforms

CLOUD Act and Data Sovereignty (Items 23–25)

• 23. Audit ENC/chart update delivery infrastructure: identify US-cloud dependencies in ECDIS update chains
• 24. Evaluate fleet management platform data residency: ensure voyage performance data can be EU-hosted
• 25. Review BNWAS biometric data processing: confirm GDPR Art.9 lawful basis and data minimisation for camera-based watch monitoring

See Also

• EU AI Act Art.109: Amendment to Directive 2014/53/EU — Software-Defined Radio, Cognitive Radio and AI Spectrum Management Under the Radio Equipment Directive
• 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) No 168/2013 — Motorcycle and Two/Three-Wheel Vehicle AI Systems
• EU AI Act Art.105: Amendment to Regulation (EU) No 167/2013 — Agricultural Vehicle AI Systems
• EU AI Act Art.43: Conformity Assessment for High-Risk AI Systems
• EU AI Act Art.9: Quality Management Systems for High-Risk AI
• EU AI Act Art.72: Post-Market Monitoring for High-Risk AI Systems
• EU AI Act Art.26: Deployer Obligations for High-Risk AI Systems