Zum Inhalt springen
Alle Artikel

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.

Private KI im eigenen Netz: Identität an der Tür, Berechtigungen im Retrieval, ein Anonymisierer am Rand und ein Audit-Log für jede Anfrage.
Architektur privater KI im eigenen Netz: Nutzer melden sich über ein SSO-Gateway an, ein PII-Anonymisierer sitzt am Rand, ein lokales LLM läuft mit vLLM oder Ollama auf GPU-Nodes, Retrieval nutzt lokale Embeddings und pgvector mit Zugriffsrechten, jede Anfrage landet im Audit-Log, und es gibt keinen Abfluss zu öffentlichen KI-APIs.

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.

json
{"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 Checklisten

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

bash
# 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"}]}'
What is vLLM? Efficient AI Inference for Large Language Models, IBM Technology (YouTube). Wird erst nach Ihrem Klick von YouTube geladen.

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.

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

Weitere Artikel

    Kontakt aufnehmen

    Erzählen Sie mir von Ihrem Projekt, ich antworte innerhalb von 1–2 Werktagen.

    Dominik Heinrich
    Unternehmen
    MADO Consulting

    Weltweit verfügbar, remote. Vor Ort auf Anfrage, je nach Land.

    Ich antworte innerhalb von 1–2 Werktagen. Freie Termine: siehe Kalender

    Öffnet hier den Buchungskalender von Calendly. Beim Laden werden Daten an Calendly übertragen (siehe Impressum).