ComplianceShield · los controles y su evidencia
Aquí el expediente no respalda la prueba. El expediente es la prueba.
Este sistema custodia identificaciones oficiales, datos biométricos, estructuras de propiedad y avisos presentados ante la autoridad. Cuando llega la visita de verificación, lo que se revisa es exactamente eso. Esta página enumera los controles, el registro que cada uno deja y el artículo que lo exige.
Por qué en este sistema la seguridad no es un anexo
En la mayoría de los sistemas, la seguridad protege la información con la que se trabaja. Aquí protege la información que es el trabajo. El expediente de identificación de una contraparte, el resultado del cotejo contra listas, el dictamen de una alerta y el acuse del aviso no son subproductos de la operación: son la única prueba de que el cumplimiento ocurrió.
Eso cambia el criterio con el que se mide un control. 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. Si el expediente se puede alterar sin dejar rastro, el cifrado no lo salva: lo que queda es un archivo bonito que no prueba nada.
Y hay un agravante propio de este dominio: lo que el sistema guarda son datos personales de terceros, algunos de ellos sensibles, recabados por obligación legal. Usted no los pidió porque quisiera: la ley le obliga a identificar y conocer de manera directa a su contraparte, a verificar su identidad con documentos de reconocimiento oficial y a recabar copia de los mismos. La misma ley que le obliga a tenerlos le obliga a custodiarlos y a evitar su destrucción u ocultamiento.
La autoridad no le pregunta si tiene seguridad. Le pregunta quién consultó ese expediente, a qué hora y con qué justificación.
El control que no produce un renglón fechado no es un control: es una intención.
El objeto protegido
Qué custodia exactamente este sistema
Antes de hablar de controles conviene nombrar lo que se protege, porque el diccionario de datos del proyecto lo tiene registrado entidad por entidad. La tabla siguiente sale del motor de la casa: son nombres y descripciones tal como están ahí, no una lista redactada para esta página.
Las entidades que concentran el dato sensible, según el motor
| Entidad | Qué guarda, según el diccionario del motor | Proyecto |
|---|---|---|
| documento_identificacion | «Los detalles de las identificaciones oficiales de las personas físicas, incluyendo imágenes y datos extraídos» por reconocimiento óptico | «Compliance Shield» |
| validacion_biometrica | «Los resultados de las validaciones biométricas realizadas, incluyendo prueba de vida y score de coincidencia facial» | «Compliance Shield» |
| beneficiario_controlador | «Las personas físicas que ejercen control sobre una persona moral» | «Compliance Shield» |
| cadena_propiedad | «La estructura de propiedad y control de una persona moral hasta llegar al beneficiario controlador final» | «Compliance Shield» |
| documento_legal | «Documentos legales de personas morales como actas constitutivas y poderes, con datos extraídos» del propio documento | «Compliance Shield» |
| aviso y acuse_recibo | «El archivo en formato oficial, el estado de presentación, la fecha límite y el acuse de recibo», con «folio, fecha y el archivo digital del acuse» | «Compliance Shield» |
| denuncia | «Quejas y denuncias internas, incluyendo descripción, evidencia, estado de investigación y anonimato» | «Compliance Shield» |
| acceso_dato_sensible | «Registro de accesos a datos personales sensibles» | «Compliance Shield - Background Check» |
| bitacora_auditoria | «Registro inmutable de eventos críticos del sistema» | «Compliance Shield - Background Check» |
| bitacora_accesos_documento | «Cada consulta, descarga o modificación de un documento, incluyendo usuario, fecha, hora y dirección» de red | «Compliance Shield» |
Transcrito del motor: base del motor de la casa, el proyecto «Compliance Shield - Background Check» y anexos «Compliance Shield» y «Plataforma Compliance Empresarial», con corte del propio servidor a las 08:03:53 del 27 de septiembre de 2026.
Dos de esas diez entidades existen sólo para dejar rastro, y una tercera registra quién miró qué. Esa proporción no es casual: en un sistema de cumplimiento, la bitácora no es un accesorio del expediente, es parte del expediente.
Quién entra: autenticación y sesión
El acceso pasa por un servidor de autenticación propio que emite un token de sesión firmado. El portal y las aplicaciones 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, de modo que una sesión abandonada deja de servir por sí sola.
Esa capa no es una recomendación de arquitectura: es la única puerta. En disco hay 500 archivos de controlador de interfaz de programación sobre una misma clase base, lo que significa que no existe un camino que vaya de una pantalla a la base de datos saltándose la autenticación (conteo).
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 del backend de la plataforma |
| Token firmado, de vida corta | Cada llamada a la interfaz de programación 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 | 500 archivos de controlador sobre una misma capa base: la pantalla no consulta la base directamente | Código de la plataforma |
| Segundo factor y detección de anomalías | Declarados como contenido del módulo de seguridad del producto | Brochure · módulo de seguridad |
Fuente: evidencia de plataforma de la casa y brochure de ComplianceShield · verificado al 27 de septiembre de 2026
La casa mantiene sus propios hallazgos de seguridad documentados con severidad y procedimiento de reproducción dentro del repositorio técnico de la plataforma, y los trata como deuda con dueño y fecha. 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
El permiso no se resuelve escondiendo botones. Se resuelve antes de dibujar la pantalla: el menú, las vistas y las operaciones que un usuario ve se arman preguntando por su rol. 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 tampoco se capturan a mano pantalla por pantalla: la tarea 120 del motor los asigna por rol y siembra los catálogos, y existe un tipo de pantalla de configuración con árbol de permisos para revisarlos y moverlos después.
En el motor, este sistema tiene sus roles dados de alta con nombre, tipo y descripción, y con permisos funcionales contados: 60 asignaciones en el proyecto que trae la especificación de la ley y 82 en la variante corporativa. El proyecto que generó pantallas tiene cero permisos de pantalla por rol al corte, y eso se declara en la página de matrices de estado en lugar de promediarse.
- Segregación de funciones donde importa. Quien abre la relación con la contraparte no es quien dictamina la alerta que esa contraparte levanta, y quien dictamina no es quien audita el dictamen. El motor registra un rol de cumplimiento, uno de supervisión de operaciones, uno de atención a clientes, uno de finanzas, uno de recursos humanos y uno de administración del sistema.
- El acceso al dato sensible se registra con justificación. El módulo de auditoría del proyecto se describe en el motor como el que «registra accesos a datos sensibles con justificación», y tiene entidad y pantalla propias.
- La identidad de quien cumple también se protege. La ley obliga a resguardar la identidad de la persona representante encargada del cumplimiento (artículos 20 y 38). Eso es un requisito de permisos, no de discreción.
Un permiso que sólo existe en el manual se rompe el primer día que alguien sale de vacaciones.
Quién consultó y quién modificó: la bitácora
En cumplimiento hay dos preguntas distintas y las dos se contestan con bitácora. La primera es la habitual: quién modificó este dato, cuándo y qué valor tenía antes. La segunda es la que sólo aparece cuando hay datos personales de terceros de por medio: quién consultó este expediente, cuándo, desde dónde y con qué justificación. Un sistema que sólo contesta la primera deja fuera la mitad del riesgo.
El motor de estados que corre dentro del sistema generado escribe el primer rastro: valida la transición y el rol, y al ejecutarla guarda el historial de la entidad con estado anterior y estado nuevo, más una bitácora con la operación marcada como cambio de estado, el valor anterior y el valor nuevo. Hay transiciones que además exigen comentario del responsable o archivo de evidencia para poder ejecutarse.
El segundo rastro está en el propio diseño del sistema. El diccionario del motor trae una entidad que «registra cada consulta, descarga o modificación de un documento, incluyendo usuario, fecha, hora y dirección» de red, otra de «registro de accesos a datos personales sensibles» y una tercera descrita como «registro inmutable de eventos críticos del sistema». El módulo que las agrupa se describe como «bitácora inmutable de eventos críticos: accesos, decisiones, verificaciones, destrucciones».
«¿Tienen bitácora?» no es la pregunta del verificador. La pregunta es «enséñeme quién abrió este expediente el mes pasado». 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 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. En el proyecto de este sistema, tres de las veintidós pantallas generadas son exactamente eso: bitácora de auditoría, control de acceso a datos sensibles y reportes de auditoría.
El secreto del aviso: la ley prohíbe avisarle al cliente
Este es el control que más sistemas de cumplimiento olvidan, y es de los que no admiten matices. La ley declara que la información y documentación soporte de los avisos, así como la identidad de quienes los hayan presentado y la de la persona representante encargada del cumplimiento, se considera confidencial y reservada (artículo 38, reformado el 16 de julio de 2025). Y va más lejos: quienes deban presentar avisos y conozcan de esa información se abstendrán de divulgarla o proporcionarla, por cualquier medio, a quien no esté expresamente autorizado (artículo 50).
Traducido a la operación diaria: la persona de mostrador no puede decirle a la contraparte que su operación levantó una alerta; el ejecutivo no puede adelantar que se presentó un aviso; y el propio expediente no puede quedar abierto a cualquier usuario del sistema «porque total, es nuestro cliente». La violación a esas reservas está sancionada en los términos de las disposiciones aplicables, según el propio artículo 50.
Un sistema sostiene eso de una sola manera: separando el expediente comercial del expediente de cumplimiento, cerrando la visibilidad del aviso y de la alerta a los roles con facultad, y dejando registro de cada consulta para poder demostrar después que nadie miró lo que no debía. La ley añade, además, que la información derivada de los avisos se usará exclusivamente para la prevención, identificación, investigación y sanción de esas operaciones (artículo 39): la finalidad también está acotada por escrito.
El aviso no es un dato del cliente. Es un dato sobre el cliente que el cliente no puede conocer, y el sistema tiene que hacer imposible lo contrario.
Un tablero que muestra alertas a todo el que entra no es transparencia: es una infracción con pantalla.
Conservación: diez años, y el reloj que se detiene
La reforma publicada en el Diario Oficial de la Federación el 16 de julio de 2025 subió la conservación del soporte de la actividad vulnerable de cinco a al menos diez años, contados desde la fecha de realización de la actividad, con excepción de la fracción XIV del artículo 17. Está en el artículo 18, fracción IV, y no es la única novedad de esa fracción.
La misma fracción obliga a custodiar, proteger, resguardar y evitar la destrucción u ocultamiento de la información, incluidos los registros que permitan la reconstrucción de operaciones en lo individual, la correspondencia comercial compartida entre las partes y los resultados de los análisis previos. Y fija el lugar: el domicilio registrado ante la Secretaría, de manera física o electrónica.
Hay un detalle que casi nadie configura y que cuesta caro: el plazo se interrumpe. Cuando se promueve un recurso o un juicio sobre esos conceptos, la conservación se interrumpe en la fecha de presentación y se reinicia hasta que la resolución definitiva quede firme. Un sistema que borra por calendario, sin conocer el estado del litigio, destruye evidencia que la ley todavía exigía.
En el motor, esa obligación tiene dónde vivir. El diccionario del proyecto trae una entidad de política de retención que «define las reglas de conservación y eliminación de documentos por tipo», otra de permisos de documento que «define los permisos de acceso para cada tipo de documento y rol», y el módulo documental del proyecto hermano se describe como almacenamiento seguro «con 10 años de retención» y control de acceso granular, con la norma mexicana de conservación de mensajes de datos nombrada como referencia de validez probatoria.
Datos personales: la ley cambió y la autoridad también
El segundo cuerpo normativo que gobierna este sistema es la ley de protección de datos personales en posesión de los particulares. La vigente se publicó en el Diario Oficial de la Federación el 20 de marzo de 2025, con reforma posterior del 14 de noviembre de 2025, y sustituyó a la de 2010. Lo primero que hay que corregir en cualquier aviso de privacidad heredado: la autoridad competente ya no es el instituto anterior.
Lo que esa ley exige y este sistema tiene que sostener es conocido: aviso de privacidad, base de licitud del tratamiento, medidas de seguridad, y atención de los derechos de acceso, rectificación, cancelación y oposición del titular. En datos sensibles —y los biométricos y los de antecedentes lo son— el consentimiento tiene que ser expreso y por escrito.
El proyecto que llegó a generar pantallas en el motor está construido precisamente sobre esa exigencia: de sus seis módulos, uno es el portal del titular con el flujo de consentimiento y firma electrónica, y otro es el de gestión de derechos del titular y ciclo de vida del dato, que «automatiza la retención y destrucción segura de datos personales, generando certificados de destrucción y gestionando excepciones». Tres de sus veintidós pantallas atienden solicitudes de derechos y destrucción de datos.
Los dos regímenes que conviven, y qué pide cada uno
| Régimen | Qué exige sobre el mismo expediente | Tensión que crea |
|---|---|---|
| Prevención de operaciones con recursos de procedencia ilícita | Recabar, custodiar y conservar al menos diez años; no destruir ni ocultar; reservar el aviso y su soporte | Obliga a guardar más tiempo del que el titular querría |
| Protección de datos personales | Licitud, finalidad acotada, consentimiento expreso para datos sensibles, medidas de seguridad y derechos del titular | Obliga a limitar el uso y a suprimir cuando ya no hay fundamento |
| Dónde se resuelve la tensión | La conservación por obligación legal es una base de licitud propia: el dato no se suprime mientras la otra ley lo exige, y el sistema tiene que poder demostrar por qué | Esa demostración es una política de retención con fundamento por tipo de documento, no una regla de borrado por antigüedad |
Fuente: LFPIORPI, artículo 18, fracción IV, y Ley Federal de Protección de Datos Personales en Posesión de los Particulares publicada el 20 de marzo de 2025 · verificado al 27 de septiembre de 2026
Los controles, uno por uno, con su evidencia y su norma
Control · qué registro deja · qué norma lo pide · de dónde sale
| Control | Qué registro deja | Norma que lo pide | Origen |
|---|---|---|---|
| Identidad verificada de la contraparte antes de operar | Expediente con documento de reconocimiento oficial y su copia; resultado de la validación biométrica con prueba de vida | Artículo 18, fracción I | Norma · motor, entidades documento_identificacion y validacion_biometrica |
| Identificación del beneficiario controlador | Cadena de propiedad hasta la persona física que ejerce el control, y declaración del cliente persona física | Artículo 18, fracción III | Norma · motor, entidades beneficiario_controlador, cadena_propiedad y declaracion_bc |
| Abstención de operar sin información | Registro del acto no celebrado y su motivo | Artículo 21, segundo párrafo | Norma |
| Permiso por rol y por funcionalidad | Tabla de permiso pantalla-funcionalidad-rol y menú resuelto por rol; 60 y 82 permisos funcionales registrados en los proyectos del motor | Control de acceso como medida de seguridad exigible sobre datos personales | Plataforma · motor |
| Bitácora de quién modificó | Estado anterior, estado nuevo, valor anterior, valor nuevo, usuario y hora | Reconstrucción de operaciones en lo individual, artículo 18, fracción IV | Plataforma |
| Bitácora de quién consultó | Usuario, fecha, hora y dirección de red por cada consulta, descarga o modificación de un documento; registro de accesos a datos sensibles con justificación | Medidas de seguridad sobre datos personales sensibles | Motor · entidades bitacora_accesos_documento, acceso_dato_sensible y bitacora_auditoria |
| Comentario obligatorio en transiciones sensibles | Texto del responsable adherido a la transición: el dictamen de una alerta deja de ser un botón | Resultados de los análisis previos, artículo 18, fracción IV | Plataforma |
| Evidencia obligatoria en transiciones sensibles | Archivo adjunto ligado a la transición: acuse, constancia, documento | Soporte de la actividad vulnerable | Plataforma |
| Monitoreo permanente con mecanismos automatizados | Alerta con su tipo, su score de riesgo, su estado y su bitácora de resolución | Artículo 18, fracción X | Norma · motor, entidad alerta |
| Reserva del aviso y de la identidad de quien lo presenta | Visibilidad restringida por rol y registro de cada consulta | Artículos 38, 39 y 50 | Norma |
| Conservación por diez años con interrupción por litigio | Política de retención por tipo de documento, con su fundamento | Artículo 18, fracción IV | Norma · motor, entidad politica_retencion |
| Capacitación anual con constancia | Resultado de la prueba de conocimiento por empleado y por política | Artículo 18, fracción IX, y artículo 20 | Norma · motor, entidad resultado_prueba_conocimiento |
| Revisión de auditoría con dictamen anual | Hallazgo con tipo, evidencia vinculada, acción correctiva y estado de resolución | Artículo 18, fracción XI | Norma · motor, entidad hallazgo_auditoria |
| Versionado de artefactos y de cambios | Instantánea de versión por cambio aplicado, con su número | Control de configuración y de versiones | Plataforma |
Fuente: texto vigente de la LFPIORPI tras la reforma del 16 de julio de 2025, diccionario de datos del motor y evidencia de plataforma · verificado al 27 de septiembre de 2026
Catorce controles, catorce registros, y el artículo que obliga a cada uno. Eso es lo que se pone sobre la mesa en una visita de verificación.
Respaldo, cifrado, ambientes y control de versiones
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 toque el expediente de una operación avisada 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 comprobación previa, 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 contestar la pregunta incómoda: «¿cómo estaba esta pantalla en la fecha en que se capturó ese expediente?».
Y ahora la parte que se dice 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. El cifrado en reposo y en tránsito, la política de respaldo, la prueba de restauración y el plan de recuperación ante desastres se operan con su área de sistemas o con su proveedor de alojamiento. El sistema le entrega los documentos que esos planes necesitan; no ejecuta su política por usted.
Quién responde por qué
| Asunto | Control de la plataforma | Obligación del sujeto obligado |
|---|---|---|
| Autenticación y sesión | Servidor de autenticación y token firmado de vida corta | Alta y baja de usuarios, y quién queda con qué rol |
| Permisos | Modelo de permiso por rol, pantalla y funcionalidad | La decisión de negocio: quién dictamina, quién aprueba y quién no debe ver el aviso |
| Bitácora | El registro automático de cada transición y de cada consulta a documento | Revisarla. Una bitácora que nadie lee es un archivo, no un control |
| Conservación | Política de retención por tipo de documento y expediente localizable | Fijar el plazo con su fundamento y conocer qué expedientes están bajo recurso o juicio |
| 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 |
| Cifrado | Transporte cifrado hacia la capa de servicios y control de acceso al dato | Cifrado en reposo de la infraestructura y custodia de las llaves |
| Ambientes | Base y servicios separados por sistema; despliegue registrado | Quién tiene acceso a cada ambiente y con qué credencial |
| Designación del responsable de cumplimiento | Rol en el sistema, con sus permisos y su identidad protegida | Designarlo ante la Secretaría, mantener vigente la designación y capacitarlo cada año |
| Cumplir ante la autoridad | La evidencia, ordenada, fechada y entregable | Cumplir. La responsabilidad no es delegable a un programa, y la ley se la atribuye a usted por nombre |
Reparto de responsabilidad declarado, con fundamento en los artículos 18 y 20 de la LFPIORPI · 27 de septiembre de 2026
El expediente de auditoría que el sistema deja
La plataforma sobre la que corre este sistema no sólo genera la aplicación: genera el expediente técnico del sistema. El catálogo tiene 211 documentos en 18 secciones, sin huecos ni duplicados en el rango, definidos en código (el conteo y las secciones). Dos de esas secciones son exactamente lo que un auditor de sistemas pide antes de mirar una pantalla.
La sección de seguridad de la información reúne quince documentos: plan de seguridad, declaración de aplicabilidad, evaluación y tratamiento de riesgos, política de control de acceso, clasificación de la información, continuidad del negocio, recuperación ante desastres, cifrado y protección de datos, privacidad, respuesta a incidentes, evaluación de vulnerabilidades, seguridad en el desarrollo, matriz de controles y concienciación. La sección de gestión de la configuración reúne diez, incluidos 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.
Las secciones del expediente que sostienen una auditoría de sistemas
| Sección | Documentos | Piezas que se piden por su nombre |
|---|---|---|
| Seguridad de la información | 15 | Declaración de aplicabilidad, política de control de acceso, clasificación de la información, cifrado y protección de datos, privacidad, respuesta a incidentes, matriz de controles |
| Gestión de la configuración | 10 | Registro de elementos de configuración, plan de líneas base, informe de auditoría de configuración, matriz de dependencias, plan de control de versiones, documento de ambientes |
| Gestión de cambios | 10 | Registro de solicitudes de cambio, informe de impacto, informe de cambios implementados, documento de reversión |
| Cumplimiento y regulaciones | 12 | Incluye el informe de auditoría interna de cumplimiento |
Fuente: catálogo de documentos técnicos de la plataforma, verificado en código, secciones 06, 07, 09 y 11 · 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 precisiones, porque en esta capa la credibilidad se gasta una sola vez.
La multa por presentar el aviso fuera de tiempo y la multa por no presentarlo no son la misma: la ley las separa por plazo y las mide en veces el valor diario de la unidad de medida y actualización.
- No existe software autorizado ni certificado por la autoridad financiera mexicana para presentar avisos. Lo verificable es que el archivo pase la validación del portal oficial. Cualquier afirmación de «sistema autorizado» es falsa por construcción.
- El régimen de actividades vulnerables no es el de entidades financieras. Son dos regímenes, con dos supervisores y dos formatos de reporte. Confundirlos es el error conceptual más caro de este dominio, y este sistema está construido sobre el primero.
- No se publica ninguna cifra de tiempo del sistema que no esté medida. Las cifras de latencia que circulan en material técnico interno son estimaciones sin instrumentación, y por eso no aparecen aquí ni en ninguna otra página.
- La responsabilidad de cumplir es del sujeto obligado. El sistema le permite demostrar cumplimiento y le impide ciertos errores; no le transfiere la obligación. La ley se la atribuye a usted, y si no hay representante encargado del cumplimiento designado, recae en el órgano de administración o en quien funja como administrador único (artículo 20).
Ese último punto conviene leerlo completo, porque es el que ordena las prioridades de configuración. El aviso presentado a más tardar dentro de los treinta días siguientes a la fecha en que debió presentarse se sanciona con multa de doscientas a dos mil veces el valor diario de la unidad de medida y actualización; si la extemporaneidad excede ese plazo, se aplica la sanción del caso de omisión, de dos mil a diez mil veces; y la omisión propiamente dicha, de diez mil a sesenta y cinco mil veces, o del diez al cien por ciento del valor del acto u operación cuando sea cuantificable, la que resulte mayor (artículos 53 y 54, reformados el 16 de julio de 2025). La reforma añadió además la facultad de ordenar la suspensión temporal de operaciones con determinadas personas clientes o usuarias (artículo 54 Bis).
Preguntas frecuentes
¿Cuánto tiempo hay que conservar el expediente?
Al menos diez años, contados desde la fecha de realización de la actividad vulnerable, con excepción de la fracción XIV del artículo 17. Lo fija el artículo 18, fracción IV, reformado por el decreto publicado en el Diario Oficial de la Federación el 16 de julio de 2025; antes eran cinco. Y el plazo se interrumpe si se promueve recurso o juicio: se reinicia cuando la resolución definitiva queda firme. Un borrado por antigüedad, sin considerar eso, destruye evidencia que la ley todavía exigía.
¿Puedo decirle a mi cliente que se presentó un aviso sobre su operación?
No. La información y documentación soporte de los avisos, y la identidad de quienes los presentaron y de la persona representante encargada del cumplimiento, son confidenciales y reservadas (artículo 38), y quienes deben presentar avisos se abstendrán de divulgar esa información a quien no esté expresamente autorizado (artículo 50). El sistema lo sostiene restringiendo por rol la visibilidad del aviso y de la alerta, y registrando cada consulta.
¿Queda registro de quién consultó un expediente, no sólo de quién lo modificó?
Sí, y son dos rastros distintos. El de modificación lo escribe el motor de estados con estado anterior, estado nuevo, valor anterior, valor nuevo, usuario y hora. El de consulta vive en el propio diseño del sistema: el diccionario del motor trae una entidad que registra cada consulta, descarga o modificación de un documento con usuario, fecha, hora y dirección de red, y otra de accesos a datos personales sensibles con justificación.
¿Quién es la autoridad de datos personales hoy?
Ya no es el instituto que lo fue hasta 2025. La ley vigente se publicó en el Diario Oficial de la Federación el 20 de marzo de 2025, con reforma del 14 de noviembre de 2025, y trasladó la competencia. Si su aviso de privacidad todavía nombra a la autoridad anterior, está desactualizado, y ése es un cambio que en este sistema se hace dentro de la sesión, no con una orden de cambio.
¿El sistema hace el respaldo y el cifrado de mi infraestructura?
No como política corporativa. Cada cambio aplicado incluye respaldo del artefacto tocado e instantánea de versión con su número, lo que permite reconstruir cómo estaba una pantalla en una fecha dada. El cifrado en reposo, la política de respaldo, la prueba de restauración y el plan de recuperación ante desastres son del operador. El sistema entrega los documentos que esos planes necesitan como parte de su expediente técnico.
¿Esto me certifica ante la autoridad?
No, y nadie puede hacerlo: no existe certificación oficial de software para presentar avisos. Lo que existe es que el archivo pase la validación del portal oficial y que usted pueda demostrar, con expediente y bitácora, que identificó, monitoreó, avisó en plazo, capacitó y auditó. La responsabilidad de cumplir sigue siendo del sujeto obligado, y la ley se la atribuye por nombre en el artículo 20.
Referencias
- Ley Federal para la Prevención e Identificación de Operaciones con Recursos de Procedencia Ilícita. Texto vigente, última reforma publicada en el Diario Oficial de la Federación el 16 de julio de 2025. Artículos 17, 18 (fracciones I, III, IV, IV Bis, VI, VII a XI), 20, 21, 23, 24, 38, 39, 50, 53, 54 y 54 Bis. Consultada 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, con reforma del 14 de noviembre de 2025. Sustituye a la ley de 2010 y traslada la competencia a una autoridad distinta del instituto anterior. Consultada el 27 de septiembre de 2026. ↗
- Ley General de Responsabilidades Administrativas, artículo 25: elementos de una política de integridad —manual de organización, código de conducta, sistemas de control y auditoría, canal de denuncia, capacitación y transparencia—. Publicada el 18 de julio de 2016, con reformas del 2 de enero y del 15 de diciembre de 2025. Consultada el 27 de septiembre de 2026. ↗
- Motor del motor de la casa · base del motor de la casa, los tres proyectos del dominio: diccionario de datos (tabla entidad), módulos (modulo_sistema), pantallas y roles con su conteo de permisos funcionales. Corte del propio servidor: 27 de septiembre de 2026, 08:03:53.
- Evidencia de plataforma: dossier técnico del motor de la casa — autenticación, ambientes y tareas del motor; 211 documentos en 18 secciones; pantallas de auditoría y documentación de seguridad; permisos, respaldo y versión; y 500 controladores, vida del token. 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 ComplianceShield 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.