Open-Weight-KI selbst hosten: fünf Kontrollen

Wer Open-Weight-KI sicher selbst hosten will, sollte den ersten Prompt erst zulassen, wenn fünf Kontrollen nachweislich funktionieren: vertrauenswürdige Modellartefakte, ein begrenzter Netzwerkpfad, getrennt verwaltete Geheimnisse, harte Ein- und Ausgabegrenzen sowie eine überwachte Notabschaltung. Eine erfolgreiche Inferenz allein ist kein Freigabenachweis.

Diese Kontrollen müssen mit dem Einsatz wachsen: Im Test genügt eine isolierte Umgebung ohne Echtdaten, im Pilot kommen definierte Nutzer und Alarmwege hinzu, in der Produktion braucht jede Freigabe einen Verantwortlichen und reproduzierbare Nachweise. Das NIST-Profil für generative KI ordnet vorgeschlagene Maßnahmen den Funktionen Govern, Map, Measure und Manage zu und betrachtet Risiken über verschiedene Phasen des KI-Lebenszyklus.

1. Herkunft und Format der Gewichte kontrollieren

Ein verändertes Modellartefakt wird bei der isolierten Prüfung von Revision und Prüfsumme vor dem Laden abgewiesen.

Die erste Kontrolle behandelt das Modell wie ein externes Softwareartefakt. Dokumentieren Sie Herausgeber, Repository, unveränderliche Revision, Lizenz, Dateiliste, Prüfsummen sowie die Versionen von Runtime, Tokenizer, Adaptern und zusätzlichem Code. Laden Sie diese Bestandteile zunächst in eine Quarantäne ohne Zugang zu Produktionsnetzen oder Geheimnissen.

Besonders kritisch sind Formate, deren Deserialisierung Code ausführen kann. Die Hinweise von Hugging Face zu Pickle erläutern dieses Risiko und stellen klar, dass der dort eingesetzte Import-Scanner keine vollständige Sicherheitsgarantie bietet. Bevorzugen Sie deshalb reine Gewichtsformate wie SafeTensors; ist ein Pickle-basiertes Artefakt unvermeidbar, sollte es nur in einer kurzlebigen, abgeschotteten Prüfzone analysiert und nicht mit Produktionsrechten geladen werden.

Nachweis: Ein Freigabemanifest verbindet Quelle und Revision mit Prüfsummen, erlaubtem Ladepfad und Scannergebnis. Ein Negativtest muss außerdem zeigen, dass das Deployment eine veränderte Datei oder eine nicht freigegebene Revision abweist.

2. Den Netzwerkpfad auf das Erforderliche reduzieren

Der Inferenzserver gehört nicht direkt ins Benutzer- oder öffentliche Netz. Nur ein authentisierendes Gateway sollte ihn erreichen; Verwaltungszugänge, Modell-Registry, Telemetrie und gegebenenfalls Vektordatenbank erhalten getrennte Regeln. Ausgehende Verbindungen bleiben standardmäßig gesperrt und werden nur für benannte Ziele freigegeben.

Der OWASP Large Language Model Security Verification Standard 2.0 nennt für selbst gehostete LLMs unter anderem Netzsegmentierung, ein aktuelles Instanzinventar, regelmäßige Updates, sichere Modellbeschaffung und nach Möglichkeit SafeTensors statt Pickle. Er verlangt außerdem Kontrollen für Geheimnisse, nicht vertrauenswürdige Ein- und Ausgaben, Protokollierung und Anomalieerkennung; Hosts für agentische Werkzeuge sollen von anderen internen Komponenten getrennt sein und keinen beliebigen ausgehenden Netzwerkzugriff erhalten.

Nachweis: Verbindungstests aus jedem relevanten Segment belegen die erlaubten und blockierten Pfade. Inventar und Firewall-Regeln müssen dabei dieselbe Instanz-ID, denselben Verantwortlichen und dieselbe freigegebene Modellrevision nennen.

3. Geheimnisse vom Modellprozess fernhalten

Das Modell benötigt in der Regel keine Zugangsdaten zu Datenbanken, Ticket-Systemen oder Cloud-Konten. Solche Rechte gehören in einen vorgeschalteten Dienst oder ein eng begrenztes Werkzeug, das Identität, Zweck und Parameter jedes Aufrufs prüft. Jedes Secret erhält minimale Rechte, eine begrenzte Gültigkeit, einen benannten Besitzer und einen Rotationsweg.

Umgebungsvariablen bilden keine ausreichende Grenze, wenn der Modellprozess sie lesen, Diagnoseausgaben erzeugen oder Unterprozesse starten kann. Binden Sie Secrets erst am aufrufenden Dienst ein, entfernen Sie sie aus Fehlermeldungen und Logs und unterbinden Sie ihre Verwendung in Test-Namespaces. Der Pilot läuft mit eigenen, nicht produktiven Zugangsdaten.

Nachweis: Ein automatisierter Test sucht nach Secrets in Modellausgaben, Fehlerseiten, Prozessumgebung und Protokollen. Ein Rotationstest belegt zusätzlich, dass ein entzogenes Token nicht mehr funktioniert und der berechtigte Dienst ein neues beziehen kann.

4. Eingaben und Ausgaben als nicht vertrauenswürdig behandeln

Manipulierte Eingaben und unerwartete Ausgabefelder werden an getrennten Validierungsgrenzen blockiert.

Eine Eingabegrenze ist mehr als ein Zeichenlimit. Das Gateway begrenzt Request-Größe, Kontextlänge, Dateitypen, Aufrufrate und zulässige Mandanten. Externe Dokumente, gespeicherte Gesprächsteile und Inhalte aus Retrieval-Systemen durchlaufen dieselben Kontrollen wie direkte Nutzereingaben, weil auch sie eine indirekte Prompt Injection transportieren können.

Auch die Ausgabe ist nicht vertrauenswürdig. Erwartet nachgelagerte Software JSON, muss sie neben der Syntax ein enges Schema mit erlaubten Feldern, Typen und Größen erzwingen. Modelltext darf weder als Shell-Befehl noch durch String-Verkettung als Datenbankabfrage oder ungeprüfter Werkzeugparameter ausgeführt werden; sensible Aktionen benötigen eine gesonderte Autorisierungsentscheidung.

Nachweis: Eine feste Negativtestsuite enthält überlange Prompts, unerlaubte Dateien, manipulierte Retrieval-Dokumente, zusätzliche JSON-Felder und Ausgaben mit Befehlsfragmenten. Bestanden ist die Kontrolle erst, wenn jede Probe am vorgesehenen Übergang blockiert wird und keine Nebenwirkung auslöst.

5. Protokollierung und Abschaltung gemeinsam testen

Ein kontrollierter Alarm stoppt neue Modellanfragen, entzieht Werkzeugrechte und erhält die Prüfprotokolle.

Protokolle müssen einen Vorfall rekonstruierbar machen, dürfen aber nicht selbst zum Datenabfluss werden. Erfassen Sie Zeit, pseudonymisierte Identität, Modellrevision, Richtlinienentscheidung, Latenz, Größenklasse, Werkzeugaufrufe und Fehlercode. Vollständige Prompts und Antworten sollten nur bei dokumentierter Notwendigkeit, mit Zugriffsschutz und definierter Löschfrist gespeichert werden; Secrets werden vor dem Schreiben entfernt.

Alarme brauchen eine ausführbare Reaktion. Legen Sie Schwellen für ungewöhnliche Last, wiederholte Richtlinienverstöße, Fehlerhäufungen und verdächtige Werkzeugaufrufe fest. Ein Kill Switch muss neue Anfragen stoppen und Werkzeugberechtigungen entziehen können; ein Rückfall auf eine bekannte freigegebene Revision ist nur sinnvoll, wenn auch diese Betriebsart vorher getestet wurde.

Nachweis: Lösen Sie im Pilot einen kontrollierten Alarm aus und prüfen Sie, ob Bereitschaft, Runbook und Abschaltweg tatsächlich greifen. Halten Sie fest, wer abschalten darf, wie der Zustand verifiziert wird, welche Beweise erhalten bleiben und welche Bedingungen für eine Wiederfreigabe gelten.

Freigaben für Test, Pilot und Produktion

Die fünf Kontrollen bleiben auf allen Stufen gleich, ihre Belege werden jedoch strenger. Eine praktikable Freigabefolge lautet:

Test: keine Echtdaten, keine Produktions-Secrets und kein freier Egress; Prüfsummen, Formatprüfung und Negativtests sind bestanden.
Pilot: benannte Nutzer und Verantwortliche, getrennte Zugangsdaten, aktive Alarme, festgelegte Aufbewahrung und ein erfolgreich erprobter Kill Switch.
Produktion: versioniertes Inventar, genehmigte Netzwerkregeln, automatisierte Policy-Tests, Rotation und Patchprozess, dokumentierte Alarmbereitschaft sowie eine formale Go-/No-go-Entscheidung.

Entscheidend ist nicht, ob das Modell grundsätzlich antwortet, sondern ob jede relevante Bedrohung einer wirksamen Kontrolle und einem aktuellen Beleg zugeordnet ist. Fehlt ein Beleg, bleibt die Instanz in der vorherigen Stufe.

Lesen Sie auch:

Open-Weight-KI selbst hosten: Fünf Kontrollen vor dem ersten Prompt