La IA agéntica no suele hacer copias de seguridad antes de actuar

Gran parte del material que reviso a diario en Arxiv y otras fuentes es bastante árido, incluso para el gusto de un friki; por eso siempre busco publicaciones que me conmuevan, ya sea como usuario, defensor o víctima de la IA.

Hoy, ese momento de indignación me lo ha provocado una nueva colaboración académica estadounidense que examina hasta qué punto los modelos de IA agéntica de frontera queman las naves antes de emprender acciones perjudiciales, y lo hacen más rápido de lo que se tarda en escribir «¡PARA!» (pista: tenlo a mano en el portapapeles).

Esto, sacado de contexto del nuevo artículo, me ha pasado últimamente por seguir ciegamente las instrucciones de ChatGPT, y porque ni se me ocurrió duplicar primero todo el entorno virtual:

Interpretado a partir del nuevo artículo: un momento desolador que muchos hemos vivido al instalar frameworks de última generación, o incluso distribuciones populares que no respetan los entornos no estándar en los que pueden acabar instaladas. Fuente

En este ejemplo aterrador y demasiado familiar, el robot tiene una excusa razonable, porque no es habitual analizar todas las posibles consecuencias de instalar una biblioteca nueva en un framework frágil e implacable. Sin embargo, el nuevo artículo sostiene que quizá sí debería hacerse; y, como alguien que todavía pulsa CTRL+S con frecuencia, incluso en entornos con guardado automático configurados para ignorar esa combinación de teclas (gracias al trauma por la pérdida de datos propio de los años noventa), no puedo sino estar de acuerdo.

Sin duda, Alexey Grigorev, fundador de la plataforma educativa DataTalks.Club, habría agradecido una actitud más prudente y cautelosa: el agente Claude Code eliminó la infraestructura de producción y las copias de seguridad durante una migración de servidor el pasado marzo, lo que provocó la pérdida de dos años y medio de datos del sitio web.

Otros incidentes recientes de imprudencia agéntica de este tipo incluyen el de un agente de Cursor que eliminó en abril la base de datos de producción y las copias de seguridad de PocketOS, proveedor de software para el alquiler de vehículos, lo que interrumpió las reservas de los clientes durante más de dos días; y el de un agente de correo electrónico de OpenClaw que eliminó mensajes de la bandeja de entrada de un investigador de Meta AI en febrero, pese a recibir repetidas instrucciones de detenerse.

Sean agénticos o no, a los modelos de lenguaje de frontera les resulta muy difícil actuar con prudencia y cautela, hasta el punto de que la búsqueda de soluciones al problema se ha convertido en una línea de investigación diferenciada dentro de la bibliografía.

Hacer copias de seguridad con antelación

Pues bien, los autores del nuevo artículo* han desarrollado un complemento multiagente para entornos de ejecución agénticos, capaz de funcionar junto con la IA invitada y obligarla a crear copias de seguridad cuando sea necesario:

Descripción general del problema de las copias de seguridad que aborda el estudio y de la solución propuesta. En 205 escenarios, seis modelos de IA de frontera hicieron copias de seguridad del estado crítico en apenas el 15,2 % de las tareas. En cambio, el sistema BackUpper de los investigadores cubrió todas las acciones críticas; los datos restaurados alcanzaron, en promedio, una similitud del 92,2 % con los originales (más adelante se explica por qué es difícil llegar al 100 %).

Uno de los aspectos más llamativos del nuevo estudio es hasta qué punto los modelos de frontera no hacen copias de seguridad antes de emprender acciones potencialmente peligrosas. Los investigadores descubrieron que GPT-5.6-Terra hacía copias de seguridad de los datos críticos en solo el 4,4 % de los casos; GPT-5.6-Sol, en apenas el 5,9 % de los casos analizados; y Gemini 3.7-Flash, en tan solo el 2,4 % de los casos.

Incluso el modelo con mejores resultados, Claude Opus-5, no hizo copias de seguridad de los datos críticos en más de un tercio de los casos analizados.

El artículo afirma^†:

‘Entre seis modelos de frontera, los agentes completan, en promedio, el 86,1 % de las tareas, pero solo hacen copias de seguridad del estado antes de realizar acciones de las que podrían arrepentirse en el 15,2 % de los casos. GPT 5.6-Sol en Codex lo hace apenas en el 5,9 % de las tareas, y DeepSeek V4-Pro en Hermes, solo en el 2,9 %.

‘Estos hallazgos ponen de relieve que los agentes actuales siguen teniendo una capacidad limitada para detectar cuándo deben hacer copias de seguridad y que se necesita una función específica para ello.’

La solución de los autores, llamada BackUpper, funciona junto con el agente como un proceso en segundo plano dentro del entorno de ejecución: comprueba qué está a punto de hacer y crea primero una copia de seguridad si existe el riesgo de perder algo útil.

Para las tareas cotidianas, como actualizar software, sigue un conjunto de reglas sencillas; en situaciones más complejas, recurre a un modelo de IA más pequeño para determinar qué hay que guardar.

En las pruebas, BackUpper cubrió todas las acciones críticas y los datos restaurados alcanzaron un 92,2 % de similitud con los originales, con un coste adicional de 0,014 $ por tarea. En este contexto no es mucho, pero sí representa un gasto considerable para los LLM de vanguardia que prestan servicio a miles de millones de clientes; quizá por eso una solución más probable para mejorar la situación sea recurrir a un servicio externo de este tipo o incorporar esta funcionalidad de forma nativa a los entornos de ejecución, en lugar de esperar que los gigantes tecnológicos implementen una solución nativa (de quienes cabría esperar razonablemente que trasladaran los costes adicionales a sus consumidores, ya fuera mediante subidas de precios o inflación de tokens).

El marco se basa en RegretBench, una prueba de referencia de 205 tareas construida a partir de casos reales en los que las personas perdieron datos que luego desearon haber guardado. Evalúa si los agentes de IA prevén la necesidad de conservar esos datos antes de realizar cambios potencialmente irreversibles. Los incidentes que conforman la colección se obtuvieron de debates y reportes en línea publicados en plataformas como X.com, GitHub y Stack Overflow.

Esquema de cómo convierte RegretBench incidentes reales en escenarios de prueba. Cada caso documentado se reconstruye a partir de la acción que provocó la pérdida, un entorno de trabajo realista y una secuencia de instrucciones. En este ejemplo, actualizar ipykernel reemplaza silenciosamente una versión existente de traitlets, lo que permite al agente terminar la tarea, pero deja sin posibilidad de recuperar la instalación original.

Aunque un 92 % puede resultar desalentador para quienes buscan la perfección, los autores señalan que existen obstáculos técnicos para recuperar ciertos tipos de datos:

«La diferencia con una restauración perfecta se debe principalmente a dos razones. Algunos campos, como los ID de las publicaciones, suelen ser regenerados por los servicios al escribir y, a menudo, no pueden reproducirse. Otras diferencias se deben a metadatos menores, como las marcas de correo leído, que rara vez están presentes en los casos de pérdida de datos que se lamentan.»

En las pruebas, se recuperó una similitud del 33,8 % con el estado original después de que el daño ya se hubiera producido, frente a solo un 14,3 % sin restauración.

El artículo sugiere que, de cara al futuro, la formación podría mejorar la capacidad de prever cuándo hacer copias de seguridad, y que las versiones posteriores de BackUpper podrían aprender a omitir las acciones de bajo riesgo y ampliar la protección a los agentes que usan la web y los ordenadores.

BackUpper es compatible con Claude Code, Codex, Hermes, OpenHands, DeepSeek Harness y OpenClaw. Además, los autores han puesto el código a disposición del público, junto con el conjunto de datos relacionado (aunque para acceder a este hay que solicitar permiso mediante un formulario). En el sitio del proyecto hay algo más de información y un video explicativo muy breve y sencillo sobre la iniciativa.

Metodología

Al construir RegretBench, se excluyeron deliberadamente los datos que ya estaban protegidos por los sistemas de copia de seguridad integrados de los agentes, con el fin de evaluar si estos sabían por sí mismos cuándo hacer una copia de seguridad. Después, los escenarios de prueba se elaboraron con ayuda de Claude Opus-5 y GPT-5.6-Sol, y se revisaron manualmente para comprobar que funcionaran y reflejaran fielmente los incidentes originales.

Las 205 pruebas de RegretBench abarcan cinco áreas: operaciones de terminal; bases de datos; aplicaciones web; correo electrónico; y DevOps. Los incidentes proceden principalmente de plataformas de desarrollo de software y productividad (44,4 %); debates sociales o comunitarios (39 %); y archivos y reportajes en los medios (16,6 %):

Fuentes de los incidentes reales de RegretBench, divididas en tres categorías. 

Los seis modelos de vanguardia evaluados fueron Claude Opus-5 y Claude Sonnet-5, en Claude Code; GPT-5.6-Sol y GPT-5.6-Terra, en Codex; y Gemini 3.7-Flash y DeepSeek V4-Pro, en Hermes.

Se utilizó en todos los casos la configuración predeterminada de razonamiento, y la protección automática mediante copias de seguridad se limitó a las instantáneas del espacio de trabajo, de modo que cualquier copia adicional pudiera atribuirse a decisiones de los propios agentes.

Se utilizaron dos jueces de IA, ambos basados en Claude Sonnet-5, para evaluar el rendimiento. La tasa de tareas superadas (PR) se calculó a partir de la proporción de tareas en las que se cumplían todas las solicitudes del usuario. Para evaluar las copias de seguridad, se comprobó si se había conservado de antemano información suficiente para recuperar cada modificación realizada fuera del espacio de trabajo (OOW).

Las métricas de copia de seguridad utilizadas fueron tasa de copias de seguridad ante pérdidas de datos lamentadas (RMBR), que refleja las acciones específicas asociadas con pérdidas de datos documentadas; y tasa de copias de seguridad fuera del espacio de trabajo (OWBR), que refleja todos los cambios realizados fuera del directorio de trabajo del agente.

Las evaluaciones del sistema automático de verificación de copias de seguridad también se compararon con anotaciones humanas, y se obtuvo un 95,3 % de concordancia.

Resultados

Para determinar si la escasa conciencia sobre la necesidad de hacer copias de seguridad se debía a los modelos de IA o a los marcos en los que se ejecutaban, primero se evaluó Claude Opus-5, GPT-5.6-Sol y DeepSeek V4-Pro con 60 tareas de RegretBench cada uno, en Claude Code, Codex y Hermes.

La proporción de tareas en las que se hicieron copias de seguridad de datos críticos varió poco entre los distintos marcos, lo que sugiere que los principales responsables eran los propios modelos. También se examinó la relación entre la capacidad general de la IA y la conciencia sobre la necesidad de hacer copias de seguridad mediante GPT-5.4, GPT-5.5 y GPT-5.6-Sol.

A pesar de las sucesivas mejoras en la capacidad general, no se observó una mejora equivalente en la conciencia sobre la necesidad de hacer copias de seguridad:

Resultados de las pruebas de RegretBench con seis modelos de IA. Izquierda: tasas de finalización de tareas en comparación con la proporción de acciones críticas de las que se hizo una copia de seguridad por adelantado; los resultados revelan altas tasas de éxito, pero poca conciencia sobre la necesidad de hacer copias de seguridad en la mayoría de los modelos. Derecha: promedio de llamadas a herramientas por tarea, con las operaciones de copia de seguridad resaltadas en azul. Claude Opus-5 obtuvo la tasa más alta de copias de seguridad, pero el 8,9 % de sus llamadas a herramientas se dedicó a ellas.

También se examinó la relación entre la capacidad general de la IA y la conciencia sobre la necesidad de hacer copias de seguridad mediante GPT-5.4, GPT-5.5 y GPT-5.6-Sol. A pesar de las sucesivas mejoras en la capacidad general, no se observó una mejora equivalente en dicha conciencia.

BackUpper

BackUpper utiliza cuatro niveles de protección, cada uno con distintos costos de recursos: el nivel 1 sustituye los comandos destructivos por alternativas reversibles, como mover archivos a la papelera; el nivel 2 combina las operaciones con comandos para hacer copias de seguridad, como registrar las versiones de los paquetes antes de una actualización; el nivel 3 crea instantáneas de los archivos afectados del espacio de trabajo; y el nivel 4 utiliza un subagente GPT-5.6-Luna para identificar y conservar los datos afectados por operaciones más complejas.

Con BackUpper activado, se cubrieron todas las acciones que modificaban el estado en los seis modelos, frente a tasas promedio de copias de seguridad del 15,2 % para las acciones críticas y del 17,4 % para otros cambios cuando no se utilizaba:

Cobertura de copias de seguridad y resultados de restauración de BackUpper. Izquierda: las barras azules y naranjas muestran las tasas de copias de seguridad de cada modelo para las acciones críticas y otros cambios fuera del espacio de trabajo. Los contornos discontinuos de color verde oscuro indican la precisión de la restauración; los contornos punteados de color verde claro muestran una cobertura del 100 % con BackUpper. Derecha: se compara la precisión de la restauración en cinco categorías de herramientas mediante BackUpper (verde), la recuperación posterior con Claude Opus-5 (morado) y la ausencia de restauración (gris). BackUpper obtuvo la mayor precisión en todos los casos.

De las copias de seguridad que el evaluador automatizado consideró exitosas, los revisores humanos también confirmaron el éxito del 94 %.

El estado original se recuperó con una similitud promedio del 92,2 %, frente al 33,8 % con Claude Opus-5 y al 14,3 % sin recuperación (véase la imagen anterior). Las discrepancias restantes se atribuyeron en gran medida a identificadores regenerados y a metadatos menores, como las marcas de lectura de los correos electrónicos, tal como se señaló antes.

¿Hazlo tú mismo..?

Cuando se dieron a los agentes instrucciones detalladas para que hicieran sus propias copias de seguridad, se protegió el 81,4 % de las acciones críticas, frente al 100 % con BackUpper. Tres cuartas partes de los fallos se atribuyeron a copias de seguridad que no contenían información suficiente para la recuperación.

Tasas de copias de seguridad comparadas en cinco enfoques, probados en 205 tareas con seis modelos de IA. El gráfico de la izquierda muestra las copias de seguridad realizadas antes de acciones de las que luego se arrepintieron; el de la derecha, la protección de otros cambios fuera del espacio de trabajo. BackUpper logró una cobertura completa en ambas categorías, frente al 81,4 % y el 80,5 % cuando se dieron a los agentes instrucciones detalladas para hacer copias de seguridad.

Con el almacenamiento en caché de prompts, el costo de las copias de seguridad se redujo de 0,344 $ a 0,014 $ por tarea, y la latencia disminuyó un 31,7 %. Se necesitaron siete veces menos tokens, en gran medida porque las operaciones rutinarias se realizaron sin asistencia de IA.

En 40 tareas adicionales de Terminal-Bench 4 y DeepSWE, GPT-5.6-Sol y Claude Opus-5 lograron una cobertura de copias de seguridad del 100 % sin reducir las tasas de finalización de tareas.

Se evaluaron tres políticas selectivas de copias de seguridad: Alto impacto, para cambios significativos; Más allá de la solicitud, para cambios ajenos a las instrucciones del usuario; y Trabajo humano, para material escrito por personas. En este caso, se obtuvo una puntuación F1 media del 84,5 % frente a los juicios humanos.

También se evaluó la capacidad de BackUpper para aprender reglas de copia de seguridad reutilizables. Tras 30 tareas adicionales en terminal, la cobertura basada en reglas aumentó del 14,9 % al 31,2 %, lo que redujo la dependencia del subagente GPT-5.6-Luna.

Conclusión

Me he adentrado en la experimentación con agentes más tarde de lo que debería, teniendo en cuenta a qué me dedico; pero el estado manifiestamente prealfa de la capacidad de los agentes para contenerse me disuadió hasta hace unas semanas, cuando por fin decidí dar rienda suelta a Codex en una máquina virtual con Windows.

Incluso en una máquina virtual, delimito mis instrucciones con mucho cuidado, consciente de la tendencia de Astra a lanzarse sin reparos y limitarse a pedir disculpas cuando ya no hay forma de recuperar los datos perdidos o el código arruinado; además, parte del marco de trabajo de Python que estoy desarrollando allí es una función incremental de un solo clic ‘guardar .7z en un recurso compartido de red’ , que comprime y crea copias de seguridad de todo el marco de trabajo y que uso con frecuencia.

Estamos todavía en una etapa muy, muy temprana de la IA agéntica; sin una atención al detalle minuciosa y constante, es cuestión de «usarlo y perderlo». Los regímenes de copias de seguridad para agentes aún no se han formalizado; ni siquiera se han formulado.

* Titulado Haz una copia de seguridad antes de arrepentirte: medir la conciencia sobre las copias de seguridad y automatizarlas en agentes de programación.

^† Énfasis de los autores, no mío; además, añadí los hipervínculos a partir de las citas en línea de los autores.

Publicado originalmente el jueves 22 de octubre de 2026