KI Drittanbieter prüfen: Verträge und Lieferkette nach dem AI Act

Due Diligence vor der Auswahl

Erfassen Sie Zweck, Nutzergruppen, betroffene Personen, Datenarten, Hostingorte, Modellherkunft, Unterauftragnehmer und technische Schnittstellen, bevor Preis oder Funktionsumfang die Auswahl bestimmen. Ordnen Sie für den konkreten Use Case ein, ob Verbote, Transparenzpflichten, GPAI Regeln oder das künftige Hochrisiko-Regime berührt sein können.

Verlangen Sie eine nachvollziehbare Systembeschreibung, Sicherheitsnachweise, Testinformationen, Datenschutzunterlagen und eine vollständige Lieferkettenübersicht. Offene Angaben werden als Entscheidungsrisiko dokumentiert; sie dürfen nicht durch allgemeine Marketingaussagen ersetzt werden. Einkauf, Legal, Datenschutz und Informationssicherheit zeichnen nur jene Prüffelder ab, für die sie tatsächlich fachlich verantwortlich sind. Der Prüfvermerk nennt Informationslücken, kompensierende Maßnahmen, Verantwortliche und Fälligkeiten. Kritische Nachweise müssen vor Vertragsschluss oder ausdrücklich vor dem Go-live vorliegen.

• Zweck, Rolle, Datenflüsse, Hosting und Modellherkunft vor der Auswahl erfassen.
• Unterauftragnehmer sowie Sicherheits- und Compliance-Nachweise risikobasiert prüfen.
• Informationslücken mit Verantwortlichem, Frist und Freigabebedingung dokumentieren.

Quellen: [1] [2] [3] [4] [5] [6]

Rollenwechsel nach Artikel 25 verhindern

Artikel 25 betrifft in diesem Zusammenhang Hochrisiko-Systeme. Ein Händler, Einführer, Betreiber oder sonstiger Dritter gilt insbesondere dann als Anbieter, wenn er seinen Namen oder seine Marke auf einem bereits vermarkteten oder in Betrieb genommenen Hochrisiko-System anbringt oder ein solches System wesentlich verändert und es hochriskant bleibt. Gleiches gilt bei einer Zweckänderung, durch die ein zuvor nicht hochriskantes System nach Artikel 6 hochriskant wird. Nicht jede Konfiguration oder jedes Fine-Tuning löst daher automatisch den Rollenwechsel aus.

Dokumentieren Sie Ausgangszweck, Risikoeinstufung, freigegebene Änderungen, Markenauftritt und Verantwortungsgrenzen versioniert. White-Label-Vertrieb, Integration in ein eigenes Produkt, Funktions- oder Zweckänderungen werden vor Umsetzung anhand der konkreten Tatbestände geprüft. Der Lieferant soll erforderliche Informationen, technischen Zugang und Unterstützung schriftlich zusagen; die interne rechtliche Einordnung darf dennoch nicht vollständig an ihn ausgelagert werden. Offene Punkte erhalten Verantwortliche, Frist und eine dokumentierte Freigabe-, Auflagen- oder Eskalationsentscheidung.

• Artikel 25 nur bei erfüllten Hochrisiko-Tatbeständen anwenden.
• Markenauftritt, wesentliche Änderung und hochrisikobegründende Zweckänderung getrennt prüfen.
• Freigegebene Konfigurationen und Änderungsgrenzen versioniert festhalten.

Quellen: [1] [2]

Vertragliche Mindestregeln festlegen

Beschreiben Sie erlaubte Zwecke, ausgeschlossene Daten, Nutzerkreise, Regionen, Modelle und Schnittstellen präzise. Regeln Sie Verfügbarkeit von Gebrauchsanweisungen, Protokollen, Monitoringdaten und technischen Informationen ebenso wie Reaktionszeiten bei Sicherheitsereignissen, Fehlfunktionen und behördlichen Anfragen. Allgemeine Compliance-Klauseln ohne überprüfbare Leistungspflichten reichen für kritische Prozesse nicht aus.

Vereinbaren Sie Änderungsmitteilungen vor Modellwechseln, neuen Unterauftragnehmern oder erheblichen Funktionsänderungen. Audit- und Auskunftsrechte müssen praktisch nutzbar sein; dabei sind Vertraulichkeit und Schutz berechtigter Geschäftsgeheimnisse auszubalancieren. Haftung, Freistellungen und Versicherungen sind risikogerecht zu verhandeln, liefern aber keine Gewähr dafür, dass das Unternehmen seine eigenen gesetzlichen Pflichten erfüllt. Abhilfefristen, Eskalationsstufen, vorläufige Nutzungseinschränkungen und Kündigungsrechte müssen zu Kritikalität und realen Wechselmöglichkeiten passen.

• Zulässige Nutzung, Daten, Modelle und Schnittstellen vertraglich eingrenzen.
• Änderungs-, Vorfall-, Informations- und Unterstützungspflichten messbar formulieren.
• Audit, Abhilfe, Exit und Datenrückgabe praktisch durchsetzbar ausgestalten.

Quellen: [1] [2]

Betrieb und menschliche Aufsicht absichern

Der Anbieter muss Informationen liefern, mit denen Nutzer Grenzen, vorgesehene Leistung, bekannte Risiken und notwendige menschliche Aufsicht verstehen können. Definieren Sie intern, wer Ergebnisse prüft, wann eine Entscheidung übersteuert wird und welche Fälle automatisiert überhaupt nicht verarbeitet werden dürfen. Besonders bei Auswirkungen auf Beschäftigte, Kunden oder Zugang zu Leistungen braucht es klare Eskalationswege.

Testen Sie das System mit repräsentativen Fällen und dokumentieren Sie Fehlerraten, Abbruchkriterien sowie zulässige Restunsicherheit. Betreiber dürfen sich nicht darauf verlassen, dass ein Label oder eine Anbieterzusage die konkrete Verwendung abdeckt. Datenschutz, Arbeitsrecht, Gleichbehandlung, Geheimnisschutz, Produktsicherheit und sektorspezifische Regeln bleiben neben dem AI Act eigenständig zu prüfen. Freigabeauflagen werden in Bedienungsanweisungen, Berechtigungen und Kontrollen übersetzt; wiederkehrende Abweichungen führen zu Nachschulung, technischer Begrenzung oder Aussetzung.

• Anleitungen und Informationen für menschliche Aufsicht und Betreiber-Monitoring verlangen.
• Repräsentative Tests, Fehlerraten und Abbruchkriterien vor dem Einsatz dokumentieren.
• Datenschutz, Arbeitsrecht, Gleichbehandlung und sonstiges Fachrecht gesondert prüfen.

Quellen: [1] [2]

GPAI und Hochrisiko getrennt prüfen

Trennen Sie die Lieferkette eines GPAI Modells von jener des darauf aufgebauten KI Systems. Pflichten für GPAI Modellanbieter gelten grundsätzlich bereits seit 2. August 2025; die besonderen Hochrisikopflichten folgen nach dem Digital Omnibus für Anhang III grundsätzlich ab 2. Dezember 2027 und für Systeme nach Artikel 6 Absatz 1 grundsätzlich ab 2. August 2028. Bei Produkten nach Anhang I Abschnitt B begrenzt Artikel 2 Absatz 2 die unmittelbare Geltung, sodass zusätzlich das sektorale Produktrecht zu prüfen ist. Diese Fristen und Regelungsebenen sind nicht austauschbar.

Eine Open-Source-Komponente ist keine pauschale Ausnahme für das integrierte Produkt oder die eigene Rolle. Erfassen Sie Modellversion, Lizenz, Herkunft, Trainingsinformationszugang und nachgelagerte Anpassungen. Wenn ein Lieferant mehrere Modelle dynamisch austauscht, braucht das Unternehmen Informationsrechte und Re-Tests, weil Leistungsprofil, Sicherheitslage und rechtliche Einordnung dadurch verändert werden können. Der Vertrag sollte festlegen, wann ein Modellwechsel zustimmungspflichtig ist, welche Vergleichstests erfolgen und wie bei verschlechterter Leistung oder fehlender Dokumentation reagiert wird.

• GPAI-Modell, nachgelagertes KI System und konkreten Use Case getrennt bewerten.
• Open-Source-Ausnahmen nicht pauschal auf integrierte Produkte oder eigene Rollen übertragen.
• Modellwechsel an Vorabinformation, Vergleichstest und erforderlichenfalls Zustimmung binden.

Quellen: [1] [2]

Vendor Monitoring und Exit organisieren

Bestimmen Sie Kennzahlen für Leistung, Sicherheit, Beschwerden, menschliche Übersteuerungen und Zweckabweichungen. Modellwechsel, neue Datenquellen, geänderte Unterauftragnehmer, relevante Vorfälle oder neue regulatorische Vorgaben lösen eine Re-Klassifikation aus. Der verantwortliche Owner berichtet nicht nur über Verfügbarkeit, sondern auch über Kontrollmängel und ungeklärte Risiken.

Planen Sie bereits im Vertrag Exportformate, Datenrückgabe, Löschung, Übergangsunterstützung und technische Abschaltung. Ein Exit muss möglich sein, bevor ein kritischer Dienst ausfällt oder unvertretbar wird. Die Geschäftsleitung legt Schwellen fest, bei denen Nutzung eingeschränkt, vorläufig ausgesetzt oder endgültig beendet wird; wirtschaftliche Abhängigkeit allein rechtfertigt keine Fortführung. Testen Sie den Exit für kritische Dienste einschließlich Datenexport, Kontenentzug, Ersatzprozess und Nachweis der Löschung, statt sich auf eine ungetestete Vertragsklausel zu verlassen.

• Modellwechsel, Leistungsabfall, Vorfälle und neue Unterauftragnehmer laufend überwachen.
• Re-Klassifikation und Eskalation an vorab definierte Auslöser koppeln.
• Exit einschließlich Datenexport, Löschung, Abschaltung und Ersatzprozess testen.

Quellen: [1] [2]

Häufige Fragen