Anbieter und Lieferkette identifizieren
Die Prüfung beginnt mit der juristischen Person, die Vertragspartner wird, und endet nicht bei deren Markenname. Zu erfassen sind Konzernstruktur, wirtschaftliche Stabilität, Leistungs- und Supportstandorte, zentrale Unterauftragnehmer und Abhängigkeiten von fremden Modellen oder Cloud-Infrastrukturen. Diese Informationen zeigen, wer Zusagen erfüllen kann und an welchen Stellen Konzentrations-, Ausfall- oder Durchsetzungsrisiken entstehen.
Bei geschäftskritischen Anwendungen sollte auch geprüft werden, wie der Anbieter auf Übernahme, Insolvenz oder Einstellung des Produkts vorbereitet ist. Referenzen und Finanzinformationen sind kontextabhängig zu bewerten; junge Anbieter sind nicht automatisch ungeeignet, benötigen aber möglicherweise stärkere Exit- und Kontinuitätsmechanismen. Eine aktuelle Lieferkettenübersicht mit Änderungsanzeige ist wertvoller als eine einmalige, allgemein gehaltene Selbstauskunft.
- Vertragspartner und Konzernbeziehungen verifizieren
- Unterauftragnehmer, Modell- und Cloud-Abhängigkeiten erfassen
- Kontinuität, Support und Konzentrationsrisiko bewerten
Quellen: [1]
Produkt, Modell und Version verifizieren
Der Anbieter sollte bestimmungsgemäßen Zweck, ausgeschlossene Nutzungen, Systemarchitektur, eingesetzte Modelle und aktuelle Version nachvollziehbar beschreiben. Dazu gehören Datenquellen, Evaluierungsmethoden, bekannte Grenzen, typische Fehler und Abhängigkeiten von Einstellungen. Ein Produktname ohne Versionsbezug ist keine stabile Prüfgrundlage, weil sich Verhalten und Risikoprofil durch Modellwechsel, neue Werkzeuge oder geänderte Moderation deutlich verändern können.
Leistungsbehauptungen müssen zum eigenen Einsatz passen. Das Unternehmen sollte Berichte nicht nur entgegennehmen, sondern Stichproben mit repräsentativen Daten und Grenzfällen durchführen. Zu prüfen sind Genauigkeit, Fehlertypen, Robustheit, Übersteuerbarkeit und Protokollierung. Bei generativen Funktionen sind Halluzinationen, Prompt-Manipulation, Datenabfluss und unangemessene Inhalte zu berücksichtigen. Ergebnisse und Testumgebung müssen so dokumentiert sein, dass spätere Vergleiche möglich bleiben.
- Zweck, Ausschlüsse, Architektur und Version festhalten
- Evaluierungen auf Einsatzkontext und Testdaten prüfen
- Eigene Tests samt Grenzfällen dokumentieren
Quellen: [1]
Regulatorische Evidenz risikobasiert verlangen
Der Anbieter sollte seine Rolle nach dem AI Act und die vorgeschlagene Klassifizierung begründen. Je nach System kommen Anleitungen, technische Dokumentation, Konformitätsunterlagen, Registrierungsangaben, Protokollzugang und Informationen für menschliche Aufsicht in Betracht. Nicht jedes Dokument ist bereits für jedes System verpflichtend. Die Due Diligence muss daher zwischen heute geltenden Anforderungen, künftigen Hochrisikopflichten und freiwillig vorgezogenen Nachweisen unterscheiden.
Selbstdeklarationen wie „EU compliant“ sind ohne Geltungsbereich und Belege wenig aussagekräftig. Zertifikate müssen Aussteller, Standard, geprüfte Organisation, Dienst, Version und Laufzeit erkennen lassen. Externe Prüfberichte können helfen, ersetzen aber nicht die Bewertung offener Feststellungen. Wenn Pflichten später anwendbar werden, sollte der Anbieter eine realistische Roadmap und vertragliche Unterstützung zusagen, statt nur auf verschobene Fristen zu verweisen.
- AI Act Rolle und Klassifizierung begründen lassen
- Dokumente nach Anwendbarkeit und Termin ordnen
- Zertifikate und Prüfberichte auf Geltungsbereich lesen
Datenschutz, Geheimnisse und IP getrennt prüfen
Im Datenschutzblock sind Rollen, Verarbeitungszwecke, Datenkategorien, Speicherfristen, Unterauftragnehmer, internationale Transfers, Sicherheit und Betroffenenrechte zu prüfen. Eine Auftragsverarbeitungsvereinbarung beantwortet nicht automatisch, ob Eingaben für Produktverbesserung oder Training genutzt werden dürfen. Technische Einstellungen müssen mit dem Vertrag übereinstimmen und für Administratoren überprüfbar sein. Datenschutzrechtliche Freigabe und AI Act Bewertung bleiben unterschiedliche Ergebnisse.
Der Geheimnis- und IP-Block untersucht, ob vertrauliche Eingaben isoliert werden, welche Rechte der Anbieter an Prompts, Ausgaben und Feedback beansprucht und wie Rechte Dritter behandelt werden. Eine Zusage zu Datenschutz ist keine Zusage zum Urheberrecht; eine Freistellung ersetzt keine Nutzungsrechte. Das Unternehmen benötigt Einsatzregeln für sensible Inhalte, Quellenprüfung und menschliche Freigabe, selbst wenn der Anbieter weitreichende Garantien verspricht.
- Datenverwendungen und technische Einstellungen abgleichen
- Vertraulichkeit und Mandantentrennung nachweisen lassen
- Rechte an Eingaben, Ausgaben und Feedback ausdrücklich regeln
Sicherheit und Vorfallfähigkeit prüfen
Sicherheitsunterlagen sollten Bedrohungsmodell, Zugriffskontrollen, Verschlüsselung, Schwachstellenmanagement, Mandantentrennung, Protokollierung und Wiederherstellung abdecken. Bei KI Diensten kommen modellspezifische Risiken hinzu, etwa manipulierte Eingaben, unzulässige Werkzeugaufrufe, Datenextraktion oder vergiftete Wissensquellen. Allgemeine Cloud-Zertifikate können relevant sein, erfassen aber nicht zwangsläufig diese Produktfunktionen oder die konkrete Version.
Die Due Diligence braucht Informationen zu vergangenen wesentlichen Vorfällen und zum Meldeprozess. Vertraglich festzulegen sind Ansprechpartner, Meldefristen, Mindestinhalt, Zusammenarbeit, Beweissicherung und Abhilfe. Entscheidend ist auch, ob der Auftraggeber den Dienst begrenzen oder abschalten kann, ohne kritische Prozesse unkontrolliert zu unterbrechen. Ein getesteter Rückfallbetrieb ist bei hoher Abhängigkeit wichtiger als ein nur schriftlich erwähnter Notfallplan.
- Produktspezifische statt nur allgemeine Kontrollen prüfen
- Vorfallmeldung und Zusammenarbeit konkret vereinbaren
- Abschaltung und Rückfallbetrieb praktisch testen
Quellen: [1]
Evidenz in eine belastbare Entscheidung überführen
Der Abschlussbericht sollte jede wesentliche Aussage mit Dokument, Test oder Interview belegen und verbleibende Unsicherheit offen ausweisen. Offene Punkte erhalten Eigner, Frist und Entscheidungsauswirkung. Ein Conditional Go eignet sich nur, wenn Auflagen konkret, überprüfbar und vor der jeweiligen Nutzungsstufe erfüllbar sind. Kritische Lücken bei verbotener Nutzung, Datenzugriff, Sicherheit oder Kontrollierbarkeit können ein No-Go erfordern.
Die Freigabe ist zeitlich und sachlich zu begrenzen. Modellwechsel, neue Unterauftragnehmer, geänderte Datenverwendung, erhebliche Vorfälle oder Ausweitung des Zwecks lösen eine Re-Prüfung aus. Der Digital Omnibus verändert Fristen und einzelne Pflichten, beseitigt aber nicht die Aufgabe, Anbieter belastbar auszuwählen und zu überwachen. Eine sorgfältige Due Diligence reduziert Informationslücken, garantiert jedoch weder Fehlerfreiheit noch Haftungsausschluss.
- Evidenz und offene Punkte in einer Matrix führen
- Go, Conditional Go oder No-Go begründen
- Änderungsauslöser und Re-Prüfdatum festlegen
Entscheidung: Go, Conditional Go oder No-Go?
- Anbieter, Lieferkette, Produkt, Modell und Version sind eindeutig identifiziert.
- Leistungs-, Sicherheits- und Regulierungsbehauptungen sind durch Evidenz geprüft.
- Datenschutz, Geheimnisschutz und IP wurden getrennt bewertet.
- Offene Punkte haben messbare Auflagen, Eigner und Fristen.
- Re-Prüfung, Vorfallreaktion, Exit und Rückfallbetrieb sind festgelegt.
Häufige Fragen
Reicht ein bekanntes Sicherheitszertifikat für die Freigabe?
Nein. Ein Zertifikat kann einen wichtigen Nachweis liefern, muss aber hinsichtlich Organisation, Dienst, Version, Kontrollumfang und Laufzeit gelesen werden. Produktspezifische KI Risiken und der konkrete Einsatz können zusätzliche Tests und Vertragsregeln verlangen.
Welche Dokumente sind vor einem kleinen Pilot nötig?
Die Tiefe darf geringer sein als beim geschäftskritischen Rollout, doch Zweck, Daten, Nutzer, Anbieterrolle, Sicherheit, erlaubte Nutzung und Exit sollten geklärt sein. Ein Pilot ist kein rechtsfreier Raum und braucht klare Grenzen.
Was bedeutet Conditional Go?
Die Nutzung wird nur in einem eindeutig begrenzten Umfang und unter überprüfbaren Auflagen zugelassen. Verantwortliche, Fristen, Nachweise, Stoppschwellen und die Bedingung für eine Ausweitung müssen dokumentiert sein; bloße Absichtserklärungen genügen nicht.
Primärquellen
- Konsolidierter AI Act
- Verordnung (EU) 2026/1744
- Datenschutz-Grundverordnung
- Aktualisierte EU-Modellvertragsklauseln für KI Beschaffung
- UWG § 26b zum Geschäftsgeheimnis
- Österreichisches Urheberrechtsgesetz
Rechtsstand: 16. September 2026. Der AI Act gilt in der durch Verordnung (EU) 2026/1744 geänderten Fassung. Spezifische Hochrisikoanforderungen gelten gestaffelt ab 2. Dezember 2027 oder 2. August 2028; andere Pflichten und sonstiges Recht können bereits gelten. Eine einheitliche gesetzliche KI-Anbieter-Due-Diligence besteht nicht; die Prüfung ist eine risikobasierte Organisations- und Vertragsaufgabe, deren Einzelanforderungen aus den anwendbaren Rechtsgebieten folgen. Vor Veröffentlichung sind Fristen und Leitlinien erneut zu prüfen.