Was gehört zur AI-Lieferkette?
Zur Supply Chain zählen Modell- und Cloud-Provider, Hosting, APIs, Datenquellen, Frameworks, Libraries, Plugins, Vector Stores, Monitoring, Identitätsdienste und sämtliche Unterauftragnehmer. R-005 macht Abhängigkeiten, Datenflüsse, Verantwortlichkeiten und Änderungen transparent.
Warum Anbieterprüfung allein nicht reicht
Kettenrisiko
Eine Schwachstelle oder Änderung eines Subprozessors wirkt bis zum Kundenprozess.
Kontrollverlust
Modelle, Preise, Regionen, Policies oder APIs können sich kurzfristig ändern.
Nachweis
Verträge, Zertifikate und technische Konfiguration müssen zusammenpassen.
Exit
Daten, Wissen und Betrieb müssen bei Wechsel oder Ausfall beherrschbar bleiben.
Typisches Praxisbild
Ein Chatbot nutzt einen Modellanbieter, einen externen Vector Store und mehrere Plugins. Ein Plugin wechselt unbemerkt den Unterauftragnehmer und verarbeitet Prompts in einer anderen Region. Ohne Komponentenregister, Change Notification und Egress-Kontrolle bleibt dies unsichtbar.
Was BAIS in der Lieferkette klärt
- Welche Provider und Komponenten sind produktionskritisch?
- Welche Modelle, Versionen, APIs, Libraries und Plugins werden genutzt?
- Welche Daten erhält jede Komponente?
- Wo werden Daten verarbeitet und gespeichert?
- Welche Subprozessoren und Drittlandbezüge bestehen?
- Welche Zertifikate und Prüfberichte sind gültig und im Scope?
- Wie werden Änderungen, Incidents und Schwachstellen gemeldet?
- Welche SLA, RTO, RPO und Supportwege gelten?
- Wie funktionieren Export, Löschung, Wechsel und Notbetrieb?
- Wer genehmigt neue Provider oder Komponenten?
Prüfbare Kette statt Markenvertrauen
„Wir verwenden nur bekannte Anbieter.“
- Keine Komponentenliste
- Keine Datenwege
- Keine Subprozessoren
- Kein Exit
„Modell, Hosting, Vector Store und Monitoring sind versioniert erfasst. Datenregion, Training-Nutzung, Subprozessoren und SLA sind geprüft. Neue Plugins sind standardmäßig blockiert; Provider-Changes lösen Security- und Datenschutzreview aus.“
Wie Lieferkettenrisiko eingestuft wird
Severity: 0–2 vollständig geregelt · 3–5 wesentliche Anbieter bekannt · 6–8 teilweise unklar/wechselnd · 9–10 unbekannte Plugins oder ungeregelte Datenflüsse.
Was eingerichtet und nachgewiesen wird
Wer trägt welche Verantwortung?
Welche Regelwerke berührt R-005?
- ISO/IEC 27001-orientiert: Lieferantenbeziehungen, Cloud-Nutzung, Informationsübertragung, Schwachstellen, Änderungen, Incident und Business Continuity.
- DSGVO: Auftragsverarbeitung, Subprozessoren, Drittlandtransfer, technische und organisatorische Maßnahmen sowie Löschung.
- EU AI Act: Rollen und Verantwortlichkeiten entlang der AI-Wertschöpfungskette, technische Dokumentation und Post-Market-Pflichten.
- ISO/IEC 42001: Third-Party-Ressourcen, AI-Lebenszyklus, Verantwortlichkeit und kontinuierliche Überwachung.
Wie die Lieferkette kontrolliert wird
- Modelle, APIs, Packages, Images und Plugins mit Version und Hash inventarisieren.
- Dependencies, Container und Secrets automatisiert scannen.
- Provider-Zugriff über kontrollierte Gateways und Endpoint-Allowlist führen.
- Neue Tools und Plugins standardmäßig sperren und freigabepflichtig machen.
- API-Verhalten, Modellversion und Qualitätsgrenzen überwachen.
- Provider-Incidents mit internem Incident-Prozess verknüpfen.
- Datenexport, Providerwechsel, Fallback und sicheren Notbetrieb testen.
- Komponenten- oder Regionswechsel als verpflichtenden Reassessment-Trigger setzen.
Was Lieferkettenkontrolle schwach macht
Abhängigkeiten verständlich erklären
„R-005 dokumentiert alle Anbieter, Modelle, APIs, Plugins und Subprozessoren, die ein AI-System tragen. Wir prüfen Datenwege, Verträge, technische Konfiguration, Änderungen, Ausfallsicherheit und Exit – nicht nur den Namen oder das Zertifikat des Providers.“
„Eine AI-Lösung besteht aus einer Kette. Deshalb führen wir ein versioniertes Komponentenregister, prüfen Provider und Subprozessoren, begrenzen Endpoints und Plugins, überwachen Änderungen und definieren Incident-, Fallback- und Exit-Prozesse. ISO-27001-orientierte Lieferantenkontrollen verbinden vertragliche Assurance mit technischen Tests.“
„Der Provider ist ISO 27001 zertifiziert.“
Das ist ein wichtiger Nachweis. Zusätzlich prüfen wir Gültigkeit, Scope, konkrete Services, Kundenkonfiguration, Datenfluss und verbleibende Verantwortung.
„Wir können jederzeit wechseln.“
Das gilt erst als belastbar, wenn Datenexport, Formate, Ersatzprovider, Schlüssel, Löschung und Wiederanlauf praktisch getestet wurden.
„Plugins sind nur kleine Erweiterungen.“
Plugins können Prompts und Daten sehen oder Aktionen ausführen und sind deshalb Teil der sicherheitsrelevanten Lieferkette.
R-005 ist vollständig, wenn …
- alle Provider, Modelle, APIs, Libraries, Plugins und Subprozessoren erfasst sind.
- Datenwege, Regionen, Training-Nutzung und Verantwortlichkeiten feststehen.
- Due Diligence, Verträge, AVV, Zertifikate und Scope geprüft sind.
- Allowlist, Egress, Secrets und Dependency Scanning funktionieren.
- Change-, Vulnerability- und Incident-Meldungen geregelt sind.
- SLA, RTO/RPO, Monitoring, Fallback und Notbetrieb getestet sind.
- Export, Migration, Vertragsende und sichere Löschung nachweisbar sind.
- Owner, Restrisiko, Review-Zyklus und Change-Trigger vorliegen.