The satellite link a ship depends on is a weak, expensive, weather-sensitive channel — and its worst moments correlate with exactly the situations where AI assistance would be most valuable. Rain fade, coverage gaps, congestion, jamming, cost caps: the link is a scarce resource that cannot be assumed. Maritime AI that needs the cloud is maritime AI that fails when it's needed.

Intermittent connectivity is therefore the defining constraint of shipboard AI — not a deployment detail, the architecture.

Key findings

  1. Satellite links degrade precisely under the conditions (weather, sea state, congestion) when AI assistance is most valuable. Established
  2. Offline-first is the architectural requirement: every safety-relevant function must work with zero link. Established
  3. The design pattern is store-and-forward + local inference — the link adds capability, it never removes safety. Maritime-GPT analysis
  4. Model-update-over-link is the legitimate cloud use — fetch improvements when connected, run without it when not. Established
  5. Jamming and interference are now operational realities — the link can be denied adversarially, not just environmentally. Established
Ship in heavy weather
The worst sea state is the worst comms state — the AI must be designed for the link that isn't there.Image: U.S. Navy photo by Photographer's Mate 3rd Class Inez Lawson. · Public domain

Satellite links to ships fail in the ways that correlate with the situations AI would help with: heavy weather attenuates the signal; the approach to a congested port congests the network; a GNSS-jamming region is often a comms-jamming region; and cost caps mean the link is rationed in normal operation. The result is a connectivity profile that is worst exactly when the demand is highest. Established

The offline-first architecture

  • <strong>Local inference, always.</strong> The safety-relevant functions — collision support, alarm interpretation, the copilot — run on shipboard hardware, no dependency on the link. Established
  • <strong>Store-and-forward data.</strong> Telemetry buffers aboard, syncs when the link is up — the model sees the full picture eventually, not in real time. Maritime-GPT analysis
  • <strong>Graceful capability degradation.</strong> The connected version is richer; the disconnected version is safe — the system must be honest about which mode it's in. Established
  • <strong>Local corpus for retrieval.</strong> The RAG corpus lives aboard — compressed, versioned, synced when possible — so the regulatory reference works offline. Maritime-GPT analysis

What the cloud is actually for

The honest use of connectivity is asymmetric: the link is for improvement, not for operation. Model updates, new data, the richer analysis the ship can pull when connected — those are the cloud's job. The core functions that must work are aboard. This is the edge-vs-cloud answer the maritime evidence keeps arriving at: the cloud augments, the edge operates, and the system's safety case must be valid in the disconnected mode alone. Maritime-GPT analysis

What we know

  • Intermittent connectivity is a design constraint, not an exception case.
  • Safety-critical functions must be fully offline-capable.
  • The link's legitimate role is augmentation — updates, enrichment, shore sync.

What we don't

  • How much of the copilot/diagnostic capability survives full disconnection.
  • Whether sync-after-fact is enough for fleet-level learning.
  • The real reliability numbers for shipboard satellite links in heavy weather.

Being tested

  • Store-and-forward fleet-data sync architectures.
  • Local-corpus RAG for offline regulatory queries.
  • Degraded-mode UIs that show the operator when the AI is offline-limited.

Maritime-GPT analysis

Intermittent connectivity is the constraint that separates real maritime AI from demos. A system that needs the cloud is a system that fails in a storm. The correct architecture treats the link as a bonus — model updates and enrichment when it's there, full function when it isn't. Offline-first isn't a feature; it's the admission ticket. Maritime-GPT analysis

This is a research feature, not operational guidance. Simulation results are reported as simulation; demonstrations are not deployments; company claims are attributed as such. Verify safety-critical decisions against official nautical publications and flag-state requirements.

Sources & evidence

Maritime-GPTCompanion research
Edge AI at sea

The onboard-compute architecture offline-first implies.

Maritime-GPTCompanion research
Small language models for ships

The sized-for-offline model answer.

Maritime-GPTCompanion research
GNSS jamming detection

The adversarial-link case — connectivity denied, not just absent.

IMOOfficial IMO page
Autonomous shipping — MASS framework

The connectivity requirement the offline-first design addresses.