Mostrando entradas con la etiqueta LLM. Mostrar todas las entradas
Mostrando entradas con la etiqueta LLM. Mostrar todas las entradas

lunes, noviembre 09, 2026

LLMJacking: Cómo los cibercriminales usan Tokens IA que pagas tú.

Llevo tiempo hablando el abuso de las cuentas y servicios de los modelos LLM que utiliza una empresa por parte de atacantes y cibercriminales, pero cada vez parece que está más industrializado y escalado. De esto habla el informe del equipo de Google Threat Intelligence Group titulado: "The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources" donde recoge las técnicas de LLMJacking como una de las más utilizadas hoy en día por los cibercriminales.

El objetivo es el mismo del que os hablo muchas veces, cómo conseguir que un LLM que paga otro - ya sea en un modelo SaaS en una plataforma de Cloud, en una API, o por medio de computo GPU en servidores locales, acabe trabajando para el atacante gratis. Eso es lo que quieren los ciberciminales, que paguen las víctimas sus Tokens AI.
Para conseguir esto existen muchas técnicas, distintas, y todas les son válidas. La primera de ella, y más evidente, es robar las cuentas de los proveedores de Cloud que tienen servicios de LLM, o las cuentas de los Servicios de IA directamente desde las empresas que los crean y los comercializan, como OpenAI o Anthropic, por supuesto. Para ello, las campañas de phishing, el malware en los equipos donde se usan, y demás son clásicos. Nada nuevo bajo el sol más que robar las cuentas.

Figura 3: LLMJacking

También hay que hacer notar que el robo de Tokens OAuth, evitando así los segundos factores de autenticación, es un clásico en estos esquemas, ya que si se roba el adecuado, como el caso del Scope de cloud-platform en Google Cloud, se puede acceder a configurar todos servicios LLMs en esa cuenta. 
Con estas dos opciones, o una cuenta privilegiada o un Token OAuth con el Scope de cloud-platform, el atacante se configura el LLM a su gusto, y como vemos en el informe, comienza a consumir a lo grande. Al final, es gratuito para ellos, así que barra libre.
Por supuesto, además de robar las cuentas, se puede funcionar bien robando directamente las API Keys, que es algo bastante sencillo de hacer en servicios inseguros en App Móviles o Aplicaciones Web  inseguras. A finales del mes de Junio os hablé de esto en el artículo titulado: "Cómo filtrar las API Keys de los LLMs en las Apps de iPhone y Android" donde se recoge un estudio que explicaba las diferentes alternativas, basadas en:
  • Robar la API Key del Código
  • Robar una sesión autenticada
  • Robar el acceso mediante LLM-Proxys que configuran los servicios.
De todos estos problemas, en el artículo tienes explicaciones detalladas de cada uno, porque al final es bastante evidente cómo se pueden explotar estas debilidades en el momento en que existen en tantos servicios digitales "powered" con LLMs como tenemos hoy.
Por último, el artículo cita algo de lo que os he hablado y hecho muchas demostraciones, que es directamente "desalinear" los servicios digitales - en mis ejemplos los Asistentes IA de soporte - y conseguir que el modelo acaba trabajando para el atacante.
Tenéis la lista de los artículos que he publicado sobre estos casos en la siguiente lista que os dejo aquí para que los leáis con calma.
Debido a eso, poner una solución como AI Gateway de Cloudflare con Control de Costes de Servicios IA es fundamental. En el caso de Cloudflare para evitar estos abusos, se introdujeron los Controles de Consumo con Cuotas por usuario, servicio, día, para evitar estos. 

Para terminar, el reporte directamente apunta a cómo se comercializan, con servicios como jet-night, un servicio que carga costes a cuentas vulneradas, y que, tal y como describe el reporte.
teniendo en cuenta los costes que cobra a sus clientes, y lo que carga en plataformas como Google Cloud, es ilegal, pues saldría a negativo si tuviera que pagar por los LLMs... pero lo hacen las víctimas.


En definitiva, el LLMJacking como se ha dado a llamar a esta técnica, es algo de lo que tienes que preocuparte, y cuando pones un servicio con IA en producción debes revisar en detalle cuáles son los posibles riesgos de abuso.
Ten en cuenta, que los modelos LLM de la IA hoy en día sirven para muchas cosas, en el mundo del cibercrimen son fundamentales, como vimos en los artículos de "Weaponized AI: El Crimeware con IA que usan los Cibercriminales para hacer Ciberestafas".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


lunes, octubre 26, 2026

Inteligencia Artificial en las empresas: Tres formas de uso. Tres niveles de control del riesgo.

Cuando hablamos de Inteligencia Artificial en las organizaciones, lo habitual es asociarla con ChatGPT, Claude o cualquier otra herramienta a la que accedemos desde un navegador. Esta asociación está bastante extendida entre las empresas menos tecnológicas y, en muchos casos, responde al desconocimiento de cómo funciona realmente esta tecnología. 


La Inteligencia Artificial necesita, recursos de computación, almacenamiento y sistemas capaces de procesar información. La capacidad de estos modelos para realizar determinadas tareas mejor o peor que las personas es otra discusión que dejaremos para otro artículo. Lo interesante aquí es comprender cómo accedemos a esta tecnología, qué ocurre con nuestros datos y qué capacidad real tenemos para aplicar medidas de control que reduzcan los riesgos.
En muchas organizaciones he observado que la gestión de estos riesgos se apoya principalmente en políticas de uso, herramientas DLP e instrucciones incorporadas a los Prompts para limitar el comportamiento de la IA. No es la solución.

Estas medidas pueden ayudar, pero presentan limitaciones importantes.

Un Prompt no constituye una barrera de seguridad fiable: Y si has visto los muchísimos artículos sobre las técnicas de Jailbreak, los ataques de Prompt Injection, o el desalineamiento de Asistentes IA y servicios digitales, lo tendrías que tener más que claro.
Los modelos pueden recibir instrucciones adversarias, interpretar incorrectamente las restricciones o generar comportamientos no previstos. 
Es precisamente una de las cuestiones sobre las que Chema Alonso insiste habitualmente en sus investigaciones y charlas sobre seguridad en IA. Para comprender mejor estas limitaciones, vamos a comparar tres formas de utilizar esta inteligencia artificial.

1. Acceso directo mediante navegador

Es el modelo más conocido. La organización contrata licencias de un servicio de Inteligencia Artificial y sus empleados acceden directamente desde el navegador. En realidad, estamos consumiendo un servicio de un proveedor externo, bajo determinadas condiciones contractuales, configuraciones de privacidad y mecanismos de seguridad que solo el propio proveedor impone. Cuando un empleado introduce información en el chat y pulsa enviar, esos datos llegan a la infraestructura del proveedor.

Figura 5: Flujo de información desde el usuario hasta
el proveedor de IA mediante navegador.
 
La organización puede establecer políticas de uso, aplicar controles DLP, restringir accesos y exigir garantías contractuales. Sin embargo, las funciones de protección más avanzadas suelen estar vinculadas a planes empresariales con costes adicionales, lo que puede dificultar su adopción por parte de pequeñas y medianas organizaciones.

Además, el comportamiento humano introduce una dificultad adicional. Un empleado puede compartir información confidencial, ignorar las instrucciones corporativas o utilizar herramientas de IA sin autorización, una práctica conocida como Shadow AI. Este fenómeno dificulta la aplicación de medidas de control y aumenta el riesgo de exposición de información fuera del perímetro organizativo. La exposición del dato puede producirse antes de que cualquier instrucción dirigida al modelo tenga oportunidad de intervenir.

2. Integración mediante API y backend corporativo

El segundo método permite introducir una diferencia importante. En este escenario, la organización desarrolla una aplicación con su propio front-end y backend. El empleado interactúa con esa aplicación y es el backend quien se comunica con el modelo del proveedor mediante una API. Esta arquitectura permite aplicar medidas técnicas antes de que la información salga de la organización.

Podemos clasificar los datos, eliminar información innecesaria, aplicar técnicas de pseudonimización, verificar permisos, limitar las operaciones autorizadas y registrar las solicitudes. También podemos revisar las respuestas del modelo antes de utilizarlas.

Figura 6: Flujo de información mediante una aplicación corporativa,
backend y API de un proveedor externo de IA.

El proveedor continúa procesando la información que recibe, pero la organización puede controlar mejor qué envía y para qué finalidad. La diferencia está en incorporar controles técnicos directamente al flujo de información, reduciendo la dependencia de las decisiones individuales de cada empleado. El riesgo permanece, aunque una implementación correctamente diseñada puede reducir tanto la exposición como la probabilidad de determinados incidentes.

3. Despliegue de inteligencia artificial en infraestructura local

El tercer método consiste en ejecutar el modelo dentro de la propia infraestructura de la organización. Actualmente existen modelos de inteligencia artificial con capacidades avanzadas que pueden desplegarse en servidores internos, como gpt-oss-20B (OpenAI), Mistral Small 3.1 de 24B, Gemma 3 de 27B (Google), Qwen3 de 32B (Alibaba), LLaMA de 65B (Meta, primera generación), Llama 3.3 de 70B y gpt-oss-120B (OpenAI). 

Estos modelos pueden ejecutarse utilizando recursos propios de CPU, GPU, memoria y almacenamiento, con requisitos técnicos que varían según su tamaño, arquitectura y nivel de cuantización. En esta arquitectura, el front-end, el backend, el modelo y los sistemas de almacenamiento pueden permanecer dentro del mismo perímetro organizativo. Estas arquitecturas son muy usadas por los expertos que usan IA para hacer Seguridad Ofensiva y Pentesting.

Esto permite controlar directamente el procesamiento, los accesos, los registros de actividad, la retención de información y las conexiones con otros sistemas. También ofrece la posibilidad de operar sin enviar los datos utilizados durante la inferencia a proveedores externos, siempre que las dependencias, la telemetría y las integraciones estén correctamente configuradas.

Figura 8: Flujo de información con un modelo de IA local dentro
del perímetro de la organización y sus dependencias externas.

La contrapartida es que la organización asume la responsabilidad de proteger y mantener toda esa infraestructura. Una mala configuración, un usuario con privilegios excesivos, un conector vulnerable o un modelo expuesto pueden generar incidentes igualmente graves.

La arquitectura es una medida de control

Los tres escenarios permiten utilizar inteligencia artificial, pero presentan diferencias importantes en la exposición de los datos, la dependencia de terceros y la capacidad de aplicar medidas de seguridad. Contratar licencias, integrar una API o desplegar un modelo local no determina automáticamente el nivel de seguridad de una organización.

La cuestión es comprender el recorrido de la información y establecer controles eficaces en cada punto de ese recorrido.Las políticas y las instrucciones pueden orientar el comportamiento de los usuarios y de los modelos. Las medidas técnicas permiten imponer restricciones verificables, aunque tampoco ofrecen garantías absolutas.


Al final, todo se reduce a entender por dónde circulan nuestros datos, quién los procesa y hasta dónde llega nuestra capacidad de control. Utilizar Inteligencia Artificial es relativamente sencillo; gestionar sus riesgos requiere conocer bien cómo funciona y cómo la hemos integrado en nuestra organización.


Figura 9: CDIE: Risk Extension and Traceable Uncertainty in Organizational Al Risk Assessment.

Y aprovechando que hablamos de riesgos y consecuencias, estoy desarrollando CDIE, una investigación exploratoria centrada en identificar y documentar las posibles consecuencias de las decisiones relacionadas con inteligencia artificial, especialmente cuando afectan a otras partes implicadas directa o indirectamente. Para quienes tengan curiosidad, la propuesta metodológica está publicada que puede consultarse aquí: CDIE: Risk Extension and Traceable Uncertainty in Organizational Al Risk Assessment.


sábado, octubre 24, 2026

Rufus, el Asistente IA de Amazon: De "Shopping Assistant" a hacer Troubleshouting de red con Powershell y Nmap en una charla

Una consulta sobre unos auriculares termina en instrucciones de PowerShell, solicitudes de permisos de administrador y noticias de actualidad. Todo ocurre en la ventana de Agente IA dentro de Amazon.es. El recorrido es llamativo porque el asistente mantiene su identidad comercial mientras acompaña al usuario hacia tareas cada vez más alejadas de la compra inicial. 


El punto sensible es cuando el Asistente IA comercial comienza a proporcionar apoyo operativo. El modelo aporta instrucciones, explica conceptos y orienta la siguiente acción. La persona puede aportar lo que el chat no tiene, acceso a un equipo, una sesión corporativa y capacidad para ejecutar esas indicaciones. Esa combinación abre una vía de riesgo incluso sin ejecución autónoma por parte de la IA. 


El caso permite examinar una consulta cotidiana convertida en una sesión de asistencia técnica reutilizable con fines maliciosos. La reducción del esfuerzo para investigar, preparar código o comprender un entorno forma parte del escenario de amenaza. Un usuario con conocimientos limitados puede apoyarse en estas capacidades para avanzar más allá de lo que resolvería por sí solo. 
Si has leído hsta aquí, mi recomendación es que te leas los artículos que Chema Alonso ha dedicado a los Asistentes IA, y que si quieres saber más, veas la charla que dio en la Ekoparty con demos en directo sobre este tema. 
Ahora, vamos a ver este caso concreto, que seguro que te va a interesar toda la historia. No te pierdas detalle.  

Análisis de caja negra

Amazon presenta RUFUS, su Agente IA como un asistente de compras disponible en la web y en su aplicación. También documenta el uso de información de Internet en algunas de las familias de productos. El interés del caso está en la combinación de ese acceso informativo con respuestas sobre administración y en la facilidad con que el hilo cambia de finalidad.


La interacción se estudia desde la interfaz visible. El hilo conecta soporte de producto, comprobación de firmas, permisos, diagnóstico de red, información externa y preguntas sobre límites. Esa continuidad permite analizar la ayuda que recibe una persona y cómo podría aprovecharla para construir una secuencia operativa.

Como cualquier especialista en ciberseguridad, empezaría por una pregunta muy sencilla. ¿Qué conocimientos puede llegar a proporcionar el asistente, qué acciones facilita y qué barreras encuentra el usuario al intentar trasladar esas respuestas a un entorno real?

Consultas sobre auriculares validación de firmas y elevación de privilegios en PowerShell

La consulta inicial sobre el funcionamiento de unos auriculares desemboca en la verificación de un instalador. El usuario afirma que necesita PowerShell como administrador. El Agente IA acepta la premisa con un «Es normal que lo solicite» y explica cómo abrir una sesión elevada. 

Figura 5: Haciendo Powershell con Rufus. La comprobación de firma
deriva hacia una consola con permisos de administrador

En PowerShell, el comando Get-AuthenticodeSignature permite comprobar la firma digital de un archivo sin necesidad, generalmente, de privilegios de administrador. El problema comienza cuando Agente IA, diseñado como asistente de compras de  Amazon, abandona su ámbito funcional y empieza a proporcionar instrucciones sobre administración de Windows y elevación de privilegios. 

Figura 6: Aprendiendo a elevar privilegios con Powershell

Una consulta sobre unos auriculares termina convirtiéndose en asistencia técnica para operar sobre el sistema, algo ajeno a su finalidad comercial. Lo que sí que es cierto es que parece que se ha leído el libro de "Pentesting con PowerShell Silver Edition" de Pablo Gonzáleez en 0xWord. Se las sabe todas.

Esta desviación abre un riesgo mayor. Un atacante podría aprovechar la disposición del asistente a responder fuera de su alcance para solicitar ayuda progresiva sobre scripting, ofuscación, enumeración de usuarios o técnicas relacionadas con Active Directory. La asistencia interactiva permitiría a personas con conocimientos limitados avanzar en tareas complejas, sin recurrir a herramientas especializadas ni a la Dark web.

Figura 7: Comprar libro de "Pentesting con PowerShell Silver Edition"

Posteriormente, Agente IA reconoce que comprobar una firma no requiere privilegios administrativos, aunque previamente había recomendado elevarlos. El fallo relevante no es únicamente la recomendación técnica, es que un asistente de compras haya asumido funciones de administración de sistemas para las que no fue concebido.

Start-Process powershell -Verb RunAs solicita abrir un proceso como administrador. Windows mantiene sus comprobaciones de autorización mediante UAC. El riesgo de esta secuencia está en impulsar al usuario hacia una sesión privilegiada y normalizar su uso para continuar el diagnóstico.

En un entorno corporativo, una instrucción presentada como el siguiente paso puede favorecer que el usuario busque credenciales, acepte una solicitud administrativa o trabaje con permisos superiores a los necesarios. El alcance de lo que ejecute después dependerá de esa identidad y de los controles del equipo.

De la elevación de permisos al reconocimiento de red

El usuario insiste en elevar permisos y recibe instrucciones con RunAs. Después cambia de objetivo y pide explorar la red. Agente IA enlaza ambos temas dentro del mismo hilo y entrega comandos de diagnóstico.

Figura 8: Instrucciones sobre RunAs y diagnóstico de red dentro del mismo hilo

La conversación pasa después a la red. arp -a consulta la caché ARP y Test-Connection realiza comprobaciones ICMP. Todas Son herramientas de administración que también pueden aportar información útil para el reconocimiento de un entorno. 

Figura 9: Y acabamos con el Nmap. Más hacker no se puede ser.

El Agente IA Rufus cuenta todo esto dentro del mismo hilo de conversación. El usuario no necesita conocer de antemano qué utilidad consultar ni cómo formular el comando. La respuesta le proporciona una primera orientación y abre la posibilidad de pedir explicaciones sobre los resultados o plantear una nueva tarea.

En un escenario de abuso, ese acompañamiento podría ayudar a ordenar información sobre equipos y conectividad para preparar acciones posteriores. La evaluación debe atender a la intención acumulada del hilo y a la asistencia concreta que facilita cada respuesta, además del contenido de un comando aislado.

El usuario puede convertirse en el ejecutor de la IA

Al pedirle un ping externo y una descripción de sus capacidades, Rufus explica que la ejecución corresponde al usuario. El asistente aporta orientaciones y comandos. La persona queda a cargo de trasladarlos al equipo, donde dispone de una identidad y unos permisos efectivos.

Figura 10: Rufus proporciona orientación técnica y reserva la ejecución al usuario.

El asistente no necesita ejecutar código por sí mismo para contribuir a una operación. La persona puede copiar sus indicaciones en una consola, aportar resultados y solicitar nuevas explicaciones. El modelo actúa como apoyo técnico mientras la ejecución queda fuera de su interfaz.

El riesgo de uso malicioso consiste en convertir esa relación en ayuda continuada para preparar scripts, comprender errores o planificar tareas. Si los controles permiten tal asistencia, el usuario podría avanzar sin dominar previamente cada componente técnico de la operación.

Figura 11: Aquí ya estamos tomando control. Vamos a salir a Internet.
Gracias Rufus.

Microsoft ha observado actores de amenaza recurriendo a modelos de lenguaje para generar o refinar scripts, comprender tecnologías y resolver problemas. Esa asistencia puede ahorrar esfuerzo y proporcionar conocimiento puntual, aunque el acceso a los sistemas siga dependiendo del operador.


En Active Directory, un escenario a considerar sería la ayuda para interpretar información sobre usuarios, grupos y permisos y utilizarla en la preparación de accesos no autorizados. También existiría riesgo de exposición si una persona pegara resultados internos del directorio en un servicio externo.

OSINT - Fuentes externas y productos que aún no están en el mercado.

El hilo abandona el diagnóstico y entra en los próximos lanzamientos tecnológicos. Rufus responde con nombres de productos, fechas y características, acompañados de referencias visibles de páginas web que ha visitado para obtener dicha información. El Asistente AI abandona nuevamente su función comercial y comienza a proporcionar información sobre lanzamientos tecnológicos, especificaciones y noticias, recurriendo a fuentes externas.

Figura 13: Previsiones de lanzamientos con referencias externas
y una advertencia sobre rumores. 

Este comportamiento abre una posibilidad especialmente interesante para los ciberdelincuentes mediante técnicas OSINT (Open Source Intelligence). La recopilación de información pública sobre posibles víctimas constituye una fase habitual de preparación de ataques. Permite identificar empleados, tecnologías utilizadas, proveedores, infraestructura expuesta y posibles puntos débiles de una organización.


Un Asistente IA como Rufus, capaz de consultar, relacionar y resumir información de Internet podría facilitar estas investigaciones desde una única interfaz, reduciendo el tiempo necesario y los conocimientos técnicos del atacante. Además, actuaría como intermediario entre quien realiza las consultas y las fuentes originales, disminuyendo la exposición directa de su actividad ante determinados sitios web, aunque sin garantizar el anonimato ni eliminar los registros del proveedor.

Las fechas revelan un problema de fiabilidad

Tras recibir un resumen de noticias, el usuario pregunta por las fechas. Rufus presenta una respuesta que afirma reunir noticias del 20 de octubre de 2026, pero incluye un bloque del día 13 y etiqueta ambos días como lunes.  Hay una inconsistencia que puede comprobarse sin validar las noticias. El 13 y el 20 de octubre de 2026 fueron martes. Además, la afirmación de que todas las noticias son del día 20 no encaja con el bloque fechado el 13. Vamos, una pequeña Hallucination de libro. Del libro de Hacking IA, claro.

Figura 15: El resumen combina fechas incompatibles con su propia presentación

La respuesta añade una matización sobre una noticia anterior cuya fecha no pudo determinar. Esa corrección parcial deja sin resolver la contradicción de los encabezados y la diferencia entre fecha del suceso, publicación y consulta. 

El problema operativo es la confianza que puede generar una respuesta detallada y acompañada de fuentes. El usuario recibe un resumen aparentemente organizado, aunque contiene señales internas de error. La precisión de la presentación puede ocultar la fragilidad de la información.

OWASP recoge la información incorrecta y la confianza excesiva en las respuestas dentro de LLM09 "Misinformation"de 2025. El riesgo aumenta cuando esas salidas se incorporan a decisiones, procedimientos o código sin una validación adecuada.

Una incoherencia equivalente podría alterar la prioridad asignada a una vulnerabilidad, distorsionar un informe de incidentes o sostener una recomendación de configuración equivocada. El posible impacto es conectar el output con el input del siguiente proceso y podría desencadenar consecuencias difíciles de detectar.

Obtención del límite de output configurado en el backend

Rufus, afirma que contar números en serie no forma parte de su función. Después cuenta hasta diez y hasta cien. Cuando el usuario pide llegar a trescientos y luego a doscientos, vuelve a rechazar la tarea por quedar fuera de su papel de asistente de compras.

La prueba de contar números tenía un objetivo más allá de comprobar si este Asistnte IA aceptaba tareas ajenas a su función comercial. Buscaba identificar posibles límites de generación de respuestas configurados en el backend del Agente IA.

Figura 16: Primero acepta la tarea.

Agente IA acepta contar hasta 100, pero rechaza solicitudes de 200 y 300 números, argumentando que esa tarea queda fuera de su función como asistente de compras. Esta diferencia plantea la posibilidad de que exista una restricción de longitud de salida que el modelo no reconoce explícitamente.

Figura 17:  Pero luego rechaza contar más.

Mediante solicitudes progresivas, comenzando por 100 números y aumentando gradualmente la cantidad, sería posible estudiar hasta dónde responde el asistente, cuándo empieza a rechazar las peticiones y si permite continuar la secuencia en mensajes posteriores.

El interés desde la perspectiva de Misalignment & Jailbreak está en determinar si una conversación prolongada permite identificar o sortear restricciones de salida mediante peticiones fragmentadas. Este comportamiento guarda relación con las técnicas multivuelta estudiadas in Crescendo, donde el contexto acumulado puede modificar las respuestas del modelo.


Al final, como hemos venido viendo en todos los artículos publicados sobre Asistentes IA en este blog, Rufus tiene la misma arquitectura, y requiere por eso tener un control extra de Guardrrailes, y sistemas de monitorización, porque los ataques y los mal-usos de los atacantes van a incrementar en complejidad. Hoy en día, vemos claramente que nos queda margen de mejora en seguridad y control.

jueves, octubre 22, 2026

Claude Mythos reduce hasta 39 veces el coste de Circuitos Cuánticos

Hace poco os contábamos en este blog cómo Claude Mythos Preview se había sentado atrabajar como criptoanalista y había encontrado nuevas formas de debilitar HAWK y AES. Aquella historia tenía a la Inteligencia Artificial buscando grietas en los algoritmos que protegen nuestra información. Ahora Claude vuelve a aparecer en el mundo de la Criptografía y la Computación Cuántica, pero en el lado contrario de la mesa. Esta vez no intenta romper un algoritmo: intenta diseñar los circuitos con los que funcionarán los ordenadores cuánticos del futuro.

 
La ironía es bastante buena. Una Inteligencia Artificial clásica está ayudando a reducir los recursos que necesitarán los Quantum Computers que, algún día, podrán ejecutar algoritmos como el de Shor y poner contra las cuerdas a buena parte de la criptografía actual.


El trabajo, liderado por Andi Gu dentro del programa STEM Fellows de Anthropic junto con Alek Kemeny, Susanne Yelin y Mikhail Lukin, plantea un experimento aparentemente sencillo: darle a Claude Mythos 5 la descripción en lenguaje natural de ocho circuitos cuánticos, dejar que proponga implementaciones en Python y utilizar un evaluador independiente para comprobar que funcionan y medir cuánto cuestan.


El resultado es de los que obligan a mirar dos veces la tabla. En siete de las ocho tareas, los circuitos encontrados reducen simultáneamente el número de Puertas Toffoli y el número de qubits respecto al mejor diseño de referencia. En las comparaciones directas, la mejora del coste combinado llega hasta 39 veces. Y en la octava tarea Claude no se limitó a optimizar una implementación conocida: encontró una nueva arquitectura reversible pararealizar inversión modular.

La carrera cuántica no se gana sólo fabricando mejores qubits

Cuando hablamos de Quantum Computing solemos imaginar que el gran cuello de botella está en el hardware: fabricar más qubits, mantenerlos aislados del ruido y corregir sus errores durante el tiempo suficiente. Y todo eso es cierto. Los procesadores actuales siguen teniendo muy pocos qubits para ejecutar muchas de las aplicaciones que prometen una ventaja real, y además son extraordinariamente frágiles. Pero hay otra forma de acercar una aplicación al hardware disponible: hacer que el algoritmo necesite mucho menos ordenador.

El ejemplo que utiliza Anthropic es FeMoco, el cluster de hierro y azufre que se encuentra en el corazón de la nitrogenasa, la enzima con la que algunas bacterias convierten el nitrógeno del aire en amoníaco. Entender su química podría ayudar a diseñar catalizadores industriales mejores y procesos de fabricación de fertilizantes más limpios.

En 2017 se estimó que calcular su energía fundamental exigiría alrededor de 50 billones de puertas Toffoli. Después de ocho años de mejoras algorítmicas y rediseños de circuitos, la estimación cayó hasta unos 340 millones: aproximadamente 150.000 veces menos. No apareció de repente un ordenador 150.000 veces mejor. Gran parte del progreso consistió en aprender a pedirle mucho menos trabajo a la máquina. Hay dos formas de hacer que un ordenador sea 150.000 veces mejor en una tarea: la primera que el ordenador sea 150.000 veces mejor y la segunda que la tarea sea 150.000 veces más sencilla


Aquí conviene explicar qué se está contando. Un circuito cuántico, igual que uno clásico, se construye aplicando operaciones elementales. La Puerta Toffoli es especialmente costosa en una arquitectura tolerante a fallos, así que su número se utiliza como una aproximación al trabajo lógico y, muchas veces, al tiempo de ejecución.

Pero contar operaciones no basta. También importa cuántos qubits necesita utilizar el circuito a la vez. Pensad en lo que ocurre con un programa normal: puede guardar resultados en memoria para no tener que calcularlos de nuevo. Ahorra trabajo, pero ocupa más espacio. En estos circuitos aparece una negociación parecida: guardar resultados intermedios consume qubits; no guardarlos puede obligar a repetir cálculos.


Por eso los investigadores valoran ambas cosas conjuntamente. Cada propuesta de Claude recibe una puntuación que combina las operaciones que necesita y los qubits que utiliza. Así pueden comparar diseños que ahorran por caminos distintos: unos reducen mucho el trabajo, otros necesitan menos memoria y algunos consiguen mejorar las dos cosas.

La idea es sencilla: hacer la misma tarea con menos recursos, sin que el ahorro en una parte dispare el gasto en la otra.

La maquinaria de búsqueda se parece más a un laboratorio automático que a una conversación normal con un chatbot. Cada tarea comienza con una especificación escrita por investigadores y un programa vacío. Claude propone varias familias de soluciones, escribe el código que construye cada circuito y recibe del evaluador los errores o la puntuación. Las propuestas válidas sobreviven y se modifican; las que dejan una ancilla sin limpiar, calculan mal una salida o incumplen la interfaz quedan descartadas.



El sistema utiliza OpenEvolve para mantener esa búsqueda evolutiva y Claude Mythos 5 para proponer arquitecturas y reescrituras. Entre iteraciones no hay una conversación infinita que lo recuerde todo: cada sesión recibe una parte limitada del archivo de diseños, sus costes, algunos intentos anteriores y el feedback del evaluador.

La extraña regla cuántica: aquí no se puede tirar la basura

Hasta aquí parece un problema de optimización de código bastante convencional. El detalle que lo vuelve realmente interesante es que un circuito cuántico no puede programarse igual que una aplicación normal.

La primera dificultad es el control de flujo. Un programa clásico mira una condición y decide: “si ocurre esto, ejecuta A; si no, ejecuta B”. Un circuito cuántico puede estar procesando una superposición de entradas en la que unas necesitarían A y otras B. No puede seleccionar tranquilamente una sola rama clásica: tiene que expresar ese comportamiento mediante operaciones controladas dentro de una secuencia fija de puertas. Y el coste de esas ramas termina dentro del circuito.

La segunda dificultad es todavía más extraña: no se puede borrar la información intermedia sin más.

Imaginad que resolvéis un problema en una pizarra. Hacéis unas cuentas auxiliares, utilizáis el resultado y después borráis la esquina donde estaban los garabatos. En un ordenador cuántico esa basura no puede desaparecer de manera irreversible. Si queda enganchada al estado, puede impedir que las amplitudes interfieran como deben. Y si intentáis borrarla de la manera clásica, destruís la reversibilidad del cálculo.

La salida habitual es el "uncomputation": una vez utilizado el resultado intermedio, se ejecutan en sentido inverso las operaciones que lo produjeron hasta devolver los qubits auxiliares a cero. Funciona, pero cuesta más puertas.


Y esto crea una negociación permanente. Guardar resultados intermedios ahorra repetir cálculos, pero consume qubits. Limpiarlos cuanto antes libera memoria, pero puede obligar a recomputarlos más tarde. Diseñar un buen circuito significa encontrar un punto inteligente en esa frontera.

El primer gran examen que pusieron a Claude fue la suma de puntos sobre curvas elípticas. Quienes hayáis leído el artículo sobre el algoritmo de Grover ya sabéis que un algoritmo cuántico no es una especie de magia universal: cada ventaja necesita un circuito muy concreto.  En este caso la suma de puntos es una pieza central de los algoritmos cuánticos para resolver el logaritmo discreto en curvas elípticas, el problema sobre el que descansa ECDSA y buena parte de la criptografía de curva elíptica.

El paso más caro de esa suma suele ser la inversión modular. En un ordenador clásico existe un método muy eficaz llamado divsteps, que va actualizando una pareja de números y decide en cada ronda si intercambia, suma, resta o divide entre dos.

El problema es que, para ejecutar el proceso al revés, un circuito cuántico tendría que recordar qué decisión tomó en cada una de sus muchas iteraciones. Guardar toda esa historia de ramas consume una cantidad enorme de qubits. Por eso un algoritmo clásico excelente podía ser una mala base para un circuito reversible.

Claude propuso una salida bastante elegante: tal vez la historia no tenía que guardarse porque podía reconstruirse mirando el estado actual de los números. Es decir, el propio resultado de cada paso podía actuar como memoria de la decisión que lo había producido.

Las primeras reglas que encontró funcionaban en ejemplos pequeños y fallaban al llegar a números de 256 bits. Entonces dejó de probar trucos locales y empezó a estudiar la estructura matemática de divsteps. Derivó identidades algebraicas, construyó una regla exacta para recuperar la rama, la comprobó con simulaciones a gran escala y formalizó la afirmación en Lean. El resultado fue la primera implementación reversible de divsteps sin almacenar toda la historia de ramas.

Todo ese recorrido nació de un encargo de un párrafo y una ejecución de 53 horas, con intervención humana limitada a la especificación inicial y a algunas indicaciones para que explorase alternativas más amplias.

Pero no existe un único circuito ganador. Decodificar la historia ahorra qubits y cuesta puertas; almacenarla cuesta memoria y puede ahorrar tiempo. Claude produjo una familia de soluciones que amplía la frontera entre ambos recursos.


La comparación que resume mejor la idea es ésta: frente al diseño anterior con menos qubits, una de las nuevas variantes utiliza aproximadamente un 12% más de qubits, pero necesita 17 veces menos puertas. En un hardware donde el tiempo sea la restricción dominante, ésa puede ser una negociación extraordinaria. En otro donde cada qubit sea carísimo, puede interesar una variante diferente.

Optimizar al propio optimizador cuántico

La segunda historia del trabajo parece un trabalenguas: Claude optimizó el decodificador que utiliza un algoritmo cuántico de optimización. El algoritmo se llama Decoded Quantum Interferometry o DQI. En vez de buscar una única respuesta de manera directa, prepara un estado cuántico en el que las soluciones mejores tienen más probabilidad de aparecer al medir. Para construir ese estado necesita un decodificador de códigos Reed–Solomon, y ese decodificador era la parte más cara del circuito.

Para ponerle una imagen al problema, Anthropic utiliza la intersección polinómica óptima donde cada columna admite ciertos valores y buscamos una curva sencilla que pase por tantos de ellos como sea posible. La figura original permite ver qué intenta optimizar DQI antes de entrar en la maquinaria del decodificador.


La implementación anterior estaba basada en el algoritmo de Euclides extendido. Es un método estupendo en un Quantum Computer, pero su secuencia de divisiones e intercambios depende de la entrada. Para un circuito cuántico con una única secuencia fija de puertas, esa variabilidad obliga a reservar rondas y operaciones que muchas entradas no necesitarán. Claude cambió la base del diseño por el algoritmo de Berlekamp–Massey, que realiza el mismo tipo de actualización en cada ronda y ejecuta un número fijo de rondas. Es una forma de cálculo mucho más compatible con el control de flujo cuántico.

Aun así quedaba la basura. Una traducción reversible ingenua debería conservar valores temporales de muchas rondas. Reservar memoria para el peor caso –35 valores excepcionales– exigiría 665 qubits. Claude volvió a utilizar la misma idea de fondo: reconstruir casi toda la historia a partir del estado actualizado y guardar únicamente lo que de verdad no puede recuperarse.

Para saber cuánto espacio necesitaba, escribió un simulador de alta velocidad y ejecutó 403 millones de decodificaciones. Casi todas necesitaron guardar como máximo un valor, por lo que el circuito reserva sólo 19 qubits. Aproximadamente una de cada 10.000 ejecuciones necesita más y falla, una probabilidad que entra dentro del presupuesto de error permitido por la tarea.


La mejora no salió de apretar un único tornillo. Llegó de rediseñar tres capas a la vez: elegir otro algoritmo, cambiar la forma de hacerlo reversible y dejar de dimensionar la memoria para un caso extremadamente raro que la propia tarea permitía tratar como fallo. En conjunto, el decodificador Reed–Solomon pasó de unos 5,1 millones de puertas Toffoli y 1.938 qubits a 440.000 Toffoli y 1.837 qubits: una mejora de unas 12 veces en el coste T Q. Y no fue un caso aislado.

Los ocho problemas cubrían decodificación para optimización, funciones numéricas utilizadas en simulación, química cuántica, teoría de números y simulación de teorías gauge. En la Función Gaussiana de punto fijo, la mejora del coste T Q llegó a 39 veces; en el ángulo de rotación de HHL fue de 32 veces; en el potencial de Coulomb, de 9,9; y en una rutina para simular un sistema no abeliano, de 7,7.


No todas estas cifras significan que una aplicación completa vaya a ejecutarse exactamente 39 veces más rápido. Son mejoras en primitivas concretas y bajo una función de coste concreta. Pero esas primitivas se llaman una y otra vez dentro de algoritmos mucho mayores, de modo que reducirlas puede cambiar de manera significativa la factura total.

Lo más importante no es que Claude escribiera el código

Hay una lectura superficial de este trabajo que sería: “Claude sabe programar circuitos cuánticos”. Es cierta, pero se queda corta. Lo realmente interesante es el tipo de entorno científico que han construido. El modelo puede proponer ideas arriesgadas porque cada resultado terminado pasa por un juez externo. Si calcula mal, si no devuelve los ancillas a cero o si utiliza demasiados recursos, el evaluador lo detecta. El sistema no confunde una explicación convincente con una demostración correcta. Ésta parece ser una de las combinaciones más fértiles para acelerar investigación con inteligencia artificial:

1. un problema que pueda representarse como código;
2. una comprobación externa y suficientemente barata de la corrección;
3. una función de coste objetiva;
4. y libertad para explorar familias de soluciones que no sean simples retoques locales.

Claude no se limitó a rebajar contadores. En los dos ejemplos principales cambió la manera de representar la información que un circuito reversible necesita conservar. La idea recurrente fue especialmente física: no guardes toda la historia si el estado presente ya contiene huellas suficientes para reconstruirla.

También conviene mantener los pies en el suelo. Los circuitos no se ejecutaron en un ordenador cuántico real. El evaluador funciona de forma eficiente porque las tareas estudiadas pertenecen a una clase concreta: circuitos que implementan funciones clásicas de forma coherente y que pueden comprobarse siguiendo estados de la base computacional. No cualquier circuito cuántico arbitrario admite una verificación clásica tan barata.



El coste T Q tampoco representa por igual todas las máquinas. En algunas arquitecturas dominará el número de puertas; en otras, la profundidad, el enrutamiento o el número de qubits activos. El propio paper subraya que la función de puntuación puede cambiarse para reflejar restricciones de hardware diferentes.

Y tampoco hubo una ausencia absoluta de humanos. Las especificaciones, las interfaces y los criterios de corrección fueron escritos por investigadores. En el experimento de curvas elípticas hubo indicaciones ocasionales para que Claude ampliara la búsqueda, porque el modelo tendía a ser conservador y a volver a enfoques conocidos. Esa cautela también tuvo una cara útil: lo llevó a comprobar repetidamente el resultado y a formalizar una parte en Lean.

Pero el salto sigue siendo difícil de ignorar. La reducción acumulada de FeMoco necesitó ocho años y muchos equipos. La nueva familia de circuitos para curvas elípticas apareció en una ejecución de 53 horas. No son comparaciones idénticas, pero sí señalan una diferencia enorme en la velocidad con la que puede explorarse un espacio de diseños cuando una IA propone y una máquina verifica.


Y aquí aparece la posibilidad más ambiciosa del trabajo. Un Quantum Computer tolerante a fallos no es sólo un circuito. También necesita códigos de corrección de errores, decodificadores, compilación, enrutamiento y decisiones de hardware. Hoy solemos diseñar cada capa por separado porque hacerlo todo a la vez es demasiado complejo. Pero muchas de esas capas comparten las mismas propiedades: pueden escribirse como código, comprobarse y puntuarse. ¿Y si una IA pudiera diseñarlas conjuntamente para una aplicación concreta?

Tal vez los primeros ordenadores cuánticos útiles no lleguen únicamente porque aprendamos a fabricar millones de qubits mejores. Puede que lleguen también porque sistemas como éste descubran que, para resolver el problema que nos interesa, no necesitábamos tantos qubits ni tantas puertas como creíamos.

La última vez que Claude Mythos apareció en este blog estaba buscando una grieta en la criptografía postcuántica. Esta vez ha estado diseñando parte de la maquinaria que algún día podría ejecutar los algoritmos cuánticos contra la criptografía clásica. Visto así, la Inteligencia Artificial no sólo está acelerando la ciencia. También está empezando a diseñar las herramientas con las que haremos la siguiente.

Saludos,

Otros artículos sobre Quantum Computing publicados:

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares