Due Diligence bei KI‑Anbietern: Rechtliche, ethische und Sicherheitsprüfungen vor Vertragsabschluss

Die Entscheidung für einen KI‑Anbieter beeinflusst weit mehr als nur Funktionalität: Sie tangiert Datenhoheit, Haftungsfragen, Betriebsaufwand und regulatorische Anforderungen. Due Diligence bei KI‑Anbietern muss deshalb integraler Bestandteil des Beschaffungsprozesses sein. Dieser Beitrag beschreibt konkrete Prüfbereiche, priorisiert Maßnahmen nach Risiko, liefert Vorlagen für Approvvigionamento und zeigt, wie Sie Audit‑ und Betriebsfolgen pragmatisch absichern.

Warum Due Diligence bei KI‑Anbietern anders ist

KI‑Lösungen kombinieren klassische Softwarerisiken (Verfügbarkeit, Schnittstellen, Lizenzierung) mit zusätzlichen Dimensionen: Trainingsdaten, nicht deterministisches Modellverhalten, Nachtrainingszyklen und Bias‑Risiken. Das hat direkte Folgen für Datenschutz (z. B. DSGVO), Haftung und Betrieb. Daher muss die Prüfung technisch, rechtlich und ethisch erfolgen — nicht nur oberflächlich.

Kerndimensionen der KI‑Due‑Diligence

• Datenherkunft & Lizenzen — Grundlage für rechtliche und reputationsbezogene Risiken
• Modell‑Provenienz & Versionierung — Basis für Reproduzierbarkeit und Rollback
• Sicherheitsarchitektur — verhindert Data Poisoning, Model Theft und API‑Missbrauch
• Erklärbarkeit & Testbarkeit — Voraussetzung für Auditierbarkeit und Compliance
• Operative Integration — SLAs, Monitoring, Rollback und TCO

Prüfbereiche und konkrete Fragen — systematisch

Eine saubere Due Diligence gliedert sich in sieben Prüfbereiche. Für jede Kategorie lässt sich klären: welche Artefakte vorgelegt werden, wer verantwortlich ist und welche vertraglichen Mindestanforderungen gelten.

1. Daten und Datenschutz

Trainingsdaten bestimmen Modellentscheidungen und legen rechtliche Risiken fest. Fragen Sie nach Dateninventar, Lizenzen, Löschkonzepten und Zugriffskontrollen.

2. Modellgovernance und Nachvollziehbarkeit

Modellgovernance (Prozesse für Training, Tests, Deployment) und Explainability (Methoden zur Nachvollziehbarkeit) sind auditrelevant. Bestehen Model Cards, Testartefakte und eine klare Versionierungsstrategie?

3. Sicherheit und Entwicklungsprozesse

Technische Kontrollen müssen Data Poisoning, Adversarial Attacks und Model Theft adressieren. Achten Sie auf Secrets‑Management, signierte Artefakte und Pen‑Test‑Berichte inklusive Scope (z. B. Modellinterfaces, Infrastruktur, CI/CD).

4. Betrieb, SLA und Support

SLA‑Definitionen sollten neben Verfügbarkeit auch Accuracy‑Commitments, RTO für Incidents und Reaktionszeiten bei Modellabweichungen enthalten. Fragen Sie nach Rollback‑Mechanismen und Kosten für zusätzliche Inference‑Last.

5. Haftung, Lizenzen und Rechtsfragen

Prüfen Sie Lizenzketten bei Bibliotheken und Datensätzen sowie Export‑ oder Zulassungsrestriktionen. Vermeiden Sie pauschale Haftungsfreistellungen für Datenschutzverstöße und grobe Fahrlässigkeit.

6. Ethik, Fairness und gesellschaftliche Risiken

Bias‑Tests, Stakeholder‑Impact‑Analysen und dokumentierte Maßnahmen bei Überschreitung definierter Schwellenwerte sind essenziell. Lassen Sie sich Metriken und Maßnahmenpläne vorlegen.

7. Kontinuierliches Monitoring und Exit‑Plan

API‑Logs, Audit Trails, Modell‑Exportformate und ein klarer Exit‑Plan (Datenrückgabe, Modellexport, Knowledge Transfer) sind Voraussetzung für langfristige Betriebsstabilität.

Due Diligence bei KI‑Anbietern: Praktische Umsetzungsschritte

Setzen Sie Due Diligence als gestuften Prozess auf: ein kurzes Erstscreening, ein tiefergehender Review bei relevanten Risiken und eine abschließende Vertrags‑/PoC‑Phase. Zuständigkeiten, Zeitfenster und Eskalationspfade gehören in jeden Plan.

Erstprüfung (Screening, 3–7 Tage)

• Prüfung Model Cards, DPA und grundlegender Security‑Statements
• Schnelles Scoring mit Bewertungsmatrix (rot/gelb/grün)
• Entscheidung: weiter vertiefen oder ausschließen

Vertiefter Review (2–6 Wochen)

• Einblick in Dateninventar, Penetrationstests, Versionierungshistorie
• Proof of Concept mit Acceptance Tests und kontrolliertem Datensatz
• Verhandlung von Auditrechten und Exit‑Klauseln

Abnahme & Vertragsabschluss

Erst nach erfolgreichem PoC, verhandelten Garantien und definierten Reviewzyklen in den SLAs freigeben. Legen Sie Transferpunkte für Wissen und Artefakte fest.

Szenarien: konkrete Risiken und ihre betrieblichen Folgen

Praxisnahe Beispiele helfen bei Priorisierung:

• Training auf urheberrechtlich geschützten Texten → rechtliche Rückforderung und Nachbesserungsaufwand
• Bias in Bewerber‑Screening → Reputationsverlust, regulatorische Prüfungen und Personalaufwand
• Model‑Drift in Prognosemodellen → finanzielle Verluste, zusätzliche Re‑Training‑Kosten, kurzfristige Notfallmaßnahmen
• Data Leak durch exponierte API‑Keys → forensischer Aufwand, Meldepflichten und Schadensbegrenzung

Implementierungsaufwand, Zeitplan und Kostenabschätzung

Der Aufwand für Due Diligence sollte als Projekt geplant werden. Typische Rollen und Zeiträume:

• Initiales Screening: 1–2 FTE‑Tage (Beschaffung, Security, DPO)
• Vertiefter Review/PoC: 2–6 Wochen, je nach Komplexität (inkl. Testdatenaufbereitung)
• Vertragsverhandlung: 2–4 Wochen (Legal + Beschaffung)
• Betrieb/Monitoring‑Setup: initial 2–8 Wochen (IT/DevOps + Produktowner)

Budgetieren Sie separate Positionen für unabhängige Penetrationstests, rechtliche Bewertungen und mögliche externe Audits. Für kritische Systeme empfiehlt sich ein Reserve‑Budget für schnelle Remediation.

Governance‑Playbook: Aufgaben nach Rhythmus

Praktische Aufgabenverteilung für den laufenden Betrieb:

• Täglich: Health‑Checks, API‑Error‑Rates, Incident‑Ticketing
• Wöchentlich: Drift‑Reports, Fairness‑Metriken, Trainings‑Queue‑Überblick
• Monatlich: Security‑Review, Versionsstände, SLA‑Compliance‑Report
• Vierteljährlich: Externes Audit oder PenTest, Risiko‑Assessment, Budgetreview

Beispiel: Curl‑Abfrage für Model Card Export

curl -H "Authorization: Bearer $TOKEN" 
  -H "Accept: application/json" 
  "https://api.vendor.example/v1/models/1234/modelcard" 
  -o modelcard_1234.json

Automatisieren Sie solche Exporte in Ihrem Audit‑Runbook, um historische Nachweise in Ihrer Dokumentation zu speichern.

Quick Risk Matrix

Ein pragmatisches Scoring hilft bei Entscheidungen. Beispielgewichtungen (Beispiel): Datenschutz 30 %, Sicherheit 25 %, Governance 15 %, Betrieb 15 %, Ethik 10 %, Haftung 5 %. Definieren Sie Toleranzen (z. B. Score >= 4 = Go with conditions; 3–4 = Mitigations; <3 = Reject) und dokumentieren Sie alle Schwellenwerte.

Technische Prüfungen für Betriebsteams

Ergänzend zu Pentests und Red‑Team‑Berichten sollten Sie konkrete Tests verlangen:

• Membership‑Inference‑Tests (prüfen, ob Trainingsdaten rekonstruierbar sind)
• Differential Privacy‑Checks oder Nachweis entsprechender Mechanismen
• Watermarking/ModelFingerprinting für Rechteeigentum

{
  "test_plan": "membership_inference",
  "dataset": "sample_holdout.csv",
  "expected_result": "no_sensitive_reconstruction",
  "operator": "third_party_lab"
}

Vorbereitung auf Aufsichtsprüfungen

Stellen Sie sicher, dass Sie maschinenlesbare Exporte der wichtigsten Artefakte (Model Cards, Audit Logs, Testreports) vorhalten. Legen Sie Verantwortlichkeiten für regulatorische Anfragen fest und proben Sie eine Audit‑Leseprobe im internen Review.

Approvvigionamento: praktische Checklisten und Vertragsbedingungen

Im Einkauf sind formale Nachweise, Scoring und vertragliche Konditionen zentral. Die wichtigsten Elemente sind RFP‑Mustervorlagen, verpflichtende PoC‑Kriterien, Auditrechte und Exit‑Klauseln mit klaren Fristen.

Audit‑Ready: Dokumentation und Prüfspur

Pflegen Sie eine zentrale Evidence‑Collection mit maschinenlesbaren Exporten: Model Cards, Versioning‑Logs, Pentest‑Berichte, DPA‑Anhänge und Monitoring‑Snapshots. Automatisieren Sie regelmäßige Exporte und Archivierung, so dass ein externer Prüfer reproduzierbare Nachweise erhält.

Abschließende Empfehlungen und Cheatsheet

Behandeln Sie Due Diligence als lebenden Prozess: Vorprüfung, Vertiefungsphase, PoC, Vertragsabsicherung und ein laufendes Monitoring‑ und Governance‑Setup. Drei kompakte Empfehlungen:

• Verlangen Sie Model Cards, vollständiges Dateninventar und Penetrationstests vor Vertragsunterzeichnung.
• Verankern Sie Auditrechte, Exit‑Klauseln und klare SLAs vertraglich.
• Etablieren Sie ein Review‑Board und ein automatisiertes Monitoring für Drift und Fairness.

Fazit: Due Diligence als kontinuierlicher Prozess

Due Diligence bei KI‑Anbietern endet nicht mit der Vertragsunterzeichnung. Angesichts nicht deterministischen Verhaltens, laufender Modellpflege und regulatorischer Entwicklungen ist ein lebender Prozess erforderlich: gründliche Vorprüfung, vertragliche Absicherung, technische Abnahme, und langfristiges Monitoring. So sichern Sie Datenhoheit, reduzieren Haftungsrisiken und erhöhen die Betriebsstabilität.

Vorlage: Kurz‑Checkliste für das Beschaffungsgespräch

• Model Card vorhanden und geprüft?
• Training Data Inventar & Lizenzen vorgelegt?
• Pentest‑ und Red‑Team‑Bericht verfügbar?
• SLA (Verfügbarkeit, Genauigkeit, MTTR) definiert?
• Audit‑ und Exit‑Rechte vertraglich festgeschrieben?
• Monitoring‑Metriken und Reporting‑Intervalle vereinbart?
• Haftung bei Datenschutzverstößen angemessen geregelt?

Nutzen Sie diese Checkliste als Basis für Ihr RFP und automatisieren Sie das Reporting, um bei Audits eine reproduzierbare Prüfspur vorzuweisen.

Handlungsaufforderung: Integrieren Sie die Vorlagen in Ihr Beschaffungs‑ und Auditverfahren und richten Sie ein Review‑Board für KI‑Projekte ein, um Risiken systematisch zu kontrollieren.

Due Diligence bei KI‑Anbietern: Architektur‑ und Betriebsaspekte, die oft fehlen

Nach Vertragsabschluss beginnen die technischen Herausforderungen: wie das Modell sicher in Ihre Infrastruktur integriert, überwacht und im Fehlerfall zurückgerollt wird. Dieser Abschnitt liefert konkrete Architekturhinweise, Betriebsregeln und Prüfobjekte, die Beschaffungsteams häufig übersehen, aber für sichere und wartbare Integrationen entscheidend sind.

Architekturprinzipien: Trennung von Training und Inference

Trennen Sie Trainings‑ und Inference‑Umgebungen physisch oder mindestens netzwerkseitig. Training arbeitet mit großen, oft sensiblen Datensätzen und braucht andere Sicherheitszonen als die Produktions‑Inference. Betriebsseitig bedeutet das:

• Training in einer isolierten, gesicherten Zone mit eingeschränktem Export und Proof‑of‑Access‑Logging.
• Inference in skalierten, containerisierten Services (Kubernetes/nomad) mit klaren Resource‑Limits und API‑Gateways.
• Benutzer‑ und Key‑Management: HSM oder Vault‑backed Schlüssel für Modellsignaturen und API‑Key‑Rotation.

Host‑Level‑Isolierung, Runtime‑Security und Supply‑Chain

Verlangen Sie Nachweise zur Build‑Kette: SBOM für verwendete ML‑Bibliotheken, SCA‑Scans auf bekannte CVEs und signierte Container‑Images. Ergänzend sollte die Runtime abgesichert sein:

• Gesperrte Capabilities, read‑only Filesystem, seccomp, SELinux/AppArmor Profile für Container.
• Signed artefacts und Image‑Attestation (z. B. Cosign, Notary) im CI/CD‑Pipeline‑Prozess.
• Out‑of‑Band‑Management und Zugriffspfade (z. B. Jump‑Hosts) dokumentiert und auditiert.

Observability: welche Metriken, Logs und Traces Sie fordern sollten

Für Auditierbarkeit und schnelles Troubleshooting fordern Sie strukturierte Telemetrie mit klaren Verantwortlichkeiten. Mindestens:

• Inference‑Latency, Fehler‑Rate, Input‑/Output‑Payload‑Size; Drift‑Indikatoren (Feature‑Distribution‑Shift).
• Fairness‑Metriken per Subgruppe (wo relevant) und Confidence‑Histogramme.
• Audit‑Logs: Who/What/When für Model‑Deployments, Weight‑Updates und Datenzugriffe.

Beispiel: Prometheus‑Metriken, die Sie als Mindeststandard verlangen können:

# HELP model_inference_latency_seconds Inference latency
# TYPE model_inference_latency_seconds histogram
model_inference_latency_seconds_bucket{le="0.01",model="credit_risk_v2"} 240
model_inference_latency_seconds_bucket{le="0.1",model="credit_risk_v2"} 1024
model_inference_latency_seconds_sum{model="credit_risk_v2"} 12.34
model_inference_latency_seconds_count{model="credit_risk_v2"} 2048

Logformat für forensische Nachvollziehbarkeit

Standardisieren Sie ein JSON‑Logformat, damit Logs automatisiert korreliert und archiviert werden können. Beispielschema für Inference‑Logs:

{
  "timestamp": "2026-07-01T12:34:56Z",
  "request_id": "uuid-1234",
  "user_id": "internal-service-A",
  "model_id": "credit_risk_v2",
  "model_version": "2026-06-15-rc2",
  "input_hash": "sha256:...",
  "prediction": "low_risk",
  "confidence": 0.87,
  "latency_ms": 12,
  "decision_path": "explainability-reference-id"
}

CI/CD, Canary‑Deployments und Rollback

Fordern Sie eine dokumentierte CI/CD‑Pipeline mit automatisierten Tests (unit, integration, black‑box fairness tests) und Canary‑Rollouts für Modelle. Wichtige Punkte:

• Automatisierte Gate‑Checks: Metrik‑Schwellen (z. B. Accuracy, AUC) müssen im PR‑Workflow bestehen.
• Canary‑Phase mit realem Traffic‑Split (1–5%) und automatischen Rollback‑Triggers bei Regression.
• Versioned Model Registry mit unveränderbaren Artefakten, damit ein schnelles Revert möglich ist.

Operational Readiness & Incident Response

Bestellen Sie im Vertrag konkrete Pflichten zur Incident‑Kommunikation: Escalation‑Matrix, forensische Evidenz‑Preservation (Write‑Once Archive), SLA‑Zeiten für Patch‑Bereitstellung und ein definiertes Playbook für Modell‑Fallback. Operative Schritte gehören ins Runbook:

1. Automatischer Failover auf vorherige Modellversion bei kritischen Metric‑Abweichungen.
2. Schnelles Deaktivieren von Endpoints und forensische Snapshot‑Erstellung.
3. Post‑Mortem mit Root‑Cause‑Analyse, Remediation‑Plan und Lessons‑Learned innerhalb definierten Fristen.

Kosten‑ und Kapazitätsbetrachtung

Klare Kostenmodelle für Inference‑Last, Speicher für Audit‑Logs und Retention sowie Training‑Rechenzeit sind entscheidend. Fordern Sie TCO‑Transparenz: Preis je API‑Call bei verschiedenen SLAs, Storage‑Kosten für Audit‑Retention und erwartete Kosten bei Re‑Training oder Forensic‑Untersuchungen.

Vertragliche Formulierungen — konkrete Minimum‑Anforderungen

Der Anbieter verpflichtet sich, signierte Model‑Artefakte mit vollständiger SBOM zu liefern, CI/CD‑Gate‑Tests nachzuweisen, Canary‑Rollouts zu unterstützen und automatische Rollbacks bei definierten Metric‑Verletzungen (z. B. Accuracy‑Drop > 2%) durchzuführen. Audit‑Logs sind 24 Monate unverändert zu archivieren und auf Anfrage maschinenlesbar bereitzustellen.

Diese zusätzlichen Prüfungen und Betriebsanforderungen minimieren Überraschungen beim Live‑Betrieb und stellen sicher, dass technische, rechtliche und ökonomische Aspekte in einer jeden Beschaffungsentscheidung vollständig abgebildet sind.

Ergänzende Betriebs‑ und Integrationshinweise

Bei der Integration von KI‑Lösungen in Ihre bestehende Infrastruktur entstehen häufig subtile Betriebsrisiken: Datenresidenzanforderungen, SSO/Service‑Account‑Mapping und eDiscovery‑Pflichten werden oft zu spät betrachtet. Definieren Sie früh, welche Regionen für Hosting zulässig sind und wie rechtliche Holds technisch umgesetzt werden (WORM‑Archiv, Retention‑Tags).

Technisch kritisch sind Caching‑Strategien und Konsistenz: gecachte Vorhersagen sparen Kosten, können aber inkonsistente Entscheidungen erzeugen. Planen Sie Cache‑Invalidation‑Policies und TTLs gemeinsam mit SLA‑Grenzen. Ebenso wichtig ist Backpressure‑Handling bei externen Inference‑Services: circuit‑breaker, rate‑limiting und kostenbasierte Throttling‑Regeln.

Operationalisieren Sie außerdem Lieferketten‑Updates: ein definierter Security‑Patch‑Window, automatisierte SBOM‑Prüfungen und ein Entitlement‑Register für API‑Keys verhindern Überraschungen. Solche Integrationsregeln schützen Betrieb, Compliance und Budget in einer Welt, in der KI‑Anbieter laufend aktualisieren.

Für dieses Thema sind auch Ki-Beschaffung und Lieferantenrisiko wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.