Analyse der Rechtsgrundlagen der Datenverarbeitung
QR Branding API – Art. 6 DSGVO
| Feld | Wert |
|---|---|
| Verantwortlicher | QR Branding (Quartzon) |
| Datum | 2026-03-08 |
| Version | 1.0 |
1. Grundsatz der Rechtmäßigkeit (Art. 6)
Jede Verarbeitung personenbezogener Daten muss sich auf mindestens eine der Rechtsgrundlagen aus Art. 6(1) DSGVO stützen. Im Folgenden wird jede Verarbeitungstätigkeit von QR Branding mit ihrer jeweiligen Rechtsgrundlage analysiert.
2. Analyse nach Verarbeitungstätigkeit
2.1 Erzeugung von QR-Codes mit personenbezogenen Daten
| Aspekt | Analyse |
|---|---|
| Tätigkeit | Der Nutzer übermittelt QR-Inhalte, die personenbezogene Daten enthalten können (eine vCard mit Name, E-Mail, Telefon und Adresse; Geostandort; E-Mail-Adressen) |
| Rechtsgrundlage | Art. 6(1)(b) – Vertragserfüllung |
| Begründung | Die Verarbeitung ist erforderlich, um den Dienst zu erbringen, den der Nutzer über RapidAPI beauftragt hat. Ohne Verarbeitung des Inhalts kann der angeforderte QR-Code nicht erzeugt werden |
| Verhältnismäßigkeit | Minimal: Verarbeitet wird nur der unbedingt nötige Inhalt, im Arbeitsspeicher, ohne Speicherung |
| Weniger eingreifende Alternative | Keine: Der QR-Inhalt SIND die zu codierenden Daten |
2.2 KI-generierte QR-Codes
Die KI-Generierung funktioniert in zwei Varianten:
- Eigene Konten von QR Branding (der KI-Designer auf qr-branding.com und der verwaltete Endpunkt
POST /api/qr/ai/generate-managed): QR Branding sendet den Design-Prompt mit seinen eigenen API-Schlüsseln an einen LLM-Anbieter seiner internen Fallback-Kette (Groq, Google Gemini, OpenAI). Diese Anbieter handeln als Auftragsverarbeiter von QR Branding und sind auf der Seite der Unterauftragsverarbeiter aufgeführt. - BYOK (Bring Your Own Key) (der Endpunkt
POST /api/qr/ai/generate): Der Kunde liefert seinen eigenen API-Schlüssel und wählt den Anbieter; QR Branding nutzt für diese Anfragen keine eigenen Konten.
| Aspekt | Analyse |
|---|---|
| Tätigkeit | Der Nutzer übermittelt einen Design-Prompt. QR Branding leitet den Prompt an einen LLM-Anbieter weiter: mit seinen eigenen Schlüsseln (Website und verwalteter Endpunkt) oder mit dem Schlüssel des Kunden (llmApiKey, BYOK-Endpunkt) |
| Modell | Eigene Konten von QR Branding bei Groq, Google (Gemini) und OpenAI, oder BYOK (Bring Your Own Key) mit dem vom Kunden gewählten Anbieter |
| Rechtsgrundlage | Art. 6(1)(b) – Vertragserfüllung |
| Begründung | Der Nutzer fordert ausdrücklich ein KI-generiertes Design an: auf der Website und über den verwalteten Endpunkt, indem er eine KI-Generierung auslöst; über den BYOK-Endpunkt zusätzlich, indem er den Anbieter wählt und seinen eigenen API-Schlüssel liefert. Die Verarbeitung ist erforderlich, um genau diese Anfrage auszuführen |
| Verhältnismäßigkeit | Nur der Design-Prompt und die Generierungsparameter werden an das LLM gesendet. QR-Inhalte, IP-Adressen und Identifikationsdaten werden NIE übermittelt. Beim BYOK-Endpunkt wird der API-Schlüssel des Kunden weder gespeichert noch protokolliert |
| Hinweis | Der Nutzer entscheidet aktiv, die KI-Generierung zu nutzen, und über den Prompt, den er sendet. Beim BYOK-Endpunkt wählt er zusätzlich den LLM-Anbieter und liefert seinen eigenen API-Schlüssel, und das Verhältnis zum LLM-Anbieter besteht unmittelbar zwischen Kunde und Anbieter |
2.3 Rate-Limiting
| Aspekt | Analyse |
|---|---|
| Tätigkeit | Zählen der Anfragen pro Kennung (RapidAPI-Nutzer, Abonnement-ID, anonymisierte IP), um die Nutzungsrate zu begrenzen |
| Rechtsgrundlage | Art. 6(1)(f) – Berechtigtes Interesse |
| Berechtigtes Interesse | Schutz der Verfügbarkeit des Dienstes für alle Nutzer sowie Verhinderung von Missbrauch und übermäßigen Kosten |
| Interessenabwägung | |
| — Interesse des Verantwortlichen | Hoch: Ohne Rate-Limiting könnte ein einzelner Nutzer die Ressourcen erschöpfen oder untragbare Kosten verursachen |
| — Auswirkung auf die betroffene Person | Minimal: Zum Zählen wird nur eine pseudonyme Kennung genutzt, die Daten liegen im flüchtigen Speicher (2 Min.), und IP-Adressen werden anonymisiert |
| — Vernünftige Erwartung | Ja: API-Nutzer erwarten Rate-Limiting als übliche Branchenpraxis |
| — Garantien | Flüchtige Daten (2 Min.), IP-Anonymisierung, Obergrenze für die Erfassung (50K IPs), keine Protokollierung von Kennungen |
| Ergebnis | Das berechtigte Interesse überwiegt angesichts der minimalen Auswirkung auf die betroffene Person eindeutig |
2.4 Telemetrie und Diagnose (Application Insights)
| Aspekt | Analyse |
|---|---|
| Tätigkeit | Erfassung von Leistungsmetriken, Fehlern und Metadaten von Anfragen (ohne personenbezogene Daten) |
| Rechtsgrundlage | Art. 6(1)(f) – Berechtigtes Interesse |
| Berechtigtes Interesse | Den Dienst zuverlässig und verfügbar halten und Probleme schnell diagnostizieren |
| Interessenabwägung | |
| — Interesse des Verantwortlichen | Hoch: Ohne Telemetrie lassen sich Vorfälle weder erkennen noch beheben |
| — Auswirkung auf die betroffene Person | Minimal: Personenbezogene Daten aus Fehlermeldungen entfernt, API-Schlüssel geschwärzt, IP-Adressen anonymisiert |
| — Vernünftige Erwartung | Ja: Monitoring ist bei Cloud-Diensten übliche Praxis |
| — Garantien | 90 Tage Aufbewahrung, Protokollierung ohne personenbezogene Daten, IP-Anonymisierung, Schwärzung von API-Schlüsseln |
| Ergebnis | Das berechtigte Interesse überwiegt eindeutig |
2.5 RapidAPI-Authentifizierung
| Aspekt | Analyse |
|---|---|
| Tätigkeit | Prüfung des Headers X-RapidAPI-Proxy-Secret bei jeder Anfrage |
| Rechtsgrundlage | Art. 6(1)(f) – Berechtigtes Interesse |
| Begründung | Schutz des Dienstes vor unbefugtem Zugriff |
| Hinweis | Das Geheimnis ist ein Serverdatum, kein Nutzerdatum. In diesem Schritt werden überhaupt keine personenbezogenen Daten verarbeitet |
3. NICHT herangezogene Rechtsgrundlagen
| Rechtsgrundlage | Art. | Warum wird sie nicht genutzt? |
|---|---|---|
| Einwilligung | Art. 6(1)(a) | Es wird keine ausdrückliche Einwilligung eingeholt. Sie ist nicht nötig: Die Verarbeitung stützt sich auf Vertrag und berechtigtes Interesse. Eine Einwilligung als Grundlage brächte ohne Nutzen zusätzliche Pflichten mit sich (Widerrufbarkeit) |
| Rechtliche Verpflichtung | Art. 6(1)(c) | Keine rechtliche Verpflichtung erfordert die Verarbeitung dieser Daten |
| Lebenswichtige Interessen | Art. 6(1)(d) | Nicht anwendbar: Der Dienst verarbeitet keine Daten zum Schutz lebenswichtiger Interessen |
| Öffentliches Interesse | Art. 6(1)(e) | Nicht anwendbar: Es handelt sich um einen privaten kommerziellen Dienst |
4. Besondere Kategorien personenbezogener Daten (Art. 9)
QR Branding fordert keine besonderen Kategorien personenbezogener Daten an und benötigt sie nicht (ethnische Herkunft, Gesundheit, sexuelle Orientierung usw.).
Der Nutzer könnte solche Daten jedoch in QR-Inhalte aufnehmen (z. B. ein QR-Code mit medizinischen Daten). In diesem Fall gilt:
- QR Branding handelt als technischer Verarbeiter, der Daten codiert, ohne sie zu interpretieren.
- Die Verantwortung für die Verarbeitung der besonderen Kategorien liegt beim Nutzer, der sie aufnimmt.
- Rechtsgrundlage wäre in diesem Fall die ausdrückliche Einwilligung der betroffenen Person, die der Nutzer vor dem Codieren der Daten einholen muss.
- QR Branding speichert diese Daten nicht und verwirft sie unmittelbar nach der Erzeugung.
5. Daten von Kindern (Art. 8)
- QR Branding ist ein B2B/B2C-API-Dienst für Entwickler und Unternehmen.
- Er richtet sich nicht an Kinder unter 16 Jahren.
- Es werden keine Altersangaben erhoben und keine Altersprüfung durchgeführt.
- Nimmt ein Nutzer Daten von Kindern in QR-Inhalte auf, liegt die Verantwortung für die Einholung der elterlichen Einwilligung beim Nutzer.
6. Internationale Übermittlungen (Art. 44-49)
| Ziel | Rechtsgrundlage der Übermittlung | Anbieter |
|---|---|---|
| EU/USA (Azure) | Online Services Terms + SCCs | Microsoft Azure |
| USA | Plattformbedingungen | RapidAPI |
| USA | Datenverarbeitungsbedingungen des jeweiligen Anbieters (siehe die Seite der Unterauftragsverarbeiter) | Groq, Google (Gemini), OpenAI: KI-Generierung mit den Konten von QR Branding |
Hinweis zu LLM-Anbietern: Mit den eigenen Konten von QR Branding (Website und verwalteter Endpunkt) werden Design-Prompts an Groq, Google (Gemini) oder OpenAI übermittelt, die als Auftragsverarbeiter von QR Branding handeln. Beim BYOK-Endpunkt werden Prompts mit dem eigenen API-Schlüssel des Kunden an den vom Kunden gewählten Anbieter übermittelt (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek oder Qwen oder ein eigener OpenAI-kompatibler Endpunkt). Die Verantwortung für diese Übermittlung liegt beim Kunden, der ein unmittelbares Vertragsverhältnis mit dem Anbieter unterhält; QR Branding handelt als technischer Vermittler.
Die Nutzung des Standard-Endpunkts zur QR-Erzeugung ist mit keiner Übermittlung an LLM-Anbieter verbunden (die Verarbeitung erfolgt ausschließlich auf Azure).
7. Überprüfung
Diese Analyse der Rechtsgrundlagen muss überprüft werden:
- Wenn neue Verarbeitungstätigkeiten hinzukommen
- Wenn sich die verarbeiteten Daten bestehender Tätigkeiten ändern
- Wenn sich die Richtlinien der LLM-Anbieter ändern
- Mindestens einmal im Jahr
Dokument erstellt am 2026-03-08.