AI Audit Trail for Maritime: Cyber Risk Records Inside the Safety Management System
IMO Resolution MSC.428(98) pushed cyber risk into the safety management system that every Document of Compliance rests on. Model requests from voyage planning, cargo documentation and shoreside operations now sit inside that scope. This article sets out what a per-request record has to carry so a flag state auditor can verify the control instead of reading a policy about it.

Resolution MSC.428(98) asked administrations to ensure that cyber risks are appropriately addressed in existing safety management systems, as defined in the ISM Code, no later than the first annual verification of the company's Document of Compliance after 1 January 2021. That deadline passed five years ago, and the safety management systems written to meet it describe firewalls, crew awareness and network segregation aboard. Almost none of them describe what happens when a port captain pastes a cargo manifest into a commercial chat product to get a faster summary. An ai audit trail maritime operators can show an auditor has to cover that request, because the SMS already claims it does.
I want to walk through where model usage lands inside ISM Code obligations, why the shipboard network diagram misses it entirely, and what the record needs to hold when a flag state verification asks how the control works.
TL;DR
- MSC.428(98) put cyber risk inside the ISM Code safety management system, so AI usage falls under an existing audited obligation instead of a new one.
- The MSC-FAL.1/Circ.3 guidelines stay deliberately high level, which leaves the operator to define what evidence the control produces.
- Shoreside requests carry more regulated content than shipboard ones, since cargo documentation, crew certificates and port clearance data live ashore.
- A record that satisfies a verification names the authenticated person, the vessel or voyage it concerned, the destination model and the data class, and it gets written before the response returns.
Where model usage lands in the ISM Code
The ISM Code, mandatory since 1 July 1998 through the 1994 SOLAS amendments that introduced chapter IX, obliges a company to establish safeguards against all identified risks and to maintain procedures that crew and shore staff actually follow. MSC.428(98) folded cyber risk into that structure rather than creating a parallel regime.
That choice has a consequence operators often miss. A gap in cyber risk management is a gap in the safety management system, which a flag state or recognised organisation audits during Document of Compliance verification. In practice it carries the same weight as a missing drill record.
The MSC-FAL.1/Circ.3 guidelines offer high-level recommendations on maritime cyber risk management and leave the implementation to the operator. High level leaves the operator to decide what evidence exists at all. An auditor reading a procedure that says staff must not disclose sensitive information to external services will reasonably ask how the company knows whether that happened.
The requests that matter happen ashore
Cyber risk work in this sector concentrated on the vessel, for good reason. ECDIS, the engine management network and the cargo control system carry direct safety consequences, and segregating them was overdue.
Model usage sits mostly in the other half of the business. A chartering desk asks for a summary of a fixture recap. An operations coordinator drafts a port authority letter from a stack of emails. A crewing team asks a model to compare certificate expiry dates across a roster containing seafarer identity document numbers. A claims handler pastes a statement of facts into a chat window while building a laytime calculation.
Each of those requests leaves the company network over ordinary HTTPS, carrying commercial terms, personal data of seafarers, or cargo details that a shipper considers confidential. The vessel network diagram in the SMS says nothing about any of it.
I think the honest reading is that the 2021 compliance wave produced a lot of documents and comparatively little measurement, and AI usage is the place where that gap now shows most clearly. A procedure nobody can verify is a procedure an auditor will eventually test.
What the record has to carry
The evidence that answers a verification question gets written at the moment the request leaves the authenticated user, before any answer comes back.
Per request, the useful content covers the timestamp, the person authenticated through the company identity provider, that person's role and the vessel or voyage the work concerned, the calling application or agent, the destination provider with model name and version, the classification applied to the request content, the policy version in force, the enforcement outcome, and a hash of request and response.
The vessel and voyage fields carry unusual weight here. An investigation after a cargo dispute or a charterer complaint asks which voyage was affected, and a record keyed only to a user account cannot answer that. Retrieval by vessel, by voyage number, by person or by time range turns the record from a log into evidence. Our cross-regulation view of the same problem sits in audit trail requirements by regulation.
Retention should follow the SMS document control schedule and the commercial record schedule, whichever runs longer. Charter party disputes surface years after the voyage, so a 90-day log rotation will have discarded the relevant record before anyone asks for it.
Agents in port and voyage workflows
Operators now run agents that draft port declarations, reconcile bunker figures and pre-fill customs submissions. Those flows authenticate with service credentials.
A service credential gives the network what it needs and gives the auditor nothing. The record shows an automated workflow submitted something. It cannot show which superintendent's instruction started it, which means the SMS accountability chain breaks at exactly the point an investigation would follow it. Carrying the initiating person through to the model request, and recording the person alongside the agent, keeps that chain readable. We covered the general shape in agentic AI audit trail.
DeepInspect
DeepInspect is a stateless proxy between authenticated users or agents and any LLM endpoint. Identity resolution, classification of request content, model routing and policy enforcement run inline on the HTTP request before it reaches the provider, which turns an SMS procedure into something an auditor can test.
Every decision writes a signed record holding the authenticated person, the role and the vessel or voyage context, the classification applied, the destination model and version, the policy version in force, the outcome and the timestamp. Records commit to append-only storage before the response returns, retention configures to match the SMS and commercial schedules, and retrieval by person, vessel, voyage, model version or time range completes in seconds. The boundary covers authenticated HTTP traffic between your people or agents and the models they call. SMS ownership, the designated person ashore role, the risk assessment itself and the flag state relationship stay where they are.
If your safety management system claims a control over external disclosure and nobody can produce a record of it operating, that gap will surface at the next verification. Book a demo today.
Frequently asked questions
- Does the IMO require an AI policy specifically?
No. MSC.428(98) and the MSC-FAL.1/Circ.3 guidelines address cyber risk in general terms and name no technology. AI usage enters scope through the company's own risk identification under the ISM Code, which is why adding the model routes to the risk assessment is the practical starting point.
- Is a prompt containing seafarer personal data a reportable incident?
That depends on the company's own classification and on the data protection regime governing the crew's residence or the flag. The security team's job is to produce the record that lets the designated person ashore make that call on facts.
- Can we rely on our shipboard network controls?
Not for this. The requests that carry regulated content mostly originate ashore, on corporate laptops with ordinary internet access. Vessel segregation does useful work and does not touch this traffic.
- What will a flag state auditor actually ask for?
Expect a request for the procedure, the risk assessment that justified it, and evidence the control operated during the period under review. The third item causes the trouble, since a policy document proves intent and a record proves operation.