AI-Vendor- und Model-Assurance

AI-Vendor und Modelle brauchen Zusagen jenseits klassischer SaaS-DPAs: Training, Logging, Evaluierung, Output-Risiken und Deployer-Pflichten. Ein Ticket-Tool-Einkauf mit „wir trainieren nicht, außer…“ ohne Nachweis und ohne Stopp-Kriterium ist kein Assurance-Stand.

Dieser Teil spezifiziert AI-Assurance in der Vendor-Kette — auf Baseline und Ketten-Evidenz aus Teil 2 und 3.

Anschluss an Compliance Essentials, Audit-Evidence Operating und Partner-Landschaft.

Vorher: Subprocessor-Ketten-Evidenz. Weiter: Exit, Evidenz-Transfer und Kontinuität.

zusagen inklusive Evidence-Zugang, eine Version-Change-Notice, benannte Deployer-Rollen und Stopp-Kriterien bei Scope-Drift oder fehlender Evidence.

In einem Satz: Kein AI-Vendor im Produktivbetrieb ohne Training-Verbot, Eval-Zugang, Version-Notice und Stopp-Kriterien.

Entscheidung

Wenn Modelle oder GenAI im Scope sind:

1. Training-/Retention-Verbote und Nachweis;
2. Logging- und Evaluierungszusagen inkl. Zugang zu Evidence;
3. Model-/Version-Change-Notice;
4. Deployer-Pflichten und interne Rollen (Data Owner, Steward, Custodian);
5. Stopp-Kriterien bei Scope-Drift oder fehlender Evidence.

Kein Produktivchat ohne Eval-Pack oder befristete Ausnahme mit Evidence-Plan.

AI-Vendor-Workflow

1. Use Case und Risiko

Der Data Owner benennt Use Case und Risikoklasse (Hochrisiko vs. Assistenz); das Tier folgt dem Use Case, nicht dem Vendor-Logo. Artefakt ist ein einseitiger Use-Case-Record mit Datenkategorien, Output-Risiko und Stopp-Kriterien. Steward übersetzt das in Pflichtmodule; Custodian prüft, ob Routing und Hosting dazu passen. Wird der Use Case nicht festgehalten, driftet der Chat von „Zusammenfassen“ zu „Entscheiden“ — ohne neue Freigabe.

2. Contract gates

Steward fordert die AI-Zusatzfragen: Training, Retention, Subprocessor, Regionen, Eval-Rechte, Logging-Zugang. Vendor-Claims sind Hypothesen, bis Vertrag und Evidence sie tragen. Fehlen die Gates, gilt die klassische DPA — und Prompt-Speicher, Fein-Tuning und Drittmodelle bleiben unsichtbar.

3. Operate

Custodian führt Version-Tracking, Prompt-/Output-Controls und Routing-Nachweis im laufenden Stack. Steward überwacht Change-Notices und Incidents gegen die Stopp-Kriterien. Ohne Betriebskontrolle ist die Unterschrift der letzte Assurance-Moment — genau das Gegenteil von Teil 2.

4. Evidence

Eval-Ergebnisse, Incidents und Change-Notices liegen in der Model-Akte mit Version, Datum und Reviewer. Steward führt die Akte; Custodian legt Logs und Routing bei. Fehlt das Pack, ist Produktivbetrieb eine Assurance-Lücke: stoppen oder befristet ausnehmen, nicht „OK bei SMB“.

5. Exit

Model-Weights, Caches, Prompt-Logs und Fein-Tuning-Kopien gehören in den Exit-Plan von Teil 5 — nicht erst in die Kündigung. Data Owner setzt die Lösch- und Transferpflicht; Custodian prüft, dass Caches erreichbar und löschbar sind. Wird Exit hier vergessen, bleibt Lernmaterial beim Vendor, nachdem der Vertrag endet.

Handoffs

Anti-Patterns

• GenAI wie Ticket-Tool einkaufen
• Training „vielleicht“ erlauben ohne verantwortliche Person
• Keine Version-Notice
• Eval nur intern, Dienstleister-Claims ungeprüft
• Ausstieg ohne Cache-/Log-Löschung

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Compliance Essentials
• Lernpfad — Compliance Essentials

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Einen AI-Vendor und Use Case tiern.
2. Training-/Retention-Klausel und Evidence-Ort prüfen.
3. Version-Change-Notice und Owner setzen.
4. Ein Eval-/Incident-Minimalpack anlegen.