DSGVO-konforme KI-Agenten: Qwen 3.6/3.8 mit llama.cpp lokal betreiben

Warum deine 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 eigenes lokales Setup: Modelle laufen auf deiner Hardware, Daten verlassen das Netzwerk nie. Kein AVV, volle Kontrolle. Dieser Artikel zeigt dir den Weg dahin. Mit llama.cpp als Engine, Qwen 3.6 oder 3.8 als Modell, Unsloth fürs Fintuning und der Weboberfläche, die den Einstieg deutlich einfacher macht als gedacht.

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

Bevor wir zur Technik kommen, die rechtlichen Pflichten. Für eine vollständige Beratung wendest du dich an deinen Datenschutzbeauftragten.

Art. 6 DSGVO verlangt eine Rechtsgrundlage. Jede Verarbeitung personenbezogener Daten braucht einen rechtmäßigen Grund. Wenn dein 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 innovative Technik einsetzen, fallen fast immer darunter. Die DPIA ist kein Hindernis, sondern ein Dokumentations- und Risiko-Management-Werkzeug.

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.

Das klingt nach viel Papier, bleibt aber überschaubar, wenn die Architektur es von Anfang an einplant. Lokale Modelle machen einen Teil davon deutlich einfacher, weil die Datenhoheit schon strukturell gegeben ist.

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. Tools wie Ollama, LM Studio oder vLLM bauen alle auf denselben Kern.

Für die DSGVO zählt vor allem eins: das Modell läuft auf deiner 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. Trage dort das Repository ein, aus dem du ein quantisiertes GGUF-Modell laden willst, zum Beispiel ein von Unsloth veröffentlichtes Qwen 3.x.

./build/bin/llama-cli -hf <dein-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.

./build/bin/llama-server -hf <dein-gguf-repo> --port 8080 --host 0.0.0.0

Die Weboberfläche von llama-server

Danach öffnest du http://localhost:8080 im Browser und landest in der eingebauten Oberfläche von llama-server. Du kannst 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. Du bedienst die Oberfläche im Browser für schnelle Tests, und deine 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 Fintuning und die Quantisierung von Modellen deutlich beschleunigt. Aus einem Basismodell wird in überschaubarer Zeit ein fein justiertes, quantisiertes GGUF für den llama-Server.

Schneller und sparsamer. Unsloth reduziert Trainingszeit und Speicherbedarf erheblich. Damit passt ein angepasstes Modell auf Hardware, die auch neben einem Schreibtisch steht.

Deutsch und Fachdomänen. Wer ein Modell auf eigene Daten fintunet, holt mehr heraus als mit jeder noch so langen Promptenkette. Für deutsche Texte sind Qwen 3.6 und 3.8 eine starke Basis.

GGUF-Export. Nach dem Fintuning exportiert Unsloth das Modell direkt ins GGUF-Format, das llama.cpp versteht. Der Weg von der Anpassung bis zur Produktion bleibt kurz.

Kurz gesagt: Qwen 3.6/3.8 mit Unsloth ist unser Standard für deutsche Agenten. Wenn dein Use-Case klein bleibt, reicht ein kompakteres deutsches Modell.

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

Ein Modell allein ist noch kein Agent. Du brauchst ein Framework, das das Modell mit Werkzeugen verbindet: Dateisystem, API-Aufrufe, Datenbankzugriff. So ordnen sich die vier relevanten Ansätze ein:

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 bindest du ü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 brauchst du mehr Konfiguration, und die Memory-Komponente solltest du 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. Setze Versionen ab 2026.3 ein und deaktiviere 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 typsicher über Pydantic, leicht zu testen und wiederzuverwenden. Du baust die Agenten selbst und behältst dadurch die volle Kontrolle über die Datenflüsse. Mehr Aufwand, dafür klare Strukturen, gerade bei sensiblen Daten.

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.

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. Beides ist ein legitimer Weg.

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

Zusammenfassung

DSGVO-konforme KI-Agenten sind heute kein Laborprojekt mehr. Mit llama.cpp als Engine, Qwen 3.6/3.8 als Modell und Unsloth fürs Fintuning betreibst du Agenten auf eigener Hardware. Die Daten bleiben im Haus, die personenbezogene Verarbeitung bleibt dokumentierbar, und der Einstieg geht über die Weboberfläche von llama-server schneller, als die meisten erwarten.

Wer parallel noch cookiefreie Web-Analytics braucht, findet in unserem Artikel über Rybbit und Matomo die passende Anleitung. Der erste Schritt ist in beiden Fällen derselbe: ein System, das du selbst kontrollierst.

Hast du Fragen zu deinem lokalen Agenten-Setup oder möchtest du deine konkrete Situation durchsprechen? Kontaktiere unser Team.