En sistemas que manejan documentos electrónicos y firmas digitales, el foco suele estar en que el flujo funcione correctamente: que el usuario firme, que el documento se genere, que el sistema responda.
Desde un punto de vista técnico, eso puede ser suficiente para operar.
Desde un punto de vista probatorio, no lo es.
Muchos problemas legales con documentos electrónicos no surgen por fallas criptográficas ni por ausencia de regulación, sino porque el sistema no fue diseñado pensando en cómo se va a verificar la evidencia años después, fuera del propio sistema.
Este texto aborda ese problema desde una perspectiva técnica. Para una visión general del fenómeno desde el punto de vista jurídico, ver Evidencia digital en juicio: por qué la verificabilidad es fundamental.
Operar no es verificar
Un error común en el diseño de sistemas de firma o conservación es asumir que:
si el sistema puede explicar lo que hizo, entonces el hecho es demostrable.
En la práctica judicial, esto no funciona así.
- Los logs no son prueba.
- Las explicaciones técnicas no son evidencia.
- Los diagramas de arquitectura no sustituyen la verificación.
En un juicio, el sistema no habla.
Habla la evidencia que puede verificarse de manera objetiva e independiente.
Esta diferencia entre operación y prueba es uno de los ejes que explican por qué muchos sistemas fallan cuando llegan a un tribunal, aun cuando funcionen correctamente en producción.
El error técnico más común: firmas que solo el sistema puede “entender”
Hemos visto múltiples casos donde una plataforma implementa correctamente criptografía, pero:
- encapsula firmas en estructuras que requieren conocimiento interno para interpretarse,
- genera artefactos cuya verificación no es evidente fuera del sistema,
- o produce resultados que solo pueden explicarse con ayuda del equipo técnico.
Técnicamente, la firma puede ser correcta.
Probatoriamente, el sistema queda cerrado sobre sí mismo.
Cuando la única forma de verificar una firma es:
- un servicio interno no auditable,
- una herramienta cuya lógica de verificación no puede reproducirse de forma independiente,
- o una explicación posterior del equipo técnico,
el sistema introduce un punto único de confianza que resulta problemático en juicio.
El problema no es que una herramienta sea operada por el proveedor, sino que la verificación dependa de confiar en ese proveedor, en lugar de poder reproducirse y validarse con criterios objetivos.
Cuando la verificación falla fuera de la plataforma
Un patrón que se repite es el siguiente:
- el documento “está firmado” según la plataforma,
- el certificado existe,
- el flujo interno fue exitoso,
pero al intentar verificar el documento fuera del sistema:
- la validación no es directa,
- requiere pasos no documentados,
- o produce resultados ambiguos.
Esto no significa necesariamente que la firma sea inválida.
Significa algo más relevante: la verificación no es evidente ni accesible para terceros.
Desde una perspectiva judicial, esto es crítico.
El juez no va a reconstruir el sistema del proveedor ni aceptar que “así funciona”.
Este mismo patrón aparece en otros contextos tecnológicos, como se explica en Transferencias no autorizadas: bancos pierden juicios.
La constancia y el certificado no se explican: se verifican
Otro error técnico frecuente es tratar la constancia de conservación o el certificado como si fueran documentos explicativos (por ejemplo, PDFs “aclaratorios”).
En realidad:
- una constancia de conservación es una estructura criptográfica,
- un certificado de firma electrónica es un objeto verificable,
y la evidencia de su validez no está en un texto, sino en el resultado de su verificación:
- integridad del contenido,
- validez de la firma,
- cadena de confianza,
- algoritmos utilizados.
Para saber que una constancia o un certificado provienen de un Prestador de Servicios de Certificación autorizado no se requiere un documento adicional.
Se requiere verificarlos correctamente.
Cuando un sistema necesita “explicar” esto con papeles, correos o informes, el problema ya no es jurídico: es de diseño.
El rol crítico de las herramientas de verificación
Desde el punto de vista técnico, una herramienta de verificación no es un accesorio.
Es parte esencial del sistema.
Una plataforma que genera documentos firmados debería asumir que:
- el documento va a salir del sistema,
- será analizado por terceros,
- posiblemente años después,
- en un entorno adversarial (un juicio).
Lo relevante no es quién hospeda la herramienta, sino que:
- la verificación sea determinística,
- el resultado pueda reproducirse,
- no dependa de información privada del proveedor,
- y pueda validarse con criterios técnicos objetivos.
En el caso de Mifiel, la verificación pública de documentos XML está disponible en:
👉 https://app.mifiel.com/verify-xml
Este tipo de herramientas evita que la prueba dependa de explicaciones técnicas posteriores y permite que la evidencia hable por sí misma.
Diseñar para juicio, no solo para producción
Muchos sistemas digitales están bien diseñados para producción, pero no para juicio.
Diseñar para juicio implica hacerse preguntas incómodas desde el inicio:
- ¿puede un tercero verificar este documento sin conocer mi sistema?
- ¿puede hacerlo sin hablar con mi equipo técnico?
- ¿la evidencia sigue siendo verificable dentro de cinco o diez años?
Estas no son preguntas legales tardías.
Son decisiones técnicas tempranas.
La verificación no es un feature, es una propiedad del sistema
Desde el punto de vista técnico, la verificabilidad no es una funcionalidad adicional.
Es una propiedad emergente del diseño.
Cuando un sistema produce evidencia que:
- puede verificarse de forma independiente,
- no depende de la confianza en el proveedor,
- no requiere explicación posterior,
la discusión legal se simplifica.
Cuando no lo hace, el problema no aparece en staging ni en producción. Aparece en juicio.
Este texto es el complemento técnico de una idea más amplia desarrollada en Evidencia digital en juicio: por qué la verificabilidad es fundamental.
