AWS Bedrock AVV und DSGVO in Deutschland: Was Legal prüfen sollte

Kurzantwort

AWS Bedrock kann für deutsche Unternehmen eine gut vertretbare DSGVO-Option sein. Vor der Freigabe müssen Sie aber den AWS-AVV, die Regionseinrichtung, mögliche Transfers, Logging sowie die zusätzlichen Bedingungen der eingesetzten Drittmodelle getrennt prüfen.

• AWS-Vertragsebene und Modellanbieter-Ebene getrennt bewerten.
• EU-Hosting als Konfigurationsfrage und nicht als pauschale Zusage behandeln.
• Prompt-Handling, Logs und Transferlogik vor dem Rollout dokumentieren.

AWS Bedrock kann für Unternehmen in Deutschland DSGVO-konform einsetzbar sein und ist oft einfacher zu beschaffen als ein direkter Vertrag mit einzelnen Modellanbietern. Entscheidend ist aber, dass Sie die AWS-Plattformzusagen von den Bedingungen der jeweiligen Drittmodelle trennen und tatsächlich prüfen, wo welche Verarbeitung stattfindet. In der Praxis sollten Legal und Procurement insbesondere den AVV nach Art. 28 DSGVO, die Transferlogik nach Kapitel V DSGVO, Logging- und Retention-Fragen sowie die zusätzlichen Bedingungen für Modelle von Anthropic, Meta, Mistral oder anderen Anbietern analysieren.

Damit ist Bedrock weniger eine abstrakte “ist das erlaubt?”-Frage als eine Due-Diligence-Frage für den Einkauf von Enterprise-KI. Wenn Legal, Security und Procurement denselben Architektur-Stack prüfen, kann Bedrock für deutsche Unternehmen eine vernünftige Beschaffungsroute sein.

Können Unternehmen in Deutschland AWS Bedrock rechtssicher einsetzen?

Oft ja. Die rechtlich belastbare Antwort hängt aber davon ab, wie Sie Bedrock konfigurieren, welche Modellfamilien Sie freigeben und welche Daten Sie über den Dienst verarbeiten.

Für viele interne Produktivitäts-, Entwicklungs-, Support-, Recherche- und Vertragsanwendungsfälle lässt sich Bedrock in eine saubere DSGVO-Struktur einordnen, wenn Sie:

1. Zweck und Datenkategorien vorab definieren,
2. die AWS-Vertragsebene sauber dokumentieren,
3. Region und Transferpfade technisch validieren,
4. provider-spezifische Modellbedingungen prüfen und
5. den Rollout in Ihre KI-Governance aufnehmen.

Die wesentlichen Rechtsfragen sind dabei bekannt:

• Art. 28 DSGVO für Auftragsverarbeitung und Weisungen,
• Art. 5 und Art. 32 DSGVO für Datenminimierung und Sicherheit,
• Kapitel V DSGVO für Drittlandtransfers,
• Art. 35 DSGVO für eine mögliche Datenschutz-Folgenabschätzung,
• § 87 Abs. 1 Nr. 6 BetrVG bei mitarbeiterbezogenen Einführungen,
• sowie der EU AI Act, wenn Bedrock in Transparenz- oder Hochrisiko-Szenarien eingesetzt wird.

Wenn Sie Bedrock mit anderen Enterprise-LLM-Optionen vergleichen, finden Sie weitere Einordnung in unseren Guides zu Claude Enterprise, Azure OpenAI, OpenAI API und Perplexity.

Gibt es einen AVV beziehungsweise DPA und wie ist Bedrock darin eingeordnet?

Für die meisten Unternehmen ist Bedrock kein isoliertes Vertragsuniversum, sondern Teil der AWS-Vertrags- und Datenschutzstruktur. Das ist aus Einkaufssicht hilfreich, weil AWS in vielen Unternehmen bereits freigegeben, verhandelt und in Vendor-Management-Prozessen erfasst ist.

Entscheidend ist jedoch nicht nur die Frage “gibt es einen AVV?”, sondern was dieser AVV im konkreten Bedrock-Setup abdeckt:

• ob die relevanten AWS-Verträge die geplanten Dienste und Nutzungsarten erfassen,
• ob Bedrock in Ihrem Vendor- und Verzeichnisprozess sauber erfasst ist,
• ob Unterauftragsverarbeiter, Support-Zugriffe und Incident-Regeln akzeptabel sind,
• ob Löschung, Audit und Sicherheitszusagen zu Ihrem internen Standard passen,
• und ob Ihre interne Nutzungsrichtlinie den vertraglichen Annahmen entspricht.

Aus deutscher Einkaufssicht ist der praktische Vorteil oft, dass AWS die zentrale Auftragsverarbeiter-Beziehung bildet. Das reduziert Reibung. Es ersetzt aber keine rechtliche Prüfung der Bedrock-spezifischen Konfiguration und keine saubere Dokumentation der tatsächlichen Datenverarbeitung.

Wie Sie den AWS-Bedrock-AVV abrufen und prüfen

AWS Bedrock stellt einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO bereit — er ist in die AWS-Kundenvereinbarung eingebettet und gilt automatisch für Amazon Bedrock als Teil des AWS-Serviceleistungsumfangs. Anders als bei einigen SaaS-Anbietern, die einen separaten AVV-Abschluss erfordern, ist der AWS-AVV bereits mit einem aktiven AWS-Account in Kraft.

So gehen Sie bei der Prüfung vor:

1. Melden Sie sich in der AWS Console an und rufen Sie Account Settings > Privacy and Terms auf, oder besuchen Sie direkt die AWS-Datenschutzseite unter aws.amazon.com/compliance/data-privacy/.
2. Laden Sie das aktuelle AWS-Datenschutzaddendum sowie die Service Terms herunter, die Amazon Bedrock abdecken.
3. Prüfen Sie die AWS-Subprocessor-Liste, die AWS öffentlich pflegt und bei Änderungen aktualisiert. Legal sollte bestätigen, dass die aufgeführten Unterauftragsverarbeiter mit Ihren internen Datenschutzrichtlinien vereinbar sind.
4. Enterprise-Kunden mit individuellen Commercial Terms können sich an ihr AWS-Account-Team wenden, um AVV-Spezifika zu verhandeln, den Abdeckungsumfang zu bestätigen oder eine gegengezeichnete Fassung des AVV zu erhalten.
5. Wenn Modelle von Anthropic, Meta, Mistral oder anderen Drittanbietern eingesetzt werden, prüfen Sie, ob die provider-spezifischen Bedrock-Bedingungen eine zusätzliche Verarbeitungsebene begründen, die eine separate rechtliche Prüfung erfordert.

Der AWS-AVV deckt insbesondere ab:

• Art. 28 DSGVO-Pflichten: AWS verpflichtet sich, personenbezogene Daten nur weisungsgemäß zu verarbeiten, geeignete technisch-organisatorische Maßnahmen zu implementieren und bei der Erfüllung von Betroffenenrechten zu unterstützen.
• Unterauftragsverarbeiter: AWS veröffentlicht seine Subprocessor-Liste, einschließlich Infrastruktur- und Supporteinheiten. Legal sollte prüfen, ob nicht-EU-Verarbeitung für den geplanten Use Case relevant ist.
• Standardvertragsklauseln (SCC): AWS nutzt die EU-SCC von 2021 für Datentransfers außerhalb des EWR. In der Regel gilt Modul 2 (Verantwortlicher an Auftragsverarbeiter).
• Datenlöschung und -portabilität: Der AVV regelt, wie AWS Daten bei Vertragsende behandelt, einschließlich Löschfristen und Portabilitätspflichten.
• Amazon Bedrock im Vertragsumfang: Bestätigen Sie, dass Ihr AWS-Vertrag Bedrock explizit erfasst und dass geplante Use Cases und Datenkategorien mit der AWS Acceptable Use Policy für KI/ML-Dienste vereinbar sind.

Einen Vergleich der AVV-Konditionen anderer Enterprise-KI-Anbieter finden Sie im Compound Law Leitfaden zum Auftragsverarbeitungsvertrag sowie in der Azure OpenAI-Datenschutzübersicht.

AWS-Bedrock-Zertifizierungen und DSGVO-Transferabsicherung für Deutschland

AWS verfügt über ein umfangreiches Zertifizierungsportfolio, das für deutsche Enterprise-Beschaffung relevant ist. Die am häufigsten angeforderten Zertifizierungen im DACH-Bereich sind:

• ISO 27001 — Das Informationssicherheits-Managementsystem (ISMS) von AWS ist ISO 27001-zertifiziert, auch für die Region Frankfurt (eu-central-1).
• SOC 2 Typ II — AWS veröffentlicht SOC-2-Typ-II-Berichte, die über AWS Artifact in der AWS Console abrufbar sind und in deutschen Beschaffungsprozessen regelmäßig angefordert werden.
• BSI C5 (Cloud Computing Compliance Criteria Catalogue) — AWS hält das C5-Testat des Bundesamts für Sicherheit in der Informationstechnik (BSI). Für öffentliche Auftraggeber und stark regulierte Unternehmen in Deutschland ist C5 oft eine Beschaffungsvoraussetzung.
• ISO 27701 — AWS hält diese Zertifizierung für Datenschutz-Informationsmanagement, die speziell DSGVO-relevante Datenschutzkontrollen adressiert.

Für deutsche Unternehmen sind folgende DSGVO-Transfer- und Compliance-Absicherungen besonders relevant:

• Region Frankfurt (eu-central-1): Die Wahl der Frankfurter Region hält Standardinferenz und Datenspeicherung innerhalb Deutschlands und der EU. Das ist die wichtigste Konfigurationsentscheidung für DSGVO-sensible Workloads. Für den Anthropic-on-Bedrock-Workflow finden Sie ergänzende Hinweise im Claude EU-Hosting-Guide, der zeigt, wie Regionsentscheidungen das Gesamtbild der DSGVO-Konformität beeinflussen.
• Standardvertragsklauseln (SCC): AWS verwendet die EU-SCC von 2021 für Transfers personenbezogener Daten aus dem EWR in Drittländer. Bestätigen Sie, dass Modul 2 (Verantwortlicher an Auftragsverarbeiter) für Ihre Bedrock-Konfiguration gilt, und prüfen Sie, ob intern ein Transfer Impact Assessment (TIA) erforderlich ist.
• Cross-Region-Inference: AWS bietet eine Cross-Region-Inference-Funktion, die Anfragen aus Kapazitäts- und Latenzgründen über mehrere AWS-Regionen verteilen kann. Wenn dieses Feature aktiviert ist, können Daten die gewählte EU-Region verlassen. Legal sollte es explizit deaktivieren oder in der Kapitel-V-Analyse berücksichtigen.
• BDSG: Das Bundesdatenschutzgesetz (BDSG) gilt neben der DSGVO in Deutschland. Bei Mitarbeiterdaten, besonderen Kategorien personenbezogener Daten oder Verhaltensdaten in Bedrock-Anwendungen gelten die strengeren BDSG-Voraussetzungen unabhängig vom AWS-AVV.
• BetrVG: Wenn Bedrock in Prozessen eingesetzt wird, die Mitarbeiter betreffen — zum Beispiel bei HR-Dokumentenautomatisierung, Leistungsauswertung oder internen Support-Tools — kann § 87 Abs. 1 Nr. 6 BetrVG eine Betriebsratsbeteiligung vor der Einführung erfordern, unabhängig davon, ob ein AVV unterzeichnet ist.

Einen umfassenderen Überblick, wie die DSGVO-Konformität von AWS Bedrock im Vergleich zu anderen Enterprise-KI-Plattformen zu bewerten ist, bietet die Compound Law-Übersicht zu KI-Tools.

EU-Hosting, Drittlandtransfer und was “EU-hosted” wirklich bedeutet

Gerade hier entstehen in Beschaffungsprozessen viele Fehlschlüsse. Wer “EU-Region” hört, liest schnell “ausschließlich EU-Verarbeitung”. So pauschal ist das nicht belastbar.

Bedrock unterstützt europäische Regionen wie Europa (Frankfurt) und Europa (Irland). AWS erklärt außerdem in den Bedrock-FAQs, dass Kundeninhalte verschlüsselt und in der Region gespeichert werden, in der der Dienst genutzt wird. Das ist für die DSGVO-Prüfung ein guter Ausgangspunkt, insbesondere wenn produktive Inferenz innerhalb der EU bleiben soll.

Trotzdem sollten Sie mindestens vier Fragen getrennt prüfen:

Thema	AWS-Ebene	Modellanbieter-Ebene	Was Legal verifizieren sollte
Vertragsabdeckung	AWS-Vertrag und AVV regeln die Servicebeziehung	Für Drittmodelle können zusätzliche Bedingungen gelten	Ob beide Ebenen für den geplanten Use Case akzeptabel sind
Inferenz-Standort	Die Regionswahl kann Standardnutzung in einer AWS-Region halten	Einzelne Features oder Model Profiles können breitere Routen nutzen	Ob Cross-Region-Inference oder ähnliche Mechaniken aktiv sind
Speicherung	AWS beschreibt eine regionale Speicherung der Kundeninhalte	Provider-Terme können zusätzliche Verarbeitungsvorgaben enthalten	Ob Logs, Caches und angebundene Dienste im Scope bleiben
Transfers	AWS stellt DSGVO-Transfermechanismen wie SCC-basierte Strukturen bereit	Provider-Ebene kann zusätzliche Subprocessor- oder Transferfragen auslösen	Ob die Kapitel-V-Prüfung wirklich abgeschlossen ist

Die wichtigste Lehre für Legal und Procurement lautet deshalb: Regionale Bereitstellung ist eine technische Kontrolle, aber keine automatische Rechtsabkürzung. Sobald Teams Features aktivieren, die Cross-Region-Inference nutzen, oder Bedrock mit weiteren Diensten koppeln, kann die ursprüngliche “EU-hosted”-Annahme unzutreffend werden.

Drittmodelle auf Bedrock: Wer verarbeitet welche Daten?

Bedrock ist attraktiv, weil Drittmodelle über eine AWS-Schnittstelle bereitgestellt werden. Das vereinfacht oft IAM, Billing, Freigaben und zentrale Zugriffskontrollen. Rechtlich verschmilzt die Architektur dadurch aber nicht zu einer einzigen Ebene.

Sie sollten sauber unterscheiden zwischen:

• AWS als Plattform- und Infrastrukturanbieter und
• dem Modellanbieter als Anbieter des eigentlichen Modells beziehungsweise modellbezogener Bedingungen.

Diese Trennung ist wichtig, weil AWS für Bedrock provider-spezifische Drittmodellbedingungen veröffentlicht. Procurement sollte deshalb vor einer Freigabe unter anderem klären:

1. Welche Modellfamilien sollen überhaupt zugelassen werden?
2. Gibt es provider-spezifische Nutzungsbeschränkungen, IP-Regeln oder Haftungsvorgaben?
3. Will das Unternehmen ein Default-Modell oder mehrere Modelle mit unterschiedlichen Rechtsprofilen zulassen?
4. Werden AWS-eigene Modelle, Drittmodelle, Fine-Tuning oder Agents mit externen Tools genutzt?

Aus Governance-Sicht ist Bedrock oft sinnvoll, wenn Unternehmen einen AWS-Kanal zentral freigeben und modellbezogene Berechtigungen intern steuern wollen. Das funktioniert aber nur, wenn die erlaubten Modelle begrenzt sind und deren Zusatzbedingungen vorab geprüft wurden.

Prompt-Retention, Training, Logging und technische Kontrollen

AWS erklärt in den Bedrock-FAQs, dass Model Invocation Requests und Responses nicht mit Modellanbietern geteilt werden und dass AWS Bedrock-Input und -Output nicht zum Training von AWS-Modellen verwendet. Das ist ein wichtiger Punkt in der datenschutzrechtlichen Bewertung.

Trotzdem bedeutet “kein Training” nicht “keine Datenverarbeitung außerhalb des eigentlichen Prompts”. Legal und Security sollten daher auch prüfen:

• Applikationslogs und Observability-Pipelines,
• CloudTrail- und Admin-Ereignisse,
• Prompts oder Outputs in Tickets, Chats oder Debugging-Systemen,
• angebundene Wissensdatenbanken und Retrieval-Quellen,
• Klassifizierungsregeln für Uploads,
• sowie Lösch- und Aufbewahrungslogik in angrenzenden Systemen.

Das gilt besonders für sensible Einsatzfelder wie:

• Support- und Callcenter-Inhalte,
• HR-nahe Entwürfe,
• interne Untersuchungen,
• Vertragsprüfung,
• regulierte Produktdokumentation,
• oder vertraulichen Quellcode und Architekturunterlagen.

Sobald personenbezogene Daten, Geschäftsgeheimnisse oder sensible Betriebsinformationen betroffen sind, empfiehlt sich eine dokumentierte Use-Case-Matrix. Darin sollte stehen, welche Daten in Bedrock dürfen, was vorher pseudonymisiert werden muss und welche Anwendungsfälle eine zusätzliche Freigabe benötigen.

Wann Bedrock gegenüber direkten Anbieter-Verträgen sinnvoller ist

Für viele Unternehmen in Deutschland ist Bedrock nicht nur technisch praktisch, sondern auch aus Beschaffungs- und Governance-Sicht sauberer als direkte Verträge mit mehreren Modellanbietern.

Bedrock ist häufig die bessere Route, wenn:

• Ihr Unternehmen bereits eine belastbare AWS-Beschaffungs- und Security-Struktur hat,
• Legal lieber eine zentrale Vendor-Beziehung statt vieler Einzelverträge steuert,
• IAM-, Netzwerk- und Logging-Kontrollen innerhalb der AWS-Umgebung bleiben sollen,
• Procurement einen zentralen Ausgaben- und Freigabekanal will,
• oder das Unternehmen mehrere Modelle testen möchte, ohne jeden Anbieter einzeln zu onboarden.

Direkte Anbieter-Verträge können dagegen sinnvoller sein, wenn:

• ein Anbieter außerhalb von Bedrock stärkere eigene EU-Zusagen macht,
• bestimmte Modellfunktionen nur direkt verfügbar sind,
• ein Kundenvertrag direkte Zusagen des Modellanbieters verlangt,
• oder das Volumen individuelle Commercial Terms rechtfertigt.

Kurz gesagt: Bedrock verändert die Beschaffungslogik, nicht den Bedarf an juristischer Prüfung. Die Prüffläche kann kleiner und zentraler werden. Sie verschwindet aber nicht.

Praktische Checkliste für Legal- und Security-Teams

Vor einer Freigabe sollten Legal, Datenschutz, Security und Procurement gemeinsam mindestens diese Punkte abarbeiten:

1. Zugelassene Bedrock-Use-Cases und Datenkategorien definieren.
2. Klären, welche AWS-Vertragspartner, Verträge und AVV-Dokumente einschlägig sind.
3. Produktions- und Testregionen für Bedrock festlegen.
4. Prüfen, ob Features, Model Profiles oder Integrationen Cross-Region-Routing nutzen.
5. Freigeben, welche Modellanbieter tatsächlich verwendet werden dürfen.
6. Provider-spezifische Bedrock-Bedingungen zu IP, Nutzung und Haftung prüfen.
7. Dokumentieren, ob eine DSFA nach Art. 35 DSGVO erforderlich ist.
8. Bewerten, ob eine Betriebsratsbeteiligung nach § 87 BetrVG erforderlich ist.
9. Regeln für Prompts, Uploads, Logs und Knowledge Bases schriftlich festlegen.
10. Die Entscheidung in KI-Governance, Vendor-Management und internen Richtlinien dokumentieren.

Wenn Sie einen umfassenderen Beschaffungsrahmen für Enterprise-KI in Deutschland aufbauen, finden Sie auf unserer Expertise-Seite die Verbindung zwischen Datenschutz, Commercial Contracts, Arbeitsrecht und AI-Act-Compliance.

Wobei Compound Law unterstützt

Compound Law berät Unternehmen in Deutschland und der DACH-Region beim Einkauf und Rollout von Enterprise-KI ohne vermeidbare rechtliche Folgekosten.

Typische Projekte sind:

• AVV- und Vendor-Paper-Review für Bedrock,
• Red-Flag-Analysen für provider-spezifische Modellbedingungen,
• DSGVO-Transfer- und DSFA-Scoping,
• KI-Governance und Nutzungsrichtlinien,
• Betriebsratsstrategie bei internen KI-Einführungen,
• sowie Vertragsgestaltung für kundennahe KI-Produkte.

FAQ

Was ist die zentrale Rechtsfrage bei einer AWS-Bedrock-AVV-Prüfung?

Die Kernfrage ist, ob Ihr konkretes Bedrock-Setup zu den vertraglichen und technischen Annahmen der AWS-Auftragsverarbeitung passt. Ein bloßer Hinweis auf einen vorhandenen AVV reicht nicht. Sie müssen auch Regionsdesign, Provider-Terme, Logging und Transferpfade prüfen.

Worin unterscheidet sich AWS Bedrock datenschutzrechtlich von einem direkten Anthropic- oder Meta-Vertrag?

Bedrock kann Infrastruktur, Beschaffung und Zugriffskontrolle über AWS zentralisieren. Das erleichtert häufig die Vendor-Steuerung. Gleichzeitig bleiben provider-spezifische Zusatzbedingungen und einzelne Transferfragen bestehen, sodass das Risikoprofil nur anders, nicht automatisch geringer ist.

Brauche ich Standardvertragsklauseln, wenn ich Bedrock in Europa nutze?

Möglicherweise ja. Die Nutzung einer EU-Region verbessert die Ausgangslage deutlich. Für die Kapitel-V-Prüfung müssen Sie aber weiterhin Support-Zugriffe, Unterauftragsverarbeiter, angebundene Dienste und mögliche Cross-Region-Verarbeitung berücksichtigen.

Verändert Bedrock das Risikoprofil beim Zugriff auf Modelle von Anthropic, Meta oder anderen Anbietern?

Ja, oft positiv aus Procurement-Sicht, weil AWS die operative Hauptschicht bildet. Das entfernt jedoch nicht alle provider-spezifischen Nutzungs- oder Transferfragen. Das Risikoprofil verschiebt sich, statt vollständig zu verschwinden.

Brauchen deutsche Unternehmen vor dem Rollout individuelle Rechtsberatung?

In vielen Fällen ja, vor allem bei personenbezogenen Daten, Mitarbeiterbezug, regulierten Prozessen oder kundenorientierter Automatisierung. Ein Guide kann den Rahmen erklären, ersetzt aber keine Prüfung des konkreten Einsatzes und der tatsächlichen Vertragslage.

Wie greife ich auf den AWS-Bedrock-AVV zu?

Das AWS-Datenschutzaddendum (DPA) ist in die AWS-Kundenvereinbarung eingebettet und gilt automatisch für Amazon Bedrock. Sie können es über die AWS-Datenschutzseite (aws.amazon.com/compliance/data-privacy/) oder über AWS Artifact in der AWS Console herunterladen. Enterprise-Kunden sollten außerdem mit ihrem AWS-Account-Team klären, ob der geplante Bedrock-Einsatz und die verarbeiteten Datenkategorien vollständig vom vereinbarten Vertragsrahmen gedeckt sind — insbesondere wenn Drittmodelle über Bedrock genutzt werden.

Verwendet AWS Bedrock Standardvertragsklauseln für Deutschland?

Ja. AWS nutzt die EU-Standardvertragsklauseln von 2021 (SCC) als primären DSGVO-Transfermechanismus für personenbezogene Daten, die außerhalb des EWR verarbeitet werden. Für die meisten Enterprise-Bedrock-Einsätze gilt Modul 2 (Verantwortlicher an Auftragsverarbeiter). Wählen Sie für Produktions-Workloads die Region Frankfurt (eu-central-1) und stellen Sie sicher, dass Cross-Region-Inference nicht ohne entsprechende Kapitel-V-Analyse aktiviert wird. Die aktuellen SCC-Dokumente stehen über AWS Artifact zum Download bereit.