En la primera nota de esta serie recorrimos el camino completo que hace un programa cuántico, desde que un usuario lo escribe hasta que un qubit físico ejecuta la operación. Hoy nos detenemos en un solo eslabón de esa cadena: el compilador. Es, probablemente, el componente menos visible de toda la arquitectura — y por eso mismo, uno de los más peligrosos si se compromete.
Qué hace exactamente un compilador cuántico
Un programa cuántico se escribe en términos lógicos y abstractos: «aplicar esta compuerta sobre estos qubits, en este orden». Pero el hardware real —ya sea de IBM, Google o cualquier otro proveedor— tiene su propia geometría física particular: qué qubits están físicamente conectados entre sí, qué frecuencias de pulso responden mejor en cada uno, cuánto dura cada operación en ese chip específico. El compilador es el que traduce la descripción lógica del programa a la secuencia exacta de pulsos analógicos que ese hardware en particular necesita para ejecutarlo correctamente.
Es, en cierto sentido, equivalente a lo que hace un compilador de software clásico al traducir código de alto nivel a instrucciones de máquina — pero con una complejidad adicional: en el mundo cuántico, pequeñas imprecisiones en esa traducción (una frecuencia levemente desajustada, un tiempo de pulso apenas distinto) pueden degradar significativamente la calidad del resultado, sin que el usuario tenga ninguna forma directa de notarlo.
Por qué es un blanco tan atractivo para un atacante
Un compilador comprometido tiene un poder enorme y silencioso: puede alterar sutilmente cómo se ejecuta un programa sin que el circuito lógico que el usuario escribió cambie en absoluto. La investigación ya documentó casos concretos de esto. Uno de los más citados es el llamado ataque QTrojan, que demuestra cómo un adversario puede deshabilitar de forma encubierta la codificación de datos de un programa manipulando archivos de configuración del hardware, disfrazando esa manipulación como una simple «calibración de pulsos» rutinaria — el tipo de ajuste técnico que ocurre todo el tiempo y que nadie cuestiona.
También existen demostraciones de robo de circuitos a través de compiladores maliciosos o comprometidos: si un usuario envía un algoritmo valioso —por ejemplo, uno que representa años de investigación en simulación molecular o optimización financiera— a un compilador que no controla, ese compilador tiene, en la práctica, acceso completo al diseño del circuito antes de que se ejecute.
El problema de fondo: confianza sin verificación
Lo que vuelve especialmente delicado a este punto de la cadena es que, hoy, la mayoría de los usuarios de computación cuántica en la nube no tiene forma sencilla de verificar que el compilador hizo exactamente lo que decía hacer. Se confía en el proveedor —IBM, Google, Amazon— casi por definición, de la misma manera en que hoy confiamos en que un compilador de C++ no está insertando código malicioso en nuestros binarios. La diferencia es que la comunidad de seguridad de software clásico lleva décadas construyendo herramientas de verificación para ese escenario (compilación reproducible, cadenas de confianza verificables), mientras que el equivalente cuántico recién está empezando a desarrollarse.
Qué se está haciendo al respecto
Las defensas que ya cubrimos en esta sección —entornos de ejecución confiable cuánticos (QTEE), técnicas de obfuscación de circuitos y compilación dividida entre varios proveedores— apuntan, en gran medida, a mitigar exactamente este problema: reducir cuánto tiene que confiar un usuario en un único compilador o proveedor para poder ejecutar su programa con garantías razonables de integridad.
En la próxima y última parte de esta serie vamos a bajar un nivel más, hasta el hardware de control clásico —generadores de RF, FPGAs, sistemas de calibración— que traduce las instrucciones del compilador en la física real que finalmente mueve a los qubits.
Nota publicada: agosto 2026. Segunda parte de una serie de tres sobre arquitectura de computación cuántica.