Minimizar lo que se pide y lo que se guarda

El principio de finalidad de la Ley 1581 de 2012 pide que todo tratamiento obedezca a un propósito legítimo que se le informa al titular. De él se desprende una regla de diseño: cada campo que la aplicación pide tiene que poder señalar la finalidad que lo justifica, y pedir más de lo que esa finalidad necesita ya es un problema, aunque el dato se guarde con cuidado.

Minimizar no es solo quitar campos. También es pedir un dato menos detallado cuando basta (un rango en lugar de un valor exacto), guardar el resultado de una comprobación en lugar del documento que la soporta, y devolver por la API solo lo que la pantalla usa. Cada una de esas decisiones reduce lo que se pierde si algo falla.

La revisión de un formulario se hace con dos columnas a la vista: qué campos son obligatorios y qué finalidad declara la política para cada uno. Un campo obligatorio sin finalidad es el peor caso: la persona no puede registrarse sin entregarlo y la empresa no puede explicar para qué lo quiere.

Recorre los campos marcados como obligatorios y busca cada uno en el extracto de la política.

Hay un campo del formulario que sí tiene finalidad (atender una emergencia en la sede), pero que es un dato de salud. El reglamento de la ley (Decreto 1377 de 2013, hoy compilado en el Decreto 1074 de 2015) añade para los sensibles dos exigencias que tocan al diseño: avisar al titular de que no está obligado a autorizar su tratamiento, y no condicionar ninguna actividad a que lo entregue.

En la interfaz eso tiene una forma concreta: el campo es opcional, se explica al lado para qué se usa y que se puede dejar en blanco, y su autorización se pide aparte y de forma expresa, no escondida en la casilla general.

Una pantalla puede mostrar poco y, aun así, la API que la alimenta devolver mucho más. Todo lo que viaja en la respuesta queda en el teléfono, en las herramientas del navegador y en cualquier registro intermedio, se pinte o no. Por eso la minimización también se revisa en el contrato de la API: la respuesta debería traer lo que la pantalla usa, y los datos delicados, en un recurso aparte con su propio control.

Compara los campos de la respuesta guardada con lo que el diseño de la pantalla dice que usa, incluido lo que usa sin mostrar.

Muchas comprobaciones necesitan un dato solo un momento: verificar la identidad, comprobar la mayoría de edad, validar un medio de pago. Lo que hace falta conservar después es el resultado de la comprobación (quién la hizo, cuándo y con qué resultado), no el documento que se miró. Guardar la prueba «por si hace falta otra vez» convierte una verificación puntual en un archivo permanente de copias de documentos.

Lee la finalidad declarada de cada campo y luego lo que hace el código con él al registrar.