Certyo
Volver al blogRiesgo y Estrategia

Lo que el cierre de AWS QLDB nos enseñó sobre el riesgo de concentración en la capa de evidencia

La lección de QLDB no es "AWS mató un producto". Es que cualquier capa de evidencia corriendo dentro de un solo hyperscaler crea riesgo de concentración para la función de auditoría misma. Cuando el proveedor desaparece, tus pruebas históricas se van con él. Aquí cómo pensarlo.

28 de abril de 2026
8 min de lectura

AWS cerró QLDB el 31 de julio de 2025. La mayor parte de la cobertura lo enmarcó como un problema de migración — qué usar en su lugar, cómo mover datos, quién quedó atrapado. La lección más incómoda es estructural. Una capa de evidencia no es el mismo tipo de dependencia que una base de datos o un caché. Cuando el proveedor de tu capa de evidencia desaparece, pierdes más que un servicio: pierdes la capacidad de defender registros que ya produjiste. Este post es para líderes de seguridad y auditoría que están construyendo estrategias de evidencia plurianuales y necesitan pensar en el riesgo de proveedor en la capa de evidencia misma.

Por qué las capas de evidencia son distintas a otras dependencias

Si tu base de datos de aplicación desaparece, restauras desde backup y sigues. Si tu caché desaparece, sufres un golpe breve de rendimiento. Si tu runner de CI desaparece, vuelves a correr pipelines en uno nuevo. Ninguno de estos fallos cuestiona registros que ya produjiste o afirmaciones que ya hiciste.

Una capa de evidencia es distinta. Su trabajo es hacer una afirmación defendible sobre algo que pasó en el pasado. Si el proveedor desaparece, la afirmación desaparece con él — no porque los registros se hayan ido, sino porque la cadena criptográfica de confianza ya no es alcanzable. Puedes mostrar el registro al auditor. No puedes mostrarle una forma de verificarlo. Esa asimetría es el problema estructural.

Cómo se ve el riesgo de concentración en esta categoría

Hay tres modos de fallo concretos que se componen cuando la capa de evidencia vive dentro de un solo hyperscaler:

  • Cierre de proveedor — el servicio se discontinúa. AWS QLDB el 31 de julio de 2025 es el ejemplo canónico. Tus pruebas pasadas son técnicamente computables durante una ventana de migración, pero la API de verificación va a desaparecer. Lo que anclaste se vuelve una afirmación auto-firmada, no verificable por terceros.
  • Restricción del proveedor — sanciones, controles de exportación o disputas contractuales restringen tu acceso. La capa de evidencia sigue operativa para alguien más; para ti, tiene el mismo efecto que un cierre. Esto no es hipotético para operaciones financieras transfronterizas.
  • Compromiso de cuenta del proveedor — tu tenant del hyperscaler queda bloqueado o vulnerado. El log de auditoría de la capa de evidencia está co-localizado con el resto de tu cuenta. No puedes usar la capa de evidencia para refutar manipulación de sí misma.

Lo que sobrevive cuando un proveedor desaparece

La propiedad arquitectónica que importa aquí es si la ruta de verificación requiere que el proveedor original siga vivo. Con QLDB y Azure Confidential Ledger, sí. Con anclaje on-chain público, no. El contrato de Polygon mainnet que registra una raíz Merkle no es propiedad de Certyo. Si Certyo desaparece mañana, los anclajes on-chain persisten, las matemáticas de verificación no cambian, y cualquier tercero con el registro original todavía puede probar que fue anclado en el timestamp original.

31 jul 2025
Fecha en que AWS QLDB cerró
0
Clientes de QLDB que pueden verificar independientemente un anclaje de 2024 hoy
Indefinida
Vida útil de un anclaje Merkle en Polygon

Esta no es una afirmación sobre la longevidad de Certyo. Es una afirmación sobre la restricción de diseño. Una capa de evidencia que su propio proveedor puede apagar es estructuralmente una peor capa de evidencia que una que no — independiente de cuán bueno sea el proveedor. La función de auditoría merece una dependencia que sobreviva a una sola decisión corporativa.

Cómo evaluar tu riesgo actual de concentración en la capa de evidencia

Si estás corriendo un servicio de auditoría o evidencia de cumplimiento hoy, la pregunta de concentración se responde recorriendo cinco checkpoints. En cada uno, la pregunta es la misma: ¿qué pasa con las pruebas pasadas si esta dependencia desaparece?

Proveedor sigue vivo
Cuenta del proveedor accesible
API de verificación alcanzable
Formato del anclaje legible
Tercero puede re-verificar

Si tu arquitectura actual pierde verificabilidad en cualquiera de los primeros cuatro checkpoints, tienes riesgo de concentración. Si la verificación solo funciona mientras el proveedor está vivo y tienes una cuenta en buen estado, la evidencia es contingente a una relación continuada con el proveedor — lo cual no es lo mismo que evidencia durable. El quinto checkpoint es la barra real: ¿puede un regulador, abogado opositor o ajustador de seguros verificar tu afirmación sin tu ayuda y sin la cooperación del proveedor?

Tres perfiles de comprador donde esto importa más

El riesgo de concentración no es igualmente importante para cada equipo. Se compone en contextos institucionales específicos:

  • Retención multi-decadal reguladaHealthcare, gobierno y ciertos registros financieros tienen ventanas de retención de 7 a 30 años. La probabilidad de que cualquier proveedor único permanezca operativo y accesible por ese horizonte no es 100 por ciento. Una estrategia de evidencia multi-decadal que depende de un solo proveedor es una estrategia con un punto débil conocido.
  • Operaciones transfronterizasSanciones, leyes de residencia de datos y restricciones comerciales pueden cambiar la postura de acceso a un servicio alojado en un hyperscaler de la noche a la mañana. Evidencia que era verificable ayer puede requerir acción legal para verificarse hoy. El anclaje on-chain público no está sujeto a esta clase de disrupción.
  • Litigio y segurosCuando un registro es disputado, la pregunta es si un tercero — corte, regulador, ajustador — puede verificarlo independientemente. Si la verificación requiere cooperación de un proveedor específico, la disputa tiene una dependencia extra que el abogado opositor explotará. La verificabilidad independiente es la barra.

Lo que esto significa para decisiones de arquitectura de capa de evidencia

El cierre de QLDB se lee mejor como una sola instancia de una clase de riesgo intrínseca a las capas de evidencia alojadas por proveedores. La respuesta estratégica no es elegir un proveedor que sea improbable de cerrar. Es elegir una arquitectura donde la verificación no dependa de que ningún proveedor único siga vivo. Los anclajes de Certyo viven en Polygon; la ruta de verificación no requiere que Certyo opere la cadena. Ese desacoplamiento es el punto entero. Para las topologías de despliegue que preservan esta garantía, ver /es/about. Para la primitiva de verificación en detalle, ver /es/blog/blockchain-without-crypto.

Una capa de evidencia que su propio proveedor puede apagar es estructuralmente una peor capa de evidencia que una que no. La función de auditoría merece una dependencia que sobreviva a una sola decisión corporativa.

¿Listo para ver esto en acción?

Solicita una demo y verifica tu primer registro en minutos.