¶ KI-Lieferanten und Drittanbieter steuern – Verantwortung bleibt im Unternehmen
Kurz gesagt: Ein bekannter Anbieter, ein ISO-Zertifikat oder ein leistungsfähiges Modell ist noch keine Freigabe für den eigenen KI-Anwendungsfall. Entscheidend sind Zweck, Rolle, Daten, Modell- und Lieferkette, Leistungsgrenzen, Änderungen, Nachweise, menschliche Aufsicht und die Fähigkeit, den Dienst sicher einzuschränken oder zu verlassen.
KI-spezifische Besonderheit: Hinter einer Oberfläche können Cloudplattform, Modellanbieter, Fine-Tuning, Datenquellen, Vektordatenbank, Plugins, Agentenwerkzeuge und Moderationsdienste verschiedener Parteien stehen. Diese Wertschöpfungskette muss soweit bekannt sein, dass Verantwortung und Risiken steuerbar bleiben.
Musterstatus: Die folgenden Klassen, Anforderungen und Dummy-Daten sind fiktiv. Sie bestätigen weder einen realen Lieferantenbestand noch abgeschlossene Prüfungen, Verträge, Wirksamkeit oder Rechtskonformität.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | AIMS-VA-05-01 |
| Dokumentenart | Verfahren und Registermodell für KI-Lieferanten und Drittanbieter |
| Wiki.js-Pfad | /ISO-42001/05-Lieferanten-und-Drittparteien/KI-Lieferanten-und-Drittanbietersteuerung |
| Prozesseigner | Einkauf/Lieferantenmanagement und AIMS-Verantwortliche/r |
| Operativ verantwortlich | Fachlicher KI-Owner und technischer System-Owner |
| Fachlich beteiligt | Informationssicherheit, Datenschutz, Recht/Compliance, Qualitätsmanagement, BCM, IT/Cloud und menschliche Aufsicht |
| Freigabe | Nach Kritikalität durch fachlichen Owner, AIMS-Verantwortung und gegebenenfalls Geschäftsführung |
| Status | Entwurf – Anbieterbestand, Kritikalität, Vertragsmindestanforderungen und Entscheidungskompetenzen festzulegen |
| Version | 0.2 |
| Stand | 10.08.2026 |
| Prüfung | Vor Beschaffung, vor Produktivstart, mindestens jährlich sowie bei wesentlicher Anbieter-, Modell-, Daten-, Vertrags- oder Rechtsänderung |
| Schutzklasse | Öffentliches Muster; Anbieterbewertungen, Verträge, Architektur, Schwachstellen und Exitdaten intern bis streng vertraulich |
| Normbezug | ISO/IEC 42001:2023; ergänzend ISO/IEC 23894:2023 und ISO/IEC 5338:2023 |
| Rechtliche Schnittstellen | Verordnung (EU) 2024/1689, DSGVO, Urheber-, Geschäftsgeheimnis-, Vertrags-, Arbeits- und Branchenrecht |
KI-Drittleistungen werden vor der Nutzung eingestuft, vertraglich beherrscht, laufend überwacht und kontrolliert beendet. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Was ist bei KI anders als bei klassischer Software?
Generische Lieferantenkontrollen bleiben notwendig, reichen bei KI jedoch oft nicht. Zusätzlich zu Verfügbarkeit, Vertraulichkeit, Datenschutz und Support werden dynamische Eigenschaften bewertet:
| KI-Besonderheit | Steuerungsfrage |
|---|---|
| Modellverhalten ist probabilistisch | Welche Tests, Fehlergrenzen und menschlichen Kontrollen gelten für den konkreten Zweck? |
| Modell und Dienst ändern sich | Wie werden Modellwechsel, neue Funktionen, Sicherheitsfilter und Abkündigungen angekündigt? |
| Daten können zum Training oder zur Verbesserung verwendet werden | Welche Eingaben, Ausgaben und Metadaten nutzt der Anbieter wofür und wie lässt sich dies kontrollieren? |
| technische Lieferkette ist mehrstufig | Welche Modelle, Hosting-, Daten-, Plugin- und Unterauftragnehmer wirken tatsächlich mit? |
| Leistungsgrenzen sind kontextabhängig | Welche Sprachen, Nutzergruppen, Fachgebiete und Randfälle wurden belegt? |
| Anbieterinformationen können unvollständig sein | Welche Unsicherheit bleibt und welche Nutzungseinschränkung folgt daraus? |
| Integration verändert die Wirkung | Werden Ausgaben nur angezeigt oder lösen sie automatisch Aktionen und Entscheidungen aus? |
| Anbieterrolle kann sich durch eigene Änderungen verschieben | Wird durch Branding, Zweckänderung oder wesentliche Modifikation eine neue rechtliche Rolle ausgelöst? |
Die AIMS-Prüfung ergänzt die bestehenden Verfahren für Informationssicherheit, Datenschutz, Qualität, Einkauf und BCM. Sie erzeugt kein paralleles zweites Lieferantenregister, sondern ein KI-spezifisches Profil zum führenden Lieferanten- und KI-Anwendungsbestand.
¶ 2. Die Wertschöpfungskette sichtbar machen
Für jeden wesentlichen KI-Anwendungsfall wird die technische und organisatorische Kette dokumentiert.
| Kettenglied | Beispiele | Benötigte Information |
|---|---|---|
| vertraglicher Hauptanbieter | SaaS- oder Plattformvertrag | Rechtsträger, Leistung, Vertrags- und Supportkontakt |
| Modellanbieter | eigenes oder eingebettetes Sprach-, Bild- oder Prognosemodell | Modellfamilie, Version, Nutzungsgrenzen, Änderungsweg |
| Hosting und Rechenleistung | Hyperscaler, Rechenzentrum, Edge-Plattform | Regionen, Resilienz, Sicherheits- und Zugriffsmodell |
| Daten- und Wissensquellen | Suchindex, lizenzierter Datenbestand, RAG-Wissensbasis | Herkunft, Rechte, Aktualität, Qualität und Löschung |
| Fine-Tuning oder Anpassung | eigenes Training, Anbieteranpassung, Systemprompt | Verantwortlichkeit, Datensatz, Test und Versionsstand |
| Werkzeuge und Plugins | E-Mail, Kalender, Datenbank, Agentenaktionen | Berechtigungen, mögliche Aktionen, Grenzen und Protokollierung |
| Moderation und Monitoring | Sicherheitsfilter, Inhaltsprüfung, Telemetrie | Abdeckung, Fehlerrisiko, Datenverwendung und Eskalation |
| Support und Unterauftragnehmer | Fernwartung, Annotation, Incident Response | Zugriff, Orte, Vertraulichkeit und Flow-down |
Unbekannte Kettenglieder werden nicht mit „nicht relevant“ gleichgesetzt. Sie bleiben als Unsicherheit sichtbar und beeinflussen Kritikalität, Vertragsforderung, technische Begrenzung oder Freigabe.
¶ 3. KI-Lieferantenregister und führende Verknüpfung
Jeder relevante Anbieter erhält eine eindeutige Lieferanten-ID. Der gleiche Anbieter kann mehrere Dienste oder Modelle bereitstellen; deshalb werden Anbieter, bezogene Leistung und konkreter KI-Anwendungsfall getrennt geführt.
| Registerfeld | Zweck |
|---|---|
| Lieferanten- und Service-ID | eindeutige Zuordnung und Vermeidung von Doppelpflege |
| KI-Anwendungs-IDs | Verknüpfung mit Zweck, Owner, Risiko, Freigabe und Auflagen |
| Rechtsträger und Vertragspartei | belastbare Zuständigkeit und Rechtsraum |
| Dienst, Modell und Version | geprüften Gegenstand abgrenzen |
| Organisationsrolle | Anbieter, Betreiber, Importeur, Händler oder weitere Rolle als Erstindikation |
| Wertschöpfungskette | wesentliche Modelle, Plattformen, Datenquellen und Unterauftragnehmer |
| Datenverwendung | Eingaben, Ausgaben, Protokolle, Training, Aufbewahrung und Löschung |
| Kritikalität | Prüftiefe, Freigabestelle und Überwachung bestimmen |
| Vertrags- und Nachweisstatus | offene Lücken und Risikoakzeptanzen sichtbar machen |
| Änderungs- und Vorfallweg | Fristen, Kontakte und Handlungen steuern |
| Exitstatus | Export, Ersatz, Löschung, Wissenssicherung und Testgrad |
Verträge, nicht öffentliche Prüfberichte, technische Schwachstellen und reale Risikobewertungen verbleiben in geschützter Ablage. Das Wiki beschreibt Steuerung und Metadaten, nicht vertrauliche Originale.
¶ 4. Kritikalität des KI-Dienstes
| Klasse | Typische Merkmale | Mindeststeuerung |
|---|---|---|
| K1 – kritisch | wesentliche Personen-, Sicherheits- oder Geschäftsentscheidung; hoch schutzbedürftige Daten; automatisierte Aktionen; geringe Austauschbarkeit | vertiefte Due Diligence, Managementfreigabe, Vertragsabweichungsmatrix, technische Begrenzung, enges Monitoring und getesteter Exit |
| K2 – hoch | wichtige Prozesse, vertrauliche Daten oder erhebliche Qualitäts-/Compliancewirkung | erweiterte Prüfung, dokumentierte Risikoentscheidung, periodischer Review und Exitplan |
| K3 – normal | begrenzter unterstützender Zweck mit prüfbarer menschlicher Kontrolle | Standardprüfung, Nutzungsauflagen, dokumentierte Freigabe und jährlicher Review |
| K4 – gering | Test mit öffentlichen Daten, keine Außenwirkung und keine produktive Integration | vereinfachte Prüfung, Zeitbegrenzung, Datenregel und Abschlussentscheidung |
Die höchste Einzelwirkung kann die Klasse bestimmen. Ein kostenloses Werkzeug bleibt nicht automatisch gering kritisch; Preis und Unternehmensgröße des Anbieters sind keine Risikokriterien.
¶ 5. Vorprüfung und Stop-Kriterien
Vor ausführlicher Bewertung werden Ausschluss- und Eskalationskriterien geprüft:
- unklare Vertragspartei oder nicht akzeptierbare Nutzungsbedingungen,
- Nutzung vertraulicher Eingaben zum Anbietertraining ohne wirksame Kontrolle,
- fehlende Lösch-, Export- oder Mandantentrennungsoption,
- nicht nachvollziehbare Modell- oder Unterauftragnehmerkette bei kritischer Nutzung,
- untersagte oder nicht vertretbare Anwendung,
- fehlende menschliche Eingriffs- und Stop-Möglichkeit,
- keine belastbare Vorfall- oder Sicherheitskommunikation,
- wesentliche Leistungsbehauptungen ohne prüfbare Grundlage,
- nicht beherrschbare Rechtsraum-, Lock-in- oder Konzentrationsrisiken.
Ein Stop-Kriterium führt zu Ablehnung, eingeschränktem Test oder dokumentierter Managementeskalation. Beschaffungsdruck hebt die Prüfung nicht auf.
¶ 6. Due-Diligence-Matrix
| Prüffeld | Leitfragen | Erwarteter Nachweis |
|---|---|---|
| Organisation und Governance | Wer verantwortet Sicherheit, Qualität, KI-Risiken und Beschwerden? | Rollen, Richtlinien, Zertifikate und Ansprechpartner |
| System und Modell | Was wird bereitgestellt und welche Version wurde geprüft? | System-/Modellkarte, Leistungsbeschreibung, Versionsinformation |
| Zweck und Grenzen | Für welche Kontexte, Sprachen und Entscheidungen ist der Dienst geeignet? | Nutzungsanleitung, Einschränkungen, Test- und Validierungsangaben |
| Daten | Welche Daten werden verwendet, gespeichert, übertragen oder zum Training genutzt? | Datenfluss, Aufbewahrung, Opt-out/Vertrag und Löschverfahren |
| Herkunft und Rechte | Woher stammen Trainings-, Fine-Tuning- und Wissensdaten? | Herkunfts- und Lizenzinformation im zulässigen Umfang |
| Qualität und Bias | Welche Metriken, Gruppen, Fehlerbilder und Randfälle wurden geprüft? | Evaluationsbericht, Testmethodik und bekannte Grenzen |
| Sicherheit | Wie werden Modell, API, Identitäten, Geheimnisse und Ausgaben geschützt? | Sicherheitskonzept, Prüfbericht, Schwachstellenprozess und Logging |
| Aufsicht und Transparenz | Welche Informationen und Eingriffsmöglichkeiten unterstützt der Dienst? | UI-/API-Funktionen, Protokolle, Kennzeichnung und Anleitungen |
| Lieferkette | Welche wesentlichen Unterauftragnehmer, Modelle und Regionen wirken mit? | aktuelle Kettenübersicht und Änderungsmechanismus |
| Betrieb und Änderung | Wie werden Updates, Drift, Abkündigung und Störungen gesteuert? | Releaseprozess, Änderungsmitteilung, SLA und Statuskanal |
| Vorfälle | Welche Ereignisse werden wann und an wen gemeldet? | Meldeprozess, Fristen, Kontakt und Unterstützungsumfang |
| Exit | Können Daten, Prompts, Konfigurationen und Wissen migriert und gelöscht werden? | Exportformate, Übergang, Löschbestätigung und Exitunterstützung |
Nachweise werden auf Scope, Gültigkeit, Herausgeber, Einschränkungen und tatsächliche Aussage geprüft. Ein Zertifikat ersetzt weder den anwendungsbezogenen Test noch die Prüfung eigener Konfiguration und Nutzung.
¶ 7. Eigenprüfung statt Anbieter-Marketing
| Aussage | Unzureichend | Belastbarer Umgang |
|---|---|---|
| „Enterprise-grade“ | Marketingbegriff | konkrete Sicherheits-, Daten-, Support- und Änderungsmerkmale prüfen |
| „Keine Trainingsnutzung“ | unklar für Logs, Feedback und Unterauftragnehmer | Vertrag, Einstellungen, Datenfluss und Testkonto abgleichen |
| „Halluziniert selten“ | keine Zielgruppe, Sprache oder Messmethode | eigene repräsentative Testfälle und Akzeptanzgrenzen verwenden |
| „DSGVO-konform“ | pauschale Rechtsbehauptung | Rollen, Vertrag, Zwecke, Transfers, Rechte und TOM selbst bewerten |
| „Human in the Loop“ | keine Aussage zu Kompetenz und Eingriff | Aufsichtsrolle, Information, Zeit, Befugnis und Stop-Funktion testen |
| „Auditierbar“ | Zugriff und Export unklar | konkrete Logdaten, Aufbewahrung, Rollen und Stichproben nachweisen |
¶ 8. Shared-Responsibility-Matrix
| Kontrollbereich | Anbieter | Eigene Organisation | Nachweis |
|---|---|---|---|
| Basismodell und Plattform | Modell-/Plattformbetrieb, dokumentierte Grenzen | Eignung für eigenen Zweck prüfen | Modellkarte plus eigene Bewertung |
| Mandant und Konfiguration | sichere Funktionen bereitstellen | Einstellungen, Identitäten und Datenregeln konfigurieren | Konfigurationsbaseline |
| Eingabedaten | vertraglich zugesicherte Verarbeitung | zulässige Datenklassen und Minimierung durchsetzen | Nutzungsregel und Stichprobe |
| Prompt und Wissensbasis | technische Verarbeitung | Qualität, Schutz und Versionslenkung verantworten | Prompt-/RAG-Freigabe |
| Ausgabequalität | bekannte Leistungsmerkmale mitteilen | fachliche Tests, Aufsicht und Grenzwerte anwenden | Test- und Reviewbericht |
| Transparenz | Funktionen und Anbieterinformation unterstützen | kontextbezogene Information und Kennzeichnung umsetzen | freigegebenes Transparenzprofil |
| Vorfall | Dienstereignisse melden und unterstützen | bewerten, begrenzen, intern/extern melden und nachverfolgen | Vorfallakte |
| Exit | Export- und Löschfunktionen bereitstellen | Migration, Zugriffsentzug und Abnahme planen | Exitprotokoll |
Eine Lücke zwischen den Spalten wird als Risiko oder Vertragsabweichung geführt; sie verschwindet nicht durch den Begriff „Shared Responsibility“.
¶ 9. Vertragsanforderungen für KI-Dienste
| Vertragsbaustein | Mindestinhalt |
|---|---|
| Leistungsgegenstand | Dienst, Modellfamilie, Funktionen, Regionen und zulässige Zwecke |
| Datenverwendung | Eingaben, Ausgaben, Metadaten, Training, Feedback, Aufbewahrung und Löschung |
| Schutz und Vertraulichkeit | Zugriff, Mandantentrennung, Verschlüsselung, Geheimnisse und Personalpflichten |
| Qualität und Grenzen | zugesicherte Merkmale, bekannte Einschränkungen und Unterstützungsleistungen |
| Änderung | Vorankündigung, prüfbare Releaseinformation, Widerspruchs-/Übergangsoption und Abkündigung |
| Unterauftragnehmer | Transparenz, Flow-down, Änderungsweg und relevante Orte |
| Nachweise | Prüfberichte, Informationen, Audit-/Auskunftsrechte und Mängelbeseitigung |
| Vorfälle und Schwachstellen | Meldeinhalt, Frist, Kontakt, Kooperation, Beweissicherung und Updates |
| regulatorische Kooperation | erforderliche Informationen und Unterstützung entsprechend tatsächlicher Rolle |
| Rechte und Inhalte | Nutzungsrechte, Schutz fremder Rechte und Verantwortungsabgrenzung |
| Kontinuität | Verfügbarkeit, Wiederherstellung, Notbetrieb und Support |
| Exit | Export, Formate, Fristen, Unterstützung, Datenlöschung und fortgeltende Pflichten |
Abweichungen von Mindestanforderungen erhalten Owner, Bewertung, Ersatzkontrolle, Ablaufdatum und befugte Risikoentscheidung.
¶ 10. Entscheidungsablauf vor Produktivnutzung
flowchart TD
A[Bedarf und KI-Anwendungsfall erfasst] --> B[Kette Rolle und Kritikalität bestimmen]
B --> C{Stop-Kriterium vorhanden?}
C -->|Ja| D[Ablehnen begrenzen oder Management eskalieren]
C -->|Nein| E[Due Diligence und Eigentest]
E --> F[Vertrag Shared Responsibility und Datenschutz prüfen]
F --> G{Nachweise und Kontrollen ausreichend?}
G -->|Nein| H[Maßnahme Ersatzkontrolle oder Risikoentscheidung]
H --> G
G -->|Ja| I[Pilot mit Daten- und Nutzungsgrenzen]
I --> J{Akzeptanzkriterien erfüllt?}
J -->|Nein| K[Stop Rückfall oder Nachbesserung]
J -->|Ja| L[Datierte Produktivfreigabe mit Auflagen]
L --> M[Änderungen Leistung Vorfälle und Exit überwachen]
¶ 11. Änderungen des Anbieters
Wesentliche Änderungen lösen eine erneute anwendungsbezogene Prüfung aus:
| Änderung | Mindestreaktion |
|---|---|
| neues Modell oder stilles Modellrouting | Vergleichstest, Grenzen und Freigabeumfang prüfen |
| geänderte Trainings- oder Datennutzung | Vertrag, Datenschutz, Geheimnisschutz und Nutzungsregel prüfen |
| neue Funktion oder Agentenaktion | Berechtigungen, Fehlwirkung und Aufsicht neu bewerten |
| neuer Unterauftragnehmer oder Standort | Zugriff, Rechtsraum, Sicherheit und Widerspruchsoption prüfen |
| Filter-/Moderationsänderung | Sicherheits- und Qualitätsfälle erneut testen |
| Preismodell, Limit oder Abkündigung | Kontinuität, Lock-in und Exitfähigkeit bewerten |
| Fusion, Verkauf oder Kontrollwechsel | Rechtsträger, Vertrag, Konzentration und Risikoentscheidung aktualisieren |
Fehlt eine verlässliche Änderungsinformation, wird dies als Kontrollschwäche behandelt. Kritische Anwendungen benötigen dann technische Versionserkennung, verstärkte Regressionstests, Einschränkung oder eine Alternative.
¶ 12. KI-Lieferantenvorfälle
Melderelevante Ereignisse umfassen nicht nur Ausfälle oder Datenpannen:
- erhebliche Qualitätsverschlechterung oder systematische Falschausgaben,
- unerwartete Modell- oder Verhaltensänderung,
- Jailbreak, Prompt Injection, Datenabfluss oder unzulässige Aktion,
- fehlerhafte Kennzeichnung oder Verlust von Protokollen,
- diskriminierende oder gefährliche Ausgaben,
- nicht angekündigte Daten-, Standort- oder Unterauftragnehmeränderung,
- Verlust einer erforderlichen Zertifizierung oder regulatorischen Grundlage,
- Abkündigung, Sperrung oder Kapazitätsbeschränkung.
Vertragliche Meldung des Anbieters und eigene Beobachtung werden zusammengeführt. Die Organisation prüft Auswirkungen auf KI-Anwendungsfälle, Betroffene, Datenschutz, Informationssicherheit, Kundenpflichten und gegebenenfalls Behördenmeldungen.
¶ 13. Konzentration, Lock-in und Exit
| Abhängigkeit | Beispiel | Gegenmaßnahme |
|---|---|---|
| Anbieter | viele kritische Anwendungen bei einem Dienst | Portfolioübersicht, Ausweichstrategie und Priorisierung |
| Modell/API | proprietäre Schnittstelle oder spezielle Funktionen | Abstraktionsschicht, dokumentierte Alternative oder Ersatzprozess |
| Datenformat | nicht exportierbare Wissensbasis oder Logs | offene Formate, regelmäßiger Probeexport und eigene Sicherung |
| Kompetenz | Know-how nur beim Anbieter | interne Rollen, Dokumentation und Übungen |
| Vertrag/Kosten | hohe Ausstiegsgebühren oder kurze Abkündigung | Exitklausel, Übergangszeit und Kostenmodell |
| Region/Infrastruktur | gemeinsame Cloud- oder Identitätsabhängigkeit | Kumulrisiko und Notbetrieb bewerten |
Der Exitplan wird vor Produktivstart erstellt. Er umfasst Daten, Prompts, Systemanweisungen, Wissensbestände, Konfigurationen, Benutzer, Schlüssel, Protokolle, Modelle, Schnittstellen, Dokumentation, Ersatzprozess, Löschung und Abnahme.
¶ 14. Dummy-Anbieterprofil
| Feld | Fiktives Beispiel |
|---|---|
| Lieferanten-/Service-ID | KI-LF-0012 / KI-SVC-0021 |
| Dienst | Cloudbasierter Assistent für interne Protokollentwürfe |
| verknüpfte KI-ID | KI-ANW-0003 |
| Kette | Hauptanbieter; externes Sprachmodell und europäisches Hosting – Einzelheiten offen |
| Daten | interne Gesprächsnotizen ohne besondere Kategorien; keine freigegebenen Kundengeheimnisse |
| Trainingsnutzung | laut Vertragsentwurf deaktiviert; technische und vertragliche Bestätigung ausstehend |
| Kritikalität | K2 – hoch |
| eigene Tests | 42 Fachfälle; 3 kritische Quellenfehler; Pilotgrenze erforderlich |
| Vertragslücke | Änderungsfrist und Unterauftragnehmerinformation noch offen |
| Freigabe | 🟡 zeitlich begrenzter Pilot mit 12 geschulten Personen |
| Auflagen | keine automatische Veröffentlichung; Quellenprüfung; monatliche Stichprobe |
| Exit | Export der Vorlagen möglich; Lösch- und Wechseltest noch nicht durchgeführt |
| nächste Entscheidung | Vertragslücken schließen und 20 Grenzfälle nachtesten |
Das Profil zeigt bewusst offene Punkte. Ein Pilotstatus ist keine Produktivfreigabe und die Lieferantenaussage ist noch kein Wirksamkeitsnachweis.
¶ 15. Qualitätsampel der Lieferantensteuerung
| Prüffeld | 🔴 Rot | 🟡 Gelb | 🟢 Grün |
|---|---|---|---|
| KI-Kette | wesentliche Parteien unbekannt | Hauptanbieter bekannt, Einzelheiten offen | relevante Modelle, Dienste, Orte und Abhängigkeiten nachvollziehbar |
| Rolle | Marketingbegriff übernommen | Erstindikation ohne Freigabe | tatsächliche Rolle datiert und fachlich geprüft |
| Daten | Trainings- und Aufbewahrungsnutzung unklar | Zusage ohne vollständige Kontrolle | Vertrag, Einstellung, Datenfluss und Stichprobe konsistent |
| Leistung | Demo oder Benchmark genügt | begrenzte Eigenauswahl getestet | repräsentative Fälle, Randgruppen, Grenzen und Schwellen geprüft |
| Vertrag | Standardbedingungen ohne Lückenanalyse | Abweichungen mit offenen Maßnahmen | Mindestanforderungen oder bewertete Ersatzkontrollen freigegeben |
| Änderungen | unangekündigt und unentdeckt | Mitteilung ohne feste Reaktion | Frist, Regressionstest, Entscheidung und Rückfall geregelt |
| Vorfälle | kein Kontakt oder keine Unterstützung | allgemeiner Support | klassifizierte Meldung, Frist, Kooperation und Übungen |
| Exit | kein realistischer Ersatz | Papierplan | Probeexport, Zugriffsentzug, Ersatz und Löschung getestet |
Ein rotes Feld bei unzulässiger Datennutzung, nicht beherrschbarer Rolle, kritischer Sicherheitslücke oder fehlender Stop-/Exitfähigkeit verhindert die Freigabe beziehungsweise löst eine Managemententscheidung aus.
¶ 16. Nachweise und Kennzahlen
¶ Mindestnachweise
- verknüpfter Anbieter-, Service- und KI-Anwendungsregistereintrag,
- Ketten- und Rollenübersicht,
- Kritikalitäts- und Risikobewertung,
- Due-Diligence- und Nachweisprüfung,
- anwendungsbezogener Test- und Pilotbericht,
- Vertrags- und Shared-Responsibility-Matrix,
- Datenschutz-, Sicherheits- und Rechteprüfung,
- dokumentierte Freigabe, Auflagen und Risikoakzeptanzen,
- Änderungs-, Vorfall- und Reviewprotokolle,
- Exitplan und risikobasierter Exittest.
¶ Managementkennzahlen
| Kennzahl | Aussage |
|---|---|
| KI-Dienste mit bestätigter Kette und Owner | Bestands- und Verantwortungslücken |
| kritische/hohe Dienste mit aktueller Eigenevaluation | Qualität der anwendungsbezogenen Prüfung |
| offene Vertragsabweichungen nach Kritikalität | nicht nur Anzahl, sondern Wirkung sichtbar machen |
| ungeplante Modell- oder Funktionsänderungen | Änderungs- und Anbieterreife |
| Lieferantenvorfälle bis interne Entscheidung | Reaktionsfähigkeit der Organisation |
| Dienste mit aktueller Exitstrategie und Probeexport | tatsächliche Wechsel- und Wiederanlauffähigkeit |
| Konzentration kritischer Anwendungen je Anbieter/Modell | Kumul- und Lock-in-Risiko |
| überfällige Anbieterreviews | Steuerungsschuld und Priorität |
¶ 17. Rollen und Entscheidungskompetenzen
| Rolle | Verantwortung |
|---|---|
| fachlicher KI-Owner | Bedarf, Zweck, Wirkung, Testfälle, Auflagen und laufende Leistung |
| Einkauf/Lieferantenmanagement | Beschaffung, Vertragsakte, Änderungen und kaufmännische Eskalation |
| technischer Owner | Architektur, Integration, Konfiguration, Logging, Rückfall und Exit |
| AIMS-Verantwortung | Methodik, Registerverknüpfung, Kontrollsatz und Wirksamkeitsauswertung |
| Informationssicherheit | Bedrohungen, Zugriffe, Schwachstellen, Vorfälle und Nachweise |
| Datenschutz | Rollen, Datenflüsse, Vertrag, Transfers, Rechte, Löschung und DSFA |
| Recht/Compliance | AI-Act-Rolle, Vertrags-, Rechte- und Branchenanforderungen |
| BCM | Ausfallwirkung, Notbetrieb, Wiederanlauf und Anbieterwechsel |
| Geschäftsführung | kritische Abweichung, Restrisiko, Konzentration und Ressourcen entscheiden |
¶ 18. Interne Verknüpfungen
- ISO/IEC 42001 – KI-Managementsystem
- KI-Anwendungsregister
- KI-Risiko- und Folgenbewertung
- KI-Freigabe und menschliche Aufsicht
- Datenmanagement und Datenqualität
- KI-Systemlebenszyklus und Änderungsmanagement
- KI-Transparenz, Kennzeichnung und Kommunikation
- KI-Kompetenz, Schulung und Befähigungsnachweise
- Lieferanten und Dienstleister
- Lieferantenbewertungen
- Externe Dienste und Cloud
- Auftragsverarbeitung
- Lieferantenkontrollen und Exit
- Incident Response
- Notfallvorsorge und BCM
¶ 19. Offizielle Quellen und Abgrenzung
- ISO: ISO/IEC 42001:2023 – AI management systems
- ISO: ISO/IEC 23894:2023 – Guidance on risk management
- ISO: ISO/IEC 5338:2023 – AI system life cycle processes
- EUR-Lex: Verordnung (EU) 2024/1689, insbesondere Artikel 25 und 26
- EU-Kommission: Leitlinien für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck
- SMCT MANAGEMENT: Beratung und Unterstützung bei ISO/IEC 42001
Diese Seite beschreibt eine eigene organisatorische Methode und ergänzt das allgemeine Lieferantenmanagement um KI-spezifische Prüfungen. Sie gibt lizenzierte Normtexte nicht wörtlich wieder und ersetzt keine Rechtsberatung. Rolle, Pflichten, Vertrag und Prüfmaßstab werden für den konkreten Anwendungsfall und aktuellen Rechtsstand bestimmt.
¶ 20. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 10.08.2026 | Erstfassung mit KI-Wertschöpfungskette, Register, Kritikalität, Stop-Kriterien, Due Diligence, Eigentest, Shared Responsibility, Vertrag, Änderungs- und Vorfallsteuerung, Konzentration, Exit, Dummy-Profil, Ampel und Nachweisen | Musterredaktion | Ausstehend | – |
| 0.2 | 10.08.2026 | Interne und externe KI-Kompetenz als Lieferanten-, Betriebs-, Vorfall- und Exitvoraussetzung verknüpft | Musterredaktion | Ausstehend | – |
Seite 1 von 1 · AIMS-VA-05-01 · Version 0.2