KI-Anbieter Due-Diligence-Checkliste: 5 Fragen, die jedes EU-Einkaufsteam braucht (2026)

Einen Auftragsverarbeitungsvertrag (AVV) mit einem KI-Anbieter zu unterzeichnen bedeutet längst nicht mehr, dass Sie Ihre Due Diligence erledigt haben. Unter dem kombinierten Gewicht von DSGVO und EU AI Act tragen EU-Einkaufsteams, Datenschutzbeauftragte und IT-Käufer jetzt eine eigene Reihe von Pflichten, für die ein Standard-AVV nie ausgelegt war. Machen Sie es falsch, drohen Bußgelder von bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes, dazu die operative Störung einer Compliance-Krise mitten in der Vertragslaufzeit. Die durchschnittlichen Kosten von Non-Compliance liegen laut dem Ponemon-Benchmark 2025 inzwischen bei 5,2 Millionen US-Dollar, und Gartner berichtete 2026, dass 34 % der KI-Projekte gezielt wegen Compliance-Bedenken pausiert wurden. Fünf Fragen, zum richtigen Zeitpunkt im Beschaffungsprozess gestellt, beseitigen den größten Teil dieses Risikos.

Warum die Standard-Anbieterprüfung in der EU nicht mehr ausreicht

Die klassische Software-Beschaffung stützte sich auf eine kurze Checkliste: Hat der Anbieter einen AVV, werden die Daten in der EU gespeichert, besitzt er ISO 27001 oder SOC 2? Diese Fragen sind weiterhin wichtig, doch sie waren für Auftragsverarbeiter gedacht, die Informationen bewegen und speichern, nicht für Systeme, die aktiv über diese Informationen schließen, ihr eigenes Verhalten anpassen und Ihre Geschäftsdaten möglicherweise in ihre Trainingspipelines zurückspeisen.

Der EU AI Act, der ab 2025 und 2026 schrittweise für KI-Systeme mit allgemeinem Verwendungszweck und Hochrisiko-KI gilt, hat eine parallele Compliance-Ebene eingeführt, die sich mit der DSGVO überschneidet, sie aber nicht ersetzt. Während die DSGVO regelt, was mit personenbezogenen Daten geschieht, regelt der AI Act, wie automatisierte Systeme, die Menschen betreffen, gestaltet, dokumentiert, überwacht und geprüft werden müssen. Dieselbe Anbieterbeziehung löst nun gleichzeitig Pflichten aus zwei getrennten Regulierungsrahmen aus, und die meisten Anbieterverträge wurden geschrieben, bevor eine der beiden Pflichten klar war.

Die praktische Folge ist, dass Einkaufsteams, die sich auf ein AVV-Häkchen verlassen, unwissentlich Risiko auf sich selbst übertragen. Nach Art. 28 DSGVO reicht ein AVV allein für die Due Diligence eines KI-Anbieters nicht aus. Käufer müssen außerdem die DSGVO-Rollenverteilung prüfen (ist der Anbieter Auftragsverarbeiter, Verantwortlicher oder agiert er in verschiedenen Teilen des Produkts als beides?), Speicher- und Zugriffsorte getrennt bestätigen, sicherstellen, dass Standardvertragsklauseln oder ein anderer Mechanismus nach Kapitel V jede Datenübermittlung außerhalb des EWR abdeckt, und eine vollständige Subprozessorenliste mit einem definierten Aktualisierungsmechanismus einholen. Nichts davon ist automatisch. Wenn Ihr AVV diese Punkte nicht ausdrücklich regelt, können Sie nicht davon ausgehen, dass sie abgedeckt sind.

Organisationen benötigen typischerweise 9 bis 14 Monate, um vollständige LLM-Compliance zu erreichen. Erst bei der Vertragsverlängerung mit der Due Diligence zu beginnen, ist zu spät. Die fünf Fragen unten sind so gedacht, dass sie in der Phase der Anbieterbewertung gestellt werden, vor jeder kommerziellen Verpflichtung, damit die Antworten prägen, was in den Vertrag kommt, statt was bei einer Prüfung entdeckt wird.

Frage 1: Sind Sie „Anbieter" oder „Betreiber" nach dem EU AI Act, und was bedeutet das für meine Pflichten?

Der EU AI Act zieht eine scharfe Linie zwischen zwei Rollen, und die Compliance-Pflichten, die Ihrer Organisation zufallen, hängen vollständig davon ab, auf welcher Seite dieser Linie Ihr Anbieter steht. Ein Anbieter (Provider) ist die Einheit, die ein KI-System entwickelt, in Verkehr bringt oder in Betrieb nimmt. Ein Betreiber (Deployer) ist jede natürliche oder juristische Person, die ein KI-System im beruflichen Kontext einsetzt. In einer typischen SaaS-KI-Beziehung ist der Anbieter der Provider, und Sie, die kaufende Organisation, sind der Betreiber.

Das ist wichtig, weil der AI Act jeder Rolle unterschiedliche Pflichten zuweist. Anbieter von Hochrisiko-KI-Systemen (Systeme, die in die in Anhang III des Gesetzes aufgeführten Kategorien fallen, darunter KI in Beschäftigungsentscheidungen, Kreditwürdigkeitsprüfung, Bildung und kritischer Infrastruktur) müssen technische Dokumentation erstellen, Konformitätsbewertungen durchführen, eine automatische Protokollierung des Systembetriebs implementieren und betreiberseitige Dokumentation liefern, die die Zweckbestimmung des Systems, seine Grenzen und Anweisungen zur menschlichen Aufsicht enthält. Betreiber wiederum müssen das System ausschließlich innerhalb seiner Zweckbestimmung betreiben, die vom Anbieter erzeugten Protokolle aufbewahren, die menschliche Aufsicht sicherstellen und ihre Aufsichtsbehörde über schwerwiegende Vorfälle informieren.

Das Problem ist, dass viele KI-Anbieterverträge diese Zuordnung nicht festlegen. Schweigt der Vertrag darüber, ob der Anbieter als Provider oder Betreiber handelt, und wird das Tool später als Hochrisiko eingestuft, können beide Parteien in der Haftung sein, und Regulierungsbehörden werden Mehrdeutigkeit nicht wohlwollend behandeln. Nach Art. 11 und 12 des EU AI Act müssen Anbieter sicherstellen, dass Hochrisiko-KI-Systeme automatisch Protokolle erzeugen, die ausreichen, um den Systembetrieb zu Prüfzwecken nachzuvollziehen; Betreiber müssen diese Aufzeichnungen aufbewahren. Wenn der Vertrag Ihres Anbieters nicht bestätigt, dass diese Protokolle existieren, exportierbar sind und angemessen aufbewahrt werden, können Sie Ihre Betreiberpflichten nicht erfüllen, egal was Ihre internen Richtlinien vorsehen.

Frage 2: Wo genau werden Daten gespeichert UND verarbeitet? (Speicherort ist nicht gleich Verarbeitungsort)

Die meisten Einkaufsteams fragen, wo Daten gespeichert werden. Fast keines fragt, wo Daten verarbeitet werden. Das sind unterschiedliche Orte, und die Lücke zwischen ihnen ist heute der Ort, an dem das häufigste DSGVO-Risiko in der KI-Beschaffung liegt.

Ein Anbieter kann wahrheitsgemäß sagen „Ihre Daten werden in Frankfurt gespeichert", während er diese Daten (Inferenz, Embedding, Retrieval und Modelloperationen) auf Infrastruktur in den Vereinigten Staaten oder in einem Land ohne Angemessenheitsbeschluss verarbeitet. In der EU gespeichert bedeutet, dass die ruhenden Daten auf einem europäischen Server liegen. In der EU verarbeitet bedeutet, dass die Berechnung über Ihre Daten innerhalb des EWR erfolgt. Für die DSGVO-Konformität ist beides relevant.

Die Unterscheidung wird angesichts des US CLOUD Act besonders brisant. Dieses Gesetz erlaubt US-Behörden, US-Unternehmen und deren Tochtergesellschaften zu zwingen, weltweit gespeicherte Daten herauszugeben, unabhängig davon, auf welchem Server sie liegen. Ein Anbieter mit Sitz in den USA oder mit US-domiziliertem Mutterkonzern kann Ihre Daten nicht vollständig vor dem Zugriff der US-Regierung abschirmen, selbst wenn die Daten physisch in einem EU-Rechenzentrum gespeichert sind. Die einzige technisch-rechtliche Architektur, die dieses Risiko beseitigt, ist ein Anbieter, der vollständig EU-eigen ist und keinen US-Mutterkonzern hat, was die Grundlage für eine CLOUD-Act-Herausgabeanordnung entfernt und zugleich die Notwendigkeit eines Transfer-Impact-Assessments beseitigt.

Für Anbieter mit US-Verbindungen oder mit Verarbeitung außerhalb des EWR verlangt die DSGVO einen gültigen Übermittlungsmechanismus nach Kapitel V. Standardvertragsklauseln (SCC) sind der häufigste Mechanismus, doch sie müssen von einem Transfer-Impact-Assessment begleitet werden, das ehrlich bewertet, ob die SCC angesichts des rechtlichen Umfelds des Empfängerlandes wirksamen Schutz bieten. Viele TIAs, die EU-Unternehmen bei der Bewertung von US-KI-Anbietern durchführen, sind in der Praxis zu optimistisch, was den Schutz der SCC im US-Rechtskontext angeht.

Frage 3: Können Sie vollständige Audit-Logs exportieren, und was enthalten sie?

Die Exportierbarkeit von Audit-Logs ist die Compliance-Anforderung, über die KI-Anbieter am wenigsten gern sprechen, und die meisten Verträge, die sie nicht ausdrücklich regeln, sollten so behandelt werden, als gäbe es die Funktion nicht. Wenn Ihr Vertrag nicht festlegt, dass Audit-Logs in einem strukturierten Format mit einer definierten Aufbewahrungsfrist exportierbar sind, können Sie nicht davon ausgehen, dass Sie darauf zugreifen können, wenn eine Aufsichtsbehörde oder Ihr interner Datenschutzbeauftragter danach fragt.

Der EU AI Act schafft hier eine direkte Pflicht für Hochrisiko-Systeme. Art. 11 und 12 des Gesetzes verlangen von Anbietern, Hochrisiko-KI-Systeme so zu gestalten, dass sie Ereignisse automatisch protokollieren, die ausreichen, um den Systembetrieb nachzuvollziehen, einschließlich Eingaben, Ausgaben und dem Zeitpunkt von Entscheidungen. Betreiber, also Sie, müssen diese Protokolle für den Zeitraum aufbewahren, der durch die einschlägige sektorspezifische Regulierung vorgegeben ist oder, in deren Ermangelung, für einen durch Durchführungsrechtsakte festzulegenden Mindestzeitraum. Wenn Sie die Protokolle nicht aus der Plattform des Anbieters exportieren können, können Sie die Aufbewahrungspflicht in Ihren eigenen Systemen nicht erfüllen und auf eine Anfrage der Aufsichtsbehörde keine Aufzeichnungen vorlegen.

Über den AI Act hinaus erfüllen Audit-Logs zwei weitere Compliance-Funktionen, die in der Beschaffung oft übersehen werden. Erstens sind bei einer DSGVO-Datenpanne Protokolle, die festhalten, welche Daten von welcher Systemkomponente und wann abgerufen wurden, entscheidend, um die Meldung der Panne einzugrenzen und die Rechenschaftspflicht gegenüber der Aufsichtsbehörde nachzuweisen. Zweitens können für interne Governance-Zwecke (besonders für Unternehmen, die sektorspezifischer Regulierung in Finanzen, Gesundheitswesen oder kritischer Infrastruktur unterliegen) Protokolle von KI-generierten Ausgaben erforderlich sein, um nachzuweisen, dass menschliche Aufsicht tatsächlich ausgeübt und nicht nur nominell verfügbar war.

Fragen Sie Anbieter konkret, was ihre Protokolle enthalten. Ein brauchbares Audit-Log für ein KI-System sollte mindestens festhalten: den Nutzer oder Prozess, der jede Anfrage ausgelöst hat, den Zeitstempel und eine eindeutige Kennung für jede Transaktion, die übermittelte Eingabe (oder deren Hash), die erzeugte Ausgabe und eine zum jeweiligen Zeitpunkt aktive Modellversionskennung. Protokolle, die nur festhalten „ein Nutzer hat eine Abfrage ausgeführt", reichen für regulatorische Zwecke nicht aus.

Frage 4: Trainieren Sie mit meinen Daten: Prompts, Transkripte, Ausgaben?

Dies ist die Frage mit den weitreichendsten kommerziellen und rechtlichen Folgen, und sie wird am häufigsten in den Nutzungsbedingungen des Anbieters vergraben, statt im Vertrag direkt angegangen zu werden. KI-Anbieter, die Geschäftsdaten verarbeiten, müssen ausdrücklich offenlegen, ob Prompts, Dateien, Telemetrie oder Ausgaben für das Modelltraining wiederverwendet werden. Legen sie dies nicht proaktiv offen, müssen Sie direkt fragen, und die Antwort schriftlich im Vertrag verlangen, nicht auf einer Webseite, die ohne Vorankündigung aktualisiert werden kann.

Das Risiko ist nicht hypothetisch. Wenn ein Anbieter Ihre Vertriebsgesprächs-Transkripte, Kundendaten, Produkt-Roadmap-Diskussionen oder kommerziellen Angebote nutzt, um sein Modell zu trainieren oder feinabzustimmen, werden mehrere DSGVO-Pflichten ausgelöst. Erstens: Enthalten diese Transkripte personenbezogene Daten über identifizierbare Personen, was Aufzeichnungen von Vertriebsgesprächen fast immer tun, stellt das Training mit diesen Daten einen neuen Verarbeitungszweck dar. Dieser Zweck braucht seine eigene Rechtsgrundlage. Das berechtigte Interesse dürfte einer Prüfung für Modelltraining mit fremden Geschäftsdaten kaum standhalten; die Einwilligung aller betroffenen Personen ist meist unpraktikabel. Zweitens erzeugen personenbezogene Daten, die in ein Modell eintrainiert werden, eine nahezu dauerhafte Aufzeichnung, gegen die Löschansprüche äußerst schwer zu erfüllen sind. Übt eine betroffene Person ihr Recht auf Löschung nach Art. 17 aus und wurden ihre Daten in Modellgewichte eintrainiert, können Sie möglicherweise nicht nachkommen.

Neben der DSGVO ist das kommerzielle Risiko klar. Ihre Prompts enthalten Ihre Geschäftslogik, Ihre Kundenintelligenz, Ihre Wettbewerbspositionierung und Ihre operativen Prozesse. Werden diese Prompts zum Training eines geteilten Modells verwendet, können die daraus gewonnenen Erkenntnisse mit der Zeit die Leistung desselben Modells für Ihre Wettbewerber verbessern, die dieselbe Plattform nutzen.

Die Vertragsklausel, die Sie brauchen, ist konkret: Sie sollte festlegen, dass der Anbieter Ihre Daten (einschließlich, aber nicht beschränkt auf Prompts, Eingaben, Ausgaben, Telemetrie, Datei-Uploads und Gesprächstranskripte) nicht nutzt, um irgendein KI-Modell zu trainieren, feinabzustimmen, zu verbessern oder zu evaluieren, ob es sich um das eigene Modell des Anbieters oder ein über eine API zugängliches Drittanbietermodell handelt. Viele Enterprise-KI-Anbieter bieten dies als Standardzusage der Enterprise-Stufe an; tut Ihrer das nicht, sollte es ein K.-o.-Kriterium oder eine hart verhandelte Anforderung sein.

Frage 5: Wie benachrichtigen Sie mich über Modell-Updates, bevor sie live gehen?

Kommunikationsprotokolle für Modell-Updates sind ein eigenständiges Bewertungskriterium für Anbieter, das die meisten Beschaffungsrahmen noch nicht enthalten, und ihr Fehlen ist ein stilles Compliance-Risiko. KI-Modelle sind nicht wie Softwareversionen, die nach einem festen Zeitplan veröffentlicht werden. Sie werden kontinuierlich aktualisiert, manchmal ohne jede öffentliche Ankündigung, und jedes Update kann die Ausgaben, von denen Ihre Abläufe abhängen, wesentlich verändern.

Die Compliance-Dimension davon ist direkt. Wenn Ihre Organisation ein KI-Tool in einem Kontext einsetzt, der konsistente, prüfbare Ausgaben erfordert (Kreditentscheidungen, HR-Screening, medizinische Triage-Unterstützung, Vertragsprüfung), kann ein Modell-Update die Kriterien, die eine bestimmte Ausgabe erzeugen, stillschweigend ändern, ohne dass sich Eingabe oder Oberfläche ändern. Der menschliche Prüfer, der letzten Monat Ausgaben freigegeben hat, hat möglicherweise Ausgaben eines anderen Modells geprüft als desjenigen, das diesen Monat läuft. Wenn Sie nicht nachweisen können, dass Ihre menschliche Aufsicht über das Modell, das die konkrete geprüfte Ausgabe erzeugt hat, tatsächlich wirksam war, ist der Prüfpfad unterbrochen.

Nach dem EU AI Act müssen Anbieter Betreiber über wesentliche Änderungen ihrer Systeme informieren, insbesondere bei Hochrisiko-Anwendungen. Doch „wesentlich" ist im aktuellen Text nicht präzise definiert, und viele Modelländerungen, die das Ausgabeverhalten wesentlich beeinflussen, werden von Anbietern nicht als wesentlich genug eingestuft, um eine formelle Benachrichtigung auszulösen. Sie können sich nicht auf die freiwillige Einstufung des Anbieters verlassen; Sie brauchen eine vertragliche Zusage.

Die vertragliche Zusage, die Sie brauchen, hat drei Komponenten. Erstens Vorankündigung: eine definierte Mindestzahl von Tagen, bevor ein Modell-Update wirksam wird, lang genug, um das neue Modell an Ihren Anwendungsfällen zu testen, bevor es in Produktion läuft. Dreißig Tage sind ein vernünftiges Minimum für geschäftskritische Abläufe; einige regulierte Sektoren verlangen mehr. Zweitens eine Zusammenfassung der Änderungen: nicht nur „Modellleistung verbessert", sondern eine Beschreibung der Art der Änderung, der betroffenen Fähigkeiten und etwaiger bekannter Änderungen der Ausgabeeigenschaften. Drittens die Möglichkeit, auf eine frühere Modellversion festzulegen oder die Migration für einen definierten Übergangszeitraum aufzuschieben. Ohne das kann ein Update, das einen Ablauf bricht, von dem Sie abhängen, über Nacht wirksam werden, ohne Rückgriffsmöglichkeit.

Zertifizierungen, auf die Sie achten sollten: ISO 27001, SOC 2, und was sie nicht abdecken

Zertifizierungen sind wichtig, müssen aber sorgfältig gelesen werden. ISO 27001 und SOC 2 Type II sind zur Grunderwartung für Enterprise-KI-Anbieter geworden, und ihr Fehlen sollte sofort Fragen aufwerfen. Ihr Vorhandensein beantwortet jedoch nicht die fünf Fragen von oben.

ISO 27001 ist ein international anerkannter Standard für Informationssicherheits-Managementsysteme. Die Erstzertifizierung kostet einen Anbieter 6.500 bis 20.000 Euro und dauert zwischen sechs und zwölf Monaten. Die jährlichen Aufrechterhaltungskosten liegen bei 2.400 bis 6.500 Euro. Ein Anbieter, der in eine ISO-27001-Zertifizierung investiert hat, hat einen funktionierenden Sicherheitsmanagementprozess, regelmäßige Risikobewertungen und definierte Kontrollen rund um Zugriff, Vorfallmanagement und Geschäftskontinuität nachgewiesen. Nicht nachgewiesen ist damit DSGVO-Konformität, Konformität mit dem EU AI Act, ein Verbot des Trainings mit Kundendaten oder irgendeine der KI-spezifischen Pflichten, die in diesem Artikel beschrieben sind.

SOC 2 Type II deckt dasselbe allgemeine Terrain ab, ist aber um fünf Trust Service Criteria strukturiert: Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz. Type II ist deutlich strenger als Type I, weil es einen sechsmonatigen Betriebszeitraum erfordert, in dem ein Prüfer beobachtet, dass die Kontrollen tatsächlich funktionieren, nicht nur, dass sie auf dem Papier existieren. Die Anfangskosten liegen bei 12.000 bis 32.000 Euro für die Prüfung, mit laufenden jährlichen Kosten von 8.000 bis 20.000 Euro. Für Anbieter mit US-Hauptsitz ist SOC 2 Type II oft der primäre Sicherheitsnachweis; für EU-basierte Anbieter ergänzt es ISO 27001.

Der praktische Leitsatz für EU-Einkaufsteams lautet: Behandeln Sie ISO 27001 und SOC 2 Type II als notwendig, aber nicht hinreichend. Sie sagen Ihnen, dass der Anbieter Sicherheit ernst nimmt. Sie sagen Ihnen nicht, ob mit Ihren Daten trainiert wird, ob Audit-Logs exportierbar sind oder ob Modell-Updates mit angemessener Vorankündigung eintreffen. Nutzen Sie sie, um Anbieter ohne Sicherheitsprogramm auszusortieren, und nutzen Sie dann die fünf Fragen dieses Artikels, um die KI-spezifischen Risiken zu bewerten, für die Zertifizierungen nie gedacht waren.

Sehen Sie, wie Numi von Grund auf für EU-Compliance gebaut ist, mit EU-Datenhaltung in Frankfurt und Amsterdam, keinem Training mit Kundendaten, exportierbaren Audit-Logs und einem standardmäßig enthaltenen AVV nach Art. 28 DSGVO. Als EU- und DSGVO-Alternative zu Gong und Chorus liefert Numi Sales Call Intelligence mit KI-Gesprächsanalyse und EU-gehostetem Coaching.