10 de abril de 2026
Introducción
Un programa de compliance de firma electrónica falla cuando existe como política, pero no como control operativo. Para que funcione en México, cada flujo debe tener un alcance definido, un responsable, una regla sobre el método de firma, evidencia esperada y una prueba que demuestre que el control funciona antes de pasar a producción.
También es importante no tratar la e.firma del SAT como la respuesta universal para cualquier documento electrónico. El marco aplicable cambia según el tipo de acto. La Ley de Firma Electrónica Avanzada regula determinados actos y comunicaciones electrónicas en su ámbito, mientras que su artículo 4 remite los actos de comercio al Código de Comercio y excluye materias como la fiscal, aduanera y financiera de su aplicación directa. Para asuntos comerciales, el Código de Comercio contiene reglas específicas sobre mensajes de datos y firmas electrónicas. Por su parte, el SAT identifica la Ley de Firma Electrónica Avanzada y el artículo 17-D del Código Fiscal de la Federación como fundamento de la e.firma en sus trámites.
Por eso, un programa de compliance no debería empezar preguntando “¿qué firma usamos?”, sino “¿qué flujo estamos controlando, qué norma o requisito le aplica y qué evidencia necesitamos conservar?”. A partir de ahí, el equipo puede diseñar controles preventivos, controles de resultado y pruebas periódicas sin convertir una regla sectorial en una política universal.
Definir el alcance por flujo y tipo de documento
El alcance debe enumerar los procesos de firma que realmente operará la organización: contratos comerciales, documentos laborales, formularios internos, trámites frente a autoridades, aprobaciones corporativas u otros casos relevantes. Cada flujo necesita una ficha propia con su propósito, partes, jurisdicción, tipo de documento y área responsable.
Este inventario evita dos errores frecuentes. El primero es aplicar el mismo método de firma a documentos con requisitos distintos. El segundo es creer que un flujo nuevo queda cubierto automáticamente por controles diseñados para otro proceso.
Para cada flujo conviene registrar qué fuente sustenta la regla aplicada. En un trámite fiscal puede ser relevante el Código Fiscal de la Federación y la configuración de e.firma prevista por el SAT. En un acto de comercio, la revisión debe considerar el Código de Comercio y cualquier norma sectorial o contractual que corresponda. Si existe una formalidad especial para el documento, esa exigencia debe analizarse antes de configurar el flujo.
Un flujo fuera del inventario no debería pasar directamente a producción. Primero debe incorporarse al alcance, recibir un propietario y completar su evaluación.
Separar requisitos legales, políticas internas y controles técnicos
Un programa sólido distingue tres capas que suelen mezclarse.
La primera es el requisito jurídico o contractual: qué forma, método o evidencia exige el acto concreto, si existe una exigencia específica. La segunda es la política interna: qué nivel de control decide adoptar la organización por encima del mínimo aplicable. La tercera es el control técnico: cómo se implementa esa decisión en el sistema de firma.
Por ejemplo, una política puede exigir una verificación adicional de identidad para contratos por encima de cierto valor. Esa regla interna no debe presentarse como una obligación general de la legislación mexicana si no lo es. De la misma manera, configurar un método de autenticación en la plataforma no demuestra por sí solo que se cumpla una formalidad jurídica.
La ficha de cada flujo debería mostrar estas capas por separado. Así, cuando cambie una norma, un contrato o una política de riesgo, el equipo podrá identificar qué controles deben revisarse sin reconstruir todo el programa desde cero.
Diseñar controles antes, durante y después de la firma
Cada flujo necesita controles que cubran el ciclo completo, no solo el momento de firmar.
Antes del envío, los controles preventivos pueden verificar la versión del documento, la identidad y rol de los participantes, la autoridad de representación cuando corresponda, el método de firma seleccionado y la ruta de aprobación interna. El objetivo es evitar que un documento incorrecto o un firmante equivocado entre al proceso.
Durante la firma, el sistema debe conservar los eventos y datos que produzca el método configurado. Dependiendo del flujo, esto puede incluir identificación del participante, consentimiento, marcas de tiempo, datos del certificado, resultado de autenticación o información de integridad.
Después del cierre, el control de resultado confirma que el documento final corresponde a la versión aprobada, que actuaron los participantes previstos y que la evidencia esperada quedó disponible y vinculada al expediente correcto.
No todos los flujos generan la misma evidencia. El programa debe documentar lo que realmente produce cada método, en lugar de usar una lista genérica que suponga capacidades inexistentes.
Asignar un responsable y una evidencia a cada control
Un control sin propietario suele convertirse en una tarea que nadie ejecuta. Por eso, cada fila del programa debería indicar quién responde por el control, qué debe revisar, cuándo lo hace y qué evidencia demuestra que la revisión ocurrió.
La responsabilidad puede recaer en Legal, Compliance, Seguridad, Recursos Humanos, Finanzas, Compras o el área de negocio, según el flujo. No es necesario que una sola persona controle todo el proceso; sí es necesario que cada decisión tenga un responsable identificable.
También conviene separar al dueño del control de quien aprueba una excepción. Si un firmante no puede usar el método previsto o una evidencia no está disponible, el programa debe indicar quién puede aceptar el riesgo, bajo qué condiciones y cómo queda documentada esa excepción.
La evidencia de control puede adoptar distintas formas: un registro del sistema, un resultado de validación, una aprobación, una versión final identificada o un expediente de firma. Lo importante es que permita reconstruir qué se comprobó y con qué resultado.
Probar el programa antes de ponerlo en producción
La existencia de un control no demuestra que funcione. Antes de operar un flujo, conviene probarlo con casos definidos y resultados esperados.
Una prueba útil no se limita al escenario ideal. Además del caso exitoso, debería incluir fallos relevantes: participante incorrecto, documento modificado, certificado no válido cuando aplique, autenticación fallida, rechazo de firma, flujo incompleto o ausencia de evidencia esperada.
Para cada caso, el equipo registra el escenario, el control evaluado, el resultado esperado, el resultado obtenido y la evidencia de la prueba. Si ambos resultados no coinciden, el problema se corrige o se acepta formalmente como riesgo antes de la puesta en producción.
Este enfoque convierte el programa de compliance en un sistema verificable. También facilita las revisiones posteriores, porque permite distinguir entre un control diseñado sobre el papel y uno que realmente fue probado.
Gestionar excepciones y cambios sin perder trazabilidad
Los programas de firma cambian: aparecen nuevos documentos, proveedores, métodos de identidad, jurisdicciones o requisitos contractuales. La aprobación inicial no debería convertirse en una autorización permanente para cualquier variante futura.
Cada cambio material debe activar una revisión proporcional. Por ejemplo, incorporar un nuevo tipo de documento, cambiar el método de firma, añadir una jurisdicción o modificar el proveedor de identidad puede requerir actualizar la evaluación jurídica, la evidencia esperada o las pruebas del flujo.
Las excepciones también deben quedar fuera del proceso informal. Si un participante no puede completar el método estándar, la ruta alternativa debe tener criterios de aprobación y evidencia propios. De lo contrario, la excepción termina creando un segundo proceso sin controles.
Mantener versiones del programa ayuda a saber qué reglas estaban vigentes cuando se ejecutó un flujo determinado.
Aprobar el programa con criterios de salida claros
La aprobación final debería producir una decisión operativa concreta: apto para producción, apto con condiciones o no apto. La expresión “homologado” puede utilizarse internamente, pero no debería interpretarse como una certificación jurídica universal del flujo.
Antes de liberar un proceso, el responsable de compliance debería comprobar que el alcance está definido, las fuentes aplicables están identificadas, los controles tienen dueño, la evidencia esperada existe, las pruebas se completaron y las excepciones abiertas cuentan con una decisión formal.
Nota Sign respalda la ejecución de flujos de firma electrónica y conserva los registros que genera el proceso. Con el alcance y la norma ya definidos, Compliance puede convertir controles preventivos, pruebas, excepciones y evidencia en una ruta operativa antes de autorizar la producción.
El resultado esperado no es una colección de políticas, sino un catálogo operativo de flujos en el que cada control pueda responder cuatro preguntas: qué riesgo cubre, quién lo ejecuta, qué evidencia deja y cómo se comprobó que funciona.
Siguiente paso: elige un flujo de alto volumen y pruébalo en Nota Sign con una ruta normal, una excepción y una revisión de evidencia.
