Cuando aplica Privacy by Design y que hacer despues

Privacy by Design aplica cuando un equipo SaaS disena, cambia u opera un producto, workflow, proveedor, herramienta interna, pipeline de datos o proceso de cliente que trata datos personales. La respuesta practica no es frenar la entrega, sino decidir pronto que datos son necesarios, que defaults corresponden, quien accede, cuanto se conservan, que proveedores intervienen y que evidencia prueba la decision.

El articulo 25 del GDPR exige medidas tecnicas y organizativas adecuadas y proteccion de datos por defecto. Por defecto solo deben tratarse los datos personales necesarios para cada finalidad concreta. El EDPB lo plantea como una obligacion durante todo el ciclo de vida del tratamiento.

Regla rapida

Privacy by Design aplica cuando un cambio afecta la recopilacion, uso, intercambio, visibilidad, almacenamiento, eliminacion, profiling, analitica, exportacion o reutilizacion de datos personales.

Incluye nuevos campos, nueva visibilidad interna, nuevos subprocesadores, exportaciones, IA, cambios de retencion, logica de eliminacion, monitorizacion o defaults modificados. El disparador debe aparecer en planificacion, no despues de implementar.

Cambios que suelen activar revision

Las funciones nuevas suelen requerir revision si recopilan datos, muestran datos existentes de otra forma o crean visibilidad interna. Ejemplos: onboarding, perfiles, dashboards, reportes, permisos, exportaciones, notificaciones, analytics y controles de administracion.

Tambien cuentan procesos internos: CRM, soporte, data warehouse, consola admin, billing, customer success y debugging. La revision debe seguir el flujo de datos, no solo la pantalla del cliente.

Proveedores, IA y DPIA

Un nuevo procesador, proveedor de IA, herramienta de soporte o plataforma de analytics puede cambiar finalidad, acceso, transferencias, retencion y eliminacion. Antes del go-live, confirma categorias de datos, subprocesadores, contrato, seguridad y soporte de eliminacion.

No toda revision requiere DPIA. Escala cuando haya datos sensibles, menores, monitorizacion a gran escala, profiling, decisiones automatizadas, IA, retencion inusual, amplio acceso interno, transferencias o reutilizacion inesperada.

Que hacer despues

Primero, pon el disparador donde empieza el trabajo: brief de producto, ticket, revision de arquitectura, vendor intake, cambio de data warehouse o checklist de release.

Segundo, asigna responsables. Producto controla finalidad, alcance y defaults. Engineering controla permisos, borrado, logs y evidencia tecnica. Security revisa acceso. Legal o privacy interpreta y decide escalado. Compliance u operaciones mantiene evidencia y follow-ups.

Tercero, documenta el registro minimo: feature, responsable, finalidad, categorias de datos, interesados, acceso, proveedores, defaults, retencion, eliminacion, riesgos, decision, aprobador y ubicacion de evidencia. Conecta ese registro al release gate.

FAQ

Cuando aplica Privacy by Design?

Cuando producto, workflow interno, proveedor, data pipeline, analytics, IA, soporte, exportacion, permisos, retencion o defaults afectan datos personales.

Que se documenta primero?

El disparador y el registro de decision. Luego corrige los defaults, accesos, proveedores, retencion o borrado de mayor riesgo.

Toda revision necesita aprobacion legal?

No. Cambios de bajo riesgo pueden necesitar solo un registro corto. Los riesgos altos deben escalar temprano a privacy, legal, seguridad, vendor review, DPIA o aceptacion ejecutiva.