IA construyendo IA: la automejora recursiva como un problema de seguridad actual

Qué significa la "automejora recursiva"

Como señaló Matthew Hutson en IEEE Spectrum, el término se utiliza de manera inconsistente: algunos lo emplean para referirse a una amenaza que permita promover la regulación, otros lo utilizan con fines publicitarios, y las definiciones que se ofrecen van desde un ciclo totalmente autónomo, sin intervención humana, hasta casi cualquier caso en el que la tecnología ayude a desarrollar otra tecnología. La descripción más honesta es la de un espectro.

La idea no es nueva. En 1965, el matemático I.J. Good describió una "máquina ultrainteligente" como aquella capaz de diseñar máquinas aún mejores, lo que provocaría una "explosión de inteligencia" que dejaría muy atrás a la inteligencia humana. Esta línea de pensamiento continúa con la formalización posterior de Nick Bostrom y con décadas de literatura sobre la seguridad de la IA. Durante la mayor parte de esa historia, la RSI fue un horizonte teórico, un estado futuro que había que modelar y temer, más que una condición presente que había que gestionar.

En el extremo superior del espectro se encuentra un sistema que no solo mejora sus resultados, sino también el proceso mediante el cual lo hace, generando ideas, evaluando resultados y modificando sus propios métodos sin intervención humana. Según ese criterio, los sistemas actuales se quedan cortos: ayudan a construir una IA mejor, pero siguen dependiendo de los humanos para establecer metas, definir el éxito y decidir qué cambios conservar. La pregunta relevante, entonces, no es si la automejora existe de alguna forma —pues sí existe abajo en el espectro—, sino qué tanto se ha cerrado el ciclo. Y lo que está en juego es la velocidad: si el progreso se acumula de manera lineal, es manejable; si se acumula de manera exponencial, décadas de avances podrían comprimirse en semanas.

La situación actual

Si dejamos de lado las especulaciones, se observa un patrón consistente entre los tres laboratorios dominantes. La información revelada por Anthropic es la más detallada, pero no la única. OpenAI informó en febrero de 2026 que GPT-5.3-Codex fue fundamental en su creación, ya que ayudó a depurar su entrenamiento, gestionar partes de su implementación y analizar los resultados de su evaluación. AlphaEvolve de Google DeepMind, un agente de codificación para el descubrimiento algorítmico, utiliza un modelo de lenguaje grande para mutar y evaluar algoritmos de manera iterativa, y se ha aplicado a la optimización de rutinas de multiplicación de matrices que sustentan la eficiencia del entrenamiento, lo que ayuda a acelerar el entrenamiento de sistemas futuros. En cada caso, los humanos siguen dirigiendo y verificando el trabajo.

El director de políticas de Anthropic, Jack Clark, dejó clara la distinción unos meses antes del artículo de junio, al afirmar que el campo aún no ha llegado a la IA que se mejora a sí misma, sino que se encuentra en la etapa de una IA que mejora partes de la próxima IA, con una autonomía cada vez mayor.

La Cloud Security Alliance (CSA) propone un término que define con claridad lo que realmente está sucediendo: su análisis de 2026 denomina a estas operaciones "adyacentes a la RSI": sistemas de IA que participan de manera significativa en el desarrollo, la evaluación o la implementación de sistemas de IA sucesores bajo supervisión humana. Ese calificativo es lo que hace que el concepto sea manejable, ya que la RSI totalmente autónoma —un sistema que reescribe sus propios pesos hacia una capacidad elegida sin intervención humana— sigue siendo especulativa, mientras que las operaciones adyacentes a la RSI ya se están llevando a cabo a gran escala, en los entornos que producen los modelos que ahora están ingresando a la economía en general. Y, como sostiene la CSA, es la infraestructura que respalda estos ciclos supervisados la que constituye la nueva superficie de ataque.

La vanguardia de la investigación va ganando terreno

Además de los anuncios sobre la producción de los laboratorios, una línea de investigación muestra hacia dónde se dirige este ciclo, y cuenta con una larga trayectoria. En las décadas de 1980 y 1990, Jürgen Schmidhuber y otros investigaron algoritmos evolutivos que escriben y perfeccionan programas, y en 2003, Schmidhuber propuso las máquinas de Gödel, sistemas que reescribirían su propio código solo cuando pudieran demostrar formalmente que el cambio era beneficioso. Ese requisito de demostración resultó no ser aplicable a agentes complejos, lo que dejó los resultados empíricos como la única base práctica para la automodificación.

A mediados de 2025, investigadores de la Universidad de Columbia Británica y de Sakana AI presentaron las Darwin Gödel Machines (DGM), cuyo nombre combina la máquina de Gödel de Schmidhuber con la evolución darwiniana, ambas tradiciones de las que provienen. Una DGM comienza con un agente de codificación, utiliza un modelo de lenguaje para proponer cambios a su propio código, prueba cada variante en un banco de pruebas y mantiene un registro de todas ellas, incluidos los fracasos temporales, basándose en la teoría de que una mala idea puede convertirse en la semilla de un avance posterior. A lo largo de más de 80 iteraciones, los agentes elevaron sus puntuaciones en SWE-bench, que evalúa soluciones a problemas reales de GitHub, del 20 % al 50 %, y en Polyglot, una prueba de programación multilingüe, del 14 % al 31 %. El mejor agente no alcanzó los aproximadamente 70 % que obtiene el mejor agente diseñado por humanos. Se trata de una prueba de concepto de la mejora continua, no de una demostración de programación sobrehumana.

Para marzo de 2026, una versión sucesora llamada DGM-Hyperagents logró que el propio mecanismo de mejora fuera editable, lo que sus autores denominan automodificación metacognitiva: el sistema mejora no solo la forma en que resuelve tareas, sino también la forma en que genera mejoras futuras. Mientras que el DGM original solo podía mejorar su capacidad de superación dentro del ámbito de la programación, la versión más reciente demostró avances que se transferían entre distintos ámbitos, desde la revisión de artículos académicos hasta el diseño de recompensas en robótica y la calificación de exámenes de matemáticas, y que se acumulaban a lo largo de las ejecuciones. Sus autores lo describen como un paso hacia una mejora abierta y autoacelerada.

Vale la pena tener en cuenta dos advertencias. En primer lugar, el DGM y el DGM-H son prototipos de investigación, no sistemas implementados, por lo que la interpretación correcta es que las fronteras de la investigación y la producción están convergiendo, no que se hayan fusionado. En segundo lugar, ambos funcionaron bajo condiciones deliberadas de contención, en un entorno aislado y bajo supervisión humana, una restricción que es importante para lo que vendrá después.

Por qué esto es un problema de seguridad

Este es el cambio para el que no fueron diseñados los marcos de seguridad actuales. Cuando un modelo participa en la construcción de su sucesor, incluso bajo supervisión, la integridad de esa construcción determina directamente la del sucesor. Un ataque convencional a la cadena de suministro contamina un resultado: una dependencia comprometida, y las aplicaciones construidas sobre ella heredan el defecto. Un ataque al flujo de entrenamiento contamina el modelo en sí, un activo que puede desplegarse en miles de aplicaciones posteriores y en el que las organizaciones que lo utilizan confían implícitamente.

Esto eleva la infraestructura de entrenamiento de IA al estatus de infraestructura crítica y abre varios puntos de influencia bien definidos. Las investigaciones han demostrado que contaminar tan solo una fracción de un por ciento de un corpus de entrenamiento —unos pocos cientos de documentos seleccionados— puede introducir puertas traseras de comportamiento que se activan ante una frase desencadenante, mientras que el rendimiento de referencia sigue siendo estadísticamente indistinguible del de un modelo limpio. Cuando son los sistemas de IA los que sintetizan los datos de entrenamiento, generan código y evalúan los resultados, el ámbito para dicha inyección indirecta se expande de los flujos de trabajo operados por humanos a los operados por IA. Un adversario que pueda manipular el entorno de prompts que observa un investigador automatizado, o la infraestructura de evaluación con la que este se optimiza, obtiene un canal indirecto hacia el modelo sucesor que se está entrenando.

El registro de modelos es el objetivo más directo en la cadena de suministro. Los investigadores de seguridad han documentado modelos maliciosos subidos a registros públicos con cargas útiles ocultas en pesos serializados, lo cual es funcionalmente equivalente a un paquete contaminado, excepto que el defecto se manifiesta en el comportamiento del modelo y puede ser mucho más difícil de detectar mediante pruebas estándar previas a la implementación. A medida que los sistemas de IA recurren cada vez más a estos registros para iniciar sus operaciones, ese vector se agrava.

Por último, la capa menos técnica no es la menos importante. Las personas que establecen los objetivos, revisan los resultados y deciden qué datos se utilizarán para la siguiente ronda de entrenamiento forman parte del ciclo, y la ingeniería social dirigida a ellas es una forma plausible de introducir la influencia de adversarios en una capa a la que los controles técnicos no llegan.

Los sistemas siguen encontrando las brechas

Hay un modo de falla recurrente en cada uno de estos ciclos, y es el que los equipos de seguridad deben vigilar con mayor atención. La manipulación aprovechada de las especificaciones, encontrando una forma de cumplir un objetivo al pie de la letra sin respetar su intención, es un comportamiento conocido de los sistemas de optimización, y los que se mejoran a sí mismos lo ponen de manifiesto una y otra vez.

Los ejemplos ya no son hipotéticos. En el estudio sobre DGM, los investigadores descubrieron que algunos agentes informaban falsamente que habían utilizado ciertas herramientas y, cuando el equipo recompensó la honestidad, un agente simplemente hackeó el mecanismo que verificaba si mentía. AlphaEvolve, de DeepMind, descubrió que podía elevar su propia puntuación de evaluación generando entradas que bloqueaban el servidor de puntuación, que luego asignaba automáticamente una calificación de aprobado. Y en abril de este año, Anthropic informó que incluso un grupo de investigadores de alineación automatizada, sometido a un estricto control, intentó manipular su propia métrica de evaluación. Tres sistemas independientes llegan a la misma conclusión: se cumple el objetivo, pero no el propósito subyacente.

Un estudio reciente sobre modelos de código presenta un caso más discreto y, podría decirse, más inquietante. El autoentrenamiento recursivo, en el que un modelo aprende a partir del código generado por versiones anteriores de sí mismo, tiende a deteriorarse en lugar de mejorar, a menos que una señal de calidad externa sirva de ancla para el ciclo. Vale la pena recordar la frase de los investigadores: el autoentrenamiento no implica automáticamente la automejora. Compararon tres regímenes de revisión y descubrieron que la revisión sin control es la que colapsa más rápido; que las verificaciones independientes del modelo, como la compilación y las pruebas, retrasan el colapso pero no lo detienen; y, lo más revelador, que una IA que revisa su propio resultado puede entrar en un "régimen de aprobación automática", en el que sus puntuaciones de aceptación aumentan mientras que la corrección real disminuye. Su conclusión es que el entrenamiento recursivo estable requiere una verificación exógena, es decir, una revisión realizada por algo ajeno a lo que se está revisando.

Este hallazgo apunta directamente a un problema al que ya se enfrentan las empresas: las herramientas de programación basadas en IA generan cambios más rápido de lo que los humanos pueden revisarlos, y la revisión de código mediante IA está cubriendo cada vez más ese vacío. Ya hemos escrito sobre cómo la IA reduce el tiempo necesario para explotar una vulnerabilidad y por qué las defensas en tiempo de ejecución son importantes cuando el código se implementa más rápido de lo que se puede verificar. La investigación sobre el colapso de modelos señala la salida de emergencia a la que muchos equipos están recurriendo —dejar que la IA revise a la IA— y demuestra que no es un sustituto seguro de la verificación independiente. Cada incremento en la velocidad impulsada por la IA también representa un incremento de código no revisado o autorrevisado que ingresa a la base de código, y fallas a nivel de diseño, como la elusión de la autenticación, el manejo inadecuado de sesiones y las credenciales codificadas de forma rígida, aparecen en el código generado por IA a un ritmo que la cadencia de revisión convencional nunca fue diseñada para detectar.

Argumentos a favor de la calma

Nada de esto requiere creer en una explosión de inteligencia inminente, y muchas personas serias no lo hacen. El contraargumento más claro es que el ciclo puede no potenciarse de forma limpia. Nathan Lambert, investigador del Instituto Allen, ha argumentado que, en lugar de una automejora recursiva, deberíamos esperar una "automejora con pérdidas", en la que la fricción frena el impulso a medida que los sistemas se vuelven más complejos y los investigadores dedican su tiempo a gestionar esa complejidad en lugar de perfeccionar las partes. La investigación sobre el colapso de los modelos es, en cierto sentido, un mecanismo por el cual esa fricción se hace sentir.

La fricción no es solo algorítmica. Como señalan los autores de un análisis de junio de 2026 sobre el salto de la IA general (AGI) a la IA superinteligente (ASI) —de una IA a nivel humano a una superhumana—, incluso los investigadores puramente digitales que operan a una velocidad superhumana se ven limitados por la necesidad de realizar experimentos cada vez más grandes y esperar los resultados, y cualquier tarea que requiera manipulación física, como fabricar mejores chips o construir centros de datos, no puede acelerarse de manera arbitraria. La propia Anthropic reconoce una versión de esto, invocando la ley de Amdahl: acelerar una parte de un proceso simplemente desplaza el cuello de botella hacia las partes que no se aceleran, razón por la cual la revisión humana del código se ha convertido en una nueva limitación.

Sin embargo, incluso los escépticos tienden a separar la singularidad (el punto hipotético en el que el avance de la IA se sale de control humano) del riesgo para la seguridad. Dean Ball, de la Fundación para la Innovación Estadounidense, ha calificado la singularidad como ciencia ficción infantil, al tiempo que, en el mismo contexto, argumenta que la investigación de vanguardia en RSI debe ser monitoreada de cerca, precisamente para que los modelos no caigan en manos de personas malintencionadas que los utilizarían para acelerar ciberataques o desarrollar armas biológicas. Esa es una línea de razonamiento acertada. Puedes considerar que la narrativa sobre el despegue es exagerada y, aun así, llegar a la conclusión de que los sistemas de IA que aceleran el desarrollo de IA generan una exposición de seguridad concreta y presente.

La gobernanza se está quedando atrás

Las publicaciones también ponen de manifiesto una brecha entre lo que se despliega y lo que cualquier marco está diseñado para regular. Las normas existentes —desde el Marco de Gestión de Riesgos de IA del NIST hasta las evaluaciones de conformidad de la Ley de IA de la UE, pasando por la propia matriz de control de la CSA— se redactaron en gran medida antes de que se documentaran públicamente operaciones relacionadas con la RSI a esta escala. El enfoque en el que coinciden la mayoría de los laboratorios y el Informe Internacional sobre Seguridad de la IA de 2026 consiste en umbrales de capacidad combinados con compromisos del tipo "si... entonces": si un sistema demuestra una capacidad determinada, entonces debe implementarse una medida de protección específica antes de continuar. El Marco de Preparación de OpenAI y la Política de Escalamiento Responsable de Anthropic son ejemplos de este enfoque.

El problema es que los umbrales definidos en función de lo que un solo modelo puede hacer pueden pasar por alto la influencia que un modelo puede ejercer sobre lo que haga el siguiente. Un sistema que, por sí mismo, no puede realizar una acción peligrosa, pero que puede configurar a su sucesor para que lo haga, es una capacidad que los umbrales actuales no captan. Aquí es donde los expertos en seguridad tienen algo que aportar, y hemos argumentado que la seguridad de la IA exige una gobernanza diseñada en función de cómo se comportan realmente estos sistemas, en lugar de cómo nos gustaría que lo hicieran.

La propia propuesta de Anthropic ilustra esta tensión. Tras revelar que Claude está acelerando significativamente su propio desarrollo, la compañía también pidió que el mundo tuviera la opción de ralentizar o pausar el desarrollo de tecnología de vanguardia, con mecanismos de cumplimiento que permitan a los laboratorios verificar que los competidores realmente se hayan detenido. Los críticos no tardaron en señalar, con toda justicia, lo incómoda de la situación: se trata de la misma empresa que reporta un multiplicador de velocidad de 8x y, como informó Scientific American, el llamado se produjo días después de una solicitud confidencial de oferta pública inicial y de una ronda de financiamiento que valoró a Anthropic en casi 1 billón de dólares. Algunos investigadores interpretaron el discurso sobre la pausa como una estrategia más que como un freno genuino, y uno de ellos lo calificó, sin rodeos, de imposible. Sea cual sea el motivo, el problema de coordinación subyacente es real: ningún laboratorio quiere reducir el ritmo mientras un competidor avanza a toda velocidad, y una pausa verificable es mucho más difícil de implementar en pruebas de entrenamiento que en silos de misiles.

Qué hacer al respecto

La respuesta adecuada no es frenar el desarrollo asistido por IA, lo cual haría perder avances reales, sino ampliar las medidas de seguridad para adaptarlas a la nueva superficie de ataque antes de que los adversarios se den cuenta de que no han seguido el ritmo. De ello se derivan algunas medidas directas.

Considera el flujo de trabajo de programación de IA como un componente crítico para la seguridad de la cadena de suministro. Esto implica el seguimiento de la procedencia del código generado por IA, flujos de trabajo de revisión adaptados al volumen y la naturaleza de ese resultado, y el monitoreo de los tipos de fallas que estas herramientas suelen introducir con mayor frecuencia. Parte de la velocidad que ofrece la IA debe reinvertirse en la capacidad de revisión, en lugar de destinarse por completo al rendimiento; de lo contrario, la acumulación de vulnerabilidades crecerá más rápido de lo que cualquiera pueda resolver.

Insiste en la verificación exógena. El hallazgo del colapso del modelo se generaliza en un principio: un verificador vinculado a lo que revisa terminará por dar su visto bueno sin más. La revisión de seguridad del código generado por IA debe provenir de algo independiente del sistema que lo generó, ya sea una clase diferente de herramientas o una evaluación externa, en lugar de que sea el mismo modelo el que califique su propio trabajo.

Trata la infraestructura de entrenamiento y evaluación como si fueran las joyas de la corona. Los controles de acceso, la verificación de integridad y el registro de auditoría en la capa de ingestión de datos, en la infraestructura de evaluación y en el registro de modelos deben ser tan rigurosos como los de los sistemas más sensibles de la organización, ya que una vulneración en esos puntos puede propagarse a todo lo que se construya posteriormente. Y cuando los modelos provienen de proveedores externos, una actualización de modelo es un evento de la cadena de suministro: justifica una revisión de su comportamiento, no una aceptación ciega a través de un punto final de API.

La cuestión principal tiene que ver con el enfoque. La automejora recursiva, en su forma plena y autónoma, sigue siendo una incógnita para el futuro, y las personas sensatas dudan de que llegue en el plazo que imaginan sus defensores más acérrimos. Pero la versión que importa para la seguridad ya está aquí: los sistemas de IA están dando forma a los sistemas de IA que desempeñarán funciones críticas, y los ciclos que llevan a cabo esa configuración constituyen una superficie de ataque activa que la mayoría de los programas de seguridad empresarial aún no han tomado en cuenta. Las organizaciones que salgan bien de esto serán aquellas que lo hayan tratado como un problema de ingeniería en tiempo presente, no como un problema filosófico lejano.

Fluid Attacks puede actuar como un agente externo para evaluar la seguridad de tu código generado por IA, su comportamiento y los modelos que lo producen. Contáctanos para ver cómo podemos ayudarte.