Verzeichnis von Verarbeitungstätigkeiten (VVT)
QR Branding API – Art. 30 DSGVO
| Feld | Wert |
|---|---|
| Verantwortlicher | QR Branding (Quartzon) |
| Datum | 2026-03-08 |
| Version | 1.0 |
Tätigkeit 1: Erzeugung von QR-Codes
| Feld | Beschreibung |
|---|---|
| Bezeichnung | Erzeugung individuell gestalteter QR-Codes |
| Verantwortlicher | QR Branding |
| Zweck | Erzeugung von QR-Bildern (PNG/SVG/PDF/Base64) aus Inhalten und Konfigurationen, die der Nutzer liefert |
| Rechtsgrundlage | Vertragserfüllung – Art. 6(1)(b) |
| Kategorien betroffener Personen | API-Nutzer (Entwickler, Unternehmen) und in vCards enthaltene Kontakte |
| Datenkategorien | URLs, Freitext, WLAN-Zugangsdaten (SSID/Passwort), vCard-Kontaktdaten (Name, E-Mail, Telefon, Adresse, Organisation), Geostandort, E-Mail-Adressen, Telefonnummern |
| Empfänger | Keine: Die Verarbeitung erfolgt ausschließlich intern; das Ergebnis wird an den Nutzer zurückgegeben |
| Internationale Übermittlungen | Nein: Verarbeitung auf Azure (Host-Region) |
| Löschfristen | Sofort: Die Daten werden im Arbeitsspeicher verarbeitet und nach der HTTP-Antwort verworfen |
| Sicherheitsmaßnahmen | TLS 1.2+, Eingabevalidierung (OWASP), SSRF-Schutz, Entfernen von EXIF-Daten, Rate-Limiting, RapidAPI-Authentifizierung, IP-Anonymisierung in Logs |
Tätigkeit 2A: KI-generierte QR-Codes mit den Anbieterkonten von QR Branding
| Feld | Beschreibung |
|---|---|
| Bezeichnung | Erzeugung von QR-Designs mithilfe künstlicher Intelligenz, mit den eigenen LLM-Anbieterkonten von QR Branding |
| Geltungsbereich | Der KI-Designer auf qr-branding.com und der verwaltete Marketplace-Endpunkt (POST /api/qr/ai/generate-managed) |
| Verantwortlicher | QR Branding |
| Zweck | Erzeugung einer QR-Design-Konfiguration aus einem Prompt in natürlicher Sprache |
| Rechtsgrundlage | Vertragserfüllung – Art. 6(1)(b) |
| API-Schlüssel-Modell | Eigene API-Schlüssel von QR Branding. Jede Anfrage durchläuft eine interne Fallback-Kette von Anbietern (Groq, Google Gemini, OpenAI): Fällt ein Anbieter aus, wird der nächste versucht |
| Kategorien betroffener Personen | Nutzer der Website qr-branding.com und API-Nutzer |
| Datenkategorien | Design-Prompt (Freitext) und Generierungsparameter (Stilvorgabe, Kreativität, strikte Scanbarkeit). Der QR-Inhalt wird nicht an das LLM gesendet |
| Empfänger | Der LLM-Anbieter, der die Anfrage in der Fallback-Kette bedient |
| Auftragsverarbeiter | Groq, Inc., Google LLC (Gemini) und OpenAI, OpCo, LLC, wie auf der Seite der Unterauftragsverarbeiter aufgeführt |
| Internationale Übermittlungen | Ja: Die drei Anbieter haben ihren Sitz in den USA. Die Übermittlung stützt sich auf die Datenverarbeitungsbedingungen des jeweiligen Anbieters, wie auf der Seite der Unterauftragsverarbeiter angegeben |
| Löschfristen | Der Prompt-Text wird im Arbeitsspeicher verarbeitet und von QR Branding nicht gespeichert. Die erzeugte Design-Konfiguration kann bis zu 30 Tage im Prompt-Cache gehalten werden, unter einem Schlüssel, der aus einem SHA-256-Hash des Prompts und der Parameter abgeleitet ist. Die Aufbewahrung beim Anbieter richtet sich nach dessen eigenen Bedingungen |
| Sicherheitsmaßnahmen | Prompt-Begrenzer, Anweisungen gegen Datenabfluss, Nullsetzen von URL-/base64-Feldern, HTML-Bereinigung, Obergrenze für Ausgabe-Tokens bei jedem LLM-Aufruf, Größenbegrenzung der Antworten (1MB), Schwärzung von API-Schlüsseln in Logs (SanitizeForLog). An den Anbieter werden keine E-Mail-Adresse, keine Abrechnungsdaten, keine IP-Adresse und keine Kundenkennung gesendet |
Tätigkeit 2B: KI-generierte QR-Codes mit dem eigenen Schlüssel des Kunden (BYOK)
| Feld | Beschreibung |
|---|---|
| Bezeichnung | Erzeugung von QR-Designs mithilfe künstlicher Intelligenz, mit dem eigenen LLM-API-Schlüssel des Kunden |
| Geltungsbereich | Der Marketplace-Endpunkt POST /api/qr/ai/generate |
| Verantwortlicher | QR Branding (Verarbeitung des Prompts und Rendering) |
| Zweck | Erzeugung einer QR-Design-Konfiguration aus einem Prompt in natürlicher Sprache |
| Rechtsgrundlage | Vertragserfüllung – Art. 6(1)(b) |
| API-Schlüssel-Modell | BYOK (Bring Your Own Key): Der Kunde liefert mit jeder Anfrage seinen eigenen API-Schlüssel des LLM-Anbieters (llmApiKey) und wählt den Anbieter: OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek oder Qwen oder einen eigenen OpenAI-kompatiblen Endpunkt (local) |
| Kategorien betroffener Personen | API-Nutzer |
| Datenkategorien | Design-Prompt (Freitext), API-Schlüssel des Kunden (flüchtig, nicht gespeichert), QR-Inhalt (wird nicht an das LLM gesendet) |
| Empfänger | Der vom Nutzer gewählte LLM-Anbieter (oder der eigene Endpunkt des Kunden), mit dem eigenen API-Schlüssel des Nutzers |
| Auftragsverarbeiter | Keine für diese Tätigkeit: QR Branding handelt als technischer Vermittler. Das Vertragsverhältnis mit dem LLM-Anbieter besteht unmittelbar zwischen Kunde und Anbieter |
| Internationale Übermittlungen | Die Übermittlung von Daten an den LLM-Anbieter liegt in der Verantwortung des Kunden, der ein eigenes Vertragsverhältnis mit dem Anbieter unterhält. QR Branding leitet den Prompt nur technisch weiter |
| Löschfristen | Der Prompt-Text wird im Arbeitsspeicher verarbeitet und nicht gespeichert. Die erzeugte Design-Konfiguration kann bis zu 30 Tage im Prompt-Cache gehalten werden, unter einem Schlüssel, der aus einem SHA-256-Hash des Prompts und der Parameter abgeleitet ist. Der API-Schlüssel des Kunden wird weder gespeichert noch protokolliert |
| Sicherheitsmaßnahmen | Prompt-Begrenzer, Anweisungen gegen Datenabfluss, Nullsetzen von URL-/base64-Feldern, HTML-Bereinigung, Obergrenze für Ausgabe-Tokens bei jedem LLM-Aufruf, Größenbegrenzung der Antworten (1MB), Schwärzung von API-Schlüsseln in Logs (SanitizeForLog) |
Tätigkeit 3: Rate-Limiting und Missbrauchsprävention
| Feld | Beschreibung |
|---|---|
| Bezeichnung | Steuerung der Anfragerate |
| Verantwortlicher | QR Branding |
| Zweck | Missbrauch verhindern sowie Verfügbarkeit und Betriebskosten des Dienstes schützen |
| Rechtsgrundlage | Berechtigtes Interesse – Art. 6(1)(f) |
| Berechtigtes Interesse | Schutz der Infrastruktur und der Verfügbarkeit des Dienstes für alle Nutzer |
| Kategorien betroffener Personen | Alle API-Nutzer |
| Datenkategorien | RapidAPI-Kennung (pseudonym), Abonnement-Kennung, IP-Adresse (anonymisiert) |
| Empfänger | Keine: interne Verarbeitung |
| Internationale Übermittlungen | Nein |
| Löschfristen | 2 Minuten (gleitendes Fenster im Arbeitsspeicher mit automatischer Verdrängung) |
| Sicherheitsmaßnahmen | Daten im flüchtigen Speicher (nicht persistiert), IP-Anonymisierung (letztes Oktett), Obergrenze von 50.000 erfassten IPs, regelmäßige Bereinigung alle 2 Minuten |
Tätigkeit 4: Telemetrie und Diagnose
| Feld | Beschreibung |
|---|---|
| Bezeichnung | Leistungsüberwachung und Fehlerdiagnose |
| Verantwortlicher | QR Branding |
| Zweck | Zuverlässigkeit des Dienstes sichern, Fehler diagnostizieren und Leistung überwachen |
| Rechtsgrundlage | Berechtigtes Interesse – Art. 6(1)(f) |
| Berechtigtes Interesse | Betriebsstabilität und schnelle Reaktion auf Vorfälle sicherstellen |
| Kategorien betroffener Personen | Alle API-Nutzer |
| Datenkategorien | Anfragepfade (ohne QR-Inhalt), HTTP-Statuscodes, Antwortzeiten, Fehler (ohne personenbezogene Daten), Leistungsmetriken |
| Empfänger | Microsoft (Azure Application Insights) als Auftragsverarbeiter |
| Internationale Übermittlungen | Möglich, je nach konfigurierter Region von Application Insights |
| Löschfristen | 90 Tage (Standardeinstellung von Application Insights) |
| Sicherheitsmaßnahmen | Fehlermeldungen ohne personenbezogene Daten, Schwärzung von API-Schlüsseln (SanitizeForLog), IP-Anonymisierung, keine Protokollierung von QR-Inhalten oder KI-Prompts |
Tätigkeit 5: API-Authentifizierung
| Feld | Beschreibung |
|---|---|
| Bezeichnung | Prüfung der RapidAPI-Authentifizierung |
| Verantwortlicher | QR Branding (Middleware), RapidAPI (Plattform) |
| Zweck | Prüfen, dass Anfragen vom autorisierten RapidAPI-Proxy stammen |
| Rechtsgrundlage | Berechtigtes Interesse – Art. 6(1)(f) |
| Kategorien betroffener Personen | Alle API-Nutzer |
| Datenkategorien | Header X-RapidAPI-Proxy-Secret (ein Server-Geheimnis, keine personenbezogenen Daten) |
| Empfänger | Keine |
| Internationale Übermittlungen | Nein |
| Löschfristen | Nicht anwendbar: Das Geheimnis wird im Arbeitsspeicher geprüft und nicht gespeichert |
| Sicherheitsmaßnahmen | Vergleich in der Middleware, Geheimnis in den Azure App Settings gespeichert (verschlüsselt), nie in Logs oder Antworten offengelegt |
Übersicht der Auftragsverarbeiter
| Auftragsverarbeiter | Tätigkeit | AVV | Standort |
|---|---|---|---|
| Microsoft Azure | Hosting, Application Insights | ✅ Standard-OST/AVV | EU/USA (konfigurierbar) |
| RapidAPI | Marketplace, Abrechnung, Authentifizierung | ✅ Plattformbedingungen | USA |
| Groq | KI-Generierung mit den Konten von QR Branding (Tätigkeit 2A) | ⚠️ Datenverarbeitungsbedingungen des Anbieters, Bestätigung ausstehend | USA |
| Google (Gemini) | KI-Generierung mit den Konten von QR Branding (Tätigkeit 2A) | ⚠️ Datenverarbeitungsbedingungen des Anbieters, Bestätigung ausstehend | USA |
| OpenAI | KI-Generierung mit den Konten von QR Branding (Tätigkeit 2A) | ⚠️ Datenverarbeitungsbedingungen des Anbieters, Bestätigung ausstehend | USA |
Hinweis zu LLM-Anbietern: Groq, Google (Gemini) und OpenAI sind nur bei der KI-Generierung mit den eigenen Konten von QR Branding (Tätigkeit 2A) Auftragsverarbeiter von QR Branding. Beim BYOK-Endpunkt (Tätigkeit 2B) ist kein LLM-Anbieter Auftragsverarbeiter von QR Branding: Der Kunde liefert seinen eigenen API-Schlüssel, und das Vertragsverhältnis und der AVV mit dem von ihm gewählten Anbieter liegen in der unmittelbaren Verantwortung des Kunden.
Dokument erstellt am 2026-03-08. Bei jeder Änderung einer Verarbeitungstätigkeit aktualisieren.