Wer mandatsbezogene Daten in ein externes KI-System eingibt, nimmt ein Risiko in Kauf, das mit dem anwaltlichen Berufsgeheimnis schwer vereinbar ist. Lokale LLM-Lösungen sind für viele Kanzleiaufgaben die einzig richtige Antwort – aber nicht für alle Zwecke.
- Cloud-KI-Dienste schaffen strukturelle Compliance-Risiken, die auch Pseudonymisierung nicht vollständig löst.
- Für die meisten Kanzlei-Aufgaben — insbesondere Datenextraktion aus Akten — sind lokale LLM wie Qwen oder Llama leistungsstark genug.
- Lokale Modelle auf eigener Hardware (z. B. NVIDIA Spark) verursachen nach dem Setup keine laufenden API-Kosten.
- Eigene Datenlayer ermöglichen kanzleispezifische Anpassungen und den Aufbau proprietärer Wissensassets.
- DEPLAW orchestriert mehrere LLM parallel: Für jede Einzeltätigkeit das passende Modell — lokal oder extern — ohne Systemwechsel.
- Für komplexe Schriftsätze bleibt ein restriktiv konfiguriertes externes LLM sinnvoll, sofern keine hochsensiblen Daten involviert sind.
Warum lokale KI für Kanzleien ein Gamechanger ist
Der Markt für Legal AI wächst schnell. Neue Produkte versprechen automatisierte Schriftsatzerstellung, Aktenanalyse und Mandantenkommunikation — allesamt gestützt auf große Sprachmodelle, die in der Cloud laufen. Für Unternehmen ohne besondere Vertraulichkeitspflichten mag das unkompliziert sein. Für Kanzleien ist die Ausgangslage grundlegend anders.
Anwältinnen und Anwälte unterliegen der beruflichen Verschwiegenheitspflicht nach § 43a Abs. 2 BRAO. Diese Pflicht gilt gegenüber jedermann — auch gegenüber Software-Anbietern. Wer Mandantendaten an einen externen KI-Dienst übermittelt, tritt faktisch in eine Datenübertragungsbeziehung ein, die vom Mandanten in der Regel weder ausdrücklich genehmigt noch auch nur im Ansatz absehbar ist.
Gleichzeitig ist der Druck, effizienter zu werden, real.
Massenverfahren mit tausenden Akten, strukturierte Datenextraktion aus Schriftsätzen, Vorprüfungen im Großmandat — dies sind Aufgaben, bei denen KI-Unterstützung enorme Effizienzgewinne liefern kann.
Lokale LLM-Lösungen können auf dieses operative Spannungsverhältnis eine Antwort sein: Sie bringen die KI in die eigene Kanzlei, statt die Daten nach draußen zu schicken.
Der technologische Reifegrad lokaler Modelle hat in den letzten 18 Monaten einen Sprung gemacht, der diese Option für mittelgroße und große Kanzleien sehr erschwinglich macht.
Modelle wie Qwen 2.5 oder Meta Llama 3 laufen auf Kleinservern, liefern bei strukturierten Aufgaben sehr gute Ergebnisse und sind nach der einmaligen Einrichtung ohne laufende Lizenz- oder API-Kosten nutzbar. Das verändert die Wirtschaftlichkeitsrechnung grundlegend.
| § 43aBRAO — gesetzliche Grundlage der anwaltlichen VerschwiegenheitspflichtBRAO | Art. 9DSGVO — besondere Kategorien personenbezogener Daten mit erhöhtem SchutzbedarfDSGVO | 0 €Laufende API-Kosten nach erfolgreicher Einrichtung eines lokalen LLM | > 80 %Kanzleiaufgaben, die keine Top-Tier-Modellleistung erfordern — strukturierte Extraktion, Klassifikation, PrüfroutinenInterne LDT-Analyse 2025 |
Datenschutz und Vertraulichkeit: Der entscheidende Vorteil
Der Einsatz cloudbasierter KI-Dienste in der Kanzlei wirft berufsrechtliche und datenschutzrechtliche Fragen auf, die von Anbietern dieser Dienste häufig systematisch unterschätzt werden.
Die Anwaltskammer Frankfurt am Main hat bereits in einem Rundschreiben aus dem Jahr 2024 explizit 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 Einwilligung des Mandanten vorliegt.
Die Datenschutzkonferenz (DSK) hat zudem klargestellt, dass die Nutzung von KI-Diensten außerhalb der EU besonderen Anforderungen unterliegt, insbesondere wenn Daten in Drittstaaten ohne angemessenes Schutzniveau übermittelt werden.
Viele Anbieter begegnen diesen Bedenken mit zwei Argumenten:
– Erstens behaupten sie, dass Trainingsdaten-Opt-out-Optionen das Problem lösen.
– Zweitens empfehlen sie Pseudonymisierung als Schutzmaßnahme.
Beide Argumente halten einer genaueren Prüfung bei Berufsgeheimnisträgern jedoch nicht stand. Das Opt-out aus der Trainingsverwendung ändert nichts daran, dass die Daten zum Zeitpunkt der Verarbeitung an externe Server übermittelt werden. Die Daten verlassen die Kanzlei — der Zeitpunkt der Übermittlung ist bereits der kritische Moment, nicht erst die spätere Verwendung für Training. Das Training vertieft den offenbarten Schutz allenfalls noch einmal
Pseudonymisierung ist bei juristischen Akten strukturell begrenzt wirksam. Ein Schriftsatz enthält typischerweise nicht nur Namen, sondern ein dichtes Geflecht aus Daten: Schadenshergang, Krankheitsbilder, Vermögensverhältnisse, Tatvorwürfe, Unternehmensstrategien. Diese Informationen sind auch ohne Klarnamen häufig reidentifizierbar, insbesondere wenn der Anbieter weitere Kontextdaten aus anderen Quellen hält.
Besonders kritisch ist die Lage bei Gesundheitsdaten (Art. 9 DSGVO), in Strafsachen sowie bei Mandaten mit Geschäftsgeheimnissen im Sinne des GeschGehG. Wer diese Daten in ein externes KI-System eingibt — auch ein europäisches — bewegt sich in rechtlich unsicherem Terrain.
Das Risiko ist nicht hypothetisch: Ein Datenschutzverstoß in diesem Kontext kann Haftungsansprüche, Strafverfahren, berufsrechtliche Konsequenzen und erheblichen Reputationsschaden nach sich ziehen.
Die Lösung? Der Einsatz von lokalen LLM in der eigenen Kanzlei.
Die Daten verlassen die eigene IT-Infrastruktur zu keinem Zeitpunkt. Es gibt keine API-Verbindung zu einem externen Anbieter, keine Übermittlung in Drittstaaten, keine Abhängigkeit von Datenschutzzertifikaten externer Dienste. Das Modell läuft auf Servern, die sich im Einflussbereich der Kanzlei befinden — entweder im eigenen Unternehmen oder bei einem deutschen Hosting-Anbieter mit entsprechendem Auftragsverarbeitungsvertrag.
Die richtige Hardware und Modellwahl für den Kanzleialltag
Die erste Frage, die sich bei lokalen LLM stellt, ist die Hardwarefrage. Große Sprachmodelle mit hunderten Milliarden Parametern — wie GPT-4 oder Claude 3 Opus — benötigen Rechenkapazitäten im Rechenzentrum-Maßstab.
Für den Kanzleieinsatz sind jedoch in der Regel erheblich kompaktere Modelle ausreichend. Modelle mit 7 bis 32 Milliarden Parametern — quantisiert auf 4 oder 8 Bit — laufen auf aktueller Server-Hardware mit einer oder zwei NVIDIA-GPUs stabil und mit praxistauglicher Antwortgeschwindigkeit.
NVIDIA bietet mit dem DGX Spark (vormals Project DIGITS) ein kompaktes System an, das speziell für den Betrieb von KI-Modellen entwickelt wurde. Der Spark liefert bis zu einem Petaflop KI-Rechenleistung in einem Desktop-Formfaktor und ist in der Lage, Modelle mit bis zu 200 Milliarden Parametern lokal zu betreiben. Für die meisten Kanzleianwendungen ist das mehr als ausreichend.
Alternativ lassen sich auch bestehende Server mit einer oder mehreren NVIDIA RTX- oder A-Series-GPUs aufrüsten, was in vielen Kanzleien mit vorhandener Server-Infrastruktur kostengünstiger ist.
Bei der Modellwahl haben sich für juristische Anwendungsfälle insbesondere Qwen 2.5 (Alibaba, in verschiedenen Größen bis 72B verfügbar), Meta Llama 3.1 sowie Mistral-Varianten bewährt. Diese Modelle sind open-weight, d.h. die Gewichte können heruntergeladen, lokal betrieben und für spezifische Aufgaben feinabgestimmt werden.
Qwen 2.5 72B zeigt bei strukturierten Extraktionsaufgaben — dem wichtigsten Anwendungsfall in der Kanzleipraxis — eine Leistung, die für den produktiven Einsatz gut geeignet ist. Für einfachere Klassifikations- und Extraktionsaufgaben reicht oft bereits die 7B- oder 14B-Variante.
Viele unserer Kunden sind dabei nach den ersten Praxistests überrascht, dass die meisten Kanzleiaufgaben im KI-Bereich keine kreative Sprachgenerierung auf höchstem Niveau erfordern.
Das Extrahieren strukturierter Daten aus Schriftsätzen — Parteien, Fristen, Streitwerte, Anspruchsgrundlagen, Schadenspositionen — ist eine Aufgabe, die auch mittelgroße lokale Modelle sehr zuverlässig erledigen.
Gleiches gilt für Klassifikation (gehört dieses Dokument zu Fall A oder B?), Vollständigkeitsprüfungen oder die Zusammenfassung von Aktenbestandteilen. Für diese Tätigkeiten ist ein externes Cloud-Modell aus Leistungssicht nicht notwendig — und aus Datenschutzsicht schwerlich vertretbar.
| Modell | Parametergröße | Typische Hardware | Stärken im Kanzleieinsatz | Lizenz |
|---|---|---|---|---|
| Qwen 2.5 | 7B / 14B / 32B / 72B | 1–2× NVIDIA RTX 4090 / A100 / DGX Spark | Strukturierte Extraktion, Mehrsprachigkeit (DE/EN), Instruktionsfolge | Apache 2.0 |
| Meta Llama 3.1 | 8B / 70B / 405B | RTX 4090 (8B) / A100 (70B) / DGX Spark (70B) | Textklassifikation, Zusammenfassungen, strukturierter Output | Llama Community License |
| Mistral 7B / Mixtral 8×7B | 7B / 46B eff. | RTX 3090 (7B) / A100-Cluster (Mixtral) | Schnelle Inferenz, effiziente Ressourcennutzung, gute Instruktionsmodelle | Apache 2.0 |
| Llama 3.2 Vision | 11B / 90B | A100 / DGX Spark | Dokumentenanalyse mit Bildinhalten, OCR-Nachverarbeitung | Llama Community License |
| DeepSeek R1 (distilled) | 7B / 14B / 32B | RTX 4090 / DGX Spark | Reasoning-Aufgaben, mehrstufige juristische Prüfschritte | MIT |
Beim Betrieb lokaler Modelle empfiehlt sich der Einsatz von Inference-Frameworks wie Ollama, vLLM oder LM Studio, die den Betrieb erheblich vereinfachen. Diese Tools übernehmen das Laden der Modelle in den GPU-Speicher, stellen eine OpenAI-kompatible API bereit und ermöglichen die parallele Verwaltung mehrerer Modelle. DEPLAW kann direkt gegen diese lokale API orchestriert werden — ohne Anpassung der Kern-Plattform.
Praxistipps für eine erfolgreiche Implementierung
Die technische Einrichtung eines lokalen LLM ist kein triviales Projekt, aber auch kein unlösbares.
Wer noch keine GPU-Server-Infrastruktur betreibt, benötigt beim initialen Setup fachkundige Unterstützung — entweder durch einen IT-Dienstleister mit KI-Erfahrung oder durch den Plattformanbieter.
Das ist eine einmalige Investition, die sich durch entfallende API-Kosten in überschaubarer Zeit amortisiert. Eine mittelgroße Kanzlei, die monatlich mehrere tausend Dokumente per KI verarbeitet, zahlt bei gängigen Cloud-Modellen schnell einen kleinen, vierstelligen Euro pro Monat allein an API-Gebühren.
Ein lokales Setup auf einem NVIDIA DGX Spark oder einem vergleichbaren Server kostet einmalig zwischen 3.000 und 15.000 Euro je nach Konfiguration — danach entstehen keine Modellkosten mehr.
Ein oft unterschätzter Aspekt ist die Möglichkeit, eigene Datenlayer mit dem lokalen Modell zu verbinden. Technisch geschieht dies über sogenannte RAG-Architekturen (Retrieval-Augmented Generation): Das Modell hat dabei keinen allgemeinen Internetzugriff, sondern greift ausschließlich auf eine strukturierte, kanzleieigene Wissensbasis zu. Diese kann Präzedenzfälle der eigenen Kanzlei enthalten, interne Prüfschemata, Formulierungsstandards, Musterklauseln, mandatsspezifische Definitionen oder eigene Urteils-Datenbanken. Das Ergebnis ist ein Modell, das nicht nur allgemeines juristisches Wissen mitbringt, sondern die spezifische Arbeitsweise und das Erfahrungswissen der Kanzlei reflektiert.
Darüber hinaus bietet das Fine-Tuning die Möglichkeit, ein Basismodell gezielt auf kanzleispezifische Aufgaben zu trainieren:
Wer über ausreichend annotierte Beispieldaten verfügt — etwa aus vergangenen Akten, bei denen die Extraktionsergebnisse manuell geprüft wurden — kann das Modell auf diese Aufgaben spezialisieren und dabei erhebliche Qualitätsgewinne erzielen. So entsteht ein proprietary Asset: ein Modell, das die Kanzlei besser versteht als jedes generisches Cloud-Modell. Dieser Wissensschatz bleibt vollständig in der Hand der Kanzlei und kann nicht von Mitbewerbern repliziert werden.
DEPLAW als Legal Tech Plattform bietet in diesem Kontext einen entscheidenden Vorteil: Sie können nicht nur ein lokales LLM einbinden, sondern mehrere Modelle gleichzeitig orchestrieren.
Jeder Schritt innerhalb eines Automatisierungsworkflows kann einem anderen Modell zugewiesen werden — dem lokalen Modell für sensible Extraktionsschritte, einem spezialisierten Modell für Klassifikation, einem leistungsstarken externen Modell für die abschließende Schriftsatzerstellung auf Basis bereits anonymisierter Daten. Diese Multi-LLM-Architektur ermöglicht es, KI-Funktionen ohne Systemwechsel und ohne Einschränkungen zu kombinieren und jederzeit flexibel zu wechseln.
Besonders für Massenverfahren ergibt sich durch diese Architektur eine vollständige End-to-End-Automatisierung: Eingehende Schriftsätze werden automatisch einer Akte zugeordnet, das lokale LLM extrahiert die relevanten Daten, die strukturierten Ergebnisse fließen in den Aktenbestand, und auf deren Grundlage wird — bei Bedarf unter Hinzuziehung eines externen Modells — ein Schriftsatzentwurf erstellt, der dem zuständigen Anwalt zur Freigabe vorgelegt wird. Der gesamte Datentransfer sensibler Informationen bleibt dabei lokal.
Fazit: Lohnt sich der Aufwand?
Lokale LLM sind nicht für jeden Anwendungsfall die optimale Lösung. Sie sind jedoch für eine klar definierte Klasse von Aufgaben die einzig sinnvolle.
Wer diese Unterscheidung versteht und operativ umsetzt, gewinnt auf zwei Ebenen gleichzeitig: Compliance-Sicherheit für sensible Aufgaben und Kosteneffizienz durch den Wegfall laufender API-Gebühren.
Die Grenzen lokaler Modelle sollten dabei nicht beschönigt werden. Bei der Erstellung komplexer, argumentativ anspruchsvoller Schriftsätze — etwa in einem Berufungsverfahren mit schwieriger Rechtsfrage — zeigen auch die besten lokalen Modelle signifikante Qualitätsunterschiede gegenüber Top-Tier-Modellen wie GPT-4o oder Claude Sonnet oder gar Opus. Wortgewandtheit, Argumentationstiefe und die Fähigkeit, implizite juristische Zusammenhänge herzustellen, sind bei großen Cloud-Modellen aktuell noch überlegen. Diesen Vorteil zu ignorieren, wäre ebenso falsch wie die Datenschutzrisiken zu ignorieren.
Die operative Empfehlung lautet daher:
Verwenden Sie ein Zwei-Ebenen-Modell.
Auf der ersten Ebene — dem lokalen System — laufen alle Aufgaben, die entweder hochvolumig sind oder besonders sensible Daten involvieren. Dazu zählen die Datenextraktion aus der Gesamtakte, Klassifikationen, Vollständigkeitsprüfungen, Zusammenfassungen.
Auf der zweiten Ebene — einem restriktiv konfigurierten, EU-konformen externen Modell — können einzelne, qualitätskritische Teilschritte wie die Erstellung komplexer Schriftsätze ausgeführt werden, sofern diese ausschließlich auf bereits extrahierten, strukturierten und vorab anonymisierten Daten basieren. Keine Rohdaten, keine Originalschriftsätze, keine Mandantenklarnamen.
| Aufgabentyp | Empfohlenes Modell | Begründung | Daten, die das System sieht |
|---|---|---|---|
| Datenextraktion aus Schriftsätzen (Parteien, Fristen, Streitwerte) | Lokal (z. B. Qwen 2.5 32B) | Ausreichende Modellleistung, enthält Rohdaten der Akte | Vollständige Schriftsätze inkl. Klarnamen |
| Dokumentklassifikation und Aktenstrukturierung | Lokal (z. B. Llama 3.1 8B) | Einfache Aufgabe, hohes Volumen, kein externer Zugriff nötig | Dokumentinhalt, Metadaten |
| Mandate mit Gesundheitsdaten / Strafsachen / Geschäftsgeheimnissen | Ausschließlich lokal | Art. 9 DSGVO, GeschGehG, berufsrechtliche Verschwiegenheit | Sämtliche Mandatsdaten — kein externer Zugriff |
| Vollständigkeitsprüfung von Akten | Lokal (z. B. Qwen 2.5 14B) | Strukturierte Prüfaufgabe, kein kreatives Sprachvermögen erforderlich | Aktenvolltext oder strukturierter Extrakt |
| Einfache Standardschriftsätze (Mahnungen, Fristverlängerungen) | Lokal (z. B. Qwen 2.5 32B) | Ausreichende Qualität, keine externen API-Kosten, keine Datenweitergabe | Strukturierte Aktendaten aus vorheriger Extraktion |
| Komplexe Schriftsätze (Berufung, komplexe Klagen) auf Basis extrahierter Daten | Extern (EU-konform, restriktiv konfiguriert, z. B. GPT-4o über Azure OpenAI) | Qualitätsvorteil großer Modelle bei argumentativer Tiefe; nur anonymisierte Strukturdaten übermitteln | Nur vorab extrahierte, anonymisierte Strukturdaten — keine Rohdaten |
DEPLAW macht diese Zwei-Ebenen-Architektur operativ umsetzbar, ohne dass die Kanzlei mehrere separate Systeme verwalten muss. Die Plattform orchestriert jeden Schritt eines Automatisierungsworkflows und spricht für jeden Schritt das passende Modell an — lokal oder extern, je nach Konfiguration und Datensensibilität. Wechsel zwischen Modellen erfolgen ohne Systemwechsel. Wird ein neues Modell verfügbar, das für einen bestimmten Aufgabentyp besser geeignet ist, kann es innerhalb des DEPLAW-Workflows ausgetauscht werden, ohne den Gesamtprozess anzupassen. Diese Flexibilität ist in einem Bereich, in dem sich Modelle monatlich weiterentwickeln, ein erheblicher strategischer Vorteil.
Für Großmandate, für Massenverfahren mit tausenden gleichartiger Akten und für das Verbraucherrecht mit standardisierten Prüfabläufen ist die beschriebene Architektur bereits heute produktiv einsetzbar. Der initiale Aufwand ist real, aber überschaubar. Die Kombination aus Compliance-Sicherheit, dauerhafter Kostenersparnis und dem Aufbau eines proprietären Modell-Assets macht lokale LLM zu einer strategischen Investition — nicht zu einem technischen Experiment.
Starten Sie mit einem klar abgegrenzten Pilotbereich: einem Massenverfahren oder einer hochvolumigen Aktenkategorie. Definieren Sie die Extraktionsaufgaben präzise, richten Sie das lokale Modell mit Unterstützung ein und messen Sie Qualität und Durchsatz nach vier Wochen. In diesem Zeitraum lässt sich der Break-even-Punkt gegenüber Cloud-API-Kosten konkret berechnen. Die Entscheidung für oder gegen eine Ausweitung trifft sich dann auf Basis von Daten, nicht auf Basis von Anbieterversprechen.
„`