Sovereign AI for Ports, Maritime and Logistics

Sovereign AI for ports, maritime and logistics is an operator-owned intelligence system that runs on the port authority's own hardware, inside its own perimeter, with every decision written to a tamper-evident, cryptographically signed ledger. It is the defensible shape because a port handles customs declarations, security screening results and commercially sensitive cargo data that must not leave the operator's control, and a public cloud AI service cannot make that guarantee. Mickai is a Sovereign Intelligence Operating System, a SIOS, built for exactly this profile: it runs offline, answers only to the operator, and seals each action so a decision can be replayed and checked months later.

This matters more in 2026 than two years ago. Ports are named critical national infrastructure, cargo throughput is increasingly steered by automated decisions, and regulators now expect operators to show operational resilience and an auditable record, not just a vendor's assurance. At the same time, piping port data into a general public model exports the operator's most sensitive information, and the reasoning behind its decisions, to a third party. Sovereignty is the response to that trade.

Why is a port different from an ordinary enterprise buyer?

A port is not a back office. It holds customs and excise data, security and screening outcomes, crew and passenger identity records, and cargo manifests that a competitor would pay to see. It also touches physical control: gates, cranes, reefer power and vessel traffic. Software decisions here have weight. A model can hold a lorry at a gate, flag a container for inspection or reprioritise a berth. When that decision is later challenged by a shipper, an insurer or a customs officer, the operator must be able to produce the record and stand behind it. Moving any of that data to an external cloud moves the decision, and the accountability, outside the operator's reach.

How does an operator-owned, air-gapped-capable system work?

The system installs on hardware the operator owns and sites inside its own network. Sovereign models run locally, so inference never leaves the building. The perimeter is zero-egress: data and instructions come in, nothing phones home to a vendor. For the most sensitive environments the system runs fully air-gapped, with no route to the public internet. Identity is hardware-attested, so each operator, device and model instance carries a cryptographic identity bound into the audit chain. The record then shows not only what was decided but which attested actor decided it, on which attested machine.

What can an auditor actually check?

Every action is written to an append-only ledger and signed with a post-quantum signature using FIPS 204, the ML-DSA standard. Data at rest and in transit is protected separately with key encapsulation under FIPS 203, ML-KEM, which secures keys but does not sign the record. An auditor can verify the ledger offline, without a network connection and without having to trust us. There is a simple test. Take any decision, pull its ledger entry, verify the signature against the attested identity, then replay the recorded inputs. If the signature holds and the inputs reproduce the same output, the record is intact. If a single byte was altered, verification fails and the tampering is visible.

“In critical infrastructure, the system that decides must also be the system that can prove, offline and after the fact, exactly what it decided and why.”

Which rules make this the necessary shape?

Several duties point the same way. DORA, in force since January 2025, presses financially connected operators on operational resilience and third-party risk. NIS2 raises the bar for critical infrastructure security and incident accountability. GDPR governs the personal data inside crew, passenger and workforce records. ISO/IEC 42001 sets an AI management-system baseline that buyers increasingly ask for. On the EU AI Act, the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moved to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. An operator-owned, auditable architecture does not by itself satisfy any of these regimes, and no vendor can promise that it does, but it supports the underlying duties and reduces the exposure that a cloud-first design creates.

Why can a port not simply use a public cloud AI service?

ChatGPT, Claude and Gemini are capable systems, but they are the wrong custody model for regulated port data. A contractual promise not to retain or train on your inputs is a promise, not a technical control, and a contractual promise is not the same as a guarantee you can verify. Under the US CLOUD Act, a US-headquartered provider can be compelled to produce data it holds regardless of where the servers sit, which creates real exposure for customs and security records. We do not claim that using such a service breaches any specific law. We say it creates risk that a sovereign, operator-owned design removes at the root, because the data and the decision never leave the operator's hardware.

How does cross-model consensus reduce the risk of a bad decision?

A single model can be confidently wrong, and in a port that can mean an unjustified hold or a missed screening flag. In our architecture several sovereign models can run the same query and their outputs are compared. Where they agree, the decision carries more weight. Where they disagree, the system escalates for human review rather than acting on one silent answer. The comparison itself is written to the ledger, so a later reviewer can see not just the outcome but the spread of opinion behind it. This architecture is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented.

Frequently asked questions

Can sovereign AI for ports run fully offline or air-gapped?

Yes. The system installs on operator-owned hardware and runs its models locally, so it can operate with no outbound connection at all. In an air-gapped deployment there is no route to the public internet, which suits customs halls, security screening and other environments where data cannot be allowed to leave the site.

What is a post-quantum signed audit ledger and why does a port need one?

It is an append-only record where each entry is signed with a post-quantum signature standard, FIPS 204 ML-DSA, so tampering is detectable and the record stays verifiable even as cryptography advances. A port needs one because its automated decisions are routinely questioned, and the ledger lets the operator prove after the fact what was decided, by which attested actor, and on what inputs.

Does an operator-owned system help with DORA and NIS2?

It supports the duties those regimes impose, such as operational resilience, third-party risk control and incident accountability, by keeping data and decisions inside the operator's own perimeter and producing a verifiable record. It does not by itself deliver compliance, and no architecture should be sold as if it does. Compliance remains the operator's responsibility.

Is a public cloud AI service ever acceptable for customs or cargo data?

For low-sensitivity, non-regulated tasks it may be. For customs declarations, security screening and commercially sensitive manifests, the custody and legal-reach questions are hard to close, particularly given the US CLOUD Act. The safer default for that data is a sovereign, operator-owned system where the information never leaves the operator's control.

Who owns the data and the audit record in an operator-owned system?

The operator does. Because the system runs on the operator's hardware inside its own network, the data, the models in use and the signed audit ledger all stay under the operator's ownership and control. There is no vendor-held copy to subpoena, mine or lose, which is the point of the sovereign design.