Evaluación de impacto relativa a la protección de datos (DPIA)
QR Branding API — Funciones de IA
| Campo | Valor |
|---|---|
| Fecha | 2026-03-08 |
| Responsable | QR Branding (Quartzon) |
| Versión | 1.0 |
| Estado | Aprobada |
| Próxima revisión | 2026-09-08 |
1. Descripción del tratamiento
1.1 Naturaleza del tratamiento
QR Branding ofrece la generación de códigos QR con IA en dos modalidades:
- Con las cuentas propias de QR Branding en los proveedores LLM: el diseñador con IA de qr-branding.com y el endpoint gestionado del marketplace (
POST /api/qr/ai/generate-managed). Cada petición la atiende una cadena interna de proveedores de respaldo (Groq, Google Gemini, OpenAI). - Con la clave propia del cliente (BYOK): el endpoint del marketplace
POST /api/qr/ai/generate. El cliente aporta su propia clave de API y elige el proveedor (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek o Qwen, o su propio endpoint compatible con OpenAI).
En ambas modalidades el usuario envía un prompt de diseño en lenguaje natural (por ejemplo: «código QR moderno azul para una empresa tecnológica») junto con el contenido QR (URL, texto, vCard, etc.). El sistema:
- Envía únicamente el prompt de diseño y los parámetros de generación a un proveedor LLM externo: el que atiende la petición en la cadena de respaldo de QR Branding o el que elige el usuario (BYOK).
- Recibe del LLM una configuración de diseño en JSON.
- Genera el código QR con el contenido aportado y el diseño sugerido.
- Devuelve la imagen QR al usuario.
1.2 Alcance
- Datos tratados: prompts de diseño (texto libre), parámetros de generación (estilo predefinido, creatividad, escaneabilidad estricta), contenido QR (URL, texto, datos de contacto vCard, credenciales WiFi, geolocalización), clave de API del cliente (solo BYOK, transitoria).
- Volumen estimado: hasta 15 peticiones de IA por minuto e IP y 100 generaciones por minuto en total.
- Interesados afectados: usuarios del sitio qr-branding.com, usuarios de la API (desarrolladores, empresas) e, indirectamente, las personas cuyos datos aparecen en el contenido QR (contactos de vCard).
- Ámbito geográfico: global (API pública en RapidAPI Marketplace).
1.3 Contexto
- Servicio sin estado (stateless): no hay base de datos y no se persiste el contenido QR.
- Cuentas propias de QR Branding (sitio y endpoint gestionado): QR Branding tiene claves de API propias con Groq, Google (Gemini) y OpenAI, que actúan como sus encargados del tratamiento y figuran en la página de subencargados. No se les envía ningún email, dato de facturación, dirección IP ni identificador del cliente.
- Modelo BYOK (Bring Your Own Key) (
POST /api/qr/ai/generate): el cliente aporta su propia clave de API en cada petición; QR Branding no usa sus cuentas propias para estas peticiones. - El contenido QR nunca se envía a los proveedores de IA; solo el prompt de diseño.
- Los campos sensibles que genera el LLM (URL, base64) se anulan antes del renderizado.
- El servicio funciona en Azure Functions (Consumption Plan).
- En el endpoint BYOK, la relación contractual con el proveedor LLM es directa entre el cliente y el proveedor.
1.4 Finalidad
Permitir a los usuarios generar diseños de QR personalizados a partir de descripciones en lenguaje natural, sin tener que configurar los parámetros a mano.
2. Necesidad y proporcionalidad
2.1 Base legal
Ejecución de un contrato (Art. 6(1)(b) RGPD): el tratamiento es necesario para prestar el servicio concreto que solicita el usuario.
2.2 Minimización de datos
| Principio | Implementación |
|---|---|
| Solo los datos necesarios | Al LLM solo se envía el prompt, no el contenido QR |
| Sin almacenamiento | Procesamiento en memoria; el texto del prompt y el contenido QR se descartan tras la respuesta HTTP. Solo la configuración de diseño generada puede guardarse en caché hasta 30 días, bajo una clave derivada de un hash SHA-256 del prompt y los parámetros |
| Sin elaboración de perfiles | No se crean perfiles de usuario ni historiales de peticiones |
| Anonimización | IP anonimizadas en los logs (último octeto enmascarado) |
| Segregación | Contenido QR y prompt de IA separados en el flujo de datos |
2.3 Proporcionalidad
El tratamiento es proporcionado porque:
- El usuario elige activamente usar la función de IA (endpoint independiente).
- En el endpoint BYOK el usuario selecciona el proveedor LLM; en el sitio y en el endpoint gestionado el proveedor es uno de los encargados que figuran en la página de subencargados.
- Solo se transfiere el prompt de diseño (no los datos personales del contenido QR).
- No existe una alternativa menos intrusiva para generar diseños a partir de lenguaje natural.
3. Identificación y evaluación de riesgos
3.1 Riesgos identificados
| # | Riesgo | Probabilidad | Impacto | Nivel | Mitigación |
|---|---|---|---|---|---|
| R1 | Inyección de prompt: el usuario inyecta instrucciones maliciosas en el prompt | Media | Medio | Medio | Delimitadores <user_request>, instrucciones contra fugas en el prompt de sistema, campos URL/base64 anulados tras el LLM |
| R2 | PII en los prompts: el usuario incluye datos personales en la descripción del diseño | Media | Bajo | Bajo | No almacenamos el texto de los prompts (la caché guarda solo el diseño generado bajo una clave derivada de un hash); el prompt se envía sin ningún identificador del usuario; política de uso documentada |
| R3 | Exfiltración del prompt de sistema: un atacante extrae las instrucciones del sistema | Baja | Bajo | Bajo | Pie contra fugas en el prompt de sistema, salida saneada (etiquetas HTML eliminadas) |
| R4 | Transferencia internacional: prompts reenviados a proveedores de fuera del EEE | Media | Bajo | Bajo | Cuentas de QR Branding: Groq, Google y OpenAI (EE. UU.) actúan como encargados conforme a las condiciones de tratamiento de datos de cada proveedor; solo se envían el prompt de diseño y los parámetros. BYOK: el cliente tiene una relación directa con el proveedor y su propio DPA; QR Branding solo actúa como intermediario técnico. Información en la Política de Privacidad y en la página de subencargados |
| R5 | Conservación por el proveedor LLM: el proveedor conserva datos según sus políticas | Media | Bajo | Bajo | Cuentas de QR Branding: se rige por las condiciones de tratamiento de datos de cada proveedor con QR Branding. BYOK: responsabilidad del cliente según sus propias condiciones con el proveedor |
| R6 | Respuesta del LLM con contenido malicioso: XSS, URL maliciosas | Media | Medio | Medio | Regex de saneamiento de HTML con timeout, campos URL/base64 anulados, MaxDepth=32 en la deserialización |
| R7 | Denegación de cartera: abuso del endpoint de IA para generar costes | Media | Alto | Alto | Límite de peticiones (15 de IA/min por IP, 100/min en total), RenderThrottle con semáforo, functionTimeout 1:30 |
| R8 | Fuga de claves de API en los logs | Baja | Alto | Medio | SanitizeForLog() oculta los patrones de claves de API, mensajes de error sin PII |
3.2 Mapa del flujo de datos
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. Medidas de mitigación
4.1 Medidas técnicas implantadas
| Medida | Riesgo mitigado | Estado |
|---|---|---|
Delimitadores de prompt (<user_request>) | R1 | ✅ Implantada |
| Pie contra fugas en el prompt de sistema | R1, R3 | ✅ Implantada |
| Anulación de los campos URL/base64 del LLM | R1, R6 | ✅ Implantada |
| Saneamiento de HTML por regex con timeout (3s) | R6 | ✅ Implantada |
| MaxDepth=32 en JsonSerializer | R6 | ✅ Implantada |
| Límite de peticiones de IA (15/min por IP, 100/min en total) | R7 | ✅ Implantada |
| RenderThrottle (semáforo de 4 concurrentes) | R7 | ✅ Implantada |
| functionTimeout 1:30 | R7 | ✅ Implantada |
| SanitizeForLog(): ocultación de claves de API | R8 | ✅ Implantada |
| Anonimización de IP (último octeto) | R2 | ✅ Implantada |
| Mensajes de error sin PII | R2 | ✅ Implantada |
| Límite de tokens de salida en todas las llamadas al LLM | R7 | ✅ Implantada |
| Content-Length + comprobación de tamaño tras la lectura (1MB) | R7 | ✅ Implantada |
| Separación con systemInstruction de Google | R1 | ✅ Implantada |
4.2 Medidas organizativas
| Medida | Riesgo mitigado | Estado |
|---|---|---|
| Política de Privacidad publicada | R4, R5 | ✅ Implantada |
| Información sobre los proveedores LLM en la documentación y en la página de subencargados | R4 | ✅ Implantada |
| DPA con los proveedores LLM que se usan con las cuentas de QR Branding (Groq, Google, OpenAI) | R4, R5 | ⚠️ Pendiente de confirmar |
| DPA con el proveedor LLM en el endpoint BYOK | R5 | Responsabilidad del cliente |
| Procedimiento de DSR documentado | General | ✅ Documentado |
| Plan de respuesta a incidentes | General | ✅ Documentado |
5. Conclusión
5.1 Riesgo residual
Una vez implantadas todas las medidas técnicas y organizativas, el riesgo residual se evalúa como BAJO:
- El tratamiento es sin estado: no se persisten ni el contenido QR ni el texto del prompt (la caché de prompts guarda solo diseños generados bajo una clave derivada de un hash).
- El contenido QR (potencialmente sensible) nunca sale de la infraestructura de Azure.
- Solo los prompts de diseño (que rara vez contienen PII) se transfieren a terceros.
- Todas las mitigaciones técnicas de la auditoría general (mega-audit) están implantadas y verificadas.
5.2 Decisión
✅ El tratamiento puede seguir adelante con las medidas actuales.
No es necesaria la consulta previa a la autoridad de control (Art. 36 RGPD), ya que el riesgo residual es bajo.
5.3 Revisión
Esta DPIA se revisará:
- Como mínimo, cada 6 meses.
- Cuando se añadan nuevos proveedores LLM.
- Cuando cambie el flujo de datos del endpoint de IA.
- Cuando se incorporen nuevos tipos de contenido QR que puedan contener datos sensibles.
Documento generado el 2026-03-08. Próxima revisión programada: 2026-09-08.