Relevo · el modelo de datos
Aquí hay dos modelos de datos. El del embarque se defiende ante un auditor; el del aprendizaje se defiende ante la persona observada.
Un embarque se modela como cualquier operación: folio, trayectos, documentos, estados. Lo que no se modela así es la observación del trabajo, porque ahí cada fila concierne a una persona. Esta página pone las dos mitades una al lado de la otra, con su llave, sus campos, su retención y quién fija ese plazo.
Por qué este sistema tiene dos modelos de datos y no uno
El primer modelo es el de la operación: el embarque con su folio, los trayectos en que se parte, el proveedor asignado a cada uno, los documentos que lo amparan y los estados por los que pasa. Ese modelo se defiende ante un auditor, ante la autoridad aduanera y ante el cliente que exige la prueba de entrega. Sus reglas son conocidas: llave estable, historial inmutable de transiciones y plazos de conservación que fija la ley fiscal.
El segundo es el del aprendizaje: la tarea observada, el patrón que se repite, la oportunidad priorizada, la propuesta de automatización, su autorización y cada ejecución. Ese modelo se defiende ante otra persona: la que fue observada. Y sus reglas son distintas, porque cada fila concierne a alguien. La llave no puede ser una persona, la retención la fija la finalidad y no un número redondo, y hay campos que la decisión correcta es no tener.
Mezclar los dos modelos es el error que convierte un sistema de automatización en un archivo de vigilancia sin que nadie lo decida. Ocurre siempre de la misma manera: alguien añade al registro de la tarea observada el identificador de la persona «para poder revisar casos concretos», y a partir de ahí existe una consulta que antes no existía. Esta página separa las dos mitades a propósito, y dice en cada una qué se guarda y qué no.
El tercer bloque, más pequeño y fácil de olvidar, es el de las entidades de gobierno: el aviso firmado, el estado del consentimiento, la bitácora de consulta y el registro de autorización de cada automatización. Son cuatro entidades que nadie pide en un requerimiento funcional y que son las únicas con las que se contesta la pregunta de por qué se observó.
La llave del trabajo observado es el puesto y la tarea. Si la llave fuera la persona, el modelo ya habría elegido ser un expediente de conducta.
Un modelo de datos que separa la operación del aprendizaje puede contestar a un auditor y a un empleado con el mismo sistema y sin contradecirse. Uno que los mezcla tiene que elegir a quién decepciona.
El modelo de la operación
Las nueve entidades del embarque, con su llave, sus campos y su retención
Las nueve de la tabla son las que sostienen un embarque internacional de principio a fin y las que un tercero va a pedir. La columna de retención dice el plazo, y la última dice quién lo fija: en siete de las nueve es la ley fiscal, por la vía del artículo 30 del Código Fiscal de la Federación, al que la Ley Aduanera remite expresamente para el expediente electrónico del pedimento.
Entidad · llave · campos que la definen · retención · qué la fija
| Entidad | Llave | Campos que la definen | Retención | Qué fija el plazo |
|---|---|---|---|---|
| Solicitud de servicio | Folio interno único, generado por secuencia controlada · REL-2026-118 | Cliente del catálogo, orden de compra del cliente con su documento adjunto, origen, destino final, fecha requerida de recolección, observaciones especiales, plantilla de ruta aplicada, estado de la solicitud | Cinco años desde la declaración relacionada | Artículo 30 del Código Fiscal de la Federación |
| Embarque | Folio del embarque, irrepetible y permanente | Solicitud de origen, conjunto de trayectos, estado del ciclo de vida completo, fechas de apertura y cierre, expediente documental asociado | Cinco años desde la declaración relacionada | Artículo 30 del Código Fiscal de la Federación |
| Trayecto | Folio del embarque más número de segmento | Tipo de trayecto según la jurisdicción del segmento, origen y destino del tramo, proveedor asignado, tarifa pactada, activos asignados, estado de ejecución, bloqueo lógico respecto del trayecto anterior | Cinco años desde la declaración relacionada | Artículo 30 del Código Fiscal de la Federación |
| Documento del cliente | Folio del embarque más tipo de documento | Tipo, documento adjunto, metadatos fiscales y de negocio, fecha de recepción, vínculo permanente al embarque | Cinco años, con el cómputo desplazado si hubo recurso o juicio | Artículo 30 del Código Fiscal de la Federación, párrafos tercero y cuarto |
| Acuerdo de confirmación de carga | Folio del trayecto | Proveedor, tarifa pactada, instrucciones de seguridad, requisitos de la caja, estado de aprobación y envío, fecha de generación automática al asignar proveedor | Mientras subsista la relación contractual, y después hasta la prescripción | El contrato, con el estado de bloqueo del artículo 2, fracción III |
| Comprobante fiscal del traslado | Folio del trayecto más identificador del comprobante | Estado del comprobante, trayecto amparado, fecha de emisión, vínculo al expediente del embarque. El sistema no lo emite: registra que existe y con qué captura se armó | Cinco años desde la declaración relacionada | Artículo 30 del Código Fiscal de la Federación |
| Expediente electrónico del despacho | Número del pedimento o documento aduanero | Documento aduanero en el formato en que se transmitió, anexos, acuses electrónicos, constancia de entrega al cliente | Los plazos del Código Fiscal, como parte de la contabilidad | Ley Aduanera, artículos 6º, 36-A y 162, texto vigente con la reforma del 19 de noviembre de 2025 |
| Prueba de entrega | Folio del trayecto de destino | Documentación de confirmación de descarga, fecha y hora, conciliación con la facturación, estado de la conciliación | Cinco años, y mientras el cobro esté abierto | El contrato con el cliente y el artículo 30 del Código Fiscal |
| Incidencia del trayecto | Folio del trayecto más consecutivo de incidencia | Tipo, severidad, escalamiento, responsable, resolución, historial inmutable de cambios | Mientras pueda determinarse responsabilidad, y después cancelación | El estado de bloqueo del artículo 2, fracción III, con el plazo de prescripción |
Entidades y campos: diccionario de datos del proyecto de este sistema en la base del motor de la casa, con el propósito registrado de cada una. Plazos: Código Fiscal de la Federación, artículo 30, y Ley Aduanera, artículos 6º, 36-A y 162, textos vigentes leídos el 27 de septiembre de 2026.Datos de ejemplo: folio y código de puesto, nunca una persona. Corte tomado del reloj del propio servidor del motor: 27 de septiembre de 2026, 13:56:27.
Siete de las nueve tienen el mismo reloj, y eso simplifica la depuración: el expediente del embarque se depura entero o no se depura, y su reloj arranca con la declaración, no con la fecha de captura.
El modelo de la observación
Las nueve entidades del aprendizaje, con su finalidad declarada
Estas nueve son las que este sistema añade y las que los sistemas de logística no tienen. Cada una lleva algo que en el modelo de la operación no hace falta: la finalidad declarada. La razón es el artículo 12 de la ley de datos personales, que limita el tratamiento a lo necesario, adecuado y relevante respecto de las finalidades del aviso. Si la finalidad no está escrita al lado de la entidad, no hay forma de decidir cuándo se depura.
Léase con atención la primera fila, porque es la que decide todo lo demás: la unidad de la observación es puesto por tarea por día, no persona por minuto. De esa elección salen las dos cosas que hacen defendible el sistema: que el número que produce sea la hora recuperable de una tarea, y que no exista ninguna vista de una persona a lo largo de su jornada.
Entidad · llave · qué guarda · finalidad declarada · retención
| Entidad | Llave | Qué guarda | Finalidad declarada | Retención |
|---|---|---|---|---|
| Tarea observada | Código de puesto más código de tarea más fecha · PUE-07 · TAR-GUIA-01 · 2026-09-21 | Aplicación y pantalla en uso, secuencia de pasos de la tarea, número de repeticiones del día, duración medida por repetición. Sin campo de contenido | Detectar la repetición para automatizarla y medir el tiempo que consume | Hasta que la tarea queda automatizada y su línea base medida |
| Sesión de observación | Equipo más intervalo | Equipo, intervalo de observación, versión del aviso vigente en ese intervalo, interrupciones por pausa declarada como periodo no observado | Acreditar con qué permiso se observó cada intervalo | Mientras pueda determinarse responsabilidad, en estado de bloqueo |
| Patrón | Código de patrón | Secuencia canónica de pasos de una tarea, variantes detectadas, pantallas implicadas, condiciones de inicio y de fin | Describir la tarea sin describir a nadie: el patrón es de la tarea, no del puesto | Vida de la tarea; se retira cuando la pantalla de origen cambia |
| Oportunidad | Código de patrón más periodo | Veces al día, segundos por vez, hora recuperable calculada, orden de prioridad frente a las demás oportunidades | Ordenar por dónde empezar: el tablero de oportunidades del sistema | Serie histórica, agregada por tarea y sin detalle por puesto |
| Propuesta de automatización | Código de propuesta | Patrón que automatiza, pasos que ejecutaría, pasos que dejaría al operador, condiciones en que se detiene, estado de la propuesta | Someter a decisión humana lo que el sistema va a hacer solo | Vida de la automatización, y después como antecedente |
| Autorización | Código de propuesta más consecutivo | Quién autorizó con su rol, fecha y hora, alcance autorizado, condiciones impuestas, motivo si se negó | Acreditar que ninguna consecuencia se produce sin intervención humana | Mientras exista la automatización, y después como antecedente |
| Automatización activa | Código de automatización | Propuesta autorizada de origen, estado de activación, condiciones de detención, responsable operativo, quién puede apagarla | Ejecutar la tarea repetida de principio a fin | Vida de la automatización |
| Ejecución | Código de automatización más consecutivo | Fecha y hora, resultado, desviación respecto del patrón, si se detuvo y por qué, referencia al folio de la operación que produjo | Probar qué hizo el sistema y qué no, caso por caso | Mientras pueda determinarse responsabilidad, en estado de bloqueo |
| Hora liberada | Código de tarea más periodo | Horas liberadas por tarea y por equipo en el periodo, contra la línea base medida antes de automatizar | Cuantificar el número del sistema: las horas recuperadas al día | Serie histórica, agregada y sin detalle por puesto |
Modelo del sistema, derivado de las cuatro capacidades del ciclo del brochure de Relevo —observa, aprende, sugiere, ejecuta— y de los seis controles de privacidad de su página 8. La columna de finalidad y la de retención responden a los artículos 11, 12 y 15 de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, texto vigente publicado el 20 de marzo de 2025. Datos de ejemplo: folio y código de puesto, nunca una persona.
La entidad de autorización es la que sostiene la página de regulación: mientras cada automatización tenga un autorizador con nombre y hora, el sistema no produce efectos sin intervención humana.
Campo por campo
Lo delicado: qué se guarda de la observación del trabajo de una persona
Esta es la tabla por la que existe la página. Va campo por campo: qué se guarda, qué expresamente no se guarda, con qué finalidad declarada, cuánto tiempo y quién fija ese plazo. Está escrita así porque es la única forma de contestar sin discutir la pregunta que un empleado o su representación van a hacer, que no es «¿me vigilan?» sino «¿qué tienen de mí?».
La columna de lo que no se guarda no es un compromiso comercial: es el límite de la finalidad, y tiene una consecuencia técnica. Un campo que no existe no se puede consultar por error, no se puede filtrar en una vulneración y no se puede pedir en un juicio. La decisión más protectora de un modelo de datos es la de no tener el campo.
La culpa de que el mismo dato se capture trescientas cuarenta veces al día no es de quien teclea. Es del modelo con el que se le vendió una herramienta que cuenta el problema y no lo quita.
Qué se guarda · qué no · finalidad · retención · quién fija el plazo
| Qué se guarda | Qué no se guarda | Finalidad declarada | Retención | Quién fija el plazo |
|---|---|---|---|---|
| Código del puesto y código del equipo | Nombre de la persona, su registro fiscal, su clave de registro de población y su correo: ninguno vive en el registro de la observación | Poder agrupar la carga de trabajo por puesto y por equipo | Vida del puesto en el catálogo | El dueño del proceso, declarado en el aviso |
| Aplicación y pantalla en uso durante la tarea | Todo lo que ocurre en aplicaciones fuera del catálogo de observación, y lo que ocurre con la pausa activada | Identificar dónde se ejecuta la tarea repetida | Hasta que la tarea queda automatizada | La finalidad, con el artículo 12 |
| Secuencia de pasos de la tarea | El contenido de los campos que se capturaron: ni el dato del cliente, ni el número de la guía, ni el texto del documento | Reproducir el proceso para poder ejecutarlo solo | Vida del patrón; se retira cuando la pantalla cambia | La finalidad, con el artículo 12 |
| Marca de tiempo y duración por repetición | Ritmo personal presentado como rendimiento, comparación entre personas del mismo puesto y cualquier calificación | Calcular veces al día por segundos por vez, que es la hora recuperable | Detalle hasta la automatización; agregado por tarea, en serie histórica | La finalidad, con el artículo 12 |
| Periodos de pausa declarada | El motivo de la pausa, y cualquier conteo de pausas atribuible a una persona | Delimitar qué intervalo no se observó, para que el registro sea exacto | Igual que la sesión de observación | La finalidad y el control de pausa declarado |
| Versión del aviso de privacidad firmada | Nada adicional: es la constancia del permiso, no un expediente de conducta | Acreditar la base del tratamiento en el periodo observado | Mientras pueda determinarse responsabilidad, en bloqueo | El artículo 2, fracción III, con la prescripción |
| Bitácora de quién consultó lo observado | Nada se omite aquí: esta tabla registra a quien consulta, incluidos los jefes | Poder contestar «¿quién vio lo mío y cuándo?» | El plazo de prescripción de la responsabilidad que documenta | Seguridad de la información, con el área jurídica |
| Solicitudes de acceso, rectificación, cancelación u oposición | El contenido de la solicitud no se usa para nada distinto de atenderla | Atender el derecho en el plazo de veinte días del artículo 31 | Mientras pueda acreditarse que se atendió | El artículo 31 y la prescripción |
Modelo del sistema sobre los seis controles de privacidad declarados en el brochure de Relevo, página 8, y sobre los artículos 2 fracción III, 11, 12, 15, 21 a 26 y 31 de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, texto vigente publicado el 20 de marzo de 2025 con la reforma del 14 de noviembre de 2025, leído el 27 de septiembre de 2026. Datos de ejemplo: folio y código de puesto, nunca una persona.
Con esta tabla delante, una reunión con la representación del personal dura veinte minutos en lugar de tres semanas, porque no hay nada que averiguar: está escrito qué hay y qué no.
Las llaves del modelo, y por qué ninguna es una persona
Una llave no es un detalle técnico: es una decisión sobre qué se puede consultar. Si la llave del trabajo observado fuera el identificador de una persona, existiría por construcción la consulta «todo lo de esta persona», y a partir de ahí ninguna política la evita. Como la llave es el puesto y la tarea, la consulta natural es «todo lo de esta tarea», y la otra hay que fabricarla a propósito.
La tabla enumera las llaves reales del modelo con su forma de ejemplo. Los ejemplos usan folio y código; ninguno usa un nombre, un registro fiscal ni un correo, ni aquí ni en el sistema abierto.
Qué se identifica · llave · forma de ejemplo · qué hace estable a la llave
| Qué se identifica | Llave | Forma de ejemplo | Qué la hace estable |
|---|---|---|---|
| El embarque | Folio interno generado por secuencia controlada | REL-2026-118 | Se genera una vez, es irrepetible y no se reasigna nunca |
| El trayecto | Folio del embarque más número de segmento | REL-2026-118 / 02 | El segmento no cambia de número aunque cambie el proveedor asignado |
| El trabajo observado | Código de puesto más código de tarea más fecha | PUE-07 · TAR-GUIA-01 · 2026-09-21 | El puesto sobrevive a la rotación de personas; la persona no es parte de la llave |
| El patrón de la tarea | Código de patrón con su versión | PAT-GUIA-01 v3 | Cada cambio de la pantalla de origen produce versión nueva, no sobrescribe |
| La automatización | Código de automatización | AUT-GUIA-01 | Se liga a la autorización que la habilitó, y no existe sin ella |
| La ejecución | Código de automatización más consecutivo | AUT-GUIA-01 / 004512 | Consecutivo sin huecos: un hueco es una señal, no un detalle |
| El permiso | Código de puesto más versión del aviso | PUE-07 · aviso v4 | La versión del aviso queda congelada; un cambio de aviso no reescribe el pasado |
Llaves del modelo del sistema, coherentes con la generación automática de folio único por secuencia controlada que el proyecto de este sistema en el motor tiene registrada como proceso.Datos de ejemplo: folio y código de puesto, nunca una persona.
Si alguna vez alguien propone añadir el identificador de la persona a la llave del trabajo observado, esa es la conversación que hay que tener, y no la de la política de privacidad.
Cuánto se guarda
Los tres relojes de la retención, y el estado intermedio que la ley define
El primer reloj lo fija la finalidad. No trae número porque no lo puede traer: el artículo 12 pide que el tratamiento sea el necesario, adecuado y relevante respecto de las finalidades del aviso, y aquí la finalidad es detectar la repetición para automatizarla. Cuando la tarea ya está automatizada y su línea base medida, el detalle por puesto dejó de ser necesario. Se conserva el agregado por tarea, que es lo que sostiene el número del sistema, y el detalle se depura.
El segundo lo fija la prescripción, y la propia ley define el estado en que el dato espera. Su artículo 2, fracción III llama bloqueo a la identificación y conservación del dato una vez cumplida la finalidad, con el único propósito de determinar posibles responsabilidades, hasta el plazo de prescripción legal o contractual; durante ese periodo el dato no puede ser objeto de tratamiento, transcurrido, se cancela. Un modelo sin ese estado sólo puede elegir entre borrar antes de tiempo o conservar sin base.
El tercero es el fiscal y aduanero, y ese sí trae número: cinco años del artículo 30 del Código Fiscal de la Federación, contados desde que se presentaron o debieron presentarse las declaraciones relacionadas. Con dos desplazamientos que hay que implementar y que casi nunca están: si los efectos fiscales del acto se prolongan en el tiempo, el cómputo empieza con la declaración del último ejercicio en que se produjeron; y si sobre el concepto se promovió recurso o juicio, se cuenta desde que quede firme la resolución que le ponga fin. La Ley Aduanera remite a esos mismos plazos para el expediente electrónico del pedimento.
La consecuencia práctica de tener los tres relojes en el modelo es una sola, y es grande: una solicitud de cancelación se puede contestar en días. Lo que está bajo el reloj fiscal no se cancela, porque el último párrafo del artículo 26 excluye la oposición cuando el tratamiento es necesario para cumplir una obligación legal. Lo que está bajo el reloj de la finalidad, sí. Y lo que está en bloqueo se queda quieto, sin tratarse, hasta que prescriba.
Tres relojes, un estado intermedio definido por la ley y un responsable con nombre para cada uno. Eso es lo que convierte la depuración en una tarea programada y no en una decisión que nadie quiere firmar.
La prueba, transcrita
Las cincuenta y tres entidades que el motor tiene dadas de alta
Lo anterior es el modelo. Esto es el inventario: el diccionario de datos del proyecto que la casa tiene generado para este sistema registra cincuenta y tres entidades, cada una con su propósito escrito y su módulo. La tabla transcribe dieciséis, las que sostienen el expediente del embarque, con el propósito tal como está registrado, resumido para que quepa.
Conviene señalar un detalle del inventario que importa justo en una página sobre datos personales. Cinco de las cincuenta y tres entidades son entidades de rol: guardan la información de negocio del ejecutivo que captura, del coordinador de operaciones, del gerente administrativo, del monitorista de tráfico y del oficial de cumplimiento. Es decir, el modelo generado sí distingue a los actores, y ahí es donde vive lo que concierne a una persona identificada. Esa separación es la que permite que el registro de la tarea observada no la necesite.
Entidad registrada · módulo · propósito registrado
| Entidad registrada | Módulo | Propósito registrado (resumido) |
|---|---|---|
| solicitud_embarque | Programación de embarques | Registro central de solicitudes de servicio de transporte con su ciclo de vida completo |
| embarque | Asignación de proveedores | Registro principal del embarque con folio único que agrupa todos los trayectos y su ciclo de vida operativo completo |
| trayecto | Asignación de proveedores | Cada segmento del embarque con su proveedor asignado, recursos y estado de ejecución. Es la entidad con más relaciones salientes del modelo |
| orden_compra | Programación de embarques | Documento de orden de compra emitido por el cliente con sus metadatos fiscales y de negocio |
| plantilla_ruta | Programación de embarques | Configuraciones predefinidas de rutas recurrentes para agilizar la captura de solicitudes |
| observacion_especial_embarque | Programación de embarques | Requerimientos adicionales capturados para un embarque que no están cubiertos por la plantilla estándar |
| load_confirmation_agreement | Asignación de proveedores | Acuerdo de confirmación de carga generado automáticamente para cada trayecto asignado a un proveedor |
| ajuste_tarifa | Asignación de proveedores | Propuestas de ajuste a la tarifa precargada con su justificación y estado de aprobación |
| estado_trayecto | Seguimiento y cierre | Registro inmutable del historial de transiciones de estado de cada trayecto, para auditoría y trazabilidad |
| cfdi_trayecto | Seguimiento y cierre | Comprobante fiscal emitido por el proveedor de transporte por cada trayecto, para efectos de deducibilidad |
| prueba_entrega | Seguimiento y cierre | Prueba de entrega del embarque con su documentación de confirmación de descarga |
| incidencia | Seguimiento y cierre | Incidencias detectadas durante la ejecución de trayectos con su clasificación, escalamiento y resolución |
| archivo_embarque | Seguimiento y cierre | Paquete de archivo digital consolidado de toda la documentación de un embarque cerrado |
| historial_auditoria_catalogo | Catálogos maestros | Registro inmutable de todos los cambios sobre los catálogos maestros, con control de versiones documentado |
| habilitacion_proveedor | Catálogos maestros | Habilitaciones, permisos y certificaciones de un proveedor, con sus fechas de vigencia |
| evaluacion_proveedor | Seguimiento y cierre | Evaluación de desempeño del proveedor por cada trayecto ejecutado, para alimentar su historial |
Transcrito del diccionario de datos del proyecto de este sistema en la base del motor de la casa, con su propósito registrado. El nombre comercial del cliente viene enmascarado en el origen y así se publica.Corte tomado del reloj del propio servidor del motor: 27 de septiembre de 2026, 13:56:27. Del total de 53 entidades se transcriben 16; las restantes son catálogos de estatus y de tipo, entidades de rol y entidades de soporte. El modelo registra además 19 ciclos de vida con 213 transiciones y 1,610 rutas de servicio distintas.
Un diccionario de datos con cincuenta y tres entidades y el propósito escrito de cada una no se improvisa en una presentación. Es la prueba de existencia más aburrida y la más difícil de fingir.
Los registros inmutables, y por qué son la mitad del valor
Tres entidades del inventario llevan la palabra inmutable en su propósito registrado, y las tres son las que sirven cuando alguien discute: el historial de transiciones de estado del trayecto, el historial de cambios de una incidencia y el historial de auditoría de los catálogos maestros. Un registro inmutable no es un capricho de arquitectura: es la diferencia entre poder decir qué pasó y tener que reconstruirlo.
En el modelo del aprendizaje hay otros tres que cumplen el mismo papel y que conviene tratar con la misma regla: la autorización de cada automatización, la bitácora de consulta de lo observado y el registro de cada ejecución. Los tres se escriben una vez y no se editan. Si la autorización se pudiera editar, la afirmación de que ninguna consecuencia se produce sin intervención humana dejaría de ser comprobable, que es la única forma en que vale algo.
Y hay una cuarta regla que casi nunca se escribe: la baja de un usuario retira el acceso y no borra la bitácora de lo que consultó mientras lo tuvo. La obligación de confidencialidad del artículo 20 subsiste después de terminar la relación, y por tanto la prueba de lo que hizo también tiene que subsistir.
- Historial de transiciones de estado del trayecto: qué estado, desde cuál, con qué evento, por qué rol y con qué regla.
- Historial de auditoría de catálogos maestros: qué cambió, quién, cuándo y con qué versión anterior.
- Historial de cambios de una incidencia: cada actualización, con su autor y su hora.
- Autorización de cada automatización: quién la habilitó, con qué alcance y con qué condiciones.
- Bitácora de consulta de lo observado: quién consultó, de qué equipo y con qué alcance; se conserva aunque el usuario se dé de baja.
- Registro de cada ejecución: resultado, desviación respecto del patrón y folio de la operación que produjo.
Seis registros que se escriben y no se editan. Son los que convierten una discusión sobre lo que pasó en una consulta con fecha.
El dato que falta, el que se corrige y el que viene de fuera
Un modelo de datos honesto tiene que decir qué hace con los tres casos incómodos, porque los tres ocurren todos los días.
El dato que falta. Una tarea observada con la secuencia incompleta porque la pantalla de origen cambió a media captura no se completa por inferencia: se marca como incompleta y no alimenta el patrón. La alternativa —rellenar el paso que falta con el más probable— produce una automatización que se rompe a la tercera ejecución y nadie sabe por qué.
El dato que se corrige. Una observación atribuida a un puesto que no era el suyo se reasigna, y la reasignación queda con su motivo y su hora sin borrar el registro anterior. Esto no es celo de auditoría: es el derecho de rectificación del artículo 23, que pide corregir el dato inexacto, incompleto o no actualizado, y el artículo 30 de la misma ley, que pide que la solicitud indique las modificaciones y aporte la documentación que las sustente.
El dato que viene de fuera. El identificador del puesto, su equipo y su adscripción vienen del catálogo de la empresa, no de la observación. Eso tiene una consecuencia que conviene conocer antes de empezar: si el catálogo de puestos de su empresa está desordenado, el mapa del trabajo real va a heredar ese desorden. No es un defecto del sistema y no se arregla dentro de él: se arregla en el catálogo, y es la primera cosa que conviene mirar.
Un patrón construido con pasos inferidos es una automatización que se va a romper, y el día que se rompa la culpa se le va a echar a quien la usaba.
Los tres casos tienen la misma regla: se marca, no se rellena. Y el registro anterior no se borra nunca.
Qué se parametriza de este modelo, y qué no
Buena parte de este modelo es configuración y se cambia en la sesión, con usuario, motivo y hora. Otra parte no se toca, y conviene saber cuál es antes de preguntar por ella, porque es la que sostiene lo que la página de regulación afirma.
Qué se configura · cómo · qué no se configura · por qué
| Se configura | Cómo | No se configura | Por qué no |
|---|---|---|---|
| El catálogo de aplicaciones y pantallas observadas | Parámetro visible, con su versión y su fecha; el cambio genera versión nueva del aviso | Observar sin aviso firmado | El aviso y la firma son un corte del flujo de arranque: antes de la firma el equipo no observa |
| El plazo de depuración del detalle por puesto | Lo fija el dueño del proceso y se declara en el aviso | Guardar el contenido de los campos capturados | No hay campo de contenido en el modelo: es la decisión de no tenerlo |
| El alcance de cada vista, por equipo y por área | Configuración de rol, con su bitácora de cambio | Una vista de una persona a lo largo de su jornada | No existe, porque la llave del trabajo observado es el puesto y la tarea |
| Las condiciones en que una automatización se detiene | Parámetro de la automatización, dentro del alcance autorizado | Activar una automatización sin autorización registrada | La automatización no existe sin la autorización que la habilitó: es su vínculo obligatorio |
| Los umbrales del tablero de oportunidades | Configuración del tablero, por tarea y por equipo | Que la bitácora de consulta se pueda editar o borrar | Se escribe una vez; si se pudiera editar, no probaría nada |
| Quién recibe las solicitudes de derechos del titular | Configuración de rol, con el reloj de veinte días a su nombre | Que el reloj de la solicitud empiece cuando alguien se acuerda | El artículo 31 cuenta desde la recepción, no desde la atención |
Correspondencia normativa: artículos 12, 15, 20, 23, 26 y 31 de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, texto vigente publicado el 20 de marzo de 2025. La columna de configuración corresponde al modelo de este sistema y al flujo de arranque declarado en el brochure de Relevo, página 9.
La columna de la derecha es la que conviene leer dos veces: son seis cosas que no se pueden configurar, y son exactamente las seis con las que este sistema se defiende.
Cómo se lee este modelo cuando le toca defenderlo
Va a tener que explicarlo tres veces, a tres audiencias distintas, y las tres quieren cosas diferentes. A la persona observada y a su representación les interesa la tabla de la sección cuarta: qué se guarda, qué no y cuánto tiempo. No hace falta traducir nada, está escrita para leerse en voz alta.
A la autoridad fiscal o aduanera le interesa la tabla de la sección segunda, y en particular la columna de retención con su fundamento. Ahí lo que decide no es el número de años sino el cómputo: desde la declaración, desplazado cuando los efectos se prolongan y desde la firmeza cuando hubo recurso. Un expediente depurado con el reloj equivocado es un expediente que no existe el día que lo piden.
Y a su propia dirección le interesa la de la sección séptima, porque es la única que contesta si el sistema existe: cincuenta y tres entidades con su propósito escrito, diecinueve ciclos de vida, doscientas trece transiciones y mil seiscientas diez rutas de servicio distintas, con la hora de corte del servidor que las contó. Con los ceros incluidos, que están declarados en la página del consentimiento y en la de regulación.
- Abrir la tabla de la sección cuarta y leerla con la representación del personal, sin resumirla.
- Comprobar que el reloj de retención de cada expediente fiscal arranca con la declaración y no con la fecha de captura.
- Confirmar que el catálogo de puestos de su empresa está ordenado, porque el mapa del trabajo hereda ese catálogo.
- Nombrar al dueño del proceso que fija el plazo de depuración del detalle por puesto, y escribirlo en el aviso.
- Comprobar que la bitácora de consulta se conserva cuando un usuario se da de baja.
Después de los cinco puntos, la discusión sobre este sistema deja de ser si observa a la gente y pasa a ser qué tareas de su operación se automatizan primero.
Preguntas frecuentes
¿El sistema guarda el nombre de la persona observada?
No en el registro de la observación. La llave del trabajo observado es el código del puesto, el código de la tarea y la fecha; el nombre vive en el expediente laboral de la empresa, que es otro sistema y otra base de licitud. Esa elección tiene una consecuencia concreta: la consulta natural del sistema es «todo lo de esta tarea», y la consulta «todo lo de esta persona» no existe por construcción. Para atender un derecho de acceso se resuelve el puesto de esa persona en el periodo pedido, se entrega el extracto y queda el folio de la solicitud.
¿Se guarda lo que aparece en la pantalla?
No hay campo de contenido en el modelo. Se guarda la secuencia de pasos de la tarea, la aplicación y la pantalla en uso, la marca de tiempo y la duración por repetición. El control declarado en el brochure lo dice en una línea: registra los pasos, no la información de sus clientes. Y los patrones sensibles —contraseñas, tarjetas, registro fiscal, clave de registro de población y correos— se enmascaran en el equipo antes de que el dato salga de ahí, lo que significa que el dato sin enmascarar nunca viaja.
¿Cuánto tiempo se conserva el detalle de lo observado?
Hasta que la tarea queda automatizada y su línea base medida. No es un número redondo: es el criterio del artículo 12, que limita el tratamiento a lo necesario, adecuado y relevante respecto de la finalidad del aviso. Cumplida la finalidad, el detalle por puesto se depura y se conserva el agregado por tarea, que es lo que sostiene el número del sistema. El plazo concreto lo fija el dueño del proceso y se escribe en el aviso, con su nombre.
¿Por qué hay tres plazos de retención distintos y no uno?
Porque los fijan tres cosas distintas y mezclarlos produce los dos errores opuestos. El de la observación lo fija la finalidad. El del dato que ya cumplió su finalidad pero podría servir para determinar responsabilidades lo fija la prescripción, y la ley define el estado en que espera: bloqueo, artículo 2, fracción III, sin tratamiento durante ese periodo y cancelación al final. El de la documentación fiscal y aduanera lo fija el artículo 30 del Código Fiscal de la Federación: cinco años, con el cómputo desplazado cuando los efectos se prolongan y cuando hubo recurso o juicio. Ese tercero no se cancela a petición del titular, porque el último párrafo del artículo 26 excluye la oposición cuando el tratamiento es necesario para cumplir una obligación legal.
¿Qué entidades tiene realmente dadas de alta el motor de la casa?
Cincuenta y tres en el proyecto de gestión logística de embarques internacionales, cada una con su propósito escrito y su módulo, más diecinueve ciclos de vida con doscientas trece transiciones y mil seiscientas diez rutas de servicio distintas. La sección séptima transcribe dieciséis, las del expediente del embarque. Cinco de las cincuenta y tres son entidades de rol, y ahí es donde el modelo generado guarda lo que concierne a una persona identificada: esa separación es la que permite que el registro de la tarea observada no la necesite. Todos los conteos llevan la hora de corte del propio servidor.
¿Qué pasa con lo observado cuando alguien deja la empresa?
Dos cosas distintas, y conviene no confundirlas. El acceso de esa persona al sistema se retira con la baja. La bitácora de lo que consultó mientras tuvo acceso no se borra, porque el deber de confidencialidad del artículo 20 subsiste después de terminar la relación y la prueba de lo que hizo tiene que subsistir con él. Y el detalle de lo que se observó de su puesto sigue el mismo reloj que el de cualquier otro puesto: se depura cuando la finalidad se cumple, y el agregado por tarea se conserva porque ya no concierne a nadie en particular.
Referencias
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares. Nueva ley publicada en el Diario Oficial de la Federación el 20 de marzo de 2025; texto vigente con la reforma publicada el 14 de noviembre de 2025. Artículos citados en esta página: 2 fracción III, 11, 12, 15, 20, 21, 22, 23, 24, 25, 26, 30 y 31. Consultada el 27 de septiembre de 2026. ↗
- Código Fiscal de la Federación, artículo 30: conservación cinco años, con el cómputo desde la declaración del último ejercicio cuando los efectos se prolongan y desde la firmeza de la resolución cuando hubo recurso o juicio. Consultado el 27 de septiembre de 2026. ↗
- Ley Aduanera, artículos 6º, 36-A y 162: expediente electrónico del pedimento con sus anexos y acuses, conservado como parte de la contabilidad por los plazos del Código Fiscal y entregado al cliente sin cargo adicional. Texto vigente con la reforma publicada el 19 de noviembre de 2025, consultado el 27 de septiembre de 2026. ↗
- Motor el motor de la casa · base del motor de la casa, el proyecto de este sistema, consultado en modo de sólo lectura para esta página: 53 entidades del diccionario de datos con su propósito registrado, 19 ciclos de vida, 213 transiciones, 178 pantallas, 48 procesos, 438 casos de uso y 1,610 rutas de servicio distintas. Corte tomado del reloj del propio servidor: 27 de septiembre de 2026, 13:56:27. El nombre comercial del cliente viene enmascarado en el origen y así se publica. ↗
- Relevo · brochure de logística, diez páginas. Las cuatro capacidades del ciclo, el ejemplo de oportunidad detectada con su cálculo y los seis controles de privacidad de la página 8, de los que salen las columnas de finalidad y de límite de esta página. ↗
- Diario Oficial de la Federación: fuente de publicación de los decretos citados, 20 de marzo de 2025, 14 de noviembre de 2025 y 19 de noviembre de 2025. ↗
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.
Siga por aquí