Registro de actividades de tratamiento (ROPA)
QR Branding API — RGPD Art. 30
| Campo | Valor |
|---|---|
| Responsable | QR Branding (Quartzon) |
| Fecha | 2026-03-08 |
| Versión | 1.0 |
Actividad 1: Generación de códigos QR
| Campo | Descripción |
|---|---|
| Nombre | Generación de códigos QR personalizados |
| Responsable | QR Branding |
| Finalidad | Generar imágenes QR (PNG/SVG/PDF/Base64) a partir del contenido y la configuración que aporta el usuario |
| Base legal | Ejecución de un contrato — Art. 6(1)(b) |
| Categorías de interesados | Usuarios de la API (desarrolladores, empresas) y contactos incluidos en vCards |
| Categorías de datos | URL, texto libre, credenciales WiFi (SSID/contraseña), datos de contacto vCard (nombre, email, teléfono, dirección, organización), geolocalización, direcciones de email, números de teléfono |
| Destinatarios | Ninguno: procesamiento exclusivamente interno; el resultado se devuelve al usuario |
| Transferencias internacionales | No: procesamiento en Azure (región del host) |
| Plazos de supresión | Inmediato: los datos se procesan en memoria y se descartan tras la respuesta HTTP |
| Medidas de seguridad | TLS 1.2+, validación de entradas (OWASP), protección frente a SSRF, eliminación de metadatos EXIF, límite de peticiones, autenticación de RapidAPI, anonimización de IP en los logs |
Actividad 2A: Generación de QR con IA con las cuentas de QR Branding en los proveedores
| Campo | Descripción |
|---|---|
| Nombre | Generación del diseño QR mediante inteligencia artificial, con las cuentas propias de QR Branding en los proveedores LLM |
| Ámbito | El diseñador con IA de qr-branding.com y el endpoint gestionado del marketplace (POST /api/qr/ai/generate-managed) |
| Responsable | QR Branding |
| Finalidad | Generar la configuración de diseño del QR a partir de un prompt en lenguaje natural |
| Base legal | Ejecución de un contrato — Art. 6(1)(b) |
| Modelo de claves de API | Claves de API propias de QR Branding. Cada petición pasa por una cadena interna de proveedores de respaldo (Groq, Google Gemini, OpenAI): si un proveedor falla, se prueba el siguiente |
| Categorías de interesados | Usuarios del sitio qr-branding.com y usuarios de la API |
| Categorías de datos | Prompt de diseño (texto libre) y parámetros de generación (estilo predefinido, creatividad, escaneabilidad estricta). El contenido QR no se envía al LLM |
| Destinatarios | El proveedor LLM que atiende la petición en la cadena de respaldo |
| Encargados del tratamiento | Groq, Inc., Google LLC (Gemini) y OpenAI, OpCo, LLC, según la página de subencargados |
| Transferencias internacionales | Sí: los tres proveedores están en EE. UU. La transferencia se ampara en las condiciones de tratamiento de datos de cada proveedor, según la página de subencargados |
| Plazos de supresión | El texto del prompt se procesa en memoria y QR Branding no lo almacena. La configuración de diseño generada puede guardarse en la caché de prompts hasta 30 días, bajo una clave derivada de un hash SHA-256 del prompt y los parámetros. La conservación por el proveedor se rige por sus propias condiciones |
| Medidas de seguridad | Delimitadores de prompt, instrucciones contra fugas, anulación de campos URL/base64, saneamiento de HTML, límite de tokens de salida en todas las llamadas al LLM, límites de tamaño de respuesta (1MB), ocultación de claves de API en los logs (SanitizeForLog). Al proveedor no se envía ningún email, dato de facturación, dirección IP ni identificador del cliente |
Actividad 2B: Generación de QR con IA con la clave propia del cliente (BYOK)
| Campo | Descripción |
|---|---|
| Nombre | Generación del diseño QR mediante inteligencia artificial, con la clave de API LLM propia del cliente |
| Ámbito | El endpoint del marketplace POST /api/qr/ai/generate |
| Responsable | QR Branding (procesamiento del prompt y renderizado) |
| Finalidad | Generar la configuración de diseño del QR a partir de un prompt en lenguaje natural |
| Base legal | Ejecución de un contrato — Art. 6(1)(b) |
| Modelo de claves de API | BYOK (Bring Your Own Key): el cliente aporta en cada petición su propia clave de API del proveedor LLM (llmApiKey) y elige el proveedor: OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek o Qwen, o su propio endpoint compatible con OpenAI (local) |
| Categorías de interesados | Usuarios de la API |
| Categorías de datos | Prompt de diseño (texto libre), clave de API del cliente (transitoria, no almacenada), contenido QR (no se envía al LLM) |
| Destinatarios | El proveedor LLM (o el endpoint propio del cliente) que elige el usuario, usando la clave de API del propio usuario |
| Encargados del tratamiento | Ninguno para esta actividad: QR Branding actúa como intermediario técnico. La relación contractual con el proveedor LLM es directa entre el cliente y el proveedor |
| Transferencias internacionales | La transferencia de datos al proveedor LLM es responsabilidad del cliente, que mantiene su propia relación contractual con el proveedor. QR Branding solo reenvía el prompt a nivel técnico |
| Plazos de supresión | El texto del prompt se procesa en memoria y no se almacena. La configuración de diseño generada puede guardarse en la caché de prompts hasta 30 días, bajo una clave derivada de un hash SHA-256 del prompt y los parámetros. La clave de API del cliente no se almacena ni se registra en logs |
| Medidas de seguridad | Delimitadores de prompt, instrucciones contra fugas, anulación de campos URL/base64, saneamiento de HTML, límite de tokens de salida en todas las llamadas al LLM, límites de tamaño de respuesta (1MB), ocultación de claves de API en los logs (SanitizeForLog) |
Actividad 3: Límite de peticiones y prevención de abusos
| Campo | Descripción |
|---|---|
| Nombre | Control de la tasa de peticiones |
| Responsable | QR Branding |
| Finalidad | Prevenir abusos y proteger la disponibilidad del servicio y los costes operativos |
| Base legal | Interés legítimo — Art. 6(1)(f) |
| Interés legítimo | Protección de la infraestructura y de la disponibilidad del servicio para todos los usuarios |
| Categorías de interesados | Todos los usuarios de la API |
| Categorías de datos | Identificador de RapidAPI (seudónimo), identificador de suscripción, dirección IP (anonimizada) |
| Destinatarios | Ninguno: procesamiento interno |
| Transferencias internacionales | No |
| Plazos de supresión | 2 minutos (ventana deslizante en memoria con expulsión automática) |
| Medidas de seguridad | Datos en memoria volátil (no persistidos), anonimización de IP (último octeto), límite de 50.000 IP en seguimiento, limpieza periódica cada 2 minutos |
Actividad 4: Telemetría y diagnóstico
| Campo | Descripción |
|---|---|
| Nombre | Monitorización del rendimiento y diagnóstico de errores |
| Responsable | QR Branding |
| Finalidad | Mantener la fiabilidad del servicio, diagnosticar errores y monitorizar el rendimiento |
| Base legal | Interés legítimo — Art. 6(1)(f) |
| Interés legítimo | Garantizar la estabilidad operativa y una respuesta rápida ante incidencias |
| Categorías de interesados | Todos los usuarios de la API |
| Categorías de datos | Rutas de las peticiones (sin contenido QR), códigos HTTP, tiempos de respuesta, errores (sin PII), métricas de rendimiento |
| Destinatarios | Microsoft (Azure Application Insights) como encargado del tratamiento |
| Transferencias internacionales | Posibles, según la región de Application Insights configurada |
| Plazos de supresión | 90 días (configuración por defecto de Application Insights) |
| Medidas de seguridad | Mensajes de error sin PII, ocultación de claves de API (SanitizeForLog), anonimización de IP, sin registro del contenido QR ni de los prompts de IA |
Actividad 5: Autenticación de la API
| Campo | Descripción |
|---|---|
| Nombre | Verificación de la autenticación de RapidAPI |
| Responsable | QR Branding (middleware), RapidAPI (plataforma) |
| Finalidad | Validar que las peticiones proceden del proxy autorizado de RapidAPI |
| Base legal | Interés legítimo — Art. 6(1)(f) |
| Categorías de interesados | Todos los usuarios de la API |
| Categorías de datos | Cabecera X-RapidAPI-Proxy-Secret (secreto del servidor, no es un dato personal) |
| Destinatarios | Ninguno |
| Transferencias internacionales | No |
| Plazos de supresión | No aplica: el secreto se verifica en memoria y no se almacena |
| Medidas de seguridad | Comparación en el middleware, secreto guardado en Azure App Settings (cifrado), no se expone en logs ni en respuestas |
Resumen de encargados del tratamiento
| Encargado | Actividad | DPA | Ubicación |
|---|---|---|---|
| Microsoft Azure | Alojamiento, Application Insights | ✅ OST/DPA estándar | UE/EE. UU. (configurable) |
| RapidAPI | Marketplace, facturación, autenticación | ✅ Términos de la plataforma | EE. UU. |
| Groq | Generación con IA con las cuentas de QR Branding (Actividad 2A) | ⚠️ Condiciones de tratamiento de datos del proveedor, pendiente de confirmar | EE. UU. |
| Google (Gemini) | Generación con IA con las cuentas de QR Branding (Actividad 2A) | ⚠️ Condiciones de tratamiento de datos del proveedor, pendiente de confirmar | EE. UU. |
| OpenAI | Generación con IA con las cuentas de QR Branding (Actividad 2A) | ⚠️ Condiciones de tratamiento de datos del proveedor, pendiente de confirmar | EE. UU. |
Nota sobre los proveedores LLM: Groq, Google (Gemini) y OpenAI son encargados del tratamiento de QR Branding solo en la generación con IA con las cuentas propias de QR Branding (Actividad 2A). En el endpoint BYOK (Actividad 2B) ningún proveedor LLM es encargado de QR Branding: el cliente aporta su propia clave de API, y la relación contractual y el DPA con el proveedor que elija son responsabilidad directa del cliente.
Documento generado el 2026-03-08. Actualizar ante cualquier cambio en los tratamientos.