Data Governance: Haftung bei fehlerhaften CII-DatenData Governance and Liability for Faulty CII Data

Eine CII- oder MRV-Meldung beruht auf einer langen Kette von Datenpunkten, die an Bord beginnt und erst am Ende in einer behördlichen Übermittlung mündet. Zwischen dem Sensor, der einen Kraftstoffdurchfluss misst, und der Zahl, die am Jahresende gemeldet wird, liegen mehrere Übergabepunkte – jeder davon eine mögliche Fehlerquelle. Wenn am Ende dieser Kette eine falsche Zahl steht, stellt sich unweigerlich die Frage, wer dafür einsteht: die Crew, die den Wert eingegeben hat, der technische Manager, der die Daten verantwortet, oder der Softwareanbieter, dessen System die Meldung erzeugt hat.

Diese Frage lässt sich nicht pauschal beantworten, weil sie von der vertraglichen Ausgestaltung, der Art des Fehlers und dem Zeitpunkt seiner Entdeckung abhängt. Dieser Beitrag ordnet, wo in der Datenkette Verantwortung typischerweise liegt, wie sich das vertraglich absichern lässt, welche Folgen eine fehlerhafte Meldung nach sich zieht, und wie sich interne Kontrollen aufbauen lassen, die Fehler idealerweise abfangen, bevor sie überhaupt gemeldet werden.

A CII or MRV submission rests on a long chain of data points that starts on board and only ends with a filing to the authority. Between the sensor measuring fuel flow and the figure reported at year-end sit several handover points, each one a possible source of error. When the wrong number comes out at the end of that chain, the question that follows is unavoidable: who answers for it — the crew member who entered the reading, the technical manager responsible for the data, or the software provider whose system generated the submission?

There is no blanket answer, because it depends on how the contracts are written, what kind of error occurred, and when it was caught. This article sets out where responsibility typically sits along the data chain, how that can be secured contractually, what consequences a faulty submission carries, and how internal controls can be built to catch errors ideally before they are ever reported.

Am Anfang der Datenkette stehen Bordsensoren und manuelle Erfassungen: Durchflussmesser für Kraftstoff, Tankpeilungen, Logbucheinträge zu Distanz und Geschwindigkeit. Schon auf dieser Ebene entstehen Fehlerquellen, etwa durch einen nicht kalibrierten Sensor, eine falsch abgelesene Peilung oder eine Rundung, die sich über viele Einträge zu einem relevanten Unterschied aufsummiert.

Von Bord gelangen diese Werte über ein Flottenmanagementsystem oder eine ähnliche Software an Land, wo sie aggregiert, geprüft und in das für die Meldung erforderliche Format gebracht werden. Jeder dieser Schritte – Erfassung, Übertragung, Aggregation, Formatierung – kann einen Fehler einführen oder einen bereits vorhandenen Fehler unbemerkt weitertragen. Wer die Verantwortung für eine fehlerhafte Endmeldung klären will, muss deshalb zuerst wissen, an welcher Stelle dieser Kette der Fehler tatsächlich entstanden ist.

The data chain starts with onboard sensors and manual entries: fuel flow meters, tank soundings, logbook entries for distance and speed. Errors can creep in at this level alone — an uncalibrated sensor, a misread sounding, or a rounding practice that adds up to something material across many entries.

From the ship, these values move ashore through a fleet management system or similar software, where they are aggregated, checked and put into the format the submission requires. Every one of these steps — capture, transmission, aggregation, formatting — can introduce an error or carry an existing one forward unnoticed. Anyone trying to establish responsibility for a faulty final submission first has to know at which point in this chain the error actually occurred.

Der technische Manager trägt in der Regel die operative Verantwortung für die Datenerfassung an Bord und für die Qualitätssicherung vor der Meldung, auch wenn er nicht zwingend Eigentümer des Schiffs ist. Der Reeder bleibt regelmäßig gegenüber der Behörde die meldepflichtige Partei, unabhängig davon, wer die operative Datenpflege im Alltag übernimmt.

Der Softwareanbieter, dessen System die Rohdaten verarbeitet und die Meldeformate erzeugt, trägt eine dritte Art von Verantwortung: die für die korrekte technische Umsetzung der Berechnung. Ein Fehler in der Berechnungslogik der Software – etwa eine falsche Umrechnung zwischen Kraftstoffarten – kann bei sonst korrekten Eingabedaten trotzdem zu einer falschen Meldung führen, ohne dass Crew oder technischer Manager etwas falsch gemacht hätten.

The technical manager usually carries operational responsibility for onboard data capture and for quality assurance before submission, even without being the ship's owner. The owner generally remains the party accountable to the authority, regardless of who handles the day-to-day data work.

The software provider, whose system processes the raw data and produces the reporting formats, carries a third kind of responsibility: for the correctness of the calculation itself. A fault in the software's calculation logic — a wrong conversion between fuel types, for instance — can produce a faulty submission even where the input data was entirely correct, with neither the crew nor the technical manager having done anything wrong.

Verträge mit Anbietern von Flottenmanagement- und Reporting-Software regeln in der Praxis oft ausführlich Funktionsumfang und Verfügbarkeit, aber deutlich knapper die vertragliche Risikoverteilung bei einem softwareseitigen Berechnungsfehler. Eine Klausel, die Haftung für Berechnungsfehler pauschal ausschließt, verlagert das gesamte Risiko zurück auf den Reeder, selbst wenn die Ursache nachweislich in der Software liegt.

Sinnvoller ist eine Vertragsgestaltung, die zwischen Dateneingabefehlern auf Kundenseite und Berechnungs- oder Verarbeitungsfehlern auf Anbieterseite unterscheidet und für beide Fälle getrennte Verantwortlichkeiten definiert. Dazu gehört auch eine Regelung, wie ein erkannter Softwarefehler dokumentiert und wie eine daraus resultierende Korrekturmeldung abgewickelt wird, statt diese Fragen erst im Streitfall zu klären.

Contracts with fleet management and reporting software providers often go into detail on functionality and uptime, but say far less about contractual risk allocation for a software-side calculation error. A clause that blanket-excludes liability for calculation errors shifts the entire risk back onto the owner, even where the cause demonstrably sits inside the software.

A better approach distinguishes between data entry errors on the customer side and calculation or processing errors on the provider side, defining separate responsibilities for each. That should also cover how a confirmed software error gets documented and how any resulting correction submission is handled, rather than leaving those questions to be settled only once a dispute arises.

Eine fehlerhafte CII- oder MRV-Meldung kann über die reine Korrektur hinaus Folgen haben: für die Einstufung eines Schiffs, für das Vertrauen von Klassifikationsgesellschaft und Behörde in künftige Meldungen desselben Betreibers, und im Chartergeschäft für die Wahrnehmung durch Charterer, die zunehmend selbst auf belastbare Emissionsdaten angewiesen sind.

Reputationsschäden entstehen dabei oft weniger durch den einzelnen Fehler als durch dessen Umgang: Ein Betreiber, der einen Fehler zügig erkennt, dokumentiert und korrigiert, wird anders wahrgenommen als einer, bei dem eine Unstimmigkeit erst durch eine externe Prüfung auffällt. Die Reaktionsfähigkeit auf einen erkannten Fehler ist deshalb selbst Teil der Data-Governance-Bewertung.

A faulty CII or MRV submission can carry consequences well beyond a simple correction: for a ship's rating, for how much confidence class and the authority place in the operator's future submissions, and — in the chartering market — for how the operator is perceived by charterers who increasingly rely on solid emissions data themselves.

Reputational damage often comes less from the error itself than from how it is handled. An operator who catches, documents and fixes an error quickly is seen differently from one whose discrepancy only surfaces through an external check. How an operator responds to a caught error is therefore itself part of how its data governance gets judged.

Fällt ein Fehler erst nach der Meldung auf, braucht es ein klar definiertes Korrekturverfahren, statt einer Ad-hoc-Reaktion. Dazu gehört, den Fehler an der Quelle zu identifizieren, seine Auswirkung auf die gemeldete Zahl zu quantifizieren, und die Korrektur über den dafür vorgesehenen Meldeweg einzureichen, statt sie informell nachzureichen.

Wichtig ist außerdem, den Fehler intern zu dokumentieren, auch wenn die Korrektur selbst unkompliziert verläuft. Diese Dokumentation wird relevant, sobald sich ein ähnlicher Fehler wiederholt oder eine Behörde nach der Systematik hinter einer Korrektur fragt. Ein Betreiber ohne nachvollziehbare Fehlerhistorie hat es in diesem Fall deutlich schwerer, eine einmalige Panne von einem strukturellen Problem abzugrenzen.

When an error surfaces after submission, what is needed is a clearly defined correction procedure rather than an ad-hoc reaction. That means identifying where the error originated, quantifying its effect on the reported figure, and filing the correction through the designated channel rather than patching it up informally.

It also matters to document the error internally, even when the correction itself is straightforward. That documentation becomes relevant the moment a similar error recurs, or an authority asks about the pattern behind a correction. An operator without a traceable error history has a much harder time showing that a one-off slip is not, in fact, a structural problem.

Die wirksamste Absicherung gegen fehlerhafte Meldungen liegt vor der Meldung selbst, in internen Kontrollpunkten, die Auffälligkeiten erkennen, bevor eine Zahl das Unternehmen verlässt. Dazu gehören einfache Plausibilitätsprüfungen wie der Vergleich gemeldeter Werte mit dem Vorjahr oder mit Schwesterschiffen, sowie automatisierte Warnungen bei Werten außerhalb eines erwarteten Bereichs.

Ebenso wirksam ist ein zweiter, unabhängiger Blick auf die Daten vor der Übermittlung – etwa durch eine Person, die nicht selbst an der ursprünglichen Erfassung beteiligt war. Dieser zusätzliche Schritt kostet Zeit, reduziert aber genau die Fehlerart, die am schwersten zu erklären ist: eine plausibel aussehende, aber falsche Zahl, die ohne zweite Prüfung unbemerkt durchläuft.

The most effective safeguard against faulty submissions sits before the submission itself, in internal control points that flag anomalies before a figure leaves the company. That includes basic plausibility checks — comparing reported values against the prior year or against sister ships — and automated flags for values outside an expected range.

Just as effective is a second, independent look at the data before it goes out, ideally from someone not involved in the original data capture. That extra step costs time but reduces exactly the error type hardest to explain later: a figure that looks plausible but is wrong, and would otherwise pass through unnoticed without a second check.

Behörden und Klassifikationsgesellschaften unterscheiden grundsätzlich zwischen einem nachvollziehbaren technischen Fehler und einer vorsätzlichen Falschmeldung, auch wenn die Grenze im Einzelfall Auslegung erfordert. Ein dokumentierter Fehler mit klarer Quelle, zügiger Meldung und nachvollziehbarer Korrektur wird typischerweise anders behandelt als eine Abweichung, die erst durch externe Prüfung auffällt und für die keine plausible technische Erklärung vorliegt.

Für Betreiber folgt daraus ein klarer Grundsatz: Eine funktionierende Data Governance schützt nicht davor, dass überhaupt einmal ein Fehler passiert – Fehler in einer so langen Datenkette lassen sich nie vollständig ausschließen. Sie schützt davor, dass ein technischer Fehler wie eine vorsätzliche Falschmeldung aussieht, weil Dokumentation, Nachvollziehbarkeit und Reaktionsgeschwindigkeit fehlen.

Authorities and class societies draw a basic distinction between a traceable technical error and a deliberate misstatement, even though the line requires interpretation in individual cases. A documented error with a clear source, prompt reporting and a traceable correction is generally treated differently from a discrepancy that only surfaces through external review and has no plausible technical explanation.

The practical takeaway for operators is straightforward: working data governance does not prevent an error from ever happening — in a data chain this long, errors can never be fully ruled out. What it prevents is a technical error looking like a deliberate misstatement, because documentation, traceability and response speed were missing when it mattered.