Protección de datos (Ley 1581) en tu software: qué debe cumplir tu app
Qué exige la Ley 1581 de 2012 a tu app o sistema en Colombia, traducido a requisitos técnicos concretos: autorización, seguridad, acceso por rol y derechos del titular.
Si tu app captura aunque sea un nombre y un correo, ya estás haciendo “tratamiento de datos personales” y la Ley 1581 de 2012 te aplica. No es un tema solo de tu abogado: es un tema de cómo está construido tu software. Y sin embargo, casi todo lo que se escribe sobre habeas data en Colombia explica la ley en lenguaje jurídico y nunca la traduce a lo que tu sistema debe hacer.
Antes de seguir, algo importante: este artículo es informativo, no asesoría legal. Para el cumplimiento formal debes consultar los textos oficiales y un abogado. Lo que sí voy a darte es la traducción práctica —cómo cada exigencia de la ley se convierte en un requisito técnico dentro de tu app— desde el lado de quien construye software.
Qué es la Ley 1581 y por qué le importa a tu software
La Ley 1581 de 2012 desarrolla el habeas data: el derecho de toda persona a conocer, actualizar y rectificar la información que se recoge sobre ella. Aplica a cualquier base de datos, pública o privada. En cristiano: desde el momento en que guardas datos de una persona, tienes obligaciones. Y la mayoría de esas obligaciones se cumplen —o se incumplen— en el código y la arquitectura de tu sistema.
Responsable o encargado: identifica tu rol
La ley distingue dos papeles. El responsable es quien decide sobre los datos: normalmente el negocio dueño de la información. El encargado es quien trata los datos por cuenta del responsable: por ejemplo, el proveedor de software o de hosting. Si contratas a alguien para construir tu app, ese proveedor suele ser encargado, y entre ambos debe haber un contrato que regule el tratamiento. Saber cuál eres define tus obligaciones, y es una de las razones para elegir bien a tu proveedor.
La autorización: el consentimiento que tu formulario debe registrar
La ley exige consentimiento previo, expreso e informado, y —clave— que puedas probar que lo obtuviste. En términos de software eso significa: una casilla de aceptación que no venga pre-marcada, un enlace a tu política de tratamiento en el punto de captura, y guardar la evidencia: fecha, hora y versión del texto que la persona aceptó. Un checkbox suelto que no registra nada no te sirve como prueba.
Los principios traducidos a requisitos técnicos
La ley tiene ocho principios; estos son los que se vuelven decisiones de arquitectura:
- Finalidad: usa los datos solo para lo que informaste; no los reutilices para otra cosa sin nueva autorización.
- Seguridad: protege la información con medidas técnicas reales (ciframos, más abajo).
- Acceso y circulación restringida: no todo el mundo debe ver todo; permisos por rol.
- Veracidad: el usuario debe poder actualizar y corregir sus datos.
- Confidencialidad: quien maneja los datos está obligado a reservarlos.
Datos sensibles: cuándo entras en zona de máximo riesgo
La ley define datos sensibles —salud, biométricos como huella o rostro, orientación, entre otros— y restringe fuertemente su tratamiento. Si tu app guarda una huella para control de acceso, datos de salud de un paciente o información de menores, necesitas autorización explícita, refuerzas la seguridad y no puedes condicionar el servicio a que la persona los entregue. Un chatbot que pide la cédula o una app de citas médicas caen aquí: mismo marco, más cuidado.
Control de acceso por rol y cifrado
El principio de seguridad se construye, no se declara. En la práctica: control de acceso por roles (cada usuario ve solo lo que su función necesita), cifrado en tránsito (HTTPS/TLS) y en reposo, principio de mínimo privilegio, y nunca exponer datos personales en las URLs. Esto se decide al diseñar el sistema, no se parcha después —es parte de construir bien una plataforma a la medida.
Trazabilidad: demostrar quién tocó qué dato
Necesitas un registro de auditoría: quién accedió o modificó qué información y cuándo. Sirve para dos cosas —responder ante la Superintendencia de Industria y Comercio si te lo piden, y cumplir el derecho del titular a saber cómo se usaron sus datos—. Sin logs, no puedes probar nada.
Atender los derechos del titular desde el software
La persona tiene derecho a conocer, actualizar, rectificar, revocar la autorización y pedir la supresión de sus datos. Tu sistema necesita un canal o, mejor, una función de autoservicio en la cuenta del usuario para atender esas solicitudes en los términos que fija la ley. Un chatbot que recoge datos, por ejemplo, también debe respetar esto —lo menciono en el artículo sobre chatbots con IA—.
Política de tratamiento, RNBD y el checklist
Tu producto debe exhibir una política de tratamiento (documento completo) y un aviso de privacidad (el resumen en el punto de captura). Además, según ciertos criterios de tamaño, algunos responsables deben inscribir sus bases en el Registro Nacional de Bases de Datos (RNBD) ante la SIC; el umbral y los plazos han cambiado por circulares, así que verifica la vigencia directamente con la SIC. Y ojo: no estar obligado al RNBD no te exime de las demás obligaciones de la ley.
Como este es el mismo marco de “qué debe cumplir tu software para operar legal en Colombia” que la facturación electrónica DIAN, conviene pensarlos juntos desde el diseño.
Un chequeo rápido: cinco cosas que puedes revisar hoy en tu app
Sin necesidad de un auditor, cualquiera con acceso al producto puede mirar estas cinco señales. Uno: ¿la casilla de autorización viene pre-marcada? (debe estar en blanco). Dos: ¿hay un enlace visible a la política de tratamiento en el punto donde pides los datos? Tres: ¿el usuario puede entrar a su cuenta y actualizar o borrar su información sin escribirle a nadie? Cuatro: ¿los datos viajan por HTTPS y ninguna cédula o correo aparece en la URL? Cinco: ¿queda registro de quién accede a los datos sensibles? Si alguna respuesta es “no”, ahí tienes tu primer pendiente —y casi siempre es más barato corregirlo ahora que después de un requerimiento de la SIC—.
Conclusión
La Ley 1581 no es letra muerta para tu abogado: es una lista de requisitos que viven en tu app —cómo capturas el consentimiento, cómo controlas el acceso, cómo ciframos, cómo registras y cómo atiendes los derechos del titular—. Construir con eso en mente desde el principio es mucho más barato que remendar después.
Y lo repito porque importa: esto es una guía práctica, no asesoría jurídica. Confirma los detalles vigentes con la SIC y un abogado de protección de datos. Si quieres una app que cumpla la Ley 1581 desde su arquitectura, hablemos.