ComplianceShield · matrices de estado
Un formulario guarda lo que usted escribe. Una matriz de estado decide qué puede pasar después.
Esta página publica dos cosas separadas y las mantiene separadas. Una es lo que el motor de la casa tiene registrado hoy para este sistema, con su conteo y su hora de corte. La otra es la secuencia que la propia ley fija para el expediente, la operación y el aviso, con su artículo. Ninguna fila cambia de columna.
Qué es una matriz de estado, y por qué un formulario no lo es
Un formulario acepta lo que usted escriba. Si el campo pide una fecha, admite cualquier fecha; si pide un estatus, admite cualquiera de la lista, en cualquier orden y capturado por cualquiera. Un formulario no sabe que un aviso no puede estar «presentado» si la operación que lo origina nunca quedó clasificada, ni que quien dictamina una alerta no debería ser quien abrió al cliente.
Una matriz de estado sí lo sabe, porque no guarda un valor: guarda el conjunto de movimientos permitidos. Declara los estados que una cosa puede tener, por cada par de estados, si el paso de uno al otro existe, quién está autorizado a darlo y qué condición tiene que cumplirse antes. Lo que no está en la matriz no se puede hacer, y no porque el botón esté escondido: porque el movimiento no existe.
En cumplimiento esa diferencia no es teórica, es probatoria. El día de la visita de verificación, la autoridad no le pregunta si tiene un sistema. Le pregunta quién identificó a ese cliente, con qué documento, en qué fecha, quién revisó la alerta que esa operación levantó y por qué se cerró como se cerró. En un formulario, eso es una colección de capturas y hay que creerle a quien las hizo. En una máquina de estados es un recorrido: cada paso tiene su autor, su hora y su condición, y los pasos que faltan se ven porque el recorrido está incompleto.
La pregunta que separa un sistema de un formulario es ésta: «¿qué pasa si alguien intenta hacerlo al revés?».
Un expediente que se puede llenar en cualquier orden no es un expediente: es un archivo de texto con bordes.
Anatomía de una transición: las columnas que el motor guarda
Conviene ver el esqueleto antes de nada, porque explica qué se puede afirmar y qué no. Una transición del motor de la casa no es una flecha en un diagrama: es un renglón con campos, y cada campo es una regla. Estas son las columnas reales de las tablas de ciclo de vida, y son las mismas para todos los sistemas de la casa.
Lo que el motor guarda por cada estado y por cada transición
| Campo | Qué significa | Dónde vive |
|---|---|---|
| Estado origen y estado destino | El par de estados que la transición conecta. Sin par, no hay movimiento | Spartan_WorkFlow_Transition |
| Acción | El nombre del movimiento en lenguaje del negocio: «dictamen de la alerta», no «actualizar estatus» | Spartan_WorkFlow_Transition |
| Rol autorizado | Quién puede dar el paso, ligado al catálogo de roles del proyecto | Spartan_WorkFlow_Transition → rol_sistema |
| Condición | Lo que tiene que ser verdad para que el paso se permita | Spartan_WorkFlow_Transition |
| Notificaciones | A qué rol se avisa, en qué evento y por qué canal cuando la transición ocurre | Spartan_WorkFlow_Transition |
| Plazo y escalamiento | Horas de compromiso de la transición y rol al que se escala si se vencen | Spartan_WorkFlow_Transition |
| Reingreso | Marca de vuelta legítima a un estado anterior, distinta de la corrección de un error | Spartan_WorkFlow_Transition |
| Estado: valor, nombre, etiqueta y fase | El estado con su valor, su nombre técnico, su etiqueta visible y la fase del flujo a la que pertenece | Spartan_WorkFlow_State |
| Rol por estado, con su participación y sus permisos | Quién ejecuta, quién revisa y quién sólo consulta en cada estado, con permiso de consulta, alta, modificación, baja, exportación e impresión | Spartan_WorkFlow_Roles_by_State |
| Condición por estado y atributo | El atributo, el operador y el valor que condicionan la permanencia en un estado | Spartan_WorkFlow_Conditions_by_State |
Esquema real de las tablas de ciclo de vida del motor de la casa, consultado el 27 de septiembre de 2026
Ese esqueleto existe y está poblado en otros sistemas de la casa. Para ComplianceShield, al corte de esta página, está vacío. La sección siguiente lo dice con el número, porque publicar una matriz redactada aquí sería exactamente el defecto que esta página existe para no cometer.
Las ocho entidades de este dominio que tendrían matriz
Que el motor no las tenga registradas no quiere decir que no se sepan cuáles son. El diccionario de datos del proyecto sí está poblado, y en él hay entidades que declaran explícitamente un campo de estado. Eso es lo que se publica en esta tabla: el nombre de la entidad tal como está en el motor, el proyecto de donde sale y la frase del propio diccionario que declara que la entidad tiene estado.
Léase con cuidado lo que esta tabla afirma y lo que no. Afirma que la entidad existe en el motor y que su descripción declara un estado. No afirma que existan las transiciones entre esos estados, porque no existen.
Entidad del motor · proyecto · lo que el diccionario declara
| Entidad del dominio | Nombre en el motor | Proyecto | Lo que declara el diccionario de datos |
|---|---|---|---|
| Expediente de identificación | expediente | «Compliance Shield - Background Check» | «Registro principal del proceso» del titular, con su catálogo de estatus aparte (cat_estatus_expediente: «lista de estatus posibles para un expediente») |
| Alerta | alerta | «Compliance Shield» | «tipo de alerta, cliente asociado, score de riesgo, estado y bitácora de resolución» |
| Aviso | aviso | «Compliance Shield» | «el archivo en formato oficial, el estado de presentación, la fecha límite y el acuse de recibo» |
| Operación | operacion | «Compliance Shield» | «monto, tipo, cliente, fecha, forma de pago y el resultado de la evaluación de umbrales» |
| Contraparte | cliente | «Compliance Shield» | «datos de identificación, contacto y estado de su relación con la empresa» |
| Política | politica | «Plataforma Compliance Empresarial» | «contenido, metadatos, estado (borrador, pendiente, publicada, archivada) y versión actual» |
| Hallazgo de auditoría | hallazgo_auditoria | «Plataforma Compliance Empresarial» | «descripción, tipo, evidencia vinculada, acción correctiva asignada y estado de resolución» |
| Capacitación | resultado_prueba_conocimiento | «Plataforma Compliance Empresarial» | «los resultados de las pruebas de conocimiento realizadas por los empleados sobre una política, incluyendo calificación» |
Transcrito del diccionario de datos del motor, tabla entidad de la base del motor de la casa.Medido en el 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.
Una sola de las ocho trae sus estados escritos con nombre y letra en el propio diccionario: la política interna, con cuatro —borrador, pendiente, publicada y archivada—. Es la única lista de estados de este sistema que se puede transcribir del motor hoy, y aun así el motor no tiene registrada ni una transición entre esos cuatro. Se publica la lista; no se publica un recorrido que no existe.
Origen: la norma, no el motor
Lo que la ley sí fija: la secuencia del expediente, la operación y el aviso
Aquí empieza la otra mitad de la página, y cambia el origen de cada fila. Lo que sigue no sale del motor: sale del texto vigente de la ley, cuya última reforma se publicó en el Diario Oficial de la Federación el 16 de julio de 2025. La ley no escribe matrices de estado, pero fija momentos, plazos y condiciones que sólo se pueden cumplir en un orden. Eso es lo que se transcribe.
La diferencia práctica con la tabla anterior es ésta: lo de arriba dice qué existe en el motor; esto dice qué tendría que existir para cumplir. Cuando el motor registre los ciclos de vida de este sistema, las dos tablas se encontrarán, y esta página lo dirá.
Momento que la ley fija · qué lo condiciona · dónde está escrito
| Entidad | Momento que la ley fija | Condición que la propia ley pone | Artículo |
|---|---|---|---|
| Expediente de identificación | Identificar y conocer de manera directa a la persona cliente o usuaria, y verificar su identidad con documentos de reconocimiento oficial | Antes de realizar la actividad vulnerable; con copia de los documentos | Artículo 18, fracción I |
| Expediente de identificación | Identificar al beneficiario controlador cuando la contraparte es persona moral, fideicomiso u otra figura jurídica | Y, si es persona física, recabar su declaración sobre la existencia de un beneficiario controlador | Artículo 18, fracción III |
| Contraparte | Abstenerse de llevar a cabo el acto u operación | Cuando la persona cliente o usuaria se niega a proporcionar la información o documentación; y se abstiene sin responsabilidad alguna | Artículo 21, segundo párrafo |
| Operación | Acumular los actos u operaciones de una misma persona en un periodo de seis meses | Si la suma acumulada supera el monto de aviso de su supuesto, la operación puede quedar sujeta a la obligación de avisar aunque cada acto individual esté por debajo | Artículo 17, penúltimo párrafo |
| Operación | Someter la operación a monitoreo permanente con mecanismos automatizados | Para identificar lo que no encaja en el perfil transaccional, y dar seguimiento intensificado a personas políticamente expuestas o de alto riesgo | Artículo 18, fracción X |
| Aviso | Presentar el aviso ante la Secretaría a más tardar el día 17 del mes inmediato siguiente a aquel en que se llevó a cabo la operación | En el formato oficial publicado en el Diario Oficial de la Federación, y por medios electrónicos | Artículos 23 y 24 |
| Aviso | Presentar aviso dentro de las 24 horas siguientes cuando hay sospecha o información basada en hechos o indicios | Incluso si el acto u operación no se celebró | Artículo 18, fracción VI, segundo párrafo |
| Aviso | Guardar la información soporte del aviso y la identidad de quien lo presentó como confidencial y reservada | Y abstenerse de divulgarla o proporcionarla, por cualquier medio, a quien no esté expresamente autorizado | Artículos 38 y 50 |
| Expediente de identificación | Custodiar, proteger, resguardar y evitar la destrucción u ocultamiento del soporte de la actividad vulnerable | Conservación de al menos diez años, en el domicilio registrado ante la Secretaría; el plazo se interrumpe si se promueve recurso o juicio y se reinicia cuando la resolución quede firme | Artículo 18, fracción IV |
| Política | Elaborar y observar un manual de políticas internas con criterios, medidas y procedimientos | Incluidos los que permiten identificar y dar seguimiento a operaciones con personas políticamente expuestas; y aplicarlo a sucursales y filiales si hay grupo empresarial | Artículo 18, fracción VIII |
| Capacitación | Adoptar programas de capacitación anuales | Dirigidos al órgano de administración, personas directivas, la persona representante encargada del cumplimiento y quienes tratan directamente con clientes | Artículo 18, fracción IX |
| Capacitación | La persona representante encargada del cumplimiento recibe capacitación anualmente | Y su designación se mantiene vigente ante la Secretaría; su identidad se resguarda | Artículo 20 |
| Hallazgo de auditoría | Contar con la revisión del área de auditoría interna, o de una persona auditora externa independiente | Externa obligatoria cuando el riesgo propio es alto; la revisión evalúa y dictamina en un año calendario la efectividad del cumplimiento | Artículo 18, fracción XI |
| Expediente de identificación | Realizar alta, registro, modificación o baja en el padrón de quienes realizan actividades vulnerables | A través del portal en internet y en el formato oficial publicado en el Diario Oficial de la Federación | Artículo 18, fracción IV Bis |
Derivado del texto vigente de la LFPIORPI, última reforma publicada en el Diario Oficial de la Federación el 16 de julio de 2025. No transcrito del motor: el proyecto no tiene ciclos de vida registrados. Las fracciones VII a XI del artículo 18, el artículo 22 Bis y el párrafo de excepciones fueron adicionados por esa misma reforma.
Catorce momentos con artículo. Ninguno de ellos es opinión, y ninguno de ellos está hoy en el motor como transición.
Los roles que el motor sí tiene, y lo que la ley les pone encima
Los roles son la otra mitad de una matriz de estado: sin rol autorizado, una transición es un botón para cualquiera. Y aquí el motor sí tiene contenido. Los roles de los tres proyectos están dados de alta con su tipo y su descripción, y dos de los tres traen además permisos funcionales contados.
La tabla cruza dos orígenes distintos y lo dice en cada columna: el rol y su descripción salen del motor; la obligación que le corresponde sale de la ley.
Rol del motor · su descripción registrada · la obligación que le toca
| Rol (motor, el proyecto «Compliance Shield») | Tipo | Lo que el motor registra | Lo que la ley le pone encima |
|---|---|---|---|
| Compliance Officer (REC) | Operativo | «Responsable del cumplimiento, monitoreo de alertas, generación y presentación de avisos, gestión de riesgos y auditorías»; 17 permisos funcionales | Designación vigente ante la Secretaría, capacitación anual e identidad resguardada (artículos 20 y 38) |
| Gerente de Operaciones | Supervisor | «Supervisa el onboarding de clientes, la correcta identificación y registro de operaciones vulnerables, y la gestión de expedientes»; 12 permisos | Identificación previa y verificación de identidad (artículo 18, fracciones I a III) |
| Personal de Ventas y Atención a Clientes | Operativo | «Realiza el proceso de onboarding y conocimiento del cliente, registra operaciones»; 7 permisos | Abstención de operar si la contraparte no entrega información (artículo 21) |
| Personal de Finanzas | Operativo | «Registra operaciones financieras, controla restricciones de efectivo y colabora en la generación de avisos»; 1 permiso | Umbrales y acumulación de seis meses (artículo 17) |
| Gerente de Recursos Humanos | Supervisor | «Administra capital humano, estructura organizacional y asegura la capacitación del personal en temas de cumplimiento»; 9 permisos | Programas de capacitación anuales (artículo 18, fracción IX) |
| Administrador del Sistema | Administrativo | «Gestión completa del sistema, configuración, usuarios y permisos de acceso a todos los módulos»; 14 permisos | Reserva y confidencialidad del soporte del aviso (artículos 38 y 50) |
Columnas 1 a 3 transcritas de rol_sistema y del conteo de permisos del proyecto «Compliance Shield». Columna 4, derivada del texto vigente de la LFPIORPI.Medido en el 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.
El reparto de permisos entre los tres proyectos también se midió y también se publica tal cual: 60 asignaciones de permiso funcional en el proyecto «Compliance Shield», 82 en el de la variante corporativa y cero en el de «Compliance Shield - Background Check», que es justamente el que sí generó pantallas. Esa asimetría es real y está declarada en la tabla de pendientes.
El motor de estados que sí corre dentro de un sistema generado
Hay que distinguir dos cosas que se parecen y no son lo mismo. Una es la matriz de estado del diseño del proyecto, que es la que está vacía para este sistema y cuyo conteo se publicó arriba. Otra es el motor de estados que corre en ejecución dentro de las aplicaciones que la plataforma genera: ése sí existe, está en código y se puede citar.
Ese motor valida cada transición contra una tabla de transiciones válidas antes de permitirla, comprueba el rol del usuario, y al ejecutarla escribe dos rastros: el historial de la entidad con estado anterior y estado nuevo, y una bitácora con la operación marcada como cambio de estado, el valor anterior y el valor nuevo.
Dos columnas más de esa tabla no son decorativas: requiere comentario y requiere evidencia. El motor las exige al ejecutar la transición. Traducido a cumplimiento: hay pasos que no se pueden cerrar sin que alguien escriba por qué, y pasos que no cierran sin el archivo adjunto. Un dictamen de alerta sin motivo no es un dictamen.
El estado no se escribe: se alcanza. Nadie teclea «presentado» en un aviso; alguien con el rol ejecuta la presentación sobre un aviso que cumple la condición, y el sistema escribe el estado, el autor y la hora.
La tabla de transiciones válidas de ese motor de ejecución tiene hoy 28 filas en la base, correspondientes a las máquinas de estado de aseguramiento de calidad de la propia plataforma, no a este sistema. Se dice con el número para que nadie lo lea como si fueran las transiciones de ComplianceShield: no lo son.
Lo que el motor sí tiene poblado para este sistema
Para no dejar la impresión equivocada: que no haya ciclos de vida no quiere decir que no haya nada. El proyecto que generó pantallas tiene seis módulos con su descripción registrada, veintidós pantallas con su tipo, su ruta y su entidad principal, y veintidós subprocesos. Esas pantallas son las que sostienen la página de pantallas de este sistema, y se listan ahí.
Lo que aquí interesa de ese inventario es una cosa: tres de las veintidós pantallas están construidas sobre entidades que existen para dejar rastro —bitácora de auditoría, control de acceso a datos sensibles y reportes de auditoría—, y el módulo que las agrupa se describe en el motor como «bitácora inmutable de eventos críticos (accesos, decisiones, verificaciones, destrucciones)». Esa es la parte del recorrido que sí está declarada.
Los seis módulos del proyecto, transcritos del motor
| Módulo | Qué agrupa, según el motor | Pantallas |
|---|---|---|
| Motor de cumplimiento regulatorio dinámico | Catálogo de fundamentos legales y perfiles de verificación; generación dinámica del documento de consentimiento; alertas de reformas legales | 5 |
| Plataforma de verificación automatizada | Ejecución de verificaciones contra fuentes externas y detección de inconsistencias entre lo declarado y lo verificado | 5 |
| Auditoría y trazabilidad | «Bitácora inmutable de eventos críticos (accesos, decisiones, verificaciones, destrucciones)» y registro de accesos a datos sensibles con justificación | 3 |
| Portal del titular y consentimiento | Flujo de consentimiento con firma electrónica, carga de documentos y ejercicio de derechos sobre los datos | 3 |
| Ciclo de vida del dato | Control de plazos, retención y destrucción segura con certificado de destrucción | 3 |
| Decisión y notificación | Registro de la resolución con justificación objetiva y notificación con mecanismo de aclaración | 3 |
Transcrito de modulo_sistema y del conteo de pantallas por módulo del proyecto «Compliance Shield - Background Check».Medido en el 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.
Hay módulos, pantallas, roles y entidades. Lo que no hay son las flechas entre estados, y eso es exactamente lo que dice la tabla siguiente.
Cómo leer una matriz de estado cuando la vea en pantalla
Cuando estas matrices estén en el motor, en el sistema se verán de otra manera: cada estado es una columna de tablero o un filtro de bandeja, y cada transición es el único botón que aparece cuando su rol puede darla y la condición se cumple. Si el botón no está, no es que se haya ocultado: es que la transición no existe para usted en ese estado.
Hay una consecuencia de diseño que conviene anticipar, porque la primera vez incomoda. Un sistema con matriz de estado tiene menos botones que un formulario y en cada momento muestra menos opciones. Esa pobreza aparente es el control: la pantalla no le ofrece hacer algo que después alguien tendría que deshacer ante la autoridad.
Y hay una consecuencia de cumplimiento que es la razón de ser de toda la página. La visita de verificación no revisa intenciones, revisa expedientes. Un expediente que se puede completar en cualquier orden, por cualquiera, después de la fecha, es precisamente lo que una matriz de estado hace imposible.
El día que le pidan el expediente, la diferencia entre teclear un estado y alcanzarlo es la diferencia entre un archivo y una prueba.
Por qué esta página se publica así
Se podría haber escrito otra versión de esta página. Ocho tablas con estados de nombre verosímil, flechas entre ellos y un rol en cada renglón. Habría quedado convincente y habría sido falsa, porque el motor no las tiene.
El trabajo de esta capa del sitio es demostrar que un sistema existe. Una matriz inventada no demuestra: contamina todo lo demás, incluidas las páginas donde los datos sí son reales. Por eso el cero se publica con su hora, y por eso la secuencia que la ley fija se publica con su artículo y en una tabla aparte.
Lo que esta página sí sostiene, y no es poco: que el motor de la casa tiene matrices de estado como mecanismo, con su esquema completo y con 6,440 transiciones pobladas en otros sistemas; que este sistema está dado de alta en ese motor con módulos, pantallas, roles, procesos y entidades; y que la ley que gobierna el dominio fija catorce momentos con artículo que cualquier matriz futura tendrá que respetar.
Lo que no se puede sostener, no se escribe. Ésa es la única razón por la que lo que sí está escrito aquí se puede creer.
Preguntas frecuentes
¿Por qué esta página no trae las matrices de estado del sistema?
Porque el motor no las tiene. El proyecto de ComplianceShield en la base del motor de la casa tiene cero filas en Spartan_WorkFlow, cero en Spartan_WorkFlow_State y cero en Spartan_WorkFlow_Transition, medido en el reloj del propio servidor el 27 de septiembre de 2026 a las 08:03:53. Publicar tablas de transiciones redactadas para esta página sería inventarlas, y una matriz inventada invalida la página entera.
Entonces, ¿el motor sabe hacer matrices de estado o no?
Sí, y con números. En toda la base hay 733 ciclos de vida, 5,354 estados, 6,440 transiciones y 14,001 asignaciones de rol por estado, medidos a las 08:14:57 del 27 de septiembre de 2026. El esquema de transición del motor guarda estado origen, estado destino, acción, rol autorizado, condición, notificaciones, plazo, escalamiento y marca de reingreso. Lo que falta es poblarlo para este sistema.
¿Qué sí tiene el proyecto en el motor?
Seis módulos con su descripción, 22 pantallas con su tipo, su ruta y su entidad principal, cinco roles, seis procesos, 22 subprocesos, 41 casos de uso y 37 entidades. Sus dos proyectos hermanos aportan la especificación de la ley y la variante corporativa: 33 y 35 entidades más, seis y siete roles, y 60 y 82 permisos funcionales respectivamente.
¿De dónde salen las filas de la tabla de la ley?
Del texto vigente de la LFPIORPI, cuya última reforma se publicó en el Diario Oficial de la Federación el 16 de julio de 2025. Cada fila lleva su artículo: la identificación previa y el beneficiario controlador en el artículo 18, fracciones I y III; la abstención de operar en el 21; la acumulación de seis meses en el 17; el monitoreo automatizado en el 18, fracción X; el día 17 y el formato oficial en el 23 y el 24; el aviso de 24 horas por sospecha en el 18, fracción VI; la reserva del aviso en el 38 y el 50; y los diez años de conservación en el 18, fracción IV.
¿Y la matriz de comportamiento de campos por estado?
No existe todavía para ningún sistema de la casa. La tabla Spartan_WorkFlow_Matrix_of_States, que es donde viviría —qué campo es visible, obligatorio o de sólo lectura en cada estado—, tiene cero filas en toda la base. Es un pendiente real del motor y se declara con ese dato, no se disimula.
Cuando el motor las tenga, ¿esta página cambia?
Cambia y se dirá cuándo. La tabla de pendientes se encoge y las matrices aparecen con la misma disciplina: entidad, estado origen, estado destino, acción, rol autorizado y condición, transcritas del motor con su fecha y su hora de corte, y separadas de lo que sostiene la norma. Mientras tanto, el cero se publica.
Referencias
- Motor del motor de la casa · base del motor de la casa, los proyectos «Compliance Shield - Background Check», «Compliance Shield» y «Plataforma Compliance Empresarial». Tablas Spartan_WorkFlow, Spartan_WorkFlow_State, Spartan_WorkFlow_Transition, Spartan_WorkFlow_Roles_by_State, Spartan_WorkFlow_Conditions_by_State, Spartan_WorkFlow_Matrix_of_States, modulo_sistema, pantalla, entidad y rol_sistema. Corte del propio servidor: 27 de septiembre de 2026, 08:03:53; conteos globales de la base a las 08:14:57 del mismo reloj.
- 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, 20, 21, 22 Bis, 23, 24, 38 y 50. Consultada el 27 de septiembre de 2026. ↗
- Motor de estados en ejecución dentro del sistema generado: — validación de transición y de rol, estados siguientes válidos, ejecución, historial de la entidad, bitácora con valor anterior y nuevo, exigencia de comentario y de evidencia. Tabla transicion_estado_valida, 28 filas en la base al 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. La autoridad competente dejó de ser el instituto anterior. Consultada 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.