KORE · seguridad y auditoría
Un control que no deja registro no existe. Y en carretera, el registro se pide en el momento.
Cuando roban un embarque, nadie pregunta si tiene seguridad informática. Pregunta quién sabía la ruta, quién sabía qué llevaba la caja y desde cuándo. Esta página enumera los controles del sistema, la evidencia que cada uno deja, la norma que lo pide y la parte que sigue siendo obligación suya como permisionario.
Auditable quiere decir una sola cosa: que se puede reconstruir
Un sistema es auditable cuando un tercero que no estuvo ahí puede reconstruir qué pasó, quién lo hizo y cuándo, sin depender de que alguien se acuerde. Todo lo demás —contraseñas, cifrado, perfiles— existe para que esa reconstrucción sea creíble. Si el registro de salida de un viaje se puede alterar después sin dejar rastro, el cifrado no lo salva.
En el autotransporte de carga esa reconstrucción tiene cuatro jueces distintos y ninguno acepta la palabra del otro. La autoridad fiscal pregunta por el comprobante que amparó el traslado y por quién lo canceló. La autoridad de transporte pregunta por el permiso, la verificación de la unidad y las horas del operador. La aseguradora, cuando hay siniestro o robo, pregunta por la cadena de custodia de la carga y por quién tuvo acceso a la ruta. Y su cliente embarcador pregunta por la evidencia de entrega, porque él responde ante el suyo.
Por eso esta página no describe una política de seguridad. Describe controles, y junto a cada control, el registro que deja. Lo que viene de la plataforma sobre la que KORE corre lleva su cita en el expediente interno. Lo que es obligación de su empresa como permisionario se dice con esas palabras, y está en la última tabla.
El control que no produce un renglón fechado no es un control: es una intención.
El comprobante del traslado
Primer frente: el comprobante fiscal no es un archivo, es un documento con validez legal
En un sistema de oficina, un comprobante es un archivo que alguien guarda. En transporte de carga no: el comprobante fiscal digital con complemento Carta Porte es lo que ampara el traslado de la mercancía en territorio nacional, con origen, destino, mercancías, operador, vehículo, remolques, permiso y póliza. La versión 3.1 del complemento es de uso obligatorio desde el 17 de julio de 2024. Sin él, el problema no es administrativo: es que la unidad no debería estar circulando con esa carga.
De ahí sale la primera exigencia de seguridad de este sector, y es una que los sistemas de gestión suelen resolver a medias: el comprobante tiene dos autores distintos y los dos importan. Quien lo timbró, cuando la hay, quien lo canceló. La cancelación de un comprobante está reglada y lleva motivo; el artículo 29-A del Código Fiscal de la Federación fue reformado por el decreto publicado en el Diario Oficial de la Federación el 7 de noviembre de 2025, y ese mismo decreto adicionó el artículo 30-B, que entra en vigor el 1 de abril de 2026.
La segunda exigencia es el plazo. El comprobante y su complemento no se conservan «un rato»: el artículo 30 del Código Fiscal de la Federación fija el plazo de conservación de la contabilidad y de los comprobantes, y durante ese plazo tienen que poder localizarse por viaje, por unidad, por cliente y por periodo. Conservar no es tener el archivo en algún lado; es poder entregarlo ordenado cuando se lo pidan.
El comprobante del traslado · qué registro deja cada acto
| Acto sobre el comprobante | Qué registro tiene que quedar | Qué lo pide |
|---|---|---|
| Emisión y timbrado del comprobante del viaje | Usuario que lo emitió, hora, viaje al que corresponde y los datos del traslado: origen, destino, mercancías, operador, vehículo, remolques, permiso y póliza | Norma · complemento Carta Porte 3.1, obligatorio desde el 17 de julio de 2024 |
| Cancelación del comprobante | Usuario que canceló, hora, motivo, cuando el motivo lo exige, el comprobante que lo sustituye | Norma · Código Fiscal de la Federación, artículo 29-A, reformado el 7 de noviembre de 2025 |
| Corrección de un dato del traslado antes de la salida | Valor anterior, valor nuevo, usuario y hora, sobre el mismo viaje | Plataforma · bitácora de cambio de estado, |
| Conservación del comprobante y su complemento | El comprobante localizable por viaje, unidad, cliente y periodo durante el plazo legal | Norma · Código Fiscal de la Federación, artículo 30 |
| Entrega al cliente embarcador | Comprobante y evidencia disponibles en el portal del cliente, con el acceso registrado | Brochure · portal de clientes |
| Cambio de versión del complemento por parte de la autoridad | Catálogos, campos y validaciones nuevos, con solicitud, respaldo e instantánea de versión | Plataforma · motor de cambios, |
Fuente: complemento Carta Porte del CFDI versión 3.1 (SAT), Código Fiscal de la Federación con el decreto del 7 de noviembre de 2025, brochure de KORE y evidencia de plataforma · verificado al 27 de septiembre de 2026
Un timbrado sin autor es un comprobante sin dueño. Y el día de la revisión, el comprobante sin dueño lo firma quien esté al frente.
Segundo frente: los datos del operador y su ubicación son datos personales
Esto es lo que más se pasa por alto en una flota, y es lo que cambió de raíz. Un sistema de transporte guarda, de cada operador, su nombre, su licencia federal, su examen médico, su calificación de conducta —frenados, exceso de velocidad, fatiga— y su posición cada pocos minutos durante toda su jornada. Eso no es telemetría de una máquina: es el registro de los movimientos de una persona identificada, y por lo tanto son datos personales.
La ley que lo rige es nueva y conviene publicarla con su fecha, porque casi todos los avisos de privacidad del sector están desactualizados: 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 al día siguiente y tuvo una reforma publicada el 14 de noviembre de 2025. Sustituyó a la ley de 2010. Y hay un cambio que obliga a corregir documentos: la autoridad ya no es el Instituto Nacional de Transparencia; la competencia pasó a la Secretaría Anticorrupción y Buen Gobierno. Si su aviso de privacidad menciona al instituto como autoridad ante la que se ejercen los derechos, su aviso está viejo.
La consecuencia operativa es concreta y se puede revisar en una tarde. Hace falta un aviso de privacidad para sus operadores, una base de licitud para tratar su ubicación, medidas de seguridad sobre esos datos y un camino para que el operador ejerza sus derechos de acceso, rectificación, cancelación y oposición. El sistema puede sostener las cuatro cosas; el que responde ante la autoridad es usted.
Datos del operador · qué guarda el sistema y qué obliga la ley de 2025
| Dato del operador | Para qué lo usa la operación | Qué obliga sobre él |
|---|---|---|
| Identidad y licencia federal, con su vigencia | Decidir si el operador puede ser asignado a un viaje | Dato personal: aviso de privacidad, licitud y medidas de seguridad |
| Ubicación de la unidad durante su jornada | Seguimiento del viaje, desviaciones, paradas no autorizadas y hora estimada de llegada | La geolocalización asociada a una persona identificada es dato personal |
| Bitácora de horas de conducción y pausas | Cumplir los tiempos de conducción y pausas de la norma, y planear el relevo | Norma · NOM-087-SCT-2-2017: la bitácora es personal e intransferible |
| Calificación de conducta de manejo | Asignar capacitación y medir la mejora; y el bono por conducta de la liquidación | Dato personal con consecuencia laboral: finalidad declarada en el aviso |
| Examen médico y documentación de la licencia | Sostener la vigencia de la licencia federal | Dato personal con protección reforzada por su naturaleza |
| Liquidación: viáticos, bonos y deducciones | Pagar sin recaptura, con el soporte del viaje cerrado | Dato personal de contenido patrimonial; acceso restringido por rol |
Fuente: 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, con reforma del 14 de noviembre de 2025; NOM-087-SCT-2-2017 (DOF, 28 de junio de 2018); brochure de KORE · verificado al 27 de septiembre de 2026
Hay una tentación que conviene nombrar para no caer en ella: usar la ubicación del operador para todo, porque está ahí. La finalidad declarada en el aviso de privacidad es la que limita el uso, y no la capacidad técnica del sistema. Un sistema que permite consultar la posición histórica de una persona sin registrar quién la consultó y para qué no está protegiendo un dato personal: lo está exponiendo con más comodidad.
La ubicación de su operador es un dato personal desde antes de que usted decida qué hacer con ella. El aviso de privacidad no la crea: la ordena.
Tercer frente: la custodia de la carga, que es la pregunta cuando hay robo
Este frente es el que distingue la seguridad de un sistema de transporte de la seguridad de un sistema de oficina, y casi nunca aparece en una política escrita. Cuando un embarque se pierde en carretera, la investigación no empieza por el cortafuegos: empieza por una lista de personas. Quién sabía qué llevaba la caja. Quién sabía por dónde iba a pasar y a qué hora. Quién cambió la ruta, y cuándo. Quién descargó el detalle del embarque, y desde dónde.
Dicho con precisión: en la carga, el dato sensible no es sólo el dato personal. Es la combinación de contenido, ruta y horario, que juntos valen exactamente lo que vale el embarque. Un sistema que reparte esa combinación a quien no la necesita está multiplicando el número de personas que podrían haberla filtrado, y por lo tanto el número de personas a las que habrá que preguntar.
Por eso la custodia se diseña al revés de como se suele configurar un permiso. No se parte de «quién debería poder ver esto» sino de «quién tiene que poder verlo para hacer su trabajo», y el resto no lo ve. Y el registro de consulta importa tanto como el registro de cambio: en un robo, saber quién miró es más útil que saber quién editó.
La pregunta del investigador no es «¿tienen control de accesos?». Es «enséñeme quién pudo ver esta ruta antes de que la unidad saliera».
- El contenido del embarque, por necesidad y no por jerarquía. El operador necesita la ruta y la parada; no necesariamente el valor declarado de la mercancía.
- La ruta y su horario, con su historial de cambios. Un cambio de ruta en el último momento es un dato de investigación: quién lo pidió, quién lo autorizó y a qué hora quedó registrado.
- La consulta, registrada como la edición. Quién abrió el detalle de un embarque y cuándo, no sólo quién lo modificó.
- El tercero subcontratado, como rol con su propio usuario. La flota externa entra al mismo sistema con su alcance acotado, no con una hoja de cálculo por correo.
- La evidencia de entrega, ligada al viaje y con su hora. Fotografía, firma y geolocalización de la entrega, para que la disputa se resuelva con el registro y no con la versión de cada parte.
- El expediente del siniestro, desde el evento. Reclamación ante la aseguradora con su parte de accidente y su evidencia integrada, sin recomponerla semanas después.
Cuando la lista de quien pudo ver la ruta es corta y está registrada, el robo deja de ser un misterio y pasa a ser un caso.
Quién entra: autenticación y sesión
El acceso al sistema pasa por un servidor de autenticación propio que emite un token de sesión firmado. El portal y las aplicaciones de campo no hablan con la base de datos: hablan con una capa de servicios que exige ese token en cada llamada. El token es de vida corta y se renueva; una sesión abandonada en una tableta dentro de una cabina deja de servir por sí sola.
Esto importa en una flota por una razón concreta: los dispositivos viven fuera de la oficina. Una tableta o un teléfono de operador se pierde, se cae, cambia de manos entre turnos y se queda en la unidad cuando la unidad entra a taller. La baja del usuario tiene que cortar el acceso desde el servidor y no desde el equipo, porque el equipo puede no volver.
El control de acceso, componente por componente
| Control | Qué hace | Dónde está la evidencia |
|---|---|---|
| Autenticación con protocolo de autorización estándar | 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 sobre la plataforma de servicios de la casa |
| Token firmado, 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 | 499 controladores de servicio sobre una misma capa base: no hay acceso directo a la base desde la pantalla | 500 archivos de controlador, clase base |
| Captura en ruta con identidad | La evidencia que se captura en el camino conserva el responsable y la hora del evento, no la hora en que el servidor la recibió | Brochure · evidencia digital de entrega y checklist con firma |
Fuente: evidencia de plataforma de la casa y brochure de KORE · verificado al 27 de septiembre de 2026
La casa mantiene sus propios hallazgos de seguridad documentados con severidad y con el procedimiento para reproducirlos, dentro del repositorio técnico de la plataforma, y los trata como deuda con dueño y fecha (citado). Se dice aquí porque un proveedor que afirma no tener hallazgos no está diciendo que su producto sea seguro: está diciendo que no los busca.
Quién puede qué: perfiles y permisos por rol
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, spGetMenuConfigurationbyRole, y el permiso vive en una tabla propia que cruza pantalla, funcionalidad y rol (permiso_pantalla_funcionalidad; el procedimiento).
En el proyecto de KORE en el motor de la casa hay 94 roles dados de alta, con su tipo y su ámbito, al corte del 27 de septiembre de 2026, 14:09 h del propio servidor. No son perfiles de informática: son los papeles de una operación de transporte y de su corporativo —coordinador de rutas, operador de despacho, conductor u operario de campo, supervisor de mantenimiento, planificador de mantenimiento, técnico senior y junior, auditor interno, analista de seguridad de la información, administrador de base de datos, dirección general—.
Lo que un grupo multiempresa tiene que mirar con más cuidado es el alcance por empresa. Si el corporativo ve todo y cada empresa ve lo suyo, el permiso no es sólo por rol: es por rol y por empresa del grupo. Esa es la diferencia entre una torre de control del grupo y un sistema donde el tráfico de una empresa puede leer los clientes y las tarifas de otra.
- Segregación de funciones donde toca el dinero. Quien calcula la liquidación del operador no es quien la autoriza; quien pide un cambio de ruta no es necesariamente quien lo aprueba.
- El portal del cliente es un rol, no una excepción. El embarcador entra con su usuario y ve el estatus, la evidencia y el indicador de su contrato; no ve las tarifas de otro cliente.
- El tercero subcontratado también. La flota externa opera con el mismo estándar documental y con un alcance acotado a sus propios viajes.
- El rol se ve en pantalla. El sistema abre con la vista puesta por el rol; no hay una pantalla genérica desde la que todos vean todo.
Un permiso que sólo existe en el manual se rompe el primer fin de semana que alguien cubre un turno que no es el suyo.
Quién hizo qué y cuándo: la bitácora
El motor de estados de la plataforma no deja cambiar un estado sin registrarlo. Cada movimiento 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 transversal 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 validación de rol, para la ejecución, para el historial de la entidad y para la bitácora con operación, valor anterior y valor nuevo.
Dos condiciones más viajan con el movimiento y no son decorativas: requiere comentario y requiere evidencia. Son columnas de la propia matriz de transiciones. Traducido a una operación de carga: hay pasos que el sistema no permite cerrar sin que alguien escriba por qué —autorizar la salida con una excepción documental, por ejemplo— y pasos que no cierran sin el archivo adjunto, como la entrega sin su fotografía.
Hay que decir una cosa con precisión, porque esta capa no se permite ambigüedades: ese mecanismo es el de la plataforma y corre dentro de los sistemas generados. En el proyecto de KORE en el motor, no hay ciclos de vida ni transiciones dados de alta al corte del servidor, y eso está publicado con su conteo en la página de matrices de estado. El mecanismo existe y se cita; las matrices de este proyecto están pendientes de transcripción, y no se presentan como si estuvieran.
La pregunta del auditor no es «¿tienen bitácora?». Es «enséñeme quién canceló este comprobante y por qué». Eso es una consulta, no una búsqueda.
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 viva 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.
Los controles, uno por uno, con su evidencia y su norma
Control · qué deja de registro · qué norma o exigencia lo pide
| Control | Qué registro deja | Norma o exigencia que lo pide | Origen |
|---|---|---|---|
| Identidad en cada captura del viaje | Usuario, fecha y hora en el evento; responsable por etapa del viaje | Trazabilidad del traslado y de su evidencia ante el cliente y la aseguradora | Plataforma · brochure, ciclo de la orden al cobro |
| Permiso por rol y por funcionalidad | Tabla de permiso pantalla-funcionalidad-rol y menú resuelto por rol, sobre 94 roles dados de alta | Control de acceso como medida de seguridad sobre datos personales | Plataforma · motor, conteo de roles |
| Bitácora de timbrado y de cancelación del comprobante | Usuario, hora, motivo y comprobante sustituto | Código Fiscal de la Federación, artículo 29-A, reformado el 7 de noviembre de 2025 | Norma · plataforma |
| Bitácora de cambio de estado en general | Estado anterior, estado nuevo, valor anterior, valor nuevo, usuario, hora | Integridad del registro ante auditoría fiscal, de transporte y de seguro | Plataforma |
| Comentario obligatorio en pasos sensibles | Texto del responsable, adherido al movimiento | Justificación documentada de una excepción, por ejemplo una salida autorizada con observación | Plataforma |
| Evidencia obligatoria en pasos sensibles | Archivo adjunto —fotografía del checklist, evidencia de entrega, parte de accidente— ligado al movimiento | Disputa de daños con evidencia y expediente de reclamación | Plataforma · brochure, checklist y siniestros |
| Validación documental antes de la salida | Registro de completitud del expediente del viaje antes de que la unidad salga | El traslado tiene que ir amparado por el comprobante, con permiso y póliza | Norma · complemento Carta Porte · brochure |
| Vigencia de permisos, licencias y verificaciones como dato | Documento, autoridad u organismo, número y fecha de caducidad, con su estatus | NOM-068-SCT-2-2014 para la verificación anual de la unidad; licencia federal para el operador | Norma · brochure, módulo de cumplimiento |
| Cómputo de horas de conducción y pausas | Bitácora de horas de servicio por operador, personal e intransferible | NOM-087-SCT-2-2017 (DOF, 28 de junio de 2018) | Norma · brochure, planeación y despacho |
| Aviso de privacidad y derechos del operador | Finalidad declarada, base de licitud y el camino para ejercer acceso, rectificación, cancelación y oposición | Ley Federal de Protección de Datos Personales en Posesión de los Particulares, 20 de marzo de 2025 | Norma · obligación del permisionario |
| Versionado de artefactos y de cambios | Instantánea de versión por cambio aplicado, con número de versión | Control de configuración y de versiones | Plataforma |
| Retención del registro del viaje | El viaje cerrado y su expediente siguen consultables | Plazo de conservación del artículo 30 del Código Fiscal de la Federación | Norma · configuración del operador |
Fuente: complemento Carta Porte del CFDI (SAT), Código Fiscal de la Federación, NOM-068-SCT-2-2014, NOM-087-SCT-2-2017, Ley Federal de Protección de Datos Personales en Posesión de los Particulares de 2025, brochure de KORE y evidencia de plataforma · verificado al 27 de septiembre de 2026
Doce controles, doce registros, doce orígenes. Eso es lo que se pone sobre la mesa en una revisión; lo demás es una declaración de intenciones.
Retención, respaldo, ambientes y el expediente que el sistema deja
Separar el ambiente donde se prueba del ambiente donde se opera no es una cortesía: es lo que evita que una corrección de un martes altere el expediente de un viaje timbrado el lunes. 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 secuencia que incluye 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. Esa instantánea es lo que permite responder a la pregunta incómoda: «¿cómo estaba esta pantalla el 14 de marzo, cuando se capturó ese dato del traslado?».
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. La política de respaldo, la prueba de restauración y el plan de recuperación son del operador. Y el expediente técnico del sistema existe como contenido generado: el catálogo de la plataforma tiene 211 documentos en 18 secciones, definidos en código (el conteo y las secciones). La sección de seguridad de la información reúne quince piezas —entre ellas la matriz de controles, la política de control de acceso, la de clasificación de la información, la de cifrado y protección de datos, el plan de respuesta a incidentes y el de continuidad— y la de gestión de la configuración reúne diez, con el registro de elementos de configuración, el plan de control de versiones, el documento de ambientes y el informe de auditoría de configuración.
Quién responde por qué
| Asunto | De la plataforma | Del permisionario |
|---|---|---|
| Autenticación y emisión de sesión | Servidor de autenticación y token firmado | Alta y baja de usuarios, y quién queda con qué rol y con qué alcance por empresa |
| Permisos | Modelo de permiso por rol, pantalla y funcionalidad | La decisión de negocio: quién autoriza una salida y quién autoriza una liquidación |
| Bitácora | El registro automático de cada cambio de estado | Revisarla. Una bitácora que nadie lee es un archivo, no un control |
| Comprobante del traslado | El registro de quién timbró, quién canceló y con qué motivo | Que el comprobante exista antes de que la unidad salga. La obligación fiscal es suya |
| Datos personales del operador | Permiso por rol, bitácora y registro de consulta | Aviso de privacidad, base de licitud y atención de los derechos del operador |
| Custodia de la carga | El alcance acotado por rol y el registro de quién consultó el embarque | Decidir quién necesita ver contenido, ruta y horario, y con qué consecuencia si se filtra |
| Retención | El registro sigue consultable y el expediente se arma en consulta | El periodo, cuando su contrato o su criterio piden más que la norma |
| Respaldo y recuperación | Respaldo del artefacto en cada cambio aplicado, con versión | Política de respaldo, prueba de restauración y plan de recuperación |
| Ambientes | Base y servicios separados por sistema; despliegue registrado | Quién tiene acceso a cada ambiente y con qué credencial |
| Cumplimiento ante la autoridad | La evidencia, ordenada y entregable | Cumplir. La responsabilidad del permisionario no es delegable a un software |
Fuente: reparto de responsabilidad declarado, sobre la evidencia de plataforma citada en las referencias · 27 de septiembre de 2026
Ese expediente es la diferencia entre decir «el sistema es seguro» y poner sobre la mesa la matriz de controles, el registro de versiones y el informe de auditoría de configuración del sistema que usted usa. Un auditor no discute adjetivos: pide documentos.
Cuando el expediente del sistema existe, la auditoría deja de ser un proyecto y pasa a ser una consulta.
Lo que esta página no afirma
Cuatro cosas se dejan dichas para que nadie las lea de más, porque en esta capa la credibilidad se gasta una sola vez.
KORE le permite demostrar cumplimiento. La responsabilidad de cumplir sigue siendo del permisionario, y así lo dicen las propias normas.
- No existe una certificación de la autoridad fiscal ni de la autoridad de transporte para un sistema de gestión de transporte. La autoridad fiscal autoriza proveedores de certificación de comprobantes; no certifica sistemas de gestión. Un sistema puede sostener el cumplimiento y decir con qué; no puede declararse certificado por la autoridad.
- No se publica ningún esquema de autenticación concreto de los servicios generados de este proyecto, porque el campo que lo declararía está vacío en los endpoints revisados de la plataforma. Se afirma lo que sí está verificado: la autenticación de la plataforma y el token firmado de vida corta.
- Las matrices de estado de este proyecto no están en el motor. El mecanismo de bitácora y de validación por rol es de la plataforma y se cita con su línea de código; los ciclos de vida de KORE están en cero al corte del servidor, con su conteo publicado en la página de matrices de estado.
- El cumplimiento como permisionario es de su empresa, no del software. El permiso, el seguro, la verificación de la unidad y la licencia del operador son obligaciones suyas; el sistema le permite demostrar que las cumple y le avisa antes de que venzan.
Preguntas frecuentes
¿Queda registro de quién timbró y quién canceló un comprobante?
Ése es el primer control de este sector y por eso abre la página. El comprobante fiscal con complemento Carta Porte es lo que ampara el traslado, y tiene dos autores posibles: el que lo emitió y el que lo canceló. La cancelación lleva motivo, cuando el motivo lo exige, el comprobante que la sustituye; el artículo 29-A del Código Fiscal de la Federación fue reformado por el decreto publicado el 7 de noviembre de 2025. En el sistema, cada cambio de estado deja usuario, hora, valor anterior y valor nuevo.
¿La ubicación de mis operadores es un dato personal?
Sí, cuando está asociada a una persona identificada, que es el caso en una flota donde la unidad tiene operador asignado. La ley vigente es la 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, con reforma del 14 de noviembre de 2025, y su autoridad ya no es el Instituto Nacional de Transparencia: la competencia pasó a la Secretaría Anticorrupción y Buen Gobierno. Si su aviso de privacidad menciona al instituto, está desactualizado.
Si me roban un embarque, ¿qué puedo enseñar?
La lista de quién pudo ver el contenido, la ruta y el horario, con su registro de consulta; el historial de cambios de la ruta, con quién lo pidió y quién lo autorizó; la bitácora de estados del viaje con su hora; y el expediente del siniestro con su parte de accidente y su evidencia integrada desde el evento. Lo que no se puede enseñar es lo que nunca se registró, y por eso el registro de consulta importa tanto como el de modificación.
¿Cómo entra un usuario y qué pasa si se pierde la tableta de una unidad?
El acceso pasa por el servidor de autenticación de la plataforma, que emite un token de sesión firmado y de vida corta; cada llamada al servicio viaja con ese token y el token caduca por sí solo. Si un equipo se pierde, la baja del usuario corta el acceso desde el servidor y no desde el equipo, que puede no volver. El alta y la baja de usuarios son del permisionario.
¿Cuánto tiempo hay que conservar el comprobante del traslado?
El plazo de conservación de la contabilidad y de los comprobantes lo fija el artículo 30 del Código Fiscal de la Federación, y durante ese plazo el comprobante tiene que poder localizarse por viaje, por unidad, por cliente y por periodo. Conservar no es tener el archivo en algún lado: es poder entregarlo ordenado cuando se lo pidan. Si su contrato con un cliente pide más, el umbral se parametriza y la decisión es de su empresa.
¿El sistema hace el respaldo de mi base de datos?
No como política corporativa. Cada cambio aplicado sobre el sistema en operación incluye un respaldo del artefacto que se toca y una instantánea de versión con su número, lo que permite reconstruir cómo estaba una pantalla en una fecha dada. La política de respaldo de la base, la prueba de restauración y el plan de recuperación son del permisionario. El sistema entrega los documentos que esos planes necesitan como parte del expediente técnico.
Referencias
- SAT · Complemento Carta Porte del CFDI, versión 3.1: publicado el 17 de junio de 2024, de uso obligatorio desde el 17 de julio de 2024. Obliga a amparar el traslado de mercancías en territorio nacional con un CFDI con complemento, con origen, destino, mercancías, operador, vehículo, remolques, permiso y póliza. Consultado el 27 de septiembre de 2026. ↗
- Decreto por el que se reforman, adicionan y derogan diversas disposiciones del Código Fiscal de la Federación. Diario Oficial de la Federación, 7 de noviembre de 2025. Reformó el artículo 29-A y adicionó el 29-A Bis y el 30-B; el 30-B entra en vigor el 1 de abril de 2026. Consultado el 27 de septiembre de 2026. ↗
- 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, con reforma publicada el 14 de noviembre de 2025. Sustituye a la ley de 2010; la autoridad es la Secretaría Anticorrupción y Buen Gobierno. Consultada el 27 de septiembre de 2026. ↗
- NOM-087-SCT-2-2017, tiempos de conducción y pausas para conductores de los servicios de autotransporte federal. Diario Oficial de la Federación, 28 de junio de 2018. Bitácora de horas de servicio personal e intransferible. Consultada el 27 de septiembre de 2026. ↗
- NOM-068-SCT-2-2014, condiciones físico-mecánicas y de seguridad del autotransporte federal. Diario Oficial de la Federación, 19 de enero de 2015. Revisión anual y constancia que se porta. Consultada el 27 de septiembre de 2026. ↗
- Motor del motor de la casa · conteo de roles del proyecto de este sistema en la base del motor de la casa (94 roles) y conteo en cero de Spartan_WorkFlow y Spartan_WorkFlow_Transition del mismo proyecto, consultados el 27 de septiembre de 2026 a las 14:09 h, hora del propio servidor.
- Evidencia de plataforma: dossier técnico del motor de la casa, archivos, con cita de archivo y línea en el expediente interno sobre código en disco: autenticación y token, clase base de los controladores, permisos por rol, bitácora del motor de estados, pantallas de auditoría, respaldo e instantánea de versión y catálogo de 211 documentos en 18 secciones. Verificado el 27 de septiembre de 2026.
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 KORE 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.