Datenschutz-Folgenabschätzung (DSFA)
QR Branding API – KI-Funktionen
| Feld | Wert |
|---|---|
| Datum | 2026-03-08 |
| Verantwortlicher | QR Branding (Quartzon) |
| Version | 1.0 |
| Status | Genehmigt |
| Nächste Überprüfung | 2026-09-08 |
1. Beschreibung der Verarbeitung
1.1 Art der Verarbeitung
QR Branding bietet die KI-gestützte Erzeugung von QR-Codes in zwei Varianten:
- Mit den eigenen LLM-Anbieterkonten von QR Branding: der KI-Designer auf qr-branding.com und der verwaltete Marketplace-Endpunkt (
POST /api/qr/ai/generate-managed). Eine interne Fallback-Kette von Anbietern (Groq, Google Gemini, OpenAI) bedient jede Anfrage. - Mit dem eigenen Schlüssel des Kunden (BYOK): der Marketplace-Endpunkt
POST /api/qr/ai/generate. Der Kunde liefert seinen eigenen API-Schlüssel und wählt den Anbieter (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek oder Qwen oder einen eigenen OpenAI-kompatiblen Endpunkt).
In beiden Varianten sendet der Nutzer einen Design-Prompt in natürlicher Sprache (z. B. „moderner blauer QR-Code für ein Tech-Unternehmen“) zusammen mit dem QR-Inhalt (URL, Text, vCard usw.). Das System:
- Sendet nur den Design-Prompt und die Generierungsparameter an einen externen LLM-Anbieter: denjenigen, der die Anfrage in der Fallback-Kette von QR Branding bedient, oder den vom Nutzer gewählten (BYOK).
- Erhält vom LLM eine Design-Konfiguration als JSON.
- Erzeugt den QR-Code mit dem gelieferten Inhalt und dem vorgeschlagenen Design.
- Gibt das QR-Bild an den Nutzer zurück.
1.2 Umfang
- Verarbeitete Daten: Design-Prompts (Freitext), Generierungsparameter (Stilvorgabe, Kreativität, strikte Scanbarkeit), QR-Inhalte (URLs, Texte, vCard-Kontaktdaten, WLAN-Zugangsdaten, Geostandort), API-Schlüssel des Kunden (nur BYOK, flüchtig).
- Geschätztes Volumen: bis zu 15 KI-Anfragen pro Minute und IP, 100 Generierungen pro Minute insgesamt.
- Betroffene Personen: Nutzer der Website qr-branding.com, API-Nutzer (Entwickler, Unternehmen) und mittelbar die Personen, deren Daten im QR-Inhalt erscheinen (vCard-Kontakte).
- Geografischer Bereich: weltweit (öffentliche API im RapidAPI Marketplace).
1.3 Kontext
- Zustandsloser Dienst: Es gibt keine Datenbank, und QR-Inhalte werden nicht persistiert.
- Eigene Konten von QR Branding (Website und verwalteter Endpunkt): QR Branding hat eigene API-Schlüssel bei Groq, Google (Gemini) und OpenAI, die als seine Auftragsverarbeiter handeln und auf der Seite der Unterauftragsverarbeiter aufgeführt sind. An sie werden keine E-Mail-Adresse, keine Abrechnungsdaten, keine IP-Adresse und keine Kundenkennung gesendet.
- BYOK-Modell (Bring Your Own Key) (
POST /api/qr/ai/generate): Der Kunde liefert mit jeder Anfrage seinen eigenen API-Schlüssel; QR Branding nutzt für diese Anfragen keine eigenen Konten. - QR-Inhalte werden nie an KI-Anbieter gesendet, nur der Design-Prompt.
- Vom LLM erzeugte sensible Felder (URLs, base64) werden vor dem Rendering auf null gesetzt.
- Der Dienst läuft auf Azure Functions (Consumption Plan).
- Beim BYOK-Endpunkt besteht das Vertragsverhältnis mit dem LLM-Anbieter unmittelbar zwischen Kunde und Anbieter.
1.4 Zweck
Nutzern zu ermöglichen, individuelle QR-Designs aus Beschreibungen in natürlicher Sprache zu erzeugen, ohne Parameter von Hand konfigurieren zu müssen.
2. Notwendigkeit und Verhältnismäßigkeit
2.1 Rechtsgrundlage
Vertragserfüllung (Art. 6(1)(b) DSGVO): Die Verarbeitung ist erforderlich, um den konkreten, vom Nutzer angeforderten Dienst zu erbringen.
2.2 Datenminimierung
| Grundsatz | Umsetzung |
|---|---|
| Nur notwendige Daten | Nur der Prompt wird an das LLM gesendet, nicht der QR-Inhalt |
| Keine Speicherung | Verarbeitung im Arbeitsspeicher; Prompt-Text und QR-Inhalt werden nach der HTTP-Antwort verworfen. Nur die erzeugte Design-Konfiguration darf bis zu 30 Tage zwischengespeichert werden, unter einem Schlüssel, der aus einem SHA-256-Hash des Prompts und der Parameter abgeleitet ist |
| Kein Profiling | Es werden keine Nutzerprofile oder Anfrageverläufe angelegt |
| Anonymisierung | IP-Adressen in Logs anonymisiert (letztes Oktett maskiert) |
| Trennung | QR-Inhalt und KI-Prompt bleiben im Datenfluss getrennt |
2.3 Verhältnismäßigkeit
Die Verarbeitung ist verhältnismäßig, weil:
- Der Nutzer sich aktiv für die KI-Funktion entscheidet (eigener Endpunkt).
- Der Nutzer beim BYOK-Endpunkt den LLM-Anbieter wählt; auf der Website und beim verwalteten Endpunkt der Anbieter einer der auf der Seite der Unterauftragsverarbeiter aufgeführten Auftragsverarbeiter ist.
- Nur der Design-Prompt übermittelt wird (keine personenbezogenen Daten aus dem QR-Inhalt).
- Es keine weniger eingreifende Alternative gibt, um Designs aus natürlicher Sprache zu erzeugen.
3. Ermittlung und Bewertung der Risiken
3.1 Ermittelte Risiken
| # | Risiko | Wahrscheinlichkeit | Auswirkung | Stufe | Abhilfe |
|---|---|---|---|---|---|
| R1 | Prompt-Injection: Der Nutzer schleust bösartige Anweisungen in den Prompt ein | Mittel | Mittel | Mittel | Begrenzer <user_request>, Anweisungen gegen Datenabfluss im System-Prompt, URL-/base64-Felder nach dem LLM auf null gesetzt |
| R2 | Personenbezogene Daten in Prompts: Der Nutzer nimmt personenbezogene Daten in die Designbeschreibung auf | Mittel | Niedrig | Niedrig | Wir speichern den Prompt-Text nicht (der Cache hält nur das erzeugte Design unter einem aus einem Hash abgeleiteten Schlüssel); der Prompt wird ohne jede Kennung des Nutzers gesendet; dokumentierte Nutzungsrichtlinie |
| R3 | Abfluss des System-Prompts: Ein Angreifer extrahiert die Systemanweisungen | Niedrig | Niedrig | Niedrig | Abschluss gegen Datenabfluss im System-Prompt, bereinigte Ausgabe (HTML-Tags entfernt) |
| R4 | Internationale Übermittlung: Prompts werden an Anbieter außerhalb des EWR weitergeleitet | Mittel | Niedrig | Niedrig | Konten von QR Branding: Groq, Google und OpenAI (USA) handeln als Auftragsverarbeiter nach den Datenverarbeitungsbedingungen des jeweiligen Anbieters; gesendet werden nur der Design-Prompt und die Parameter. BYOK: Der Kunde hat ein unmittelbares Verhältnis zum Anbieter und einen eigenen AVV; QR Branding handelt nur als technischer Vermittler. Offenlegung in der Datenschutzerklärung und auf der Seite der Unterauftragsverarbeiter |
| R5 | Aufbewahrung beim LLM-Anbieter: Der Anbieter bewahrt Daten nach eigenen Richtlinien auf | Mittel | Niedrig | Niedrig | Konten von QR Branding: geregelt durch die Datenverarbeitungsbedingungen des jeweiligen Anbieters mit QR Branding. BYOK: Verantwortung des Kunden nach seinen eigenen Bedingungen mit dem Anbieter |
| R6 | LLM-Antwort mit bösartigem Inhalt: XSS, bösartige URLs | Mittel | Mittel | Mittel | Regex zur HTML-Bereinigung mit Timeout, URL-/base64-Felder auf null gesetzt, MaxDepth=32 bei der Deserialisierung |
| R7 | Denial of Wallet: Missbrauch des KI-Endpunkts, um Kosten in die Höhe zu treiben | Mittel | Hoch | Hoch | Rate-Limiting (15 KI/Min. pro IP, 100/Min. insgesamt), RenderThrottle mit Semaphor, functionTimeout 1:30 |
| R8 | Abfluss von API-Schlüsseln in Logs | Niedrig | Hoch | Mittel | SanitizeForLog() schwärzt Muster von API-Schlüsseln, Fehlermeldungen ohne personenbezogene Daten |
3.2 Übersicht des Datenflusses
User → qr-branding.com or RapidAPI Proxy → Azure Functions
↓
[Design prompt + parameters only]
↓
LLM provider (QR Branding's fallback chain,
or the user's choice on BYOK)
↓
[Design JSON config]
↓
QR Rendering (SkiaSharp)
+ QR content (never leaves the server)
↓
QR image → User
4. Abhilfemaßnahmen
4.1 Umgesetzte technische Maßnahmen
| Maßnahme | Gemindertes Risiko | Status |
|---|---|---|
Prompt-Begrenzer (<user_request>) | R1 | ✅ Umgesetzt |
| Abschluss gegen Datenabfluss im System-Prompt | R1, R3 | ✅ Umgesetzt |
| Nullsetzen der URL-/base64-Felder des LLM | R1, R6 | ✅ Umgesetzt |
| Regex zur HTML-Bereinigung mit Timeout (3s) | R6 | ✅ Umgesetzt |
| MaxDepth=32 im JsonSerializer | R6 | ✅ Umgesetzt |
| KI-Rate-Limiting (15/Min. pro IP, 100/Min. insgesamt) | R7 | ✅ Umgesetzt |
| RenderThrottle (Semaphor, 4 gleichzeitig) | R7 | ✅ Umgesetzt |
| functionTimeout 1:30 | R7 | ✅ Umgesetzt |
| SanitizeForLog(): Schwärzung von API-Schlüsseln | R8 | ✅ Umgesetzt |
| IP-Anonymisierung (letztes Oktett) | R2 | ✅ Umgesetzt |
| Fehlermeldungen ohne personenbezogene Daten | R2 | ✅ Umgesetzt |
| Obergrenze für Ausgabe-Tokens bei jedem LLM-Aufruf | R7 | ✅ Umgesetzt |
| Content-Length + Größenprüfung nach dem Lesen (1MB) | R7 | ✅ Umgesetzt |
| Trennung über Google systemInstruction | R1 | ✅ Umgesetzt |
4.2 Organisatorische Maßnahmen
| Maßnahme | Gemindertes Risiko | Status |
|---|---|---|
| Veröffentlichte Datenschutzerklärung | R4, R5 | ✅ Umgesetzt |
| Offenlegung der LLM-Anbieter in der Doku und auf der Seite der Unterauftragsverarbeiter | R4 | ✅ Umgesetzt |
| AVV mit den LLM-Anbietern, die mit den Konten von QR Branding genutzt werden (Groq, Google, OpenAI) | R4, R5 | ⚠️ Bestätigung ausstehend |
| AVV mit dem LLM-Anbieter beim BYOK-Endpunkt | R5 | Verantwortung des Kunden |
| Dokumentiertes Verfahren für Betroffenenrechte | Allgemein | ✅ Dokumentiert |
| Plan zur Reaktion auf Vorfälle | Allgemein | ✅ Dokumentiert |
5. Fazit
5.1 Restrisiko
Mit allen umgesetzten technischen und organisatorischen Maßnahmen wird das Restrisiko als NIEDRIG bewertet:
- Die Verarbeitung ist zustandslos: Weder QR-Inhalte noch Prompt-Texte werden persistiert (der Prompt-Cache hält nur erzeugte Designs unter einem aus einem Hash abgeleiteten Schlüssel).
- QR-Inhalte (potenziell sensibel) verlassen die Azure-Infrastruktur nie.
- Nur Design-Prompts (die selten personenbezogene Daten enthalten) werden an Dritte übermittelt.
- Alle technischen Abhilfemaßnahmen aus dem Mega-Audit sind umgesetzt und geprüft.
5.2 Entscheidung
✅ Die Verarbeitung darf mit den aktuellen Maßnahmen fortgeführt werden.
Eine vorherige Konsultation der Aufsichtsbehörde (Art. 36 DSGVO) ist nicht erforderlich, da das Restrisiko niedrig ist.
5.3 Überprüfung
Diese DSFA wird überprüft:
- Mindestens alle 6 Monate.
- Wenn neue LLM-Anbieter hinzukommen.
- Wenn sich der Datenfluss des KI-Endpunkts ändert.
- Wenn neue QR-Inhaltstypen eingeführt werden, die sensible Daten enthalten können.
Dokument erstellt am 2026-03-08. Nächste geplante Überprüfung: 2026-09-08.