Personenbezug steckt in Cloud-Kostendaten überall dort, wo eine Zeile auf einen Menschen verweist: eine E-Mail-Adresse im Owner-Tag, ein Vorname im Konto- oder Ressourcennamen, die Kennung der Person, die eine Ressource angelegt oder ein Modell aufgerufen hat, oder der Ansprechpartner auf der Rechnung. Die DSGVO, Verordnung (EU) 2016/679, erfasst jede Information über eine identifizierte oder identifizierbare Person, und Kostendaten werden exportiert, kopiert und in Berichten breit geteilt. Diese Seite zeigt, in welchen Feldern von AWS, Azure und Google Cloud solche Werte stehen können und wie die Provider ihre eigene Verarbeitung dieser Daten beschreiben. Wie ein Unternehmen damit umgeht, entscheidet es mit seiner Datenschutzberatung.
So funktioniert es
Personenbezogen sind nach Artikel 4 Nummer 1 alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, direkt oder indirekt, etwa über einen Namen, eine Kennnummer oder eine Online-Kennung. Pseudonymisierte Daten, die sich mit zusätzlichen Informationen einer Person zuordnen lassen, bleiben nach Erwägungsgrund 26 Informationen über eine identifizierbare Person; der Europäische Datenschutzausschuss sagt dasselbe in seinen Leitlinien 01/2025 zur Pseudonymisierung, die er im Januar 2025 zur Konsultation veröffentlicht hat. Drei Grundsätze aus Artikel 5 Absatz 1 betreffen Kostendaten besonders: Zweckbindung (Buchstabe b), Datenminimierung (Buchstabe c) und Speicherbegrenzung (Buchstabe e). Nach Absatz 2 muss der Verantwortliche ihre Einhaltung nachweisen können. EUR-Lex führt die Verordnung am Lesetag ohne Änderung, mit zwei Änderungsvorschlägen der Kommission.
Felder, die auf eine Person zeigen können
| Fundstelle | AWS | Azure | Google Cloud |
|---|---|---|---|
| Frei vergebene Schlüssel-Wert-Paare | Cost-Allocation-Tags | Tags | Labels und Tags |
| Frei vergebene Namen | Kontonamen des Zahler- und des Nutzungskontos im CUR 2.0 | Abonnement, Ressourcengruppe, Ressourcenname | Projektname, Ressourcenname im detaillierten Export |
| Wer eine Ressource angelegt oder aufgerufen hat | Tag aws:createdBy mit Benutzername oder Rollensitzung; Spalte line_item_iam_principal für Bedrock-Aufrufe | kein solches Feld in der Feldliste | kein solches Feld in der Feldliste |
| Kontakte in Konto und Rechnung | Kontoinformationen wie Namen und E-Mail-Adressen | Feld AccountOwnerId mit der E-Mail-Adresse des EA-Kontoinhabers; Sold-to-Adresse auf jeder Rechnung | Kontoinformationen wie Namen, Kontaktdaten und Funktion |
Zwei AWS-Felder entstehen nur auf Entscheidung des Kunden: aws:createdBy wird erst nach Aktivierung durch das Verwaltungskonto gesetzt, und line_item_iam_principal füllt der CUR 2.0 nur mit der Option für IAM-Principal-Daten, frühestens ab dem 8. April 2026. Außerhalb der Hyperscaler gruppieren KI-Anbieter die Nutzung teils nach Personen; OpenAI etwa die Completions-Nutzung nach user_id, wie Nutzungs- und Kostenexporte der KI-Anbieter beschreibt.
Wie die Provider ihre Verarbeitung beschreiben
- AWS. Der Datenschutznachtrag (DPA) gilt für personenbezogene Daten, die der Kunde in die Dienste hochlädt; dafür ist AWS Auftragsverarbeiter. Ressourcenkennungen, Metadaten-Tags und Zugriffsregeln sind nach der Datenschutz-FAQ keine Kundeninhalte, und AWS rät, Angaben zu Personen sowie vertrauliche oder sensible Werte dort wegzulassen. Für Kontoinformationen, also Namen, Benutzernamen, E-Mail-Adressen und Abrechnungsdaten, gilt der Datenschutzhinweis von AWS.
- Microsoft. Der Products and Services Data Protection Addendum, aktuelle Fassung vom Mai 2026, macht den Kunden zum Verantwortlichen und Microsoft zum Auftragsverarbeiter. Für Geschäftsvorgänge, die mit der Leistung verbunden sind, darunter Abrechnung und Kontoverwaltung, handelt Microsoft nach eigener Aussage als eigenständiger Verantwortlicher und sagt Datenminimierung zu. Anhang B des Nachtrags führt pseudonyme Kennungen unter den Kategorien personenbezogener Daten.
- Google Cloud. Für personenbezogene Daten in den Kundendaten ist Google nach dem Cloud Data Processing Addendum Auftragsverarbeiter. Der Google Cloud Privacy Notice, gültig seit dem 15. Oktober 2026, nennt Kontoinformationen, Abrechnungsunterlagen sowie Ressourcenkennungen und -attribute als Service Data, für die bei Geltung des EU-Rechts Google Cloud EMEA Limited der Verantwortliche ist, für die Abrechnung gegebenenfalls die Google-Gesellschaft, mit der der Vertrag besteht. Die meisten Service Data hält Google bis zu 180 Tage, Daten für Steuer- und Buchhaltungszwecke in der Regel mindestens fünf Jahre.
Ein Tag-Wert oder Ressourcenname ist damit in der Darstellung von AWS und Google kein Kundeninhalt, sondern Teil der Konfiguration und läuft so in die Abrechnung des Providers und in jeden Export. Was daraus für die eigene Verarbeitung folgt, beurteilt die Datenschutzberatung.
Was es für Ihre Kosten bedeutet
Für die Kostenverteilung braucht es fast nie die Person, sondern das Team, das Produkt oder die Kostenstelle. Eine Tagging-Richtlinie, die Rollen und Teams statt Namen vorsieht, verteilt dieselben Kosten, ohne dass eine Person in jedem Export steht; die Regeln dafür stehen in Tagging-Strategie: eine Richtlinie, die hält. Wo ein personenbezogenes Feld einmal in den Daten ist, kostet es an jeder Kopie Aufwand: im Export-Bucket, im BI-Werkzeug, in Tabellen, die per E-Mail verschickt wurden. Eine Prüffolge für jeden Kostendatensatz hilft, diese Kopien klein zu halten:
- Welche Spalten können auf eine Person zeigen? Tags und Labels, Namen, Ersteller- und Aufruferkennungen, Kontakte.
- Wofür wird der Datensatz genutzt: Verteilung, Chargeback, Anomalieprüfung?
- Braucht dieser Zweck die Person, oder genügt das Team?
- Wer erhält den Datensatz? Rollen und Freigaben behandelt Zugriff auf Kostendaten: Rollen der Provider.
- Wie lange wird er aufbewahrt, und braucht die Historie die personenbezogene Spalte? Wie weit die Daten der Provider zurückreichen, zeigt Historie der Abrechnungsdaten.
- Welche Bedingungen des Providers decken das Feld ab? Die Liste oben nennt die Dokumente.
Die Abwägung zwischen langer Historie für Finance und Speicherbegrenzung entscheidet nicht diese Seite, sondern das Unternehmen mit seiner Datenschutzberatung.
Wo es schiefgeht
- E-Mail-Adressen als Owner-Tag. Der Wert steht in jedem Export und jedem Bericht mit dieser Spalte (Tags und Labels); was die drei Provider zu Personenangaben in Tags schreiben, fasst die Tagging-Strategie zusammen.
- aws:createdBy ohne Blick auf den Inhalt aktiviert. Der Wert kann Benutzernamen enthalten und erscheint in Kostenkonsole und Berichten für alle Mitgliedskonten der Organisation.
- Nutzung je Person breit verteilt. Ein Dashboard mit KI-Kosten nach user_id oder IAM-Principal geht an das ganze Unternehmen, obwohl die Steuerung nur Teamsummen braucht.
- Exporte ohne Zugriffskontrolle kopiert. Der Export liegt in einem Bucket oder Dataset, dessen Berechtigungen niemand prüft, und wandert von dort in Werkzeuge mit eigenen Freigaben.
- Ein Hash gilt als anonym. Eine gehashte E-Mail-Adresse lässt sich zuordnen, indem man die bekannten Adressen ebenso hasht und die Werte vergleicht. Die Leitlinien des Datenschutzausschusses beschreiben diesen Abgleich am Beispiel gehashter Namen, und Erwägungsgrund 26 behandelt pseudonymisierte Daten als Informationen über eine identifizierbare Person.
- Historie ohne Löschregel. Exporte werden über Jahre gesammelt, ohne festzulegen, welche Spalten nach welcher Frist entfallen.
Ob eine bestimmte Verarbeitung von Kostendaten zulässig ist und welche Fristen gelten, beurteilt die Datenschutzberatung des Unternehmens.
Quellen
Gelesen am 2026-10-16. EUR-Lex Verordnung (EU) 2016/679 (DSGVO); Europäischer Datenschutzausschuss Leitlinien 01/2025 zur Pseudonymisierung, Fassung zur Konsultation und Mitteilung zur Annahme; AWS Data Processing Addendum, Data Privacy FAQ, AWS-generierte Tags und CUR 2.0; Microsoft Products and Services Data Protection Addendum, Felder der Kostendetails und Kontaktdaten eines Abrechnungskontos; Google Cloud Cloud Data Processing Addendum, Google Cloud Privacy Notice und Struktur des detaillierten Exports; OpenAI Completions-Nutzung.