Private KI für sensible Daten: ein lokales LLM-Setup, das durch die Sicherheitsprüfung kommt
Gesundheitsdaten, Kundenverträge, unveröffentlichte Finanzzahlen: Manche Daten dürfen nie an eine öffentliche KI-API gehen, und die Security hat recht, darauf zu bestehen. Meist endet damit das KI-Gespräch, und genau die Leute, die am meisten profitieren würden, kopieren weiter Text von Hand. Das muss nicht sein. Das ist die Architektur, die ich für private KI im eigenen Netz nutze: zuerst ein Testset, dann das kleinste Modell, das es besteht, Retrieval, das Zugriffsrechte respektiert, ein Anonymisierer am Rand und ein Audit-Trail für alles.
Aktualisiert 11 Min. Lesezeit
1. Daten und Aufgabe einordnen
Mit zwei kurzen Listen beginnen. Die erste nennt die beteiligten Datenklassen: Personendaten, Gesundheitsdaten, Geschäftsgeheimnisse, regulierte Finanzdaten. Die zweite nennt die Aufgaben: Klassifizieren, Extrahieren aus Dokumenten, Zusammenfassen, Antworten entwerfen, Fragen zu internen Dokumenten beantworten. Zusammen bestimmen sie, wie streng das Setup sein muss und wie gross das Modell.
Die Aufgabe zählt mehr, als viele denken. Klassifizieren, Extrahieren und Zusammenfassen gelingen kleinen Open-Weight-Modellen gut, oft in einer Qualität, die das Business überrascht. Mehrstufiges Schlussfolgern über viele lange Dokumente braucht ein grösseres Modell und mehr Hardware. Das NIST AI Risk Management Framework und die Azure-Well-Architected-Leitlinien für KI-Workloads beginnen nicht zufällig hier: erst Anwendungsfall und Risiken erfassen, dann Technik wählen.
Tipp aus der Praxis
Die Datenklassen ins Systemdesign schreiben, nicht nur in ein Richtlinien-PDF. Dann kann das Gateway nach Klasse routen: Öffentliches darf an ein gehostetes Modell, Vertrauliches nie.
2. Das Testset vor der Modellwahl bauen
30 bis 50 echte Beispiele mit der erwarteten Antwort sammeln und von jemandem aus dem Business prüfen lassen. Die schwierigen Fälle bewusst aufnehmen: gescannte PDFs, gemischte Sprachen, Tabellen, den Vertrag mit der seltsamen Klausel, den Mail-Verlauf, in dem die Antwort in der dritten Antwort steckt. Als einfache JSON-Zeilen speichern, ein Fall pro Zeile, mit Quelldatei und erwarteter Antwort.
Jedes Kandidatenmodell und jeden Prompt gegen dieses Set bewerten: Genauigkeit, Latenz und Kosten pro Anfrage. Das Set entscheidet über das Modell, nicht eine Rangliste, denn öffentliche Benchmarks sehen selten aus wie Ihre Dokumente. Und es entscheidet weiter: Jedes Mal, wenn jemand einen Prompt, eine Retrieval-Einstellung oder das Modell ändert, läuft dasselbe Set erneut. Ohne Set ist jede Änderung Meinungssache; mit Set ist sie eine Zahl auf dem Dashboard.
{"id": "contract-017", "file": "contracts/017.pdf",
"question": "What is the notice period?",
"expected": "3 months to the end of a quarter",
"must_cite": "section 9.2", "data_class": "confidential"}3. Das Modell auf die Hardware abstimmen
GPU-Speicher bestimmt, was läuft. Als Faustregel brauchen die Gewichte Parameter mal Bytes pro Gewicht: Ein Modell mit 14 Milliarden Parametern hat in 16 Bit rund 28 GB, in 8 Bit 14 GB und in 4 Bit 7 GB. Dazu kommen der KV-Cache, der mit Kontextlänge und Anzahl paralleler Nutzer wächst, und etwas Laufzeit-Overhead. Den Rechner unten mit eigenen Zahlen ausprobieren, bevor das Gespräch mit dem Hardware-Händler beginnt.
Quantisierung ist der Hebel, der das bezahlbar macht. 4-Bit-Modelle verlieren bei den meisten Aufgaben etwas Genauigkeit, manchmal so wenig, dass Ihr Testset nichts merkt, und sie laufen auf einer einzigen Workstation-GPU. Für Prototypen reicht eine Desktop-GPU oder ein Mac mit genug Unified Memory. Für Produktion eine GPU-Node mit Reserve für Lastspitzen einplanen, denn ein Modell, das genau passt, staut Anfragen, sobald drei Leute gleichzeitig arbeiten.
Tipp aus der Praxis
Das quantisierte Modell testen, das wirklich laufen wird, nicht das in voller Präzision aus der Model Card. Veröffentlichte Benchmarks werden fast immer in 16 Bit gemessen.
Interaktiv
Welche GPU braucht Ihr Modell?
Wählen Sie Modellgrösse und Genauigkeit. Gewichte brauchen Parameter × Bytes pro Parameter, rund 20 % mehr decken den KV-Cache bei normaler Kontextlänge.
Modellgrösse (Milliarden Parameter)
Genauigkeit
≈ 19 GB
benötigter GPU-Speicher
1×
passt auf 24 GB (RTX 4090)
- 1× 24 GB (RTX 4090)
- 1× 32 GB (RTX 5090)
- 1× 48 GB (L40S)
- 1× 80 GB (H100)
- 1× 96 GB (RTX PRO 6000 Blackwell)
- 1× 141 GB (H200)
Faustregel zur Planung, kein Benchmark. Lange Kontexte und viele parallele Nutzer brauchen mehr KV-Cache, 4-Bit kostet etwas Qualität.
Alle Rechner und Checklisten4. Es wie jede andere interne API betreiben
Für eine Handvoll Nutzer ist Ollama oder llama.cpp der schnellste Weg zu einem funktionierenden Endpoint. Sobald viele Leute oder Agenten dasselbe Modell nutzen, auf vLLM wechseln: Continuous Batching und Paged Attention holen deutlich mehr Durchsatz aus derselben GPU, und vLLM bietet eine OpenAI-kompatible API, sodass Ihren Anwendungen egal ist, welches Modell dahintersteckt. Ein späterer Modellwechsel wird so zur Konfigurationsänderung statt zum Projekt.
Den Server im eigenen Netz oder in der Private Cloud betreiben, hinter demselben Gateway, TLS, Monitoring und Patch-Rhythmus wie jeder andere Dienst. Modellversion und Container-Image festschreiben, die Gewichte in der eigenen Registry oder im eigenen Object Storage ablegen und ein Modell-Upgrade wie ein Datenbank-Upgrade behandeln: zuerst Testset, dann Staging, dann Produktion. Die Generative AI Lens des AWS Well-Architected Framework beschreibt dieselbe Betriebsdisziplin für gehostete Modelle; auf eigener Hardware gilt sie genauso.
# OpenAI-compatible endpoint on an internal GPU node (example model;
# pick yours with the test set)
vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \
--quantization awq \
--max-model-len 32768 \
--gpu-memory-utilization 0.90 \
--host 0.0.0.0 --port 8000
# Any OpenAI client can now talk to it, inside your network only
curl http://llm.internal:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "Qwen/Qwen2.5-14B-Instruct-AWQ",
"messages": [{"role": "user", "content": "Summarise clause 9.2"}]}'5. Die eigenen Dokumente einbinden, mit ihren Zugriffsrechten
Retrieval liefert dem Modell zu jeder Frage die richtigen Seiten, statt es mit Ihren Daten zu trainieren. Dokumente in Abschnitte teilen, mit einem lokalen Embedding-Modell Vektoren erzeugen und diese in pgvector im Postgres speichern, das Sie vermutlich schon betreiben. Quelle, Version und Zugriffsliste jedes Abschnitts direkt neben dem Vektor ablegen, denn bei der Abfrage braucht man alle drei.
Entscheidend ist die Reihenfolge. Zuerst nach dem filtern, was der Nutzer sehen darf, dann nach Ähnlichkeit ranken, damit das Modell nie einen Absatz erhält, den die Person im Originalsystem nicht öffnen könnte. Dann in jeder Antwort die Quelle mit Link nennen, damit die Leute prüfen können statt glauben zu müssen. OWASP zählt die Offenlegung sensibler Informationen zu den grössten Risiken von LLM-Anwendungen, und Retrieval ohne Berechtigungen ist der häufigste Weg dorthin.
-- Chunks with their source and who may read them
create extension if not exists vector;
create table doc_chunks (
id bigserial primary key,
source text not null,
allowed_groups text[] not null,
content text not null,
embedding vector(1024)
);
-- Nearest chunks the user is allowed to see
select source, content
from doc_chunks
where allowed_groups && $1 -- the user's groups
order by embedding <=> $2 -- cosine distance
limit 8;Tipp aus der Praxis
Zugriffsregeln indexieren, nicht nur Text. Retrieval ohne Berechtigungen ist ein Datenleck mit Zusatzschritten.
6. Am Rand anonymisieren
Manchmal profitiert ein Schritt wirklich von einem grossen gehosteten Modell, etwa beim Feinschliff eines Endtexts oder bei schwierigem Schlussfolgern auf einer Zusammenfassung. Dann erledigt die lokale Seite zuerst die sensible Arbeit: Sie entfernt Namen, Adressen, Kontonummern und Fall-IDs, ersetzt sie durch Platzhalter, schickt nur den anonymisierten Text hinaus und setzt die echten Werte lokal wieder in die Antwort ein.
Tools wie Microsoft Presidio erkennen die gängigen Entitätstypen von Haus aus; eigene Erkenner für Kundennummern, Vertrags-IDs oder interne Codes ergänzen und mit derselben Disziplin testen wie das Modell. Jede Anfrage protokollieren, die das Netz verlässt: wann, welches Modell, welche Datenklasse und wie viele Entitäten ersetzt wurden. Zeigt das Log je eine vertrauliche Klasse auf dem Weg nach draussen, ist das ein Bug, und Sie finden ihn am selben Tag statt ein Jahr später im Audit.
7. Identität, Audit und kein überraschender Datenabfluss
Das Modell hinter das Single Sign-on stellen, damit jede Anfrage eine Personen- oder Dienstidentität trägt. Ein Audit-Log mit Nutzer, Modell, Datenklasse und den abgerufenen Quellen schreiben und so lange aufbewahren, wie es Ihre Compliance verlangt. Dieses Log beantwortet die zwei Fragen, die jeder Auditor stellt: Wer hat was gesehen, und ist etwas hinausgegangen?
Dann die Türen schliessen, die niemand braucht. Ausgehenden Verkehr der GPU-Nodes standardmässig sperren, ausser zu den Registries für Updates, und jede Ausnahme als geprüfte Änderung behandeln. KI-Agenten eigene Dienstidentitäten geben, zuerst nur mit Lesezugriff; Schreibrechte kommen später, Werkzeug für Werkzeug, mit menschlicher Freigabe. Die Sicherheitsprüfung wird kurz, wenn Sie Architekturdiagramm, Audit-Log und Firewall-Regeln in einem Termin zeigen können, und genau das verlangt die Sicherheitssäule des Azure Well-Architected Framework: mehrere Schutzschichten, minimale Rechte und Nachweise.
Tipp aus der Praxis
Vor dem Go-live einen bewussten Egress-Test machen: Von einer GPU-Node aus eine öffentliche KI-API erreichen wollen. Klappt es, klappt Ihre Firewall-Regel nicht.
8. Messen, dann skalieren
Das Testset bei jeder Modell- oder Prompt-Änderung laufen lassen und Genauigkeit, Latenz und Kosten pro Anfrage auf einem Dashboard neben den anderen Diensten verfolgen. Auf die GPU-Auslastung achten: Als grobe Orientierung heisst deutlich unter einem Drittel, dass Sie für ungenutztes Silizium zahlen, und dauerhaft über 85 Prozent heisst Warteschlangen und wachsende Latenz. Beides sind Signale zum Umdimensionieren, nicht zur Panik.
Hält die Qualität und nutzen die Leute es täglich, vom Prototyp-Rechner auf einen kleinen GPU-Node-Pool im eigenen Rechenzentrum oder in der Private Cloud wechseln, mit Autoscaling nach Warteschlangenlänge statt CPU. Ein zweites Modell erst dann ergänzen, wenn das Testset eine Aufgabe zeigt, die das erste nicht schafft. Das Ergebnis ist auf die beste Art langweilig: ein interner Dienst mit Owner, Testsuite, Audit-Trail und Kosten pro Anfrage, die Sie der Finanzabteilung erklären können.
Fazit
Private KI ist vor allem Ingenieursdisziplin: ein Testset, das kleinste Modell, das es besteht, Berechtigungen im Retrieval und ein Audit-Log. Stimmen diese vier, vertragen sich sensible Daten und KI bestens.
Echte Projekte dazu
Selbst ausprobieren
Quellen und offizielle Leitfäden
- Azure Well-Architected Framework: AI workloads
- Azure Well-Architected Framework: Security pillar
- AWS Well-Architected: Generative AI Lens
- NIST AI Risk Management Framework
- OWASP Top 10 for Large Language Model Applications
- vLLM documentation
- pgvector: vector similarity search for Postgres
- Microsoft Presidio: data protection and de-identification
Weitere Artikel
- 3'025 Pull Requests in zehn Monaten: ein KI-gestützter Delivery-Prozess von innen
- Der EU AI Act für den Mittelstand: was für Sie gilt, und ab wann
- FinOps für KI-Kosten: Tokens, Caching, Routing und Budgets, die halten
- Ein Restaurant-Netzwerk in KI-Antworten sichtbar machen: ein GEO-Projekt Schritt für Schritt
- Wie diese Website gebaut ist: statisch, wo es geht, streamend, wo es muss
- Kubernetes-Kosten auf EKS und GKE: dasselbe Playbook, andere Hebel
- Eine Landing Zone für den Mittelstand, in Terraform oder Bicep: die Teile, die zählen
- Das Playbook für Legacy-Migrationen: Wellen, Parallelbetrieb und identische Zeilenzahlen und Prüfsummen
- MCP-Sicherheit im Detail: KI-Assistenten ins Produkt lassen, ohne die Türen zu öffnen
- Monitoring auf Geschäftsergebnisse: grüne Dashboards, leere Kasse
- KI-Agenten am Telefon: die Architektur, und die Stolperfallen, die keine Demo zeigt
- Restore-Tests: Ein Backup, das nie wiederhergestellt wurde, ist nur eine Hoffnung
- KI-Antworten auf Azure Static Web Apps streamen: der eine Header, der alles zurückhielt
- Einen KI-Assistenten für WhatsApp bauen, von Anfang bis Ende: was es über die Demo hinaus braucht
- Air-gapped-Systeme: kritische Software ganz ohne Internet betreiben
- Produktive KI auf AWS: Amazon Bedrock und AgentCore in einem privaten Setup
- Produktive KI auf Microsoft Foundry: ein privates Referenz-Setup für Agenten
- /goal, /loop oder Routines: Hören Sie auf, Ihren Coding-Agenten zu babysitten
- Claudes neue Pläne: Max, Ultra und was sie für Teams bedeuten
- OpenAI Codex Ende 2026: Goal Mode, Dots und wie man es absichert
- GitHub Copilot, Claude Code oder Codex? So würde ich für ein Unternehmen entscheiden
- GEO-Grundlagen: So erscheinen Sie in KI-Antworten
- Produktive KI auf Google Cloud: von Vertex AI zur Gemini Enterprise Agent Platform
- Lokale LLMs im Air-Gap-Netz: KI für Ihre sensibelsten Daten
- Ich will ein lokales LLM betreiben: Welchen Server soll ich kaufen?
- MiniMax M3: ein offenes Spitzenmodell zum Selbstbetreiben?
- Prompt-Research im grossen Stil mit einem offenen Modell
- SEO und GEO zusammen: ein praktisches Audit in 6 Schritten
- Kubernetes richtig dimensionieren: das Playbook, mit dem ein Cluster von 7 auf 4 Nodes kam
- Vom KI-Prototyp zur Produktion: die acht Schichten, die ich ergänze, in dieser Reihenfolge
