Cloudbasierte Lösungen dominieren das Angebot an KI-Anwendungen für Kanzleien. Daneben hat sich mit der lokalen KI ein zweiter Ansatz etabliert, der in Aufbau und rechtlicher Bewertung vom Cloud-Modell abweicht. Hier findet die KI-Verarbeitung nicht auf den Servern eines externen Anbieters statt, sondern auf Hardware, die der Kanzlei unmittelbar zur Verfügung steht – auf Rechnern am Arbeitsplatz oder kanzleieigenen Servern.

Der Beitrag „Cloud-Software für Kanzleien: Der technische Aufbau im Überblick" beschreibt den technischen Aufbau cloudbasierter Systeme. Der vorliegende Text bildet dazu das Pendant: Er behandelt die technische Architektur lokaler Legal-KI, ihre Bereitstellungsvarianten und ihre rechtliche Einordnung.

Definition: Lokale Inferenz als Kernmerkmal

Was ist lokale KI? Unter lokaler KI versteht man KI-Systeme, bei denen die Generierung einer KI-Antwort auf der eigenen Hardware des Nutzers oder der Kanzlei ausgeführt wird. Das KI-Modell liegt lokal vor, Eingabedaten verlassen das eigene Gerät nicht, und die Ausgabe wird ohne Rückgriff auf externe Rechenkapazität erzeugt. Gegenüber verwandten Modellen lässt sich lokale KI wie folgt abgrenzen:

• Cloud-KI: Modell und Inferenz liegen beim Anbieter. Eingaben werden über das Internet übertragen, dort verarbeitet und die Antwort zurückgesendet.

• Hybrid-KI: Teile der KI-Verarbeitung erfolgen lokal, andere in der Cloud. Die konkrete Aufteilung variiert von Anbieter zu Anbieter stark.

• Lokale KI: Die KI-Inferenz findet vollständig auf lokaler Hardware statt. Inhaltsdaten werden nicht an externe Dienste übertragen.

Die Kernmerkmale lokaler KI

Lokale KI lässt sich durch fünf charakteristische Eigenschaften beschreiben:

1. Lokale Inferenz: Die vollständige Generierung erfolgt auf Prozessor (CPU) oder Grafikkarte (GPU) der lokalen Hardware.

2. Offline-Fähigkeit: Für den eigentlichen KI-Betrieb ist keine Internetverbindung erforderlich. Eine Verbindung wird nur für Authentifizierung, Lizenzprüfung und Updates benötigt.

3. Hardware-gebundene Leistung: Die verfügbare Rechenleistung ist durch die lokale Hardware begrenzt. Eine elastische Skalierung wie in der Cloud, bei der Rechenkapazität innerhalb von Sekunden zu- oder abgeschaltet wird, entfällt; eine planbare Erweiterung durch zusätzliche Computer oder Server-Hardware bleibt möglich.

4. Single-Tenancy: Jede Installation betreibt eine eigene Instanz des Modells. Kein geteilter Ressourcenpool, keine gemeinsame Infrastruktur mit anderen Kanzleien.

5. Datenlokalität: Alle verarbeiteten Inhalte – Mandatsdaten, Dokumente, Zwischenergebnisse, Chatverläufe – verbleiben ausschließlich auf dem eigenen Gerät bzw. im eigenen Netzwerk.

Besonders die Merkmale 3 bis 5 unterscheiden lokale KI strukturell von Cloud-KI und prägen ihre datenschutzrechtliche, berufsrechtliche und praktische Einordnung.

Die zwei Deployment-Varianten lokaler Legal-KI

Lokale KI lässt sich auf zwei grundsätzlich unterschiedliche Weisen bereitstellen. Beide Varianten teilen die oben genannten Kernmerkmale. Das entscheidende Unterscheidungsmerkmal liegt nicht in der Hardware, sondern im Nutzungsmuster: Wird das KI-Modell von einer einzelnen Person auf ihrem eigenen Gerät betrieben (On-Device), oder greifen mehrere Nutzer über das Kanzleinetz auf einen zentralen Server oder Rechner zu (On-Premise)?

On-Device: Lokal auf dem Arbeitsplatzrechner

Bei der On-Device-Variante wird das KI-Modell direkt auf dem Arbeitsplatzrechner der Nutzerin oder des Nutzers installiert und betrieben. Die Software läuft wie eine gewöhnliche Desktop-Anwendung; die KI-Inferenz erfolgt auf dem Prozessor (CPU), der Grafikkarte (GPU) oder einer dedizierten KI-Recheneinheit (NPU) des Endgeräts.

Typische Rahmenbedingungen:

• Hardware: moderne Kanzleirechner mit 16 GB RAM (Arbeitsspeicher) oder mehr, Windows 11 oder macOS

• Modellgrößen: typischerweise zwischen drei und vierzehn Milliarden Parametern in komprimierter Form; auf leistungsstarken Rechnern (insbesondere Apple Silicon) sind auch deutlich größere Modelle lauffähig

• Installation: lokal pro Arbeitsplatz, Lizenzverwaltung über zentrales Konto

• Verantwortung: IT-Administration und Backup-Konzept verbleiben beim Einzelnutzer bzw. der Kanzlei, ohne dass zentrale Server-Infrastruktur erforderlich ist

On-Device-Architekturen eignen sich insbesondere für Kanzleien, die ohne zusätzliche Infrastruktur die vollständige Kontrolle über Mandatsdaten behalten möchten.

On-Premise: Lokal auf dem Kanzleiserver

Bei der On-Premise-Variante läuft das KI-Modell auf einem zentralen Rechner in der Kanzlei – sei es ein dedizierter Server oder ein leistungsstarker Arbeitsplatzrechner, der diese Rolle übernimmt. Die Arbeitsplatzrechner der Nutzerinnen und Nutzer fungieren als Clients (Endgeräte, die auf den zentralen Rechner zugreifen) und senden über das Kanzleinetz Anfragen an diesen. Die KI-Inferenz erfolgt zentralisiert auf der leistungsfähigeren Hardware.

Typische Rahmenbedingungen:

• Hardware: GPU-Server mit hoher VRAM-Ausstattung (Grafikspeicher), zum Beispiel NVIDIA RTX 6000 Ada, oder leistungsfähige Apple-Silicon-Workstations

• Modellgrößen: 30 bis 70 Milliarden Parameter oder mehr, mit entsprechend höherer Qualität der Ergebnisse

• Installation: zentral auf dem Kanzleiserver, mehrere Clients greifen parallel zu

• Verantwortung: zentrale IT-Verwaltung, serverseitige Backups, gemeinsame Wissensbasis möglich

On-Premise-Architekturen kommen insbesondere für Kanzleien in Betracht, die leistungsstärkere Modelle einsetzen möchten oder eine teamübergreifend geteilte Wissensbasis benötigen. Beide Varianten werden am Markt teilweise vom selben Anbieter in unterschiedlichen Leistungsstufen angeboten, sodass Kanzleien je nach Bedarf die passende Bereitstellungsform wählen können. Die Grenzen zwischen den Varianten sind dabei fließend. Die Leistungsfähigkeit moderner Hardware – insbesondere von Chipsätzen mit großem Arbeitsspeicher wie Apple Silicon – steigt kontinuierlich, während die Kosten sinken. Ein einzelnes Gerät kann heute sowohl als leistungsstarker Einzelarbeitsplatz (On-Device) als auch als lokaler KI-Server für mehrere Nutzer (On-Premise) dienen. Was vor wenigen Jahren eine spezialisierte Serverinfrastruktur erforderte, ist zunehmend mit handelsüblicher Hardware realisierbar.

Der technische Aufbau lokaler Legal-KI

Auch lokale KI-Anwendungen folgen einer mehrstufigen Architektur. Die konkreten Umsetzungen variieren je nach Anbieter, die zentralen Ebenen sind jedoch vergleichbar.

Die Modell-Ebene: Das komprimierte Sprachmodell

Das Herzstück jeder KI-Anwendung ist das Sprachmodell selbst – ein sogenanntes Large Language Model (LLM), das anhand umfangreicher Textmengen darauf trainiert wurde, Sprache zu verstehen und zu erzeugen. Damit solche Modelle außerhalb eines spezialisierten Rechenzentrums betrieben werden können, setzen Anbieter an drei Stellschrauben an: der Modellgröße, der numerischen Präzision der gespeicherten Parameter und der auf die Zielhardware abgestimmten Laufzeitumgebung.

Modellgröße: Die Leistungsfähigkeit eines LLM korreliert grob mit der Anzahl seiner Parameter. Cloud-Anbieter betreiben Modelle mit hunderten Milliarden Parametern. Lokal ausführbare Modelle bewegen sich typischerweise zwischen drei Milliarden Parametern (für leichte Endgeräte) und siebzig Milliarden Parametern (auf leistungsstarken Servern). Innerhalb dieser Spanne wählen Anbieter ihre Modelle passend zur Zielhardware.

Quantisierung: Bei der Quantisierung werden die Parameter eines Modells mit geringerer Genauigkeit gespeichert – vereinfacht: Statt jeden Wert sehr präzise abzulegen, genügt eine gröbere Darstellung. Das spart erheblich Speicher. Ein Modell mit sieben Milliarden Parametern benötigt so nur noch etwa vier statt rund vierzehn Gigabyte Arbeitsspeicher. Die Antwortqualität bleibt dabei in der Regel weitgehend erhalten. Dadurch lassen sich Modelle auf handelsüblicher Hardware ausführen, die sonst spezielle Rechenzentren erfordern würden.

Inference-Runtime: Die Ausführung des quantisierten Modells übernimmt eine spezialisierte Laufzeitumgebung. Diese nutzt hardware-spezifische Optimierungen – etwa für den jeweiligen Prozessor- oder Grafikkartentyp –, um auch auf handelsüblichen Rechnern akzeptable Geschwindigkeiten zu erreichen.

Token-Metrik: Sprachmodelle verarbeiten Text nicht zeichen- oder wortweise, sondern in sogenannten Tokens. Ein vorgeschalteter Tokenizer zerlegt den Eingabetext in diese Einheiten und überführt sie in Zahlen, mit denen das Modell rechnet. Ein Token kann ein ganzes Wort, ein Wortteil oder ein einzelnes Zeichen sein – die konkrete Zerlegung hängt vom jeweiligen Tokenizer und von der Sprache ab. Im Englischen entspricht ein Token im Durchschnitt etwa drei bis vier Zeichen; bei deutschen Texten fällt der Wert tendenziell niedriger aus, weil Komposita und Flexionsformen häufig in mehrere Tokens zerlegt werden. Die Menge der verarbeiteten Tokens bestimmt den Rechenaufwand, das nutzbare Kontextfenster und dient bei kostenpflichtigen Tarifen als Abrechnungseinheit.

Bei lokaler KI werden Tokens lokal gezählt; übertragen wird an den Anbieter lediglich die numerische Summe, nicht die verarbeiteten Inhalte. Die Token-Metrik selbst ist damit keine vertraulichkeitsrelevante Information.

Die Anwendungs-Ebene: Desktop-Software und Clients

Über dem Modell liegt die Anwendung selbst. Ihre Ausprägung unterscheidet sich je nach Deployment-Variante.

Bei On-Device-Installationen handelt es sich in der Regel um eine native Desktop-App für Windows und macOS. Diese übernimmt Benutzeroberfläche, Dokumenten- und Chatverwaltung sowie die Kommunikation mit der lokalen Inference-Runtime. Technisch werden solche Anwendungen häufig plattformübergreifend umgesetzt oder als native Frameworks implementiert.

Bei On-Premise-Installationen teilt sich die Anwendung in einen Client auf den Arbeitsplatzrechnern und einen Server-Dienst, der das Modell betreibt und Anfragen mehrerer Clients parallel bearbeitet. Die Kommunikation erfolgt über das interne Kanzleinetz, typischerweise über eine abgesicherte HTTP- oder gRPC-Schnittstelle (interne Netzwerkverbindung).

In beiden Varianten ist die Anwendungs-Ebene auch für die lokale Token-Zählung und -Durchsetzung verantwortlich: Erreicht ein Nutzer sein vertraglich vereinbartes Kontingent, sperrt die Anwendung weitere Anfragen oder weist auf die Kontingentüberschreitung hin – ohne dass der Anbieter in die Inhalte der Anfragen Einblick hat.

Die Datenschicht: Dokumente, Wissensbasis, Verläufe

Bei Cloud-KI liegen Dokumente, Chatverläufe und abgeleitete Metadaten auf Servern des Anbieters. Bei lokaler KI verbleiben diese Daten ausschließlich auf dem eigenen Gerät bzw. im eigenen Netzwerk.

Dokumentenverarbeitung: Eingabedokumente (PDF, DOCX, E-Mails) werden lokal eingelesen, in Text konvertiert und – falls erforderlich – per OCR (optische Texterkennung) aufbereitet. Hierfür kommen etablierte Software-Bibliotheken zum Einsatz. Die extrahierten Inhalte werden an das lokale Modell übergeben, ohne den Verarbeitungsraum zu verlassen.

Retrieval Augmented Generation (RAG): Moderne Legal-KI arbeitet häufig mit RAG – einem Verfahren, bei dem relevante Textpassagen aus einer Wissensbasis (Mandatsakten, Musterverträge, interne Dokumentation) vor der Modellanfrage gezielt herausgesucht und dem Modell als Kontext mitgegeben werden. Bei lokaler KI liegt diese Wissensbasis vollständig lokal vor, typischerweise als Vektor-Datenbank. Die für RAG notwendigen Einbettungen werden ebenfalls lokal erzeugt.

Chatverläufe und Session-Daten: Alle Interaktionen mit dem Modell werden lokal gespeichert und sind nur dem jeweiligen Nutzer bzw. den im Kanzleinetz berechtigten Nutzern zugänglich.

Mehrnutzer-Szenarien:

• On-Device: Jede Installation betreibt isolierte Daten. Gemeinsame Dokumente müssen über etablierte Kanäle (Dokumenten-Management-System, Kanzleinetz) bereitgestellt werden.

• On-Premise: Eine gemeinsame, zentral auf dem Kanzleiserver gepflegte Wissensbasis ist ohne Weiteres möglich, da alle Clients auf denselben Server zugreifen.

Die Cloud-Kontoverwaltung: Minimaler Serveranteil

Bei kommerziellen Anbietern lokaler KI ist in der Regel eine minimale Cloud-Anbindung für Authentifizierung, Lizenzverwaltung und Software-Updates erforderlich – wie bei jeder lizenzpflichtigen Desktop-Software. Dieser Serveranteil ist funktional scharf von der inhaltlichen KI-Verarbeitung getrennt.

Über die Cloud-Kontoverwaltung werden in der Regel übertragen:

• Kontodaten: E-Mail-Adresse, Unternehmens-/Kanzleiname, verschlüsselt gespeichertes Passwort

• Lizenzinformationen: gebuchter Tarif, Nutzerlizenzen, Vertragslaufzeit

• Abrechnungsdaten: Token-Verbrauch als numerische Zählwerte (ohne Inhaltsbezug), Rechnungen

• Update-Metadaten: installierte Version, Verfügbarkeit neuer Software- und Modell-Versionen

Nicht über die Cloud-Kontoverwaltung übertragen werden: Mandatsdaten, Dokumente, Prompts, KI-Antworten, Chatverläufe, Zwischenergebnisse. Für diese gilt: Die inhaltliche Verarbeitung findet ausschließlich lokal statt. Dass ein minimaler Serveranteil besteht, ist architektonisch kein Bruch mit dem Lokalitätsprinzip, sondern notwendige Infrastruktur für Vertragsabwicklung und Softwarepflege – ähnlich wie bei Adobe, Microsoft Office oder jeder anderen lizenzpflichtigen Desktop-Software.

Die Hardware-Ebene: CPU, GPU, NPU, Server

Die Leistungsfähigkeit lokaler KI wird durch die konkret eingesetzte Hardware bestimmt.

CPU (Prozessor): Die Ausführung quantisierter Modelle auf modernen Desktop-CPUs ist möglich, liefert jedoch typischerweise nur wenige Tokens pro Sekunde. Für interaktive Anwendungen mit kleineren Modellen ausreichend, aber deutlich langsamer als GPU-basierte Inferenz.

GPU: Dedizierte Grafikkarten (NVIDIA, AMD) beschleunigen die Modell-Inferenz erheblich. Auch die in moderne Chipsätze integrierten Grafikeinheiten – insbesondere die GPU-Kerne der Apple-M-Serie sowie die Arc-Grafik in Intel Core Ultra – eignen sich inzwischen für Modelle mit sieben bis dreizehn Milliarden Parametern.

NPU (Neural Processing Unit): Speziell für KI-Inferenz entwickelte Recheneinheiten, verbaut etwa in Apple-Silicon-Chips, in AMD Ryzen AI und in Intel Core Ultra. Sie arbeiten besonders energieeffizient. Bei der Ausführung größerer Sprachmodelle spielen NPUs in den heute gängigen lokalen Laufzeitumgebungen allerdings noch eine nachgeordnete Rolle: Die eigentliche Inferenzlast tragen derzeit überwiegend GPU-Kerne und schneller, gemeinsam genutzter Arbeitsspeicher (Unified Memory). Ihr Gewicht für die lokale KI-Verarbeitung dürfte mit der weiteren Entwicklung der Modelle und Runtimes zunehmen.

Server-GPUs (für On-Premise): Professionelle Beschleuniger wie NVIDIA RTX 6000 Ada oder mehrere parallel geschaltete Mac Studio mit M-Chips ermöglichen den Betrieb deutlich größerer Modelle und die parallele Bearbeitung von Anfragen mehrerer Nutzer.

RAM/VRAM: Der wichtigste limitierende Faktor. 16 GB RAM – heute Standard bei Neugeräten – gelten als praktischer Mindeststandard für quantisierte Modelle mit sieben Milliarden Parametern; 32 GB oder mehr erlauben den Einsatz leistungsfähigerer Modelle. On-Premise-Server verfügen üblicherweise über 48 bis 192 GB VRAM, um auch die größten lokal betreibbaren Modelle ausführen zu können.

Für Kanzleien bedeutet das: Der Einsatz lokaler KI erfordert Investitionen in geeignete Hardware – entweder am Rechner oder zentral auf einem Kanzleiserver. Die Investition skaliert planbar mit der Nutzerzahl bzw. der gewünschten Modellgröße, ohne die Komplexität eines eigenen Rechenzentrums zu erreichen.

Die Integrationsebene: Schnittstellen zum Kanzleialltag

Die lokale Architektur ermöglicht grundsätzlich die Einbindung in bestehende Arbeitsabläufe. Welche Integrationspunkte ein Anbieter tatsächlich umsetzt, variiert – die Architektur selbst setzt jedoch keine strukturellen Grenzen. Denkbare und teilweise bereits verfügbare Integrationspunkte sind:

• Textverarbeitung: Add-ins für Microsoft Word, die Dokumente direkt an die lokale KI übergeben und Ergebnisse einfügen

• E-Mail: Outlook-Integrationen zum Analysieren oder Verfassen von Nachrichten

• Dateisystem und DMS: direkter Zugriff auf lokale Dokumentenablagen oder Dokumenten-Management-Systeme, ohne Upload in externe Dienste

• Kanzleisoftware: Anbindung an Fristen- oder Aktenverwaltung über lokale Schnittstellen

Da solche Integrationen lokal stattfinden, entstehen auch hier keine zusätzlichen Datenabflüsse zu Dritten. Bei On-Premise-Installationen erfolgt die Integration zusätzlich im Kanzleinetz und lässt sich in bestehende Netzwerk- und Sicherheitskonzepte einbetten.

Besonderheiten für Legal-KI

Die lokale Architektur bringt spezifische Eigenschaften mit sich, die für juristische Anwendungsfälle besonders relevant sind.

Aktualität des Modellwissens

Rechtsprechung und Gesetzgebung ändern sich fortlaufend. Während cloudbasierte Systeme Modelle und Wissensbasis kontinuierlich aktualisieren können, erfolgt die Aktualisierung bei lokaler KI über Modell-Updates, die in regelmäßigen Abständen eingespielt werden.

In der Praxis bedeutet das: Lokale Legal-KI ersetzt keine juristische Rechercheplattform mit Live-Zugriff auf tagesaktuelle Rechtsprechung. Ihre Stärke liegt in der Verarbeitung der vor Ort vorliegenden Dokumente und Mandatsakten. Die Aktualität des Modellwissens hängt davon ab, wie regelmäßig der Anbieter aktualisierte Modelle bereitstellt. Darüber hinaus können Kanzleien aktuelle Primärquellen – etwa neue Urteile, Gesetzesänderungen oder eigene Dokumente – über RAG in die lokale Wissensbasis einpflegen und so den Aktualitätsstand gezielt selbst steuern. Ergänzend bleibt der Nutzer auf eigene Recherchequellen (beck-online, juris, Gesetzestexte) angewiesen.

Halluzinationskontrolle durch RAG

Sprachmodelle neigen dazu, plausibel klingende, aber inhaltlich unrichtige Aussagen zu erzeugen – sogenannte Halluzinationen. In der juristischen Anwendung sind erfundene Paragrafenzitate oder nicht existierende Urteile ein bekanntes Problem.

Lokale KI begegnet diesem Problem primär über RAG: Die Antworten basieren auf den konkret bereitgestellten Dokumenten, deren Passagen das Modell zitieren kann. Die Antwortgenerierung wird damit an nachvollziehbaren Textstellen verankert, statt frei aus dem Modellwissen zu schöpfen. Im Zweifel lässt sich die Antwort anhand der verknüpften Originalpassage überprüfen. RAG reduziert das Risiko erfundener Aussagen erheblich, schließt es aber nicht vollständig aus – das Modell kann Quellen auch bei vorhandenem Kontext fehlinterpretieren oder verkürzt zusammenfassen. Die eigenverantwortliche juristische Prüfung durch die Anwältin oder den Anwalt bleibt unabhängig davon unverzichtbar.

Rechtliche Einordnung

Datenschutzrechtlich

Da bei lokaler KI keine Mandatsinhalte an den Anbieter übertragen werden, entfällt die Konstellation der Auftragsverarbeitung nach Art. 28 DSGVO für die eigentlichen Inhaltsdaten. Soweit der Anbieter Kontodaten für eigene Zwecke – etwa Abrechnung oder Lizenzmanagement – verarbeitet, handelt er insoweit als eigenständig Verantwortlicher nach Art. 4 Nr. 7 DSGVO.

Für Kanzleien vereinfacht dies die Prüfpflicht in mehreren Punkten:

• Kein Auftragsverarbeitungsvertrag für die Inhaltsverarbeitung erforderlich

• Kein Subunternehmer-Mapping für KI-Inferenz-Dienste

• Kein Drittstaatentransfer der Mandatsdaten durch die KI-Verarbeitung; für die verbleibenden Kontodaten gelten die üblichen Transfermechanismen, sofern der Anbieter Infrastruktur außerhalb der EU einsetzt

• Reduzierte technisch-organisatorische Prüfmatrix, da die inhaltliche Verarbeitung in der bereits kontrollierten Kanzleiumgebung stattfindet

Diese Entlastung gilt allerdings nur, soweit das Produkt über die Konto- und Lizenzverwaltung hinaus keine Inhaltsdaten überträgt. Die Prüfpflichten verschwinden damit nicht, sondern verlagern sich von der Anbieter-Due-Diligence auf die eigene IT-Umgebung der Kanzlei – insbesondere auf Endgerätesicherheit, Berechtigungsmanagement und Backup-Konzepte.

Berufsrechtlich

Die anwaltliche Verschwiegenheitspflicht nach § 43a BRAO setzt voraus, dass Mandatsgeheimnisse nicht unbefugten Dritten zugänglich werden. Bei lokaler KI findet keine Weitergabe von Mandatsinhalten an den Anbieter oder sonstige Dritte statt. § 43e BRAO, der die Einschaltung von Dienstleistern unter Offenbarung fremder Geheimnisse regelt, dürfte für die inhaltliche Verarbeitung der Mandatsdaten daher nicht einschlägig sein. Für die verbleibenden Berührungspunkte mit dem Anbieter – Bereitstellung der Software, Lizenz- und Kontoverwaltung – gelten die üblichen Vertraulichkeits- und Auftragsverarbeitungsanforderungen.

Bei cloudbasierten Architekturen müssen Verschwiegenheits- und Datenschutzpflichten vertraglich entlang der gesamten Subunternehmer-Kette weitergegeben werden – vom Anbieter an dessen Unterauftragnehmer, von dort an weitere Beteiligte. Diese sogenannte flow-down-Problematik ist bei lokaler KI für die inhaltliche Verarbeitung strukturell nicht relevant, da keine Subunternehmer an der Datenverarbeitung beteiligt sind. Für den verbleibenden Serveranteil (Auth, Lizenzierung) gelten die üblichen Auftragsverarbeitungs- und Vertraulichkeitsanforderungen.

EU-KI-Verordnung

Seit dem 2. Februar 2025 gelten die ersten Pflichten der EU-KI-Verordnung. Kanzleien, die KI-Systeme einsetzen, sind regelmäßig als Betreiber im Sinne von Art. 3 Nr. 4 KI-VO einzuordnen. Zentrale Pflichten – insbesondere die KI-Kompetenz nach Art. 4 KI-VO sowie Dokumentations- und Transparenzpflichten – bestehen unabhängig davon, ob das eingesetzte KI-System lokal oder in der Cloud betrieben wird.

Bei lokaler KI ist der Nachweis einzelner Anforderungen jedoch strukturell vereinfacht. So ist etwa die Ausschlussgarantie, dass Mandatsdaten nicht zu Trainings- oder Weiterentwicklungszwecken verwendet werden, bei lokaler Architektur gegeben – ein Abfluss zu Trainingszwecken ist technisch ausgeschlossen, solange das Produkt über die Konto- und Lizenzverwaltung hinaus keine Inhaltsdaten überträgt.

Grenzen und Rahmenbedingungen

Lokale KI ist kein universelles Werkzeug. Ihre Grenzen liegen primär in drei Bereichen:

Leistungsfähigkeit der Modelle: Kleinere, auf Endgeräten lauffähige Modelle liegen qualitativ hinter den größten Cloud-Modellen zurück. Auf leistungsstärkerer Hardware lassen sich jedoch auch deutlich größere Modelle betreiben, die diesen Abstand deutlich verringern. Die Entwicklung lokaler KI-Modelle schreitet dabei kontinuierlich voran.

Hardware-Anforderungen und Investitionen: Lokale KI setzt geeignete Hardware voraus – am Arbeitsplatz für On-Device-Installationen, zentral für On-Premise-Setups. Diese Investitionen fallen planbar an, sind aber nicht zu vernachlässigen.

Integration externer Rechtsdatenbanken: Der Zugriff auf aktuelle Rechtsprechung oder kommerzielle Rechtsdatenbanken erfolgt in der Regel über Online-Plattformen. Eine nahtlose Einbindung in lokale KI erfordert gesonderte, kontrollierbare Schnittstellen.

Fazit

Lokale Legal-KI ist ein eigenständiger Ansatz mit klar umrissenen Eigenschaften. Sie zeichnet sich dadurch aus, dass die KI-Verarbeitung vollständig auf dem eigenen Gerät bzw. im eigenen Netzwerk erfolgt und Mandatsinhalte die Kanzlei nicht verlassen. Die beiden Deployment-Varianten – On-Device und On-Premise – decken unterschiedliche Anwendungsprofile und Leistungsanforderungen ab.

Die technische Bauweise lokaler KI ist inzwischen so weit gereift, dass sie auf Standard-Hardware praxistauglich ist. Quantisierte Modelle auf Consumer-Rechnern liefern für viele juristische Anwendungsfälle tragfähige Ergebnisse; On-Premise-Server ermöglichen auch den Einsatz deutlich leistungsfähigerer Modelle, wenn Kanzleien eine entsprechende IT-Umgebung betreiben möchten.

Welche Architektur – lokal oder cloudbasiert – für eine konkrete Kanzlei die passende Wahl ist, lässt sich nicht allgemein beantworten. Im folgenden Beitrag „KI-Tools für Kanzleien im Vergleich – Der Leitfaden zur richtigen Wahl" werden die am Markt verfügbaren KI-Assistenten entlang konkreter Kriterien verglichen und die architektonische Grundsatzentscheidung in eine praktische Auswahlentscheidung überführt.