Definition: KI-Backup und Model Recovery umfassen alle Maßnahmen, um Machine-Learning-Systeme nach Datenverlust, Ausfall, Ransomware oder Manipulation in einen bekannten, vertrauenswürdigen Zustand zurückzuversetzen. Gesichert werden dabei nicht nur die Modellgewichte, sondern alle Bestandteile, die für Betrieb und Reproduzierbarkeit nötig sind. Ziel ist eine Wiederherstellung, deren Integrität nachweisbar ist.
Warum klassische Datensicherung nicht ausreicht
Ein KI-System besteht aus mehr als einer Datei. Wer nur den Server sichert, auf dem ein Modell läuft, kann nach einem Vorfall zwar den Dienst starten, weiß aber oft nicht, welche Modellversion mit welchen Daten und Einstellungen trainiert wurde. Zwei Annahmen halten sich hartnäckig und sind trotzdem falsch:
- „Wir können ja neu trainieren.“ Training ist häufig nicht deterministisch, dauert lange, verursacht erhebliche Rechenkosten – und die ursprünglichen Trainingsdaten sind vielleicht gelöscht, verändert oder selbst vom Vorfall betroffen.
- „Das Modell liegt beim Cloud-Anbieter.“ Bei eigenen Feinabstimmungen, Prompt-Konfigurationen und Wissensdatenbanken liegt die Verantwortung für die Wiederherstellung meist beim Unternehmen selbst.
Was gesichert werden muss
| Bestandteil | Beispiele |
|---|---|
| Modellartefakte | Gewichte, Checkpoints, Tokenizer, Adapter aus dem Fine-Tuning (z. B. LoRA) |
| Daten | Versionierte Trainings-, Validierungs- und Testdatensätze, Labels, Feature Store |
| Code und Umgebung | Trainings- und Inferenzcode, Abhängigkeiten mit Versionen, Container-Images |
| Konfiguration | Hyperparameter, Schwellenwerte, System-Prompts, Guardrail-Regeln |
| RAG-Komponenten | Quelldokumente, Vektordatenbank bzw. die Pipeline, mit der sie neu aufgebaut werden kann |
| Metadaten | Modell-Registry, Experiment-Tracking, Freigabeentscheidungen, Evaluationsergebnisse |
Werkzeuge wie MLflow (Modell-Registry, Experiment-Tracking) oder DVC (Datenversionierung) helfen, diese Bestandteile konsistent miteinander zu verknüpfen. Sie ersetzen aber keine eigentliche Datensicherung auf getrennten Systemen.
Typische Wiederherstellungsszenarien
- Ransomware: Verschlüsselte GPU-Server, Datenspeicher oder Registries. Hier zählen unveränderliche (immutable) und vom Produktivnetz getrennte Sicherungen.
- Data oder Model Poisoning: Wird eine Manipulation entdeckt, muss auf die letzte Version zurückgerollt werden, die nachweislich vor dem Eingriff entstanden ist. Das setzt voraus, dass Sie wissen, wann welche Daten ins Training eingeflossen sind.
- Fehlerhaftes Update: Ein neues Modell verschlechtert Ergebnisse oder verhält sich unerwartet. Ein schneller Rollback auf die vorherige freigegebene Version begrenzt den Schaden.
- Ausfall eines Anbieters: Ein externes Modell wird abgekündigt oder ist nicht erreichbar. Hier hilft ein dokumentierter Plan B, etwa ein alternatives Modell mit vorbereiteter Konfiguration.
Vorgehen in der Praxis
- Inventar erstellen: Erfassen Sie alle KI-Systeme mit ihren Bestandteilen und Abhängigkeiten, einschließlich externer Dienste.
- RTO und RPO festlegen: Bestimmen Sie je System, wie schnell es wieder laufen muss (Recovery Time Objective) und wie viel Datenverlust tolerierbar ist (Recovery Point Objective).
- 3-2-1-Regel anwenden: Drei Kopien, zwei unterschiedliche Medien, eine davon extern – ergänzt um eine unveränderliche oder offline gehaltene Kopie.
- Integrität absichern: Speichern Sie Prüfsummen und signieren Sie Modellartefakte, damit sich vor der Wiederherstellung prüfen lässt, dass nichts verändert wurde. Bevorzugen Sie sichere Formate wie safetensors gegenüber Pickle-basierten Dateien, die beim Laden Code ausführen können.
- Zugriffe trennen: Backup-Administration gehört nicht in dieselben Hände und Konten wie der ML-Betrieb.
- Wiederherstellung testen: Stellen Sie regelmäßig ein Modell vollständig in einer isolierten Umgebung wieder her und prüfen Sie es gegen Referenz-Testdaten. Ein Backup, dessen Wiederherstellung nie geübt wurde, ist ein Versprechen, keine Maßnahme.
- Löschpflichten berücksichtigen: Wenn Trainingsdaten personenbezogen sind, muss das Löschkonzept auch Sicherungen abdecken (Art. 17 DSGVO).
Regulatorischer Bezug
ISO/IEC 27001:2022 fordert in Anhang A, Maßnahme 8.13, Sicherungskopien von Informationen, Software und Systemen und deren regelmäßige Prüfung. Im BSI IT-Grundschutz beschreibt der Baustein CON.3 das Datensicherungskonzept. Für Einrichtungen im Anwendungsbereich von NIS2 nennt Art. 21 ausdrücklich Backup-Management und Wiederherstellung nach einem Notfall als Teil des Risikomanagements – das umfasst auch betriebskritische KI-Systeme. Für Hochrisiko-KI-Systeme verlangt der EU AI Act in Art. 15 Robustheit und Widerstandsfähigkeit; technische Redundanz, etwa Sicherungs- oder Notfallpläne, wird dort ausdrücklich als mögliches Mittel genannt.
Fazit
Ein KI-System ist nur so wiederherstellbar wie sein am schlechtesten gesicherter Bestandteil – und nur so vertrauenswürdig wie der Nachweis, dass das zurückgespielte Modell unverändert ist. SecTepe unterstützt dabei, KI-Systeme in Ihr Notfall- und Datensicherungskonzept aufzunehmen.
Häufige Fragen
Wie oft sollten Modelle gesichert werden?
Mindestens bei jeder freigegebenen Modellversion sowie vor jedem Deployment. Trainingsdaten und Konfigurationen sollten versioniert werden, sodass jede produktive Version reproduzierbar dokumentiert ist.
Muss ich ein extern bezogenes Sprachmodell selbst sichern?
Das Basismodell meist nicht, wohl aber alles, was Sie selbst beisteuern: Fine-Tuning-Adapter, Prompts, Wissensdatenbanken, Integrationscode und Konfigurationen.
Weitere Begriffe in „KI & Machine Learning“
- Adversarial Machine Learning
- AI Poisoning
- AI Red Teaming
- Algorithmic Accountability
- Algorithmic Bias (algorithmische Verzerrung)
- Chatbot-Sicherheit
- DSGVO-konforme KI-Systeme
- Edge AI
- EU AI Act Compliance
- Explainable AI (XAI)
- Federated Learning
- Homomorphe Verschlüsselung (Homomorphic Encryption)