Relevo · seguridad y privacidad
Observar el trabajo de una persona es tratar un dato personal. Todo lo demás de esta página sale de ahí.
Un sistema que mide cómo trabaja su equipo no se justifica con una política de seguridad. Se justifica con tres respuestas por escrito: qué se observa, quién puede verlo y cómo lo comprueba la persona observada. Esta página da las tres, con la ley que las exige y el registro que las prueba.
Por qué esta página es distinta de las demás del sistema
En los otros sistemas de la casa, la página de seguridad habla de un expediente: quién capturó un lote, quién liberó un embarque, quién firmó un reporte. Aquí el objeto del registro es otro. Relevo no observa una cosa: observa a una persona trabajando en su computadora. Eso cambia la naturaleza del dato y cambia quién tiene derecho a pedir cuentas.
El dato de que un puesto ejecuta 340 capturas al día, a 45 segundos cada una, es un dato de productividad. Pero el registro de que una persona identificada ejecutó esas capturas, en esas horas, en esas pantallas, es un dato personal de esa persona. Y a los datos personales de los trabajadores les aplica la misma ley que a los de un cliente, con una diferencia que conviene decir en voz alta: entre el patrón y el trabajador no hay simetría, y por eso el consentimiento no basta como única justificación del tratamiento.
De ahí la forma de esta página. Primero la ley, con su fecha y su autoridad. Después la finalidad declarada y lo que queda fuera de la observación. Después quién puede ver la observación de quién, que es la pregunta que hará el comité de la empresa o la representación de los trabajadores en la primera reunión. Y al final los controles de plataforma, con su evidencia, y la tabla que separa lo que el sistema hace de lo que el patrón tiene que hacer.
La frase que este sistema tiene que poder sostener es «automatizar el trabajo de su equipo, no espiarlo». Una frase así no se sostiene con una promesa: se sostiene con una lista de lo que no se registra.
Un control de privacidad que la persona observada no puede verificar por sí misma no es un control: es una cortesía revocable.
El primer frente
La ley que manda, con su fecha y su autoridad
Hay un error que circula en casi todos los avisos de privacidad que se firman hoy en México, y conviene corregirlo antes de cualquier otra cosa: el INAI ya no es la autoridad de datos personales. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente se publicó en el Diario Oficial de la Federación el 20 de marzo de 2025, entró en vigor el 21 de marzo de 2025 y fue reformada el 14 de noviembre de 2025. Sustituyó a la ley del 5 de julio de 2010 y trasladó la competencia a la Secretaría Anticorrupción y Buen Gobierno.
Esto no es un detalle de erudición jurídica. Un aviso de privacidad que nombre al INAI como autoridad ante la cual ejercer derechos está desactualizado, y es el documento que una persona observada leerá primero. Si su empresa firmó la política de uso de una herramienta de monitoreo antes del 21 de marzo de 2025, ese documento hay que revisarlo.
Lo que la ley obliga, en los términos verificados del texto vigente, es cuatro cosas: aviso de privacidad, base de licitud del tratamiento, medidas de seguridad y atención de los derechos del titular. Las cuatro se traducen en controles concretos dentro del sistema, y la traducción es la tabla siguiente.
Lo que la ley obliga · qué control lo cumple · quién responde
| Obligación | Qué exige en un sistema que observa trabajo | Control del sistema | Quién responde |
|---|---|---|---|
| Aviso de privacidad | Que la persona observada sepa qué se recoge, para qué, quién lo verá y cómo ejerce sus derechos | Aviso visible en el equipo y política de uso firmada por cada colaborador | El sistema lo presenta y guarda la firma; el texto del aviso lo redacta y lo asume el patrón |
| Base de licitud del tratamiento | Una razón legítima y declarada, no sólo una firma obtenida en una relación desigual | Finalidad declarada por proceso observado y exclusión configurada de lo que no se observa | El patrón declara la finalidad; el sistema la hace exigible |
| Minimización y proporción | Que no se recoja más de lo que la finalidad necesita | Registro del proceso y no del contenido; enmascaramiento de datos sensibles antes de que salgan del equipo; botón de pausa | Control del sistema, verificable por la persona observada |
| Medidas de seguridad | Que el dato observado esté protegido en tránsito, en reposo y en el acceso | Autenticación con token firmado de vida corta, una sola puerta de entrada al dato, permiso por rol y bitácora del cambio | Plataforma, sobre la infraestructura que el operador administra |
| Derechos del titular | Acceso, rectificación, cancelación y oposición sobre su propio registro | Vista del propio registro para la persona observada y trazabilidad de quién lo consultó | El sistema entrega la evidencia; contestar en tiempo es del patrón |
| Autoridad ante la que se responde | Que el aviso nombre a la autoridad correcta | Secretaría Anticorrupción y Buen Gobierno, no el INAI | Del patrón, y hay que corregirlo si el documento es anterior al 21 de marzo de 2025 |
Fuente: Ley Federal de Protección de Datos Personales en Posesión de los Particulares, DOF 20 de marzo de 2025, en vigor el 21 de marzo de 2025, reforma DOF 14 de noviembre de 2025 · verificado al 27 de septiembre de 2026.
El segundo frente
Qué se observa y qué no, por escrito
Ésta es la tabla que decide si un sistema de observación es aceptable o no, y es también la que casi nunca se publica. El criterio del sistema es uno y se declara así: se registran los pasos del proceso, no la información que pasa por ellos. Se guarda que un puesto abrió una pantalla de captura de guía, en qué orden llenó los campos y cuánto tardó. No se guarda el contenido del campo.
Y hay una segunda regla que cambia todo para la persona observada: los datos sensibles se ocultan antes de salir del equipo, no después de llegar al servidor. La diferencia es la que hay entre un filtro y una promesa. Una contraseña que nunca salió del equipo no se puede filtrar desde el servidor, porque no está ahí.
La tercera es el botón de pausa para asuntos personales. Que exista un botón de pausa es la prueba de que el sistema no reclama la jornada completa. Y su contrapartida honesta también se dice: el uso del botón queda registrado como una pausa. No se registra qué hizo la persona durante ella.
Lo que se registra · lo que no se registra · por qué
| Sobre esto | Se registra | No se registra | Por qué |
|---|---|---|---|
| La tarea | Qué secuencia de pasos se ejecutó y en qué orden | El contenido de los campos que se llenaron | La finalidad es reconocer la tarea repetida, no leer el dato del cliente |
| El tiempo | Cuántas veces al día ocurre la tarea y cuántos segundos toma cada vez | Un juicio sobre el desempeño de la persona | El indicador del sistema es la hora recuperable de la tarea, no la calificación del puesto |
| Credenciales | Que hubo un paso de autenticación | La contraseña, ni enmascarada, ni cifrada, ni en ningún otro sitio | Se oculta en el equipo, antes de que el dato salga |
| Datos fiscales y de identidad de terceros | Que el paso ocurrió sobre un campo de ese tipo | El registro fiscal, la clave de identidad, el número de tarjeta ni el correo capturados | Se enmascaran en el equipo, por la misma razón |
| Asuntos personales | Que hubo una pausa, y cuánto duró | Qué se hizo durante la pausa | El botón de pausa existe para que la jornada no se reclame completa |
| Contenido de comunicaciones privadas | Nada | Ni el texto, ni el destinatario, ni el archivo adjunto | No forma parte de la finalidad declarada, y la finalidad es el límite del tratamiento |
Fuente: Relevo · brochure de logística, sección de privacidad, los seis controles declarados · el alcance concreto de exclusión por aplicación y por horario es parámetro de su política, y se configura.
La lista de lo que no se registra vale más que la lista de lo que sí. La primera es la que alguien puede desmentir.
Los seis controles de privacidad que el sistema declara
Se transcriben los seis tal como el sistema los declara, con lo que cada uno significa para la persona observada y con lo que hay que hacer para que sea verificable y no sólo enunciado. La columna de la derecha es la importante: un control que nadie puede comprobar no cuenta.
Los seis controles, y cómo se comprueba cada uno
| Control | Qué declara | Cómo lo comprueba la persona observada |
|---|---|---|
| Visible y avisado | Cada colaborador sabe que el sistema está instalado en su equipo | El indicador está en su propio equipo, a la vista, mientras el sistema observa |
| Con consentimiento | Política de uso y aviso de privacidad firmados, conforme a la ley de protección de datos personales | Puede pedir copia del documento que firmó, con su fecha, y comparar el texto con lo que el sistema hace |
| Datos sensibles ocultos | Contraseñas, números de tarjeta, registros fiscales, claves de identidad y correos se ocultan antes de salir del equipo | El enmascaramiento se ve en su propio registro: el campo aparece como oculto, no con su valor |
| Botón de pausa | La observación se detiene para asuntos personales, a voluntad de la persona | El botón está en su equipo y el registro de la pausa aparece en su propio expediente, sin contenido |
| El proceso, no el contenido | Se registran los pasos, no la información de los clientes de la empresa | Su propio registro no contiene el dato capturado; contiene la secuencia y el tiempo |
| Acceso por rol | Cada jefe ve solamente a su equipo. Recursos Humanos audita | Puede pedir la lista de quién tiene acceso a su registro y la bitácora de quién lo consultó |
Fuente: Relevo · brochure de logística, sección de privacidad: los seis controles declarados, transcritos · 27 de septiembre de 2026.
Los seis son controles del producto. Ninguno de los seis exime al patrón de sus propias obligaciones, y por eso la última sección de esta página existe. Un sistema puede enmascarar una contraseña; no puede firmar por usted el aviso de privacidad ni decidir por usted qué proceso merece ser observado.
Verificable por el propio observado, que es la prueba que importa
Los derechos del titular sobre sus datos personales son cuatro y se ejercen sobre cualquier tratamiento: acceso a lo que se tiene de él, rectificación de lo que está mal, cancelación de lo que ya no debe estar y oposición a un tratamiento que no acepta. En un sistema de observación del trabajo esos cuatro derechos se traducen en algo muy concreto, y la traducción conviene tenerla escrita antes de que alguien la pida.
Acceso significa que la persona puede ver su propio registro, no un resumen que alguien le lea. Rectificación significa que si el sistema clasificó como una tarea lo que en realidad eran dos, o atribuyó a un puesto un tiempo que no era suyo, hay una vía para corregirlo y la corrección deja rastro. Cancelación y oposición son las dos que incomodan, y por eso hay que decidirlas antes: qué pasa cuando alguien pide que se deje de observar su equipo, y quién contesta esa solicitud en su empresa.
Hay una consecuencia de diseño que se deriva de esto y que no es negociable: el registro de una persona tiene que ser consultable por ella con el mismo detalle con el que lo ve su jefe. Un sistema donde el supervisor ve más que el observado sobre el observado no es auditable: es asimétrico por construcción, y esa asimetría es exactamente lo que la representación de los trabajadores va a cuestionar.
- Acceso: su propio registro, con el mismo detalle que ve quien lo supervisa.
- Rectificación: una vía para corregir una tarea mal clasificada o un tiempo mal atribuido, con rastro de la corrección y del valor anterior.
- Cancelación: qué se borra, cuándo y con qué registro de que se borró.
- Oposición: quién contesta en su empresa cuando alguien pide dejar de ser observado, y en cuánto tiempo. Esto no lo resuelve el software.
El día que llegue la primera solicitud de acceso, la diferencia entre un sistema y un problema es si la respuesta es una consulta o una investigación.
El tercer frente
Quién puede ver la observación de quién
Ésta es la pregunta que decide si el sistema entra o no entra a su empresa, y la contestación no puede ser «se configura». Se configura, sí, pero el criterio se decide antes y se escribe. El sistema declara el suyo en una frase corta: cada jefe ve solamente a su equipo, y Recursos Humanos audita. Lo que sigue es esa frase desarrollada en una tabla de alcance, que es la forma en que se lleva a un comité.
Conviene notar el renglón de la dirección general, porque es donde se rompen casi todos los modelos de permiso. La dirección tiene interés legítimo en el agregado —cuántas horas se recuperan, en qué áreas, con qué tareas— y no tiene por qué ver el detalle individual de una persona a la que no supervisa directamente. Separar el agregado del detalle nominal es lo que permite sostener el sistema frente a la pregunta incómoda.
Rol · qué observación puede ver · qué no puede ver
| Rol | Qué ve | Qué no ve | Para qué |
|---|---|---|---|
| La persona observada | Su propio registro completo: tareas, tiempos, pausas y sugerencias recibidas | El registro de sus compañeros | Ejercer sus derechos y comprobar que el sistema hace lo que dice |
| Jefe de área | El detalle de las personas de su propio equipo y el agregado de su área | Personas de otras áreas, ni siquiera en agregado nominal | Decidir qué tarea de su área conviene automatizar primero |
| Recursos Humanos, que audita | La bitácora de consultas, las firmas de la política de uso y el agregado por área | El contenido de las capturas, que el sistema no guarda | Comprobar que el acceso por rol se respeta y que el consentimiento está documentado |
| Dirección general | El agregado: horas recuperadas por área, tareas candidatas, avance de las automatizaciones | El detalle individual de personas a las que no supervisa | Decidir dónde invertir el esfuerzo de automatización |
| Área de sistemas | El estado de la instalación, los equipos cubiertos y los errores técnicos | El registro de productividad de ninguna persona | Operar la instalación sin convertirse en un observador más |
| Quien administra el sistema | La configuración: qué se observa, qué se excluye, quién tiene acceso | Nada que no quede en la bitácora: cada cambio de configuración deja solicitud, autor y hora | Que el administrador no sea el único punto sin control |
Fuente: alcance declarado en el brochure de Relevo, sección de privacidad —acceso por rol, auditoría de Recursos Humanos— desarrollado sobre los roles del sistema · el reparto concreto es parámetro de su política y se configura.
Si en la primera reunión con el comité no puede enseñar esta tabla llena, el proyecto no está listo para empezar. Y no es un problema de software.
El permiso, donde de verdad vive: 568 filas y 61 accesos
El permiso no se resuelve escondiendo botones. Se resuelve en la capa de datos: el menú, las pantallas y las operaciones que un usuario ve se arman preguntando por su rol antes de dibujar nada. La plataforma tiene un procedimiento dedicado a eso y el permiso vive en una tabla propia que cruza pantalla, funcionalidad y rol (permiso_pantalla_funcionalidad; el procedimiento). Los permisos no se capturan a mano pantalla por pantalla: una tarea del motor los asigna por rol y siembra los catálogos, y el sistema incluye un tipo de pantalla de configuración con árbol de permisos para revisarlos y moverlos después.
En el proyecto de gestión logística que la plataforma tiene generado, eso está medido y se puede enseñar. Son ocho roles, 61 accesos declarados de rol a pantalla sobre 178 pantallas, y 568 filas que cruzan estado, rol y siete permisos distintos: consultar, dar de alta, modificar, dar de baja, exportar, imprimir y configurar. El detalle está en las matrices de estado; aquí interesa una lectura concreta de esas filas.
La lectura es ésta: de las 18 filas del rol que captura en la calle, ninguna tiene permiso de exportación, mientras que las 122 filas del rol de administración lo tienen todas. Quien captura no se lleva el dato; quien audita, sí. Eso es un modelo de permiso que se puede auditar, en lugar de una declaración de intenciones.
El modelo de permiso, componente por componente
| Control | Qué hace | Dónde está la evidencia |
|---|---|---|
| Autenticación con servidor propio | Emite el token de sesión contra el directorio de usuarios; el resto de los servicios no autentica por su cuenta | Portal y ejecución del motor |
| Token firmado y de vida corta | Cada llamada al servicio viaja con el token; el token caduca y se renueva sin volver a pedir la contraseña | Vida del token y renovación desde la capa intermedia |
| Una sola puerta de entrada al dato | Los controladores de servicio se apoyan en una misma clase base: la pantalla no habla con la base de datos | Código de la plataforma |
| Menú y pantallas resueltos por rol | Lo que un usuario ve se arma preguntando por su rol antes de dibujar la pantalla | Código de la plataforma |
| Permiso por estado y por rol | Para cada estado de cada ciclo de vida, qué rol puede moverlo y qué puede hacer mientras la cosa está ahí | 568 filas de rol por estado, el proyecto de este sistema en el motor — corte del 27 de septiembre de 2026, 13:53:43 |
| Pantalla de configuración de permisos | Árbol de permisos para revisar y mover el reparto después del arranque | Código de la plataforma |
Fuente: evidencia de plataforma de la casa y motor de la casa, el proyecto de este sistema, corte de servidor del 27 de septiembre de 2026, 13:53:43 · verificado al 27 de septiembre de 2026.
La bitácora: quién cambió qué, y quién consultó qué
El motor de estados de la plataforma no deja cambiar un estado sin registrarlo. Cada transición pasa por una validación que comprueba el estado de origen, el estado de destino y el rol del usuario, y al ejecutarse escribe dos rastros: el historial de la entidad —con estado anterior y estado nuevo— y una bitácora con la operación marcada como cambio de estado, el valor anterior y el valor nuevo. Las citas exactas son para la validación, para la de rol, para la ejecución, para el historial y para la bitácora.
Dos condiciones más viajan con la transición y no son decorativas: requiere comentario y requiere evidencia. Traducido a un sistema que observa trabajo: hay decisiones que no se pueden cerrar sin que alguien escriba por qué. Apagar la observación de un equipo, ampliar el alcance a un proceso nuevo o dar acceso a un jefe sobre un área que no era la suya son exactamente ese tipo de decisión.
Y aquí hace falta una distinción que casi nunca se hace y que en este sistema es central. La bitácora de cambio no es la bitácora de consulta. Saber quién modificó la configuración de la observación es un control; saber quién abrió el registro de una persona es otro, y es el que la persona observada va a pedir. El primero está verificado en el código con las citas de arriba. El segundo se declara como requisito de esta página y aparece en la tabla de pendientes con lo que hoy sí está medido y lo que no.
La pregunta del comité no será «¿tienen bitácora?». Será «enséñeme quién abrió mi registro la semana pasada». Eso debe ser una consulta, no una investigación.
La plataforma genera además pantallas de auditoría como tipo propio —con indicadores arriba, línea de tiempo y rejilla de detalle, detecta campos de auditoría al generar cada pantalla y publica en la documentación del proyecto dos piezas que un auditor pide por su nombre: el modelo de seguridad con su matriz de permisos y la matriz de trazabilidad y auditoría.
Retención, respaldo, ambientes y cifrado
En este sistema la retención no la fija una norma sectorial, y eso hay que decirlo con claridad en lugar de inventar un plazo. No hay una regla que obligue a conservar durante N años el registro de cuántos segundos tardó un puesto en capturar una guía. Lo que sí hay es el principio de la ley: el dato personal no se conserva más allá de lo que la finalidad declarada necesita. De modo que el periodo lo fija su empresa, por escrito, y el sistema lo hace cumplir.
Hay un criterio práctico que conviene considerar al fijarlo. El detalle nominal —qué persona hizo qué tarea a qué hora— sirve para detectar la tarea repetida y para medir el tiempo liberado; cumplida esa finalidad, el agregado por puesto y por equipo sigue siendo útil y el detalle nominal ya no. Retener el agregado y dejar caducar el detalle es la decisión que más reduce el riesgo sin perder el indicador.
Sobre ambientes y respaldo, la plataforma separa la base de cada proyecto —una base por sistema generado— y trata la creación del sitio, la base y los servicios como pasos con su propio registro. Todo cambio aplicado sobre un sistema en operación pasa por una comprobación previa, un respaldo del artefacto que se va a tocar, el cambio, el posproceso y una instantánea de versión con su número. Dicho con precisión, para que nadie lea de más: ese respaldo es el del cambio, no el respaldo corporativo de su base de datos.
Sobre cifrado, esta página dice lo que puede sostener y no más. El enmascaramiento de datos sensibles en el equipo antes de que el dato salga es un control declarado del producto, y es el que más importa aquí. El cifrado en tránsito y en reposo depende de la infraestructura en la que el sistema corre y de su configuración; el esquema concreto no se publica en esta página porque no está verificado en la evidencia revisada, y aparece en la tabla de pendientes. Un proveedor que le enumere algoritmos sin decirle dónde los verificó le está vendiendo una lista, no un control.
Lo que no se publica, porque no está medido
Esta tabla es parte de la página. En un sistema que observa personas, la tentación de enumerar controles que suenan bien es mayor que en cualquier otro, y ceder a ella es lo que destruye la confianza en la primera pregunta técnica. Lo que no está verificado se declara con su conteo.
Pendiente de verificación · qué falta y por qué no se afirma
| Qué falta | Situación al 27 de septiembre de 2026 | Por qué no se publica |
|---|---|---|
| Bitácora de consulta, no sólo de cambio | El registro del cambio de estado está verificado en código con valor anterior y nuevo. El registro de cada consulta al expediente de una persona no está verificado en la evidencia revisada | Es el control que la persona observada va a pedir primero. Se declara como requisito y no se afirma como hecho |
| Esquema de autenticación concreto por servicio | El campo que declara el esquema de autenticación viene vacío en los 2,891 puntos de servicio revisados del inventario del motor | Se afirma que hay autenticación con token firmado, citada en código; no se atribuye un esquema por servicio que la base no declara |
| Esquema de cifrado en tránsito y en reposo | No verificado en la evidencia de plataforma revisada | Depende de la infraestructura y de su configuración. Enumerar algoritmos sin fuente sería exactamente lo que esta capa no hace |
| Calificación de calidad del producto | El motor evalúa los ocho atributos del estándar de calidad de producto de software, y la calificación está vacía al cien por ciento | Publicable es que se evalúan los ocho atributos. Nunca una nota |
| Reglas de negocio del proyecto generado | 0 reglas de negocio dadas de alta en el proyecto de este sistema en el motor al corte del 27 de septiembre de 2026, 13:53:43 | Las validaciones que se publican son las condiciones de las transiciones, no un catálogo de reglas que no existe |
| Ciclo de vida del propio expediente de observación | Los diecinueve ciclos de vida del proyecto son del negocio logístico. La tarea observada, la oportunidad detectada y la automatización aprendida no tienen ciclo de vida dado de alta | El expediente de la observación se describe por lo que el producto declara, no como dato del motor |
| Agentes de inteligencia artificial del proyecto | 0 agentes dados de alta en el proyecto de este sistema en el motor | Lo que el producto declara sobre aprender por observación se atribuye a su propio material, nunca al motor |
| Periodo de retención | No hay norma sectorial que lo fije para la observación de productividad | Lo fija su empresa por escrito. Publicar un plazo aquí sería inventar una obligación que no existe |
Conteos medidos contra la base del motor de la casa y contra el inventario de plataforma, con corte del propio servidor del 27 de septiembre de 2026, 13:53:43. Esta tabla se actualiza cuando la evidencia cambia, no cuando conviene.
Control del sistema y obligación del patrón
Ésta es la tabla con la que cierra la página, y es deliberado. En un sistema que observa el trabajo de personas, la peor confusión posible es creer que comprar el software resuelve el deber legal. No lo resuelve, y ningún proveedor puede asumirlo por usted: el responsable del tratamiento de los datos personales de sus trabajadores es su empresa.
Lo que el sistema puede hacer es que cumplir sea posible y que incumplir sea visible. Eso es mucho, y es distinto de cumplir.
Quién responde por qué
| Asunto | Del sistema | Del patrón |
|---|---|---|
| Aviso de privacidad y política de uso | Los presenta en el equipo y guarda la firma con su fecha | Redactarlos, mantenerlos vigentes y nombrar a la autoridad correcta |
| Finalidad del tratamiento | La hace exigible: lo que está fuera de la finalidad no se observa | Declararla, por escrito y por proceso. Una finalidad genérica no es una finalidad |
| Minimización | Registra el proceso y no el contenido; enmascara lo sensible en el equipo | Decidir qué procesos se observan y qué queda excluido |
| Consentimiento | Documenta quién firmó y cuándo | Obtenerlo sin que sea la única base del tratamiento, y no tratarlo como un trámite de alta |
| Derechos del titular | Entrega el registro y la evidencia que la respuesta necesita | Contestar en tiempo, y decidir de antemano quién contesta |
| Acceso por rol | El modelo de permiso, la configuración y la bitácora del cambio | La decisión de negocio: quién ve a quién, y sostenerla ante el comité |
| Bitácora | El registro automático del cambio, con valor anterior y valor nuevo | Revisarla. Una bitácora que nadie lee es un archivo, no un control |
| Retención | Hace cumplir el periodo que se le configure | Fijar el periodo, y separar el agregado del detalle nominal |
| Respaldo y recuperación | Respaldo del artefacto en cada cambio aplicado, con su versión | Política de respaldo, prueba de restauración y plan de recuperación |
| Relación laboral | Nada. El sistema no evalúa personas ni sustenta una decisión sobre nadie | Toda. Lo que se haga con el dato de productividad es una decisión del patrón, y no es delegable a un software |
Reparto de responsabilidad declarado, sobre la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, DOF 20 de marzo de 2025 · 27 de septiembre de 2026.
El sistema puede hacer que cumplir sea posible y que incumplir sea visible. Cumplir lo hace usted, y el último renglón de esa tabla no se puede comprar.
Preguntas frecuentes
¿El sistema lee el correo, el chat o los archivos de mi equipo?
No. El criterio declarado es registrar los pasos del proceso, no la información que pasa por ellos: se guarda que se abrió una pantalla de captura, en qué orden se llenaron los campos y cuánto tardó, no el contenido del campo. El contenido de comunicaciones privadas no forma parte de la finalidad declarada, y la finalidad es el límite del tratamiento. El alcance concreto de exclusión por aplicación y por horario es parámetro de su política y se configura.
¿Ante qué autoridad se ejercen los derechos de mis trabajadores?
Ante la Secretaría Anticorrupción y Buen Gobierno. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente se publicó en el Diario Oficial el 20 de marzo de 2025, entró en vigor el 21 de marzo de 2025 y fue reformada el 14 de noviembre de 2025; sustituyó a la ley de 2010 y trasladó la competencia. El INAI ya no es la autoridad. Si su política de uso es anterior al 21 de marzo de 2025, ese documento hay que revisarlo.
¿Basta con que el trabajador firme la política de uso?
Es necesario y no es suficiente. Entre el patrón y el trabajador no hay simetría, de modo que una firma obtenida en el alta no sostiene por sí sola un tratamiento amplio. Lo que lo sostiene es la finalidad declarada por proceso, la minimización —registrar el paso y no el contenido, enmascarar lo sensible en el equipo, permitir la pausa— y la posibilidad real de que la persona observada compruebe qué se registra de ella.
¿Quién puede ver mi registro individual?
El criterio declarado es que cada jefe ve solamente a su equipo y que Recursos Humanos audita. La dirección general ve el agregado por área, no el detalle nominal de personas a las que no supervisa. El área de sistemas ve el estado de la instalación, no la productividad de nadie. Y la propia persona observada ve su registro completo, con el mismo detalle que quien la supervisa. El reparto concreto se configura y se sostiene por escrito.
¿Qué queda registrado cuando alguien cambia la configuración de la observación?
Cada cambio deja solicitud, autor, hora, comentario cuando el nivel lo exige, respaldo del artefacto tocado e instantánea de versión. El motor de estados escribe además el historial con estado anterior y estado nuevo y una bitácora con el valor anterior y el valor nuevo, y hay transiciones que exigen comentario o evidencia para poder ejecutarse. Ampliar el alcance de la observación o dar acceso a un jefe sobre un área nueva son decisiones de ese tipo. El recorrido completo está en los cambios, en la sesión.
¿Cuánto tiempo se conserva lo observado?
El que su empresa fije por escrito. No hay norma sectorial que imponga un plazo para el registro de productividad, y publicar uno aquí sería inventar una obligación que no existe. El principio de la ley es que el dato personal no se conserva más allá de lo que la finalidad declarada necesita. El criterio práctico que más reduce el riesgo es retener el agregado por puesto y por equipo, y dejar caducar el detalle nominal una vez que la tarea ya se automatizó.
Referencias
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares. Publicada en el Diario Oficial de la Federación el 20 de marzo de 2025; en vigor el 21 de marzo de 2025; reforma publicada el 14 de noviembre de 2025. Sustituye a la ley del 5 de julio de 2010. Autoridad: Secretaría Anticorrupción y Buen Gobierno. Consultada el 27 de septiembre de 2026. ↗
- Relevo · brochure de logística, 10 páginas, sección de privacidad: los seis controles declarados —aviso visible, consentimiento firmado, enmascaramiento de datos sensibles antes de salir del equipo, botón de pausa, registro del proceso y no del contenido, y acceso por rol con auditoría de Recursos Humanos. Origen de todo lo que esta página afirma del producto.
- Evidencia de plataforma de la casa: autenticación y ejecución del portal, vida y renovación del token, clase base de los controladores de servicio, permiso por pantalla, funcionalidad y rol y procedimiento de menú por rol, asignación de permisos por el motor, pantalla de configuración con árbol de permisos, pantallas de auditoría como tipo, detección de campos de auditoría, modelo de seguridad y matriz de trazabilidad en la documentación del proyecto, separación de base por proyecto y respaldo con instantánea de versión por cambio. Verificado el 27 de septiembre de 2026.
- Motor de estados en ejecución dentro del sistema generado: — validación de transición y de rol, ejecución, historial de la entidad, bitácora con valor anterior y nuevo, exigencia de comentario y de evidencia. Verificado el 27 de septiembre de 2026.
- Motor el motor de la casa, base del motor de la casa, el proyecto de este sistema: ocho roles, 61 accesos declarados de rol a pantalla, 568 filas de rol por estado con siete permisos, 0 reglas de negocio y 0 agentes de inteligencia artificial dados de alta. Corte tomado del propio servidor: 27 de septiembre de 2026, 13:53:43.
El modelo
Primero ve su sistema funcionando, sin costo y sin compromiso. Después decide si lo compra o lo renta.
No es un demo: es Relevo con sus procesos, sus áreas y su operación dentro. Entra, lo recorre y lo usa. Verlo no cuesta nada y no lo compromete a nada. Cuando decida, cobramos por resultados, no por entregables.