Problema
La conversación cuántica suele saltar del riesgo futuro a nombres de algoritmos. Entre ambos existe el trabajo difícil: descubrir dónde usa criptografía la organización, qué datos deben seguir secretos y qué sistemas no toleran claves mayores.
El certificado de una web es visible. La clave embebida en firmware industrial, la firma de un archivo que debe verificarse dentro de quince años o el protocolo de un proveedor antiguo no lo son. La migración fracasa en esas dependencias olvidadas.
Tesis
La preparación postcuántica es primero un problema de inventario y crypto-agility. Sin mapa de dependencias, ningún estándar puede migrarse con seguridad.
La urgencia real: el riesgo cuántico es futuro; la incapacidad de cambiar criptografía ya es deuda presente.
Framework
Google Cloud recomienda identificar datos y firmas de larga duración, y ofrece mecanismos postcuánticos como ML-KEM junto a firmas ML-DSA y SLH-DSA. Durante la transición, los modos híbridos reducen el riesgo de apostar todo a una sola construcción.
El inventario debe unir activo, algoritmo, biblioteca, owner, vida útil y mecanismo de rotación. Añade quién controla el cambio: tu equipo, un proveedor o un dispositivo imposible de actualizar.
Después prioriza por exposición y duración. Datos capturados hoy y útiles durante años merecen atención antes que secretos efímeros, incluso si el sistema que los protege todavía funciona perfectamente.
Señal medible: porcentaje de usos criptográficos críticos con algoritmo, owner, vida útil y ruta de migración conocidos.
Por que importa ahora
Los nuevos algoritmos ya entran en servicios gestionados, pero sus claves y artefactos pueden ser mucho mayores. Esperar a una fecha límite convierte compatibilidad, rendimiento y rotación en un único proyecto de emergencia.
La fase híbrida no debe quedarse para siempre. Necesita criterio de salida, telemetría de compatibilidad y calendario de retirada del algoritmo anterior.
Anti-ejemplo
“Activaremos post-quantum cuando lo exija compliance.” Compliance no descubrirá por ti certificados embebidos, firmware antiguo ni datos capturados hoy con valor futuro.
El segundo error es migrar primero lo más visible. Una web corporativa puede ser fácil y poco crítica; una firma longeva puede ser difícil y urgente.
Protocolo (3 pasos)
- Inventaría. Localiza claves, certificados, firmas, protocolos y datos longevos.
- Prioriza. Cruza criticidad, vida útil y dificultad de cambio.
- Pilota híbrido. Mide compatibilidad, tamaño y rendimiento antes de migrar.
Haz que cada sistema nuevo declare crypto-agility como requisito: algoritmos configurables, rotación probada y ausencia de claves rígidas. La migración más barata es no crear nueva deuda.
| Campo | Pregunta | Riesgo |
|---|---|---|
| dato | cuánto debe durar secreto | captura hoy, descifra después |
| sistema | puede cambiar algoritmo | bloqueo técnico |
| dependencia | quién la controla | calendario externo |
Relacionado
- Auditoría IA en empresa: 27 preguntas antes de proponer
- Tool Registry: el nuevo mapa de riesgos de los agentes enterprise
Fuentes consultadas
- Google Cloud: Preparing for a quantum-safe future
- Google Cloud: Quantum-safe KEMs in Cloud KMS
- Google Cloud: Security for the AI era at Next ’26
Proximo paso
Empieza por un inventario de veinte sistemas críticos. Marca en rojo cualquier uso criptográfico sin owner, vida útil o mecanismo de rotación.