Los ingenieros que buscan comprobaciones de revisión de código GDPR suelen querer una cosa: una lista breve de obligaciones legales que realmente pueden incumplirse en una pull request normal, no un manual completo de un programa de privacidad. El Reglamento se centra principalmente en procesos, registros y medidas organizativas. Sin embargo, un grupo minoritario de obligaciones sigue apareciendo en el código: qué datos se almacenan, cuánto tiempo se conservan, si una ruta de eliminación llega a todas las copias, qué exponen los valores predeterminados, cómo se protege el procesamiento y dónde se aloja el dato.
Esta guía es ese mapa. No es deliberadamente un tutorial sobre un único error de limitación de almacenamiento (que se encuentra en /guides/catching-a-gdpr-retention-bug-in-code-review) ni un análisis en profundidad de los controles (que están en /frameworks/gdpr). Es la lista de verificación para la revisión de código: qué artículos mencionar, cómo es la forma del cambio y qué puede preguntar un revisor sin convertirse en asesor legal.
Los artículos que suelen modificarse en un diff
Art. 5(1)(c) minimización de datos: un cambio comienza a recopilar o registrar más datos personales de los necesarios para el propósito (cuerpos completos de solicitudes, registros completos de identidad copiados en un almacenamiento secundario). Art. 5(1)(e) limitación del almacenamiento: un nuevo almacenamiento o caché de datos personales se implementa sin límite de retención, o se amplía una ventana de purga sin justificación. Art. 17 derecho al olvido: una ruta de eliminación no llega a una caché, índice de búsqueda, exportación de análisis o copia del procesador. Art. 25 protección de datos desde el diseño y por defecto: un campo personal se vuelve visible o compartido con todos los usuarios por defecto, o se desactiva una configuración protectora predeterminada. Art. 32 seguridad del procesamiento: se debilitan el cifrado, el control de acceso o las medidas de integridad de los datos personales (se reduce el mínimo de TLS, almacenamiento de tokens en texto plano, apertura de una ruta de administrador). Art. 44 capítulo sobre transferencias: los datos personales se mueven a una nueva región o procesador de tercer país sin la justificación de transferencia que espera tu programa.
Ejemplo práctico: protección de datos por defecto modificada por "comodidad de soporte"
Un equipo de soporte quiere una triaje de tickets más rápida. Un ingeniero abre una pull request que modifica la API de perfil de cliente para que todos los roles de personal autenticado reciban nombre_completo, correo, teléfono y los últimos cuatro dígitos de pago en el endpoint de lista predeterminado, no solo en una solicitud explícita "expand=pii". El cambio es pequeño: una bandera del serializador pasa de false a true. Las pruebas se actualizan para esperar la carga útil más completa. La revisión de código habla del tamaño de la respuesta y las cabeceras de caché. Nada parece un error de seguridad; la autenticación sigue funcionando.
Lo que cambió es el Art. 25 protección de datos desde el diseño y por defecto: los datos personales ahora se exponen por defecto a un conjunto más amplio de consumidores internos que la forma anterior de mínimo privilegio. La forma más segura mantiene el valor predeterminado estrecho y requiere una expansión explícita y auditada para las herramientas de soporte. Este es un modo de fallo diferente al error de retención (Art. 5(1)(e) en un nuevo almacenamiento sin purga) y al ejemplo puro de minimización en el registro (Art. 5(1)(c) en cuerpos de solicitudes). Una revisión consciente de cumplimiento cita el Art. 25 (y a menudo el Art. 5(1)(c) como principio de apoyo) en la PR mientras la bandera aún es fácil de revertir.
Qué preguntar en la revisión sin convertirse en un DPO
Para cualquier cambio que afecte a datos personales: qué campos son nuevos, quién puede verlos por defecto, cuánto tiempo existen y si una ruta de eliminación o exportación aún los alcanza. Para cambios de región o proveedor: adónde van los datos y si el equipo de privacidad ya tiene registrado ese procesador o transferencia. Para PRs de "limpieza": ¿eliminamos cifrado, comprobaciones de acceso o líneas de auditoría que protegían datos personales (relacionado con Art. 32).
No es necesario citar el Reglamento. Es necesario rechazar la fusión cuando la respuesta sea "desconocido" hasta que alguien asuma la responsabilidad del paso de privacidad o se restaure el valor predeterminado más seguro.
Dónde encaja heygrc y el límite de honestidad
heygrc está diseñado para analizar cada pull request frente a los marcos que hayas seleccionado, incluido el GDPR cuando esté activado, y para identificar el artículo que un cambio parece afectar (por ejemplo, Art. 25 en una carga útil predeterminada ampliada). No decide la base legal, ejecuta EIPD, mantiene el RoPA, aprueba transferencias ni reemplaza a tu DPO. Una revisión verde no es una aprobación supervisora.
Los revisores de errores y calidad siguen en la misma PR. Preguntan si el código es correcto. Las preguntas de GDPR preguntan si las obligaciones con los datos personales aún se cumplen. Ejecuta ambas.