Executive summary

Ship management runs on correspondence and paper. A shore office of a few superintendents handles thousands of vessel emails a week, keeps hundreds of statutory certificates current, answers Port State Control, reviews inspection and noon reports, and knows where the manuals are. The people who can do this well are scarce, and every new vessel adds load exactly where the team is thinnest.

General-purpose chatbots have not changed this. Pilots stall because a chat window has no scope, no tools, no memory of the fleet and no place in the workflow. What works is narrower and less glamorous: specialist agents, each with one job, a fixed set of tools and a person at the end of the loop.

The second decision, and the one this paper is mostly about, is where the model lives. Sending operational email, certificates and contracts to a hosted frontier API means a third party sees the prompt, keeps it under its own retention terms, and can change or retire the model on its own calendar. An open-weight model running on a dedicated GPU inside the client's own environment removes those dependencies. In our experience it is also cheaper at fleet volume, and considerably more reliable than a metered API that can stop answering when a credit balance runs out.

The paper makes six claims and shows the working for each:

1. The job is agentic, not conversational. Email triage, certificate extraction, PSC root-cause analysis and report validation are repeatable tasks with a review step, not open-ended chats.
2. The model should live with the data. Single-tenant environments in a region the client chooses, with inference inside them, are the simplest way to satisfy ISM cyber obligations, data-protection law and a client's own security review.
3. Localised models are more reliable in practice. Four outages in one month, twenty thousand silent failures and a quality collapse caused by a vendor model swap are the kinds of incidents a hosted API produces and a pinned local model does not.
4. At fleet volume, the economics favour the GPU. One fleet's email-analysis workload costs roughly $960 to $2,400 a month on frontier APIs at list price and about $320 a month on one dedicated GPU. Batch document work is cheaper still.
5. Quality is a measurement problem, not a brand problem. With held-out test sets and field-by-field gates, open-weight models met or beat the hosted baseline on the tasks that matter, and the few tasks that still need a frontier model can go through a controlled gateway.
6. Gains come from knowing the job. Because we have mapped what each role in a ship-management office does hour by hour, we know exactly which steps to automate, which to prepare for a person, and which to leave alone. That is what turns a model into time back on every desk.

The closing section is a twelve-question checklist for evaluating any AI vendor, ours included.

The work of a ship-management office

The shape of the workload matters more than its size, so it is worth being concrete. For one manager running Sea-Squad in production, eight shore mailboxes receive on the order of 1,200 to 2,700 email threads a day.¹ Roughly a quarter of those need a reply; the rest need to be read, classified, linked to the right vessel and, where they contain an action, turned into a task with an owner. Superintendents used to do this by reading everything.

Email is only the lighter half. Attachments carry three to eight times the token load of the messages they arrive with: class reports, survey records, requisitions, drawings, certificates and manuals, most of them scanned.² A fleet's document archive runs to tens of thousands of pages, and it is useless to any AI system until it has been read by a machine that preserves tables, certificate numbers and dates exactly as written.

Around this sit the structured obligations: a certificate register with one slot per statutory and class certificate per vessel; Port State Control findings that recur across a fleet in ways nobody sees from inside one vessel's file; periodic reports on templates that change; inspections captured on board, often offline, and written up on shore days later.

Three properties of this work decide what kind of AI helps:

• It is repetitive with judgement at the edges. Ninety per cent of a technical inbox is classification and routing. The remaining ten per cent needs a superintendent, and needs the context the first ninety per cent produced.
• It is confidential by default. Charter parties, claims correspondence, crew records, defect lists and commercial terms are in the same inbox as vendor newsletters. There is no clean split between "sensitive" and "safe to send to a model".
• It is audited. Since 2021 the ISM Code has required cyber risk to be managed within the Safety Management System, and auditors check it.³ Anything that reads the company's operational data is inside that boundary.

A chat window addresses none of this. It has to be told the context every time, it cannot act, it has no review step, and every question sent to a hosted service is an outbound transfer of operational data. The teams that got value from AI did something else.

Specialist agents, not a chatbot

An agent, in the sense used here, is a small system with a scope, a set of tools, a review step and an audit trail. It does one class of work end to end and hands the result to a person.

Sea-Squad ships six agents, four of them in production today:

The design rules are the same across all six:

• The agent drafts; a person decides. Reply drafts are generated on request and shown with the emails and documents they relied on. Nothing is sent by the system.
• Extraction never overwrites a human value. When a certificate is uploaded, the expiry date and number are read automatically, but only into fields that are still empty. A value someone typed is never silently replaced.⁴
• Uncertainty is flagged, not guessed. PSC extraction records a deficiency code only when it is confident, marks the rest for a person, and keeps a "reviewed" marker on every finding.⁴
• Everything has a source. Answers cite the document, page or record they came from, and the citation opens the original.
• Scope is enforced by the platform, not the prompt. A user assigned to five vessels cannot query the sixth, whatever role they hold. Out-of-scope items appear as an anonymous count, never hidden without explanation.⁵

Built from the working day, not the demo

The reason the agents are shaped this way is not a theory of AI. It is that we sat with the people who do the work. Before any model was chosen we mapped the day of each role in a ship-management office: what arrives, in what form, what has to happen to it, who has to see it, and where the time actually goes. The picture that emerged is consistent across fleets.

Understanding the day at that resolution changes what "automation" means:

• The right unit of work. A superintendent does not want an inbox summarised; they want the three decisions that need them today at the top, and the rest already assigned. That is a different feature from a chat window, and a cheaper one to run.
• The right hand-off point. Extraction, classification, linking and drafting are automated because they are high-volume and checkable. Sending, approving, signing and deciding are left with people because that is where judgement and accountability live. The line is drawn per step, not per module.
• The right order. The first thing automated on a new fleet is whatever consumes the most senior hours: usually the technical inbox, then certificates, then PSC. Each step pays for the next.
• The right measure. Every automated step has a before and an after we can count: emails triaged without a person opening them, certificates extracted without a re-key, RCAs drafted with the fleet's history attached. Those counts, not model benchmarks, are how a deployment is judged.

This is why the gains compound. The model is a component; the map of the working day is the product. Each role gets back the hours its most repetitive work consumed, and the office as a whole gets a shared, current picture of the fleet that no amount of individual effort produced before.

None of this requires the largest model available. It requires a model that follows a schema, reads a scanned page faithfully and stays inside the context it is given. Those are properties that current open-weight models have, and that we can measure.

Where the model lives decides who owns the data

Every AI feature is, mechanically, a function that takes the company's text and returns more text. The only architectural question that matters for sovereignty is where that function executes.

The hosted API, honestly described

The large providers have improved their enterprise terms, and it is fair to say so. OpenAI's API does not train on business customers' data by default and offers Zero Data Retention for eligible enterprise endpoints. But the defaults are worth reading: API prompts are retained for 30 days for abuse monitoring unless ZDR is negotiated through sales, ZDR does not apply to ChatGPT or Team plans, and even under ZDR some metadata is kept.⁶ Anthropic's commercial terms are similar in spirit. In every case the company's operational text leaves its environment, crosses the public internet, is processed on shared infrastructure in a region the provider chooses, and is governed by a policy the provider can change.

For most software this is an acceptable trade. For a ship manager it creates four specific problems:

1. The security questionnaire. A client's IT reviewer will ask where inference runs, who can see prompts, and under what law. "A US provider, region not selectable, 30-day retention unless we negotiate otherwise" is an answer that lengthens every procurement.
2. The regulatory perimeter. The ISM Code's cyber requirement, updated in the IMO's May 2026 guidelines, asks for senior-management-led risk management of every system that touches operations, with integrated and complex systems singled out for care.³ India's DPDP Rules 2025 permit cross-border transfers today but reserve the government's right to restrict destinations, and place extra duties on significant data fiduciaries.⁷ The EU AI Act's obligations for general-purpose model providers became enforceable on 2 August 2026, with downstream deployer duties following.⁸ Each of these is easier to satisfy when the data does not move.
3. Contracts with the fleet's counterparties. Charterers, owners, P&I clubs and shipyards impose confidentiality terms of their own. Some of them were written before anyone imagined the correspondence being forwarded to a model vendor.
4. The exit. When the engagement ends, what does the provider hold, and how would anyone know?

The localised alternative

The alternative is not exotic. Open-weight models from several labs are now published under permissive licences and run on a single rented or owned GPU with the same inference API the hosted services expose.⁹ Sea-Squad's production architecture places that GPU inside each client's environment: one deployment per client, with its own compute, database and object store, in a region the client chooses, and the model alongside the data.⁵

The consequences are simple to state:

• Prompts and documents never leave the client's environment. There is no third-party retention policy to negotiate because there is no third party in the path.
• The model version is pinned by the client's deployment, not by a vendor's deprecation calendar.
• Egress is allow-listed at the network layer, so a misconfiguration cannot quietly route traffic to a public API.
• The audit trail, access controls and export on exit are the same for the AI layer as for the rest of the system, because it is the same system.

For clients with stricter requirements, the same stack runs on hardware they own. One box, one company; Sea-Squad's support login exists on that box but is visible in the client's own audit log and can be revoked.

Reliability and control

Cost and sovereignty are the arguments people expect. The one that surprised us in production was reliability.

A hosted API is a metered dependency. In one thirty-day period our earlier hosted configuration suffered four separate outages caused by an exhausted prepaid balance; two of them ran for a full day before anyone noticed, because a request that fails fast looks, to a queue, much like a request that succeeded.¹⁰ Over a separate four-day window roughly twenty thousand calls failed in about 74 milliseconds each without raising an alert.¹⁰ Each failure left an email stored and visible but never analysed, with no reminder created and no draft prepared.

Silent degradation is worse than an outage. When a cheaper hosted model was substituted for email analysis, every call succeeded, latency improved, and the output quietly lost a field. Eighty per cent of mail landed in a single "general" category; reminders fell from about 250 an hour to 15, drafts from 60 to 5. One thousand four hundred and eight emails were analysed in that degraded state before the change was caught.¹¹ Nothing in the vendor's status page or the HTTP responses indicated a problem, because from the vendor's point of view there was none.

A pinned model on a GPU you control does not have these failure modes. It can still break, but it breaks visibly, on your own monitoring, and it does not change behaviour between Tuesday and Wednesday because a provider re-routed traffic. Two practices make the difference:

• Every AI call is recorded in an in-house usage ledger: provider, model, task, tokens, cost, latency and outcome, kept for 180 days. Spend alerts fire at defined daily thresholds. No third-party observability service sees the prompts.¹²
• Outage behaviour is designed, not discovered. Uploads always succeed and park as pending; a document backlog is drained when the model lane is up; email analysis retries rather than burning attempts; nothing "fails fast" into a success state.

The economics

The common assumption is that hosted APIs are cheap and GPUs are expensive. At small volume that is true. At the volume of a working fleet office it inverts, and for batch document work it inverts by an order of magnitude.

One fleet's email workload

Take the measured monthly load for email analysis alone at one Sea-Squad client: about 360 million input tokens and 24 million output tokens across roughly 137,000 calls, from eight mailboxes.¹³ Priced at September 2026 list rates for frontier APIs, and against one dedicated GPU:

Two fairness notes. Prompt caching on the hosted side roughly halves the input bill for this workload, because the system prompt dominates; even so, the hosted options remain two to four times the GPU at this volume, and the caching itself is another vendor-specific behaviour to manage.¹⁴ And the GPU line is compute only: someone has to run it. We return to that below.

The GPU also does not stop at email. The same card serves the assistant, drafting, reminder extraction and the document lanes, whereas each of those adds to the hosted bill. Measured in an evaluation on an A40, a 27-billion-parameter open-weight model handled email-class requests at about 26 per minute with zero errors, comfortably above the fleet's average load.¹⁵

Batch document work

Document pipelines are where the gap opens. Two measured examples from Sea-Squad's own corpus:

• Context enrichment. Adding a vessel, document and section header to every one of roughly 300,000 document chunks, so that search and answers carry their context, cost about $3 to $4 of GPU time on a localised model. The same job on hosted APIs was estimated at $75 to $150.¹⁶
• Optical character recognition. A single overnight session on one rented GPU read 19,117 pages across 332 documents, including a 1,248-page ECDIS manual, with no per-page API charge.¹⁷ Commercial OCR at around $1 per thousand pages would have cost a similar amount for that one run; the difference is that the localised pipeline can be re-run on the whole archive every time it improves, at GPU cost only, and the pages never leave the environment.

What self-hosting actually costs

The GPU line is not the whole story, and a paper that pretended otherwise would not survive an IT review.

• Operations. Someone provisions the lane, watches its health, applies updates and holds the rollback. In a managed Sea-Squad deployment that is us; on a client-hosted box it is a shared responsibility with a runbook.
• Cold starts and sizing. A 27B model takes about fifteen minutes to load onto an A40 and needs quantisation to fit; a dense model of that size on that card is the wrong shape for OCR, where a mixture-of-experts model on a larger card read pages at roughly 1,900 an hour instead of 150.¹⁵ Choosing the right model for each lane is engineering work.
• Evaluation. Every model change goes through held-out test sets and field-by-field comparison before it carries traffic. Hosted vendors do this for you, invisibly, and the incident above shows what invisibly can mean.
• The crossover. For a very small operation, a hosted gateway to open-weight models at fractions of a cent per call is hard to beat on price. The GPU wins once any of three things is true: volume (roughly ten times a single mailbox's load), a sovereignty requirement, or a need for behaviour that does not change without notice. Most ship managers meet at least two.

Quality without a frontier model

The reasonable objection is that the largest hosted models are simply better. On general benchmarks they are. The question for a ship-management workload is narrower: is the open-weight model good enough at this task, and how would we know?

The method

We treat model choice as an evaluation problem:

1. Held-out sets with known answers. For OCR: pages with verified transcriptions, including certificate numbers, tables, handwritten annotations and poor scans. For email: real threads with agreed categories, priorities and vessel links.
2. Field-by-field comparison against the incumbent, not an overall impression.
3. Three-way bake-offs where a change touches production: the candidate, the current model and the original baseline, on the same stratified sample.
4. Partial adoption. Where a candidate underperforms on one document type, that type stays on the existing lane. Nothing is migrated on a slogan.

What the measurements showed

Sources for each row are in the references.^{15 16 17}

Two lessons generalise. Turning off "reasoning" or "thinking" modes for mechanical tasks such as transcription improved throughput roughly sixfold with no loss of quality, because transcription needs fidelity, not deliberation.¹⁷ And the failure of the dense 27B model at OCR is the point, not an embarrassment: the right answer was a different open-weight model on a different card, found by measurement in a week, not a return to the hosted API.

Where frontier models still belong

Some tasks genuinely benefit from the strongest available model: long, ambiguous legal reasoning, or research across the open web. The pattern for those is a controlled gateway: a single, allow-listed route to a hosted model, enabled per task by the client, with prompts scrubbed of identifiers where possible and every call logged in the same ledger. It is an exception with a switch, not the default path for operational data.

Reference architecture

The environment is the unit of deployment. Each client gets one, and every layer of it is the client's:

• Edge. TLS everywhere; documents served through short-lived signed URLs scoped to one file and one request; outbound egress allow-listed so nothing reaches a public model API unless a client has enabled that gateway.
• Application. The API and background workers, the Outlook add-in, and the sync endpoint for the offline-first inspection app. The mobile app carries no model on board; it captures, queues and syncs.
• Data. The document database, cache and object store, with encrypted backups on a defined schedule and a rehearsed restore.
• AI lane. One or more GPUs running open-weight models: a vision-language model for documents, a text model for email and the assistant, a reranker for retrieval, and the usage ledger that records every call.
• Governance. Role-based access across three tiers with vessel scoping; an audit trail of administrative actions; a defined export of all data at the end of the engagement.⁵

The three lanes

Inside the environment the work runs in three lanes that share the same model infrastructure but have different shapes.

Email. Messages arrive through the Microsoft 365 connection or the Outlook add-in. Each is analysed once into a fixed schema: category, priority, action, summary, and a vessel link that is only made when the match is unambiguous. Action items and reminders are created from the result, pinning rules let a manager override any field for a sender or subject, and a reply is drafted only when someone asks. Every step writes to the usage ledger.

Documents. Uploads land in the object store through a signed URL and always succeed, even when the model lane is busy. Pages are rendered and read by a vision-language model on the client's GPU into markdown that keeps tables, certificate numbers and dates as written. Text is chunked with overlap, each chunk is given back its context as a header (vessel, document, section), and retrieval combines lexical search with a reranker, scoped to the vessels the user may see. Answers cite the page, and the page opens.

The AI lane. One scheduler serves all of it with three priorities: interactive requests first, email second, documents in the background. A backlog of ten thousand pages never slows a superintendent waiting for an answer, and the same GPU that answers questions by day drains the document queue at night. The models are open-weight and pinned per deployment: a text model for email and the assistant, a vision-language model for pages, a reranker for retrieval, and a speech model for voice notes.

Controls you can check

A sovereignty claim is only worth what can be verified. These are the controls a client's IT team can inspect in their own deployment.

Two ways to run it

Sea-Squad managed: the environment is provisioned in the client's chosen region and operated by us, with the client administering users, roles and retention. Client hosted: the same images run on the client's own server and GPU, updated from a versioned registry with a one-command upgrade and rollback; Sea-Squad holds a support login that appears in the client's audit log as "SeaSquad support" and can be revoked.

A buyer's checklist

The questions below are the ones we would want answered before any AI system read our own operational mail. They apply to Sea-Squad as much as to anyone else.

A vendor who can answer all twelve in a paragraph each, with the contract clause or the architecture diagram to back it, has done the work. A vendor who answers most of them with "it depends on the plan" has told you where the data goes.

About Sea-Squad

Sea-Squad AI builds specialist AI agents for ship-management offices: Supt-GPT for the technical inbox, Marine-GPT for marine and QHSE questions, Captain-GPT on board, Crewmanager-GPT for crewing, with Legal-GPT and Claims-GPT in early access. The platform has run in production since May 2026 for ship managers and a naval shipbuilder, on single-tenant deployments with localised models.

To see it on your own fleet, book a working session at seasquad.ai/demo. Product documentation is at docs.seasquad.ai. Security questions go to security@seasquad.ai.

Karthik Ramesh is co-founder and CEO of Sea-Squad AI. Vivek Dosaya is co-founder and CTO.

References

1. Sea-Squad production telemetry, one client, eight mailboxes, measured August to September 2026: 1,240 messages per day (7 August) to about 2,700 threads per day (9 September). Figures anonymised; available to prospective clients under NDA. ↩
2. Sea-Squad load projection from measured attachment rates: 1.17 attachments per message of which 56% are signature images; document processing estimated at three to eight times the email token load at 30 users. ↩
3. IMO Resolution MSC.428(98), Maritime Cyber Risk Management in Safety Management Systems (effective 1 January 2021); IMO MSC-FAL.1/Circ.3/Rev.4, Guidelines on Maritime Cyber Risk Management, 28 May 2026. imo.org/en/ourwork/security/pages/cyber-security.aspx ↩
4. Sea-Squad product documentation: Certificates, PSC and RCA, Inspections, Reports. docs.seasquad.ai/docs ↩
5. Sea-Squad security and trust overview, and Roles and access. docs.seasquad.ai/docs/security ↩
6. OpenAI, Enterprise privacy, and "Offering Zero Data Retention for frontier models" (2026). openai.com/enterprise-privacy ↩
7. Digital Personal Data Protection Rules, 2025 (India), Rule 15, Transfer of personal data outside India. dpdpa.com/dpdparules/rule15.html ↩
8. Taylor Wessing, "GPAI obligations under the EU AI Act: enforcement has started 2 August 2026". taylorwessing.com ↩
9. For a current survey of permissively licensed open-weight models and their benchmark positions relative to proprietary models, see Hugging Face, "Best open-source LLM models in 2026". huggingface.co/blog/daya-shankar/open-source-llms ↩
10. Sea-Squad incident records, August to September 2026: four gateway credit outages in 30 days including 19 to 21 August; approximately 20,000 failed calls between 27 and 30 August with no alert. ↩
11. Sea-Squad incident record, 9 September 2026: hosted model substitution for email analysis; 1,408 analyses degraded over four hours with zero failed calls; corrected the same day. ↩
12. Sea-Squad usage ledger design: one record per AI call with provider, model, task, tokens, cost, latency and outcome; 180-day retention; daily spend alerts at defined thresholds; no third-party observability service. ↩
13. Sea-Squad production ledger, 30 days to 2 September 2026: email analysis 137,000 calls, 360M input and 24M output tokens. ↩
14. Frontier API list prices, September 2026, standard tier: OpenAI GPT-5.6 Terra $2/$12 per million tokens; Anthropic Claude Sonnet 5 $2/$10, Claude Opus 5 $5/$25. Cached input billed at about 10% of the input rate. benchlm.ai/openai/api-pricing, benchlm.ai/anthropic/api-pricing. GPU: RunPod Secure Cloud A40 $0.44 per hour. gpuperhour.com/providers/runpod ↩
15. Sea-Squad evaluation, 15 August 2026: Qwen3.8-27B (FP8) on one A40. Email classification 9/10 agreement plus vessel codes missed by the baseline; chat 18 tokens per second single stream; email-class throughput 26 requests per minute at concurrency 16 with zero errors; OCR 23.8 seconds per page (not viable). Mixture-of-experts session on a 96 GB card: about 1,900 pages per hour. ↩
16. Sea-Squad, "Contextual enrichment: making 300,000 document chunks searchable", engineering note, August 2026: 296,424 of 307,993 chunks enriched (96.2%); about $3 to $4 of GPU time for roughly 160,000 chunks in one overnight session; hosted estimate $75 to $150 for the full corpus. ↩
17. Sea-Squad, "Running open-weight vision-language models for maritime document OCR", engineering note, August 2026: 19,117 pages across 332 documents in one overnight session; reasoning mode off gave roughly six times the throughput; quality gate against verified transcriptions before any traffic moved. ↩