Implementa los requisitos del RGPD en el desarrollo de software desde el equipo de producto y tecnología con los principios de privacy by design, la gestión del consentimiento, el registro de actividades de tratamiento y las medidas de seguridad técnica que exige la regulación.
Cuándo usarlo: RGPD desarrollo software, privacy by design, protección datos producto, RAT RGPD, consentimiento RGPD
Herramienta recomendada: Claude
Actúa como un Data Privacy Engineer con experiencia implementando los requisitos del RGPD en equipos de producto y tecnología donde la protección de datos no es solo una obligación legal sino una ventaja competitiva ante clientes enterprise que auditan a sus proveedores. Contexto: - Tipo de datos personales que maneja tu producto: [email + nombre / datos de comportamiento / datos financieros / datos de salud / datos de menores] - Tipo de usuarios: [consumidores / empresas (B2B) / empleados internos] - Estado actual del cumplimiento: [sin proceso / cumplimiento básico / queremos profundizar / auditoría próxima] ## RGPD para Equipos de Producto y Tecnología — [Empresa] ### 🧠 Los 7 principios del RGPD que afectan al diseño del producto **Principio 1 — Licitud, lealtad y transparencia:** ``` Debes tener una base legal para cada tratamiento de datos personales. Las 6 bases legales del RGPD: 1. Consentimiento del interesado (la más usada en apps de consumo) 2. Ejecución de un contrato (cuando procesas datos para prestar el servicio contratado) 3. Cumplimiento de una obligación legal (facturas, retenciones fiscales) 4. Interés vital (emergencias médicas) 5. Interés público (organismos públicos) 6. Interés legítimo (el más flexible, pero requiere una evaluación de intereses en juego) IMPORTANTE: no uses el consentimiento como base legal cuando puedes usar "ejecución de contrato". El consentimiento es la base más débil (el usuario puede retirarlo en cualquier momento). ``` **Principio 2 — Limitación de finalidad:** ``` Los datos recogidos para una finalidad no pueden usarse para otra. Si recoges el email para enviar la factura, no puedes usarlo para marketing sin base legal adicional. Implicación en el diseño del producto: cada tratamiento necesita documentar su finalidad. ``` **Principio 3 — Minimización de datos:** ``` Solo recoge los datos estrictamente necesarios para la finalidad declarada. El campo de formulario que añades "porque puede ser útil en el futuro" es una violación del principio. Revisión periódica: ¿sigues usando todos los datos que recogiste? Si no → borra los que ya no necesitas. ``` **Principio 4 — Exactitud:** ``` Los datos deben estar actualizados. Necesitas un proceso para que los usuarios puedan corregir sus datos. ``` **Principio 5 — Limitación del plazo de conservación:** ``` No puedes guardar datos personales indefinidamente. Para cada tipo de dato, define un plazo de retención: → Datos de clientes activos: mientras dure la relación + los plazos legales de conservación (ej: facturas, 6 años en España por obligación fiscal). → Datos de usuarios que se dieron de baja: eliminación o anonimización en 30-90 días (salvo obligación legal). → Logs del sistema con datos personales: máximo 12-24 meses. ``` **Principio 6 — Integridad y confidencialidad (seguridad):** ``` Medidas técnicas que el RGPD considera adecuadas para la mayoría de sistemas: → Cifrado en tránsito (HTTPS/TLS) y en reposo (para datos sensibles) → Control de acceso mínimo privilegio (solo puede acceder a los datos quien lo necesita para su función) → Gestión de contraseñas: hashing con bcrypt/argon2 — NUNCA texto plano → Logs de acceso a datos sensibles (quién accedió a qué y cuándo) → Plan de respuesta a brechas de seguridad (el RGPD exige notificar en 72 horas) ``` **Principio 7 — Responsabilidad proactiva (accountability):** ``` No basta con cumplir — debes poder demostrarlo. Los documentos que materializan el accountability: → Registro de actividades de tratamiento (RAT): el inventario de todos los tratamientos de datos personales. → Evaluaciones de impacto (EIPD/DPIA): obligatorias para tratamientos de alto riesgo. → Contratos con encargados del tratamiento (art. 28 RGPD): con todos tus proveedores que tratan datos en tu nombre. ``` ### 🛠️ Privacy by Design: cómo integrar la protección de datos en el proceso de desarrollo El checklist de privacidad para la revisión de nuevas features (preguntas que el equipo de producto debe responder antes de lanzar), el proceso de DPIA (evaluación de impacto) para features de alto riesgo y cómo documentar las decisiones de privacidad en el código y en los tickets.