Una IA puede corregir una respuesta sin cambiar cómo trabajará mañana. ¿Qué tendría que conservar para mejorar también el proceso que produce sus futuras mejoras? El preprint The Last AI Built by Humans: Toward Genuine Recursive Self-Improvement propone una clasificación para examinar esa diferencia. Su título no demuestra que hayamos construido la última IA diseñada por humanos.
1. La pregunta: ¿qué queda cuando termina la tarea?
Imagina un taller donde un ayudante arregla un reloj. Puede entregar el reloj reparado y empezar el siguiente desde cero. Puede también guardar una técnica útil. O puede aprender a elegir mejores pruebas para encontrar antes el próximo fallo.
Las tres situaciones producen algo distinto: una pieza reparada, una receta reutilizable o una mejora del método de reparación. Cuando hablamos de IA que se mejora a sí misma, necesitamos saber cuál ocurrió. Una colección de respuestas mejores no identifica por sí sola un sistema que aprendió a producir mejoras.
Yi Duan y sus coautores organizan esa pregunta en una revisión sobre mejora recursiva, abreviada RSI por su nombre en inglés. Examinan el bucle de mejora: origen del problema, propuesta del cambio, aceptación y versión que vuelve al trabajo siguiente.
Fuentes de este apartado
Fuente: secciones 1.7 y 2.2.
2. La dificultad: un buen parche puede enseñar una mala lección
Un cambio aceptado puede ayudar en una tarea y estropear otra. Si además se guarda para futuras tareas, el error se hereda. Por eso no basta con preguntar si el agente cambió algo o si subió su puntuación en una prueba.
El evaluador es parte del problema. Una búsqueda que consulta repetidamente la misma prueba puede adaptarse a sus defectos. El resultado aparente mejora aunque la capacidad que queríamos medir no lo haga. Si el agente modifica también la forma de puntuar, las notas de dos generaciones pueden dejar de ser comparables.
Hay un tercer obstáculo: más intentos, un modelo base mejor o más presupuesto pueden explicar parte de la ganancia. Atribuirla al nuevo procedimiento exige comparaciones que controlen esos factores. La revisión distingue autonomía, calidad de las mejoras y eficiencia; no las trata como sinónimos.
Fuentes de este apartado
Fuente: secciones 1.3, 3.3.4 y 3.7.
3. El punto de partida: alguien fija cómo aprender
La mejora automática tiene antecedentes en programas que se modifican, aprendizaje continuo, búsqueda de arquitecturas y sistemas de agentes. No nació con esta revisión. Lo habitual en muchos de esos enfoques es que personas o infraestructura fija definan objetivos, presupuesto y reglas de selección.
Un agente puede probar varias respuestas y corregirlas dentro de una conversación. Los autores usan B0 como referencia para ese caso cuando no queda un cambio persistente del sistema para tareas independientes. B0 delimita la corrección del resultado actual; no se cuenta como RSI en su clasificación.
La frontera cambia cuando algo útil vuelve al propio sistema. Puede ser un parámetro, una memoria, una herramienta o el código que organiza sus acciones. Mejorar un producto externo no implica automáticamente mejorar al agente que lo produjo.
Fuentes de este apartado
Fuente: secciones 2.2.3 y 3.1.
4. El giro: clasificar por decisiones, no por tamaño
La propuesta de la revisión es preguntar qué responsabilidades del proceso pasan al sistema. Dos agentes pueden modificar el mismo tipo de archivo y tener grados de autonomía distintos. Uno ejecuta una receta fijada; otro interpreta fallos y decide qué intervención conviene intentar.
Los autores organizan el bucle en cinco niveles, L1 a L5. Los niveles describen responsabilidades, no una escala universal de inteligencia. Estar más arriba no garantiza mejores resultados, menos coste o seguridad.
| Nivel | Responsabilidad que examina la revisión |
|---|---|
| L1: ejecución | Ejecutar un procedimiento de mejora definido externamente y conservar resultados para después. |
| L2: estrategia | Diagnosticar y elegir qué intervención probar, con objetivo y criterios de aceptación externos. |
| L3: experiencia | Elegir qué practicar o qué datos buscar después según el estado del aprendiz. |
| L4: adaptación | Convertir resultados del uso en cambios persistentes que influyen en tareas posteriores. |
| L5: meta-mejora | Revisar un mecanismo que gobierna futuras mejoras y reutilizarlo en rondas siguientes. |
La clasificación se aplica al bucle concreto y a la evidencia disponible. No exige que una sola red realice todas las funciones ni que desaparezca la supervisión humana.
Fuentes de este apartado
Fuente: secciones 1.4 y 3.2–3.7.
5. La idea central: el procedimiento también puede heredarse
En el taller, conservar una receta de reparación ayudaría a repetirla. Mejorar cómo se eligen las próximas pruebas cambiaría qué recetas se descubren. El segundo caso convierte el método de aprendizaje en parte del material que puede revisarse.
La revisión identifica varios componentes. El estado del sistema reúne lo que permanece entre rondas. El mejorador propone candidatos. El verificador los examina según una regla de aceptación. El sucesor es la versión que hereda los cambios aceptados y los usa después.
Tres preguntas permiten seguir ese circuito:
- ¿El cambio vuelve al sistema o solo modifica un producto externo?
- ¿Qué artefacto persiste y se utiliza en otra ronda?
- ¿Qué decisiones siguen bajo control externo?
El último nivel añade la revisión persistente del mecanismo que genera, evalúa o selecciona mejoras. Una modificación de ese mecanismo debe influir en una ronda posterior; editar su archivo sin utilizarlo no demuestra el circuito.
Fuentes de este apartado
Fuente: secciones 2.2.1, 2.2.2 y 3.6.
6. La comprobación: estructura y eficacia son preguntas distintas
Los autores distinguen recursión estructural de recursión efectiva. La primera muestra que un mecanismo revisado se conserva y gobierna una ronda posterior. La segunda necesita demostrar que produce o selecciona mejores sucesores, con recursos comparables y evaluación independiente.
Así, un registro de versiones puede demostrar que cambió el buscador. Todavía falta comprobar si ese cambio mejora la búsqueda. Hacen falta tareas nuevas, mediciones de regresión y presupuesto que incluya también el coste de evaluar al mejorador.
La revisión utiliza además el índice HCI para comparar cuánto del margen de una prueba se ha cerrado desde su frontera inicial. La relación es HCI = 100 × (puntuación − frontera inicial) / (100 − frontera inicial). En ese índice, cero corresponde a la frontera del año de entrada y cien a una puntuación perfecta.
Es una normalización de resultados de benchmarks, no un porcentaje de inteligencia ni una medida directa de autonomía. Sus comparaciones dependen de protocolos y familias de evaluación compatibles. La extensión gráfica posterior a 2026 es ilustrativa: no es un resultado observado ni una predicción validada del efecto de RSI.
Fuentes de este apartado
Fuente: secciones 2.1, 3.6.5 y 1.7.
7. Lo inesperado: más autonomía no elimina el árbitro
Poder elegir qué practicar no demuestra que la práctica sea útil. Una dificultad estimada puede reflejar ambigüedad y una respuesta consistente puede seguir siendo incorrecta. Los autores separan validez de una experiencia, dificultad para el aprendiz y beneficio de aprender de ella.
Algo parecido sucede con la memoria. Una habilidad guardada puede no recuperarse, aplicarse fuera de su ámbito o dejar de funcionar con otro ejecutor. El problema no termina cuando se escribe el archivo: hay que observar cuándo se activa y qué cambia en las tareas siguientes.
En L5, incluso el evaluador puede ser un objeto de mejora. Eso aumenta la necesidad de una referencia protegida. La revisión describe mecanismos que mantienen evaluadores fijos durante un periodo y contrastan sus reemplazos con una referencia independiente.
La autonomía de un bucle sigue delimitada por objetivos, permisos y condiciones de aceptación externos. Los autores no presentan L5 como autorización para cambiar sin límites la misión del sistema o desplegar cualquier candidato.
Fuentes de este apartado
Fuente: secciones 3.4.4, 3.5.4, 3.6.2 y 6.
8. Aplicaciones: cada mundo ofrece una evidencia diferente
En software, se pueden ejecutar pruebas, conservar versiones y deshacer cambios. Eso facilita examinar mejoras, aunque una suite incompleta no capture toda la intención del usuario, la seguridad o la mantenibilidad.
En ciencia, un fallo puede proceder de una hipótesis, un protocolo o un instrumento. En robótica, probar consume recursos y puede tener efectos físicos. En salud, los resultados llegan tarde y dependen de población e institución. Revertir código no deshace una consecuencia clínica o física.
La revisión incluye prácticas industriales y resultados preliminares, además de literatura académica. Esas fuentes ayudan a describir mecanismos, pero no equivalen todas a experimentos replicados de forma independiente.
Un ejemplo son los estudios de entorno de Theseus. La revisión describe una comparación de cinco combinaciones fijas de modelo y harness, con treinta tareas y 547 rúbricas. El entorno reconstruido elevó las puntuaciones agregadas entre 18,65 y 39,67 puntos porcentuales, según la configuración. También hubo tareas con regresiones por cambios más extensos de lo necesario.
Ese resultado se refiere a calidad del entorno de trabajo. No demuestra que ya se completara un ciclo sostenido de mejora de entornos, datos y modelos. Los autores lo presentan como evidencia inicial de una etapa de su propuesta.
[Inferencia] Para evaluar una promesa de auto-mejora, convendría pedir el artefacto cambiado, la evidencia que lo aceptó y una prueba de su uso posterior. Esta orientación deriva del marco de la revisión; no es una nueva garantía de seguridad.
Fuentes de este apartado
Fuente: secciones 2.3, 4, 5.1 y 6.
9. La lección: conservar un cambio no basta
La pregunta útil ante una nueva generación de IA es qué aprendió sobre mejorar y cómo se sabe que lo aprendió. La revisión ayuda a separar una respuesta corregida, una capacidad persistente y un procedimiento que produce mejores capacidades futuras.
La aceleración fiable entre generaciones continúa como una cuestión abierta en la evidencia que revisan los autores. El valor del marco está en exigir una cadena comprobable: cambio, validación, herencia y efecto posterior. Ninguno de esos pasos convierte el título del preprint en un hecho demostrado.
Fuentes de este apartado
Fuente: secciones 3.6.5 y 7.
Fuente y límites de esta lectura
- Se consultaron HTML y ficha de arXiv:2609.11873v3, revisada el 22 de septiembre de 2026.
- Es una revisión con marco conceptual, casos industriales y resultados preliminares heterogéneos. No se reprodujeron benchmarks o sistemas descritos ni se auditó por separado cada fuente citada.
- HCI mide margen cerrado en protocolos de benchmark; no mide inteligencia general. Las curvas futuras de la fuente son ilustrativas.
- B0 y L1–L5 son categorías del marco. No predicen una escalada inevitable ni autonomía sin controles.
- Este texto es un comentario divulgativo original, no una traducción del manuscrito. La viñeta es nueva y no reproduce sus figuras.
Referencia: Duan, Y. y colaboradores (2026). The Last AI Built by Humans: Toward Genuine Recursive Self-Improvement. Preprint, arXiv:2609.11873v3. HTML de la versión leída · Ficha bibliográfica.