The verification tax is the time and attention maritime professionals spend checking AI-generated work before anyone acts on it. In 2026 research by Thetius and Marcura, 55% of maritime professionals spend an hour or more a week checking or correcting AI outputs, rising to more than five hours for one in five respondents.
Some of that checking protects decisions and should stay. The rest comes from uncertainty, and it falls as AI proves itself: built on data people have verified, tested task by task, and corrected by the people who use it.
Key facts (Thetius and Marcura, Earning Trust: AI in Maritime, 2026)
55% spend an hour or more a week checking or correcting AI outputs
57% place their trust in AI outputs at the midpoint of a five-point scale
26% find errors often or almost always when they check
47% would check much less, or stop, once an output had proved reliable
8% describe their organisation as mature and governed in its use of AI
What is the verification tax?
The verification tax is the cost of checking AI's work: the review itself, plus moving between the output and the source documents, finding the evidence and correcting what is wrong. We first introduced the concept of the verification tax in Earning Trust: AI in Maritime a study we co-produced with Thetius.
Marcura has used AI to read maritime documents for years, and every customer asks the same two questions first: how accurate is it, and can I rely on it inside my own process? Until those questions are answered, people check everything, and that checking is the tax. The report splits it in two: checking a decision warrants, and checking that comes from uncertainty.
Why do people check AI's work, and which checking should stay?
In my experience people check AI for two reasons. Only one should fade.
Warranted checking protects a decision. Where an error would change a contractual position, a sanctions judgement or a port call, close review is right. Our research found 70% of maritime professionals always check an AI recommendation before acting on an important business decision, and 80% want a named person accountable for every commercial decision. That layer stays.
Residual checking comes from uncertainty: limited trust, or no view of how the system reached its answer. Asked how their checking would change once an output had proved reliable, 47% said they would check much less or stop. That is the part of the tax that can come down, and what sets it is trust in the output, not the size of the decision.
Warranted checking | Residual checking | |
|---|---|---|
Driver | The consequences of an error | Uncertainty about whether the output is correct |
Example | A charter party clause; a sanctions screening result | Re-checking a port restriction the system has had right many times |
What to do | Keep it, formalise it, name who signs off | Bring it down with verified data; visible testing and corrections the system learns from |
What makes the checking come down?
Trust grows when people can see what the system got right and how it got there. Three things produce that, and none of them is AI for the sake of AI.
Data that people have verified. Better data means data you can trace and trust in context, and most maritime AI lacks it. An interviewee in last year's research put it plainly: "AI with poor quality data is just smarter and faster stupidity" (Beyond the Hype, Thetius and Marcura, 2025). Marcura's AI is not a general-purpose tool adapted for maritime use. It is trained specifically on maritime language, contract structures and industry processes, like a student learning a specialised field, and the data used to train each client's model is kept in an instance specific to that client.
Models tested on the customer's own work, and kept under test. A single accuracy figure says little: a system can be very good at extracting dates and much less reliable at interpreting contractual obligations, so judge performance task by task. When customers doubted our accuracy, we did not argue. We tested with them. At Marcura, we build evaluation metrics based on real and factual data that we receive from the end user for that specific use case, and then we continue to run these tests to show how accuracy improves over time.
Corrections that teach the system, and a person on the decision. When a reviewer fixes an answer, the correction should feed back into the evaluation rather than disappear with the edit. Every output should point back to its source and say when it is uncertain: an answer you cannot explain is an answer you cannot defend. I never tell a customer to aim for full automation. What I ask of every model we ship is that it knows the context it is working in, keeps a person on the decision, and can explain its answer. One caution, which I gave the report's authors: don't replace muscle memory with AI. The person checking still needs to know what a good answer looks like.
What earns trust | In practice | Ask any vendor |
|---|---|---|
Verified, traceable data | The system shows which document and line an answer came from | Where does this answer come from and can I see it? |
Accuracy you can see, per task | Results tested against your own cases, shown in a dashboard | How accurate is it at this task and how do you know? |
Corrections that inform future outputs | Override and correction rates fall because the system learns from them | What happens to my corrections? |
A human in the loop | Named ownership; escalation when information is missing | Who signs off and when does it escalate? |
How do you measure the verification tax?
Most cannot yet. "We don't have benchmarking data," Rajesh Gopinathan, Head of Business Transformation at Seaspan, told the report's researchers. The measure has to cover the whole human-AI process: a five-minute check is excessive for an internal summary and inadequate for a contractual recommendation, so review time alone says little.
What to measure | Why it matters |
|---|---|
Review time per output, escalation delays, and the cost of locating evidence or reporting a downstream error. | The visible and hidden tax |
Proportion of outputs amended, and overrides with reasons logged | A high rate points to the data, the retrieval or the use case |
Whether the complete workflow beats the process it replaced | The test that settles whether the tax was worth it. |
What does it look like in practice?
Charter party review is an example of warranted verification that can be made simpler through AI. A charter party sets a company's contractual position, so the review stays whatever the tool. What changes is where the hours goes. The clauses that need a decision sit among pages of standard wording and carried-over terms.
CP Optimiser reads voyage and time charters alike, extracts the clauses, scores each for risk and flags ambiguous, missing or non-standard wording, so the reviewer spends the hours on the flagged clauses and keeps the judgement.
One flag from a dry bulk voyage charter shows the pattern. The demurrage clause required "all supporting documents" within 90 days but never defined them. One missing statement of facts could time-bar the whole demurrage entitlement. The fix is to tighten the definition before fixing. The reviewer makes the call; the system makes sure the clause is in front of them.
What should a company do next?
The report's five priorities apply whatever tools you use:
Start with a specific workflow or problem, rather than looking for somewhere to deploy AI.
Measure the complete human-AI process against the process it replaced.
Match verification to the consequences of an error.
Turn verification into a learning process.
Establish clear ownership and governance for every AI-assisted decision.