Proteger los datos también es una decisión de producto

Una política de privacidad no compensa un producto que recopila información sin una razón clara, permite el acceso a demasiadas personas o conserva registros sin un plazo definido. La política describe compromisos; el software determina cuánto de ellos puede cumplir la organización en su operación diaria.

Eso no significa que el software sea una persona jurídica con obligaciones propias. En la mayoría de los regímenes de protección de datos, los deberes corresponden a organizaciones y personas según lo que deciden y hacen. Pero el modelo de datos, los permisos, las integraciones y las reglas de conservación del producto pueden hacer posible un tratamiento responsable o socavarlo silenciosamente.

Empieza por la finalidad, no por el campo de datos

Antes de añadir un campo, un evento o una fuente de analítica, define qué decisión o servicio habilita. “Quizá lo necesitemos después” no es un requisito de producto suficiente. Esa lógica incentiva la recopilación amplia y dificulta explicar a una persona por qué se conserva su información, quién puede usarla y cuándo debe eliminarse.

En Colombia, la Ley 1581 de 2012 establece principios para el tratamiento de datos personales como finalidad, libertad, veracidad, transparencia, acceso restringido, seguridad y confidencialidad. También distingue al responsable, que decide sobre la finalidad y los medios del tratamiento, del encargado, que trata los datos por cuenta del responsable. El consentimiento y las demás condiciones legales dependen de la norma aplicable y las circunstancias; un equipo de producto no debe asumir que una casilla de aceptación constituye siempre la base legal. Ley 1581 de 2012 de Colombia.

El Reglamento General de Protección de Datos de la Unión Europea también exige limitar la finalidad y minimizar los datos, e integrar salvaguardas desde el diseño y por defecto. Es una referencia comparativa, no un sustituto de verificar qué legislación aplica a una organización, un servicio y las personas involucradas. Reglamento General de Protección de Datos de la UE, Reglamento (UE) 2016/679.

Haz que el producto permita cumplir las obligaciones

La revisión legal y de privacidad ayuda a determinar qué debe hacer una organización. Los equipos de producto e ingeniería convierten esas obligaciones en recorridos funcionales. Una solicitud de acceso o corrección debe llegar al equipo indicado con contexto suficiente para localizar los registros. Una solicitud de supresión debe considerar sistemas conectados y obligaciones de conservación. Un agente de soporte debe ver solo la información necesaria para resolver el caso.

Para lograrlo, hay que mapear qué datos existen, dónde circulan, qué servicios los reciben, quién es responsable de cada finalidad y cuánto tiempo se conservan. Los permisos deben corresponder al rol y al propósito. Las reglas de retención deben alcanzar respaldos, exportaciones y copias posteriores tanto como permitan la ley y el diseño técnico. Los registros deben permitir revisar accesos y cambios relevantes sin recopilar todavía más información personal de la necesaria.

Los controles de seguridad también necesitan responsables operativos. El cifrado, la revisión de accesos, las copias de seguridad, la gestión de vulnerabilidades y la respuesta a incidentes no son tareas de implementación que se hacen una sola vez: necesitan responsables, evidencia y una ruta de acción cuando algo falla.

La responsabilidad depende de la relación real

Que un contrato llame “encargado” a un proveedor no resuelve por sí solo todas las cuestiones jurídicas. Importan las finalidades, decisiones e instrucciones reales. En Colombia, el Decreto 1377 de 2013 establece condiciones para los acuerdos entre responsables y encargados, incluido el alcance del tratamiento y los deberes del encargado. También exige que los responsables puedan demostrar medidas apropiadas y efectivas, proporcionales a la organización, los datos, el tratamiento y sus riesgos potenciales. Decreto 1377 de 2013 de Colombia.

Por eso, al comprar o desarrollar software conviene identificar subencargados, ubicaciones de alojamiento, flujos de datos, acceso del equipo de soporte, rutas para notificar incidentes, devolución o eliminación al terminar el servicio y la evidencia que cada parte puede aportar. Los requisitos contractuales y de transferencia dependen de la ley y del acuerdo aplicables. Un proveedor puede ayudar a implementar salvaguardas, pero no sustituye las decisiones y la rendición de cuentas del cliente.

En 2025, la Superintendencia de Industria y Comercio emitió instrucciones sobre protección de datos personales en procesos de transferencia de tecnología, con énfasis para las entidades comprendidas en su alcance en verificaciones previas, gestión de riesgos, decisiones documentadas y protección desde el diseño. Es un recordatorio concreto de que un cambio tecnológico puede modificar flujos de datos y exposición legal; no es una regla general para todo proyecto de software. Instrucciones de la SIC sobre protección de datos en transferencias de tecnología.

No diseñes solo para las condiciones ideales

El uso responsable de datos contempla situaciones cotidianas y excepciones: una persona cambia de cargo; una integración duplica registros; alguien revoca su autorización cuando aplica; termina la relación con un proveedor; se compromete una cuenta; o hay que evaluar rápidamente un incidente. Si el producto no permite limitar accesos, encontrar registros afectados, detener un flujo o apoyar una investigación, un procedimiento escrito puede resultar difícil de ejecutar.

No todas las actividades de tratamiento requieren la misma evaluación, control o notificación. Por ejemplo, el GDPR de la UE exige una evaluación de impacto antes de tratamientos que probablemente entrañen un alto riesgo para los derechos y libertades de las personas; no impone la misma evaluación a cada funcionalidad. Los umbrales y procedimientos también varían entre leyes. El asesor jurídico y el responsable de privacidad de cada organización deben determinar qué corresponde al tratamiento concreto.

Integra la protección de datos al lanzamiento y la operación

Para cada nuevo flujo, el equipo puede incluir unas preguntas en el descubrimiento y la revisión antes del lanzamiento: ¿cuál es la finalidad?, ¿qué datos personales son realmente necesarios?, ¿quién puede consultarlos o cambiarlos?, ¿cómo se ejercen los derechos que apliquen?, ¿cuál es el plazo de conservación?, ¿qué proveedores reciben los datos?, ¿qué ocurre ante un incidente o al terminar el servicio?, ¿qué evidencia demuestra que los controles funcionan?

Responderlas requiere conocimientos de producto, ingeniería, seguridad, operaciones, compras y derecho. Es más sencillo hacerlo mientras todavía se están definiendo el flujo y la arquitectura que después de que datos innecesarios ya circulen por varios sistemas y contratos.

El análisis legal debe responder al contexto de cada organización, las personas afectadas, el tipo de datos y los países involucrados. La responsabilidad de producto es más inmediata: definir el uso previsto, limitar accesos y conservación, apoyar los derechos de las personas y conservar suficiente evidencia operativa para revisar qué ocurrió. Así, los compromisos de privacidad se convierten en un sistema por el que alguien puede responder.

Este artículo ofrece información general y no constituye asesoría jurídica. Cada organización debe obtener orientación sobre las normas aplicables a su tratamiento.