Privacidad en proyectos de identificación: separar producto, activo y persona

Aviso previo: orientación general, no asesoría legal

Este artículo ofrece criterios de diseño para reducir riesgos de privacidad en proyectos de identificación como RFID, códigos de barras y PDA. No es asesoría legal ni afirma qué obligaciones concretas tiene tu empresa. Su propósito es ayudarte a documentar el proyecto y las preguntas que debe revisar un especialista.

Como referencia documental se consultó el texto original publicado en el Diario Oficial de la Federación el 20 de marzo de 2025. No se comprobó una versión consolidada que incorpore las posibles reformas posteriores, por lo que aquí no se determina el contenido vigente de las obligaciones legales. Antes de utilizar datos vinculados a personas, pide a un especialista que confirme la normativa aplicable, el aviso de privacidad y las medidas que requiere tu caso.

Tres planos que no deben mezclarse

El riesgo aparece cuando los planos se cruzan. Un identificador de producto en una prenda vendida, si se combina con un dato de cliente, puede permitir reconocer a una persona fuera de la tienda. Un activo asignado a un empleado y leído en puertas puede convertirse en un registro de movimientos de esa persona. Nada de esto ocurre por la tecnología en sí, sino por las uniones de datos que decides hacer.

Qué dice una etiqueta y qué no

Un EPC de una etiqueta RFID identifica un objeto; el Tag Data Standard de GS1 define cómo se codifica el identificador y su relación con las claves GS1. Por sí solo, un EPC no contiene el nombre de nadie, pero la información que se enlaza a él en tus sistemas determina el riesgo. Si el EPC de un artículo vendido se vincula en tu base con un cliente, esa base contiene datos personales.

Dos preguntas útiles: ¿qué pasa con las etiquetas cuando el producto sale de tu control, por ejemplo tras la venta?, y ¿existe un procedimiento para desactivar, retirar o dejar de asociar el identificador cuando ya no se necesita? Si no tienes respuesta, es un punto abierto del proyecto, no un detalle.

Minimización y finalidad en la práctica

• Finalidad escrita. Anota para qué se captura cada dato, antes de capturarlo.
• Solo lo necesario. Si para el conteo basta la cantidad por zona, no registres quién estaba presente.
• Separar identidad de actividad. Usa identificadores internos pseudónimos para operadores en lugar de nombres, y mantén la tabla de equivalencias con acceso restringido.
• Retención definida. Decide cuánto tiempo guardas eventos con datos de personas y quién autoriza prorrogar.
• Acceso por rol. Que quien consulta inventario no vea automáticamente datos de empleados.

El Marco de Privacidad del NIST, un marco voluntario sin fuerza de ley, incluye entre sus resultados de control el tratamiento desasociado: procesar los datos para limitar la capacidad de asociarlos con personas, limitar la identificación de las personas y configurar sistemas o dispositivos para recolectar o divulgar solo lo necesario. También propone políticas de retención y ciclo de vida de los datos, y destaca el mapa de datos como herramienta para entender el tratamiento. Úsalo como lista de preguntas de diseño, no como evidencia de cumplimiento legal.

La hoja de OWASP sobre logging recomienda no registrar datos personales sensibles o, cuando sea necesario, enmascararlos, aplicar hash o cifrarlos, y considerar técnicas de desidentificación como la pseudonimización. Esa lógica sirve igual para bases de eventos de inventario.

Ejemplo hipotético: contenedores retornables y choferes

Ejemplo ilustrativo. Una empresa etiqueta contenedores retornables para saber cuántos hay en cada sitio. El diseño original anotaba, en cada lectura, el nombre del chofer que los entregó, “por si hay dudas”. Al revisarlo con el responsable de cumplimiento descubren que ese dato no era necesario para el conteo y sí creaba un historial de entregas por persona.

Cambian el diseño: registran el número de viaje y el sitio, y guardan la relación entre viaje y chofer en el sistema de transporte, con acceso restringido y retención propia. El inventario de contenedores ya no depende de datos de personas. Si hay una disputa, se consulta el viaje por el canal con permisos.

Cuándo pedir revisión especializada

• Si se vinculan identificadores con clientes, empleados o visitantes.
• Si se registran horarios o movimientos de personas, incluso de forma indirecta.
• Si se comparten datos con terceros, dentro o fuera del país.
• Si se capturan datos sensibles de cualquier tipo.
• Si cambiará el aviso de privacidad o los contratos con proveedores que tratan datos.

Pide al especialista que revise el mapa de datos del proyecto (qué se captura, dónde se guarda, quién accede, cuánto tiempo y a quién se envía), con las pantallas, los registros y los contratos de proveedores como anexos.

Proveedores, contratos y datos compartidos

Cuando un proveedor accede a tus datos (por ejemplo, soporte remoto de una plataforma de etiquetas o de un middleware), la privacidad también depende del contrato y del control de acceso. Pide por escrito qué datos ve, desde dónde, con qué cuentas individuales y cómo queda registrado. Evita las cuentas compartidas y establece cómo se revoca el acceso al terminar el servicio. Si el proveedor aloja datos fuera de tu infraestructura, aclara dónde se almacenan y qué ocurre con ellos al concluir el contrato. Estos puntos deben revisarse con tu área legal y con el especialista en privacidad, porque la implicación jurídica de cada arreglo depende de los hechos de tu caso.

Siguiente paso

Dibuja el mapa de datos de tu proyecto en una hoja con las columnas producto, activo y persona, y marca dónde se cruzan. Elimina las uniones que no puedas justificar y lleva el resto a tu área legal. Si quieres comentar la parte técnica de captura con ARKCOM, escribe desde garkcom.com/contact.