El dato más seguro es el que nunca guardaste. Los datos sensibles en una aplicación se protegen con candados, claves y revisiones, pero la mejor defensa empieza antes: decidir qué datos recoges, quién los ve y cuánto tiempo los conservas. Eso se llama minimizar desde el origen. Te explicamos el criterio y cómo lo aplicamos en un turnero para una institución de salud.
Qué son los datos sensibles y por qué cambian el diseño
En términos generales, un dato es sensible cuando su filtración o su mal uso puede afectar de verdad a la persona: su salud, su documento de identidad, su ubicación, su situación económica. No es lo mismo perder la lista de turnos de una fila que exponer quién consultó a qué especialista.
Tener datos sensibles cambia las decisiones de diseño desde el primer boceto, no al final. Si se piensa tarde, protegerlos se vuelve un parche. Si se piensa al inicio, muchas decisiones simplemente dejan de ser necesarias.
Este artículo es una guía de criterios de diseño, no asesoría legal. Para las obligaciones de tu negocio consulta a un abogado. La referencia que usamos en Acuareloo es la Ley 1581 de protección de datos personales (habeas data).
La idea en una frase: recoger, separar, retener
Minimizar se resume en tres verbos:
- Recoger lo mínimo. Antes de pedir un campo, pregunta para qué lo necesitas. Si no hay una decisión o una obligación detrás, no lo pidas.
- Separar lo público de lo privado. Lo que se muestra en una pantalla de sala, en un código QR o en una página abierta no debe contener datos personales.
- Retener lo necesario. Define cuánto tiempo conservas cada dato y qué haces con él cuando ya no sirve.
A esos tres se suma uno transversal: auditar. Que quede registro de quién consultó qué y cuándo.
Un ejemplo real, sin nombre: el turnero de una institución de salud
Diseñamos un turnero para una institución de salud: tres equipos sincronizados en tiempo real. Un kiosco o tablet, donde la persona se identifica, elige el servicio y recibe su turno. Una pantalla en la sala de espera, que muestra el turno en atención con voz y timbre. Y recepción, desde donde se llama al siguiente. Puedes ver el caso completo en el portafolio.
Es un caso exigente: hay datos de salud, pantallas que ve todo el mundo y varios equipos que deben mostrar lo mismo al mismo tiempo. Estas fueron las decisiones de minimización:
- Las pantallas públicas no reciben datos personales. La información que viaja a la pantalla de sala no contiene nombres ni documentos: solo lo necesario para llamar el turno.
- El nombre se guarda enmascarado y nunca se guarda la cédula. Si alguien accediera a la base, no encontraría el documento de nadie.
- Cada consulta queda auditada, y el documento se registra como una huella (un hash), que permite saber que hubo una consulta sin conservar el número.
- Hay límites de intentos por minuto. Eso frena las consultas repetidas, por ejemplo alguien que pruebe documentos uno tras otro desde el kiosco.
- El modo demostración usa personas ficticias. El mismo código corre con datos de ejemplo para mostrar y con datos reales para operar, así que mostrar el sistema no exige tocar información real.
Cómo se aplica en cualquier aplicación
No necesitas ser una institución de salud para usar estos criterios. Esta tabla sirve para revisar cualquier aplicación que maneje datos de personas:
| Si tu aplicación… | Pregúntate | Decisión de diseño |
|---|---|---|
| Pide muchos campos | ¿Para qué decisión uso cada uno? | Elimina o vuelve opcional lo que no tenga uso claro |
| Muestra datos en pantallas o QR públicos | ¿Qué verá alguien que pasa por ahí? | Mostrar códigos y estados, no nombres ni documentos |
| Tiene varios tipos de usuario | ¿Quién necesita ver qué? | Roles y permisos desde el inicio |
| Guarda documentos de identidad | ¿Necesito el número completo? | Enmascarar, o guardar una huella en lugar del dato |
| Permite consultas | ¿Quién consultó y cuándo? | Registro de auditoría y límites de intentos |
| Se prueba o se muestra | ¿Con qué datos? | Datos ficticios en demos y pruebas |
| Acumula información por años | ¿Cuánto tiempo la necesito? | Definir retención y borrado |
Los roles, por ejemplo, no son exclusivos de salud. En Barloo, la plataforma para bares, los roles de administrador, subadministrador y empleado hacen que cada persona vea solo lo suyo.
Minimizar no es esconderle información a quien la necesita
Una objeción frecuente es que menos datos significa una aplicación menos útil. En la práctica suele ocurrir lo contrario. Minimizar no es negarle la información a quien la necesita para trabajar: es entregarle a cada persona exactamente lo que su tarea exige, y nada más.
Quien atiende en recepción necesita saber qué turno sigue y a qué servicio corresponde. Una pantalla de sala necesita saber qué turno llamar. Ninguna de las dos necesita un expediente. Cuando cada pantalla recibe solo lo suyo, además, el sistema se vuelve más simple: menos campos que validar, menos casos raros que probar y menos cosas que pueden salir mal.
También ayuda a quien administra. Una base de datos con menos datos personales es más fácil de explicar, de revisar y de proteger. Y si un día alguien pregunta qué información guarda tu negocio de una persona, la respuesta es corta.
Lo que aprendimos al revisar una aplicación antes de salir
Ninguna aplicación nace perfecta. Antes de tocar la base de datos real, el turnero pasó por una revisión de seguridad y otra de calidad. La revisión de seguridad encontró dos hallazgos críticos, tres altos y cuatro medios, y todos se corrigieron. La de calidad corrigió 26 hallazgos.
De ese proyecto nos quedaron reglas escritas que seguimos en los siguientes:
- La revisión de seguridad y de calidad va antes de ejecutar nada sobre la base real, no después.
- Un fallo de red nunca se muestra como “no encontrado”. Si el sistema dice que una persona no existe cuando en realidad se cayó la conexión, alguien puede quedar sin atención.
- La zona horaria del cliente es un requisito, no un detalle: la numeración diaria de turnos depende de ella.
- Los datos de salud se minimizan en el origen, no se limpian después.
Nada de esto garantiza que una aplicación sea invulnerable. Lo que hace es reducir lo que hay para perder y dejar rastro de lo que ocurre.
Qué preguntarle a quien te construya una aplicación
Si vas a contratar una aplicación con datos de personas, estas preguntas separan una promesa de un criterio:
- ¿Qué datos va a recoger y para qué sirve cada uno?
- ¿Qué verá una persona que mire la pantalla por encima del hombro de otra?
- ¿Quién puede consultar qué, y queda registro de las consultas?
- ¿Con qué datos se prueban y se muestran los demos?
- ¿Qué revisiones se hacen antes de poner la aplicación con datos reales?
- ¿Cuánto tiempo se conservan los datos y cómo se borran?
Si las respuestas son vagas, es una señal. Si te interesa saber más sobre cuándo hace falta una aplicación, lee cuándo tu negocio necesita una aplicación web y no solo una página. Y si hoy los datos de tu negocio viven en una hoja de cálculo, también es un buen momento para pensar cómo dar el salto del Excel a un sistema propio.
Preguntas frecuentes
¿Qué significa minimizar datos en una aplicación?
Recoger solo los datos que de verdad necesitas, mostrarlos solo a quien le corresponde y conservarlos solo el tiempo necesario. Lo que no recoges no se puede filtrar, perder ni usar mal.
¿Una pantalla de sala de espera puede mostrar el nombre de la persona?
Puede, pero conviene no hacerlo. En el turnero que diseñamos, las pantallas públicas no reciben datos personales: muestran el turno y el lugar de atención, no quién es la persona.
¿Esto es asesoría legal?
No. Son criterios de diseño. Para las obligaciones legales de tu negocio consulta a un abogado. Nuestra referencia es la Ley 1581 de protección de datos personales (habeas data).
¿Solo aplica a datos de salud?
No. Aplica a cualquier aplicación que maneje datos de personas: clientes, empleados, pacientes, estudiantes o proveedores. Los datos de salud son de los más delicados, pero el criterio es el mismo.
