Vendor‑Risk‑Management für KI‑Services: Vertragsklauseln und technische Prüfanforderungen

Vendor‑Risk‑Management für KI‑Services muss Einkauf, IT, Security und Compliance verbinden. KI‑Funktionen unterscheiden sich von klassischen SaaS‑Diensten durch komplexe Datenflüsse, probabilistische Outputs und mehrstufige Lieferketten (Subprozessoren und Modellprovider). Dieser Beitrag zeigt, welche Vertragsklauseln und technischen Prüfungen vor Beschaffung und im Betrieb wirklich relevant sind, wie Sie Risiken priorisieren und welche Nachweise Auditoren fordern.

Was KI‑Services speziell macht

Kurz gesagt: drei Aspekte treiben die Anforderungen: 1) Datenflüsse (Prompts, Anhänge, Telemetrie) sind heterogen und können verschiedene Speicherorte und Retentionsregeln haben; 2) Outputs sind nicht deterministisch — plausible, aber falsche Antworten („Halluzinationen“) sind möglich; 3) die technische Lieferkette umfasst Hyperscaler, Basismodelle und Dritt‑APIs, also mehrere Subprozessoren. Daraus folgen Konsequenzen für Datenschutz, Haftung, Betrieb und Tests.

Vendor‑Risk‑Management für KI‑Services: Vertragsklauseln priorisieren

Bei Verhandlungen sollten Sie nicht alle Klauseln gleich behandeln. Priorisieren Sie nach drei Kriterien: Sensitivität der Daten, Automatisierungsgrad der Entscheidungen und externe Regulierung (z. B. Gesundheits‑ oder Finanzdaten). Diese Priorisierung steuert Verhandlungsfokus, technische Prüfungen und Governance‑Aufwand.

Use‑Case‑Typisierung: Grundvoraussetzung für Prüfaufwand

Bevor Sie Klauseln verhandeln, typisieren Sie den Einsatz: API‑Integration vs. integriertes Produkt, Datenklassifikation (personenbezogen, vertraulich, reguliert) und Automatisierungsgrad (Assistenz vs. automatisierte Entscheidung). Diese Einordnung bestimmt Tiefe und Priorität Ihrer Prüfungen und Vertragsanforderungen.

Prüfdomänen und Prioritäten

Effektives Vendor‑Risk‑Management gliedert Prüfungen in Domänen, die Einkauf, IT‑Security, Datenschutz und Fachbereich koordinieren:

Domäne: Datenverarbeitung & Datenschutz

Essentiell sind AVV/DPA mit klarer Rollenbeschreibung (Verantwortlicher vs. Auftragsverarbeiter) und eine präzise Zweckbindung: dürfen Eingaben/Outputs zum Training genutzt werden oder nicht? Klären Sie Retention‑Fristen für Prompts, Anhänge und Logs, Datenresidenz und Drittlandtransfers (inkl. Subprozessorenkette). Für DSGVO‑Risiken ist ein Data‑Flow‑Mapping unverzichtbar.

Domäne: Informationssicherheit

Identitäten und Zugriff sind erste Verteidigungslinie: SSO (SAML/OIDC), MFA, RBAC und idealerweise SCIM‑Provisioning. Prüfen Sie Verschlüsselung in Transit (TLS) und at rest sowie Key‑Management‑Optionen (BYOK, wenn gefordert). Audit‑Logs müssen manipulationsarm und exportierbar sein (SIEM‑Anbindung).

Domäne: Modell‑ und Output‑Risiken

Vertraglich und technisch regeln Sie Einsatzgrenzen (z. B. keine medizinische Beratung), Maßnahmen gegen Prompt‑Injection (Input‑Filter, Redaction) und Output‑Validierung. Definieren Sie Abuse‑Monitoring‑Triggers und Alarme bei anormalem Verhalten.

Domäne: Betrieb, SLA und Change

SLA‑Metriken (Availability, latency, Fehlerrate), Incident‑Meldepflichten mit KI‑Spezifika (Datenexfiltration via Output, Cross‑Tenant Leaks, Modellregression) sowie Regeln für Modell‑Updates und Versionierung gehören zwingend in den Vertrag.

Domäne: Exit & Portabilität

Planen Sie Exportformate für Prompts, Konversationen, Anhänge und Admin‑Logs; klären Sie Löschbelege einschließlich Subprozessoren und definieren Sie Übergangsbetrieb bzw. Migrationsunterstützung.

Vertragsklauseln mit hohem Hebel

Standardverträge sind bei KI oft zu allgemein. Die folgenden Klauseln geben echten Schutz oder Nachweisbarkeit:

Zweckbindung und Datenverwendung

Teilen Sie Datenrechte in Servicebetrieb, Abuse‑Prevention und Produktverbesserung/Training. Wenn Training ausgeschlossen ist, brauchen Sie eine nachprüfbare Zusicherung und technische Garanten (z. B. separate Log‑Pfade, kein Persistieren von Prompts).

Subprozessoren & Lieferkette

Bestehen Sie auf einer aktuellen Subprozessorenliste, Ankündigungsfristen bei Änderungen und einem Widerspruchs‑ bzw. Sonderkündigungsrecht, falls kritische Subprozessoren hinzukommen. Fordern Sie Flow‑Down‑Pflichten: Ihre Datenschutzanforderungen müssen auch bei Subprozessoren gelten.

Sicherheits‑TOMs als Anhang

Statt Marketingfloskeln fordern Sie einen prüfbaren Anhang (TOMs): MFA für Admins, minimale Logging‑Events, Verschlüsselungsanforderungen, Supportzugriff nur nach Freigabe, secure SDLC‑Beschreibungen.

Audit‑Rechte und Nachweise

SOC 2 / ISO‑Zertifikate sind nützlich, ersetzen aber nicht spezifische Nachweise. Vereinbaren Sie regelmäßige Berichte, Zugriff auf Findings‑Summaries und einen Prozess für Follow‑up‑Fragen, speziell zu Datenverwendung und Modellupdates.

Incident‑Meldepflichten mit SLAs

Definieren Sie Meldefristen für Sicherheitsvorfälle und KI‑spezifische Ereignisse, den Mindestinhalt der Erstmeldung und den Kommunikationskanal (auch außerhalb der Bürozeiten). Legen Sie eskalative SLAs fest, z. B. Erstreaktion innerhalb X Stunden.

Change‑ und Release‑Management

Vereinbaren Sie Vorankündigungen für Modell‑ und API‑Änderungen, versionierte Endpunkte, Deprecation‑Fristen und ein Rollback‑Verfahren für kritische Regressionen.

Technische Prüfanforderungen (praktisch und priorisiert)

Technische Prüfungen müssen risikobasiert sein. Die folgenden Mindestprüfungen gelten in den meisten Fällen und sind prüfbar:

Pflicht: Data‑Flow‑Mapping

Ein Data Flow Diagram (DFD) ist das wichtigste Artefakt: Quellsysteme, Transformationen (Redaction/Pseudonymisierung), KI‑Endpoints, Speicherschichten, Rückflüsse und Subprozessoren. Dieses Mapping ist Grundlage für Datenschutz‑Folgenabschätzung, Security Review und Incident‑Analyse.

Identity & Access

Testen Sie SSO‑Integration, MFA‑Durchsetzung, RBAC, Service Accounts mit Rotation und Revocation. Vermeiden Sie Shared Keys; setzen Sie kurzlebige Tokens oder scoped API‑Keys ein.

Logging & Monitoring

Prüfen Sie, welche Events geloggt werden, ob Logs exportierbar sind (API, S3, Webhook), und wie lange sie aufbewahrt werden. Fehlt Anbieter‑seitig Logging, planen Sie Proxy‑ oder Gateway‑Logging auf Ihrer Seite ein – das ist ein Kostenfaktor.

Prompt‑ und Kontext‑Härtung

Implementieren Sie Kontextminimierung, Redaction/Maskierung sensibler Felder, Secrets‑Scanning vor Versand und Output‑Validierung. Legen Sie Regeln fest, welche Datenklassen niemals unredigiert in Prompts dürfen.

Resilienz‑Tests

Simulieren Sie Timeouts, Rate‑Limit‑Szenarien und Ausfälle: Wie reagiert Ihr System? Haben Sie Fallbacks (alternative Provider, human fallback) und definierte Degradationsmodi?

Beispiel Baseline‑Policy (kopierbar)

ai_vendor_baseline:
  data_usage:
    training_opt_in_required: true
    prompt_retention_days_max: 30
    output_retention_days_max: 30
  privacy:
    dpa_required_if_personal_data: true
    subprocessors_list_required: true
    data_residency_required_regions:
      - EU
  security:
    sso_required: true
    mfa_enforced: true
    role_based_access_control_required: true
    encryption_in_transit_required: true
    encryption_at_rest_required: true
    customer_audit_logs_exportable: true
  operations:
    incident_notification_hours_max: 72
    change_notice_days_min: 14
    versioned_api_or_deprecation_policy_required: true
  exit:
    data_export_supported: true
    deletion_confirmation_required: true

Konkrete Klauselvorlagen (verhandelbare Muster)

Die folgenden Textbausteine sind als Ausgangspunkt für Legal‑Verhandlungen gedacht. Sie müssen organisatorisch angepasst und geprüft werden.

Beispiel: Trainings‑Opt‑Out

Anbieter verpflichtet sich, die Kundendaten (Prompts, Anhänge, Metadaten) nicht für Produkt‑ oder Modelltraining zu verwenden, es sei denn, es liegt eine ausdrückliche, dokumentierte Opt‑in‑Erklärung des Kunden vor. Der Anbieter stellt technische Nachweise, wie getrennte Log‑Pfade und Nicht‑Persistierung von Prompts, bereit und unterzieht diese Nachweise halbjährlichen Prüfungen durch einen unabhängigen Prüfer.

Beispiel: Subprozessor‑Änderung

Der Anbieter informiert den Kunden mindestens 30 Tage vor der Beauftragung eines neuen Subprozessors schriftlich. Erkennt der Kunde den Subprozessor als unzumutbar (z. B. Datenresidenz, Zertifizierungen), so hat der Kunde ein Widerspruchsrecht mit Option auf Vertrags‑Sonderkündigung oder technische Isolationsmaßnahmen.

Beispiel: Incident‑Meldung

Der Anbieter meldet sicherheitsrelevante Vorfälle, die Kundendaten betreffen, unverzüglich und spätestens innerhalb von 48 Stunden nach Erkenntnis an den Kunden. Die Meldung enthält: Betroffene Datentypen, geschätzter Umfang, vorläufige Ursache, kurzfristige Gegenmaßnahmen und geplante Schritte zur forensischen Analyse sowie ein voraussichtliches Zeitfenster für ein erstes Remediation‑Update.

Technische Verifikationsschritte: Checkliste mit Prüfmethoden

Für die technische Abnahme und wiederkehrende Prüfungen empfehlen sich klar definierte Schritte, die auch Auditoren nachvollziehen können.

1) Identitätsintegration testen

Prüfen Sie SSO‑Login, Role‑Mapping und Provisioning. Ein einfacher Testablauf:

1. Erstellen eines Testkontos via SCIM/Provisioning.
2. Zuweisung einer Rolle mit minimalen Rechten.
3. Verifikation, dass Admin‑Funktionen nicht verfügbar sind.
4. Deprovisioning und Validierung, dass Tokens invalidiert werden.

2) Log‑Export prüfen

Lassen Sie sich einen Export‑Job einrichten und prüfen Sie, ob die Logs vollständig, zeitnah und in einem maschinenlesbaren Format (z. B. JSON, Common Event Format) ankommen. Testen Sie zudem die Integrität mit Prüfsummen oder Zeitstempeln.

3) Redaction & Secrets‑Scan

Führen Sie kontrollierte Tests durch, in denen definierte sensiblen Felder (z. B. Kundennummer, E‑Mail, Gesundheitsinfo) an den Service gesendet werden. Validieren Sie, ob diese Felder vom Anbieter oder Ihrer Redaction‑Pipeline entfernt bzw. pseudonymisiert werden.

4) Resilienz‑Simulation (Beispiel: API‑Timeout)

Simulieren Sie hohe Latenzen und prüfen Sie Zeitüberschreitungs‑Verhalten und Fallback‑Logik. Ein einfaches Beispiel, um Endpoint‑Timeouts zu provozieren, ist ein curl‑Aufruf mit kurzer Timeout‑Einstellung:

curl -m 2 -X POST https://api.ki-anbieter.example/v1/query 
  -H "Authorization: Bearer $API_KEY" 
  -d '{"input":"Test"}'

Erwartung: Fehlerbehandlung im Client ist dokumentiert, Retries sind begrenzt, und es existiert ein human fallback.

Audit‑Evidenz: Was Prüfer sehen wollen

Auditoren suchen Kontrollnachweise, nicht Modell‑Details. Wichtige Artefakte sind: Risikoassessment des Use‑Cases, Vertragspaket (AVV, TOMs, SLA, Change/Incident), Data‑Flow‑Mapping, technische Nachweise (SSO aktiv, Logging exportierbar, Key‑Rotation‑Prozess), Betriebsdokumente (Runbooks, Incident‑Playbooks) und Change‑Freigaben.

Governance: Rollen, Risk Acceptance und Lifecycle

Nutzen Sie RACI zur Verantwortungsverteilung: IT‑Security (Responsible für technische Abnahmen), Datenschutz (Responsible/Consulted für AVV und Data‑Flow), Einkauf/Legal (Responsible für Vertragsklauseln), Fachbereich (Accountable für Use‑Case und operative Entscheidungen). Definieren Sie einen formellen Risk‑Acceptance‑Punkt für Abweichungen.

Kostenrealität und Budgetplanung

Berücksichtigen Sie nicht nur Lizenzkosten, sondern Integrationsaufwand (SSO/SCIM), Logging‑Storage, DLP/Redaction‑Pipelines, Qualitätssicherung und Support für Exporte/Migration. Rechen Sie initial mit Mehraufwand für die technische Abnahme (meist 2–6 Wochen) und jährlichen Re‑Assessments. Legen Sie die Kosten transparent im Business Case dar, um Überraschungen zu vermeiden.

Pragmatischer Ablauf: Anfrage bis Re‑Assessment

1. Intake: Use‑Case, Datenklassen, Kritikalität.
2. Vorprüfung: Baseline‑Check (SSO, Datenverwendung, Subprozessoren, Region, Logs).
3. Vertragspaket: AVV/DPA, TOMs, SLA, Incident/Change, Exit.
4. Technische Abnahme: Identity, Logging, Redaction, Resilienztests.
5. Go‑Live mit Guardrails: Monitoring, Runbooks, Schulung.
6. Re‑Assessment: jährlich oder bei Triggern (Modellwechsel, Subprozessorenwechsel, Incident).

Trigger‑basiertes Re‑Assessment ist zentral: Modellupdates und Subprozessorenänderungen können Risiken schnell verändern.

Minimum‑Checkliste vor Vertragsabschluss

• Ist Datentraining ohne Opt‑in ausgeschlossen oder vertraglich geregelt?
• Existiert ein AVV/DPA bei personenbezogenen Daten?
• Liegt eine aktuelle Subprozessorenliste vor?
• Unterstützt der Service SSO + MFA und RBAC?
• Sind Audit‑Logs verfügbar und exportierbar?
• Sind Retention‑Zeiten steuerbar?
• Gibt es definierte Incident‑Meldepflichten und Change‑Regeln?
• Ist ein praktischer Exit‑Plan vorhanden (Export, Löschung, Bestätigung)?

Fazit

Vendor‑Risk‑Management für KI‑Services ist pragmatisch umsetzbar, wenn Vertrag und Technik zusammen gedacht werden. Setzen Sie auf Use‑Case‑Typisierung, eine verbindliche Baseline‑Policy, prüfbare TOMs, Data‑Flow‑Mapping und einen klaren Governance‑Prozess mit Risk‑Acceptance. So werden KI‑Services beschaffbar, betreibbar und auditfähig, ohne die Organisation mit unnötigem Overhead zu blockieren.

Weiterführende Hinweise

Die im Artikel genannten Artefakte und Klauseln sind als Vorlage gedacht. Insbesondere bei stark regulierten Daten oder kritischen Automatisierungen empfiehlt sich eine gemeinsame technische Prüfung mit dem Anbieter und eine juristische Review der Klauseln. Legen Sie Verantwortlichkeiten fest und dokumentieren Sie Annahmen, damit Auditoren später nachvollziehen können, warum bestimmte Kompensationsmaßnahmen bestanden.

Betrieb & Architektur: praxisnahe Hinweise für IT‑Teams

Technische Vertragsklauseln sind nötig, aber im Live‑Betrieb entscheidet die Architektur. Legen Sie den KI‑Provider hinter ein kontrolliertes Gateway/Proxy (API‑Gateway, Reverse‑Proxy oder Sidecar), das Redaction, Secrets‑Scanning, Rate‑Limiting und Audit‑Logging zentral durchsetzt. So bleibt Ihre individuelle Unternehmenssoftware unabhängig vom Provider‑Feature‑Set und Sie gewinnen eine Prüfschicht für Compliance und Forensics.

Wichtige Architekturregeln in der Umsetzung:

• Edge‑Redaction: sensible Felder schon vor dem Versand entfernen oder pseudonymisieren; diese Logik außerhalb des Anbieters betreiben.
• Key‑Custody: BYOK‑Option prüfen. Liegt der Schlüssel beim Anbieter, verhandeln Sie Nachweise zur Key‑Rotation und Key‑Zugriffsprotokollen; ideal ist ein KMS/Vault, auf das Sie Kontrolle haben.
• Network‑Härtung: Egress‑Filter, explizite Destinationen, TLS‑Inspektion nur dort, wo rechtlich und technisch erlaubt, sowie Quota‑Enforcement zur Kostenbegrenzung.
• Deployment‑Safety: Canary‑Rollouts für Modell‑Updates, A/B‑Tests mit synthetischen Prüfdatensätzen und automatisierte Validierung auf Regressionen (Antwortqualität, Halluzinationsrate).
• Observability: Metriken für Token‑Nutzung, Fehlerraten, Antwortlatenz, und ein Halluzination‑Signal (z. B. Plausibilitätsfehler pro 1.000 Anfragen) als Alarmbedingung.

Praktisch bedeutet das: integrieren Sie diese Kontrollen in CI/CD‑Pipelines und in Ihr Incident‑Runbook. Messen Sie neben Verfügbarkeit auch Kosten‑Anomalien und inhaltliche Qualitätskennzahlen. Mit dieser Kombination aus Architektur, Schlüsselhoheit und automatisierten Prüfungen reduzieren Sie Betriebsrisiken, halten Audit‑Evidenz sauber und machen KI‑Integrationen für Compliance‑Teams prüfbar und kontrollierbar.

Für dieses Thema sind auch Ki‑Services Vertrag und Auftragsverarbeitung Ki wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.