Lokales LLM in Kanzlei einsetzen – Vorteile und Praxistipps

Lokales LLM in Kanzlei einsetzen – Vorteile und Praxistipps14 min LesezeitLDT-DEPLAW

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. 

Das Wichtigste in Kürze

  • 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.

01

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.

„Lokale KI ist nicht die abgespeckte Variante für Datenschutzbewusste — sie ist für definierte Aufgaben die technisch überlegene Wahl, weil sie Kontrolle, Kontinuität und Kostensicherheit vereint.“
§ 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

02

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. 

03

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.

04

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.

01
Anforderungsanalyse und Use-Case-Priorisierung
Definieren Sie konkret, welche Aufgaben das lokale LLM übernehmen soll: Datenextraktion aus Schriftsätzen, Dokumentklassifikation, Vollständigkeitsprüfungen, Zusammenfassungen. Priorisieren Sie nach Volumen und Datensensibilität. Hochvolumige, sensible Aufgaben sind ideale Einstiegspunkte.
02
Hardware-Entscheidung und Beschaffung
Wählen Sie die passende Hardware auf Basis des erwarteten Verarbeitungsvolumens und der Modellgröße. Für die meisten Kanzleien mit bis zu 50 parallelen Nutzern ist ein NVIDIA DGX Spark oder ein Server mit 2× A100 80GB ein geeigneter Einstieg. Planen Sie VRAM-Reserven für zukünftige Modellgenerationen ein.
03
Setup und Modellinstallation mit Fachunterstützung
Installieren Sie ein Inference-Framework (Ollama, vLLM) und laden Sie die gewünschten Modelle. In diesem Schritt ist in der Regel einmalige externe Unterstützung sinnvoll. Das Setup umfasst auch Netzwerksicherheit, Zugriffskontrolle und Monitoring-Konfiguration. Nach Abschluss läuft das System autonom.
04
Aufbau des kanzleieigenen Datenlayers (RAG)
Strukturieren Sie Ihre internen Wissensdaten: eigene Urteils-Datenbanken, Musterformulierungen, Prüfschemata, mandatsspezifische Glossare. Verbinden Sie diese über ein Vektordatenbank-System (z. B. Qdrant, Weaviate) mit dem lokalen Modell. Dieser Datenlayer wächst mit jeder neuen Akte und wird zu einem dauerhaften Wettbewerbsvorteil.
05
Integration in DEPLAW und Workflow-Orchestrierung
Binden Sie das lokale LLM über die DEPLAW-Plattform in bestehende Automatisierungsworkflows ein. DEPLAW ermöglicht die parallele Orchestrierung mehrerer Modelle: Das lokale LLM übernimmt Extraktion und sensible Schritte, ein extern angebundenes Modell optionaler Weise einzelne Schriftsatzentwürfe auf Basis bereits extrahierter, anonymisierter Daten.
06
Qualitätssicherung, Fine-Tuning und kontinuierliche Optimierung
Etablieren Sie einen strukturierten Review-Prozess für KI-Outputs in der Anfangsphase. Nutzen Sie validierte Ergebnisse als Trainingsgrundlage für späteres Fine-Tuning. Messen Sie Qualität und Durchsatz über DEPLAW-Reports und passen Sie Modellauswahl und Prompt-Logik kontinuierlich an.

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.

05

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.

„Brot und Butter sowie jedes hochsensible Mandat gehören auf das lokale System. Für den finalen Schriftsatz auf Basis sauber extrahierter Daten kann ein externes Modell hinzugezogen werden — kontrolliert, restriktiv konfiguriert, ohne Rohdaten.“
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.

Empfehlung für Kanzleiinhaber

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.

LD
Tim Platner
Geschäftsführer, Legal Data Technology GmbH
Die Legal Data Technology GmbH entwickelt DEPLAW, eine Legal Tech Plattform für die End-to-End-Automatisierung von Kanzlei- und Rechtsabteilungsprozessen. Schwerpunkte: Massenverfahren, Großmandate, KI-Orchestrierung und datenschutzkonforme Legal-AI-Architekturen im DACH-Raum.

„`

Produkt-Highlights
BPMN Workflow Editor Legal Tech
DEPLAW Workflow Editor

Modellieren Sie Ihre Legal-Prozesse visuell – vollständig automatisierbar, ohne Code. 

Überblick

Kategorien