ISO 42001 Supply Chain: KI-Lieferanten bewerten und managen
ISO 42001 Supply Chain Management regelt die Bewertung und Steuerung von KI-Lieferanten und Drittanbietern — von der Due Diligence bis zum laufenden Monitoring. Unternehmen bleiben für Risiken, Ergebnisse und den rechtskonformen Betrieb verantwortlich, auch wenn Modelle, APIs, Cloud-Plattformen oder Trainingsdaten von OpenAI, Microsoft, Google oder anderen Anbietern stammen.
Letzte Aktualisierung: 23. März 2026
Die operative Relevanz ist hoch: Viele Unternehmen arbeiten heute mit 5 bis 10 KI-bezogenen Lieferanten, vom Foundation-Model-Anbieter über Hosting und Vektordatenbanken bis zu Annotierungs- oder Monitoring-Diensten. Gleichzeitig nutzen nach verschiedenen Marktbeobachtungen inzwischen deutlich mehr als 70 Prozent der Organisationen externe KI-Dienste oder GenAI-Plattformen statt ausschließlich eigener Modelle. Genau deshalb ist Lieferantensteuerung kein Randthema, sondern ein Kernbaustein des AI Management Systems. Wer zuerst die Grundlagen von ISO 42001 einordnen will, findet den Überblick im ISO-42001-Leitfaden, die Normeinordnung im Glossar zu ISO 42001 und den Risikokontext im Glossar zur KI-Risikobewertung.
KI-Supply-Chain-Risiken im Überblick
KI-Supply-Chain-Risiken entstehen, weil Unternehmen zentrale Fähigkeiten an externe Anbieter auslagern, ohne die Verantwortung auszulagern. Typische Abhängigkeiten betreffen Foundation Models, Hosting, Fine-Tuning, Datenspeicher, Sicherheitsfunktionen und branchenspezifische SaaS-Produkte mit eingebauter KI.
Die erste große Gefahr ist Konzentrationsrisiko. Wenn ein Unternehmen sein internes Wissenssystem, Chatbot-Frontend, Dokumentenanalyse und Code-Assistenz auf einen einzelnen Hyperscaler oder ein einziges Modell-Ökosystem stützt, entsteht ein Single Point of Failure. Technische Störungen, Preissprünge, API-Limits oder geänderte Nutzungsbedingungen wirken dann unmittelbar auf Geschäftsprozesse. Besonders kritisch ist das in regulierten Branchen wie Finanzdienstleistung, Gesundheit, Industrie oder Personalwesen, weil dort ein Ausfall nicht nur Produktivität kostet, sondern Compliance- und Haftungsfragen auslöst.
Die zweite Gefahr ist Black-Box-Abhängigkeit. Viele Drittanbieter liefern hohe Leistungsfähigkeit, aber nur begrenzte Transparenz zu Trainingsdaten, Modellgrenzen, Bias-Tests, Sicherheitsmechanismen oder Änderungen am Modellverhalten. Das ist für Einkauf und IT oft noch beherrschbar, wird aber für Compliance, Datenschutz und Fachbereiche problematisch, sobald KI-Ausgaben in Entscheidungen einfließen. Wer etwa Bewerbungen, medizinische Dokumente, Verträge oder Kundenanfragen mit externer KI verarbeitet, muss erklären können, warum ein Anbieter geeignet war und wie Risiken kontrolliert werden.
Die dritte Gefahr ist vierte-Partei-Risiko. Ein SaaS-Anbieter nutzt häufig selbst wieder OpenAI, Anthropic, Azure, AWS, Google oder spezialisierte Unterauftragnehmer für Moderation, Labeling oder Infrastruktur. Dadurch wird Ihre direkte Lieferkette schnell mehrstufig. Ohne Offenlegung zentraler Subunternehmer wissen Sie unter Umständen nicht, welche Modelle tatsächlich im Hintergrund arbeiten, in welchen Regionen Daten verarbeitet werden oder wie ein Sicherheitsvorfall eskaliert werden müsste.
Die vierte Gefahr ist schleichende Veränderung. KI-Dienste ändern sich durch Modellupdates, neue Trainingsstände, geänderte Sicherheitsfilter, veränderte Token-Limits oder neue Standardkonfigurationen oft schneller als klassische Software. Ein Tool, das im Januar stabile Ergebnisse liefert, kann im April andere Schwächen, Halluzinationsmuster oder Performance-Eigenschaften zeigen. Deshalb genügt einmalige Beschaffungskontrolle nicht. Sie brauchen laufende Überwachung.
Annex A.10 — Controls für Drittanbieter
Annex A.10 von ISO/IEC 42001 adressiert Drittanbieter nicht als Nebenfrage, sondern als eigenständigen Kontrollbereich für ausgelagerte KI-Leistungen und Lieferantensteuerung. Für die Praxis sind vor allem zwei Controls zentral: die Steuerung ausgelagerter KI-Entwicklung und Komponenten sowie die Auswahl, Bewertung und Überwachung von KI-Lieferanten.
Control A.10.2 zielt auf ausgelagerte KI-Entwicklung und fremde Komponenten. Die Kernaussage lautet: Rollen und Verantwortlichkeiten müssen klar zugewiesen werden, wenn Modelle, Datensätze, Fine-Tuning, Validierung oder Betriebsaufgaben durch Dritte erbracht werden. Unternehmen sollten dokumentieren, wer für Design, Daten-Governance, Test, Freigabe, Monitoring, Incident-Management und Nachbesserung zuständig ist. Gerade bei Integrationsprojekten mit mehreren Beteiligten reicht ein pauschaler Verweis auf den Anbieter nicht aus.
Control A.10.3 ist der operative Schwerpunkt für Lieferantenmanagement. Er verlangt einen dokumentierten Prozess, mit dem KI-Lieferanten ausgewählt, auf ihre Fähigkeit zur Einhaltung verantwortungsvoller KI-Anforderungen geprüft, kontinuierlich überwacht und einschließlich ihrer kritischen Subunternehmer bewertet werden. Das unterscheidet sich deutlich vom klassischen Vendor Management, das häufig nur Informationssicherheit, Datenschutz und Preis prüft. ISO 42001 ergänzt um KI-spezifische Kriterien wie Modelltransparenz, Datenherkunft, Fairness, Erklärbarkeit, Änderungsmanagement und Drift.
Für ein belastbares AIMS sollten Sie im Rahmen von A.10 mindestens diese Fragen beantworten:
| Prüffrage | Zweck im AIMS |
|---|---|
| Welche Lieferanten beeinflussen Modellverhalten, Datenqualität oder Systemintegrität? | Kritische KI-Abhängigkeiten identifizieren |
| Welche Anforderungen muss der Lieferant fachlich, technisch und organisatorisch erfüllen? | Auswahlkriterien dokumentieren |
| Welche Nachweise liegen vor? | Due Diligence belegen |
| Welche Änderungen muss der Lieferant melden? | Update- und Incident-Steuerung sichern |
| Welche Kontrollen gelten für Subunternehmer? | Viertparteirisiken steuern |
| Wie wird die Leistung laufend überwacht? | Monitoring und Management Review ermöglichen |
A.10 wirkt außerdem nicht isoliert. Die Lieferantenkontrollen greifen in andere Teile der Norm hinein: in die Risikoanalyse, in die Leistungsbewertung, in Korrekturmaßnahmen und in Management Reviews. Wer Annex A besser einordnen möchte, findet den Gesamtüberblick im Beitrag Was ist ISO 42001? und die Verbindung zu offenen Modellen in unserem Artikel Open-Source-KI und der EU AI Act.
KI-Lieferanten bewerten
KI-Lieferanten bewertet man nach ISO 42001 nicht nur nach Preis, sondern nach ihrer Fähigkeit, verantwortungsvollen und kontrollierbaren KI-Betrieb zu unterstützen. Die Due Diligence muss deshalb Governance, Technik, Recht und Betrieb zusammenführen.
Ein praxistaugliches Bewertungsmodell beginnt mit einer Risikoklassifizierung. High-Risk-Lieferanten sind zum Beispiel Foundation-Model-Provider, Anbieter für Fine-Tuning, Datensatz-Lieferanten und branchenspezifische KI-Systeme für Personal, Medizin, Finanz- oder Sicherheitskontexte. Mittelrisiko-Anbieter sind häufig Cloud-KI-Plattformen, API-Dienste für Klassifikation oder Übersetzung und branchenspezifische SaaS-Lösungen mit begrenztem Einfluss auf Entscheidungen. Niedrigrisiko-Lieferanten liefern eher Infrastruktur ohne wesentlichen Einfluss auf Modelllogik.
Die eigentliche Due Diligence sollte mindestens diese Kriterien abdecken:
| Kriterium | Woran Sie es prüfen |
|---|---|
| Governance | AI-Policy, Zuständigkeiten, Roadmap für AIMS oder vorhandene Nachweise |
| Transparenz | Model Card, technische Doku, Beschreibung von Grenzen und typischen Fehlmustern |
| Datenschutz | DPA, Datenstandorte, Löschfristen, Nutzung Ihrer Daten für Retraining ja oder nein |
| Sicherheit | ISO 27001, SOC 2, Incident-Prozess, Schutz gegen Prompt Injection oder Missbrauch |
| Fairness | Bias-Tests, definierte Prüfmethoden, Eskalation bei diskriminierenden Ergebnissen |
| Änderungsmanagement | Release Notes, Vorabbenachrichtigung, Versionierung, Rollback-Möglichkeiten |
| Monitoring | Zugriff auf Logs, Qualitätsmetriken, Verfügbarkeits- und Performance-Daten |
| Subunternehmer | Offenlegung kritischer Abhängigkeiten und Verpflichtung zur Weitergabe von Anforderungen |
Die Bewertung sollte dokumentiert und freigabefähig sein. In vielen Unternehmen scheitert Lieferantenprüfung nicht an fehlendem Wissen, sondern an fehlender Standardisierung. Sinnvoll ist deshalb ein fester Fragenkatalog, der sowohl für neue Anbieter als auch für Re-Assessments genutzt wird. Für kritische KI-Dienste sollten Sie zusätzlich einen Fachverantwortlichen benennen, der fachliche Eignung und Ausgaberisiken beurteilt, nicht nur Vertrags- oder Sicherheitsmerkmale.
Branchenkontext ist dabei entscheidend. Im Gesundheitswesen zählt stärker, ob klinische Validierung, Datenqualität und nachvollziehbare Eskalationswege vorliegen. In der Finanzbranche stehen DORA-nahe Drittparteirisiken, Resilienz und Modellkontrollen im Vordergrund. In der Industrie zählen Lieferkettenstabilität, Qualitätssteuerung und Wechselmöglichkeiten zwischen Plattformen stärker. Diese Branchensicht ist wichtig, weil dieselbe API in einem Marketing-Use-Case akzeptabel sein kann, in HR oder Kreditprüfung aber wesentlich strengere Anforderungen auslöst.
Vertragliche Absicherung
Ein KI-Vertrag muss nicht jedes technische Detail regeln, aber er muss die Mindestbedingungen für Transparenz, Steuerbarkeit und Ausstieg eindeutig festlegen. Ohne diese Klauseln bleibt Ihr Unternehmen in der Verantwortung, hat aber zu wenig Rechte, um dieser Verantwortung praktisch nachzukommen.
Vertraglich sollten zunächst Rollen und Verantwortlichkeiten sauber beschrieben werden. Der Anbieter muss offenlegen, welche Leistung er konkret erbringt, ob er selbst Modelle entwickelt oder nur integriert und welche Subunternehmer für Modellbetrieb, Datenspeicherung oder Moderation eingebunden sind. Für Ihr Unternehmen muss erkennbar sein, ob Sie reiner Betreiber eines fremden Systems sind oder durch Integration, White-Label oder Zweckänderung näher an Anbieterpflichten heranrücken. Genau diese Abgrenzung ist auch für den EU AI Act relevant, wie unser Beitrag Anbieter vs. Betreiber im AI Act zeigt.
Danach folgen die Mindestklauseln für den laufenden Betrieb. Dazu gehören Service Levels für Verfügbarkeit, Antwortzeiten, Incident-Bearbeitung und Change-Kommunikation. Besonders wichtig ist eine Pflicht zur Benachrichtigung bei sicherheitsrelevanten Vorfällen, wesentlichen Modelländerungen, neuen Unterauftragnehmern oder geänderten Datenflüssen. Wenn ein Anbieter sein Modell heimlich austauscht oder die Datennutzung ändert, ist Ihr bisheriges Risikobild unter Umständen wertlos.
Ebenfalls wesentlich sind Audit- und Auskunftsrechte. Nicht jedes Unternehmen wird einen Lieferanten technisch vor Ort auditieren können. Realistisch und sinnvoll sind abgestufte Rechte: standardisierte Nachweise, Fragebögen, Bescheinigungen, Third-Party-Reports, Ergebnisgespräche und bei kritischen Konstellationen vertiefte Prüfungen. Entscheidend ist, dass Sie nicht auf bloßes Marketingmaterial angewiesen sind.
Zu jeder KI-Beschaffung gehören außerdem Datenrückgabe und Exit-Strategie. Ein Vertrag sollte regeln, wie Daten, Prompts, Protokolle, Feintuning-Artefakte und Konfigurationen bei Vertragsende zurückgegeben oder gelöscht werden, welche Fristen gelten und welche Unterstützung beim Wechsel zu einem Ersatzanbieter geschuldet ist. Gerade bei Cloud-KI-Plattformen ist Vendor Lock-in ein unterschätztes Risiko.
Die folgende Tabelle bildet die wichtigsten Pflichtklauseln kompakt ab:
| Klausel | Warum sie unverzichtbar ist |
|---|---|
| Leistungs- und Verfügbarkeits-SLA | Betriebssicherheit und Eskalation |
| Incident-Benachrichtigung | Frühe Reaktion auf Sicherheits- oder Modellvorfälle |
| Änderungsmitteilung bei Modellupdates | Re-Assessment und Freigabe ermöglichen |
| Audit- und Auskunftsrecht | Nachweise statt bloßer Zusicherungen |
| Datenschutz und Datennutzung | Retraining, Speicherorte, Löschung, DPA |
| Subunternehmer-Offenlegung | Viertparteirisiken sichtbar machen |
| Datenrückgabe und Löschung | Exit ohne Kontrollverlust |
| Exit-Support und Übergang | Resilienz bei Anbieterwechsel |
Monitoring von KI-Drittanbietern
Monitoring von KI-Drittanbietern ist der Teil, der in der Praxis am häufigsten fehlt, obwohl gerade hier Supply-Chain-Risiken sichtbar werden. Ein einmal freigegebener Lieferant bleibt nicht automatisch geeignet, wenn sich Modell, Preis, Datenverarbeitung oder Sicherheitslage verändert.
Für kritische Anbieter sollten Sie ein risikobasiertes Review-Modell einführen. Monatlich oder zumindest quartalsweise geprüft werden sollten Verfügbarkeit, Fehlerraten, wesentliche Qualitätsabweichungen, Beschwerden aus Fachbereichen, sicherheitsrelevante Hinweise, gemeldete Vorfälle und angekündigte Änderungen. Bei generativen Diensten kommen zusätzlich Halluzinationsquote in Ihrem Use Case, Prompt-Injection-Vorfälle, Moderationsfehler und unerwartete Ausgabemuster hinzu.
Besonders wichtig ist Drift-Monitoring. Auch wenn Sie kein eigenes Modell trainieren, kann sich das Verhalten eines Drittanbieters über Zeit ändern. Für Textsysteme zeigt sich das häufig in veränderten Antwortstilen, anderen Quellenpräferenzen oder neuen Schwächen bei bestimmten Dokumenttypen. Für Klassifikations- oder Prognosemodelle äußert sich Drift in sinkender Genauigkeit, höherer Fehlklassifikation oder stärkerer Streuung in Randfällen. Diese Effekte müssen in Ihre Review-Logik einfließen.
Ein praktikables Monitoring-Set umfasst:
- technische Kennzahlen wie Verfügbarkeit, Latenz, Fehlerrate und SLA-Verstöße
- fachliche Kennzahlen wie Genauigkeit, Relevanz, manuelle Korrekturquote oder Eskalationen
- Governance-Signale wie neue Subunternehmer, geänderte Nutzungsbedingungen oder geänderte Datenrichtlinien
- Incident-Meldungen zu Sicherheit, Datenschutz, diskriminierenden Ergebnissen oder ungeplanten Modelländerungen
Die Reviews müssen nicht bürokratisch sein. Für viele Mittelständler genügt ein monatliches Vendor-Log mit Ampelstatus, offenen Maßnahmen, nächstem Review-Termin und Nachweisen. Kritisch ist nur, dass Monitoring nachweisbar erfolgt und in Management Reviews einfließt. Wer Lieferanten nur einmal bewertet, erfüllt den Geist von Annex A.10 nicht.
EU AI Act und Supply Chain
Der EU AI Act bestätigt, dass Verantwortung in der Wertschöpfungskette verteilt, aber nicht beliebig abgewälzt wird. Besonders wichtig ist Art. 25 der EU-VO 2024/1689, weil dort geregelt ist, wann ein Dritter durch Rebranding, wesentliche Änderung oder Zweckänderung wie ein Anbieter behandelt werden kann.
Für die Supply Chain bedeutet das: Ein Unternehmen, das fremde KI lediglich nutzt, bleibt häufig Betreiber. Sobald es jedoch ein System unter eigener Marke bereitstellt, den vorgesehenen Zweck wesentlich verändert oder tiefgreifend modifiziert, können zusätzliche Anbieterpflichten entstehen. Art. 25 ist deshalb für Integratoren, White-Label-Konstellationen und Plattformanbieter besonders relevant.
Daneben bleiben Betreiberpflichten aus Art. 26 wichtig, wenn Drittanbieter-KI in Hochrisiko-Kontexten eingesetzt wird. Betreiber müssen Systeme bestimmungsgemäß nutzen, menschliche Aufsicht sicherstellen, Datenqualität im eigenen Einflussbereich beachten, Logs aufbewahren und Risiken oder schwere Vorfälle adressieren. Externe Lieferanten entlasten Sie davon nicht automatisch. Der regulatorische Prüfpunkt lautet nicht nur: Welcher Anbieter wurde gewählt? Er lautet auch: Hat Ihr Unternehmen die Nutzung angemessen gesteuert?
ISO 42001 und der EU AI Act greifen hier gut ineinander. Die Norm schafft mit A.10 einen Governance-Rahmen für Lieferantenauswahl, Vertragssteuerung und Monitoring. Der EU AI Act definiert die rechtlichen Folgen entlang der Rollen in der Wertschöpfungskette. Wer beide Ebenen verbindet, kann Drittanbieter-KI deutlich belastbarer steuern als mit einem isolierten Datenschutz- oder Einkaufsprozess.
Open-Source-KI in der Supply Chain
Open-Source-KI reduziert nicht automatisch Lieferantenrisiko, sondern verschiebt es. Sie gewinnen mehr technische Kontrolle, tragen dafür aber mehr eigene Verantwortung für Herkunft, Sicherheit, Lizenzen, Updates und Dokumentation.
Die Chancen sind real. Open-Source-Modelle können Lock-in senken, Kosten transparenter machen, On-Premises- oder EU-Hosting erleichtern und tiefere Anpassung an Fachprozesse erlauben. Für Unternehmen mit sensiblen Daten oder hohen Anforderungen an Datenhoheit kann das ein strategischer Vorteil sein.
Die Risiken sind ebenfalls erheblich. Erstens ist die Herkunft von Trainingsdaten oft weniger klar dokumentiert als bei großen Plattformanbietern. Zweitens entstehen Lizenz- und Nutzungsfragen, insbesondere bei Gewichtsdateien, kommerzieller Nutzung, Weitergabe und Kombination mit eigenen Daten. Drittens braucht der sichere Betrieb interne Fähigkeiten für Tests, Schwachstellenmanagement, Modellversionierung und Rollback. Viertens verlagert sich das Monitoring von einem Anbieter auf das eigene Team oder den Integrator.
Aus ISO-42001-Sicht gelten die Controls deshalb auch für Open Source. Sie müssen trotzdem dokumentieren, warum ein Modell ausgewählt wurde, welche Grenzen bekannt sind, wie Risiken geprüft wurden und wie Updates überwacht werden. Wer Open Source nur als kostenlosen Ersatz für proprietäre APIs versteht, unterschätzt den Governance-Aufwand. Für den regulatorischen Kontext ist außerdem wichtig, dass Open Source im konkreten Einsatz nicht automatisch außerhalb aller Pflichten liegt. Entscheidend bleibt, wie das Modell bereitgestellt, verändert und verwendet wird.
Praxisbeispiel — Cloud-KI-Anbieter managen
Cloud-KI-Anbieter wie Azure AI, AWS Bedrock oder Google Vertex lassen sich gut in ein AIMS einbinden, wenn Auswahl, Verträge und Monitoring sauber getrennt werden. Ein praxisnahes Vorgehen besteht aus vier Schritten.
Schritt eins ist die Lieferkettenkarte. Das Unternehmen dokumentiert, welche Fachprozesse welche Plattform nutzen, welche Modelle dahinterliegen, in welchen Regionen Daten verarbeitet werden und welche Subunternehmer relevant sind. Schon an diesem Punkt wird sichtbar, ob eine einzige Plattform mehrere kritische Prozesse bündelt und damit Konzentrationsrisiko erzeugt.
Schritt zwei ist die Lieferantenbewertung. Azure AI könnte etwa bei Sicherheits- und Governance-Nachweisen stark abschneiden, aber bei Modelltransparenz von Drittmodellen Grenzen haben. AWS Bedrock kann durch Modellvielfalt punkten, verlangt aber eine saubere Steuerung der Modellwahl pro Use Case. Google Vertex kann für MLOps und Monitoring sehr leistungsfähig sein, braucht aber ebenfalls klare Regeln zu Datenflüssen, Zugriffen und Change-Kommunikation. Keine Plattform ist pauschal geeignet oder ungeeignet; entscheidend ist die dokumentierte Passung zum konkreten Risiko.
Schritt drei ist die vertragliche Absicherung. Für alle drei Plattformtypen sollten Unternehmen SLAs, Supportpfade, Datenverwendung, Auditnachweise, Unterauftragsverhältnisse, Modelländerungen und Exit-Pfade verhandeln oder zumindest dokumentiert bewerten. Wenn einzelne Punkte nicht verhandelbar sind, muss das Restrisiko bewusst akzeptiert und genehmigt werden.
Schritt vier ist das laufende Review. Ein AIMS sollte für kritische Cloud-KI-Anbieter feste Review-Termine, definierte KPIs, Incident-Eskalation und Re-Assessments bei wesentlichen Änderungen vorsehen. Genau hier zeigt sich, ob Lieferantenmanagement nur ein Beschaffungsformular oder tatsächlich ein Steuerungsprozess ist.
Wenn Sie Ihr Lieferantenmanagement für ISO 42001 systematisch aufbauen möchten, ist der nächste sinnvolle Schritt eine strukturierte ISO-42001-Schulung. Sie hilft dabei, Rollen, Kontrollen, Nachweise und Management Reviews so aufzusetzen, dass Drittanbieter-KI nicht nur genutzt, sondern kontrolliert betrieben wird.
FAQ
Wie bewertet man KI-Lieferanten nach ISO 42001?
KI-Lieferanten werden nach ISO 42001 anhand eines dokumentierten Verfahrens bewertet, das Governance, Transparenz, Datenschutz, Sicherheit, Fairness, Änderungsmanagement, Monitoring und Subunternehmer abdeckt. Entscheidend ist nicht nur die Erstbewertung, sondern auch die nachvollziehbare laufende Überwachung.
Was muss in einem KI-Vertrag stehen?
Ein KI-Vertrag sollte mindestens Leistungszusagen, Incident- und Änderungsbenachrichtigung, Audit- und Auskunftsrechte, Datenschutzregelungen, Subunternehmer-Offenlegung, Datenrückgabe, Löschung und Exit-Support enthalten. Ohne diese Klauseln können Unternehmen ihre eigene Verantwortlichkeit oft nicht praktisch erfüllen.
Wer haftet bei Fehlern von Drittanbieter-KI?
Die Haftung hängt von Rolle, Einsatzkontext und Vertragslage ab, aber die Verantwortung verschwindet nicht durch den Verweis auf den Lieferanten. Nach dem EU AI Act bleiben Betreiber- oder in bestimmten Konstellationen Anbieterpflichten bei Ihrem Unternehmen. Verträge können Risiken verteilen, aber nicht alle regulatorischen Pflichten beseitigen.
Wie oft sollte man KI-Lieferanten überprüfen?
ISO 42001 nennt kein starres Intervall. Für kritische KI-Dienste ist eine Kombination aus laufendem Monitoring, quartalsweisen Reviews und einer jährlichen Vollbewertung sinnvoll. Bei wesentlichen Modell- oder Vertragsänderungen sollte zusätzlich sofort neu bewertet werden.
Gelten die Controls auch für Open-Source-KI?
Ja. Open-Source-KI entbindet nicht von Due Diligence, Risikobewertung, Dokumentation und Monitoring. Im Gegenteil: Weil ein klassischer Vertragspartner teilweise fehlt, müssen interne Kontrollen häufig sogar stärker sein.
Warum reicht klassisches Third-Party-Risk-Management nicht aus?
Klassisches Third-Party-Risk-Management prüft oft vor allem Sicherheit, Datenschutz und Finanzstabilität. ISO 42001 ergänzt um KI-spezifische Fragen wie Modellverhalten, Bias, Datenherkunft, Erklärbarkeit, Drift und die Steuerung von Modellupdates. Genau diese Punkte entscheiden bei KI über reale Betriebsrisiken.