KI-Modelle einkaufen: Wareneingangsprüfung nach ISO/IEC 27090

Kein Fertigungsbetrieb baut ein Zukaufteil ein, das nicht durch den Wareneingang gegangen ist. Lieferschein gegen Bestellung. Sichtprüfung. Bei kritischen Teilen das Prüfzeugnis. Bei KI-Modellen fehlt dieser Schritt fast überall. Das Modell wird heruntergeladen, gestartet und daran gemessen, ob die Antworten gut klingen. Fertig.

Die neue ISO/IEC 27090:2026 gibt der Lieferkette einen eigenen Abschnitt (5.5) und im Anhang einen zweiten (B.3). Ihr Ausgangspunkt: KI bringt neben Code und Softwarebausteinen weitere Bestandteile mit, die geschützt werden müssen. Vortrainierte Modelle. Trainings-, Test- und Validierungsdatensätze. Die Werkzeuge, mit denen entwickelt wird (5.5.1, 5.5.2).

Wie ernst das ist, zeigen drei dokumentierte Fälle aus den letzten vier Jahren. Aus ihnen und aus der Norm ergibt sich eine Prüfung, die auch ein Betrieb ohne eigene KI-Abteilung leisten kann. Oder von seinem Dienstleister verlangen.

Eine Modelldatei kann ein Programm sein

Der unterschätzte Punkt zuerst. Viele Modelle werden in Formaten verteilt, die beim Laden Code ausführen können. Das verbreitete Pickle-Format von Python ist so gebaut. Es speichert die Zahlen des Modells und dazu Anweisungen, wie die Daten wieder zusammengesetzt werden. Wer die Datei lädt, führt diese Anweisungen aus. Laden ist hier schon Ausführen.

Die Norm beschreibt das nüchtern. Über Hintertüren und Schwachstellen lässt sich Schadsoftware in die Dateien mit den Modellgewichten einbetten, bis hin zur Ausführung beliebigen Codes (B.4.2). Als Gegenmittel nennt sie sichere Formate wie safetensors, die beim Laden keinen Code ausführen, dazu Prüfsummen, Signaturen und vertrauenswürdige Quellen (B.4.3).

Ein Laborszenario ist das nicht. Im Februar 2024 berichtete der Sicherheitsanbieter JFrog von rund 100 Modellen mit Schadfunktion auf Hugging Face, der bekanntesten öffentlichen Plattform für KI-Modelle. Eines davon öffnete beim Laden mit PyTorch eine Rückverbindung zu einem fremden Server, eine sogenannte Reverse Shell. Über diese Verbindung lassen sich Befehle auf dem Rechner ausführen, auf dem das Modell geladen wurde. Die Plattform markierte verdächtige Dateien als unsicher. Den Download sperrte sie nach Angaben von JFrog nicht.

Ein Jahr später folgte die nächste Stufe. ReversingLabs berichtete im Februar 2025 von zwei Modellen, deren Schadcode der Scanner der Plattform nicht erkannt hatte. Der Trick war schlicht. Die Dateien waren mit 7z gepackt statt wie üblich mit ZIP, und der Schadcode stand ganz vorn in einer absichtlich beschädigten Datei. Der Scanner meldete den Fehler an der kaputten Stelle und übersah, was davor stand. Beim Laden lief genau dieser vordere Teil zuerst. Hugging Face entfernte die Modelle nach der Meldung in weniger als 24 Stunden und besserte den Scanner nach.

Die Lehre daraus ist einfach. Ein Scanner, der nach bekannten gefährlichen Mustern sucht, arbeitet wie eine Sperrliste. Er findet, was er kennt. Sicher wird es erst, wenn die Datei gar keinen Code mitbringen kann. Darum steht in meiner Prüfliste das Format vor dem Scan.

Auch die Werkzeuge gehören zur Lieferkette

Die Norm zählt die Entwicklungsumgebung ausdrücklich zur Lieferkette: Notebook-Plattformen, MLOps-Werkzeuge, Trainingsframeworks (5.5.2). Sie laufen ständig, sehen Trainingsdaten und Modellparameter und sind damit ein lohnendes Ziel. Unter den Angriffswegen nennt sie Schadcode in KI-Bibliotheken, der vertrauliche Daten abzieht oder das Verhalten des Modells verändert (5.5.4).

Das bekannteste Beispiel traf PyTorch, eines der verbreitetsten KI-Frameworks. Zwischen dem 25. und 30. Dezember 2022 bekam jeder, der die Vorabversion für Linux per pip installierte, ein fremdes Paket namens torchtriton mit. Jemand hatte es unter genau diesem Namen im öffentlichen Paketverzeichnis PyPI hochgeladen. Das öffentliche Verzeichnis hatte Vorrang vor dem eigenen Verzeichnis von PyTorch. Sobald das Paket geladen wurde, sammelte ein Programm darin Systemdaten, SSH-Schlüssel und bis zu tausend Dateien aus dem Benutzerordner und schickte sie über DNS-Anfragen nach außen. Die stabile Version war nicht betroffen.

Im Fachjargon heißt das Dependency Confusion. Für den Mittelstand ist die Übersetzung wichtiger. Ihr Dienstleister installiert für ein KI-Projekt Dutzende Bibliotheken, und jede bringt eigene Abhängigkeiten mit. Wer nicht festhält, welche Version aus welcher Quelle kam, kann im Ernstfall nicht einmal sagen, ob er betroffen ist. PyTorch konnte es seinen Nutzern sagen: mit einem Prüfbefehl und der Prüfsumme der Schadsoftware.

Das Grundproblem benennt die Norm in 5.5.3. Bei klassischer Software ist meist klar, wer welchen Teil geschrieben hat. Bei KI fließen Beiträge vieler Lieferanten ineinander, in Daten, in Gewichten, in Code. Eine Schwachstelle kann an jeder Stelle der Kette entstehen und sich so leise zeigen, dass klassische Sicherheitstests sie nicht finden.

Nachtrainieren reinigt nichts

Der naheliegende Einwand lautet: Wir nehmen das Modell nur als Grundlage und trainieren es mit eigenen Daten nach. Für genau diesen Fall hat die Norm einen eigenen Begriff. Liefert ein Anbieter ein absichtlich manipuliertes Modell, und der Kunde trainiert oder justiert es weiter, bleibt das unerwünschte Verhalten erhalten. Die Norm nennt das Transfer Learning Attack (6.7.1).

Hintertüren in Modellen sind tückisch, weil sie im Normalbetrieb schlafen. Das Modell beantwortet tausend Testfragen richtig und springt erst bei einem bestimmten Auslöser um. Ein Wort. Ein Muster im Bild. Eine Kombination von Messwerten (5.5.4). Ein Qualitätstest mit Ihren eigenen Daten findet so etwas nur durch Zufall.

Bei der Erkennung bleibt die Norm ehrlich. Wird ein Modell im eigenen Haus verändert, kann die allgemeine Angriffserkennung das bemerken. Kommt es vergiftet vom Lieferanten, helfen vor allem Informationen über bekannte bösartige Quellen und Modelle (6.7.3). Ein Verfahren, das eine Hintertür sicher ausschließt, nennt sie nicht. Ob Trainingsdaten vergiftet wurden, lässt sich nach ihrer Einschätzung bis heute nicht verlässlich automatisch erkennen (6.2.3).

Ein Modell aus unbekannter Quelle wird durch Nachtrainieren nicht vertrauenswürdiger. Es wird nur Ihres.

Daraus folgt eine unbequeme Regel. Die Herkunft wiegt schwerer als jeder Test. Für den Betrieb rät die Norm zu Zero-Trust-Prinzipien: Modelle abgeschottet halten und verschlüsselt speichern, Zugriff nur so lange und so weit wie nötig, vor dem Einsatz mehrere Prüfstufen (6.7.4). Wer ein Modell auf einem Rechner laufen lässt, der nicht ins ganze Firmennetz sieht, begrenzt den Schaden, falls doch etwas durchrutscht.

Die Wareneingangsprüfung in sieben Schritten

Was heißt das für einen Betrieb, der ein offenes Modell herunterlädt oder eines vom Dienstleister bekommt? Ich prüfe in dieser Reihenfolge, angelehnt an 5.5.5, B.4 und 6.11.4:

• Herkunft: Wer hat das Modell veröffentlicht, ist das Konto des Herstellers bestätigt, gibt es eine Modellbeschreibung mit Trainingsdaten, Lizenz und Grenzen? Ohne nachvollziehbaren Absender kommt kein Modell ins Haus.
• Format: Gewichte nur in Formaten, die beim Laden keinen Code ausführen, etwa safetensors. Liegt nur eine Pickle-Datei vor, wird sie abgelehnt oder in einer abgeschotteten Umgebung ohne Netzzugang umgewandelt.
• Unversehrtheit: Prüfsumme gegen die Angabe des Herstellers abgleichen, Signatur prüfen, wo es eine gibt. Die Prüfsumme kommt in die Akte.
• Scan: Die Datei mit einem Werkzeug prüfen, das gefährliche Operationen in Modelldateien sucht (B.4.2). Ein sauberer Scan ist ein Indiz. Ein Freispruch ist er nicht.
• Abhängigkeiten: Bibliotheken nur aus einer festgelegten Quelle, Versionen festschreiben, regelmäßig gegen bekannte Schwachstellen prüfen (5.5.5).
• Verhaltenstest: Vor der Freigabe gegen einen festen Testsatz prüfen, dazu gezielte Angriffsversuche, auch auf Auslöser, die das Modell umschalten könnten (5.5.5, B.3.3).
• Freigabe und Akte: Wer hat freigegeben, welche Version, welche Prüfsumme, welche Quelle, welche Lizenz. Abgelegt so, dass niemand die Einträge unbemerkt ändern kann (6.11.4).

Mit der Freigabe endet die Prüfung nicht. Die Norm empfiehlt, die Leistung des Modells laufend auf Anzeichen einer Kompromittierung zu beobachten (5.5.5). Kippt die Trefferquote ohne erkennbaren Grund, ist das ein Fall für die Informationssicherheit. Mit einem besseren Prompt ist er nicht erledigt.

Für die Akte ist Abschnitt 6.11.4 die beste Vorlage. Er beschreibt eine Herkunftsdokumentation über den ganzen Lebenszyklus: Trainings- und Eingabedaten, Architektur, Softwareabhängigkeiten, Konfiguration, Verarbeitungsschritte. Bei Trainingsdaten gehören Quelle, Lizenzbedingungen, Vorverarbeitung und beteiligte Dritte dazu. Die Einträge sollen mit digitalen Signaturen gegen Änderung geschützt sein und für interne Audits und die Aufarbeitung nach einem Vorfall bereitliegen.

Das ist dieselbe Rückverfolgbarkeit, die jeder Zulieferer der Automobilindustrie kennt. Charge + Prüfzeugnis + Freigabe. Nur heißt die Charge hier Modellversion. Und das Prüfzeugnis ist eine Prüfsumme, die Sie selbst nachrechnen können.

Was in den Vertrag gehört

Nicht jeder Betrieb lädt Modelldateien selbst herunter. Je nach Einkaufsweg verschiebt sich die Prüfung von der Datei zum Vertrag:

Für Verträge nennt Anhang B.3.3 vier Punkte. Die Sicherheit der Lieferkette gehört in die Verträge mit allen, die Lerndaten, vortrainierte Modelle, Entwurf oder Entwicklung liefern. Die Lieferanten werden in Sicherheit geschult. Die Übergabe der Spezifikation, etwa der Modellbeschreibung, verdient besondere Sorgfalt. Und gelieferte Modelle werden vor dem Einsatz ausreichend mit gezielten Angriffen getestet, im Fachjargon Red Teaming.

In Vertragssprache übersetze ich das so. Der Lieferant nennt Basismodell, Version und Quelle. Er liefert Prüfsummen und, wo möglich, signierte Dateien. Er beschreibt die Trainingsdaten so weit, dass Sie Lizenz und Herkunft beurteilen können. Er meldet jede bekannte Schwachstelle in den verwendeten Komponenten innerhalb einer festen Frist. Und er legt einen Testbericht vor, der Angriffsversuche enthält und nicht nur die Genauigkeit.

Beim Modell als Dienst kommt ein Punkt dazu, den Anhang B.6.1 ausdrücklich nennt. Wer ein Modell in der Cloud mit eigenen Unterlagen feinjustieren lässt, teilt diese Unterlagen mit dem Cloud-Dienst. Die Bedrohungslage ändert sich damit. Das gehört vorher in die Risikobeurteilung und in den Vertrag.

Für die Lieferkette verweist die Norm selbst auf die Maßnahmen 5.19 bis 5.23 und 8.30 der ISO/IEC 27002 (Hinweis zu 5.5). Wer nach ISO/IEC 27001 zertifiziert ist, hat Lieferantenbeziehungen, Lieferantenvereinbarungen und die IKT-Lieferkette also schon im Managementsystem (A.5.19 bis A.5.21). In ISO/IEC 42001 hängt das Thema nach meiner Zuordnung an A.10.3 für Lieferanten, an A.7.5 für die Herkunft der Daten und an A.6.2.4 für die Prüfung vor dem Einsatz. Die Wareneingangsprüfung ist der Ablauf, der diese Maßnahmen für KI prüfbar macht.

Was ich als Auditor zuerst frage

Bei eingekaufter KI frage ich zuerst nach einer einzigen Angabe: der Prüfsumme der Modelldatei, die gerade läuft, samt Version und Quelle. Kommt sie aus der Akte, gibt es einen Wareneingang. Muss erst jemand suchen, gab es einen Download.

Die gute Nachricht steckt in derselben Frage. Nichts davon braucht ein KI-Labor. Prüfsummen abgleichen, Formate festlegen, Quellen freigeben, eine Akte führen: Das ist Handwerk aus der Informationssicherheit, angewendet auf ein neues Zukaufteil. Die 27090 liefert die Begründung, warum dieses Teil denselben Wareneingang verdient wie jede Schraube mit Prüfzeugnis.