LieferantenKI-Anbieter und Modelle prüfen.
Wer KI zukauft, kauft Risiken ein, die er nicht selbst kontrolliert. Diese Seite zeigt die Rollenteilung nach AI Act, die Ebenen der KI-Lieferkette, einen Fragenkatalog für die Due Diligence, Vertragsbausteine, Prüfpunkte für Modellartefakte und Auslöser für die laufende Überwachung.
Rechtsstand: 11. Oktober 2026. AI Act in der Fassung der Verordnung (EU) 2026/1744. EU-Recht (AI Act, NIS2, DORA), für Schweizer Unternehmen nur bei EU-Bezug anwendbar (Art. 2 AI Act). Die Fragen und Vertragsbausteine sind eigene Empfehlungen von STOP.LI (CC BY 4.0), keine Normtexte.
Geteilte
Verantwortung.
Bei zugekaufter KI verteilt sich die Verantwortung auf zwei Seiten. Der AI Act unterscheidet Anbieter (Provider) und Betreiber (Deployer). Betreiber von Hochrisiko-KI-Systemen müssen das System nach der Betriebsanleitung verwenden, den Betrieb überwachen, den Anbieter bei Auffälligkeiten informieren und automatisch erzeugte Protokolle mindestens sechs Monate aufbewahren, soweit diese ihrer Kontrolle unterliegen (Art. 26 Abs. 1, 5 und 6). Der Anbieter eines Hochrisiko-KI-Systems und ein Dritter, der Komponenten oder Dienste dafür liefert, regeln in einer schriftlichen Vereinbarung, welche Informationen, Fähigkeiten und welchen technischen Zugang der Anbieter für seine Pflichten braucht (Art. 25 Abs. 4).
Wer ein Hochrisiko-KI-System unter eigenem Namen vertreibt, wesentlich verändert oder die Zweckbestimmung so ändert, dass daraus ein Hochrisiko-KI-System wird, gilt als Anbieter und übernimmt dessen Pflichten (Art. 25 Abs. 1 Bst. a bis c). Das kann auch Betreiber treffen, die ein KI-System mit allgemeinem Verwendungszweck so einsetzen, dass daraus ein Hochrisiko-KI-System wird (Bst. c). Vertragliche Zusagen des Lieferanten ersetzen diese Prüfung nicht. Einordnung der Rollen: Regulierung DCH.
Wer macht
was.
Die Tabelle ist ein Ausgangspunkt für das Gespräch mit dem Lieferanten. Je nach Bereitstellungsform (API, verwaltete Plattform, selbst betriebenes Modell) verschiebt sich die Teilung. Die Architekturvarianten stehen in der Architektur-Referenz.
| Aufgabe | Lieferant | Ihre Organisation |
|---|---|---|
| Modellsicherheit und Training | Robustheit, Trainingsdaten, Schwachstellenbehebung des Modells | Prüfung der Nachweise, eigene Tests im Einsatzkontext |
| Plattform und Hosting | Infrastruktur, Mandantentrennung, Betrieb | Konfiguration, Zugriffsrechte, Datenklassen |
| Eingaben und Wissensdaten | Verarbeitung gemäss Vertrag | Auswahl, Klassifizierung und Freigabe der Daten |
| Ausgaben und Entscheide | Dokumentation von Fähigkeiten und Grenzen | Prüfung, menschliche Aufsicht, Verantwortung für Entscheide |
| Vorfälle | Meldung an Kunden, Unterstützung bei der Analyse | Eigene Meldewege, Erstreaktion, Behördenmeldungen |
Mehr als
ein Lieferant.
Hinter einem KI-Dienst stehen meist mehrere Parteien. Jede Ebene braucht einen Eintrag im KI-Inventar und eine Antwort auf die Frage, was bei ihrem Ausfall oder ihrer Kompromittierung geschieht.
| Ebene | Beispiele | Typisches Risiko | Leitfrage |
|---|---|---|---|
| Modellanbieter | Anbieter des Basismodells, API-Dienst | Eingabedaten werden für Training genutzt; Modelländerung ohne Ankündigung | Wer ändert das Modell, und wann erfahren wir es? |
| Plattform und Hosting | Cloud, Inferenzdienst, Gateway | Konzentration, Standort, Mandantentrennung | Wo laufen Daten und Modell, und wer hat Zugriff? |
| Unterauftragnehmer | Subprozessoren, Beschriftungsdienste, Sicherheitsdienste | Lange Ketten, die niemand überblickt | Welche Parteien sehen unsere Daten? |
| Daten und Wissensquellen | Datensätze, Embedding-Modelle, Wissensdatenbanken | Manipulierte oder lizenzrechtlich belastete Daten | Woher stammen die Daten, und wer darf sie ändern? |
| Modellartefakte | Vortrainierte Modelle, Adapter, Konvertierungen | Manipulation, fehlende Herkunft (Abschnitt unten) | Können wir Herkunft und Integrität belegen? |
| Software und Werkzeuge | Bibliotheken, Serving-Frameworks, Agenten-Werkzeuge | Verwundbare oder bösartige Komponenten | Steht die Komponente in der Stückliste? |
Agenten, MCP-Server und Werkzeugregister bilden eine eigene Lieferkette mit zusätzlichen Risiken. Sie ist auf Agenten und MCP beschrieben und hier nicht wiederholt.
Konzentrationsrisiko. Viele KI-Dienste hängen an wenigen Modell- und Cloud-Anbietern. NIS2 verlangt von wesentlichen und wichtigen Einrichtungen Massnahmen zur Sicherheit der Lieferkette, die auch die Beziehungen zu unmittelbaren Anbietern umfassen (Art. 21 Abs. 2 Bst. d). Bei der Wahl der Massnahmen sind die spezifischen Schwachstellen der Anbieter und die Qualität ihrer Cybersicherheitspraxis einschliesslich der Entwicklungsprozesse zu berücksichtigen (Art. 21 Abs. 3). Das NIST AI RMF sieht Richtlinien für Risiken durch Dritte (GOVERN 6.1) und Notfallprozesse für Ausfälle oder Vorfälle bei Dritten mit hohem Risiko vor (GOVERN 6.2).
Der Fragen-
katalog.
Stellen Sie die Fragen vor dem Vertragsabschluss und wiederholen Sie sie bei wesentlichen Änderungen. Die Tiefe richtet sich nach der Risikoklasse des Einsatzes (Risikobeurteilung). Der Katalog ist eine Auswahl, kein vollständiger Standard. Als frei zugängliche Vergleichsbasis eignet sich die AI Controls Matrix (AICM) der Cloud Security Alliance, Version 1.1.
| Thema | Frage | Gewünschter Nachweis |
|---|---|---|
| Training auf Kundendaten | Werden Eingaben, Ausgaben oder Feedback zum Training oder zur Verbesserung verwendet? Ist das abschaltbar? | Vertragsklausel, Konfigurationsbeleg |
| Speicherort und Zugriff | In welchen Regionen werden Daten verarbeitet, gespeichert und gesichert? Wer hat administrativen Zugriff? | Standortliste, Zugriffskonzept |
| Subprozessoren | Welche Unterauftragnehmer sind beteiligt, und wie werden Änderungen angekündigt? | Liste mit Funktion und Standort, Einspruchsrecht |
| Sicherheitsnachweise | Welche unabhängigen Prüfberichte oder Zertifikate gibt es, und was decken sie bei der KI-Komponente ab? | Bericht mit Geltungsbereich, nicht nur Zertifikat |
| Modelltests | Wurden Angriffstests wie Prompt Injection und Datenabfluss durchgeführt? Gibt es eine Modellbeschreibung (Model Card)? | Zusammenfassung der Testergebnisse |
| Vorfallmeldung | Innerhalb welcher Frist und über welchen Kanal meldet der Lieferant Vorfälle? | Vertragliche Frist, Kontaktstelle |
| Neue KI-Funktionen | Wie werden neue KI-Funktionen in bestehenden Produkten angekündigt, und können wir sie deaktivieren? | Änderungsprozess, Schalter pro Mandant |
| Modellwechsel | Wie werden Modellversionen eingeführt und ausgemustert? Gibt es Vorankündigung und Übergangszeit? | Versionspolitik, Supportzeitraum |
| Protokolle | Welche Protokolle stehen uns zur Verfügung, und wie lange? | Protokollbeschreibung, Exportfunktion |
| Exit | Wie erhalten wir Daten, Konfigurationen und Feinabstimmungen zurück, und was geschieht mit Kopien? | Rückgabeformat, Löschbestätigung |
Wenn der Lieferant keine Auskunft gibt, ist das ein Befund. Halten Sie ihn im Risikoregister fest und entscheiden Sie bewusst über die Risikoakzeptanz.
Was in den
Vertrag gehört.
Die Bausteine sind Empfehlungen für die Verhandlung. Rechtliche Formulierungen gehören in die Hand von Recht und Einkauf. Muss der Vertrag zusätzlich Vorgaben aus dem Finanzaufsichtsrecht erfüllen, gelten die Anforderungen im Kasten unten.
| Baustein | Inhalt |
|---|---|
| Nutzungsrechte | Zulässiger Zweck, Nutzerkreis, Ausschluss der Datennutzung zum Training ohne Zustimmung, Eigentum an Ausgaben |
| Haftung | Haftung für Datenabfluss, Rechtsverletzungen und fehlerhafte Zusagen, Abgrenzung zur Nutzung ausserhalb der Betriebsanleitung |
| Geistiges Eigentum | Freistellung bei Urheberrechtsansprüchen, Umgang mit Lizenzen von Trainings- und Wissensdaten |
| Audit und Nachweise | Recht auf Prüfberichte und, bei hoher Kritikalität, auf Audit; alternative Nachweisformen, wenn Rechte anderer Kunden betroffen sind |
| Meldefristen | Frist für Sicherheitsvorfälle, Datenschutzverletzungen und wesentliche Modelländerungen; Unterstützung bei der Analyse |
| Unterauftragnehmer und Standorte | Liste, Vorankündigung von Änderungen, Einspruchs- oder Kündigungsrecht |
| Informationspflichten nach AI Act | Zusicherung der Informationen und des Zugangs, die der Anbieter eines Hochrisiko-KI-Systems für seine Pflichten braucht (Art. 25 Abs. 4) |
| Exit | Rückgabe und Löschung von Daten, Übergangsphase, Unterstützung beim Wechsel |
Modelle sind
Fremdcode.
Die OWASP Top 10 for LLM Applications 2026 führen Supply Chain als LLM04:2026. Genannt werden unter anderem verwundbare oder veraltete Komponenten, Lizenzrisiken, manipulierte vortrainierte Modelle, fehlende Herkunftsnachweise bei unsignierten Artefakten, verwundbare Adapter sowie unklare Nutzungsbedingungen, die zur Nutzung von Daten für das Training führen können. Die Leitlinien von NCSC und CISA empfehlen, importierte Modelle und serialisierte Gewichte wie nicht vertrauenswürdigen Fremdcode zu behandeln, sie zu scannen und zu isolieren, sowie kryptografische Prüfsummen und Signaturen für Modelldateien und Datensätze zu berechnen und zu teilen.
- Quelle und Herausgeber des Modells sind dokumentiert; Namensähnlichkeiten wurden geprüft.
- Artefakte werden per Prüfsumme oder Signatur fixiert, nicht über veränderliche Bezeichnungen wie «latest».
- Unsichere Serialisierungsformate (z. B. Pickle) werden vermieden oder in isolierter Umgebung geprüft.
- Lizenz, Nutzungsbeschränkungen und Modellbeschreibung sind erfasst.
- Verhalten wird im Einsatzkontext getestet; eine statische Prüfung allein belegt keine Verhaltenssicherheit (OWASP LLM04:2026).
- Das Modell steht mit Version in der Stückliste (SBOM und VEX, Software Supply Chain).
Der Code
als Massstab.
Anbieter von KI-Modellen mit allgemeinem Verwendungszweck (GPAI) haben eigene Pflichten. Sie müssen die technische Dokumentation führen, nachgelagerten Anbietern Informationen bereitstellen, eine Urheberrechtsstrategie einführen und eine Zusammenfassung der Trainingsinhalte veröffentlichen (Art. 53 Abs. 1). Bei Modellen mit systemischem Risiko kommen unter anderem Modellbewertung mit Angriffstests, Meldung schwerwiegender Vorfälle und angemessene Cybersicherheit hinzu (Art. 55 Abs. 1). Bis zu einer harmonisierten Norm können sich Anbieter auf Praxisleitfäden stützen (Art. 53 Abs. 4, Art. 55 Abs. 2).
Der GPAI-Verhaltenskodex (Code of Practice) wurde am 10. Juli 2025 veröffentlicht. Er ist freiwillig und besteht aus den Kapiteln Transparenz, Urheberrecht sowie Sicherheit und Gefahrenabwehr. Die Kommission und das KI-Gremium haben ihn als geeignetes Mittel bestätigt, um die Einhaltung nachzuweisen. Für die Lieferantenprüfung bedeutet das: Fragen Sie, ob der Anbieter den Kodex unterzeichnet hat, und fordern Sie andernfalls die alternativen Nachweise. Ein Anbieter, der weder den Kodex befolgt noch eine harmonisierte Norm einhält, muss geeignete alternative Verfahren aufzeigen, die die Kommission bewertet (Art. 53 Abs. 4). Die Modelldokumentation nach Art. 53 Abs. 1 Bst. b gehört in Ihre Due-Diligence-Akte.
Auslöser für
die Neuprüfung.
Eine Prüfung beim Einkauf genügt nicht. Legen Sie fest, welche Ereignisse eine Neubeurteilung auslösen, und weisen Sie sie dem AI-Owner und dem Lieferantenmanagement zu. Werkzeuge dafür beschreiben Vendor Risk und Vendor Monitoring.
| Auslöser | Reaktion |
|---|---|
| Modellwechsel, neue Version oder Ausmusterung | Regressionstests, Prüfung von Leistung und Sicherheitsverhalten, Freigabe durch den AI-Owner |
| Neue KI-Funktion im bestehenden Produkt | Inventar aktualisieren, Risikoklasse prüfen, Funktion bis zur Freigabe deaktivieren |
| Änderung bei Subprozessoren oder Standorten | Auswirkung auf Datenschutz und Konzentration beurteilen, Einspruchsfrist nutzen |
| Sicherheitsvorfall beim Lieferanten | Eigene Betroffenheit klären, Zugangsdaten rotieren, Protokolle sichern |
| Änderung der Nutzungsbedingungen | Recht und Datenschutz prüfen, Zustimmung dokumentieren |
| Neue Schwachstelle in einer Komponente | Betroffenheit anhand der Stückliste klären, Korrektur nachverfolgen |
| Neuer Rechtsakt oder Behördenhinweis | Vertrag und Nachweise gegen die neue Anforderung abgleichen; Fristen im Fristenkalender |
EU, DORA (Verordnung (EU) 2022/2554). Für Finanzunternehmen nach Art. 2 sind KI-Anbieter IKT-Drittdienstleister, soweit sie IKT-Dienstleistungen erbringen. Art. 28 verlangt ein Informationsregister über alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern (Abs. 3), eine Prüfung vor Vertragsabschluss einschliesslich Konzentrationsrisiko (Abs. 4), Kündigungsrechte (Abs. 7) und Ausstiegsstrategien für kritische oder wichtige Funktionen (Abs. 8). Art. 29 betrifft das Konzentrationsrisiko und Unterauftragsketten, Art. 30 die Mindestinhalte der Verträge, darunter Standorte, Unterstützung bei Vorfällen sowie bei kritischen oder wichtigen Funktionen Audit- und Zugangsrechte und Ausstiegsfristen. Die KI-Anbieter gehören ins Register, die Fragen und Bausteine oben ergänzen die DORA-Mindestinhalte.
Schweiz, FINMA-Aufsichtsmitteilung 08/2024. Die FINMA nennt die Abhängigkeit von Drittparteien wie Anbietern von Modellen in einem konzentrierten Markt als Risiko. Bei Outsourcing beurteilte sie unter Kap. 2.1 (Governance), ob zusätzliche Tests, Kontrollen und Vertragsklauseln zu Verantwortlichkeiten und Haftung bestehen und ob die Dritten über die nötigen Fähigkeiten verfügen. Beaufsichtigte hatten teilweise Mühe festzustellen, ob zugekaufte Anwendungen KI enthalten und ob eine ausreichende Due Diligence vorliegt.
Deutschland, BaFin. Die unverbindliche Orientierungshilfe zu IKT-Risiken beim Einsatz von KI (18.12.2025) ordnet das Drittparteienrisiko nach DORA ein. Im Abschnitt «Cloud-Spezifika beim Betrieb von KI» empfiehlt sie unter anderem Risikobewertung und Due Diligence vor Vertragsschluss, Transparenz über Unterauftragnehmer und Standorte sowie Exit-Strategien; im Abschnitt davor (Kap. IV.1) die Einbindung der Anbieter in das Geschäftsfortführungsmanagement. Das Framework mit Governance, Control Standard und Security Baseline: AI Act Framework für Finanzinstitute.
Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt bei der Prüfung von KI-Anbietern und Modellen. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.
- Verordnung (EU) 2024/1689 (AI Act), Art. 2, 25, 26, 53, 55 (EU, 13.06.2024)
- Verordnung (EU) 2026/1744, Digital-Omnibus zur KI, Änderung Art. 25 Abs. 4 (EU, 08.07.2026)
- Verordnung (EU) 2022/2554 (DORA), Art. 2, 28, 29, 30 (EU, 14.12.2022)
- Richtlinie (EU) 2022/2555 (NIS2), Art. 21 Abs. 2 Bst. d und Abs. 3 (EU, 14.12.2022)
- General-Purpose AI Code of Practice (Europäische Kommission, 10.07.2025)
- NIST AI 100-1, AI Risk Management Framework 1.0, GOVERN 6.1 und 6.2 (NIST, 01/2023)
- OWASP Top 10 for LLM Applications 2026, LLM04:2026 Supply Chain (OWASP GenAI Security Project, 2026, CC BY-SA 4.0)
- Guidelines for secure AI system development (NCSC/CISA u. a., 27.11.2023)
- AI Controls Matrix (AICM) v1.1 (Cloud Security Alliance, 22.06.2026)
- FINMA-Aufsichtsmitteilung 08/2024, Kap. 2 und 2.1 (FINMA, 18.12.2024)
- BaFin, Orientierungshilfe zu IKT-Risiken beim Einsatz von KI (BaFin, 18.12.2025)
Zitierte Fremdinhalte unterliegen der Lizenz ihrer Herausgeber. Die Seite ist eine Orientierung, keine Rechtsberatung.
© 2026 4T2 Solutions GmbH. Text und eigene Diagramme stehen unter CC BY 4.0.