Wer mandatsbezogene Daten in ein externes KI-System eingibt, geht ein Risiko ein, das sich mit dem anwaltlichen Berufsgeheimnis kaum vereinbaren lässt. Für viele Aufgaben im Kanzleialltag ist ein lokal betriebenes Sprachmodell deshalb nicht nur die vorsichtigere, sondern schlicht die richtige Antwort – wenn auch nicht für jeden Anwendungsfall.

01 Ausgangslage

Warum lokale KI für Kanzleien ein Gamechanger ist

Der Markt für Legal AI wächst rasant. Neue Produkte versprechen automatisierte Schriftsatzerstellung, Aktenanalyse und Mandantenkommunikation – fast immer gestützt auf große Sprachmodelle, die in der Cloud laufen. Für Unternehmen ohne besondere Verschwiegenheitspflichten mag das unproblematisch sein. Für Kanzleien liegt der Fall anders.

Die berufliche Verschwiegenheitspflicht nach § 43a Abs. 2 BRAO gilt gegenüber jedermann – auch gegenüber Software-Anbietern. Wer Mandantendaten an einen externen KI-Dienst schickt, tritt faktisch in eine Datenübertragung ein, die der Mandant in aller Regel weder ausdrücklich erlaubt noch überhaupt absehen konnte.

Gleichzeitig ist der Effizienzdruck real: Massenverfahren mit tausenden Akten, strukturierte Datenextraktion aus Schriftsätzen, Vorprüfungen im Großmandat – all das sind Aufgaben, bei denen KI enorme Zeitgewinne bringen kann.

Lokale Modelle lösen diesen Widerspruch, indem sie die KI in die eigene Kanzlei holen, statt Daten nach außen zu schicken. Der technologische Reifegrad hat in den vergangenen 18 Monaten einen Sprung gemacht, der diese Option inzwischen auch für mittelgroße und große Kanzleien wirtschaftlich attraktiv macht: Modelle wie Qwen 2.5 oder Meta Llama 3.1 laufen auf vergleichsweise kompakter Server-Hardware, liefern bei strukturierten Aufgaben gute Ergebnisse und verursachen nach der einmaligen Einrichtung keine laufenden Lizenz- oder API-Kosten mehr. Das verändert die Wirtschaftlichkeitsrechnung grundlegend.

02 Compliance & Berufsrecht

Datenschutz und Vertraulichkeit: der entscheidende Vorteil

Der Einsatz cloudbasierter KI in der Kanzlei wirft berufsrechtliche und datenschutzrechtliche Fragen auf, die Anbieter solcher Dienste häufig unterschätzen. Die Rechtsanwaltskammer Frankfurt am Main hat schon 2024 in einem Rundschreiben darauf hingewiesen, dass die Übermittlung mandantenbezogener Daten an KI-Dienste Dritter in der Regel gegen § 43a Abs. 2 BRAO verstößt, sofern keine ausdrückliche Mandanteneinwilligung vorliegt. Die Datenschutzkonferenz (DSK) hat ergänzend klargestellt, dass KI-Dienste außerhalb der EU besonderen Anforderungen unterliegen, insbesondere bei Übermittlung in Drittstaaten ohne angemessenes Schutzniveau.

Anbieter begegnen diesen Bedenken meist mit zwei Argumenten: einem Opt-out aus der Trainingsverwendung und einer Pseudonymisierung der Daten. Beide halten einer genaueren Prüfung bei Berufsgeheimnisträgern nicht stand. Das Opt-out ändert nichts daran, dass die Daten zum Zeitpunkt der Verarbeitung ohnehin schon an externe Server übermittelt wurden – dieser Moment, nicht die spätere Trainingsnutzung, ist bereits der kritische Punkt. Und Pseudonymisierung wirkt bei juristischen Akten nur begrenzt: Ein Schriftsatz enthält neben Namen meist ein dichtes Geflecht aus Schadenshergang, Krankheitsbildern, Vermögensverhältnissen oder Geschäftsstrategien, das auch ohne Klarnamen häufig reidentifizierbar bleibt – besonders wenn der Anbieter zusätzlichen Kontext aus anderen Quellen hält.

Besonders kritisch ist die Lage bei Gesundheitsdaten (Art. 9 DSGVO), in Strafsachen und bei Mandaten mit Geschäftsgeheimnissen im Sinne des GeschGehG. Ein Datenschutzverstoß in diesem Kontext ist kein theoretisches Risiko, sondern kann Haftung, Strafverfahren, berufsrechtliche Konsequenzen und erheblichen Reputationsschaden nach sich ziehen.

Die naheliegende Lösung: ein lokal betriebenes Sprachmodell. Die Daten verlassen die eigene IT-Infrastruktur zu keinem Zeitpunkt – keine API-Verbindung nach außen, keine Übermittlung in Drittstaaten, keine Abhängigkeit von den Datenschutzzusagen eines externen Anbieters. Das Modell läuft auf Servern im eigenen Einflussbereich, sei es im eigenen Haus oder bei einem deutschen Hoster mit entsprechendem Auftragsverarbeitungsvertrag.

03 Technik & Modelle

Die richtige Hardware und Modellwahl für den Kanzleialltag

Die erste Frage bei lokalen Sprachmodellen ist meist die Hardwarefrage. Modelle mit hunderten Milliarden Parametern wie GPT-4 oder Claude Opus brauchen Rechenzentrum-Kapazitäten – für den Kanzleieinsatz reichen aber in der Regel deutlich kompaktere Varianten. Modelle mit 7 bis 32 Milliarden Parametern, auf 4 oder 8 Bit quantisiert, laufen stabil und mit praxistauglicher Antwortgeschwindigkeit auf aktueller Server-Hardware mit ein bis zwei GPUs.

NVIDIA bietet mit dem DGX Spark ein kompaktes System im Desktop-Format an, das bis zu einem Petaflop KI-Rechenleistung liefert und Modelle mit bis zu 200 Milliarden Parametern lokal betreiben kann – für die meisten Kanzleianwendungen mehr als ausreichend. Alternativ lässt sich vorhandene Server-Infrastruktur mit einer oder mehreren GPUs der RTX- oder A-Serie aufrüsten, was in vielen Kanzleien der günstigere Weg ist.

Bei der Modellwahl haben sich für juristische Anwendungsfälle vor allem Qwen 2.5, Meta Llama 3.1 und verschiedene Mistral-Varianten bewährt – alle open-weight, also frei herunterladbar, lokal betreibbar und für einzelne Aufgaben feinjustierbar:

Modell Parametergröße Typische Hardware Stärken im Kanzleieinsatz Lizenz
Qwen 2.5 7B / 14B / 32B / 72B 1–2× RTX 4090 / A100 / DGX Spark Strukturierte Extraktion, Mehrsprachigkeit DE/EN Apache 2.0
Meta Llama 3.1 8B / 70B / 405B RTX 4090 (8B) / A100 (70B) / DGX Spark (70B) Textklassifikation, Zusammenfassungen Llama Community License
Mistral 7B / Mixtral 8×7B 7B / 46B eff. RTX 3090 (7B) / A100-Cluster (Mixtral) Schnelle Inferenz, effiziente Ressourcennutzung Apache 2.0
Llama 3.2 Vision 11B / 90B A100 / DGX Spark Dokumentenanalyse mit Bildinhalten, OCR-Nachbearbeitung Llama Community License
DeepSeek R1 (distilled) 7B / 14B / 32B RTX 4090 / DGX Spark Mehrstufige juristische Prüfschritte MIT

Qwen 2.5 72B liefert bei strukturierter Extraktion – dem wichtigsten Anwendungsfall in der Kanzleipraxis – bereits produktionsreife Ergebnisse; für einfachere Klassifikations- und Extraktionsaufgaben reichen oft schon die 7B- oder 14B-Varianten. Für den Betrieb empfehlen sich Inference-Frameworks wie Ollama, vLLM oder LM Studio: Sie laden die Modelle in den GPU-Speicher, stellen eine OpenAI-kompatible API bereit und verwalten mehrere Modelle parallel. DEPLAW lässt sich direkt gegen diese lokale API orchestrieren, ohne Änderungen an der Kern-Plattform.

04 Implementierung

Praxistipps für eine erfolgreiche Einführung

Die technische Einrichtung ist kein triviales Projekt, aber auch kein unlösbares. Wer noch keine GPU-Server-Infrastruktur betreibt, braucht beim initialen Setup fachkundige Unterstützung – durch einen KI-erfahrenen IT-Dienstleister oder den Plattformanbieter. Diese einmalige Investition amortisiert sich meist zügig: Eine mittelgroße Kanzlei, die monatlich mehrere tausend Dokumente per KI verarbeitet, zahlt bei gängigen Cloud-Modellen schnell einen niedrigen vierstelligen Eurobetrag pro Monat allein an API-Gebühren. Ein lokales Setup auf einem DGX Spark oder vergleichbarem Server kostet je nach Konfiguration einmalig zwischen 3.000 und 15.000 Euro – danach entstehen keine laufenden Modellkosten mehr.

Ein oft unterschätzter Vorteil: die Anbindung eines eigenen Datenlayers per RAG (Retrieval-Augmented Generation). Das Modell hat dabei keinen allgemeinen Internetzugriff, sondern greift ausschließlich auf eine strukturierte, kanzleieigene Wissensbasis zu – etwa Präzedenzfälle, interne Prüfschemata, Formulierungsstandards oder Musterklauseln. So entsteht ein Modell, das nicht nur allgemeines juristisches Wissen mitbringt, sondern die Arbeitsweise der eigenen Kanzlei kennt. Ergänzend erlaubt Fine-Tuning, ein Basismodell mit ausreichend annotierten Beispieldaten – etwa manuell geprüften Extraktionsergebnissen aus vergangenen Akten – gezielt auf kanzleispezifische Aufgaben zu spezialisieren. Das Ergebnis ist ein proprietäres Wissens-Asset, das kein Wettbewerber replizieren kann.

Die Einführung lässt sich in sechs Schritten strukturieren:

  1. Anforderungsanalyse und Priorisierung – welche Aufgaben soll das lokale Modell übernehmen? Priorisiert wird nach Volumen und Datensensibilität; hochvolumige, sensible Aufgaben sind ideale Einstiegspunkte.
  2. Hardware-Entscheidung – für die meisten Kanzleien mit bis zu 50 parallelen Nutzern reicht ein DGX Spark oder ein Server mit zwei A100-80GB-GPUs, mit VRAM-Reserve für künftige Modellgenerationen.
  3. Setup und Modellinstallation – Inference-Framework wählen (Ollama, vLLM), Modelle laden, Netzwerksicherheit, Zugriffskontrolle und Monitoring einrichten, idealerweise mit externer Unterstützung.
  4. Aufbau des kanzleieigenen Datenlayers – interne Wissensdaten strukturieren und per Vektordatenbank (z. B. Qdrant, Weaviate) an das Modell anbinden; dieser Layer wächst mit jeder neuen Akte.
  5. Integration in DEPLAW – das lokale Modell in bestehende Automatisierungsworkflows einbinden, mit optionaler Ergänzung durch ein extern angebundenes Modell für einzelne Schritte auf Basis bereits anonymisierter Daten.
  6. Qualitätssicherung und laufende Optimierung – strukturierter Review-Prozess in der Anfangsphase, validierte Ergebnisse als Trainingsgrundlage für Fine-Tuning, kontinuierliche Messung von Qualität und Durchsatz.

DEPLAW kann dabei mehrere Modelle gleichzeitig orchestrieren: das lokale Modell für sensible Extraktionsschritte, ein spezialisiertes Modell für Klassifikation, ein leistungsstarkes externes Modell für die abschließende Schriftsatzerstellung auf Basis bereits anonymisierter Daten – frei kombinierbar, ohne Systemwechsel. Besonders bei Massenverfahren ergibt sich daraus eine durchgehende Automatisierung: Eingehende Schriftsätze werden automatisch der richtigen Akte zugeordnet, das lokale Modell extrahiert die relevanten Daten, und auf dieser Grundlage entsteht – bei Bedarf mit einem externen Modell – ein Schriftsatzentwurf zur Freigabe durch den zuständigen Anwalt. Der sensible Datentransfer bleibt dabei durchgehend lokal.

05 Fazit

Lohnt sich der Aufwand?

Lokale Sprachmodelle sind nicht für jeden Anwendungsfall die beste Lösung – aber für eine klar umrissene Klasse von Aufgaben die einzig sinnvolle. Wer diese Unterscheidung trifft, gewinnt gleich doppelt: Compliance-Sicherheit für sensible Aufgaben und Kosteneffizienz durch den Wegfall laufender API-Gebühren.

Die Grenzen sollten dabei nicht beschönigt werden. Bei komplexen, argumentativ anspruchsvollen Schriftsätzen – etwa in einem Berufungsverfahren mit schwieriger Rechtsfrage – liegen selbst die besten lokalen Modelle in Wortgewandtheit, Argumentationstiefe und dem Herstellen impliziter juristischer Zusammenhänge noch hinter Top-Tier-Cloud-Modellen wie GPT-4o oder Claude Opus zurück. Diesen Vorsprung zu ignorieren wäre ebenso falsch wie die Datenschutzrisiken der Cloud zu ignorieren.

Die praktikable Antwort ist ein Zwei-Ebenen-Modell: Auf der ersten Ebene, dem lokalen System, laufen alle hochvolumigen oder besonders sensiblen Aufgaben – Datenextraktion aus der Gesamtakte, Klassifikation, Vollständigkeitsprüfungen, Zusammenfassungen. Auf der zweiten Ebene kann ein restriktiv konfiguriertes, EU-konformes externes Modell einzelne qualitätskritische Teilschritte übernehmen, etwa die Erstellung komplexer Schriftsätze – aber ausschließlich auf Basis bereits extrahierter, strukturierter und anonymisierter Daten. Keine Rohdaten, keine Originalschriftsätze, keine Mandantenklarnamen verlassen dabei die Kanzlei.

Aufgabentyp Empfohlenes Modell Begründung
Datenextraktion aus Schriftsätzen (Parteien, Fristen, Streitwerte) Lokal Hochvolumig, sensible Rohdaten
Dokumentklassifikation, Vollständigkeitsprüfung Lokal Strukturierte Aufgabe, kein Kreativitätsbedarf
Zusammenfassung von Aktenbestandteilen Lokal Sensible Inhalte bleiben in der Kanzlei
Komplexe Schriftsatzentwürfe auf Basis anonymisierter Daten Extern (restriktiv konfiguriert) Höhere Argumentationstiefe erforderlich