Cada gran proveedor cloud ha intentado venderte un servicio de ledger administrado. AWS tenía QLDB (ahora muerto). Microsoft tiene Azure Confidential Ledger. El discurso es siempre el mismo: nosotros nos encargamos de la criptografía, tú obtienes registros a prueba de manipulación. Suena como un problema resuelto. Pero hay una trampa enterrada en la arquitectura — y solo se hace visible cuando intentas usar estas pruebas fuera de la nube que las creó.
La promesa vs. la letra pequeña
Los ledgers cloud administrados sí proporcionan integridad criptográfica genuina. Hashean tus datos, encadenan bloques, y emiten recibos. Las matemáticas son reales. Pero la ruta de verificación pasa por la API del proveedor cloud. Tu prueba solo es tan accesible como el endpoint del servicio del proveedor.
Cuando un auditor pide evidencia, no puedes entregarle un recibo y decir "verifícalo tú mismo." Tienes que decir: "Ingresa a nuestro portal de Azure, navega a este endpoint, autentícate con estas credenciales, y llama a esta API." Eso no es verificación independiente — es verificación mediada por el proveedor.
Tres formas en que el lock-in socava la integridad
El problema de lock-in se manifiesta de tres formas concretas que erosionan la propuesta de valor de los ledgers administrados:
- ✓Dependencia de verificación: auditores terceros, reguladores y partners necesitan credenciales cloud para validar tus datos. Esto crea fricción, preocupaciones de seguridad y un punto único de falla.
- ✓Riesgo de descontinuación del servicio: AWS cerró QLDB después de 6 años. Todo ledger administrado tiene este riesgo. Cuando el servicio muere, tus pruebas se vuelven inaccesibles — potencialmente justo cuando más las necesitas.
- ✓Imposibilidad multi-cloud: si operas entre AWS y Azure (como muchas empresas lo hacen), ningún ledger cloud cubre ambos. Terminas con integridad fragmentada — algunos registros comprobables en una nube, otros en otra, ninguno universalmente verificable.
El costo real de la verificación opaca
El problema de lock-in no es solo arquitectónico — tiene costos directos de negocio. Cuando la verificación requiere acceso a la plataforma, cada verificación de integridad se convierte en una cadena de dependencias: autenticación, conectividad de red, disponibilidad de API, y estado de suscripción.
En respuesta a incidentes, resolución de disputas o examen regulatorio, esta cadena de dependencias introduce latencia y riesgo exactamente en el peor momento. La pregunta pasa de "¿podemos probar que estos datos no fueron alterados?" a "¿podemos lograr que todos se autentiquen en la plataforma correcta para verificar?"
Cómo luce la verificación neutral a proveedores
La alternativa es prueba que vive en infraestructura que ninguna empresa controla. Las blockchains públicas proporcionan esto: una vez que una raíz Merkle es anclada on-chain, es verificable por cualquiera con un navegador y un explorador de bloques.
Combinado con almacenamiento direccionado por contenido como IPFS para manifiestos y metadata, esto crea una ruta de verificación que no depende de la API, suscripción o existencia continuada de ningún proveedor. La prueba es la prueba — no un puntero al servicio de un proveedor.
Cuándo el lock-in más importa
El lock-in de ledger cloud es especialmente peligroso en estos escenarios:
- ●Exámenes regulatorios — Cuando un regulador exige evidencia de integridad de datos, la prueba necesita ser verificable independientemente — no depender de que tu suscripción cloud esté activa y tus API keys sean válidas.
- ●Disputas entre múltiples partes — Cuando dos partes no están de acuerdo sobre el contenido de un registro, la prueba debe ser neutral. Si vive dentro de la cuenta cloud de una parte, la otra no tiene razón para confiar en ella.
- ●Archival a largo plazo — Los requisitos de retención regulatoria abarcan 7-10+ años. Ningún servicio cloud tiene un historial de disponibilidad garantizada en ese horizonte de tiempo. QLDB duró 6.
Elegir integridad sobre conveniencia
Los ledgers cloud administrados son convenientes. Se integran perfectamente con la infraestructura cloud existente. Pero la conveniencia es la optimización incorrecta para la integridad. El punto de los registros a prueba de manipulación es que la prueba debe sobrevivir condiciones adversas — incluyendo la condición donde el proveedor de servicio sale del mercado. Si tu prueba de integridad requiere la cooperación continuada de un tercero, en realidad no es prueba. Es una promesa.
Si tu prueba de integridad de datos requiere que la API del proveedor esté funcionando, no es prueba — es una promesa. Las promesas expiran. Las matemáticas no.