Der Wechsel von Cloud-KI zu lokalen Modellen eliminiert eine wohldefinierte Risikoklasse — und bringt eine andere mit sich, die die meisten Teams erst nach dem ersten Vorfall entdecken.
Warum Organisationen lokal werden
Die Argumente dafür, Modelle innerhalb des eigenen Netzwerks zu betreiben, sind in den letzten achtzehn Monaten ungewöhnlich überzeugend geworden. Daten bleiben on-premise, was eine ganze Kategorie regulatorischer und vertraglicher Probleme rund um Drittverarbeitung beseitigt. Es gibt keine Abhängigkeit von externen API-Anbietern, deren Preise, Verfügbarkeit oder Modellverhalten sich ohne Vorwarnung ändern können. Sensible Prompts und Antworten passieren kein öffentliches Netz, was eine bedeutsame Exposition für Organisationen schließt, die mit medizinischen Akten, Finanztransaktionen, eingestuftem oder kommerziell sensitivem Material oder personenbezogenen Daten unter strengen Lokalitätsregeln arbeiten. Für jede regulierte Branche — Gesundheitswesen, Finanzwesen, Verteidigung oder jeden Sektor mit strengen Daten- und Sicherheitsauflagen — ist lokales Deployment oft keine Präferenz, sondern Voraussetzung dafür, moderne KI überhaupt einsetzen zu dürfen.
Die Versuchung besteht freilich darin, diese Liste an Vorteilen als Beweis dafür zu lesen, lokales Deployment sei automatisch sicherer als die Cloud-Alternative. Das ist es nicht. Was lokales Deployment tut, ist die Sicherheitsverantwortung vom Operations-Team eines Anbieters auf Ihr eigenes zu verlagern. Ob die resultierende Posture stärker oder schwächer ist, hängt vollständig davon ab, ob Ihr Team bereit ist, diese Verantwortung mit denselben Werkzeugen, in derselben Frequenz und mit derselben Disziplin zu tragen, die der Cloud-Anbieter auf dieselbe Fläche aufgewendet hat.
Die neue Risikofläche
Wenn Sie von einer Cloud-API zu einem selbstgehosteten Inferenz-Stack migrieren, tauschen Sie eine Risikoklasse gegen eine andere. Die Risiken, die Sie eliminieren, sind real und es lohnt sich, sie zu eliminieren: Datenübertragung an Dritte, Abhängigkeit von der Datenschutzposition und Vertragsgestaltung eines Anbieters, das ewige Problem, dass API-Schlüssel in Quell-Repositories gelangen, und die operative Abhängigkeit von Rate-Limits, regionaler Verfügbarkeit und Incident-Timeline eines Anbieters. Das sind keine trivialen Gewinne.
Die Risiken aber, die Sie sich stattdessen einhandeln, sind ebenfalls real, und die meisten von ihnen sind so still wie klassische Cybersicherheit still ist: nichts geht sichtbar kaputt, bis etwas exfiltriert, modifiziert oder ausgenutzt worden ist.
Modellgewichte im Ruhezustand
Das erste betrifft die Modellgewichte im Ruhezustand. Eine Modelldatei, die unverschlüsselt auf einem Server liegt, ist kommerziell betrachtet eine komprimierte Kopie des institutionellen Wissens, das in ihre Erstellung oder Fine-Tuning eingeflossen ist; sicherheitsbetrachtet ist sie eine Datei mit demselben Schadensradius wie Ihr sensibelster Datenbankexport. Ohne Verschlüsselung im Ruhezustand und strenge Zugangskontrollen auf das Verzeichnis, das die Gewichte enthält, ist ein kompromittierter Server ein kompromittiertes Modell — und ein Modell, das ein Angreifer leise modifiziert hat, ist per Definition ein vergiftetes Modell, mit allen Folgekonsequenzen, die in der Literatur zu Supply-Chain-Angriffen beschrieben sind.
Fehlende Filterschichten
Das zweite ist das Fehlen jener Eingabe- und Ausgabe-Filterschichten, die Cloud-Anbieter standardmäßig anwenden. Wenn Sie OpenAI, Anthropic oder Google aufrufen, läuft Ihre Anfrage durch anbieterseitige Moderation, Prompt-Injection-Heuristiken und Policy-Durchsetzung, bevor sie das Modell überhaupt erreicht, und die Antwort durchläuft auf dem Rückweg ähnliche Filter, bevor sie bei Ihnen ankommt. Selbstgehostete Stacks haben davon nichts, sofern Sie es nicht selbst bauen. Ein naives Deployment von llama.cpp, Ollama oder vLLM exponiert das Modell direkt gegenüber jeder Eingabe, die die Anwendungsschicht zufällig weiterleitet — was bedeutet, dass jede Prompt-Injection-Technik, die in den letzten zwei Jahren publiziert wurde, auf Ihr Deployment zutrifft, bis Sie sich explizit dagegen verteidigen.
Kein Audit-Trail
Das dritte ist das Audit-Trail-Problem. Cloud-Anbieter protokollieren API-Aufrufe standardmäßig, halten diese Logs mindestens für die vertragliche Dauer und stellen sie für Incident-Untersuchungen bereit. Lokale Deployments haben keinen Audit-Trail, sofern Sie keinen bauen — und wenn ein Vorfall eintritt, macht das Fehlen von Aufzeichnungen es nahezu unmöglich festzustellen, was geschehen ist, welche Eingaben welche Ausgaben erzeugt haben, wer betroffen war und ob das Problem eingegrenzt ist. Der Zeitpunkt, in Eingabe- und Ausgabe-Logging zu investieren, ist vor dem Vorfall, nicht danach.
Exponierte Inferenz-Endpunkte
Das vierte sind exponierte Inferenz-Endpunkte. Die populären lokalen Inferenz-Server exponieren alle HTTP-APIs, und eine Netzwerk-Fehlkonfiguration genügt, um diese APIs an Stellen erreichbar zu machen, an denen sie nicht beabsichtigt waren. Dadurch werden produktive Inferenz-Server gefunden, die aus dem öffentlichen Internet erreichbar waren — manchmal weil eine Firewall-Regel zu permissiv geschrieben wurde, manchmal weil der Server im falschen Netzwerksegment platziert wurde, manchmal schlicht weil niemand verifiziert hatte, dass das lauschende Interface nur an localhost gebunden war. Die Kosten, das in einem Assessment zu finden, sind erträglich; die Kosten, dass ein Angreifer es zuerst findet, sind es nicht.
Betriebssteuer für Aktualität
Das fünfte ist die Betriebssteuer, aktuell zu bleiben. Inferenz-Stacks entwickeln sich rasch: llama.cpp, vLLM, die verschiedenen CUDA-Treiberschichten, die Container-Runtimes, in denen sie laufen, und die Modellformate selbst sehen alle nahezu monatlich relevante Sicherheits- und Stabilitätspatches. Ohne eine Patching-Disziplin, die diese Komponenten wie die Produktionsinfrastruktur behandelt, die sie geworden sind, häuft eine Organisation bekannte Schwachstellen an — genau jenes Fehlerbild, das die klassische Infrastruktursicherheit zwei Jahrzehnte gebraucht hat zu vermeiden.
Wie ein sicheres lokales Deployment aussieht
Ein verteidigungsfähiges lokales Deployment zu bauen ist nicht schwierig, erfordert aber bewusste Arbeit an drei Punkten des Lebenszyklus. Vor dem Deployment braucht das Team ein ehrliches Threat-Model, das die für dieses System spezifischen Angriffspfade kartiert: wer die API im Normalbetrieb erreichen kann, wer sie unter plausibler Fehlkonfiguration erreichen könnte, welche Daten hindurchfließen und welche Konsequenzen hätten, wenn das Modell kompromittiert, exfiltriert oder ersetzt würde. Dieselbe Vor-Deployment-Phase ist der richtige Zeitpunkt, Modell-Checksummen zu verifizieren und Netzwerksegmentierung so zu architektieren, dass die Inferenz-API nicht aus demselben Segment erreichbar ist wie Ihre internet-seitigen Dienste.
Beim Deployment lautet die täuschend einfache Regel, dass kein Endpunkt ohne Authentifizierung erreichbar sein darf — auch nicht innerhalb eines nominell vertrauenswürdigen Netzes. API-Schlüssel sind das Minimum; mutual TLS oder kurzlebige OIDC-Tokens sind angemessen für hochsensible Deployments. Jede Anfrage und Antwort sollte in einem Speicher protokolliert werden, den die Inferenz-Anwendung selbst nicht modifizieren kann, denn ein Logging-System, das von der Anwendung kontrolliert wird, die es überwachen soll, ist kein echtes Logging-System. Ressourcenlimits — Token-Obergrenzen pro Anfrage, Rate-Limits pro Aufrufer, Request-Timeouts — schützen sowohl gegen missbräuchliches Verhalten als auch gegen das echte operative Risiko, dass ein außer Kontrolle geratener Inferenz-Job unbegrenzt GPU-Zeit konsumiert.
Im laufenden Betrieb sind Dependency-Updates mit derselben Ernsthaftigkeit zu behandeln wie Patches jeder anderen produktiven Komponente. CVE-Feeds für die konkret eingesetzten Komponenten zu abonnieren ist ein günstiger Weg, das konkret zu machen. Eine Neubewertung des Deployments gegen die aktuelle Bedrohungslandschaft sollte stattfinden, wann immer das zugrundeliegende Modell aktualisiert wird, wann immer in der öffentlichen Literatur neue Bedrohungserkenntnisse auftauchen, und mindestens jährlich, ob etwas Sichtbares sich geändert hat oder nicht.
Die OWASP LLM Top 10 als Basislinie
Die OWASP LLM Top 10 in der Ausgabe 2025 liefert eine brauchbare Basislinien-Checkliste für jedes LLM-basierte System und ist für lokale Deployments besonders nützlich, weil sie die Punkte ins Bewusstsein zwingt, die Cloud-Anbieter still für Sie behandelt haben. Prompt Injection (LLM01) und unsichere Ausgabeverarbeitung (LLM02) sind die beiden Punkte, die am direktesten mit dem Verlust anbieterseitiger Filterung korrespondieren. Offenlegung sensibler Informationen (LLM06) adressiert die Datenexfiltrationsszenarien, die entstehen, sobald Sie ein Modell auf internen Korpora fine-tunen oder ihm sensiblen Kontext zuführen. Vektor- und Embedding-Schwächen (LLM08) werden direkt relevant, sobald Sie Retrieval-Augmented Generation gegen Ihren eigenen Dokumentenspeicher deployen. Fehlinformation (LLM09) ist die Kategorie, die die Konsequenzen halluzinierter oder selbstbewusst falscher Outputs in operativen Settings adressiert. Ein Deployment durch jeden dieser Punkte zu führen, mit dokumentierten Befunden und Behebungen, ist eine vernünftige Basislinie vor der Produktivsetzung.
Fazit
Lokales Deployment ist für viele Organisationen die richtige Wahl, und für einige ist es die einzige Wahl, die KI-Einsatz überhaupt erlaubt. Aber es ist keine Sicherheits-Abkürzung. Es ist eine Verantwortungsübertragung — die Sicherheitsarbeit, die Ihr Cloud-Anbieter erbracht hat, ist nun Ihre Aufgabe, mit Ihren Werkzeugen, Ihren Menschen und Ihrer operativen Frequenz. Die Organisationen, die das richtig machen, behandeln ihre Inferenz-Stacks wie jede andere Produktionsinfrastruktur: mit Threat-Modelling vor dem Deployment, mit Sicherheitsprüfungen gegen eine explizite Checkliste, mit operativer Hygiene um Patching und Monitoring herum, und mit der Annahme, dass irgendwann etwas schiefgeht und der Audit-Trail dann echte Fragen beantworten muss.
Kontaktieren Sie uns, um Ihr lokales KI-Deployment zu besprechen
Dieser Artikel dient ausschließlich zu Informationszwecken und stellt keine Rechtsberatung dar.