KI-Chat-Agent fuer eine mittelgrosse Kanzlei

Eine Kanzlei mit 40 Anwaelten in der DACH-Region hatte ein Problem, das die meisten Rechtsteams kennen: kritisches Wissen, eingeschlossen in Dokumenten, die niemand richtig durchsuchen konnte. Interne Vermerke, Fallzusammenfassungen, Vertragsvorlagen, regulatorische Updates. Verstreut ueber gemeinsame Laufwerke und die Koepfe der Senior-Partner.

Sie wollten einen internen KI-Assistenten, den ihre Anwaelte tatsaechlich nutzen wuerden. Keinen generischen Chatbot. Etwas, das ihre Dokumente versteht, auf Deutsch antwortet, seine Quellen nennt und Mandantendaten innerhalb der EU behaelt.

Ich habe es fuer sie gebaut. Frontend, Backend, RAG-Pipeline, Deployment. So sah das Projekt aus.

Die Ausgangssituation

Die Kanzlei hatte zwei KI-Standardloesungen fuer den Rechtsbereich ausprobiert, bevor sie mich kontaktierte. Beide scheiterten aus denselben Gruenden.

Ihr Datenschutzbeauftragter stellte fest, dass Anfragen ueber US-basierte APIs geleitet wurden. Fuer eine Kanzlei, die mandantenvertrauliche Informationen verarbeitet, war das fuer beide Tools sofort das Aus. DSGVO plus die eigenen Auftragsverarbeitungsvereinbarungen der Kanzlei liessen keinerlei Interpretationsspielraum.

Die Tools konnten zudem nur oeffentliche Rechtsdatenbanken zusammenfassen. Sie hatten keinen Zugriff auf das interne Wissen der Kanzlei, eigene Praezedenzfaelle, Mandantenaufnahme-Vorlagen oder interne Richtlinien. Die Anwaelte probierten sie zweimal aus und hoerten auf.

Und ohne Quellenangaben konnte niemand ueberpruefen, ob die KI aus tatsaechlichen Kanzleidokumenten schoepfte oder plausibel klingende Fiktion generierte. In der juristischen Arbeit reicht "wahrscheinlich korrekt" nicht aus.

Der Auftrag war klar: Bauen Sie etwas, das mit unseren Dokumenten funktioniert, innerhalb der EU laeuft und genau zeigt, woher jede Antwort stammt.

Was ich gebaut habe

Das System hat vier Schichten. Jede einzelne musste innerhalb der Sicherheits- und Compliance-Anforderungen der Kanzlei funktionieren.

Wissensaufnahme-Pipeline

Die Kanzlei hatte rund 12.000 Dokumente aus drei Quellen: ein Dokumentenmanagementsystem (DMS), ein gemeinsames Netzlaufwerk und ein internes Wiki. Die Formate umfassten PDF, DOCX und HTML.

Ich baute eine Aufnahme-Pipeline, die Text aus allen drei Quellen nach einem naechtlichen Zeitplan extrahiert, Dokumente mit einer semantischen Strategie chunked (keine Splits fester Groesse), Embeddings mit einem multilingualen Modell auf EU-Infrastruktur generiert und Vektoren in einer PostgreSQL-Datenbank mit pgvector speichert, die bei einem deutschen Cloud-Anbieter laeuft.

Die Chunking-Strategie ist wichtiger, als die meisten denken. Feste 512-Token-Chunks brechen Rechtsklauseln mitten im Satz ab. Ich verwendete eine Kombination aus Ueberschriftenerkennung, Absatzgrenzen und Ueberlappungsfenstern, um den rechtlichen Kontext intakt zu halten. Allein das verbesserte die Retrieval-Genauigkeit um etwa 20% gegenueber dem naiven Ansatz.

RAG-Retrieval und Antwortgenerierung

Wenn ein Anwalt eine Frage stellt, wandelt das System die Anfrage in ein Embedding um, ruft die 8 relevantesten Dokumenten-Chunks ueber Vektor-Aehnlichkeitssuche ab, rankt die Ergebnisse mit einem Cross-Encoder-Modell um, um Fehlpositive herauszufiltern, und uebergibt dann die Top-5-Chunks plus die urspruengliche Frage an das LLM. Das LLM generiert eine Antwort mit Inline-Zitaten, die auf bestimmte Dokumente und Seitenzahlen verweisen.

Das LLM laeuft auf EU-gehosteter Infrastruktur. Keine Daten verlassen deutsche Rechenzentren zu irgendeinem Zeitpunkt. Ich verwendete ein selbst gehostetes Open-Source-Modell, das fuer deutsche Rechtssprache feinabgestimmt wurde und auf dedizierten GPU-Instanzen laeuft.

Jede Antwort enthaelt klickbare Quellenverweise. Anwaelte koennen jede Aussage ueberpruefen, indem sie das Originaldokument genau an dem Absatz oeffnen, den die KI verwendet hat. Das war die erste Anforderung, die die Kanzlei nannte, und das Letzte, was ich vor dem Launch getestet habe.

Das Frontend

Ich baute die Chat-Oberflaeche als React-Anwendung, eingebettet in das bestehende Intranet-Portal der Kanzlei. Sie musste sich wie ein Werkzeug anfuehlen, das Anwaelte tatsaechlich morgens um 7 oeffnen, nicht etwas, das man einmal vorfuehrt und dann vergisst.

Der Agent merkt sich den Kontext innerhalb einer Sitzung, sodass Anwaelte Folgefragen stellen koennen, ohne sich zu wiederholen. Ein Seitenpanel zeigt die abgerufenen Dokumente mit hervorgehobenen Passagen. Wenn die Retrieval-Konfidenz niedrig ist (wenige passende Dokumente, niedrige Aehnlichkeitswerte), sagt die Oberflaeche das explizit, anstatt eine sicher klingende Vermutung zu generieren. Anwaelte koennen Antworten auch als hilfreich markieren oder Ungenauigkeiten melden, was in die Retrieval-Optimierung zurueckfliesst.

Die Oberflaeche ist responsiv, aber fuer den Desktop optimiert. Anwaelte nutzen sie an ihren Arbeitsplaetzen, nicht auf dem Handy.

Deployment und Infrastruktur

Alles laeuft auf Hetzner Cloud in Deutschland mit Datenresidenz-Garantien. Das Node.js-Backend sitzt auf einer dedizierten VM. PostgreSQL mit pgvector laeuft auf einer verwalteten Instanz mit taeglichen verschluesselten Backups. Das selbst gehostete LLM laeuft auf GPU-Instanzen, lastverteilt fuer das Konkurrenz-Ziel von 40 Nutzern. Ein separater Embedding-Service uebernimmt die Dokumentenverarbeitung und Query-Embedding. Grafana-Dashboards verfolgen Antwortzeiten, Retrieval-Qualitaetsmetriken und Nutzungsmuster. Die Authentifizierung ist ueber SAML SSO in das bestehende Active Directory der Kanzlei integriert.

Keine externen API-Aufrufe. Keine Daten, die die Infrastruktur verlassen. Der Datenschutzbeauftragte prueft die Architektur, bevor ich die erste Zeile Code schrieb.

Ergebnisse nach 3 Monaten

Das System ging nach 8 Wochen Entwicklung und 2 Wochen Tests mit einer Pilotgruppe von 6 Anwaelten live.

Die 6% Ungenauigkeitsrate stammt hauptsaechlich von mehrdeutigen Anfragen, bei denen das System korrekte Dokumente abruft, das LLM aber die Frage falsch interpretiert. Die Feedback-Schleife erfasst diese, und die Retrieval-Qualitaet verbessert sich mit der Zeit, wenn Anwaelte mehr Trainingssignale liefern.

Die Zeitersparnis ist real, aber moderat. 3,5 Stunden pro Woche pro Anwalt. Die Kanzlei berechnet, dass sich das gesamte System bei ihrem durchschnittlichen Stundensatz innerhalb des ersten Quartals amortisiert. Juengere Anwaelte berichteten auch, dass sie sich bei ihrer Recherche sicherer fuehlen, weil sie gegen die eigene Wissensbasis der Kanzlei gegenpruefen koennen, anstatt sich nur auf externe Datenbanken zu verlassen.

Ein aehnlicher Ansatz funktionierte gut fuer ein RAG-System, das wir fuer einen Versicherungsmakler gebaut haben, wo die Recherchezeit um 75% sank.

Was ich anders machen wuerde

Zwei Dinge, die ich bei diesem Projekt auf die harte Tour gelernt habe.

Ich integrierte alle drei Dokumentenquellen waehrend der Entwicklung gleichzeitig. Rueckblickend waere es besser gewesen, nur mit dem DMS (der qualitativ hochwertigsten Quelle) zu beginnen und die anderen schrittweise hinzuzufuegen, um das Testen zu beschleunigen und die anfaengliche Genauigkeit zu erhoehen. Lektion: Mit einer sauberen Quelle anfangen, beweisen, dass es funktioniert, dann erweitern.

Ich unterschaetzte auch, wie viel Zeit das deutsche Prompt-Engineering in Anspruch nehmen wuerde. Die Standard-Deutschen-Ausgaben des LLM waren grammatikalisch korrekt, aber zu umgangssprachlich fuer Juristen. Ich verbrachte etwa zwei zusaetzliche Wochen damit, den System-Prompt und die Antwortformatierung an den Ton anzupassen, den Anwaelte erwarten. Das haette von Anfang an in der urspruenglichen Zeitplanung stehen sollen.

Tech-Stack

Fuer wen das relevant ist

Wenn Sie eine Kanzlei oder Rechtsabteilung in der DACH-Region fuehren und einen internen KI-Assistenten in Betracht ziehen, kommt es auf Folgendes an.

EU-Hosting ist nicht optional. Mandantenvertrauliche Daten duerfen die EU nicht verlassen. Jeder Anbieter, der Ihnen erzaehlt, seine US-gehostete API sei "DSGVO-konform", bittet Sie, ein Risiko mit den Daten Ihrer Mandanten einzugehen.

RAG mit Ihren eigenen Dokumenten ist der einzige Ansatz, der fuer internes Wissen funktioniert. Generische Legal-AI-Tools sind nuetzlich fuer oeffentliche Rechtsprechung. Fuer Ihre eigenen Praezedenzfaelle und Vorlagen sind sie nutzlos. Der Wert liegt darin, KI mit den Dokumenten zu verbinden, mit denen Ihre Kanzlei taeglich arbeitet.

Quellenangaben duerfen kein Nachgedanke sein. Anwaelte muessen jede Antwort verifizieren koennen. Wenn die KI nicht genau zeigen kann, welches Dokument und welchen Absatz sie verwendet hat, ist sie eine Haftung, kein Werkzeug.

Und Sie brauchen jemanden, der das Gesamtpaket bauen kann. KI-Backend, Frontend-Interface, Deployment, Sicherheitspruefung. Das ist kein Projekt, das man auf fuenf Anbieter aufteilen und hoffen kann, dass es sauber integriert.

Ich baue End-to-End-KI-Systeme fuer regulierte Branchen in der DACH- und Nordics-Region. Wenn das nach dem klingt, was Ihre Kanzlei braucht, vereinbaren Sie ein Gespraech und wir besprechen die Details.