AI on the bridge: what the regulations actually allow

The maritime industry has been discussing AI on the bridge for several years. The conversation is often confused — partly because "AI" covers a very wide range of capabilities, and partly because the regulatory framework was written before AI systems were a real commercial prospect. The result is two kinds of error: operators who assume any AI on the bridge requires type approval and avoid it entirely, and operators who assume any AI tool is fine as long as it's marketed correctly.

Both errors are costly. The regulatory framework is actually clear. The question is whether you know where the line is.

The line that matters: informing vs. advising

SOLAS Chapter V establishes the framework for navigational equipment on ships. Under MSC.Circ.982 and the broader e-navigation framework, systems that output navigational recommendations — route alterations, speed changes, collision avoidance actions — require type approval by flag state authorities and, in many cases, class society review. These systems affect the vessel's navigation directly, so they need to be certified as fit for purpose.

ECDIS has type approval. AIS transponders have type approval. Radar has type approval. Any system that a future ECDIS or AIS standard absorbs will need type approval. If you are building a system that outputs a recommended course alteration to avoid a close-quarters situation and that output influences the OOW's navigation, you are in type-approval territory.

Electronic logbooks, voyage data recorders, alarm management systems, and AIS tracking displays operate on the other side of this line. They are information systems — they present data to the OOW, who then makes decisions. They do not output navigational recommendations. They do not need type approval.

What this means for AI systems in practice

An AI system that answers the OOW's questions about historical voyage data — "what was the weather when we transited this channel last month?" or "what does the standing order say about fog procedures?" — is an information system. It retrieves and presents data. It does not advise the OOW on what to do next.

An AI system that processes voice commands to create log entries — "log: altered course to 280° due to traffic density, time 0347" — is a record system. It captures what the OOW dictated and creates a timestamped record. It does not recommend the course alteration; it records the one the OOW already made.

An AI system that displays the current AIS picture, labels targets with their CPA and TCPA calculations, and surfaces alarms when thresholds are breached is presenting information — the same information that's available from the ARPA display, organised differently. No new navigational output. No type approval required.

Why the framing matters commercially

Type approval is not a bureaucratic obstacle — it is a multi-year, multi-jurisdiction process that typically costs several hundred thousand euros and requires significant ongoing maintenance as flag states and class societies update their requirements. For a startup building its first product, entering type-approval territory without full understanding of the implications is a way to consume runway without reaching market.

More importantly: a system that claims to be a record system but actually outputs navigational recommendations is not in a regulatory grey zone — it is non-compliant. The consequences of installing non-compliant equipment on a vessel go well beyond commercial risk. P&I clubs and insurers assess these questions carefully after incidents.

The correct path for AI on the bridge in 2026 is to build capable, genuinely useful systems within the record-system boundary — and to be transparent about where that boundary is. The regulatory framework rewards precision; it does not reward euphemism.