Legal DocAI

Dokumentenautomatisierung für Kanzleien

Gebaut von Rogue AI · Dokumenten-KI für Kanzleien · Selbst gehostet · Lokales Lab

Als selbst gehostetes Lab-Projekt in einem konzentrierten Build-Sprint entstanden und in Iterationen verfeinert.

Legal DocAI — Dokumentenautomatisierung für Kanzleien

Das Problem

Kanzleien bearbeiten Dokumente, die nicht in eine fremde Cloud hochgeladen werden dürfen — Verträge, Handelsregistereintragungen, Eigentumsurkunden, Compliance-Unterlagen — und doch ist das Durcharbeiten nach Schlüsselklauseln und Risiken langsam und manuell. Die meisten KI-Dokumentenwerkzeuge lösen das Leseproblem, indem sie den Text an eine gehostete API schicken, also genau das, was eine Kanzlei mit vertraulichem Material nicht tun darf. Die Aufgabe bestand darin, nützliche Klauselextraktion und Risikomarkierung zu erreichen, ohne dass vertraulicher Inhalt jemals die Maschine verlässt, auf der er verarbeitet wurde.

Was ich gebaut habe

Eine Next.js-Anwendung, in der ein Nutzer Verträge, Handelsregistereintragungen, Eigentumsurkunden oder Compliance-Dokumente hochlädt und extrahierte Schlüsselklauseln, markierte Risiken und exportierbare strukturierte Daten zurückbekommt. Jeder Inferenzaufruf geht an ein lokales Ollama-Modell auf demselben Host — keine externe API, kein Dokumenteninhalt, der die Maschine verlässt. Die App hält die Arbeit im Arbeitsspeicher mit kurzer Session-TTL, statt sie in einer Datenbank zu speichern, es gibt also keinen langlebigen Speicher vertraulichen Materials. Sie läuft als gehärteter Docker-Container, der statt zu Ollama auch zu einer lokalen CLI-Bridge routen kann, doch die Voreinstellung bleibt vollständig lokal.

Architektur

Inferenz ausschließlich lokal über Ollama

Alle Modellaufrufe gehen an eine Ollama-Instanz, die über das gemeinsame Lab-Netzwerk erreichbar ist, niemals an eine gehostete API. Vertraulicher Dokumententext wird an einen Prozess auf demselben Host geschickt und nirgendwo sonst — die Rahmenbedingung, die den gesamten selbst gehosteten Ansatz rechtfertigt.

Keine Datenbank, Sessions im Arbeitsspeicher

Es gibt keinen persistenten Speicher. Hochgeladene Dokumente und Extraktionsergebnisse leben im Arbeitsspeicher unter einer kurzen Session-TTL und sind nach deren Ablauf verschwunden, was Fragen zu Daten im Ruhezustand und zur Aufbewahrung beseitigt — auf Kosten jeglicher Persistenz.

Vision-fähige Extraktion für bildlastige Seiten

Gescannte Eintragungen und gestempelte Urkunden sind kein sauberer Text. Ein vision-fähiges lokales Modell lässt die Pipeline auf bildlastigen Seiten arbeiten, statt an allem zu scheitern, was nicht bereits maschinenlesbar ist, auch wenn das Layout weiterhin begrenzt, wie zuverlässig die Extraktion ist.

Gehärteter, isolierter Docker-Container

Die App läuft schreibgeschützt mit allen entfernten Linux-Capabilities, gesetztem no-new-privileges, tmpfs als Ablagefläche sowie engen Speicher- und Prozessgrenzen, in einem eigenen isolierten Bridge-Netzwerk, das nur an localhost gebunden ist. Der Container hat eine minimale Angriffsfläche, noch bevor das Modell betrachtet wird.

Austauschbarer LLM-Provider

Der Provider ist ein Schalter: die Voreinstellung routet zum lokalen Ollama, mit einem optionalen Pfad zu einer lokalen CLI-Bridge. Die Voreinstellung verlässt nie den Host, sodass die Lokal-Garantie ohne Sonderkonfiguration gilt.

Tech-Stack

Next.jsOllamallavaDocker

Was zuerst gebrochen ist

▸
Vertrauliche Dokumente legen die Rahmenbedingung fest, bevor irgendeine Modellentscheidung fällt. Sobald die Regel lautet 'nichts verlässt den Host', ist eine gehostete API ausgeschlossen, und die gesamte Pipeline muss gegen ein lokales Modell laufen — diese eine Entscheidung prägt alles Weitere, von der Modellgröße bis zu den Latenzerwartungen.
▸
Die Klauselextraktion ist nur so gut wie der Text, den man einspeist. Saubere, gut gesetzte PDFs werden sauber gelesen; gescannte Eintragungen, gestempelte Eigentumsurkunden und dichte mehrspaltige Verträge verschlechtern die Extraktionsqualität. Ein vision-fähiges Modell hilft bei bildlastigen Seiten, aber das Layout entscheidet weiterhin über die Obergrenze.
▸
Dokumente im Arbeitsspeicher mit kurzer Session-TTL statt in einer Datenbank zu halten, hat eine ganze Klasse von Datenaufbewahrungsfragen beseitigt. Es gibt keinen Speicher, der lecken, falsch gesichert oder zu löschen vergessen werden könnte — aber es bedeutet auch, dass nichts erhalten bleibt, die App ist also ein Arbeitswerkzeug für eine Session, kein Archivsystem.

Ergebnis

Ein funktionierendes, selbst gehostetes Dokumenten-KI-Werkzeug, das Klauselextraktion und Risikomarkierung an Kanzleidokumenten demonstriert und dabei jedes Byte vertraulichen Inhalts auf dem Host hält. Als Portfolio-Demo belegt es die Architektur — lokale Inferenz, kein persistenter Speicher, ein gehärteter Container — statt echte Mandate zu bearbeiten. Die ehrliche Erkenntnis ist, dass das Datenschutzmodell solide und das Engineering sauber ist, die Extraktionsqualität aber vom Dokumentenlayout bestimmt wird und die Ausgabe eine Triage-Hilfe bleibt, die ein Anwalt weiterhin prüfen muss.

Ehrliche Grenzen

Selbst gehostet und allein als Portfolio-Demo gebaut, läuft in einem lokalen Lab — der alte VPS, der es einst hostete, wurde stillgelegt. Die Genauigkeit bei vertraulichen Dokumenten schwankt mit dem Layout: saubere digitale PDFs werden gut extrahiert, während Scans und stark formatierte Eintragungen schwächer sind. Es läuft gegen ein lokales Modell, die Ausgabe ist daher nicht deterministisch und sollte geprüft werden. Es ist eine Extraktions- und Triage-Hilfe, kein Ersatz für einen Anwalt, und nichts, was es erzeugt, ist Rechtsberatung.