Maritime Document AI: Wie wir ein Dokumenten-KI-System in 4 Wochen gebaut haben

Reedereien verarbeiten jedes Jahr tausende Compliance-Dokumente — Inspektionszertifikate, Hafenstaatkontrollberichte, ISM-Audits, Klassifikationsgesellschafts-Surveys und Behördenunterlagen aus verschiedenen Ländern und Sprachen. Ein einziger übersehener Absatz oder ein abgelaufenes Zertifikat kann ein Schiff festsetzen, Bußgelder auslösen oder die Hafeneinfahrt verhindern. Wir haben ein Document-AI-System gebaut, das diese Dokumente innerhalb von Minuten liest, analysiert und abgleicht — statt in Stunden. So haben wir es gemacht, was funktioniert hat und was wir dabei gelernt haben.

Das Problem: Papierchaos

Unser Auftraggeber, ein mittelständischer europäischer Reeder mit über 30 Schiffen, verbrachte durchschnittlich zwei Stunden pro Dokument mit manuellen Compliance-Prüfungen. Sein Operations-Team erhielt Inspektionsberichte, Klassifikations-Surveys und regulatorische Updates im PDF-Format — oft gescannt, manchmal handschriftlich, häufig in gemischten Sprachen (Englisch, Griechisch, Deutsch und gelegentlich Norwegisch).

Der Prüfprozess war mühsam: Ein Operations-Mitarbeiter öffnete das PDF, prüfte jeden Befund manuell gegen die geltenden Vorschriften, glich ihn mit früheren Inspektionsberichten ab, um wiederkehrende Mängel zu erkennen, und erstellte eine Zusammenfassung für den Compliance-Manager. Das passierte dutzende Male pro Woche quer durch die gesamte Flotte.

Drei konkrete Schmerzpunkte waren Auslöser des Projekts:

• Verpasste Fristen: Zertifikatsverlängerungen und Fristen für Korrekturmaßnahmen wurden in Spreadsheets gepflegt. Da ging einiges unter. Zweimal im Vorjahr wurde ein Schiff im Hafen festgehalten, weil Dokumente abgelaufen waren.
• Uneinheitliche Prüfungen: Verschiedene Mitarbeiter meldeten unterschiedliche Dinge. Es gab keine standardisierte Checkliste und kein Bewertungssystem — die Qualität hing komplett davon ab, wer gerade prüfte.
• Kein historischer Kontext: Bei der Prüfung eines neuen Inspektionsberichts gab es keine schnelle Möglichkeit festzustellen, ob ein Mangel wiederkehrend oder neu war. Dieser Kontext ist entscheidend für die Priorisierung.

Was wir gebaut haben: Vier Analysemodi

Wir haben das System um vier verschiedene Analysemodi herum konzipiert, die jeweils einen anderen Teil des Compliance-Workflows abdecken. Der Nutzer lädt ein Dokument (oder mehrere) hoch, wählt den Analysemodus und erhält innerhalb weniger Minuten strukturierte Ergebnisse.

Modus 1: Compliance-Prüfung

Der Kernmodus. Sie laden einen Inspektionsbericht oder Survey hoch, und das System prüft jeden Befund gegen das zutreffende Regelwerk — SOLAS, MARPOL, MLC, ISM Code und Klassifikationsvorschriften. Es markiert Verstöße, kategorisiert sie nach Schweregrad (kritisch, erheblich, geringfügig, Beobachtung) und erstellt eine priorisierte Maßnahmenliste mit Fristen auf Basis der vorgeschriebenen Reaktionszeiten.

Hier liefert das System den größten Mehrwert. Aus einer zweistündigen manuellen Prüfung werden drei Minuten automatisierte Analyse mit höherer Konsistenz. Die KI wird nicht freitagnachmittags um 16 Uhr müde und überspringt keine Abschnitte, weil sie routinemäßig aussehen.

Modus 2: Risikobewertung

Dieser Modus geht über die Einzeldokument-Compliance hinaus. Er aggregiert Befunde aus mehreren Dokumenten desselben Schiffs und berechnet einen Risiko-Score auf Basis von Mängelhäufigkeit, Schweregradtrends und der bisherigen Zeit bis zur Behebung. Schiffe mit wiederkehrenden Maschinenraummängeln oder einem Muster verspäteter Korrekturmaßnahmen werden für die Geschäftsführung markiert, bevor es zu einer Festhaltung kommt.

Modus 3: Operative Erkenntnisse

Laden Sie ein beliebiges operatives Dokument hoch — Crew-Berichte, Wartungsprotokolle, Reiseberichte — und das System extrahiert verwertbare Erkenntnisse. Es erkennt Muster, die Menschen übersehen: Zusammenhänge zwischen Routenentscheidungen bei Wetter und Geräteausfällen, Ermüdungsindikatoren der Besatzung in Schichtprotokollen und Treibstoffverbrauchsanomalien im Zusammenhang mit dem Rumpfzustand. Stellen Sie es sich als einen Analysten vor, der jedes Dokument liest und nie ein Detail vergisst.

Modus 4: Dokumentenvergleich

Laden Sie zwei Versionen eines Dokuments hoch — einen alten und einen neuen Inspektionsbericht, zwei Versionen eines Sicherheitsmanagement-Handbuchs oder eine Vorschriftenaktualisierung neben der vorherigen Version — und das System erstellt einen strukturierten Vergleich. Es zeigt an, was sich geändert hat, was hinzugefügt wurde, was entfernt wurde und welche Auswirkungen das hat. Besonders nützlich, wenn Klassifikationsgesellschaften ihre Regeln aktualisieren oder wenn Zustände vor und nach einem Survey verglichen werden sollen.

Architektur: So funktioniert es

Das System läuft vollständig auf der eigenen Infrastruktur des Kunden. Kein einziges Dokument verlässt jemals seine Server. Das war eine harte Anforderung — Reeder verarbeiten wirtschaftlich sensible Ladungsmanifeste, persönliche Daten der Besatzung und geschützte Betriebsinformationen. Cloud-AI-APIs kamen nicht in Frage.

Der Datenfluss ist geradlinig: Der Dokumenten-Upload löst die Parsing-Pipeline aus, die normalisierten Textabschnitte an das LLM mit modusspezifischen Prompts und relevantem regulatorischem Kontext übergibt. Das LLM produziert strukturierte JSON-Ausgabe, die die Ergebnis-Engine für die Anzeige aufbereitet und für historische Analysen speichert. Durchschnittliche End-to-End-Verarbeitungszeit liegt unter drei Minuten für einen standardmäßigen 20-seitigen Inspektionsbericht.

Die schwierigen Teile: Was das Projekt herausfordernd machte

Herausforderung 1: Maritime Fachsprache

Maritimes Englisch ist praktisch ein eigener Dialekt. Begriffe wie "scheduled drydocking", "class notation", "condition of class" und "port state control detention" haben sehr spezifische regulatorische Bedeutungen, die von der alltagssprachlichen Interpretation abweichen. Allgemeine Sprachmodelle interpretieren diese Begriffe häufig falsch. Eine "condition of class" ist keine vage Beschreibung — es ist eine formale Anforderung einer Klassifikationsgesellschaft, die innerhalb eines festgelegten Zeitrahmens erfüllt werden muss.

Wir haben das durch Prompt-Engineering und ein maritimes Fachwörterbuch gelöst, das als Kontext eingespeist wird. Für die kritischsten Begriffe haben wir explizite Parsing-Regeln gebaut, die sie erkennen und taggen, bevor das LLM den Text verarbeitet. Dieser hybride Ansatz — Regeln für sicherheitskritische Terminologie, LLM für natürliches Sprachverständnis — lieferte die beste Genauigkeit.

Herausforderung 2: Mehrsprachige Dokumente

Inspektionsberichte aus griechischen Häfen kommen auf Griechisch. Deutsche Klassifikationsgesellschaftsberichte mischen Deutsch und Englisch. Norwegische Seebehördenmitteilungen verwenden Norwegisch für narrative Abschnitte und Englisch für technische Befunde. Das System musste all das verarbeiten, ohne dass der Nutzer die Sprache vorher angeben muss.

Die Lösung war ein Spracherkennungsschritt in der Parsing-Pipeline. Das System identifiziert die Hauptsprache jedes Dokumentenabschnitts und leitet ihn durch sprachspezifische Verarbeitung. Für die Analyseausgabe wird alles auf Englisch normalisiert (die Arbeitssprache des Operations-Teams). Das funktioniert gut für europäische Sprachen. Bei asiatischen Sprachen steht der Test noch aus — das ist eine zukünftige Erweiterung.

Herausforderung 3: PDF-Parsing-Qualität

Das war die größte Fehlerquelle überhaupt. Maritime Dokumente kommen in jedem vorstellbaren Format. Manche sind gut strukturierte digitale PDFs mit sauberem Textlayer. Andere sind gescannte Kopien von gefaxten Dokumenten (ja, Fax lebt in der Schifffahrt weiter). Manche haben Stempel, Nasssignaturen und handschriftliche Anmerkungen über gedrucktem Text.

Wir haben eine dreistufige Parsing-Strategie entwickelt:

• Stufe 1 — Saubere digitale PDFs: Direkte Textextraktion mit Standard-PDF-Bibliotheken. Schnell, genau, deckt 60 % der Dokumente ab.
• Stufe 2 — Gescannt, aber lesbar: OCR-Verarbeitung mit Nachkorrektur-Heuristiken für gängige maritime Fachbegriffe. Deckt 30 % der Dokumente mit akzeptabler Genauigkeit ab.
• Stufe 3 — Schlechte Scan-Qualität: Erweiterte OCR mit Bildvorverarbeitung (Kontrastanpassung, Entzerrung, Rauschentfernung) gefolgt von einem Konfidenz-Scoring-Schritt. Fällt die Konfidenz unter einen Schwellenwert, markiert das System das Dokument zur manuellen Prüfung, anstatt unzuverlässige Analysen zu produzieren. Etwa 10 % der Dokumente landen in dieser Stufe.

Ehrlich mit den Grenzen der OCR-Qualität umzugehen, war eine bewusste Designentscheidung. Ein Analysesystem, das selbstbewusst falsche Ergebnisse liefert, ist schlimmer als eines, das sagt: "Ich kann dieses Dokument nicht zuverlässig lesen, bitte manuell prüfen."

Ergebnisse: Was wir gemessen haben

Nach vier Wochen Entwicklung und zwei Wochen Parallelbetrieb (KI neben manueller Prüfung zur Genauigkeitsvalidierung) haben wir Folgendes gemessen:

Zeitplan: Vier Wochen von Anfang bis Ende

Wir hatten uns auf einen vierwöchigen Lieferzeitraum festgelegt. So verteilte sich die Arbeit:

• Woche 1 — Discovery und Dokumentenanalyse: Wir erhielten Beispieldokumente vom Kunden (über 50 echte Inspektionsberichte und Surveys). Analyse der Dokumenttypen, Formate und Sprachverteilung. Definition der vier Analysemodi basierend auf dem tatsächlichen Workflow des Operations-Teams. Aufbau der Entwicklungsinfrastruktur.
• Woche 2 — Parsing-Pipeline und LLM-Integration: Aufbau der Dokumenten-Parsing-Pipeline mit der dreistufigen Strategie. Konfiguration von Ollama mit dem ausgewählten Modell. Entwicklung und Iteration der Prompts für jeden Analysemodus. Erstellung des maritimen Fachwörterbuchs und der regulatorischen Wissensdatenbank.
• Woche 3 — Frontend und Ergebnis-Engine: Aufbau des Next.js-Frontends mit Upload, Modusauswahl und Ergebnisdarstellung. Entwicklung der Nachverarbeitungsschicht, die LLM-Output in konsistente Formate bringt. End-to-End-Verbindung aller Komponenten. Erste Gesamtsystemtests mit echten Dokumenten.
• Woche 4 — Tests, Feinschliff und Deployment: System gegen über 200 Dokumente aus dem Archiv des Kunden getestet. Sonderfälle in Parsing und Analyse behoben. Deployment auf die Docker-Infrastruktur des Kunden. Schulung des Operations-Teams (zwei halbtägige Sessions). Systemdokumentation für das IT-Team.

Vier Wochen sind schnell für ein Produktivsystem, aber machbar, wenn man den Umfang konsequent begrenzt. Wir haben während der Entwicklung mehrere Feature-Wünsche abgelehnt — E-Mail-Integration, automatisierte Zertifikatsverfolgung und flottenweite Dashboards — und sie für eine Folgephase eingeplant. Erst das Kernprodukt liefern, den Mehrwert beweisen, dann erweitern.

Warum Self-Hosting entscheidend war

Jedes Dokument, das dieses System verarbeitet, enthält wirtschaftlich sensible Informationen — Ladungsdetails, Schiffszustände, Besatzungsdaten und operationelle Muster. Das an eine Cloud-API zu senden, war für den Kunden inakzeptabel, und offen gesagt teilen wir diese Einschätzung für diesen Anwendungsfall.

Ollama lokal auf einem dedizierten Server zu betreiben bedeutet: Keine Daten verlassen das Netzwerk, keine Kosten pro Anfrage, keine Abhängigkeit von einem Anbieter und keine Abhängigkeit von externer Dienstverfügbarkeit. Der Kompromiss ist, dass lokale Modelle nicht so leistungsfähig sind wie die größten Cloud-Modelle — aber für diese strukturierte, domänenspezifische Aufgabe reicht die Genauigkeit mehr als aus. Maritime Compliance-Prüfung ist kein kreatives Schreiben. Es ist Musterabgleich gegen bekannte Regeln, und das können kleinere, gut promptgesteuerte Modelle sehr gut.

Was wir gelernt haben

• Dokumentqualität ist der Flaschenhals, nicht KI-Qualität. Das LLM funktionierte gut, wenn es sauberen Text erhielt. Die meisten Fehler ließen sich auf schlechte OCR bei degradierten Scans zurückführen. Investieren Sie in Ihre Parsing-Pipeline, bevor Sie Ihre Prompts optimieren.
• Domänenspezifische Glossare sind unverzichtbar. Allgemeine Sprachmodelle interpretieren Fachterminologie falsch. Ein kuratiertes Fachwörterbuch als Kontext einzuspeisen ist eine einfache Maßnahme mit großer Wirkung.
• Von Anfang an für Human-in-the-Loop konzipieren. Wir haben das System nie als Ersatz für menschliche Prüfer positioniert. Es ist ein Werkzeug, das sie schneller und konsistenter macht. Diese Darstellung sorgte sofort für Akzeptanz beim Operations-Team, das sich gegen eine "KI ersetzt euch"-Botschaft gewehrt hätte.
• Strukturierte Ausgabe zählt mehr als reine Genauigkeit. Eine 90 % genaue Analyse in einer sauberen, sortierbaren Tabelle ist nützlicher als 95 % Genauigkeit in einer Textwand. Investieren Sie in Ihre Ausgabeformatierung.
• Vier Wochen sind ein Feature, keine Einschränkung. Enge Zeitrahmen erzwingen Disziplin beim Umfang. Der Kunde bekam schnell ein funktionierendes System, validierte den Ansatz und hat jetzt eine Roadmap zur Erweiterung. Sechs Monate auf ein "vollständiges" System zu warten, hätte sechs weitere Monate manuelle Prüfungen bedeutet.

Wie es weitergeht

Das System ist im Einsatz und verarbeitet täglich Dokumente. Die nächste Phase umfasst automatisierte Zertifikatsablaufverfolgung (Extraktion von Terminen aus analysierten Dokumenten in ein Kalendersystem), flottenweite Risiko-Dashboards mit aggregierten Schiffsbewertungen und Integration in die bestehende Flottenmanagement-Software des Kunden per API.

Wenn Ihr Unternehmen große Mengen spezialisierter Dokumente verarbeitet — ob in der Schifffahrt, im Rechtswesen, im Bau, in der Versicherung oder einer anderen regulierten Branche — ist dieselbe Architektur anwendbar. Ein domänenspezifisches Document-AI-System, selbstgehostet für Datenschutz, mit strukturierter Ausgabe und menschlicher Kontrolle. Genau das bauen wir.

Kontaktieren Sie uns, um zu besprechen, ob ein Document-AI-System für Ihren Anwendungsfall sinnvoll ist. Wir sagen Ihnen ehrlich, ob es passt — und ob nicht.