Was ist lokale KI? Modelle auf eigener Infrastruktur

Lokale KI vom Pilot bis zum belastbaren Betrieb aufbauen? WZ-IT plant Hardware, Modellserver, Identitäten, Wissensabruf, Monitoring und Backup als zusammenhängende Plattform - On-Premise oder auf dedizierter Infrastruktur. Managed AI ansehen

„Lokale KI" beschreibt mehr als ein Sprachmodell auf einer GPU. Produktiv wird sie erst durch eine kontrollierte Betriebsgrenze, Identitäten, Wissensquellen, Protokollierung, Updates und Wiederherstellung. Dieser Artikel erklärt die Architektur und zeigt, wann On-Premise, dediziertes Self-Hosting oder ein Hybridmodell sinnvoll ist. Stand August 2026.

Inhaltsverzeichnis

• Cloud-KI oder lokale KI
• Was "lokal" konkret bedeutet
• Warum Unternehmen lokal betreiben
• Was zu lokaler KI dazugehört
• Wann lokale KI sinnvoll ist
• Wo lokale Systeme trotzdem nach außen kommunizieren
• Vom Pilot zum produktiven Betrieb
• Wie WZ-IT lokale KI umsetzt
• Quellen

Cloud-KI oder lokale KI

Die meisten kennen KI über Cloud-Dienste: Eine Anwendung sendet eine Anfrage an einen extern betriebenen Modellendpunkt und erhält eine Antwort. Je nach Anbieter, Produkt und Konfiguration werden dabei Inhalte und Metadaten in der vereinbarten Region verarbeitet. Das ist bequem und skaliert schnell, gibt aber einen Teil der technischen Kontrolle an den Betreiber ab.

Lokale KI verlagert die Inferenz in eine kontrollierte Umgebung. Für Nutzer kann dieselbe Chat- oder API-Oberfläche bestehen bleiben. Unter der Oberfläche entscheidet das Unternehmen jedoch über Modell, Version, Netzwerkpfade, Zugriffe und Aufbewahrung. Das schafft Gestaltungsspielraum, bringt aber auch Betriebsverantwortung.

Was "lokal" konkret bedeutet

„Lokal" heißt nicht zwingend „im eigenen Serverraum". Gemeint ist: auf Infrastruktur, die Sie kontrollieren. Das kann sein:

• ein GPU-Server im eigenen Rechenzentrum oder Serverraum (On-Premise),
• eine virtuelle Maschine auf Proxmox oder Bare Metal,
• ein Server bei einem europäischen Hoster, der Ihrer Kontrolle unterliegt.

Entscheidend ist nicht der Standort allein, sondern die definierte Vertrauens- und Betriebsgrenze. On-Premise meint meist Hardware am eigenen Standort. Self-hosted beschreibt, dass der Stack durch das Unternehmen oder in seinem Auftrag betrieben wird. Dediziert kann auch bei einem europäischen Hoster liegen. Diese Begriffe sollten im Projekt nicht synonym verwendet werden, weil Zugriff, Verantwortlichkeit und Ausfallsicherheit unterschiedlich sind.

Warum Unternehmen lokal betreiben

Drei Gründe treiben den Wechsel:

• Datenschutz und Souveränität - Datenwege, Zugriffe und Aufbewahrung lassen sich enger begrenzen. Ob externe Übermittlungen vollständig entfallen, muss anhand der gesamten Plattform geprüft werden. Das stärkt die technische Grundlage für Datenschutz und KI-Souveränität, ersetzt aber keine rechtliche Bewertung.
• Kostenkontrolle - Kapazitätskosten sind planbar. Dem stehen Hardware, Energie, Redundanz und Betrieb gegenüber. Bei kontinuierlicher Grundlast kann lokale Inferenz wirtschaftlich sein; bei geringer oder stark schwankender Last kann Cloud günstiger bleiben.
• Unabhängigkeit - keine Bindung an Preis-, Modell- oder Lizenzänderungen eines einzelnen Anbieters. Sie entscheiden, welches Modell wann läuft.

Die Abwägung im Detail - wann Cloud, wann eigene Hardware - zeigt Cloud-KI vs. self-hosted.

Was zu lokaler KI dazugehört

Lokale KI ist kein einzelnes Werkzeug, sondern eine Plattform mit mehreren Schichten:

• Compute und Speicher - GPU, CPU, VRAM, Modell- und Dokumentenspeicher sowie Backup.
• Inferenzserver - etwa Ollama für kompakte Setups oder vLLM für durchsatzorientierte API-Bereitstellung.
• Gateway - einheitliche Endpunkte, Modellrouting, Limits und Fallbacks.
• Identität und Netzwerk - SSO, Rollen, Secrets, Segmentierung und kontrollierte Administration.
• Anwendung und Wissen - Oberfläche, APIs, RAG, Quellenanzeige und Berechtigungsprüfung vor dem Retrieval.
• Betrieb - Metriken, datensparsame Traces, Evaluation, Updates, Rollback, Backup und Incident-Prozess.

Erst dieses Zusammenspiel macht aus einer Modelldemo ein produktives System. Ein Modell, das auf einer Workstation antwortet, ist noch kein Mehrbenutzerdienst mit definierten Rechten und Verfügbarkeit.

Wann lokale KI sinnvoll ist

Lokale KI lohnt sich besonders, wenn mindestens einer dieser Punkte zutrifft: Sie verarbeiten sensible oder regulierte Daten (Recht, Gesundheit, öffentliche Hand, Industrie), Sie haben eine kontinuierliche, hohe Nutzung, bei der Token-Kosten ins Gewicht fallen, oder Sie wollen unabhängig von einem einzelnen US-Anbieter sein.

Für sporadische, geeignete Nutzung kann ein Cloud-Dienst der einfachere Einstieg bleiben. Lokale KI ist besonders relevant, wenn Datenwege eng begrenzt, Systeme in bestehende Identitäten und Netzwerke integriert oder eine planbare Grundlast betrieben werden soll. Die Entscheidung sollte anhand eines Piloten fallen, nicht aufgrund einer pauschalen Datenschutz- oder Kostenbehauptung.

Wo lokale Systeme trotzdem nach außen kommunizieren

„Das Modell läuft lokal" sagt noch nicht, dass die Plattform offline arbeitet. Typische ausgehende Verbindungen sind:

• Downloads von Modellen, Containern und Updates,
• Telemetrie und Crash-Reporting,
• externe Embedding-, Moderations- oder Websuchdienste,
• Cloud-basierte Tracing- und Observability-Endpunkte,
• E-Mail, OCR, Speech-to-Text oder weitere angebundene APIs,
• Remote-Support und externe Backup-Ziele.

Diese Wege können sinnvoll und zulässig sein. Sie müssen nur sichtbar, freigegeben und technisch begrenzt sein. Ollama bietet beispielsweise eine Konfiguration zum Abschalten seiner Cloud-Funktionen. Zusätzlich helfen Egress-Regeln und Tests, unerwartete Verbindungen zu erkennen.

Vom Pilot zum produktiven Betrieb

Ein sinnvoller Ablauf besteht aus sechs Schritten:

1. Anwendungsfall, Nutzergruppen, Datenklassen und messbare Qualitätsziele festlegen.
2. Zwei bis drei konkrete Modelle mit realen Aufgaben und Dokumenten vergleichen.
3. VRAM, Kontext, Parallelität, Latenz und erwartete Spitzenlast messen.
4. Identität, Rechte, RAG und Protokollierung bereits im Pilot realistisch abbilden.
5. Update, Ausfall, Backup-Restore und Modell-Rollback testen.
6. Erst danach Hardware und Service Level für den Produktivbetrieb festlegen.

Das reduziert das Risiko, zu große Hardware für ein ungeeignetes Modell zu kaufen oder eine gute Demo ohne Betriebsweg zu bauen.

Wie WZ-IT lokale KI umsetzt

WZ-IT kann die Plattform auf vorhandener Infrastruktur integrieren oder als Managed AI betreiben. Für einen kompakten On-Premise-Einstieg gibt es den AI Cube, für größere oder zentral bereitgestellte Modelle GPU-Server und LLM-Hosting.

Der Mehrwert liegt nicht nur im Modellstart. Wir verbinden Netzwerk, Identität, Modellserver, Wissensquellen, Monitoring, Backup und Weiterentwicklung zu einem betreibbaren System. Für wissensbasierte Anwendungen kann darauf ein interner KI-Assistent mit Quellen und Berechtigungen aufbauen.

Quellen

• Ollama-Dokumentation: lokaler Betrieb, Cloud-Deaktivierung und Parallelität
• vLLM-Dokumentation: OpenAI-kompatibler Inferenzserver
• LiteLLM-Dokumentation: Routing und Load-Balancing
• EU-Kommission: Datenschutzpflichten und Datenschutz-Folgenabschätzung