Lieferantenbewertung für KI: die zwölf vergessenen Fragen

Auf einen Blick

• Die klassische Lieferantenbewertung wurde für eine Lieferkette entworfen, die unveränderliche Software auslieferte. Sie belegt, dass ein Anbieter zahlungsfähig, versichert und zertifiziert ist, sagt aber nichts darüber aus, womit ein Modell trainiert wurde oder wie es sich nach der Unterschrift verändert.
• Nach Artikel 25 Absatz 4 der KI-Verordnung ist die Prüfung eines KI-Zulieferers keine gute Praxis mehr, sondern eine Rechtspflicht. Eine schriftliche Vereinbarung muss festlegen, welche Informationen, Fähigkeiten und technischen Zugänge Sie erhalten.
• Artikel 25 Absatz 1 enthält die Falle, die die meisten Einkäufer übersehen: Wer ein zugekauftes System unter eigenem Namen vertreibt, wesentlich verändert oder zweckentfremdet, wird selbst zum Anbieter.
• ISO/IEC 42001 A.10.3 und NIST AI RMF GOVERN 6.1 verlangen beide eine aktive Steuerung der Zulieferer. Die Verantwortung für das Ergebnis bleibt bei Ihnen, unabhängig davon, was im Vertrag steht.
• Der richtige Auslöser für eine erneute Prüfung ist ein Versionswechsel des Modells, nicht der Jahrestag des Vertrags.

Was die Lieferantenbewertung heute abdeckt

Fragen Sie eine beliebige Plattform für Drittparteienrisiken, was in eine Prüfung gehört, und Sie erhalten eine bemerkenswert einheitliche Antwort. Die Lieferantenbewertung bezeichnet den vorvertraglichen Vorgang, mit dem geprüft wird, ob einem Dritten eine Geschäftsfunktion anvertraut werden kann. Der übliche Katalog umfasst sechs bis sieben Rubriken: Rechtsform und Beteiligungsstruktur, wirtschaftlich Berechtigte, Finanzstabilität, Sicherheits- und Datenschutznachweise wie SOC 2 oder ISO/IEC 27001, operative Widerstandsfähigkeit und Notfallplanung sowie ein regulatorisches Screening auf Sanktionen, Rechtsstreitigkeiten und negative Medienberichte. Reife Programme stufen ihre Zulieferer zunächst nach Kritikalität ein, damit ein Lohnabrechnungsdienstleister gründlicher geprüft wird als ein Büromateriallieferant. Anschließend werden Nachweise gesammelt, gegen eine festgelegte Risikobereitschaft bewertet und ein Turnus für die Wiedervorlage bestimmt. Nichts daran ist falsch. Es handelt sich um einen bewährten Vorgang, den zwei Jahrzehnte Auslagerungspraxis geschliffen haben, und er bleibt das Fundament jeder KI-Governance. Das Problem ist enger gefasst: Jede dieser Rubriken beschreibt das Unternehmen, bei dem Sie einkaufen. Keine einzige beschreibt das Modell, das Sie einkaufen.

Lieferantenbewertung und Commercial Due Diligence

Beide Begriffe werden häufig genug verwechselt, um sie sauber zu trennen. Die Commercial Due Diligence prüft, ob Markt, Kundenstruktur und Ertragslage eines Zielunternehmens eine Bewertung rechtfertigen, und gehört in den Zusammenhang einer Transaktion. Die Lieferantenbewertung prüft, ob ein Zulieferer eine Leistung erbringen kann, ohne ein unvertretbares Risiko in Ihr Haus zu tragen. Im Transaktionsgeschäft bezeichnet der englische Begriff Vendor Due Diligence verwirrenderweise zusätzlich einen Bericht, den ein Verkäufer über sich selbst in Auftrag gibt. Gemeint ist hier durchgängig die erste Bedeutung: Sie kaufen ein, und der Zulieferer liefert Ihnen ein KI-System.

Warum die Standard-Checkliste bei KI-Anbietern versagt

Ein SOC 2-Bericht vom Typ II ist das Urteil eines Prüfers darüber, dass ein Unternehmen angekündigte Kontrollen über einen Zeitraum hinweg angewandt hat. Er sagt Ihnen, dass das Gebäude verschlossen ist, Zugriffsrechte überprüft werden und Sicherungen getestet sind. Er sagt Ihnen nichts darüber, mit welchen Daten das Modell trainiert wurde, ob diese Daten lizenziert waren, ob das Modell für die von Ihnen betreute Personengruppe evaluiert wurde oder was sich im letzten Release an seinem Verhalten geändert hat. Das sind Fragen anderer Art über einen anderen Gegenstand, und der übliche Fragebogen stellt sie nicht. Vier Eigenschaften von KI-Zulieferern setzen die herkömmliche Prüfung außer Kraft. Das Produkt ist nicht deterministisch. Herkömmliche Software liefert bei gleicher Eingabe dieselbe Ausgabe, weshalb ein einmaliger Test das Verhalten hinreichend beschreibt. Ein KI-Modell leistet das nicht zwingend. Der Nachweis, dass ein System sich während eines Pilotbetriebs angemessen verhalten hat, wiegt deshalb weniger schwer als dasselbe Ergebnis bei einem deterministischen Werkzeug, und eine Prüfung, die auf einmaliger Abnahme beruht, überschreitet stillschweigend ihre Aussagekraft. Das Produkt ändert sich, ohne dass der Vertrag sich ändert. Anbieter trainieren nach, tauschen Basismodelle aus und passen Systemanweisungen fortlaufend an. Ein System, das Ihre Prüfung im März bestanden hat, kann sich im Juni wesentlich anders verhalten, ohne Nachtrag, ohne Ankündigung und ohne neuen Nachweis. Der klassische Einkauf kennt dafür kein Ereignis, weil klassische Software in angekündigten Versionen auf einer sichtbaren Roadmap erschien. Die Kette reicht tiefer als Ihr Register. Ihr Zulieferer ist häufig nur eine dünne Anwendungsschicht auf dem Basismodell eines Dritten, das wiederum bei einem vierten Anbieter betrieben wird. Risiken aus Unterauftragsverhältnissen sind nichts Neues, doch bei KI bestimmt der Unterlieferant das Verhalten des gekauften Systems und nicht bloß dessen Verfügbarkeit. Die meisten Lieferantenregister enden bei der unmittelbaren Vertragspartei. Die Offenlegung stößt auf das Geschäftsgeheimnis. Das NIST hält fest, dass Anbieter die Zusammensetzung ihrer Trainingsdaten, ihre Architektur oder ihre Evaluationsergebnisse regelmäßig unter Verweis auf Betriebs- und Geschäftsgeheimnisse nicht offenlegen, und dass GOVERN 6.1, die Kontrolle zu Dritten, zu den am häufigsten scheiternden Punkten unabhängiger Audits gehört. Diese Verweigerung ist selbst ein Prüfungsergebnis, und eine Bewertung, die „Anbieter hat nicht geantwortet“ als Leerstelle statt als Risikoeinstufung behandelt, erfüllt ihren Zweck nicht. Ein fünftes Problem liegt gänzlich außerhalb des Fragebogens. Anbieter ergänzen Werkzeuge, die Sie bereits einsetzen, um KI-Funktionen. KI gelangt dadurch über eine Vertragsverlängerung in das Unternehmen und nicht über eine Beschaffung. Das ist die vertragliche Erscheinungsform von Schatten-KI, und keine noch so sorgfältige Vorprüfung entdeckt sie, wenn nichts den Vorgang wieder öffnet.

Die Rechtspflicht, die die meisten Einkäufer übersehen: Artikel 25 der KI-Verordnung

Die Fachliteratur behandelt die Prüfung von Zulieferern als kluges Risikomanagement. Für einen erheblichen Teil der europäischen Anwendungsfälle ist sie inzwischen eine Rechtspflicht mit einer konkreten Fundstelle, was sowohl die Dringlichkeit als auch die Art der aufzubewahrenden Nachweise verändert.

Die Pflicht zur schriftlichen Vereinbarung

Artikel 25 Absatz 4 bestimmt, dass der Anbieter eines Hochrisiko-KI-Systems und der Dritte, der ein KI-System, Werkzeuge, Dienste, Komponenten oder Verfahren zuliefert, die darin verwendet oder integriert werden, durch schriftliche Vereinbarung die Informationen, Fähigkeiten, technischen Zugänge und sonstige Unterstützung festlegen, die zur Erfüllung der Verordnung erforderlich sind, und zwar nach dem allgemein anerkannten Stand der Technik. Lesen Sie diese Vorschrift als Beschaffungsanweisung. Wenn Sie ein Hochrisikosystem entwickeln oder in Verkehr bringen und ein Teil davon von außerhalb stammt, muss der zugehörige Informationsfluss vertraglich verankert sein. Die mündliche Zusicherung eines Vertriebsingenieurs genügt dafür ebenso wenig wie ein ausgefüllter Fragebogen, der auf einem Laufwerk liegt. Verlangt ist, vorher schriftlich vereinbart zu haben, was der Zulieferer Ihnen mitteilt und welchen Zugang er Ihnen eröffnet.

Wenn der Käufer zum Anbieter wird

Artikel 25 Absatz 1 ist die Vorschrift, die aus einer Beschaffungsentscheidung eine Compliance-Verpflichtung macht. Ein Händler, Einführer, Betreiber oder sonstiger Dritter gilt als Anbieter eines Hochrisikosystems und unterliegt den Anbieterpflichten des Artikels 16 in drei Fällen: wenn er seinen Namen oder seine Marke auf einem bereits in Verkehr gebrachten Hochrisikosystem anbringt, wenn er ein solches System wesentlich verändert, oder wenn er die Zweckbestimmung eines nicht als hochriskant eingestuften Systems so verändert, dass es hochriskant wird. Jede dieser Varianten beschreibt etwas, das Unternehmen routinemäßig tun, ohne es als regulatorischen Akt wahrzunehmen. Der Vertrieb eines zugekauften Systems unter eigener Marke fällt unter Buchstabe a. Ein Feintuning mit eigenen Daten, das den Rahmen der ursprünglichen Konformitätsbewertung verlässt, fällt unter Buchstabe b. Ein allgemeines Sichtungswerkzeug auf Einstellungsentscheidungen zu richten, fällt unter Buchstabe c. Artikel 3 Nummer 23 definiert die wesentliche Veränderung als eine Änderung, die in der ursprünglichen Konformitätsbewertung nicht vorgesehen oder geplant war und die die Einhaltung der Anforderungen des Kapitels III Abschnitt 2 beeinträchtigt oder die Zweckbestimmung verändert. Für Modelle mit allgemeinem Verwendungszweck nennt die Kommission einen indikativen quantitativen Anhaltspunkt: Ein Feintuning, das mehr als etwa ein Drittel der ursprünglichen Trainingsrechenleistung beansprucht, spricht dafür, dass der nachgelagerte Beteiligte die Anbieterpflichten für das veränderte Modell übernimmt. Unser Leitfaden zu KI mit allgemeinem Verwendungszweck erläutert das Zusammenspiel dieser vorgelagerten Pflichten mit Ihren eigenen. Für die Prüfung folgt daraus eine Frage, die auf den Fragebogen gehört: Beabsichtigen wir, dieses System zu verändern? Die Antwort entscheidet darüber, welches Pflichtenprogramm Sie einkaufen. Wissenschaftliche Arbeiten zu agentischen Systemen, darunter AI Agents Under EU Law, weisen darauf hin, dass eine Verhaltensdrift zur Laufzeit sich schwer mit der Grenzziehung des Artikels 3 Nummer 23 verträgt, da ein System, das sein eigenes Verhalten nach der Inbetriebnahme verändert, eine Linie überschreiten kann, deren Überschreitung sich die Verfasser als bewusste menschliche Handlung vorgestellt hatten.

Was der ursprüngliche Anbieter Ihnen schuldet

Die Pflicht wirkt nicht nur in eine Richtung. Artikel 25 Absatz 2 verpflichtet den ursprünglichen Anbieter zur engen Zusammenarbeit mit jedem neuen Anbieter und dazu, die erforderlichen Informationen sowie den vernünftigerweise zu erwartenden technischen Zugang und die Unterstützung bereitzustellen, damit dieser seine Pflichten erfüllen kann, insbesondere bei der Konformitätsbewertung. Schließt der Vertrag Ihres Zulieferers eine solche Zusammenarbeit vollständig aus, steht die Klausel im Spannungsverhältnis zur Verordnung, und es ist sachgerecht, sie in der Verhandlung anzusprechen statt sie als Standardformulierung hinzunehmen. Unser operativer Leitfaden zur KI-Verordnung beschreibt die Rollenverteilung zwischen Anbieter und Betreiber im Überblick.

Was ISO 42001, NIST AI RMF und DORA von der Lieferantenbewertung verlangen

Drei Regelwerke nähern sich der Steuerung von Zulieferern aus unterschiedlichen Richtungen, und eine Bewertung, die allen dreien genügt, ist in den meisten Rechtsordnungen vertretbar.

ISO/IEC 42001: Verantwortung geht nicht über

Die Anhang-A-Kontrolle A.10 regelt Beziehungen zu Dritten und Kunden. A.10.2 verlangt, Rollen und Verantwortlichkeiten über sämtliche externen Beteiligten des KI-Lebenszyklus hinweg eindeutig zuzuweisen, also über Datenlieferanten, Modellentwickler, Plattformanbieter und Systemintegratoren, damit keine Pflicht in die Lücke zwischen zwei Organisationen fällt, von denen jede die andere in der Verantwortung wähnte. A.10.3 verlangt eine aktive Steuerung der KI-Zulieferer, damit bezogene Modelle, Datensätze und Komponenten mit Ihren Zielen einer verantwortungsvollen KI übereinstimmen, nachgewiesen durch Lieferantenbewertungen und Vertragsklauseln zu Transparenz und Verzerrung. Der Grundsatz hinter beiden Kontrollen wiegt schwerer als ihr Wortlaut: Verantwortung geht nicht über. Sie bleiben für das Ergebnis einstandspflichtig, auch wenn ein Zulieferer es verursacht hat. Unsere Einführung in die ISO 42001 ordnet Anhang A in das Managementsystem insgesamt ein.

NIST AI RMF: die Kontrolle, an der Audits scheitern

Die Funktion GOVERN 6 behandelt Risiken aus Software, Daten und Lieferketten Dritter. GOVERN 6.1 erstreckt Ihre Governance auf Anbietermodelle, fremde Programmierschnittstellen, vortrainierte Datensätze und quelloffene Komponenten und stellt ausdrücklich klar, dass die rechtliche Verantwortung für Schutzrechtsverletzungen, urheberrechtlich geschützte Trainingsdaten und Datenschutzverstöße, die in einem fremden Modell angelegt sind, bei der einsetzenden Organisation verbleibt. GOVERN 6.2 verlangt Vorsorgeprozesse für den Ausfall Dritter, einschließlich Ausweichlösungen und Kriterien für die Außerbetriebnahme. Unser Leitfaden zum NIST AI RMF stellt den vollständigen Funktionsumfang dar.

DORA: das Informationsregister und die Pflichtklauseln

Finanzunternehmen tragen eine weitere Schicht. Die Verordnung DORA, anwendbar seit dem 17. Januar 2025, verlangt in den Artikeln 28 bis 30 ein Informationsregister über sämtliche vertraglichen Vereinbarungen mit IKT-Drittdienstleistern, wobei zwischen Vereinbarungen für kritische oder wichtige Funktionen und übrigen zu unterscheiden ist. Artikel 30 schreibt die Klauseln vor, die in diesen Verträgen enthalten sein müssen: Leistungsbeschreibung und Leistungsniveaus, Datenstandorte, Mitteilung von Änderungen, Prüfungsrechte, Meldung von Vorfällen, Fortführung des Geschäftsbetriebs und Kündigungsrechte. Anbieter von KI und großen Sprachmodellen können als IKT-Drittdienstleister in den Anwendungsbereich fallen. Im November 2025 haben die Europäischen Aufsichtsbehörden die ersten neunzehn kritischen IKT-Drittdienstleister benannt, eine Liste, die von den Cloud-Plattformen bestimmt wird, auf denen die meisten KI-Dienste laufen. In Deutschland konkretisiert die BaFin diese Erwartungen gegenüber beaufsichtigten Instituten, während das BSI die technische Sicherheit und der oder die BfDI den datenschutzrechtlichen Teil abdecken.

Die zwölf KI-Fragen für Ihren Fragebogen zur Lieferantenbewertung

Diese Fragen treten neben Ihre bestehenden Abschnitte zu Sicherheit, Finanzlage und Fortführung, sie ersetzen sie nicht. Entscheidend ist jeweils der Nachweis, nicht die Antwort. Die folgende Gliederung folgt der Aufteilung des offen lizenzierten AI Vendor Security and Safety Assessment Guide von Dennis Ah-king, der sich in ein bestehendes Verfahren zum Drittparteienrisiko einfügen lässt.

Herkunft und Daten

1. Mit welchen Daten wurde das Modell trainiert, und unter welcher Lizenz? Erwartet wird eine dokumentierte Datenerklärung mit Quellen und Rechtsgrundlage. „Öffentlich verfügbare Daten“ ist keine Antwort. 2. Trainieren unsere Daten Ihre Modelle, standardmäßig oder auf Wunsch? Erwartet wird eine vertragliche Zusage, kein Screenshot einer Einstellung. Klären Sie, ob sich die Voreinstellung bei Verlängerung ändert. 3. Welche Unterauftragnehmer und Modellanbieter stehen hinter diesem Dienst? Erwartet wird eine namentliche Liste samt Zusage zur Mitteilung von Änderungen. Vertreibt der Zulieferer ein fremdes Basismodell weiter, betreffen Sie auch dessen Bedingungen.

Modellverhalten und Änderungen

4. Welche Evaluationen wurden durchgeführt, an welchen Personengruppen, mit welchen Ergebnissen? Erwartet werden Berichte mit nach Gruppen aufgeschlüsselten Ergebnissen. Eine aggregierte Trefferquote verdeckt gerade jene Fehlerbilder, aus denen die rechtliche Verantwortung erwächst. 5. Wie teilen Sie uns einen Versionswechsel des Modells mit, und mit welcher Vorlaufzeit? Erwartet werden eine Frist und ein festgelegter Kanal. Das ist die wertvollste Antwort der gesamten Liste. 6. Wie erkennen und melden Sie eine Verschlechterung der Leistung nach der Inbetriebnahme? Erwartet wird eine Überwachung, deren Ergebnisse Sie sehen, idealerweise eine Kennzahl, die Sie erhalten, statt einer, die der Anbieter für sich betrachtet. 7. Welche Zweckbestimmung haben Sie für das System festgelegt? Erwartet wird eine schriftliche Festlegung. Ein geplanter Einsatz außerhalb davon ist der schnellste Weg in die Anbieterpflichten.

Lieferkette und Abhängigkeiten

8. Gilt dieses System nach der KI-Verordnung als hochriskant, und auf welcher Grundlage? Erwartet wird eine begründete Einstufung. Uneinigkeit an dieser Stelle gehört vor Vertragsschluss geklärt. 9. Wenn wir das Modell feinjustieren oder unter eigener Marke vertreiben, wie verschiebt sich die Verantwortung? Erwartet wird eine Antwort, die sich mit Artikel 25 auseinandersetzt. Ein Zulieferer, der darüber nicht nachgedacht hat, sagt damit bereits etwas aus. 10. Welche technische Dokumentation stellen Sie bereit, und wird sie fortgeschrieben? Erwartet wird eine Zusage, die zu dem passt, was Sie selbst Ihrer Aufsicht schulden. Unser Leitfaden zur KI-Systemdokumentation beschreibt den Mindestumfang.

Nachweise und Ausstieg

11. Welche Prüfungsrechte haben wir, und erstrecken sie sich auf Ihren Modellanbieter? Erwartet werden Rechte, die über die Grenze zum Unterauftragnehmer hinausreichen, denn dort wird das Verhalten tatsächlich bestimmt. 12. Was geschieht bei Kündigung mit unseren Daten, den feinjustierten Gewichten und den Einbettungen? Erwartet wird eine Löschzusage, die auch abgeleitete Artefakte erfasst und nicht nur die Ausgangsdatensätze. Verweigert ein Zulieferer die Antwort, halten Sie die Verweigerung fest, stufen Sie das Restrisiko ein und leiten Sie es an denjenigen weiter, der die Risikoübernahme verantwortet. Eine verweigerte Antwort ist ein Ergebnis.

Vertragsklauseln, die die Antworten verbindlich machen

Antworten auf einem Fragebogen binden niemanden. Die Klauseln, die daraus Pflichten machen, fehlen KI-Verträgen am häufigsten, weil ein allgemeiner Softwarevertrag nicht für ein nicht deterministisches Produkt entworfen wurde. Praxisleitfäden für Juristen, die mit KI-Anbietern verhandeln, benennen durchweg dieselben Punkte: Beschränkungen der Nutzung von Kundendaten zu Trainingszwecken, Eigentum und Lizenzierung der Modellausgaben, Mitteilungs- und Zustimmungsrechte bei Modelländerungen, Zustimmung zu Unterauftragnehmern und Modellanbietern, Prüfungsrechte bis zum vorgelagerten Anbieter, Pflichten zu Verzerrungstests und Nachbesserung, an probabilistische Ausgaben angepasste Leistungsmaßstäbe sowie Beendigungsregelungen, die feinjustierte Gewichte und Einbettungen rückabwickeln und nicht nur gespeicherte Datensätze. Zwei verdienen besondere Aufmerksamkeit. Klauseln zur einseitigen Änderung, in Softwareverträgen üblich, haben ein ganz anderes Gewicht, wenn der geänderte Gegenstand das Modell selbst ist. Und Haftungsobergrenzen in Höhe von zwölf Monatsentgelten waren auf Betriebsunterbrechungen zugeschnitten, nicht auf die Feststellung einer Diskriminierung durch ein Modell, das Sie nicht gebaut haben. Unser Leitfaden zur KI-Compliance ordnet diese Punkte in den Gesamtzusammenhang ein.

Erneute Prüfung: die Auslöser, die den Vorgang wieder öffnen

Die meisten Programme prüfen ihre Zulieferer jährlich oder bei Vertragsverlängerung. Für KI-Anbieter passt dieser Turnus nicht zum Risiko, weil sich der geprüfte Gegenstand im Takt der Auslieferungen des Anbieters ändert und nicht im Takt Ihres Einkaufskalenders. Ersetzen oder ergänzen Sie den Kalender durch ereignisbezogene Auslöser:

• Ein Versionswechsel des Modells oder ein Wechsel des zugrunde liegenden Basismodells
• Ein neuer Unterauftragnehmer oder Modellanbieter in der Kette
• Eine Erweiterung der Fähigkeiten, insbesondere wenn dem System neue Handlungen oder Werkzeugzugriffe eröffnet werden
• Eine Änderung der erklärten Zweckbestimmung durch eine der beiden Seiten
• Jede Entscheidung auf Ihrer Seite, das Modell feinzujustieren, unter eigener Marke zu führen oder umzuwidmen, denn damit greift Artikel 25 Absatz 1
• Ein meldepflichtiger Vorfall, beim Zulieferer wie in Ihrem eigenen Betrieb
• Eine gemessene Drift, die einen bei Vertragsbeginn festgelegten Schwellenwert überschreitet

Die letzten beiden verbinden diesen Vorgang mit Kontrollen, die Sie möglicherweise bereits betreiben und die unser Leitfaden zum KI-Risikomanagement beschreibt. Die Lieferantenprüfung an diese Signale zu koppeln statt an ein Datum ist es, was das Verfahren dem tatsächlichen Verhalten von KI-Anbietern gerecht werden lässt.

Häufige Fragen

Worin unterscheiden sich Kundenprüfung und Lieferantenbewertung? Die Kundenprüfung entstammt der Geldwäschebekämpfung: Identität, wirtschaftlich Berechtigte und Sanktionsstatus eines Kunden werden vor Aufnahme der Geschäftsbeziehung überprüft, getrieben vom Finanzaufsichtsrecht. Die Lieferantenbewertung verläuft in die Gegenrichtung und betrifft einen Zulieferer, von dem Sie abhängig werden. Beide nutzen ähnliche Screening-Techniken und oft dieselben Datenbanken, was die Verwechslung erklärt, doch sie beantworten verschiedene Fragen gegenüber verschiedenen Aufsichtsbehörden. Worin unterscheiden sich Lieferantenbewertung und Commercial Due Diligence? Die Commercial Due Diligence prüft, ob ein Unternehmen den Preis wert ist, den ein Erwerber zu zahlen bereit ist, und betrachtet dazu Marktstellung, Kundenkonzentration und Ertragsqualität. Sie gehört in eine Transaktion. Die Lieferantenbewertung prüft, ob ein Zulieferer liefern kann, ohne ein unvertretbares Risiko in Ihren Betrieb zu tragen, und gehört in Einkauf und Drittparteienrisikomanagement. Genügt ein SOC-2-Bericht bei einem KI-Anbieter? Nein. Ein SOC 2-Bericht ist eine Aussage darüber, ob angekündigte Kontrollen über einen Zeitraum hinweg gewirkt haben, etwa Zugriffsverwaltung, Änderungssteuerung und Überwachung. Er ist nützlich und sagt nichts über die Herkunft der Trainingsdaten, Evaluationsergebnisse, Verzerrungstests oder das Management von Modellversionen. Behandeln Sie ihn als notwendig, aber nicht hinreichend, und ergänzen Sie die modellbezogenen Fragen. Wann werden wir durch den Kauf eines KI-Systems zu dessen Anbieter? Nach Artikel 25 Absatz 1 der KI-Verordnung in drei Fällen: Sie bringen Ihren Namen oder Ihre Marke auf einem bereits in Verkehr gebrachten Hochrisikosystem an, Sie verändern ein solches System wesentlich, oder Sie ändern dessen Zweckbestimmung so, dass es hochriskant wird. Jeder dieser Fälle überträgt Ihnen die Anbieterpflichten des Artikels 16, darunter Qualitätsmanagementsystem, technische Dokumentation und Konformitätsbewertung. Wie oft sollte ein KI-Zulieferer erneut bewertet werden? Behalten Sie eine jährliche Grundprüfung für Fortführung und Finanzlage bei und ergänzen Sie ereignisbezogene Auslöser für alles Modellbezogene. Ein Versionswechsel, ein neuer Unterauftragnehmer, eine Erweiterung der Fähigkeiten, ein Vorfall oder eine gemessene Drift sollten den Vorgang unabhängig vom Datum der letzten Prüfung wieder öffnen. Wer allein nach Kalender prüft, bewertet womöglich ein System, das nicht mehr dasjenige ist, das er bewertet hat. Was tun, wenn ein Anbieter die Trainingsdaten nicht offenlegt? Halten Sie die Verweigerung als Feststellung fest und nicht als offen gebliebene Frage, und stufen Sie das Restrisiko entsprechend ein. Das NIST behandelt die Nichtoffenlegung unter Verweis auf Geschäftsgeheimnisse als anerkanntes Merkmal dieses Marktes und nicht als Ausnahme. Häufig lässt sich eine tragfähige Position anders erreichen: durch eine vertragliche Freistellung für Schutzrechts- und Datenschutzansprüche aus Trainingsdaten, durch die Bescheinigung eines Dritten oder durch eine engere Zusicherung zur Lizenzgrundlage statt vollständiger Offenlegung.

Fazit

Die Disziplin verfügt über ein gutes Verfahren. Zwei Jahrzehnte Drittparteienrisikomanagement haben eine Prüfung hervorgebracht, die verlässlich klärt, ob es einen Zulieferer im nächsten Jahr noch gibt und ob sein Firmennetz standhält. Wofür sie nie entworfen wurde, ist die Beschreibung eines Modells: woher seine Trainingsdaten stammen, wie es sich gegenüber den von Ihnen betreuten Menschen verhält und was sich vergangene Woche in ihm verändert hat. Artikel 25 Absatz 4 hat diese Lücke für Hochrisikoanwendungen in Europa bereits zu einer rechtlichen gemacht, und ISO/IEC 42001 wie NIST AI RMF gelangen über die Governance zum selben Ergebnis. Das Gegenmittel ist kein neues Programm. Es sind zwölf zusätzliche Fragen, eine Handvoll Klauseln, die die Antworten verbindlich machen, und ein Auslöser, der bei einem Versionswechsel greift statt an einem Stichtag. Wo Lieferantennachweise in einem größeren Kontrollrahmen stehen, zeigt unser Leitfaden zum KI-Risiko.