- Coastal/inland autonomy is advancing fast — because the operating domain is constrained and support is close. Deep sea is not that domain.
- The big blockers offshore aren’t “more AI”: they’re redundancy economics, authority/liability, and evidence for rare edge cases.
- The near-term win is AI-assisted operations (decision support + remote expertise) while humans remain responsible — so bridge/engine human factors still matter.
The Digital Kraken lives offshore
Autonomous ships exist.
But “crewless, commercially routine, transoceanic shipping” is a different species of problem.
Once you’re out of sight of the coast, a kind of digital Kraken waits for anyone who thinks autonomy is “software + sensors.” Not a monster in the mythological sense — a monster in the engineering sense: rare failures, degraded modes, and long stretches where the ship must survive without help.
So, let’s separate what’s real progress from what’s wishful extrapolation.
The category error: people mix up two axes
Axis 1: Where you operate (ODD) Autonomy is always tied to an Operational Design Domain — the conditions where it’s designed to work safely.
- Inland/ports: short routes, more infrastructure, fast assistance.
- Coastal/short-sea: repeatable routes, better comms, closer help.
- Deep sea: weeks offshore, harsh conditions, and “send a technician” isn’t a strategy.
Traffic density and choke points are why “open ocean” doesn’t mean “simple autonomy.” Credit: Rignetta (CC BY‑SA 4.0), via Wikimedia Commons.
Axis 2: What you mean by “autonomy” Are we talking about: decision support with crew onboard, remote assistance, remote control, reduced crew, or truly uncrewed operation?
Those are not incremental software versions. They’re different operational designs – with different safety cases, training needs, and liability outcomes.
Regulation reality check: milestones aren’t the same as normality
The IMO’s work on Maritime Autonomous Surface Ships (MASS) is moving — but it’s moving in steps.
The roadmap targets finalization and adoption of a non-mandatory MASS Code in May 2026, with work toward a mandatory code later (with indicative dates extending into the 2030s). That’s a major governance milestone – and also a signal that the transition is long by design.
Translation: regulation is being built to accommodate autonomy, but it’s not a green light for “crewless deep-sea at scale next year.”
Blocker #1: redundancy economics (and the engine room is the boss level)
Most autonomy talk is bridge-centric (COLREGs, sensors, target tracking). Deep sea is engineering-centric.
The ship is a floating industrial plant that also needs to avoid other floating industrial plants — in weather — for weeks.
Deep‑sea autonomy fails in the engine room long before it fails in a slide deck. Credit: U.S. Navy (Public Domain), via Wikimedia Commons.
If you try to remove crew offshore, you replace human adaptability with hardware + software redundancy, fault detection, and recovery systems.
That adds:
- capital cost (more systems)
- integration complexity (more interactions, more surprises)
- lifecycle burden (maintenance of “hope-you-never-need-it” systems)
- validation burden (proving failover logic is safe)
At some point, the “remove crew = save money” narrative collides with the redundancy bill. The result is often a hard question:
Is the unmanned-ready ship actually cheaper or more reliable than a professional crew using proven procedures?
This is not anti-tech. It’s reliability math.
Blocker #2: authority & liability (who is Master when ship/shore/AI disagree?)
Even with great sensors and control, remote operations create a governance puzzle that shipping has spent a century simplifying:
- Who has final authority in a time-critical collision-avoidance decision?
- If shore recommends one action and ship executes another, whose decision was it?
- How does that interact with flag state oversight, class expectations, and P&I reality?
The hard part isn’t writing a policy memo that says “shore supports ship.” The hard part is designing a system where, under stress, everyone knows who is responsible — and the evidence trail doesn’t become a blame machine.
Deep-sea autonomy won’t scale until command and liability are operationally boring.
Blocker #3: evidence (rare edge cases don’t show up on your sprint backlog)
Shipping doesn’t get the “billions of miles” advantage road vehicles got.
Deep-sea operations have:
- fewer instrumented “runs”
- slower iteration cycles
- rare, messy scenarios that matter most
The most valuable seamanship knowledge is often tacit, learned through near-misses and judgment calls — and rarely captured as clean training data.
Rule compliance isn’t only detection – it’s judgment under uncertainty, in real traffic. Credit: Yannbertholet (Public Domain), via Wikimedia Commons.
So the answer isn’t “more AI.” It’s a proof pipeline:
- scenario libraries (including near-misses)
- simulator-to-sea validation
- clear ODD boundaries, expanded only when evidence accumulates
- safety cases that class / flag / insurers can actually interrogate
If you can’t explain how safety is proven in degraded modes, you don’t have autonomy — you have a demo.
What’s real right now: AI-assisted shipping (humans still central)
The real story in deep sea (today) looks less like “remove crews” and more like:
- better route optimization and weather risk management
- higher-frequency operational data and decision support
- shore-side expertise supporting bridge teams
Large operators already describe 24/7 operational support centers that guide ships and recommend safer routing — autonomy as assistance, not crew replacement.
This is the “human-in-the-loop” era: tools get stronger, humans remain responsible.
That’s why we should obsess less over the sci-fi endpoint and more over the transition safety problem: How do we reduce errors while humans are still the primary safety system?
What good looks like (design principle + procurement boundary)
Here’s my bias, stated clearly:
Assist the bridge, don’t audit it. Design systems to support watchkeeping and learning – not to create surveillance-heavy bridges or perfect-compliance theatre.
Practical implications:
- Define the ODD, and make degraded mode behavior explicit
- Treat the engine room as first-class in autonomy design (not an afterthought)
- Build training and simulator validation into deployment, not as a “phase 2”
- Put authority and override rules in writing and drill them like emergencies
- Keep data governance strict: purpose limits, minimal retention, controlled access
- Treat cyber resilience and comms outages as safety-critical, not IT issues
Checklist: 10 questions to ask before believing an autonomy claim
- What is the ODD (weather/traffic/geography/comms limits)?
- What happens in degraded modes (sensor loss, comms loss, power faults)?
- What is the redundancy architecture (and what does it cost to maintain)?
- Where does engineering fault recovery sit in the concept (onboard/shore/robotics)?
- Who has final authority during conflict: ship vs shore vs automation?
- How is the safety case structured — what evidence is accepted?
- What is the scenario library and simulator validation approach?
- What are the human factors safeguards (automation bias, deskilling, alert fatigue)?
- What is the data governance (retention, access, purpose limitation)?
- What is the cyber + comms resilience plan when links degrade?
If a vendor can’t answer these cleanly, the Kraken is already tapping the hull.
Closing question (for practitioners)
If you work in class, P&I/claims, pilotage, remote ops, or deep-sea operations:
Which blocker is hardest in practice — redundancy economics, authority/liability, or evidence for edge cases — and what would you accept as “proof” that the industry has crossed that barrier?
Disclosure: I am the founder of ELNAV.AI and the designer of Aware Mate, a bridge watchkeeping monitoring system. I therefore have a commercial interest in this space. The views here are my own, based on more than three decades around ships. Not legal advice: regulatory commentary is informational; consult legal/compliance for decisions.
Sources
IMO – Autonomous shipping (MASS roadmap incl. May 2026 non-mandatory code): https://www.imo.org/en/mediacentre/hottopics/pages/autonomous-shipping.aspx
IMO – MSC 110 meeting summary (revised MASS roadmap / indicative dates): https://www.imo.org/en/mediacentre/meetingsummaries/pages/msc-110th-session.aspx
The Nippon Foundation – MEGURI2040 program overview: https://en.nippon-foundation.or.jp/what/projects/ocean/meguri2040
The Nippon Foundation – ‘Olympia Dream Seto’ MEGURI2040 project page: https://en.nippon-foundation.or.jp/what/projects/ocean/meguri2040/olympiadreamseto
CMA CGM Group – 2024 CSR Report (Fleet Center described as 3 entities covering time zones): https://www.cmacgm-group.com/api/sites/default/files/2025-03/2024%20CSR%20Report%20CMA%20CGM%20Group.pdf
Maritime Executive – Japan licenses autonomous navigation Ro-Pax ferry (Olympia Dream Seto): https://maritime-executive.com/article/japan-licenses-its-first-autonomous-navigation-ro-pax-ferry