Lokale KI in der Patentkanzlei einführen

Was „lokal" hier heißt

Je nach Setup zwei Bedeutungen. Im einfachsten Fall verarbeitet der eigene Rechner — Laptop oder Workstation — die Texte selbst, die Erfindungsmeldung verlässt die Festplatte gar nicht. Im Mehrbenutzer-Fall steht eine zentrale Workstation in der Kanzlei, die alle Mitarbeiter über das interne Netz nutzen; die Daten verlassen weder das Bürogebäude noch landen sie bei einem Cloud-Anbieter. In beiden Varianten gilt: es gibt keinen Cloud-Vertrag, an dem die Vertraulichkeit hängt — die hängt allein an der eigenen IT.

Wo der Cloud-Vorteil schrumpft

Beim Drafting, beim Verfassen einer Bescheidserwiderung oder einer Stellungnahme arbeiten wir mit Texten, die das Modell nicht kennen kann: einer Erfindungsmeldung, einem konkreten Anspruchssatz, einem konkret zitierten Stand-der-Technik-Dokument. Diese Inhalte stehen nicht im Trainingsdatensatz von ChatGPT oder Claude, sie sind neu.

Der vermeintliche Vorteil der Cloud-Modelle, breiteres Weltwissen und vielseitigere Reasoning-Fähigkeiten, läuft in dieser Aufgabenklasse weitgehend leer. Was tatsächlich zählt, ist die Qualität des Kontextes — bei der Erfindungsmeldung etwa, ob die Erfindung klar und ausführbar beschrieben ist und ob Vorteile, technische Effekte und Unterscheidungsmerkmale gegenüber dem Stand der Technik deutlich werden — und das Context Engineering, also die Disziplin, dem Modell genau diesen Kontext und nicht mehr in den Prompt zu geben. Das ist Aufgabe der Praktikerin oder des Praktikers, nicht des Modells. Und sie ändert sich nicht, wenn man von Cloud auf lokal wechselt.

Zwei Hardware-Pfade

Beide Pfade kommen mit einer vierstelligen Einmal-Investition aus.

Welcher Pfad besser passt, hängt davon ab, ob ein zweites Modell oder die nächste Modellgeneration bereits eingeplant werden soll. Eine Workstation mit RTX 4090 trägt die heute relevanten Modelle souverän; die DGX Spark gibt mehr Kopffreiheit nach oben.

Software-Stack

Auf der Hardware läuft ein Inference-Framework, das die Modelldateien lädt, an die Hardware anpasst und eine API bereitstellt. Drei Frameworks sind in der Praxis sinnvoll: Ollama (leichtgewichtig, ideal zur Automatisierung), LM Studio (grafische Oberfläche, gut für den Einstieg) und Msty (mit RAG-Funktion „Ask your data").

Das eigentliche Sprachmodell wird separat heruntergeladen. Empfehlenswert sind:

• Gemma 4 (26B) — eine gut ausgewogene Variante für den lokalen Einsatz. Apache-2.0-Lizenz inklusive Patentgrant, also ohne lizenzrechtliches Risiko für Patentarbeit.
• Qwen 3 in passender Größe — strukturierter Text, solider Allrounder.

Für die Office-Integration (Word und Excel direkt mit dem lokalen Modell verbinden) gibt es eine kleine Python-Bridge mit FastAPI, beschrieben im Wissens-Artikel Office + KI Integration.

Wer eigene Dokumentenbestände durchsuchbar machen will, etwa Hausbestände an Vorbescheiden oder eigene Mandantsakten, nutzt RAG mit ChromaDB und Ollama; die Bauanleitung steht im RAG Workshop Guide.

Schritt für Schritt durch die Installation aller Komponenten führt das Workshop-Modul Lokale KI, mit Installations-Videos für Ollama und LM Studio sowie einer kuratierten Modell-Auswahl je nach verfügbarer Hardware.

Was zusätzlich nötig bleibt

Lokale Modelle halluzinieren wie Cloud-Modelle. Auch in einer geschlossenen Umgebung ohne Cloud-Risiko bleibt die Belegpflicht ein nicht verhandelbarer Bestandteil jedes Workflows: jede Aussage des Modells gehört mit wörtlichem Zitat und Fundstelle aus der zugrunde liegenden Quelle abgesichert.

Hinzu kommt: lokale Modelle reagieren auf Prompts strenger als Cloud-Modelle. Vage Anweisungen werden ignoriert oder fehlinterpretiert. Wer mit Gemma 4 oder Qwen 3 arbeitet, formuliert Pfade explizit als WENN-DANN-Regeln, gibt Few-Shot-Beispiele und definiert Output-Templates wörtlich. Die Patterns dafür sind im Wissens-Artikel Prompt Engineering für lokale LLMs zusammengetragen.

Die KI in den Werkzeugen, die schon laufen

Ein lokales Modell schließt nur eine von mehreren Türen, durch die Mandatsdaten nach außen gelangen. Vertrauliche Inhalte erreichen ein Cloud-Modell oft, ohne dass jemand das bewusst entschieden hätte. Eingebettete Assistenten sind der häufigste Weg: Copilot in Microsoft 365, Gemini in Google Workspace, der Zoom AI Companion in Besprechungen. Sie sind oft vorab aktiviert oder einen Klick entfernt, und jeder von ihnen kann Dokument- oder Besprechungsinhalte an ein externes Modell senden, zu Bedingungen, die niemand geprüft hat. Die lokale Workstation hilft nicht, wenn dieselbe Anmeldung nebenher durch Copilot in Word läuft.

Der zweite, leisere Weg ist die Memory-Funktion. Chat-Werkzeuge merken sich zunehmend frühere Unterhaltungen und ziehen sie als Kontext heran. Was vergangene Woche für Mandant A eingegeben wurde, kann auftauchen, während für Mandant B formuliert wird: eine mandatsübergreifende Vermischung, die der Lokal-oder-Cloud-Entscheidungsbaum nicht erfasst, weil sie innerhalb eines einzigen Werkzeugs über die Zeit entsteht.

Praktisch heißt das: einmal durchgehen, welche vorhandenen Werkzeuge KI-Funktionen mitbringen und zu welchen Bedingungen, und dann bewusst entscheiden, was bleibt, was abgeschaltet und was für Mandatsarbeit getrennt wird (eigenes Profil oder Konto). Für vertrauliche Arbeit die Memory-Funktion ausschalten oder einen frischen, temporären Chat nutzen, dieselbe Hygiene wie beim Context Engineering, wo es ebenfalls darum geht, genau zu steuern, was das Modell zu sehen bekommt.

Erste 30 Minuten

Wer einen ersten Eindruck holen will, ohne gleich zu investieren, fängt mit einem normalen Office-Laptop und einem kleinen Modell wie Gemma 3n (E4B) an. Damit lassen sich die Patterns aus dem Prompt-Engineering-Artikel ausprobieren, die Antwortqualität ist begrenzt, aber das Verhalten der lokalen Modelle wird erfahrbar. Für die volle Drafting-Qualität rentiert sich der Schritt zur Workstation.

Schritt für Schritt durch die Installation führt das Workshop-Modul Lokale KI. In einer halben Stunde steht der Einstieg.