Ein produktives KI-System ist selten ein Modell. Es ist ein Modell plus Dutzende Komponenten: Bibliotheken, Konnektoren zu Werkzeugen, Konfigurationsdateien, Prompts, Datenquellen für das Retrieval und gehostete Dienste. Jede dieser Komponenten ist ein Glied einer Lieferkette, und Bedrohungsanalysen wie die ENISA Threat Landscape 2025 beschreiben Angriffe auf genau diese Glieder als wachsendes Risiko. Wer nur den Namen des Modellanbieters prüft, hat den kleinsten Teil geprüft.
Was zur Lieferkette eines KI-Systems gehört
| Komponente | Typisches Risiko | Kontrolle |
|---|---|---|
| Modell oder Modell-API | Stiller Versionswechsel, verändertes Verhalten, Ausfall | Version festschreiben, Testset bei jeder Änderung ausführen |
| Modellgewichte zum Selbstbetrieb | Manipulierte Dateien, unklare Herkunft, unklare Lizenz | Prüfsummen, vertrauenswürdige Bezugsquelle, Lizenz dokumentiert |
| Bibliotheken und Pakete | Schadcode in Abhängigkeiten, verwechselbare Paketnamen | Gepinnte Versionen, automatische Abhängigkeitsprüfung, Signaturen |
| Konnektoren und Werkzeug-Server | Übermäßige Rechte, unbekannter Code von Dritten | Rechte je Werkzeug, Quellcode-Durchsicht, Isolation |
| Prompts und Konfiguration | Unbemerkte Änderungen mit großer Wirkung | Versionierung, Review, Freigabe wie bei Code |
| Datenquellen für Retrieval | Manipulierte oder veraltete Dokumente | Freigabeprozess, Herkunftsnachweis, Tests gegen eingebettete Anweisungen |
| Gehostete Dienste | Ausfall, unklarer Datenzugriff, fehlender Export | Vertrag, Sicherung, geprüfter Exportpfad |
Die Tabelle zeigt, dass die meisten Kontrollen keine KI-spezifischen Werkzeuge erfordern. Sie sind Softwarehygiene, angewendet auf Komponenten, die viele Projekte bisher nicht als Software behandeln.
Drei Fragen an jede Komponente
Woher stammt sie? Welche Version ist im Einsatz? Wer hat sie freigegeben? Kann eine dieser Fragen für eine Komponente nicht beantwortet werden, ist sie ein unbekanntes Risiko, unabhängig davon, wie harmlos sie wirkt. Prompts und Konfigurationsdateien fallen bei dieser Prüfung am häufigsten durch, weil sie als Text und nicht als Code betrachtet werden.
Release-Checkliste vor jeder Änderung
- Die Änderung ist beschrieben, einschließlich der betroffenen Komponenten.
- Alle Versionen sind fixiert; kein Bestandteil aktualisiert sich selbstständig.
- Automatisierte Tests und das fachliche Testset, einschließlich der Angriffsfälle, wurden ausgeführt.
- Berechtigungen sind unverändert oder die Änderung ist begründet und freigegeben.
- Der Rückweg auf den vorherigen Stand ist vorhanden und wurde geprüft.
- Eine benannte Person hat freigegeben; Zeitpunkt und Ergebnis sind protokolliert.
Beispiel: Ein harmloses Update
Eine Hilfsbibliothek zur Textextraktion aus PDF-Dateien wird aktualisiert. Die neue Version behandelt Tabellen anders, das Retrieval findet bestimmte Passagen nicht mehr, und die Antworten des Systems werden unvollständig. Ohne festgeschriebene Versionen und ohne Testset fällt das erst nach Wochen über Beschwerden aus dem Kundenservice auf. Mit beidem wäre die Abweichung beim ersten Testlauf nach dem Update sichtbar gewesen und die Änderung hätte zurückgenommen werden können.
Wiederherstellbarkeit über Sicherung und Rückweg, minimale Rechte je Komponente, versionierte Konfiguration und ein Testset, das bei jeder Änderung läuft. Fehlt einer dieser vier Punkte, ist das System ein Experiment, kein Betrieb.
Wer die Lieferkette verantwortet
Die Verantwortung liegt nicht allein bei der IT-Sicherheit. Der Product Owner kennt die fachlichen Auswirkungen, die Entwicklung kennt die Abhängigkeiten, der Betrieb kennt die Ausfallwege. Alle drei gehören an den Tisch, wenn Komponenten hinzukommen oder wechseln. Wie eingebettete Anweisungen in Datenquellen abgewehrt werden, beschreibt der Beitrag zu Prompt Injection; wie Abweichungen im laufenden Betrieb erkannt werden, der Beitrag zum KI-Monitoring.