DSGVO-konforme KI-Agenten lokal: llama.cpp, Ollama & LM Studio

Warum Ihre KI-Agenten nicht in die Cloud müssen

Autonome KI-Agenten durchsuchen Dokumente, beantworten Kundenanfragen, generieren Code und koordinieren Workflows über mehrere Schritte. Dabei verarbeiten sie fast immer personenbezogene Daten. Für Unternehmen in Deutschland, Österreich und der Schweiz steht damit vor jeder anderen Frage diese: Wie setzen wir Agenten ein, ohne gegen die DSGVO zu verstoßen?

Cloud-APIs wie die von OpenAI, Anthropic oder Google schicken die Daten auf US-Server. Das bedeutet Auftragsverarbeitungsverträge, Drittlandtransfer-Prüfungen und im schlimmsten Fall Bußgeldrisiko. Mehrere europäische Datenschutzbehörden haben Google Analytics bereits für nicht konform erklärt, KI-APIs dürften die nächste Prüfstelle sein.

Die Alternative ist ein lokales Setup: Modelle laufen auf Ihrer Hardware, Daten verlassen das Netzwerk nie, kein AVV nötig. Unser Stack sieht so aus: llama.cpp als Engine, Qwen 3.6 oder 3.8 als Modell, Unsloth fürs Finetuning und die Weboberfläche, die llama-server mitbringt. Ollama, LM Studio und Unsloth Studio ordnen wir weiter unten ein, mit Blick auf Datenschutz und Sicherheit.

Lokale Modelle sind keine Notlösung für Datenschutzfans. Für viele Agenten-Workloads sind sie die wirtschaftlich sinnvollere und rechtlich sauberere Wahl.

Was die DSGVO von KI-Agenten verlangt

Die rechtlichen Pflichten kommen zuerst. Für eine vollständige Beratung wenden Sie sich an Ihren Datenschutzbeauftragten.

Art. 6 DSGVO verlangt eine Rechtsgrundlage. Jede Verarbeitung personenbezogener Daten braucht einen rechtmäßigen Grund. Wenn Ihr Agent E-Mail-Adressen, Namen oder Vertragsdaten liest, muss dokumentiert sein, warum er das darf. Je nach Fall sind das Vertragserfüllung, berechtigtes Interesse oder Einwilligung.

Art. 5 Abs. 1c verlangt Datenminimierung. Ins Kontextfenster gehört nur, was die konkrete Anfrage braucht. Ein Agent, der alle Kundendaten lädt, um eine einzelne Frage zu beantworten, verstößt gegen dieses Prinzip. Die Lösung ist eine kontextbezogene Filterung, bevor etwas an das Modell geht.

Art. 35 verlangt eine Datenschutz-Folgenabschätzung. Neue Technologien mit hohem Risiko für betroffene Personen lösen eine DPIA aus. Agenten, die Profile bilden, automatisiert entscheiden oder neue Technik einsetzen, fallen fast immer darunter. Die DPIA ist damit ein Werkzeug für Dokumentation und Risikomanagement, kein Stoppschild.

Art. 17 verlangt Löschung auch im Agenten-Gedächtnis. Das Recht auf Vergessenwerden gilt nicht nur für Datenbanken, sondern auch für Vektorspeicher, Agenten-Logs und Konversationsverläufe. Fordert ein Kunde die Löschung, muss sie alle Agenten-Komponenten erreichen.

Art. 22 regelt automatisierte Entscheidungen. Trifft ein Agent Entscheidungen mit Rechtsfolge, ohne menschliche Intervention, gelten verschärfte Anforderungen: Ausnahmen, Garantien und ein Weg zur menschlichen Prüfung.

Der Papierkram bleibt überschaubar, wenn die Architektur ihn von Anfang an einplant. Lokale Modelle erledigen einen Teil davon mit, weil die Datenhoheit schon im Setup steckt.

Wenn Sie vor dem Launch einer Website ein paar Grundlagen abhaken wollen, hilft unsere DSGVO-Checkliste vor dem Launch weiter. Einige Punkte, jeder mit Prüfschritt.

llama.cpp: die Engine für lokale Modelle

llama.cpp ist eine Inferenz-Engine in C und C++, die Open-Source-Modelle im GGUF-Format auf CPU und GPU ausführt. Ollama und LM Studio bauen auf llama.cpp beziehungsweise dessen Bibliothek ggml auf.

Für die DSGVO zählt vor allem eins: das Modell läuft auf Ihrer Hardware, ein externer API-Aufruf fällt komplett weg. Dazu ist der Code Open Source und damit auditierbar, und das Deployment bleibt flexibel, egal ob Docker, Kubernetes oder bare Metal.

Der Schnelleinstieg in drei Schritten

llama.cpp bauen. Ein Clone und zwei cmake-Befehle, mehr braucht es nicht.

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release

Ein Modell laden und testen. llama-cli startet ein Modell direkt in der Konsole. Tragen Sie dort das Repository ein, aus dem Sie ein quantisiertes GGUF-Modell laden wollen, zum Beispiel ein von Unsloth veröffentlichtes Qwen 3.x.

./build/bin/llama-cli -hf <ihr-gguf-repo> -ngl 99 -p "Was ist der wichtigste DSGVO-Grundsatz?"

Den Server starten. llama-server macht das Modell für Agenten und für die Weboberfläche verfügbar. Wir binden ihn an 127.0.0.1 und schützen ihn mit einem API-Key. Wer den Server für andere Rechner öffnen will, stellt einen Reverse Proxy mit TLS und Authentifizierung davor, statt ihn direkt auf 0.0.0.0 zu legen.

./build/bin/llama-server -hf <ihr-gguf-repo> --port 8080 --host 127.0.0.1 --api-key <langer-zufallswert>

Die Weboberfläche von llama-server

Danach öffnen Sie http://localhost:8080 im Browser und landen in der eingebauten Oberfläche von llama-server. Sie können sofort chatten, ohne ein einziges Tool zu installieren. Die Oberfläche erlaubt es, Modelle zu wechseln und neue GGUF-Modelle aus dem Hugging-Face-Hub zu laden oder eigene hochzuladen. Neben dem Chat gibt es Ansichten zum Testen von Chat- und Completion-Anfragen sowie den Tokenizer.

Der praktische Nebeneffekt: Derselbe Server liefert unter der Haube die OpenAI-kompatiblen Endpunkte. Sie bedienen die Oberfläche im Browser für schnelle Tests, und Ihre Agenten sprechen dieselbe Adresse unter http://localhost:8080/v1/chat/completions an. Ein Setup, zwei Aufgaben.

llama-server ist kein Headless-Dienst mit optionalem Anhängsel. Die Weboberfläche gehört zum Lieferumfang und reicht für die tägliche Arbeit mit einem Agenten in vielen Fällen aus.

Qwen 3.6/3.8 mit Unsloth: unsere Empfehlung

Nicht jedes Modell beherrscht Deutsch. Für Agenten, die deutsche Texte verarbeiten, setzen wir auf Qwen 3.6 oder 3.8, kombiniert mit Unsloth. Unsloth ist eine Open-Source-Bibliothek, die das Finetuning und die Quantisierung von Modellen deutlich beschleunigt. Aus einem Basismodell wird in überschaubarer Zeit ein fein justiertes, quantisiertes GGUF für den llama-Server. Mit Unsloth Studio gibt es dafür inzwischen auch eine Weboberfläche, die wir im Vergleich weiter unten einordnen.

Ein angepasstes Modell passt auf Hardware, die auch neben einem Schreibtisch steht, weil Unsloth zusätzlich den Speicherbedarf senkt. Wer ein Modell auf eigenen Daten finetunt, holt mehr heraus als mit jeder noch so langen Prompt-Kette, und für deutsche Texte sind Qwen 3.6 und 3.8 eine starke Basis. Nach dem Finetuning exportiert Unsloth das Modell direkt ins GGUF-Format, das llama.cpp versteht, sodass der Weg von der Anpassung bis zur Produktion kurz bleibt.

Unser Standard für deutsche Agenten ist Qwen 3.6/3.8 mit Unsloth. Wenn Ihr Use-Case klein bleibt, reicht ein kompakteres deutsches Modell.

Was ist Ollama? Lokale KI mit einem Befehl

Ollama ist ein Open-Source-Tool unter MIT-Lizenz, das Sprachmodelle herunterlädt und auf dem eigenen Rechner ausführt, unter macOS, Windows und Linux. Ein Befehl genügt, um ein Modell zu laden und in der Konsole zu chatten:

ollama run <modell>

Dazu kommen eine Modellverwaltung, ein Hintergrunddienst und eine lokale REST-API, über die andere Programme das Modell ansprechen. Wer Ollama lokal betreibt, bekommt so in wenigen Minuten eine funktionierende lokale KI, und deshalb ist Ollama für viele der erste Kontakt mit dem Thema.

Technisch baut Ollama auf ggml auf, der Bibliothek hinter llama.cpp, und liest Modelle im GGUF-Format. Sie können also dieselben quantisierten Modelle nutzen wie mit llama.cpp, auch eigene GGUF-Dateien, etwa aus einem Unsloth-Finetuning. Der Unterschied liegt in der Bedienung: Ollama nimmt Ihnen Build, Modellsuche und Serverstart ab, llama.cpp gibt Ihnen dafür mehr Stellschrauben und eine eingebaute Weboberfläche.

Neuigkeiten zu Releases und neuen Modellen veröffentlicht das Projekt im Ollama-Blog. Hier geht es um die Frage, was davon für den Betrieb unter der DSGVO zählt.

Ollama und Datenschutz: lokal und in der Cloud

Ob Ollama datenschutzkonform ist, hängt vom Modus ab. Ollama bietet lokale Modelle und gehostete Cloud-Modelle unter demselben Dach an, und beide haben ein völlig anderes Risikoprofil.

Ollama lokal: keine Inhalte beim Anbieter

Laut Datenschutzerklärung von Ollama Inc. (Stand März 2026) erhebt und speichert der Anbieter bei lokalem Betrieb keine Prompts, Antworten oder sonstigen Inhalte, die Sie verarbeiten. Erfasst werden können begrenzte Geräte- und Nutzungsdaten wie die App-Version und die Zahl der Anfragen, aber keine Inhalte. Für die DSGVO heißt das: Personenbezogene Inhalte fließen bei lokalem Betrieb nicht an einen Dienstleister, ein AVV für die Inferenz entfällt.

Ihre Pflichten bleiben trotzdem bestehen. Rechtsgrundlage, Datenminimierung und Löschung in Logs und Konversationsverläufen gelten für lokale Agenten genauso.

Ollama Cloud: Datenschutz mit US-Bezug

Bei den Cloud-Modellen von Ollama läuft die Verarbeitung auf fremder Infrastruktur. Nach eigenen Angaben loggt Ollama Prompts und Antworten dort nicht und nutzt sie nicht zum Training. Hosting-Partner, laut Ollama NVIDIA Cloud Providers, müssen No-Logging, No-Training und Zero Data Retention zusichern. Gehostet wird überwiegend in den USA, bei Bedarf auch in Europa und Singapur.

Aus DSGVO-Sicht ist das trotzdem eine Auftragsverarbeitung bei einem US-Anbieter. Sie brauchen einen AVV nach Art. 28 und eine Prüfung des Drittlandtransfers, und den Hosting-Standort können Sie nicht festlegen. Zusicherungen auf einer Webseite ersetzen keinen Vertrag. Für Agenten mit personenbezogenen Daten bleiben wir deshalb bei lokalen Modellen.

Checkliste: Ollama datenschutzkonform betreiben

• Nur lokale Modelle einsetzen, solange personenbezogene Daten im Spiel sind, und vor dem Start prüfen, ob das gewählte Modell wirklich lokal läuft.
• Ollama an 127.0.0.1 gebunden lassen oder hinter einem Reverse Proxy mit Authentifizierung und TLS betreiben.
• Konversationsverläufe und Logs der Agenten in das Löschkonzept aufnehmen (Art. 17).
• Ollama aktuell halten, damit bekannte Sicherheitslücken geschlossen sind.
• Den Einsatz im Verarbeitungsverzeichnis und, wenn nötig, in der DPIA dokumentieren.

Ist Ollama sicher?

Lokal betrieben ist Ollama ein brauchbares Werkzeug. Riskant wird es durch die Konfiguration. Ollama bindet sich standardmäßig an 127.0.0.1, die REST-API hat aber keine eingebaute Authentifizierung. In vielen Anleitungen für Docker und Homelabs steht OLLAMA_HOST=0.0.0.0, und damit ist die API für jeden erreichbar, der die Adresse kennt.

Das passiert im großen Stil. Sicherheitsforscher zählten im Januar 2026 rund 175.000 öffentlich erreichbare Ollama-Instanzen in 130 Ländern. Im Mai 2026 machte die Lücke CVE-2026-7482 (“Bleeding Llama”, CVSS 9.1) Schlagzeilen, die Cyera Research gemeldet hatte. Über den GGUF-Loader konnte ein Angreifer ohne Anmeldung den Arbeitsspeicher eines erreichbaren Servers auslesen, samt Prompts, Konversationen, API-Keys und Umgebungsvariablen. Cyera schätzt die betroffenen Server auf etwa 300.000. Der Fix steckt in Ollama 0.17.1 vom 25. Februar 2026, die Release Notes wiesen ihn aber nicht als Sicherheitsupdate aus. Viele Betreiber haben deshalb nie aktualisiert.

Bei Agenten mit personenbezogenen Daten ist das mehr als ein IT-Problem. Ein Abfluss von Konversationen ist eine Datenpanne, die Sie nach Art. 33 innerhalb von 72 Stunden melden müssen, und Art. 32 verlangt angemessene technische Schutzmaßnahmen. Auch für den Windows-Updater von Ollama meldeten Forscher im Mai 2026 zwei weitere Lücken (CVE-2026-42248 und CVE-2026-42249), für die zu diesem Zeitpunkt noch kein Fix vorlag. Prüfen Sie den aktuellen Stand in den Release Notes.

Was hilft:

• Ollama auf die aktuelle Version bringen und automatische Updates im Blick behalten.
• Die API nie direkt ins Internet oder ins Gäste-WLAN stellen.
• Einen Reverse Proxy mit Authentifizierung und TLS davorsetzen und den Port per Firewall auf bekannte Clients beschränken.
• Zugriffe protokollieren, ohne Prompt-Inhalte in den Logs zu speichern.

Das gilt für jeden lokalen Inferenzserver, auch für llama-server. Dort schützen Sie den Zugriff mit --api-key, wie im Schnelleinstieg oben.

llama.cpp, Ollama, LM Studio und Unsloth Studio im Vergleich

Alle vier Tools führen Modelle lokal aus, und keines schickt Ihre Prompts an einen Anbieter. Sie unterscheiden sich in Lizenz, Bedienung, Server-Betrieb und darin, ob Sie Modelle auch trainieren können.

Ein paar Punkte zur Einordnung:

llama.cpp ist die Basis, auf der die anderen aufbauen. Sie bekommen die meisten Einstellmöglichkeiten und die kleinste Angriffsfläche, zahlen dafür mit etwas mehr Handarbeit beim Setup.

Ollama ist der schnellste Weg zu einem laufenden Modell. Der Preis ist die offene API ohne Authentifizierung und die Nähe zu den Cloud-Modellen, die Sie für personenbezogene Daten meiden sollten.

LM Studio ist die bequemste Oberfläche und seit Juli 2025 auch für geschäftliche Nutzung kostenlos. Der Quellcode der App ist nicht einsehbar, was bei Unternehmen mit Pflicht zur Quellcodeprüfung ein Ausschlusskriterium sein kann. Für Server ohne Bildschirm gibt es mit llmster einen eigenen Daemon.

Unsloth Studio deckt als einziges der vier auch das Training ab und exportiert nach GGUF. Die Oberfläche steht unter AGPL-3.0. Für den internen Betrieb ist das meist unkritisch, wer sie verändert und Dritten als Dienst anbietet, sollte die Lizenz prüfen (kein Rechtsrat).

Unsere Empfehlung: trainieren mit Unsloth, betreiben mit llama.cpp

Wir kombinieren die Tools nach ihren Stärken. Das Finetuning von Qwen 3.6/3.8 läuft mit Unsloth, der Export landet als GGUF im llama-server, und die Agenten sprechen dessen OpenAI-kompatible API an. Ollama nutzen wir für schnelle Tests auf dem Entwickler-Laptop, LM Studio empfehlen wir Teams, die ohne Terminal starten wollen. Die Modelle bleiben zwischen allen vier Tools austauschbar, weil sie alle GGUF lesen.

Die Agent-Frameworks im Überblick: Pi, Hermes, OpenClaw, Atomic Agents

Ein Modell allein ist noch kein Agent. Sie brauchen ein Framework, das das Modell an Werkzeuge bindet: Dateisystem, API-Aufrufe, Datenbankzugriff. Vier davon lohnen einen Blick.

Pi (TypeScript)

Ein schlanker Agent für die Kommandozeile. Pi gibt Agenten Werkzeuge zum Lesen, Schreiben, Editieren und Ausführen von Bash, mit einem anbieterneutralen LLM-Layer. Für Entwickler-Workflows ist das der einfachste Einstieg. Pi binden Sie über den llama-Server an ein lokales Modell an, ganz ohne Cloud.

Hermes Agent (Python/TypeScript)

Ein cloud-ausgerichteter autonomer Agent mit persistenter, mehrschichtiger Memory und kontinuierlichem Selbstlernen. Er integriert Slack und Teams. Für lokalen Betrieb brauchen Sie mehr Konfiguration, und die Memory-Komponente sollten Sie bei Löschungsanfragen im Blick behalten, damit eine Löschung auch das Agenten-Gedächtnis erreicht.

OpenClaw Foundation (TypeScript)

Das mit Abstand größte Community-Projekt, mit kompletter Sandbox für autonome Agenten. Nach der Sicherheitskrise Anfang 2026 ist der Code besser auditiert. Setzen Sie Versionen ab 2026.3 ein und deaktivieren Sie Telemetrie. Die Docker-Sandbox senkt Risiken deutlich, der Rest ist Standardhygiene.

Atomic Agents (Python)

Jeder Agent übernimmt genau eine Verantwortung mit typisierten Ein- und Ausgaben. Das Framework ist über Pydantic typsicher, was es auch leicht testbar und wiederverwendbar macht. Sie bauen die Agenten selbst und behalten dadurch die volle Kontrolle über die Datenflüsse. Mehr Aufwand, dafür klare Strukturen, was gerade bei sensiblen Daten zählt.

Drei Beispiele aus der Praxis

Kundenservice, ohne Daten aus der Hand zu geben

Ein Agent beantwortet Kundenanfragen per E-Mail, ohne dass personenbezogene Daten eine Cloud-API sehen.

[Kunden-E-Mail] -> [PII-Filter] -> [lokales LLM (Qwen 3.6/3.8)]
   -> [Antwort-Entwurf] -> [menschliche Prüfung] -> [Versand]

Dazu gehören eine PII-Erkennung vor dem Modell-Input, Logs, die nach 30 Tagen gelöscht werden, und ein Löschungsweg, der auch die Agenten-Logs umfasst.

Verträge durchsuchen statt überfliegen

Ein Agent liest Vertrags-PDFs, findet Kündigungsklauseln und fasst sie zusammen. OCR läuft lokal, und die Vektordatenbank auch.

[Vertrags-PDF] -> [OCR lokal] -> [RAG-Vektordatenbank lokal]
   -> [lokales LLM] -> [Zusammenfassung]

Löschungsanfragen löschen hier auch die Vektoren, und das Verfahren ist in der DPIA dokumentiert.

Code-Reviews, die im eigenen Netz bleiben

Ein Agent prüft Pull Requests auf Sicherheitslücken und Coding-Standards, ohne dass Code das Netzwerk verlässt.

[Git-Repo] -> [Pi mit lokalem LLM] -> [Code-Analyse]
   -> [Review-Kommentare] -> [Pull-Request]

Der Agent bekommt Zugriff nur auf das Repo, nicht auf Kundendaten. Logs bleiben 14 Tage.

Seit August 2026: KI-Inhalte müssen gekennzeichnet werden

Seit dem 2. August 2026 gelten die Transparenzpflichten des EU AI Act (Verordnung 2024/1689, Artikel 50). Synthetisch erzeugte Audio-, Bild-, Video- oder Text-Inhalte müssen maschinenlesbar als KI-generiert markiert werden, wenn sie in Umlauf gebracht werden. Chatbots müssen offenlegen, dass sie KI sind, Deepfakes müssen als solche erkennbar sein. Verstöße können mit bis zu 15 Millionen Euro beziehungsweise 3 Prozent des weltweiten Jahresumsatzes geahndet werden. Für Systeme, die bereits vor dem 2. August genutzt wurden, gilt bei der Markierung eine Übergangsfrist bis zum 2. Dezember 2026.

Wer ist verantwortlich? Provider oder Deployer. Der AI Act unterscheidet zwei Rollen: Den Provider, das ist derjenige, der ein KI-System in Verkehr bringt, also entwickelt oder unter eigenem Namen bereitstellt. Und den Deployer, der es im eigenen Betrieb einsetzt. Für die maschinenlesbare Markierung von KI-generierten Inhalten (Art. 50 Abs. 2) ist der Provider verantwortlich. Für Deepfake-Offenlegung und Chatbot-Hinweise (Art. 50 Abs. 1, 4) ist es der Deployer. Ein Startup, das einen KI-Chatbot auf der eigenen Website einsetzt, ist Deployer und muss die Nutzer darauf hinweisen, dass sie mit einer KI sprechen. Ein Startup, das ein eigenes KI-System entwickelt und anderen zur Nutzung anbietet, ist Provider und trägt zusätzliche Pflichten.

Zwei Dinge sind mit einem lokalen Modell leichter:

• Sie kontrollieren die Kennzeichnung. Läuft das Modell auf Ihrer Hardware, gehört Ihnen die gesamte Output-Pipeline. Die maschinenlesbare Markierung bauen Sie dort ein, wo der Inhalt entsteht, und dokumentieren sie mit. Bei einer Cloud-API hängen Sie von der Umsetzung des Anbieters ab.
• Keine Abhängigkeit von GPAI-Dokumentationspflichten. Große Basismodelle unterliegen seit August 2025 eigenen Auflagen, unter anderem technische Dokumentation und Trainingsdaten-Zusammenfassung. Mit einem lokal betriebenen Open-Source-Modell kaufen Sie diese Kette nicht ein, und Modelle, die nur intern genutzt werden, bringen Sie nicht in die Provider-Rolle.

Ein Hinweis: Die Kennzeichnungspflicht trifft jeden, der KI-Inhalte veröffentlicht, egal wo das Modell läuft. Wer einen Chatbot betreibt, muss dessen KI-Natur offenlegen, ob die Inferenz nun lokal oder in der Cloud passiert. Der Vorteil lokaler Modelle liegt in der Kontrolle über den gesamten Prozess, von der Pflicht befreit Sie das aber nicht.

Mini-PC oder Cloud-Server: beides funktioniert

Die Hardwarefrage ist heute selten der Flaschenhals. Für Modelle der 8B-Klasse reicht ein Mini-PC, der neben den Monitor passt. Wer mehrere Agenten parallel laufen lässt oder größere Modelle braucht, nimmt einen Cloud-Server.

Für unsere Kunden kombinieren wir die beiden Methoden und die Hardware, die zum Einsatz passt. Derselbe Agent läuft bei dem einen auf einem lokalen Mini-PC, bei einem anderen in der Cloud, und eine spätere Verteilung auf weitere Geräte ist ohne Umbau möglich. Welche Mischung die richtige ist, entscheiden wir gemeinsam mit Ihnen.

Unser Artikel über Rybbit und Matomo behandelt cookiefreie Web-Analytics, falls Sie das auch brauchen. Der erste Schritt ist in beiden Fällen derselbe: ein System, das Sie selbst kontrollieren.

Haben Sie Fragen zu Ihrem lokalen Agenten-Setup oder möchten Sie Ihre konkrete Situation durchsprechen? Kontaktieren Sie unser Team.