Vendor-Assessment-Checkliste für KI-Anbieter

Lernziele

Sie erklären, warum strukturiertes Vendor Assessment für KI-Anbieter eine DSGVO-Pflicht und keine optionale Best Practice ist.

Sie wenden eine 7-Kriterien-Checkliste auf einen KI-Anbieter an und unterscheiden Pflichtkriterien von Kann-Kriterien.

Sie formulieren konkrete Prüffragen für einen Anbieter bezüglich AVV, Sub-Prozessoren, Datenlokation und Sicherheitszertifizierungen.

Sie leiten ein Go / No Go / Conditional Go aus dem Assessment-Ergebnis ab und begründen die Entscheidung.

Sie beschreiben die Rollen im Vendor-Assessment-Prozess (IT, Datenschutzbeauftragte:r, KI-Beauftragte:r, Fachbereich).

Auf einen Blick

Worum geht es?

Stellen Sie sich vor, ein Fachbereichsleiter in Ihrer Organisation hat ein attraktives neues KI-Tool für die Projektdokumentation entdeckt. Es spart geschätzt zwei Stunden pro Woche und Mitarbeitenden. Der Anbieter wirbt auf seiner Landingpage mit dem Siegel „DSGVO-konform”. Der Fachbereichsleiter fragt die IT: „Können wir das einführen?”

Was jetzt passiert, entscheidet darüber, ob Ihre Organisation ein kalkuliertes Risiko eingeht oder ein unkontrolliertes. Ein strukturiertes Vendor Assessment verwandelt die Marketingaussage „DSGVO-konform” in eine prüfbare Aussage — oder deckt auf, dass dahinter nichts steht als Wunschdenken.

Das Vendor Assessment für KI-Anbieter ist keine bürokratische Pflichtübung. Es ist eine unternehmerische Schutzmaßnahme. Sobald Ihre Organisation eine Auftragsverarbeitungsbeziehung mit einem KI-Anbieter eingeht — was immer dann der Fall ist, wenn personenbezogene Daten verarbeitet werden — unterliegt diese Beziehung strengen DSGVO-Anforderungen nach Art. 28. Wer diese Anforderungen nicht prüft, haftet im Schadensfall.

In dieser Lerneinheit erarbeiten Sie eine vollständige, sofort einsatzfähige Vendor-Assessment-Checkliste mit sieben Pflichtkriterien. Sie üben deren Anwendung auf bekannte KI-Anbieter und lernen, wie Go / Conditional Go / No Go-Entscheidungen systematisch begründet und dokumentiert werden. Ergänzend betrachten Sie branchenspezifische Zusatzanforderungen, die in regulierten Sektoren wie Finanz, Gesundheit oder öffentliche Verwaltung relevant werden.

Lerntext — Theorie und Konzepte

Warum Vendor Assessment eine Pflicht ist

Sobald Ihre Organisation einem KI-Anbieter personenbezogene Daten zur Verarbeitung übergibt — sei es durch die Nutzung einer API, einer SaaS-Plattform oder einer integrierten KI-Funktion — liegt eine Auftragsverarbeitung nach DSGVO Art. 28 vor. Das erfordert:

Einen schriftlichen Auftragsverarbeitungsvertrag (AVV) mit Mindestinhalt nach Art. 28 Abs. 3

Regelmäßige Überprüfung, dass der Auftragsverarbeiter ausreichende Garantien bietet

Dokumentation der getroffenen Sorgfaltsprüfung

Viele Organisationen vernachlässigen das Assessment neuer KI-Tools, weil sie schnell produktiv sein wollen. Ein Datenschutzvorfall später stellt die Frage: „Haben Sie vor der Einführung geprüft, ob der Anbieter DSGVO-konform ist?” Ohne dokumentiertes Assessment lautet die Antwort nein — und das hat rechtliche Konsequenzen.

Merksatz

„DSGVO-konform” auf einer Landingpage ist Marketing — kein Rechtsnachweis. Das Assessment wandelt Selbstauskunft in prüfbare Belege.

Abb. 102.1 — Vendor-Assessment-Prozess: Entscheidungsfluss für die Freigabe eines KI-Anbieters

Die 7 Pflichtkriterien des Vendor Assessments

Kriterium 1: Auftragsverarbeitungsvertrag (AVV / DPA)

Existiert ein AVV? Ist er DSGVO-konform nach Art. 28? Die Prüfliste umfasst:

Weisungsgebundenheit des Auftragsverarbeiters

Vertraulichkeitsverpflichtung der Mitarbeitenden

Sicherheitsmaßnahmen nach Art. 32

Unterstützung bei der Erfüllung von Betroffenenrechten

Unterstützung bei Datenschutz-Folgenabschätzungen (DSFA)

Löschpflichten bei Vertragsende

Auditrechte für den Verantwortlichen

KI-spezifische Zusatzklausel: Expliziter Ausschluss der Nutzung von Eingabedaten für Modelltraining — prüfbar formuliert und durchsetzbar gestaltet.

Kriterium 2: Sub-Prozessoren (Unterauftragnehmer)

Welche Sub-Prozessoren setzt der Anbieter ein? Eine vollständige Liste mit Sitz, Zweck und DSGVO-Konformität ist erforderlich. Werden Änderungen rechtzeitig kommuniziert — und gibt es eine Opt-out-Möglichkeit? Beispiel OpenAI: Die Sub-Processor List umfasst Hosting-Provider (Microsoft Azure), Zahlungsdienstleister und Support-Systeme. Alle Sub-Prozessoren müssen DSGVO-konform sein.

Kriterium 3: Modell-Herkunft und Trainingsdaten-Transparenz

Auf welchen Daten wurde das Modell trainiert? Existiert eine Model Card oder System Card? Für EU-AI-Act-relevante Systeme: Ist die Trainingsdaten-Dokumentation nach Art. 10 (für Hochrisiko-KI) vorhanden?

Kriterium 4: Datenlokation

Wo werden Daten verarbeitet und gespeichert? Gibt es eine EU-Datenlokations-Option? Konkrete Prüffrage: „Können Sie vertraglich garantieren, dass meine Daten die EU nicht verlassen?”

Kriterium 5: Sicherheitszertifizierungen

Mindestanforderung: SOC 2 Type II oder ISO/IEC 27001, mit aktuellem Prüfbericht (nicht älter als 12 Monate). Weitere relevante Zertifizierungen:

ISO/IEC 27701 (Datenschutz-IMS — Erweiterung von ISO 27001)

CSA STAR (Cloud Security Alliance — spezifisch für Cloud-Dienste)

C5-Testat (BSI-Anforderungen, für Behördenkunden relevant)

Kriterium 6: Incident Response und Breach Notification

Wie schnell informiert der Anbieter Ihre Organisation bei einem Sicherheitsvorfall? DSGVO Art. 33 setzt eine 72-Stunden-Frist für die Meldung an die Aufsichtsbehörde — der Anbieter muss Sie rechtzeitig informieren, damit diese Frist eingehalten werden kann. Gibt es einen dedizierten Sicherheitskontakt und eine Status-Page für laufende Vorfälle?

Kriterium 7: Exit-Strategie und Datenlöschung

Wie werden Daten bei Vertragsende gelöscht? In welchem Zeitrahmen? Gibt es einen Datenexport vor der Löschung? Wird die Löschung durch ein Löschzertifikat nachgewiesen?

Merksatz

Fehlt auch nur eines der sieben Pflichtkriterien, ist kein Go möglich. Ohne AVV gibt es keinen rechtskonformen Betrieb — unabhängig davon, wie attraktiv das Produkt ist.

Kann-Kriterien (wünschenswert, nicht zwingend)

Neben den Pflichtkriterien gibt es eine Reihe von Qualitätsindikatoren, die zeigen, wie ernsthaft ein Anbieter seine Sicherheits- und Compliance-Verpflichtungen nimmt:

Penetration-Testing-Reports (öffentlich zugänglich oder auf Anfrage)

Bug-Bounty-Programm mit definiertem Scope

Responsible-AI-Prinzipien und öffentlicher Ethik-Kodex

Erklärbarkeit von Modellentscheidungen (Explainability)

EU AI Act Konformitätsdokumentation (für Hochrisikosysteme)

Biases-Dokumentation und Fairness-Metriken

Diese Kann-Kriterien sind besonders relevant, wenn das Tool in einem sensiblen Anwendungsfeld (Personalentscheidungen, Kreditscoring, Gesundheitsdiagnose) eingesetzt werden soll.

Bewertungssystematik: Go / Conditional Go / No Go

Jedes Pflichtkriterium wird mit Erfüllt / Teilweise erfüllt / Nicht erfüllt bewertet. Aus der Gesamtbewertung ergibt sich:

Go: Alle 7 Pflichtkriterien erfüllt — Anbieter kann sofort eingesetzt werden (mit dokumentiertem Assessment)

Conditional Go: Ein oder zwei Kriterien teilweise erfüllt, mit definierten Nachbesserungsfristen; Einsatz unter Auflagen möglich

No Go: Mindestens ein Pflichtkriterium nicht erfüllt, insbesondere wenn kein AVV verfügbar, Datenlokation unklar oder Training-Opt-out fehlt

Das Ergebnis wird im KI-Systemverzeichnis (UE 105) dokumentiert — mit Datum, bewertender Person und nächstem Re-Assessment-Termin.

Vertiefung — Der AVV als aktives Schutzinstrument

Ein Auftragsverarbeitungsvertrag (AVV) ist kein Formaldokument, das man abheftet und vergisst. Er ist ein aktives Schutzinstrument. Die wichtigsten Prüfpunkte bei KI-Anbieter-AVVs im Detail:

Training-Opt-Out — die kritischste KI-spezifische Klausel

Der größte Unterschied zwischen einem Consumer-Tarif und einem Business-Tarif eines KI-Anbieters ist häufig genau diese Klausel: Werden Nutzerdaten (Eingaben und Ausgaben) für das Training zukünftiger Modellversionen verwendet? Consumer-Tarife erlauben dies häufig standardmäßig. Business- und Enterprise-Tarife schließen es in der Regel explizit aus. Die Klausel muss explizit formuliert sein — „Wir respektieren Ihre Privatsphäre” ist keine AVV-konforme Zusage.

Konkrete Muster für eine akzeptable Formulierung: „Customer Data is not used to train, retrain or improve foundational models, unless Customer explicitly opts in.” Alles, was weniger präzise ist, reicht nicht aus.

Auditrecht: Der unterschätzte Prüfpunkt

Der AVV muss Ihrer Organisation das Recht einräumen, die Einhaltung der Datenschutzpflichten zu überprüfen — entweder durch eigene Audits oder durch anerkannte Zertifizierungen (die dann an die Stelle des Audits treten). Wenn ein Anbieter kein Auditrecht anbietet und auch kein aktuelles SOC-2-Zertifikat vorweisen kann, ist er für die Verarbeitung personenbezogener Daten nicht geeignet.

In der Praxis bedeutet das: Der Anbieter stellt das aktuelle Prüfzertifikat auf Anfrage bereit — und zwar innerhalb einer angemessenen Frist (typischerweise 10–14 Werktage). Anbieter, die dieses Recht von vornherein ablehnen, setzen damit ein deutliches Warnsignal.

Löschpflichten und Nachweispflichten

Nach Vertragsende müssen Daten gelöscht werden — und der Anbieter muss das nachweisen können. Viele Anbieter haben keine klaren Angaben zu Löschfristen. Die entscheidende Frage lautet: „Wie lange werden unsere Daten nach Vertragsende in Backups gespeichert — und werden Backups in die Löschpflicht einbezogen?” Ein Löschzertifikat oder eine schriftliche Bestätigung der Löschung ist die Minimalanforderung.

Vertragliche Mindestanforderungen im Überblick

Laufende Due Diligence: Wann wird neu bewertet?

Ein einmalig durchgeführtes Vendor Assessment hat eine begrenzte Gültigkeit. Anbieter können sich verändern:

Änderungen in der Sub-Prozessoren-Liste (z. B. neuer Hosting-Anbieter)

Änderungen in der Datenschutzpolitik (z. B. neue Training-Opt-in-Klauseln)

Sicherheitsvorfälle beim Anbieter

Neue Regulierungsanforderungen, die bisherige Freigaben in Frage stellen

Ablauf von Zertifizierungen (SOC 2 ist jährlich zu erneuern)

Empfohlener Rhythmus: Vollständiges Re-Assessment bei allen wesentlichen Änderungen und routinemäßig einmal jährlich. Bei sicherheitskritischen Änderungen beim Anbieter: sofortiges Ad-hoc-Assessment. Das KI-Systemverzeichnis (UE 105) sollte eine Spalte „Nächste Überprüfung” enthalten — die KI-Beauftragten pflegen diese Termine und initiieren Re-Assessments rechtzeitig.

Sub-Prozessoren-Prüfung in der Praxis

Die Prüfung von Sub-Prozessoren ist in der Praxis oft aufwändiger als erwartet:

Lange Sub-Prozessoren-Listen: Größere KI-Anbieter haben oft 50–100 Sub-Prozessoren. Eine vollständige Einzelprüfung jedes Sub-Prozessors ist für die meisten Organisationen nicht praktikabel. Pragmatische Vorgehensweise: Fokus auf die für die Datensicherheit kritischen Sub-Prozessoren (Hosting/Infrastruktur, Daten-Analytics, Support-Systeme) und Vertrauen auf die Zertifizierungen des Hauptanbieters für den Rest.

Dynamische Listen: Sub-Prozessoren-Listen ändern sich. Gute Anbieter kommunizieren Änderungen proaktiv per E-Mail oder bieten einen RSS-Feed an. Schlechte Anbieter aktualisieren die Liste still. Lösung: Im AVV eine Benachrichtigungspflicht bei Sub-Prozessoren-Änderungen verankern — mit Opt-out-Möglichkeit, wenn eine Änderung nicht akzeptabel ist.

Drittstaaten-Sub-Prozessoren: Wenn der KI-Anbieter selbst in der EU sitzt, aber Sub-Prozessoren in Drittländern hat (z. B. für Support oder Analytics), entstehen Drittlandtransfer-Anforderungen. Zu klären: Auf welcher Rechtsgrundlage erfolgen diese Transfers? Standardvertragsklauseln (SCCs)? Angemessenheitsbeschluss?

Branchen-Anwendungen

IT-Dienstleistung & Beratung

In IT-Dienstleistungsunternehmen werden KI-Werkzeuge oft zunächst für interne Prozesse eingesetzt — Code-Review, Dokumentationsgenerierung, interne Wissenssuche — und erst später für Kundenprojekte. Das Vendor Assessment hat hier eine doppelte Funktion: Es schützt interne Daten und dient als Vorlage für Assessments, die im Kundenauftrag durchgeführt werden.

Vignette: Ein mittelständisches IT-Beratungsunternehmen führt GitHub Copilot für alle Entwickler ein. Das IT-Team führt ein Vendor Assessment durch und stellt fest, dass der Business-Tarif eine explizite „No training on your code”-Klausel enthält. Das Ergebnis: Go für interne Nutzung, mit der Empfehlung, für Kundenprojekte mit vertraulichem Code den Enterprise-Tarif mit getrennten Workspaces zu verwenden. Das dokumentierte Assessment wird Teil der Projektunterlagen für alle Kunden, für die GitHub Copilot eingesetzt wird.

Industrie & Fertigung

In industriellen Fertigungsunternehmen werden KI-Systeme zunehmend für Predictive Maintenance, Qualitätskontrolle und Prozessoptimierung eingesetzt. Dabei fallen oft sensible Produktionsdaten an (Maschinenlogs, Qualitätsparameter, Rezepturen), die als Geschäftsgeheimnis eingestuft sind.

Vignette: Ein Maschinenbauunternehmen evaluiert einen KI-Anbieter für Anomalie-Erkennung in Produktionsprozessen. Das Vendor Assessment offenbart, dass der Anbieter keine explizite Klausel zum Ausschluss des Trainings mit Kundendaten hat. Die IT-Abteilung stuft das als No Go ein — nicht weil DSGVO verletzt wird (Produktionsdaten sind keine personenbezogenen Daten), sondern weil Geschäftsgeheimnisse nicht als Trainingsdaten für Wettbewerber dienen sollen. Das Assessment schützt hier Intellectual Property, nicht Personendaten.

Finanzdienstleistung & Versicherung

Im Finanzsektor unterliegen KI-Systeme zusätzlichen regulatorischen Anforderungen: MaRisk 10/2021, DORA und die Anforderungen der BaFin an Auslagerungen. Ein Vendor Assessment für KI-Anbieter muss diese Anforderungen explizit adressieren.

Vignette: Eine Regionalbank evaluiert einen KI-Assistenten für die Beratungsunterstützung. Das Assessment-Team stellt fest, dass der Anbieter keine DORA-Konformitätserklärung vorlegen kann. Das ist ein Conditional Go: Die Bank setzt eine Nachbesserungsfrist von 90 Tagen und verlangt entweder die Konformitätserklärung oder ein Gutachten eines anerkannten Prüfers. In der Zwischenzeit darf das Tool nur für nicht-regulierte interne Prozesse genutzt werden. Dieses abgestufte Vorgehen zeigt, wie das Conditional-Go-Modell in der Praxis funktioniert.

Öffentliche Verwaltung

Behörden und öffentliche Einrichtungen haben besonders strenge Anforderungen an IT-Anbieter. Für Bundesbehörden gilt das BSI C5-Testat als Mindestanforderung; viele Bundesländer haben eigene Anforderungen. Zusätzlich ist die Vergabe an öffentliche Ausschreibungen gebunden, die eigene Due-Diligence-Anforderungen stellen.

Vignette: Eine Bundesbehörde möchte einen KI-Textassistenten für die Bearbeitung von Bürgeranfragen einsetzen. Das Vendor Assessment ergibt, dass der führende US-Anbieter kein C5-Testat besitzt und Datenlokation außerhalb der EU nicht ausgeschlossen werden kann: klares No Go. Die Behörde wendet sich an einen deutschen Anbieter, der das C5-Testat nachweisen kann, Datenspeicherung in deutschen Rechenzentren garantiert und den EVB-IT-Rahmen erfüllt. Das Assessment wird Teil der Vergabedokumentation.

Warnung — Sicherheitsrisiken

OWASP LLM Top 10 — Relevanz für Vendor Assessment:

LLM06 — Sensitive Information Disclosure: KI-Anbieter ohne explizite Training-Opt-out-Klausel können Eingabedaten (Prompts) potenziell für Modelltraining verwenden. Das bedeutet: Vertrauliche Informationen in Prompts könnten in zukünftige Modellversionen einfließen und von anderen Nutzern indirekt abgerufen werden.

LLM08 — Excessive Agency (Drittanbieter-Risiko): Wenn ein KI-Anbieter Unterauftragnehmer (Sub-Prozessoren) nutzt, die nicht sorgfältig geprüft werden, können Sicherheitslücken beim Sub-Prozessor die gesamte Verarbeitungskette gefährden.

Prompt Injection über Drittanbieter-Content: Manche KI-Systeme rufen externe Inhalte ab (z. B. via Web-Browsing oder RAG). Ein kompromittierter Sub-Prozessor oder ein schädlich präpariertes Dokument in der Wissensbasis kann Prompt-Injection-Angriffe ermöglichen, die die Sicherheitskontrollen des Haupt-KI-Systems umgehen.

Handlungsprinzip: Vendor Assessment ist kein einmaliges Ereignis — es ist ein kontinuierlicher Prozess. Jede Änderung beim Anbieter (neue Sub-Prozessoren, geänderte AGB, Sicherheitsvorfälle) erfordert eine Neubewertung.

Übung 1 — Vendor Assessment für einen bekannten Anbieter

Aufgabe: Sie führen ein vereinfachtes Vendor Assessment für OpenAI (ChatGPT Enterprise / API) durch, basierend auf öffentlich verfügbaren Informationen.

Material: Laptop mit Internetzugang, Vendor-Assessment-Vorlage (Tabelle unten).

Schritt-für-Schritt:

Suchen Sie auf der OpenAI-Website die relevanten Dokumente: Data Processing Agreement (DPA), Sub-Processor List, Security Certifications, Privacy Policy für Enterprise.

Prüfen Sie Kriterium 1 (AVV): Existiert ein DPA? Enthält er die Klausel „No training on customer data”?

Prüfen Sie Kriterium 2 (Sub-Prozessoren): Finden Sie die Sub-Processor List und notieren Sie die drei wichtigsten Sub-Prozessoren.

Prüfen Sie Kriterium 4 (Datenlokation): Bietet OpenAI Enterprise eine EU-Datenlokations-Option?

Prüfen Sie Kriterium 5 (Zertifizierungen): Welche Sicherheitszertifizierungen kann OpenAI nachweisen?

Füllen Sie die Bewertungstabelle aus und geben Sie eine Empfehlung: Go / Conditional Go / No Go — für welche Datenstufenkontexte?

Erwartetes Ergebnis: Eine ausgefüllte Bewertungstabelle und eine differenzierte Empfehlung — z. B. „Go für interne Daten (Stufe 2) mit AVV; Conditional Go für vertrauliche Daten (Stufe 3) nur mit EU-Rechenzentrum-Option”.

Musterlösung Übung 1:

Gesamtempfehlung: Go für Stufe 1 und 2 mit aktivem DPA. Conditional Go für Stufe 3 nur mit explizit vereinbarter EU-Datenlokation und aktueller DSFA. No Go für Stufe 4.

Übung 2 — Vendor Assessment für einen unbekannten Anbieter

Aufgabe: Ein Fachbereich möchte ein neues KI-Tool namens „SummaryPro AI” einführen. Die Landingpage wirbt mit „DSGVO-ready” und „Secure AI for Business”. Entwickeln Sie die Prüffragen für den Anbieter.

Schritt-für-Schritt:

Formulieren Sie für jedes der 7 Pflichtkriterien eine konkrete, direkte Prüffrage an den Anbieter (Frage per E-Mail oder im Erstgespräch).

Notieren Sie für jede Frage: Was ist ein akzeptables Ergebnis? Was ist ein Red Flag?

Überlegen Sie: Welche drei Fragen sind am kritischsten — und warum?

Diskutieren Sie in der Gruppe oder allein: Wie reagieren Sie, wenn der Anbieter auf die AVV-Frage mit „Unsere Privacy Policy deckt das ab” antwortet?

Zeitrahmen: 15 Minuten Einzelarbeit, 10 Minuten Plenum

Musterlösung Übung 2 (Auszug):

Die drei kritischsten Fragen: AVV, Training-Opt-out, Datenlokation — weil diese drei Kriterien direkt über Go oder No Go entscheiden und nicht durch Kann-Kriterien kompensiert werden können.

Cheat-Sheet — Vendor Assessment Kurzreferenz

7 Pflichtkriterien: 1. AVV nach DSGVO Art. 28 (mit Training-Opt-out-Klausel) 2. Sub-Prozessoren-Liste vollständig und mit Änderungsbenachrichtigung 3. Modell-Herkunft und Trainingsdaten-Transparenz (Model Card) 4. Datenlokation — EU garantiert für Stufe 3+ 5. Sicherheitszertifizierungen — SOC 2 Type II oder ISO 27001, < 12 Monate alt 6. Incident Response — 72h-Notification nach DSGVO Art. 33 7. Exit-Strategie — Löschung und Löschzertifikat nach Vertragsende

Entscheidungsmatrix: - Alle 7 erfüllt → Go (dokumentieren) - 1–2 teilweise erfüllt → Conditional Go (Fristen setzen) - Mindestens 1 nicht erfüllt → No Go

Red Flags: - Kein AVV oder AVV ohne Training-Opt-out - Keine Sicherheitszertifizierung (auch nicht in Vorbereitung) - Datenlokation unklar oder außerhalb EU ohne SCCs - Sub-Prozessoren-Änderungen ohne Kommunikationspflicht

Re-Assessment-Trigger: - Jährlich routinemäßig - Bei wesentlichen Änderungen beim Anbieter (Sub-Prozessoren, AGB, Sicherheitsvorfälle) - Bei Ablauf von Zertifizierungen

Rollenzuweisung: - KI-Beauftragte:r: Koordination - Datenschutzbeauftragte:r: Prüfung AVV und Sub-Prozessoren - IT: Prüfung Zertifizierungen und technische Integration - Fachbereich: Use-Case-Beschreibung und Anforderungen

Prompt-Vorlage — Vendor-Assessment-Fragebogen für einen KI-Anbieter erstellen

Prompt für einen KI-Assistenten:

„Wir evaluieren einen neuen KI-Anbieter für den Einsatz in unserem Unternehmen. Der Anbieter bietet eine API-basierte LLM-Lösung an, die in unsere internen Systeme integriert werden soll. Ich benötige einen strukturierten Vendor-Assessment-Fragebogen, den wir dem Anbieter zur Beantwortung vorlegen können.

Erstelle einen Fragebogen mit mindestens 20 Fragen, strukturiert in folgenden Kategorien:

Datenschutz & Rechtskonformität (DSGVO, Auftragsverarbeitung, AVV): Mindestens 5 Fragen

Datenspeicherung & Datennutzung: Werden Eingaben für Modelltraining genutzt? Wie lange werden Logs gespeichert?

Sicherheitsarchitektur: Verschlüsselung, Zugriffskontrolle, Penetrationstests, ISO 27001 / SOC 2 Zertifizierung

KI-spezifische Risiken: Maßnahmen gegen Prompt Injection, Guardrails, Abuse-Detection

Betriebsstabilität & SLA: Uptime, Incident-Response-Zeiten, Benachrichtigung bei Sicherheitsvorfällen

Subprozessoren: Welche Drittanbieter werden genutzt? Wo befinden sich deren Rechenzentren?

Exit-Strategie: Datenportabilität, Löschfristen, Ausstiegsklauseln

Formatiere als nummerierten Fragebogen, der direkt an den Anbieter gesendet werden kann. Ergänze für jede Kategorie einen Hinweis, welche Antwort als ‚ausreichend’ gilt.”

Erwartetes Ergebnis: Ein einsatzbereiter Vendor-Assessment-Fragebogen, der als Template für alle zukünftigen KI-Anbieter-Evaluierungen genutzt werden kann.

Reflexionsfragen

Welches der 7 Pflichtkriterien ist in Ihrer Organisation am schwierigsten zu prüfen — und warum?

Ein attraktives KI-Tool hat keinen AVV, bietet aber an, die Privacy Policy anzupassen. Ist das ausreichend? Begründen Sie Ihre Position.

Wie oft sollte das Vendor Assessment für einen bereits freigegebenen Anbieter wiederholt werden?

Was passiert, wenn ein bisher genehmigter Anbieter seine Sub-Prozessoren-Liste ohne Ankündigung ändert? Welche Schritte leiten Sie ein?

Wie unterscheidet sich das Vendor Assessment für einen KI-Anbieter von einem klassischen IT-Lieferanten-Assessment?

Welche branchenspezifischen Zusatzanforderungen würden Sie für Ihre eigene Branche ergänzen?

Quellen & Weiterlesen

Hinweise für AI Champions — So vermitteln Sie das Thema

Timing: 45 Min — Empfohlene Aufteilung: 15 Min Input (Pflichtkriterien), 20 Min Übung 1 oder 2 (je nach Gruppe), 10 Min Auswertung und Plenumsdiskussion.

Methodische Empfehlung: Diese UE lebt von der praktischen Anwendung. Der Input zu den 7 Pflichtkriterien sollte kompakt gehalten werden (10–12 Minuten). Den Kern der Zeit investieren Sie in eine der beiden Übungen. Übung 1 eignet sich besonders für technikaffine Gruppen, die selbst recherchieren können; Übung 2 eignet sich für gemischte Gruppen, da sie auf Kreativität statt auf Recherchefähigkeit setzt.

Stolpersteine: - Teilnehmende verwechseln Privacy Policy mit AVV: Klar betonen, dass eine Privacy Policy eine einseitige Erklärung ist, kein bilateraler Vertrag nach Art. 28 DSGVO. - „Wir sind doch klein — das gilt nicht für uns”: Größe des Unternehmens ist irrelevant für die AVV-Pflicht; sie gilt für jede Auftragsverarbeitung mit personenbezogenen Daten. - Verwirrung über „Drittlandtransfer”: Kurze Klarstellung: Drittland = Nicht-EU/EWR. Jede Datenübertragung dorthin braucht eine Rechtsgrundlage (z. B. Standardvertragsklauseln nach Art. 46 DSGVO).

Diskussionsfragen für Plenumsdiskussion: 1. Haben Sie in Ihrer Organisation bereits KI-Tools eingesetzt, ohne ein Vendor Assessment durchzuführen? Was würde ein nachträgliches Assessment ergeben? 2. Wer trägt die Verantwortung, wenn ein KI-Anbieter die Sicherheitsversprechen nicht einhält? 3. Wie verhalten Sie sich, wenn der Fachbereichsleiter sagt: „Das Tool brauchen wir sofort — das Assessment kann warten”?

Tafelbild:

VENDOR ASSESSMENT — ENTSCHEIDUNGSBAUM



Anfrage Fachbereich

↓

Frageliste an Anbieter (7 Kriterien)

↓

Bewertung

┌───────┬───────┐

Go Cond.Go No Go

↓ ↓ ↓

Dokument. Fristen Ablehnung

im KI- setzen + Alternative

Verzeichnis suchen

Differenzierung Power-User ↔ Einsteiger: - Einsteiger: Fokus auf die 7 Kriterien und die Entscheidungsmatrix; Übung 2 (Prüffragen formulieren) ist zugänglich ohne tiefes Technik-Vorwissen. - Power-User: Vertiefen mit Sub-Prozessoren-Prüfung und branchenspezifischen Anforderungen (DORA, MaRisk, C5-Testat); diskutieren die Verhandlungsposition gegenüber großen Anbietern.

Materialliste: - Vendor-Assessment-Template (Tabelle mit 7 Kriterien, druckbar oder digital) - Zugang zu openai.com für Übung 1 - Bewertungsskala (Erfüllt / Teilweise / Nicht erfüllt)

Übergang zur nächsten UE: UE 103 behandelt Qualitätssicherung — Evals, Test-Sets und Benchmarks. Der Übergang ist natürlich: Das Vendor Assessment klärt, ob ein Anbieter grundsätzlich zugelassen ist; die Qualitätssicherung stellt sicher, dass das konkrete Modell tatsächlich das leistet, was erwartet wird. Brückenformulierung: „Wir haben jetzt den richtigen Anbieter ausgewählt. Nun stellt sich die Frage: Wie prüfen wir, ob das KI-System in der Praxis wirklich funktioniert?”

Tipp zur Branchenauswahl: Für Gruppen aus dem Finanzsektor: Fokus auf DORA und MaRisk 10/2021; die Erweiterungstabelle aus dem Lerntext verwenden. Für Gruppen aus der Verwaltung: C5-Testat und EVB-IT sind die zentralen Referenzpunkte. Für gemischte Gruppen: Übung 2 mit fiktivem Anbieter bietet Neutralität.

Vertiefung II — Strategische Ebene — Verhandlungsführung mit KI-Anbietern

Wann und wie verhandeln?

Große KI-Anbieter wie OpenAI oder Anthropic bieten Standardverträge, die für die meisten kleinen Unternehmen nicht verhandelbar sind. Aber es gibt Situationen, in denen Verhandlungsmacht entsteht:

Volumen: Ab bestimmten monatlichen Token-Volumina (typischerweise ab 10.000–50.000 USD/Monat) sind Anbieter bereit für individuelle Vertragsanpassungen.

Branche / Regulierung: Wenn das Unternehmen für Kunden in hochregulierten Branchen tätig ist (Finanz, Gesundheit, öffentliche Verwaltung), hat das Argument „Wir benötigen diese Klausel aus regulatorischen Gründen” erhebliches Gewicht.

EU-Alternativen als Verhandlungstool: Wenn glaubhaft auf Mistral oder Aleph Alpha als Alternative verwiesen werden kann, entsteht Verhandlungsdruck — insbesondere bei europäischen Niederlassungen US-amerikanischer Anbieter.

Vendor Assessment als Serviceprodukt

Für IT-Dienstleister und Beratungsunternehmen ist die Fähigkeit, strukturierte Vendor Assessments für KI-Anbieter durchzuführen, ein differenzierendes Serviceangebot:

Beratungsleistung: Kunden, die KI-Systeme einführen möchten, brauchen jemanden, der die Vendor-Assessment-Fragen stellt und die Ergebnisse interpretiert. Diese Leistung kann als Teil von KI-Beratungsprojekten angeboten werden.

Projektsicherheit: Wenn im Rahmen eines Kundenprojekts ein KI-Anbieter empfohlen und ein strukturiertes Assessment dokumentiert wird, ist das ein Schutz vor späteren Haftungsansprüchen.

Compliance-as-a-Service: Für Kunden ohne eigene Datenschutzexpertise kann das Vendor Assessment als Dienstleistung angeboten werden — quartalsweise Re-Assessment inklusive. Das schafft eine Ongoing-Service-Beziehung jenseits des einmaligen Projektgeschäfts.

Häufige Red Flags in der Anbieter-Praxis

Aus der Praxis bekannte Warnsignale, die auf einen nicht DSGVO-konformen Anbieter hindeuten:

„Unsere Lösung ist DSGVO-konform by Design” ohne konkrete Belege: Das ist eine Marketingaussage, kein rechtlicher Nachweis. Fragen Sie immer nach dem AVV und den Zertifizierungen.

Kein dedizierter Datenschutz-Kontakt: Anbieter, die keinen Datenschutzbeauftragten oder keinen dedizierten Compliance-Kontakt benennen können, sind für die Verarbeitung personenbezogener Daten ungeeignet.

AVV nur auf Anfrage und mit sehr langer Lieferzeit: Ein seriöser Anbieter hat den AVV griffbereit. Eine Lieferzeit von mehr als zwei Wochen deutet darauf hin, dass AVVs selten ausgestellt werden — ein schlechtes Zeichen.

Keine öffentlich zugängliche Sub-Prozessoren-Liste: Seriöse Anbieter veröffentlichen diese Liste. Wenn sie nur auf NDA-Basis verfügbar ist, ist das ein Warnsignal — Sub-Prozessoren-Transparenz ist eine DSGVO-Anforderung.

Vertiefung II — Strategische Ebene — Vendor Assessment Lifecycle und Anbieter-Portfolio-Management

Das Vendor Assessment als fortlaufender Prozess

Ein einmaliges Vendor Assessment zu Vertragsbeginn ist ein guter Start — aber kein ausreichendes Sicherheitsnetz. KI-Anbieter entwickeln sich schnell: Modelle werden ausgetauscht, Verarbeitungsbedingungen geändert, neue Datenschutz-Vorfälle bekannt. Ein belastbares Vendor-Management-System umfasst daher:

Initiales Assessment (vor Vertragsabschluss): Vollständige Checkliste, AVV-Prüfung, Sicherheitszertifikate, Subprozessoren-Liste.

Halbjährliches Monitoring: Prüfung der Anbieter-Kommunikation auf wesentliche Änderungen (Release Notes, Datenschutzrichtlinien-Updates), neue Sicherheitszertifikate, Änderungen bei Subprozessoren.

Anlassbezogenes Re-Assessment: Bei wesentlichen Modell-Updates, bei bekannt gewordenen Datenschutz-Vorfällen beim Anbieter, bei regulatorischen Änderungen, bei eigenem Nutzungsausweitung auf neue Datenkategorien.

Jährliches Re-Assessment: Vollständige Wiederholung des initialen Assessments, Vertragsüberprüfung, Verhandlung über neue Vertragskonditionen falls nötig.

Automatisierte Überwachung von Anbieter-Änderungen

Ein praktischer Mechanismus, um Anbieter-Änderungen nicht zu verpassen: Regelmäßige Prüfung spezifischer Anbieter-Seiten. Für die wichtigsten Anbieter empfehlen sich folgende Quellen für Monitoring:

Monatliche manuelle Prüfung dieser Seiten (Änderungsdaten prüfen) oder automatisiertes Web-Monitoring (z. B. VisualPing für kritische Seiten) stellt sicher, dass wesentliche Änderungen nicht unbemerkt bleiben.

Anbieter-Diversifizierung als Resilienzstrategie

Wer für kritische KI-Use-Cases auf einen einzigen Anbieter angewiesen ist, trägt ein erhebliches Risiko: Ausfall des Anbieters, Preiserhöhungen, regulatorische Probleme oder Qualitätsverschlechterungen können den gesamten KI-Betrieb beeinträchtigen.

Eine Anbieter-Diversifizierungsstrategie sieht vor: - Primäranbieter für die wichtigsten Use-Cases (vollständig assessiert und integriert) - Sekundäranbieter für kritische Use-Cases als Fallback (assessiert, aber nicht vollständig integriert) - Explorationsanbieter für experimentelle Use-Cases (im Sandbox-Modus, noch im Assessment)

Diese Dreigliedrung schafft Resilienz, ohne den Assessment-Aufwand zu verdoppeln. Der Sekundäranbieter für kritische Use-Cases muss vollständig assessiert sein — aber die Integration ist minimal, bis er tatsächlich gebraucht wird.

Merksatz

Ein Vendor Assessment ist keine einmalige Aufgabe — es ist ein fortlaufender Prozess. Anbieter-Änderungen, Modell-Updates und regulatorische Entwicklungen erfordern regelmäßige Überprüfung. Die halbjährliche Monitoring-Routine ist die Mindestanforderung.

Vertiefung IV — Subprozessoren und die Komplexität der KI-Lieferkette

Die Subprozessoren-Kette verstehen

Wenn ein KI-Anbieter wie OpenAI Daten verarbeitet, tut er das nicht allein. Die KI-Wertschöpfungskette umfasst zahlreiche Subprozessoren:

Infrastruktur-Anbieter: Microsoft Azure, Google Cloud, Amazon AWS — Hosting der Modell-Infrastruktur

Sicherheitsdienstleister: Monitoring, DDoS-Schutz, Content-Moderation

Zahlungsabwicklung: Stripe oder ähnliche für Abrechnungsprozesse

Kundenservice-Tools: Wenn der KI-Anbieter Support-Tickets verarbeitet, nutzt er dafür möglicherweise eigene Tools mit eigenen Datenprozessen

Jeder dieser Subprozessoren kann im Prinzip Zugang zu den verarbeiteten Daten haben. Als Deployer sollten Sie die Subprozessoren-Liste Ihres KI-Anbieters kennen und prüfen, ob diese Liste mit Ihren Compliance-Anforderungen kompatibel ist.

Die Subprozessoren-Liste wird in der Regel als Anhang zum AVV oder auf einer dedizierten Seite des Anbieters (z. B. openai.com/policies/sub-processors) veröffentlicht. Änderungen müssen dem Auftraggeber typischerweise mit einer Frist von 30–60 Tagen angekündigt werden.

Konsequenz bei avv-Verletzung: Eskalationsoptionen

Was tun, wenn ein Anbieter gegen seinen AVV verstoßen hat — z. B. indem er Daten entgegen seiner Zusagen für Training genutzt hat oder eine Datenpanne hatte, die nicht gemeldet wurde?

Die Eskalationsoptionen in aufsteigender Schwere:

Formelles Schreiben an den Anbieter: Konkrete Benennung des Verstoßes, Forderung nach Klarstellung und Korrektur.

AVV-Kündigung und System-Abschalten: Das Recht, den AVV zu kündigen und das System sofort abzuschalten, ist in jedem wirksamen AVV verankert. Bei einem schwerwiegenden Verstoß kann dies notwendig sein.

Meldung an die zuständige Datenschutzaufsichtsbehörde: Wenn der Anbieter-Verstoß zu einer Datenschutzverletzung geführt hat, besteht möglicherweise eine Meldepflicht. Gleichzeitig kann die Aufsichtsbehörde eingeschaltet werden, um den Anbieter zur Rechenschaft zu ziehen.

Rechtliche Schritte: Schadensersatzansprüche nach DSGVO Art. 82 bei nachgewiesenem Schaden.

Diese Eskalationsmöglichkeiten setzen voraus, dass ein wirksamer, schriftlicher AVV besteht und der Verstoß dokumentiert werden kann. Ohne AVV — z. B. bei Consumer-Tools — sind die Handlungsoptionen erheblich eingeschränkt.

Vertiefung V — Vendor Assessment bei Open-Source-Modellen

Besonderheiten des Assessments bei Open-Source-Modellen

Bei Open-Source-Modellen (Llama, Mistral, Gemma, Phi) gibt es keinen klassischen „Anbieter" im Sinne eines SaaS-Unternehmens. Dennoch besteht ein Assessment-Bedarf — auf einer anderen Ebene:

Modell-Herkunft: Wer hat das Modell trainiert? Auf welchen Daten? Mit welcher Methodik? Open-Source-Modelle von Meta (Llama), Mistral AI oder Google sind gut dokumentiert. Anonyme Modelle aus unbekannten Quellen sind ein erhebliches Risiko.

Lizenzprüfung: Open-Source-Modelle werden unter verschiedenen Lizenzen veröffentlicht. Llama 3 hat eine eigene Meta-Lizenz mit kommerziellen Einschränkungen (> 700 Millionen monatliche Nutzer der Plattform benötigen eine separate Lizenz). Mistral-Modelle werden unter Apache 2.0 lizenziert — deutlich freizügiger. Eine Lizenzprüfung durch die Rechtsabteilung ist bei kommerzieller Nutzung notwendig.

Hosting-Verantwortung: Bei Open-Source-Modellen ist die Organisation selbst Provider ihrer Deployment-Infrastruktur. Das bedeutet: Alle Sicherheitsverantwortlichkeiten, die sonst beim Cloud-Anbieter liegen, liegen nun beim eigenen IT-Team. Das Assessment prüft daher auch die eigene Infrastruktur-Kompetenz.

Modell-Qualitäts-Assessment: Da kein Anbieter für Qualität haftet, muss die eigene Organisation das Modell intensiver evaluieren. Das Golden Test-Set (UE 103) hat bei Open-Source-Modellen noch höhere Bedeutung.

Das Assessment-Framework aus UE 102 gilt auch für Open-Source-Modelle — mit der Anpassung, dass viele der Fragen an die eigene IT-Abteilung gerichtet werden, nicht an einen externen Anbieter.

Vertiefung VI — NIST AI RMF und ISO 42001 als Bewertungsrahmen für KI-Anbieter

Bei der Bewertung von KI-Anbietern können zwei internationale Rahmenwerke als Bewertungsstandard eingesetzt werden: das NIST AI Risk Management Framework (AI RMF 1.0) und die ISO/IEC 42001:2023.

NIST AI RMF — Die vier Kernfunktionen:

Das NIST AI RMF strukturiert das KI-Risikomanagement in vier Kernfunktionen: GOVERN (Steuerung), MAP (Abbildung), MEASURE (Messung) und MANAGE (Verwaltung). Für Vendor Assessments ist besonders die GOVERN-Funktion relevant: Hat der Anbieter interne Richtlinien, Rollen und Verantwortlichkeiten für KI-Risiken definiert? Liegt ein verabschiedetes AI Risk Management Policy-Dokument vor?

Konkrete Fragen für das Vendor Assessment basierend auf NIST AI RMF: - GOVERN: Verfügt der Anbieter über ein formales KI-Governance-Gremium oder einen AI Safety Officer? - MAP: Werden KI-Risiken systematisch dokumentiert — mit Risikoregister und Risikoklassifikation? - MEASURE: Wie werden KI-Modelle vor dem Deployment getestet? Liegt ein Red-Teaming-Protokoll vor? - MANAGE: Wie läuft der Prozess bei einem identifizierten KI-Bias oder Sicherheitsvorfall ab?

ISO/IEC 42001:2023 — Das KI-Management-System:

ISO 42001 ist der erste internationale Standard für KI-Management-Systeme — vergleichbar mit ISO 27001 für Informationssicherheit. Anbieter mit ISO 42001 Zertifizierung haben nachgewiesen, dass sie ein strukturiertes KI-Governance-System betreiben. Im Vendor Assessment bedeutet das: Zertifizierung prüfen, Scope des Zertifikats verstehen (deckt es genau das Produkt ab, das Sie evaluieren?) und das zugehörige Statement of Applicability anfordern.

Praktische Priorisierung: Für die meisten Mittelstandsunternehmen ist eine vollständige ISO 42001 Zertifizierung des Anbieters wünschenswert, aber nicht immer verfügbar — besonders bei Start-ups. Verlangen Sie stattdessen mindestens: SOC 2 Type II Bericht (Sicherheit, Verfügbarkeit), schriftliche Antworten auf die NIST AI RMF Kernfragen und eine auditierbare Verpflichtung zu jährlichen Penetrationstests.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.