Die Auftragsverarbeitung bei KI-Diensten erfordert nach DSGVO Art. 28 einen spezifischen AVV, der zusätzlich die AI-Act-Pflichten zur Transparenz und Datenverwaltung berücksichtigen muss. Für ChatGPT, Azure OpenAI, Gemini, Claude oder Bedrock ist deshalb die kurze Antwort: Sobald der Anbieter personenbezogene Daten ausschließlich nach Ihren Weisungen verarbeitet, brauchen Sie einen belastbaren Auftragsverarbeitungsvertrag.
Letzte Aktualisierung: 20. März 2026
Für Unternehmen ist die Reihenfolge entscheidend. Prüfen Sie zuerst, ob überhaupt Auftragsverarbeitung vorliegt, dann die Pflichtinhalte aus Art. 28 DSGVO und anschließend die KI-spezifischen Risiken wie Trainingsoptionen, Missbrauchsmonitoring, Unterauftragsverarbeiter und Drittlandtransfer. Wenn Sie die Grundlogik von Datenschutz und KI-Verordnung parallel einordnen wollen, lesen Sie ergänzend KI-Verordnung vs. DSGVO, den Überblick zu ChatGPT im Unternehmen, unsere Einordnung zu AI Act und Datenschutz, den Vergleich AI Act vs. NIS2 vs. DSGVO, den ISO-42001-Hub und die EU AI Act Schulung.
Wann liegt bei KI-Diensten überhaupt Auftragsverarbeitung vor?
Auftragsverarbeitung liegt nur dann vor, wenn der KI-Anbieter personenbezogene Daten für Ihr Unternehmen, zu einem von Ihnen festgelegten Zweck und weisungsgebunden verarbeitet. Genau daran scheitern viele pauschale Aussagen zu ChatGPT, Claude oder Gemini. Nicht jede Nutzung eines KI-Dienstes ist automatisch Auftragsverarbeitung, aber bei Business- und API-Szenarien ist sie häufig der Regelfall.
Die Abgrenzung lässt sich in drei Fragen herunterbrechen:
- Bestimmen Sie Zweck und Mittel der Verarbeitung im Wesentlichen selbst?
- Verarbeitet der Anbieter die Daten primär, um Ihre Leistung zu erbringen, statt eigene Zwecke zu verfolgen?
- Können Sie vertraglich steuern, was mit Prompts, Dateien, Logs und Ausgaben passiert?
Wenn alle drei Fragen überwiegend mit Ja beantwortet werden, spricht viel für Art. 28 DSGVO. Typische Beispiele sind ein Unternehmensaccount für generative KI, eine API-Einbindung in ein internes Assistenzsystem oder ein Copilot-Setup innerhalb einer bestehenden Cloud-Umgebung. Schwieriger wird es, wenn der Anbieter Eingaben gleichzeitig für eigene Produktverbesserung, Sicherheitsforschung oder eigenes Modelltraining nutzt. Dann kann die Rolle in Richtung eigener Verantwortlichkeit oder zumindest gemischter Verantwortlichkeit kippen.
Die praktisch wichtigste Abgrenzung lautet daher:
| Konstellation | Typische Einordnung | Warum das wichtig ist |
|---|---|---|
| Unternehmensinterner KI-Assistent über API oder Enterprise-Tarif | Häufig Auftragsverarbeitung | Art. 28 DSGVO, DPA/AVV, TOMs und Transferprüfung stehen im Vordergrund. |
| Anbieter nutzt Inhalte zusätzlich für eigenes Training oder Produktverbesserung | Häufig keine reine Auftragsverarbeitung | Dann reicht ein Standard-AVV allein nicht; Sie müssen die Rollen sauber neu bewerten. |
| Gemeinsame Produktgestaltung mit gemeinsamen Zwecken | Mögliche gemeinsame Verantwortlichkeit | Art. 26 DSGVO kann relevanter werden als Art. 28. |
| Frei zugängliches Consumer-Tool ohne Business-Vertrag | Oft eigene Verantwortlichkeit des Anbieters plus eigenes Risiko des Nutzers | Für personenbezogene Daten meist die schwächste und riskanteste Konstellation. |
Die operative Folge ist klar: Nutzen Sie möglichst keine Consumer-Tarife für personenbezogene Unternehmensdaten. Für einen strukturierten Einstieg in die Tool-Auswahl ist auch der Beitrag zu Open-Source-KI vs. ChatGPT hilfreich, weil dort die Betriebsmodelle und Datenflüsse besser vergleichbar werden.
Was Art. 28 DSGVO im AVV für KI-Dienste zwingend verlangt
Art. 28 DSGVO ist keine Formalität, sondern der Pflichtkatalog für die Zusammenarbeit mit dem KI-Anbieter. Ein belastbarer AVV muss mindestens Gegenstand und Dauer der Verarbeitung, Art und Zweck, Kategorien personenbezogener Daten, Kategorien betroffener Personen sowie die Rechte und Pflichten des Verantwortlichen festlegen.
Für KI-Dienste sollten Sie diese Pflichtpunkte nicht abstrakt, sondern technisch konkret beschreiben. Statt nur „Nutzung eines KI-Tools“ zu schreiben, ist besser: „Verarbeitung von Mitarbeiter-, Kunden- oder Bewerberdaten in Prompts, Anhängen, Retrieval-Datenbanken, Systemlogs und generierten Ausgaben zur Unterstützung interner Arbeitsprozesse.“ Diese Präzision hilft später bei DSFA, Löschkonzept, TOM-Prüfung und Audit.
Die unverzichtbaren Art.-28-Bausteine sind:
- Gegenstand und Dauer. Welcher Dienst, welche Module, welche Speicherfunktionen, welche Retention?
- Art und Zweck der Verarbeitung. Chat, Zusammenfassung, Suche, Klassifikation, RAG, Fine-Tuning oder Agentenfunktion?
- Datenkategorien. Stammdaten, Vertragsdaten, Beschäftigtendaten, Supportdaten, besondere Kategorien nur bei ausdrücklicher Freigabe.
- Betroffenengruppen. Kunden, Beschäftigte, Bewerber, Lieferanten, Nutzer des Supportsystems.
- Weisungsgebundenheit. Der Anbieter verarbeitet nur auf dokumentierte Weisung, nicht für beliebige Eigenzwecke.
- Vertraulichkeit und TOMs. Zugriffssteuerung, Verschlüsselung, Mandantentrennung, Logging, Löschroutinen, Notfallmanagement.
- Unterauftragsverarbeiter. Transparente Liste, Benachrichtigung bei Änderungen und Widerspruchsmechanismus.
- Unterstützungspflichten. Hilfe bei Betroffenenrechten, DSFA, Meldungen und Behördenanfragen.
- Löschung oder Rückgabe. Was passiert mit Prompts, Dateien, Trainingsdaten, Vektordaten und Backups nach Vertragsende?
- Audit und Nachweise. Zertifikate allein reichen nicht; Sie brauchen Prüfunterlagen, Berichte oder Trust-Center-Nachweise.
Genau hier überschneiden sich DSGVO und KI-Compliance. Der AVV muss nicht den gesamten AI Act „abbilden“, sollte aber die Punkte unterstützen, die Sie als Betreiber organisatorisch brauchen: Datenherkunft, menschliche Aufsicht, Zugriffskontrolle, Protokollierung und eine klare Lieferantensteuerung. Wenn Sie Governance breiter denken, ist die Systemperspektive aus AI Act, NIS2 und DSGVO im Vergleich ein sinnvoller Anschluss.
Welche KI-spezifischen Klauseln im AVV oft fehlen
Der Standard-AVV vieler Cloud-Anbieter ist für generative KI häufig zu allgemein. Entscheidend sind deshalb Zusatzfragen, die bei klassischem Hosting weniger relevant waren.
Erstens müssen Sie die Trainingsnutzung prüfen. Bei Business- und API-Produkten werben mehrere Anbieter damit, Eingaben und Ausgaben standardmäßig nicht für Modelltraining zu verwenden oder nur nach Opt-in. Genau diese Aussage gehört in Ihre Vertragsprüfung, weil sie für die Rollenfrage zentral ist. Fehlt eine klare Trennung zwischen Leistungserbringung und Modellverbesserung, ist der AVV rechtlich schwächer.
Zweitens müssen Sie Unterauftragsverarbeiter und Modellpfade verstehen. Bei KI-Diensten reicht eine Liste von Rechenzentren oft nicht aus. Relevant sind auch Safety-Dienste, Content-Filter, Abuse-Monitoring, Search-Grounding, Datei-Storage, Vektordatenbanken und externe Modellprovider im Hintergrund. Bei Azure OpenAI ist der Pfad anders als bei direkter OpenAI-Nutzung; bei Anthropic über Bedrock oder Vertex gelten wiederum die Drittplattform-Bedingungen des Host-Anbieters.
Drittens brauchen Sie belastbare Regeln zu Löschfristen und Speicherlogik. Generative KI speichert Daten nicht nur im „Chatverlauf“. Je nach Produkt können zusätzlich Dateien, embeddings, Zustandsdaten, Missbrauchslogs, Sicherheitsflags oder Gesprächshistorien anfallen. Der AVV sollte deshalb nicht nur Löschung „nach Vertragsende“ nennen, sondern auch betriebliche Speicherfristen und kundenseitige Löschmöglichkeiten abdecken.
Viertens sollten Sie Fine-Tuning, RAG und Connectoren gesondert behandeln. Sobald Ihr Unternehmen eigene Wissensbestände, E-Mail-Postfächer, SharePoint-Daten oder CRM-Inhalte anbindet, vergrößert sich der Umfang der Verarbeitung erheblich. Dann reichen die allgemeinen DPA-Aussagen auf der Marketingseite nicht mehr; Sie müssen die konkrete Feature-Nutzung prüfen. Genau deshalb sollten Sie KI-Features nie ohne Freigabematrix aktivieren.
Drittlandtransfer bei OpenAI, Google, Anthropic und anderen KI-Anbietern
Der Drittlandtransfer ist bei KI-Diensten oft das eigentliche Prüfzentrum. Ein AVV löst dieses Thema nicht automatisch, sondern bildet nur die vertragliche Basis. Entscheidend ist, wo Daten verarbeitet werden, welche Konzerngesellschaft Vertragspartner ist und auf welcher Transfermechanik der Datentransfer beruht.
Für US-Anbieter gibt es 2026 typischerweise drei Ebenen:
- EU-US Data Privacy Framework (DPF). Das kann einen Transfer in die USA erleichtern, ersetzt aber nicht Ihre Prüfung der konkreten Produktarchitektur.
- Standardvertragsklauseln (SCCs). Viele DPAs enthalten SCCs als Standard-Backstop oder für Konstellationen außerhalb des DPF.
- Transfer Impact Assessment (TIA). Bei sensiblen Daten, Beschäftigtendaten, hohem Volumen oder komplexen Unterauftragsketten bleibt eine dokumentierte Risikoprüfung sinnvoll.
Für die Praxis heißt das: Verlassen Sie sich nicht nur auf das Schlagwort „EU-Hosting“. Bei manchen Diensten betrifft EU-Hosting nur die Speicherung im Ruhezustand, während Abuse-Monitoring, globales Processing oder Supportzugriffe anders organisiert sein können. Microsoft dokumentiert für Azure OpenAI etwa starke Zusagen zu geografischer Verarbeitung und Nicht-Training ohne Kundenerlaubnis, weist aber zugleich auf globale oder Data-Zone-Deployment-Typen hin. Google beschreibt bei Vertex AI Trainingsbeschränkungen, nennt aber auch Funktionen mit begrenzter Retention oder besonderer Speicherlogik. Anthropic verweist bei kommerziellen Produkten auf DPA und SCCs, kombiniert dies aber je nach Produkt mit unterschiedlichen Retentions- und Zero-Data-Retention-Modellen.
Die richtige Transferfrage lautet deshalb nicht „Ist der Anbieter DSGVO-konform?“, sondern: Welche Daten aus welchem Use Case gehen über welche Produktvariante an welche Empfänger und mit welcher Rechtsgrundlage? Wer diese Frage nicht beantworten kann, hat den AVV noch nicht wirklich geprüft.
DPA-Vergleich: OpenAI vs. Microsoft vs. Google vs. Anthropic vs. AWS
Die großen Anbieter haben inzwischen belastbare Vertragsunterlagen, aber die Unterschiede liegen im Detail. Für den Einkauf ist weniger wichtig, ob „irgendein DPA“ existiert, sondern wie klar Trainingsnutzung, Unterauftragskette, Speicherfristen und Transfermechanik beschrieben sind.
| Anbieter | DPA/AVV-Basis | Trainingsnutzung laut Anbieter | Auffällige Punkte für die Prüfung |
|---|---|---|---|
| OpenAI | Eigener DPA für Business/API, Vertragspartner in EWR typischerweise OpenAI Ireland Ltd. | Business- und API-Daten werden standardmäßig nicht zum Training genutzt; Opt-in ist gesondert möglich. | Genau zwischen Consumer-, Business- und API-Nutzung unterscheiden; Retention, Connectoren und Feature-Umfang gesondert prüfen. |
| Microsoft / Azure OpenAI | Microsoft Products and Services DPA plus dienstspezifische Datenschutzdokumentation | Prompts, Outputs und Trainingsdaten sollen nicht ohne Erlaubnis zum Training von Foundation-Modellen genutzt werden. | Deployment-Typen, Geografie, Abuse-Monitoring und Datenzonen genau prüfen; in vielen Unternehmen vertraglich am stärksten integriert. |
| Google / Vertex AI | Cloud Data Processing Addendum und Service Specific Terms | Kundendaten werden laut Training Restriction nicht ohne vorherige Erlaubnis oder Weisung zum Training oder Fine-Tuning genutzt. | Prompt-Logging, Search-Grounding, Caching und Zero-Data-Retention-Optionen featurebezogen prüfen. |
| Anthropic | DPA mit SCCs ist in die Commercial Terms eingebunden | Bei kommerziellen Produkten laut Anbieter keine Trainingsnutzung ohne gesondertes Opt-in. | Zwischen API, Claude for Work und Nutzung über Bedrock oder Vertex unterscheiden; Zero Data Retention nicht für alle Produkte verfügbar. |
| AWS / Bedrock | AWS DPA greift über AWS Service Terms | AWS beschreibt für Bedrock, dass Inputs und Outputs nicht zum Training der Bedrock-Modelle genutzt werden. | Prüfen, welcher Modellanbieter im Hintergrund sitzt und welche zusätzlichen Vertragswerke für Drittmodelle gelten. |
Die nüchterne Bewertung lautet: Microsoft und AWS sind für viele Unternehmen vertraglich am einfachsten integrierbar, OpenAI und Anthropic sind oft funktionsstark, Google ist bei Feature-Steuerung differenziert, aber kein Anbieter nimmt Ihnen die eigene Risikoanalyse ab. Das ist eine Schlussfolgerung aus den Vertrags- und Produktunterlagen, nicht eine pauschale Rechtsaussage.
Praxistipps: So prüfen Sie einen AVV für KI-Dienste sauber
Ein guter AVV-Prozess für KI-Dienste ist kurz, standardisiert und featurebezogen. Sinnvoll ist eine Checkliste mit Go-/No-Go-Kriterien statt einer bloßen Ablage des PDF-Vertrags.
Ihre Mindest-Checkliste sollte diese Punkte enthalten:
- Liegt für genau den genutzten Tarif und das genutzte Produkt ein DPA/AVV vor?
- Ist die Rollenverteilung als Verantwortlicher und Auftragsverarbeiter konsistent beschrieben?
- Sind Trainingsnutzung und Produktverbesserung klar standardmäßig ausgeschlossen oder opt-in-basiert?
- Gibt es eine aktuelle Unterauftragsverarbeiterliste und ein Änderungsregime?
- Sind Speicherfristen, Löschung und Exportmöglichkeiten verständlich geregelt?
- Ist die Transfermechanik für USA- oder Drittstaatenzugriffe dokumentiert?
- Passen TOMs, Zugriffsmodell und Auditunterlagen zu Ihrem Schutzbedarf?
- Sind Zusatzfeatures wie Connectoren, Grounding, Files, Assistants, Fine-Tuning oder Agenten gesondert bewertet?
Typische Red Flags sind ebenso klar:
- Kein belastbarer Unterschied zwischen Consumer- und Business-Nutzung
- Unklare oder zu weite Rechte zur Produktverbesserung
- Fehlende oder schwer auffindbare Unterauftragsverarbeiterliste
- Unpräzise Angaben zu Datenlöschung und Backup-Löschung
- Marketingaussagen zu „DSGVO-Konformität“ ohne konkrete Vertrags- oder Featurebezüge
Verhandlungsoptionen haben vor allem Enterprise-Kunden. Häufig realistisch sind individuelle Speicherfristen, zusätzliche Sicherheitsanhänge, Zero-Data-Retention-Modelle, strengere Support-Regeln, Feature-Deaktivierungen und ergänzende Sicherheitsdokumentation. Für kleinere Unternehmen ist die bessere Strategie oft nicht „alles verhandeln“, sondern den passenden Tarif und das passende Betriebsmodell zu wählen. Deshalb lohnt sich in sensiblen Umgebungen auch die Prüfung von Self-Hosting oder europäischen Alternativen, etwa im Kontext von Datensouveränität mit Open Source KI.
Fazit: Der AVV für KI-Dienste ist ein Steuerungsinstrument, kein PDF für die Ablage
Ein AVV für KI-Dienste ist nur dann wirksam, wenn er die reale Produktnutzung abbildet. Für ChatGPT, Azure OpenAI, Gemini, Claude oder Bedrock bedeutet das: Art. 28 DSGVO, Trainingsoptionen, Unterauftragsverarbeiter, Löschfristen und Drittlandtransfer müssen als Gesamtbild geprüft werden, nicht als Häkchenliste.
Die beste Praxis für 2026 lautet deshalb: erst Rollen sauber bestimmen, dann den passenden DPA prüfen, anschließend Features und Transfers dokumentieren und zuletzt Schulung, Freigaben und Governance im Unternehmen verankern. Wenn Sie dafür ein belastbares Mindestniveau für Fachbereiche, Datenschutz, IT und Einkauf aufbauen wollen, ist die EU AI Act Schulung der pragmatische nächste Schritt.