Minimización: pedirle a la flota sólo lo necesario

Una integración de flota suele arrancar con una planilla que trae más columnas de las que el proceso usa: conductor asignado, documento, teléfono, centro de costos, domicilio. La consulta de infracciones necesita bastante menos, en general el dominio y el alcance de la búsqueda. Las demás columnas viajan igual, porque estaban en el archivo que alguien exportó del sistema de personal.

El reflejo habitual es protegerlas mejor: cifrar, restringir la vista, fijar un plazo de borrado. Todo eso hace falta, pero llega después. La minimización es la decisión anterior: no pedir esa columna. La Ley 25.326 la plantea como requisito de calidad del dato —los datos que se recojan deben ser ciertos, adecuados, pertinentes y no excesivos en relación al ámbito y finalidad para los que se hubieren obtenido— y no como una recomendación opcional.

El campo que nunca entró no se cifra, no se replica al respaldo, no aparece en el informe de multas y no entra en el alcance de un incidente. Es el único que sale gratis.

La finalidad decide, no la utilidad futura

La pregunta frente a cada campo no es si algún día podría servir, sino qué salida del proceso cambia cuando falta. Si ninguna consulta de patente, ningún aviso de acta y ningún reporte dependen de ese dato, el campo es excesivo aunque resulte cómodo tenerlo.

“Por las dudas” tampoco es una finalidad declarable. La ley prevé que los datos no se utilicen para fines distintos o incompatibles con los que motivaron su obtención, y que se destruyan cuando dejan de ser necesarios o pertinentes. Un dato guardado sin uso definido no queda disponible para cualquier uso posterior: queda pendiente de justificación.

Cada campo pedido debería poder nombrar la decisión que habilita: identificar el vehículo, dirigir el aviso, imputar el gasto, ubicar la autoridad. Un campo sin decisión asociada es candidato a salir del formulario.

Cuatro lugares donde se pide de más

Conviene revisarlos por separado, porque cada uno suele tener otro responsable:

• el alta del cliente, con un formulario largo cuyos datos ninguna función posterior lee;
• la carga del padrón, cuando se sube el archivo completo en vez de la columna de dominios;
• los parámetros de la consulta, cuando un documento o un CUIT viaja en la ruta o en la cadena de consulta y termina replicado en registros y proxies intermedios;
• la respuesta, cuando el servidor entrega el objeto interno entero.

Ese último punto tiene nombre propio en la guía de pruebas de OWASP —exposición excesiva de datos— y lo tratamos desde el lado de la respuesta en datos personales en una API de infracciones. La recomendación es definir un esquema explícito con los campos permitidos en vez de serializar el objeto interno. Los tres puntos anteriores son la cara de entrada del mismo criterio: un dato que ya entró no se puede devolver.

Un inventario campo por campo

El plan de protección de datos que publica la Agencia de Acceso a la Información Pública le pone nombre al criterio: los datos deben limitarse a lo necesario en relación con los fines para los que fueron recolectados —principio de minimización— y el tratamiento debe acotarse con criterios expresos de proporcionalidad y razonabilidad.

Llevado a una integración, eso se ordena en una tabla corta con una fila por campo: de dónde entra, qué decisión habilita, quién lo ve y cuándo deja de existir. Una fila con la finalidad vacía se resuelve rápido: o se escribe la finalidad o se saca el campo.

Sobre lo que queda pesan las obligaciones que la Agencia publica para el responsable de una base de datos personales: informar la finalidad y la posibilidad de ejercer los derechos de acceso, rectificación y supresión, y adoptar medidas de seguridad y confidencialidad, entre otras. Cada campo de más ensancha esa superficie.

Lo que no se pide no hay que sostener

Un campo tiene costo durante toda su vida: validarlo, almacenarlo, migrarlo cuando cambia el esquema, incluirlo o excluirlo de cada exportación y responder por él si alguien ejerce sus derechos.

Ese costo se propaga: una integración con menos campos deja trazas y métricas más fáciles de publicar y una auditoría más fácil de conservar, porque hay menos para esconder.

Cómo se prueba que un campo sobra

El primer control es reproducible y no toca datos reales. Tomá un caso sintético, quitá el campo de la entrada y corré el flujo entero: consulta de la patente, resultado, aviso y exportación. Si nada falla y ninguna pantalla queda con un hueco, el campo era excesivo.

El segundo control es de lectura: identificar qué vista, qué regla y qué reporte usan ese campo. Un dato que nadie lee es peso muerto con obligaciones asociadas.

El tercero es de vigencia: cuando una función se retira, revisá si dejó campos huérfanos en el alta.

Antes de cerrar una integración, verificá qué campos pide el alta, cuáles viajan en cada consulta de patente, qué devuelve el contrato por defecto y qué decisión justifica cada uno. Pedir menos no es ofrecer menos: es sostener y explicar menos.

Preguntas frecuentes

¿Minimizar es pedir menos datos de los que el proceso necesita?

No. Es pedir exactamente los que cambian una decisión del proceso. Si una alerta, un reporte o una imputación de gasto dependen de un campo, ese campo es pertinente. El problema aparece con los que se cargan por costumbre y ninguna función posterior lee.

¿Alcanza con borrar más adelante los datos que sobran?

El borrado programado es una obligación distinta y necesaria, pero no reemplaza la decisión de entrada. Entre la carga y el vencimiento el dato existió en la base, en los respaldos, en los registros y en cualquier exportación ya generada. Es orientación general y no asesoramiento legal.

¿Puedo guardar un campo hoy por si mañana lo necesito?

La normativa prevé que los datos no se usen para finalidades distintas o incompatibles con las que motivaron su obtención, de modo que un uso nuevo exige revisar la finalidad declarada y no sólo tener la columna cargada. Suele ser más simple incorporar el campo cuando el caso de uso existe.

Notas relacionadas