Dependencia de verificación

La dependencia oculta

La mayoría de las organizaciones cree que conserva registros, logs, certificados o sellos temporales que documentan lo ocurrido. Y así es.

Lo que con frecuencia se pasa por alto es que la verificación posterior de esos registros sigue dependiendo de que el sistema original siga disponible, de que el proveedor original siga cooperando, de que la infraestructura original siga viva y de que las credenciales originales sigan siendo válidas.

Esa dependencia es invisible mientras todo funciona. Se convierte en el problema central en el momento en que algo se cuestiona, audita, disputa o revisa en condiciones independientes.

Los registros, logs, recibos y anclajes no bastan

Los registros, logs, bases de datos internas, pistas de auditoría, firmas, recibos en blockchain y anclajes de hash añaden señales útiles de integridad.

Ninguno de ellos, por sí solo, elimina la dependencia del emisor para la verificación posterior. Muestran que algo existió en un momento dado, o que un registro puede reconstruirse consultando el sistema que lo originó. No hacen, por sí solos, que el certificado sea verificable de forma independiente bajo reglas públicas sin la infraestructura viva del emisor.

Tratamos esta distinción de forma explícita en Los registros no bastan.

La continuidad del emisor es un riesgo

La verificación que depende del emisor es una posición expuesta a cambios operativos, organizativos y contractuales.

• Los sistemas se migran, reemplazan o retiran.
• Los proveedores se adquieren, reestructuran o liquidan.
• Las bases de datos internas se rotan, particionan o archivan tras controles de acceso.
• La cooperación entre contrapartes se degrada con el tiempo.
• Las credenciales, los contratos y las políticas que rigen el acceso caducan.
• Las obligaciones y las disputas sobreviven más que los sistemas que las generaron.

Cada una de estas cosas es normal. Ninguna es excepcional. Juntas convierten la continuidad del emisor en una base poco fiable para la verificación a largo plazo.

El paso a `Independent`

CERTCRYPT introduce una distinción entre dos estados formales de un certificado.

`Issued` significa que el emisor produjo el certificado. El certificado existe. Puede consultarse, presentarse y referenciarse a través de los sistemas del emisor.

`Independent` significa que la verificación posterior ya no depende de los sistemas vivos del emisor. El certificado ha alcanzado las condiciones estructurales necesarias para la verificación independiente bajo reglas públicas.

`Issued` no es `Independent`. Un certificado puede emitirse sin alcanzar nunca `Independent`. CERTCRYPT es la infraestructura que permite que determinados certificados alcancen `Independent` en el momento de la emisión, de modo que la dependencia de verificación se resuelve cuando el certificado se crea, no se reconstruye después.

El modelo arquitectónico que lo sustenta se describe en Arquitectura de certificación.

Dominios expuestos a la dependencia de verificación

La dependencia de verificación se convierte en un riesgo estructural reconocible en entornos donde el coste de una verificación futura fallida es mayor que el coste de certificar la independencia en el momento de la emisión.

• Banca, finanzas y auditoría, donde reguladores, tribunales y contrapartes pueden requerir más adelante pruebas en condiciones independientes.
• Gobernanza de la IA, donde decisiones automatizadas pueden necesitar revisión, defensa o impugnación mucho después de que el modelo y el sistema hayan cambiado.
• Flujos legales y de cumplimiento, donde una versión, estado o momento específico debe seguir siendo atribuible años después.
• Educación y certificación, donde las credenciales deben seguir siendo verificables más allá de la ventana operativa de la institución emisora.
• Comunicaciones y notificaciones con efecto legal o contractual posterior.
• Activos tokenizados y digitales, donde las transiciones de estado deben seguir siendo evaluables de forma independiente de la plataforma que las registró.
• Flujos operativos críticos, donde los logs por sí solos no bastan para sostener la verificación independiente posterior.

Siguiente paso

Si su entorno presenta dependencia de verificación sobre sistemas, proveedores o instituciones cuya disponibilidad a largo plazo no está garantizada, la pregunta es si determinados certificados, registros o decisiones deberían alcanzar `Independent` en el momento de la emisión.

Enviar un caso de uso →