Análisis de base legal para el tratamiento de datos
QR Branding API — RGPD Art. 6
| Campo | Valor |
|---|---|
| Responsable | QR Branding (Quartzon) |
| Fecha | 2026-03-08 |
| Versión | 1.0 |
1. Principio de licitud (Art. 6)
Todo tratamiento de datos personales debe estar amparado por al menos una de las bases legales del Art. 6(1) RGPD. A continuación se analiza cada actividad de tratamiento de QR Branding y su base legal correspondiente.
2. Análisis por actividad de tratamiento
2.1 Generación de códigos QR con datos personales
| Aspecto | Análisis |
|---|---|
| Actividad | El usuario envía contenido QR que puede incluir datos personales (vCard con nombre, email, teléfono, dirección; geolocalización; direcciones de email) |
| Base legal | Art. 6(1)(b) — Ejecución de un contrato |
| Justificación | El tratamiento es necesario para prestar el servicio contratado por el usuario a través de RapidAPI. Sin procesar el contenido, no es posible generar el código QR solicitado |
| Proporcionalidad | Mínima: solo se procesa el contenido estrictamente necesario, en memoria y sin almacenamiento |
| Alternativa menos intrusiva | No existe: el contenido QR ES el dato que hay que codificar |
2.2 Generación de QR con IA
La generación con IA funciona en dos modalidades:
- Cuentas propias de QR Branding (el diseñador con IA de qr-branding.com y el endpoint gestionado
POST /api/qr/ai/generate-managed): QR Branding envía el prompt de diseño, con sus propias claves de API, a un proveedor LLM de su cadena interna de respaldo (Groq, Google Gemini, OpenAI). Estos proveedores actúan como encargados del tratamiento de QR Branding y figuran en la página de subencargados. - BYOK (Bring Your Own Key) (el endpoint
POST /api/qr/ai/generate): el cliente aporta su propia clave de API y elige el proveedor; QR Branding no usa sus cuentas propias para estas peticiones.
| Aspecto | Análisis |
|---|---|
| Actividad | El usuario envía un prompt de diseño. QR Branding reenvía el prompt a un proveedor LLM: con sus propias claves (sitio y endpoint gestionado) o con la clave del cliente (llmApiKey, endpoint BYOK) |
| Modelo | Cuentas propias de QR Branding con Groq, Google (Gemini) y OpenAI, o BYOK (Bring Your Own Key) con el proveedor que elige el cliente |
| Base legal | Art. 6(1)(b) — Ejecución de un contrato |
| Justificación | El usuario solicita explícitamente la generación del diseño con IA: en el sitio y en el endpoint gestionado, al lanzar una generación con IA; en el endpoint BYOK, además, al elegir el proveedor y aportar su propia clave de API. El tratamiento es necesario para ejecutar esa solicitud concreta |
| Proporcionalidad | Solo el prompt de diseño y los parámetros de generación se envían al LLM. El contenido QR, las IP y los datos de identificación NUNCA se transmiten. En el endpoint BYOK, la clave de API del cliente no se almacena ni se registra en logs |
| Nota | El usuario elige activamente usar la generación con IA y el prompt que envía. En el endpoint BYOK elige además el proveedor LLM y aporta su propia clave de API, y la relación con el proveedor LLM es directa entre el cliente y el proveedor |
2.3 Límite de peticiones (rate limiting)
| Aspecto | Análisis |
|---|---|
| Actividad | Recuento de peticiones por identificador (usuario de RapidAPI, ID de suscripción, IP anonimizada) para limitar la tasa de uso |
| Base legal | Art. 6(1)(f) — Interés legítimo |
| Interés legítimo | Proteger la disponibilidad del servicio para todos los usuarios y prevenir abusos y costes excesivos |
| Test de ponderación | |
| — Interés del responsable | Alto: sin límite de peticiones, un solo usuario podría agotar los recursos o generar costes prohibitivos |
| — Impacto en el interesado | Mínimo: solo se usa un identificador seudónimo para contar peticiones, los datos están en memoria volátil (2 min) y las IP se anonimizan |
| — Expectativa razonable | Sí: los usuarios de API esperan un límite de peticiones como práctica estándar del sector |
| — Salvaguardas | Datos efímeros (2 min), anonimización de IP, límite de seguimiento (50K IP), sin registro de identificadores |
| Resultado | El interés legítimo prevalece claramente, dado el impacto mínimo en el interesado |
2.4 Telemetría y diagnóstico (Application Insights)
| Aspecto | Análisis |
|---|---|
| Actividad | Recopilación de métricas de rendimiento, errores y metadatos de peticiones (sin datos personales identificables, PII) |
| Base legal | Art. 6(1)(f) — Interés legítimo |
| Interés legítimo | Mantener la fiabilidad y la disponibilidad del servicio y diagnosticar problemas con rapidez |
| Test de ponderación | |
| — Interés del responsable | Alto: sin telemetría no es posible detectar ni resolver incidencias |
| — Impacto en el interesado | Mínimo: PII eliminada de los mensajes de error, claves de API ocultadas, IP anonimizadas |
| — Expectativa razonable | Sí: la monitorización es una práctica estándar en los servicios en la nube |
| — Salvaguardas | Retención de 90 días, logs sin PII, anonimización de IP, ocultación de claves de API |
| Resultado | El interés legítimo prevalece claramente |
2.5 Autenticación de RapidAPI
| Aspecto | Análisis |
|---|---|
| Actividad | Verificación de la cabecera X-RapidAPI-Proxy-Secret en cada petición |
| Base legal | Art. 6(1)(f) — Interés legítimo |
| Justificación | Proteger el servicio frente a accesos no autorizados |
| Nota | El secreto es un dato del servidor, no del usuario. En este paso no se trata ningún dato personal |
3. Bases legales NO utilizadas
| Base legal | Art. | ¿Por qué no se usa? |
|---|---|---|
| Consentimiento | Art. 6(1)(a) | No se recaba consentimiento explícito. No es necesario: el tratamiento se ampara en el contrato y en el interés legítimo. Usar el consentimiento crearía obligaciones adicionales (revocabilidad) sin ningún beneficio |
| Obligación legal | Art. 6(1)(c) | No existe ninguna obligación legal que exija tratar estos datos |
| Intereses vitales | Art. 6(1)(d) | No aplica: el servicio no trata datos para proteger intereses vitales |
| Interés público | Art. 6(1)(e) | No aplica: es un servicio comercial privado |
4. Categorías especiales de datos (Art. 9)
QR Branding no solicita ni requiere categorías especiales de datos personales (origen étnico, salud, orientación sexual, etc.).
Sin embargo, el usuario podría incluir estos datos en el contenido QR (por ejemplo, un QR con datos médicos). En ese caso:
- QR Branding actúa como un procesador técnico que codifica los datos sin interpretarlos.
- La responsabilidad del tratamiento de las categorías especiales recae en el usuario que decide incluirlas.
- La base legal en este supuesto sería el consentimiento explícito del titular de los datos, que el usuario debe obtener antes de codificarlos.
- QR Branding no almacena estos datos y los descarta inmediatamente después de la generación.
5. Datos de menores (Art. 8)
- QR Branding es un servicio de API B2B/B2C dirigido a desarrolladores y empresas.
- No está dirigido a menores de 16 años.
- No se recopilan datos de edad ni se verifica la edad.
- Si un usuario incluye datos de menores en el contenido QR, la responsabilidad de obtener el consentimiento parental recae en el usuario.
6. Transferencias internacionales (Art. 44-49)
| Destino | Base legal de la transferencia | Proveedor |
|---|---|---|
| UE/EE. UU. (Azure) | Online Services Terms + CCT (SCC) | Microsoft Azure |
| EE. UU. | Términos de la plataforma | RapidAPI |
| EE. UU. | Condiciones de tratamiento de datos de cada proveedor (ver la página de subencargados) | Groq, Google (Gemini), OpenAI: generación con IA con las cuentas de QR Branding |
Nota sobre los proveedores LLM: con las cuentas propias de QR Branding (el sitio y el endpoint gestionado), los prompts de diseño se transfieren a Groq, Google (Gemini) u OpenAI, que actúan como encargados del tratamiento de QR Branding. En el endpoint BYOK, los prompts se transfieren al proveedor que elige el cliente (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek o Qwen, o su propio endpoint compatible con OpenAI) con la clave de API del propio cliente. La responsabilidad de esa transferencia recae en el cliente, que mantiene una relación contractual directa con el proveedor; QR Branding actúa como intermediario técnico.
El uso del endpoint estándar de generación de QR no implica ninguna transferencia a proveedores LLM (el procesamiento se realiza exclusivamente en Azure).
7. Revisión
Este análisis de base legal debe revisarse:
- Cuando se añadan nuevas actividades de tratamiento
- Cuando cambien los datos tratados por las actividades existentes
- Cuando cambien las políticas de los proveedores LLM
- Al menos una vez al año
Documento generado el 2026-03-08.