EU-Fragebogen zur Sicherheit von KI-Anbietern: 45 Fragen vor der Unterschrift

Ein Sicherheitsfragebogen für KI-Anbieter sollte mehr leisten als Policy-Links zu sammeln. Er muss den Anbieter zwingen, den Datenpfad zu benennen, Nachweise vorzulegen, Vertragskontrollen zu akzeptieren und jede Verantwortung nach dem EU AI Act zuzuordnen. Die 45 Fragen unten machen daraus eine Procurement-Entscheidung.

Nutze diesen Fragebogen, wenn der konkrete Use Case und eine Shortlist stehen. Er ist ein Procurement-Artefakt, kein Tool zur rechtlichen Klassifikation. Unser Leitfaden zu den Kosten des EU AI Act erklärt die Regulierung. Unser Leitfaden zur EU-Datenresidenz zeigt, wohin KI-Daten fließen können. Diese Seite prüft, ob ein bestimmter Anbieter deine operativen und vertraglichen Anforderungen erfüllt.

Nutze die indexierbare Checkliste hier oder nimm sie ins Procurement mit

Die HTML-Seite ist die vollständige und kanonische Version. Das Spreadsheet ergänzt Verantwortliche, Status, Nachweislinks, Scores und Entscheidungsnotizen.

 Mehrsprachiges Spreadsheet herunterladen

So bewertest du eine Enterprise-KI-Anbieterprüfung

Bewerte Antwort, Nachweis und Vertrag gemeinsam. Eine polierte Policy ohne Produktnachweis ist kein Pass. Dieses Modell ist eine Wavect-Procurement-Hilfe, kein regulatorischer Standard. Wenn dein Team eine unabhängige technische Prüfung braucht, macht unser AI-Enablement-Service aus den Nachweisen ein Risikoregister und eine vertragsreife Entscheidung.

• 76 bis 90: Procurement-Kandidat, vorbehaltlich Legal-, Security- und Business-Freigabe.
• 58 bis 75: Nur bedingte Freigabe mit benannter Remediation, Verantwortlichem und Termin.
• 0 bis 57: Stoppen. Der Käufer übernimmt zu viel unbepreistes Risiko.
• Jeder Hard Stop schlägt den Gesamtscore.

Acht Hard Stops vor der Unterschrift

• Kundeninhalte dürfen ohne explizites Opt-in und bindenden Ausschluss für Training oder Evaluation genutzt werden.
• Der Anbieter kann nicht jeden Prozessor, Subprozessor, Modellanbieter und jede Hosting-Region im Datenpfad nennen.
• Sensible Prompts oder Outputs werden unbegrenzt gespeichert, oder die Löschung lässt Logs, Backups, Embeddings oder Fine-Tunes ohne begründete Frist aus.
• Dem Service fehlen Tenant-Isolation, Least-Privilege-Administration oder die für dein Risikoniveau nötigen Identity-Kontrollen.
• Wesentliche Änderungen an Modell, Safety, Region oder Subprozessor können ohne Hinweis, Re-Evaluation oder Rollback erfolgen.
• Die Incident-Klausel hat keine vertragliche Frist, keinen Mindestinhalt oder keine Pflicht zur Beweissicherung.
• Der Anbieter hat keine repräsentative Use-Case-Evaluation oder legt Methoden, Versionen, Grenzen und Ergebnisse nicht offen.
• Die Parteien können sich nicht einigen, wer für den geplanten Einsatz Provider, Deployer oder ein anderer Akteur nach dem EU AI Act ist.

Training und Aufbewahrung von Kundendaten: Fragen 1 bis 4

Ein No-Training-Claim ist zu eng, wenn Feedback, Abuse Monitoring, Human Review oder ein Subprozessor Kundeninhalte dennoch wiederverwenden kann. Frage jede Datenklasse und jede Kopie ab, einschließlich jedes Fine-Tuning-Workflows.

1. Werden Prompts, Dateien, Outputs, Feedback oder Telemetrie zum Training, Fine-Tuning, Distillieren oder Evaluieren eines Modells genutzt, auch durch Subprozessoren?

Anzufordernder Nachweis: Data-Use-Matrix nach Datenklasse, Zweck, Modell und Empfänger sowie aktuelle Produkteinstellung und Policy-Version.

In den Vertrag: Keine Nutzung von Kundeninhalten außerhalb von Bereitstellung und Absicherung des Service ohne separates, ausdrückliches Opt-in des Kunden.

2. Ist die Nutzung zur Modellverbesserung standardmäßig aus, und auf welcher Ebene kann der Käufer das durchsetzen?

Anzufordernder Nachweis: Screenshots oder API-Dokumentation für Organisation, Workspace, Projekt und Endpoint sowie ein Admin-Test.

In den Vertrag: Der Ausschluss gilt für jedes Konto, jede API, jeden Supportkanal und jedes künftige Feature unter dem Vertrag.

3. Welche Standard- und konfigurierbaren Fristen gelten für Prompts, Outputs, Uploads, Embeddings, Logs, Backups und Abuse-Monitoring-Kopien?

Anzufordernder Nachweis: Retention Schedule getrennt nach Live-Systemen, Logs, Caches, Backups, Supporttickets und Safety-Review-Queues.

In den Vertrag: Maximalfristen, erlaubte Zwecke und jede nicht konfigurierbare Ausnahme stehen im AVV oder Order Form.

4. Kann der Anbieter nachweisen, dass die zugesagten Daten- und Retention-Einstellungen für diesen Tenant wirksam sind?

Anzufordernder Nachweis: Tenant-Konfigurationsexport, Kontrolltest, Auditresultat oder signierte Attestation für den gebuchten Service-Tier.

In den Vertrag: Eine falsch konfigurierte oder umgangene Sperre ist ein Security Incident mit Korrektur-, Hinweis- und Löschpflichten.

Subprozessoren: Fragen 5 bis 7

Der EDSA verlangt, dass Verantwortliche die Identität aller Prozessoren und Subprozessoren jederzeit verfügbar haben und deren ausreichende Garantien prüfen. Eine generische Kategorienliste reicht für einen echten Datenpfad nicht.

5. Wer sind alle Prozessoren und Subprozessoren, was tut jeder, wo sitzt er und welche Daten kann er erhalten?

Anzufordernder Nachweis: Aktuelles Register mit Rechtsträger, Adresse, Service, Land, Datenkategorien und Verarbeitungsort.

In den Vertrag: Das Register wird einbezogen und muss für die Services im Scope vollständig bleiben.

6. Wie lange im Voraus wird ein neuer oder ersetzter Subprozessor angekündigt, und kann der Käufer widersprechen oder kündigen?

Anzufordernder Nachweis: Notification Workflow, bisherige Hinweise und ein Muster einer Change Notice.

In den Vertrag: Definierte Vorlaufzeit, begründeter Widerspruchsprozess und kostenfreier Exit, wenn keine angemessene Alternative besteht.

7. Werden gleichwertige Security-, Confidentiality-, Transfer-, Assistance- und Löschpflichten durch die gesamte Kette weitergegeben?

Anzufordernder Nachweis: Relevante Vertragsauszüge, Scope unabhängiger Assurance und Nachweis zur Überwachung kritischer Subprozessoren.

In den Vertrag: Der Anbieter bleibt für Subprozessoren verantwortlich und liefert nötige Compliance-Nachweise.

Standort von Modell und Infrastruktur: Fragen 8 bis 10

Ein Speicherregion-Versprechen sagt nicht, wo Inference, Logging, Supportzugriff oder Disaster Recovery stattfinden. Mappe den vollständigen Request-Pfad mit den Kontrollen aus unserem Leitfaden zur EU-Datenresidenz für KI.

8. In welchen Ländern finden Inference, Speicherung, Logging, Backup, Support und Failover statt?

Anzufordernder Nachweis: Architektur- und Datenflussdiagramm mit benannten Services, Regionen und Cross-Region-Replikationspfaden.

In den Vertrag: Genehmigte Standorte werden je Verarbeitungstätigkeit aufgeführt und nicht nur als EU verfügbar beschrieben.

9. Kann die Region fixiert werden, und unter welchen Support-, Safety- oder Disaster-Recovery-Bedingungen dürfen Daten sie verlassen?

Anzufordernder Nachweis: Konfigurationsdokumentation, getestetes Routing-Verhalten und Ausnahmeprozess.

In den Vertrag: Kein Standortwechsel oder Remote-Zugriff außerhalb genehmigter Länder ohne dokumentierten Rechtsmechanismus und vereinbarte Kontrollen.

10. Wie lautet die genaue Modell-, Gateway-, Cloud- und Supportkette, und welcher Transfermechanismus deckt jedes Nicht-EWR-Segment ab?

Anzufordernder Nachweis: Lieferkette, gegebenenfalls Transfer Impact Assessments, SCC-Module und ergänzende Maßnahmen.

In den Vertrag: Der Anbieter hält Transferdokumentation gültig und meldet Änderungen an Mechanismus oder Ziel.

Logging von Prompts und Outputs: Fragen 11 bis 13

Logging kann Security und Auditierbarkeit stützen und zugleich einen zweiten sensiblen Datensatz erzeugen. Trenne Inhalte von operativen Metadaten und definiere Zugriffe.

11. Was wird auf Application-, Gateway-, Modellanbieter- und Infrastruktur-Ebene genau geloggt?

Anzufordernder Nachweis: Feldschema mit Payloads, Metadaten, Redaction, Hashing und Correlation IDs.

In den Vertrag: Nur vereinbarte Felder und Zwecke dürfen geloggt werden, sensible Felder werden vor Speicherung redigiert.

12. Kann Content Logging für Prompts und Outputs deaktiviert werden, während nötige Security- und Betriebsmetadaten erhalten bleiben?

Anzufordernder Nachweis: Tenant-Level-Kontrolltest und Beispiele der resultierenden Logs.

In den Vertrag: Gewählter Logging-Modus und jede verpflichtende Safety-Ausnahme werden für den Service-Tier fixiert.

13. Wer darf Prompt- und Output-Logs zu welchem Zweck, mit welcher Genehmigung und wie lange lesen?

Anzufordernder Nachweis: Rollenmatrix, Privileged-Access-Workflow, Access Review und Beispiel-Auditrecord.

In den Vertrag: Benannte Zugriffszwecke, Least Privilege, Reviewfrequenz und Retention gelten für Anbieterpersonal und Subprozessoren.

Berechtigungen: Fragen 14 bis 17

Enterprise-KI erbt die Berechtigungen jeder Quelle und jedes Tools, das sie erreichen kann. Ein starkes Modell hinter schwachen Identity-Kontrollen bleibt ein schwaches System, besonders wenn RAG-Berechtigungen SharePoint, Confluence oder Drive umfassen.

14. Unterstützt der Service die nötigen SSO-, MFA-, SCIM- und rollenbasierten Zugriffskontrollen?

Anzufordernder Nachweis: Feature-Demo, Rollenkatalog und Test von Joiner-, Mover-, Leaver- und Emergency-Access-Workflows.

In den Vertrag: Erforderliche Identity-Features sind im gebuchten Tier enthalten und dürfen während der Laufzeit nicht entfallen.

15. Wie wird Tenant-Isolation in Storage, Retrieval, Caches, Fine-Tunes und Supporttools durchgesetzt und getestet?

Anzufordernder Nachweis: Isolation Design, Pentest-Scope, Testergebnisse und Architektur der Encryption Keys.

In den Vertrag: Cross-Tenant-Zugriff ist ein Security Incident; kritische Isolation Controls werden unabhängig getestet.

16. Bleiben Quellberechtigungen in RAG, Connectors, Caches, generierten Links und Exporten erhalten?

Anzufordernder Nachweis: Negativer Permission-Test, der zeigt, dass entzogene oder unberechtigte Inhalte nicht abgerufen, zitiert oder exportiert werden können.

In den Vertrag: Retrieval muss aktuelle Quellberechtigungen durchsetzen, bevor Suchresultate das Modell erreichen.

17. Können API Keys, Agents und Service Accounts eingeschränkt, rotiert, widerrufen und einem Owner zugeordnet werden?

Anzufordernder Nachweis: Key-Management-Kontrollen, Scope-Modell, Rotation Log und Nutzungszuordnung.

In den Vertrag: Keine geteilten, ownerlosen Credentials; Rotations- und Widerrufsfristen entsprechen der Security Policy des Käufers.

Audit Logs: Fragen 18 bis 20

Der Käufer braucht genug Traceability, um ein Ergebnis zu untersuchen, eine Kontrolle zu belegen und anwendbare Retention-Pflichten zu erfüllen, ohne unbegrenzte Überwachung zu schaffen.

18. Welche Authentifizierungs-, Konfigurations-, Datenzugriffs-, Modell-, Policy- und Admin-Ereignisse erscheinen im Audit Trail?

Anzufordernder Nachweis: Beispielexport mit Logins, Rollenänderungen, Connector-Zugriff, Modelländerungen, Safety Settings und Admin-Aktionen.

In den Vertrag: Der vereinbarte Event-Katalog bleibt während der Laufzeit verfügbar und materiell vollständig.

19. Enthalten Events verlässliche Zeit, Actor, Tenant, Aktion, Objekt, Resultat, Vorher-Nachher-Werte und eine Correlation ID?

Anzufordernder Nachweis: Feldbeispiel, das einen Prompt oder eine Aktion vom Request bis zum Outcome rekonstruiert.

In den Vertrag: Zeitsynchronisierung, Integritätsschutz und Privileged-Log-Zugriffskontrollen werden aufrechterhalten.

20. Kann der Käufer Logs in sein SIEM exportieren und für die nötige Dauer speichern?

Anzufordernder Nachweis: API- oder Streaming-Dokumentation, Exporttest, Rate Limits und Retention-Konfiguration. Bei anwendbaren Hochrisikosystemen testen, ob automatisch erzeugte Logs mindestens sechs Monate gehalten werden können.

In den Vertrag: Zugriff, Exportformat, Latenz und Retention entsprechen Incident- und regulatorischen Pflichten des Käufers.

Modelländerungen: Fragen 21 bis 23

Ein stilles Modellupdate kann eine Evaluation entwerten, Output-Verhalten ändern oder das Rechts- und Security-Profil verschieben. Behandle Modelländerungen wie Änderungen an Production Dependencies.

21. Welche Änderungen an Modell, System Prompt, Safety, Region und Subprozessor lösen eine Vorabinformation aus?

Anzufordernder Nachweis: Change Policy, Release Notes und frühere Notices mit Materiality-Kriterien.

In den Vertrag: Für Änderungen mit Einfluss auf Performance, Risiko, Datenfluss oder Compliance gilt eine definierte Vorlaufzeit.

22. Kann der Käufer eine Version pinnen, einen Canary testen, den Rollout freigeben und zurückrollen?

Anzufordernder Nachweis: Versionierungs-API, Deployment Workflow und demonstrierter Rollback mit erhaltenen Logs.

In den Vertrag: Kritische Workflows erhalten ein unterstütztes Validierungsfenster und einen Rollback-Pfad.

23. Welches Kompatibilitäts- und Deprecation-Fenster gilt, und welche Re-Evaluation begleitet eine wesentliche Änderung?

Anzufordernder Nachweis: Support Policy, Migration Guide, Delta-Evaluation und aktualisierte Known Limitations.

In den Vertrag: Keine erzwungene wesentliche Migration vor Ende des Testfensters, außer bei dokumentiertem dringendem Security-Grund.

Incident Response: Fragen 24 bis 27

Klassische Breach-Klauseln können Prompt Injection, unsichere Toolnutzung, Modellkorruption und schädliche automatisierte Outcomes verpassen. Definiere KI-Incidents vor dem Ernstfall.

24. Was zählt als KI-Security- oder Safety-Incident?

Anzufordernder Nachweis: Taxonomie für Datenoffenlegung, Cross-Tenant-Retrieval, Prompt Injection, Tool Abuse, schädlichen Output, Modell- oder Policy-Manipulation, Ausfall und unautorisierte Änderung.

In den Vertrag: Die Definition deckt Vertraulichkeit, Integrität, Verfügbarkeit, Sicherheit und Grundrechtsauswirkung ab, nicht nur bestätigte Datenschutzverletzungen.

25. Wie schnell informiert der Anbieter den Käufer, über welchen Kanal und mit welchen Mindestangaben?

Anzufordernder Nachweis: Response Plan, Eskalationsbaum, Beispielhinweis und Fristen je Severity.

In den Vertrag: Initiale Benachrichtigungsfrist, Kanal, Mindestinhalt und Updatefrequenz sind explizit.

26. Sichert der Anbieter Beweise, unterstützt die Untersuchung und liefert Root-Cause- sowie Corrective-Action-Reports?

Anzufordernder Nachweis: Forensische Retention, Chain-of-Custody-Praxis und redigierter Post-Incident-Report.

In den Vertrag: Beweissicherung, Kooperation, regelmäßige Updates und Abschlussbericht haben definierte Fristen.

27. Wie werden Response-Pläne geübt, und welche relevanten Incidents gab es?

Anzufordernder Nachweis: Letzter Tabletop- oder Simulation-Record, Remediation Tracking und Offenlegung materiell ähnlicher Incidents im vereinbarten Zeitraum.

In den Vertrag: Regelmäßige Übungen und materielle Control-Regressions sind reportable Assurance Events.

Menschliche Prüfung: Fragen 28 bis 30

Ein Human-in-the-loop-Label bedeutet wenig, wenn der Reviewer keine Zeit, Information, Autorität und echte Stop-Kontrolle hat.

28. Können autorisierte Personen ein KI-gestütztes Ergebnis prüfen, überschreiben, stoppen und anfechten?

Anzufordernder Nachweis: Workflow-Demo mit fehlerhaftem Modelloutput, Eskalation und sicherem Shutdown.

In den Vertrag: Der Service umgeht keine verpflichtenden Freigaben und führt vor nötigem Review keine irreversible Aktion aus.

29. Welche Informationen und Schulungen helfen Reviewern, Grenzen zu verstehen und Automation Bias zu vermeiden?

Anzufordernder Nachweis: Instructions for Use, Limitation Notices, Reviewer-Training und UI-Nachweis, dass Unsicherheit nicht als Gewissheit erscheint.

In den Vertrag: Der Anbieter hält Anweisungen und Trainingsmaterial nach wesentlichen Änderungen aktuell.

30. Werden Review-, Override- und Eskalationsentscheidungen dokumentiert, ohne unnötige personenbezogene Daten zu sammeln?

Anzufordernder Nachweis: Decision-Log-Schema, Zugriffsregeln und Privacy Review.

In den Vertrag: Records unterstützen Accountability und Appeal unter Purpose-Limitation- und Retention-Kontrollen.

Evaluationsnachweise: Fragen 31 bis 34

Generische Benchmarks sind kein Abnahmenachweis. Der NIST AI RMF verlangt dokumentierte, wiederholbare Tests unter produktionsähnlichen Bedingungen und regelmäßige Evaluation im Betrieb. Definiere akzeptable Halluzinationsraten und plane den laufenden Aufwand aus unserem Leitfaden zu Kosten und ROI von LLM-Evaluationen ein.

31. Wurde das genaue System für diesen Use Case auf repräsentativen Aufgaben, Sprachen, Nutzern und Fehlerbedingungen evaluiert?

Anzufordernder Nachweis: Testset-Design, Sampling-Begründung, Modell- und Promptversion, Resultate, Error Analysis und Grenzen.

In den Vertrag: Production Acceptance hängt von vereinbarten Use-Case-Tests ab, nicht von einem allgemeinen Model Leaderboard.

32. Welche Metriken und Schwellen decken Qualität, Halluzination, Bias, Security, Robustheit, Latenz und Kosten ab?

Anzufordernder Nachweis: Metrikdefinitionen, Baseline, Umgang mit Unsicherheit, Thresholds und aktuelle Scorecard.

In den Vertrag: Kritische Schwellen, Monitoring-Frequenz und Remediation Trigger sind Abnahmekriterien oder Service Levels.

33. Wer hat evaluiert, und wie unabhängig war die Prüfung vom Delivery-Team?

Anzufordernder Nachweis: Reviewer-Rollen, proportionale externe Assurance, reproduzierbare Methoden und Zugriff auf materielle Limitierungen.

In den Vertrag: Der Käufer darf Methoden prüfen und erhält genug Nachweis, um kritische Tests ohne Offenlegung fremder Trade Secrets zu reproduzieren.

34. Wurden Prompt Injection, Datenexfiltration, unsichere Toolnutzung und modellspezifischer Abuse getestet, und werden Tests nach Änderungen wiederholt?

Anzufordernder Nachweis: Threat Model, Red-Team-Scope, Findings, Remediation und Regressionsergebnisse für die aktuelle Version.

In den Vertrag: Kritische KI-Security-Tests werden nach wesentlichen Änderungen wiederholt; ungelöste High-Risk-Findings blockieren den Rollout.

Datenlöschung: Fragen 35 bis 37

Löschen muss abgeleitete und operative Kopien des KI-Systems abdecken, nicht nur den ursprünglichen Upload.

35. Kann der Anbieter Kundendaten aus Production, Logs, Embeddings, Fine-Tunes, Caches, Supportsystemen und Backups löschen?

Anzufordernder Nachweis: Deletion Map, systemspezifische Fristen, Backup-Ablauf und getesteter Löschprozess.

In den Vertrag: Scope, Abschlussfrist und enge Ausnahmen werden für jeden Datenspeicher aufgeführt.

36. Kann die Löschung einzelne Betroffene, Records, Workspaces oder Tenants treffen und an Subprozessoren propagiert werden?

Anzufordernder Nachweis: Deletion API oder Operations-Workflow, Subprozessor-Propagation und Beispieltrace.

In den Vertrag: Der Anbieter unterstützt relevante Betroffenenanfragen und bestätigt den Downstream-Abschluss.

37. Welcher Löschbeleg wird geliefert, und wie wird die Rückkehr gelöschter Daten nach Backup Restore verhindert?

Anzufordernder Nachweis: Löschzertifikat, Exception Register, Restore Controls und Re-Deletion-Prozess.

In den Vertrag: Die Bestätigung nennt Scope, Datum, verbleibende Legal Holds und Kontrolle für wiederhergestellte Backups.

Exit und Portabilität: Fragen 38 bis 40

Der EU Data Act enthält Wechselpflichten für erfasste Datenverarbeitungsdienste. Auch wenn der genaue Scope rechtlich zu prüfen ist, muss Procurement festlegen, was in welchem Format, wie schnell und zu welchen Kosten exportiert wird. Dokumentiere die Antworten als Teil der Technical Due Diligence des Käufers.

38. Kann der Käufer Inputs, Outputs, Konfiguration, Prompts, Eval-Sets, Logs, Metadaten und andere kontrollierte Assets exportieren?

Anzufordernder Nachweis: Vollständiger Beispielexport und Data Dictionary in gängigen maschinenlesbaren Formaten.

In den Vertrag: Exportierbare Kategorien und begründete Ausnahmen werden vor Unterschrift abschließend aufgeführt.

39. Welche APIs, Tools, Limits, Fristen, Assistance und Gebühren gelten für den Wechsel?

Anzufordernder Nachweis: Exit Guide, API-Dokumentation, Volumentest, Zeitschätzung und aktuelle Gebührenliste.

In den Vertrag: Switching Support, Kontinuität, Security, Notice, Retrieval Period und Gebühren entsprechen geltendem Recht und vereinbarten Service Levels.

40. Kann der Käufer sicher migrieren, einen Ersatz validieren und die Löschung bis zur Exportbestätigung verzögern?

Anzufordernder Nachweis: Exit-Plan-Walkthrough mit Read-only-Zugriff, Parallelbetrieb, Modellsubstitution, Exportvalidierung und finaler Löschung.

In den Vertrag: Definiertes Transition- und Retrieval-Fenster verhindert Lockout oder verfrühte Löschung.

Verantwortlichkeiten nach dem EU AI Act: Fragen 41 bis 45

Der AI Act verteilt Pflichten nach Rolle und Use Case, nicht nach dem Verfasser des MSA. Artikel 25 kann einen Deployer oder Dritten nach Rebranding, wesentlicher Änderung oder geändertem Zweck zum Provider eines Hochrisikosystems machen.

41. Welche Partei ist im geplanten Use Case Provider, Deployer, Importeur, Distributor, GPAI-Provider oder Downstream-Systemprovider?

Anzufordernder Nachweis: Signierte Verantwortungsmatrix für Produkt, Modell, Zweck und EU-Marktweg.

In den Vertrag: Jede Pflicht hat einen accountable Owner und benannte Kooperationspflichten.

42. Welche dokumentierte Analyse deckt verbotene Praktiken, Hochrisiko-Klassifikation, Artikel-50-Transparenz und GPAI-Pflichten ab?

Anzufordernder Nachweis: Aktuelles Classification Memo mit Annahmen, Ausnahmen und Versionsdatum sowie angemessener Legal Review.

In den Vertrag: Der Anbieter meldet Änderungen, die die Analyse verschieben könnten.

43. Liefert der Anbieter die Informationen, die der Käufer für Anweisungen, Logging, Human Oversight, Grenzen, Incidents und Downstream-Compliance braucht?

Anzufordernder Nachweis: Instructions for Use, technische Dokumentation, Modellinformationen, Kontaktwege und Beispiel-Compliance-Pack.

In den Vertrag: Nötige Information, Capabilities, technischer Zugang und Assistance sind Deliverables mit Updatepflicht.

44. Wer betreibt Post-Market Monitoring, Serious-Incident-Reporting, Transparenzkontrollen, AI Literacy und eine eventuell nötige Fundamental Rights Impact Assessment?

Anzufordernder Nachweis: Lifecycle-Verantwortungsmatrix, Prozesse, geschulte Owner und Behördenkontaktliste.

In den Vertrag: Notification- und Kooperationsfristen geben der rechtlich verantwortlichen Partei genug Zeit zum Handeln.

45. Was passiert, wenn Branding, Änderung oder neuer Zweck die Provider-Verantwortung auf den Käufer verschieben?

Anzufordernder Nachweis: Change-Control-Szenario, Substantial-Modification-Assessment und Handover-Paket.

In den Vertrag: Keine verantwortungsverschiebende Änderung ohne Freigabe, aktualisierte Dokumentation, technische Hilfe, Kostenallokation und Exit-Recht.

So werden 45 Antworten zu einer Procurement-Entscheidung

1. Führe zuerst einen 45-Minuten-Scope-Call. Fixiere Use Case, Datenklassen, Nutzer, Tools, Regionen und Impact vor Versand.
2. Lass den Anbieter im Spreadsheet antworten und Nachweise anhängen. Policy-Links allein erreichen höchstens Teilweise.
3. Security, Privacy, Legal, Product und Operational Owner prüfen nur die Abschnitte, die sie freigeben oder ablehnen können.
4. Verwandle jede akzeptierte Lücke in Vertragskontrolle, Remediation, Owner und Termin.
5. Teste vor Production die fünf wichtigsten Kontrollen deines Use Case. Wiederhole nach wesentlichen Modell- oder Datenpfadänderungen.

Warum dieser Fragebogen evidenzbasiert ist

Die Struktur folgt der Verteilung von Value-Chain-Verantwortung, Deployer Oversight, Logging und Incident-Pflichten im EU AI Act; den GDPR-Pflichten zu Prozessorketten und Löschung; den Switching-Regeln des EU Data Act; den Test- und Third-Party-Risk-Praktiken des NIST AI RMF; und ENISAs mehrschichtigem Ansatz für KI-Cybersecurity. Sie verlangt bewusst Systemnachweise, weil Zertifikat oder Policy nicht beweisen, wie dein konfigurierter Tenant arbeitet.

Primärquellen und Research-Basis

1. Verordnung (EU) 2024/1689, EU AI Act. Artikel 12, 14, 15, 25, 26, 50, 72 und 73 zu Value Chain, Logging, Oversight, Robustheit, Transparenz, Monitoring und Incidents.
2. Europäische Kommission, Überblick und Umsetzungszeitplan zum AI Act. Aktueller Kommissionsüberblick zu Provider-, Deployer-, GPAI- und Transparenzpflichten, geprüft am 17. Juli 2026.
3. Verordnung (EU) 2016/679, DSGVO. Artikel 28 und 32 zu Prozessorverträgen, Subprozessoren, Audits, Löschung oder Rückgabe und Security of Processing.
4. EDSA Opinion 22/2024 zu Prozessoren und Subprozessoren. Identität in der Prozessorkette, ausreichende Garantien und Transferdokumentation.
5. EDSA Opinion 28/2024 zu KI-Modellen. Anonymität, berechtigtes Interesse und Folgen unrechtmäßig verarbeiteter personenbezogener Daten bei Entwicklung und Einsatz von KI-Modellen.
6. Verordnung (EU) 2023/2854, Data Act. Artikel 23 bis 30 zu Vertrag, Export, Transition, Retrieval, Löschung und Gebühren beim Wechsel erfasster Datenverarbeitungsdienste.
7. NIST AI Risk Management Framework Core. Third-Party-Risk, Human Oversight, dokumentierte Tests, unabhängige Bewertung und Production Monitoring.
8. ENISA Multilayer Framework for Good Cybersecurity Practices for AI. Cybersecurity Foundations, KI-spezifische und sektorspezifische Kontrollen über den AI Lifecycle.