Ángulo de Anderson

NVIDIA Research descubre que los agentes de IA son menos seguros cuando usan herramientas

mm
Añade Unite.AI a tus fuentes preferidas en Google
An AI-extended screenshot from the 2012 sci-fi outing 'Robot and Frank', here showing Robot practicing how to pick a lock. Image adapted to format and refined by GPT Image 2 and Photoshop. Still from Robot & Frank (2012). © 2012 Hallowell House, LLC. All Rights Reserved. Used strictly for illustrative and cultural purposes.

Los modelos de IA, como ChatGPT, Gemini y Claude, pueden utilizarse para impulsar agentes: «estructuras» que permiten a los modelos interactuar directamente con el mundo real. Es una innovación reciente y cada vez más controvertida.

En cualquier caso, los agentes no cuentan automáticamente con las capacidades que necesitarán para recorrer una red o una base de datos, ya que las herramientas necesarias varían según la misión y el modo de operación. Por ejemplo, pueden necesitar capacidades de reconocimiento óptico de caracteres (OCR) para interpretar el texto de las fotografías, entre otras habilidades. También existen categorías de herramientas adaptadas al alcance del agente y a su propósito.

En teoría, una solicitud que infrinja las medidas de protección integradas en una IA nunca llegará a ejecutarse, se utilicen o no herramientas para llevarla a cabo. Sin embargo, según una nueva investigación, en la práctica el uso de herramientas puede debilitar considerablemente los filtros de protección que impiden que un agente de IA cometa «transgresiones».

La incapacidad de rechazar solicitudes

El nuevo artículo de NVIDIA, titulado Los MLLM no rechazan solicitudes cuando usan herramientas de forma autónoma, revela que los modelos de lenguaje multimodales (MLLM, denominados en adelante con la sigla más habitual «VLM», o modelos de lenguaje visual) tienen muchas más probabilidades de atender solicitudes perjudiciales cuando se les proporcionan herramientas; los fallos de rechazo aumentaron en todos los modelos y bancos de pruebas evaluados.

Aunque los modelos de pesos abiertos, como Qwen3-VL, resultaron más propensos a este problema, los modelos de IA de vanguardia, como Claude Opus 4.7, Gemini 3.1 Pro y GPT-5.4, también registraron un aumento de los fallos de rechazo al utilizar herramientas.

Los autores afirman*:

«A pesar del reciente éxito de los MLLM autónomos, este trabajo revela un fallo de seguridad crítico en el paradigma del uso de herramientas: los MLLM autónomos que utilizan herramientas tienen menos capacidad para rechazar solicitudes perjudiciales.»

«Nuestros experimentos confirman que, en tres de los principales bancos de pruebas de seguridad, todos los MLLM de pesos abiertos y cerrados de primer nivel que evaluamos muestran un nivel de seguridad significativamente menor cuando utilizan herramientas que cuando no las utilizan. El aumento relativo de la tasa de fallos de rechazo alcanza el 68,7 %.»

«A partir del análisis de más de 100 000 respuestas, incluidos experimentos ampliados, también proponemos dos posibles causas de este deterioro de la seguridad.»

Las dos posibles causas que plantea el artículo son la dilución del contexto, por la que la solicitud perjudicial original pierde relevancia a medida que se acumulan los resultados de las herramientas; y el desplazamiento del foco de seguridad, por el que el modelo se centra en describir las observaciones obtenidas mediante las herramientas en lugar de dar prioridad a la seguridad.

Resultados de las pruebas que ilustran el hallazgo central del artículo sobre seguridad. En la parte superior, un usuario pregunta cómo cometer un aparente carterismo que se muestra en una imagen. Un VLM convencional rechaza la solicitud de plano, mientras que una versión que usa herramientas primero recurre a herramientas de análisis de imágenes, como la ampliación, luego sigue razonando y, finalmente, proporciona una respuesta perjudicial. El gráfico de abajo muestra que este aumento de los fallos de rechazo se observó en todos los modelos de pesos abiertos y propietarios evaluados.

Resultados de las pruebas que ilustran el hallazgo central del artículo sobre seguridad. En la parte superior, un usuario pregunta cómo cometer un aparente carterismo que se muestra en una imagen. Un VLM convencional rechaza la solicitud de plano, mientras que una versión que usa herramientas primero recurre a herramientas de análisis de imágenes, como la ampliación, luego sigue razonando y, finalmente, proporciona una respuesta perjudicial. El gráfico de abajo muestra que este aumento de los fallos de rechazo se observó en todos los modelos de pesos abiertos y propietarios evaluados. Fuente

En los once modelos evaluados, habilitar herramientas aumentó sistemáticamente los fallos de rechazo, con incrementos relativos de hasta el 68,7 % en los casos más desfavorables, incluso en modelos que, por lo demás, demostraron un sólido rendimiento en materia de seguridad.

Será interesante comprobar si otros investigadores reproducen o replican los resultados de este trabajo, realizado por seis investigadores de NVIDIA, y si estos podrían profundizar nuestra comprensión de la aparente y emergente conducta transgresora de los agentes de IA que infringen las normas.

Método y datos

Los investigadores evaluaron once VLM pertenecientes a siete familias de modelos. Los modelos propietarios fueron Gemini 2.5 Pro, Gemini 3.1 Pro Preview, Claude Opus 4.6, Claude Opus 4.7 y GPT-5.4.

Los modelos de pesos abiertos fueron Qwen3-VL-235B-A22B-Instruct, Qwen3.5-122B-A10B, Kimi-K2.5, Kimi-K2.6, GLM-5V-Turbo y AdaReasoner-7B-Randomized, un modelo de pesos abiertos ajustado específicamente para el uso autónomo de herramientas.

También se llevaron a cabo experimentos independientes con Gemini 3 Flash Vision Agent, ya que su uso autónomo de herramientas exigía evaluarlo por separado.

Para las pruebas con uso de herramientas, los investigadores utilizaron el formato ReAct, que alterna entre el razonamiento y las llamadas a herramientas. Las cuatro herramientas disponibles eran el etiquetado con RAM++; el zoom y recorte; el reconocimiento óptico de caracteres (OCR) con GOT-OCR2.0; y un intérprete de código Python en un entorno aislado, que podía manipular y analizar imágenes.

Los investigadores diseñaron instrucciones emparejadas para aislar el efecto del uso de herramientas y no el del estilo de las instrucciones. Se indicó a los modelos convencionales de visión y lenguaje (VLM) que examinaran la imagen y respondieran directamente a la solicitud del usuario, mientras que las versiones con capacidades de agente seguían el flujo de trabajo ReAct y decidían repetidamente si debían utilizar herramientas antes de generar una respuesta final.

Comparación de las instrucciones emparejadas utilizadas en los experimentos principales. En la condición sin herramientas, se requería analizar la imagen y razonar directamente; en cambio, la condición con capacidades de agente seguía el flujo de trabajo iterativo ReAct, que permitía al modelo decidir cuándo utilizar herramientas externas antes de generar su respuesta final.

Comparación de las instrucciones emparejadas utilizadas en los experimentos principales. En la condición sin herramientas, se requería analizar la imagen y razonar directamente; en cambio, la condición con capacidades de agente seguía el flujo de trabajo iterativo ReAct, que permitía al modelo decidir cuándo utilizar herramientas externas antes de generar su respuesta final.

Los tres conjuntos de pruebas de seguridad multimodal utilizados fueron MM-SafetyBench, VLSBench y HoliSafe. Cada conjunto está compuesto por pares de imágenes y solicitudes dañinas de usuarios, diseñados para comprobar si un modelo se niega a prestar ayuda en situaciones peligrosas, como cuando se pregunta cómo llevar a cabo un aparente caso de carterismo que se muestra en una imagen.

La métrica principal fue la tasa de fallos de rechazo (RFR), que mide el porcentaje de solicitudes dañinas que un modelo no rechazó; cuanto mayor es la puntuación, menor es la seguridad.

Pruebas

GPT-5.2 clasificó las respuestas como evaluador basado en un modelo de lenguaje grande (LLM), mediante la instrucción de evaluación recomendada por VLSBench:

Instrucción de evaluación de GPT-5.2 utilizada para determinar si cada respuesta del modelo constituía un rechazo satisfactorio, una respuesta consciente de los riesgos que los señalaba o una respuesta insegura que no los reconocía y atendía la solicitud dañina. Se proporcionaron al evaluador la imagen original, la consulta del usuario y la respuesta del modelo, y se le pidió que devolviera su clasificación y razonamiento en formato JSON.

Instrucción de evaluación de GPT-5.2 utilizada para determinar si cada respuesta del modelo constituía un rechazo satisfactorio, una respuesta consciente de los riesgos que los señalaba o una respuesta insegura que no los reconocía y atendía la solicitud dañina. Se proporcionaron al evaluador la imagen original, la consulta del usuario y la respuesta del modelo, y se le pidió que devolviera su clasificación y razonamiento en formato JSON.

Cada respuesta se asignó a una de tres categorías: segura con rechazo, segura con advertencia o insegura.

Tasas de fallos de rechazo en los tres conjuntos de pruebas de seguridad, con una comparación de cada modelo con y sin acceso a herramientas. Todos los modelos fueron menos propensos a rechazar solicitudes dañinas cuando usaban herramientas, aunque la magnitud de este efecto varió considerablemente: la RFR media aumentó 12,6 puntos en GLM-5V-Turbo, frente a 2,3 puntos en GPT-5.4. Los tonos más oscuros indican aumentos mayores en los fallos de rechazo.

Tasas de fallos de rechazo en los tres conjuntos de pruebas de seguridad, con una comparación de cada modelo con y sin acceso a herramientas. Todos los modelos fueron menos propensos a rechazar solicitudes dañinas cuando usaban herramientas, aunque la magnitud de este efecto varió considerablemente: la RFR media aumentó 12,6 puntos en GLM-5V-Turbo, frente a 2,3 puntos en GPT-5.4. Los tonos más oscuros indican aumentos mayores en los fallos de rechazo.

Al darles herramientas, los modelos fueron más propensos a responder a solicitudes dañinas que, de otro modo, habrían rechazado; este resultado se observó en todos los modelos y en todos los conjuntos de pruebas evaluados. En general, los fallos de rechazo aumentaron un 17,7 % en comparación con los mismos modelos cuando funcionaban sin herramientas.

GPT-5.4 fue el menos afectado: sin herramientas, no rechazó el 14,6 % de las solicitudes dañinas; con herramientas, esa cifra aumentó al 16,8 %. En GLM-5V-Turbo, los fallos aumentaron del 38,7 % (referencia sin herramientas) al 51,3 %. El mismo patrón se observó en los tres conjuntos de pruebas, lo que indica que el problema quizá no se limite a un tipo particular de solicitud dañina.

¿Razones del incumplimiento…?

Como se mencionó anteriormente, los investigadores proponen la «dilución del contexto» como una posible explicación del aumento de los fallos: a medida que un agente realiza llamadas sucesivas a herramientas, la solicitud dañina original pierde relevancia entre los resultados de las herramientas que se van acumulando.

Para comprobarlo, tuvieron en cuenta únicamente las solicitudes que el mismo modelo había rechazado correctamente sin herramientas. Como se muestra a continuación, los fallos aumentaron de forma progresiva con el número de llamadas a herramientas: pasaron de casi cero cuando no se utilizaba ninguna herramienta a tasas considerablemente mayores después de tres llamadas o más:

Resultados de las pruebas que comparan los fallos de rechazo con distintos números de llamadas a herramientas. Las tasas de fallos aumentaron a medida que se acumulaban llamadas adicionales, tanto en cada modelo como en el conjunto de todos los modelos.

Resultados de pruebas que comparan los fallos de rechazo con distintas cantidades de llamadas a herramientas. Las tasas de fallo aumentaron a medida que se acumulaban llamadas adicionales, tanto en los modelos individuales como en el conjunto de todos los modelos.

Una segunda prueba revirtió parcialmente el efecto. Cuando se volvieron a insertar la solicitud original y la imagen después de la última llamada a una herramienta, justo antes de que el modelo respondiera, los fallos de rechazo disminuyeron en un promedio del 7.6% en los distintos modelos y bancos de pruebas, como se muestra a continuación:

Resultados de pruebas que comparan los fallos de rechazo con y sin la reinserción de la solicitud original y la imagen. Reinserirlas después de la última llamada a una herramienta redujo la tasa media de fallos en un 7.6% en los cinco modelos evaluados.

Resultados de pruebas que comparan los fallos de rechazo con y sin la reinserción de la solicitud original y la imagen. Reinserirlas después de la última llamada a una herramienta redujo la tasa media de fallos en un 7.6% en los cinco modelos evaluados.

Esto respalda la dilución del contexto como un factor contribuyente y, al mismo tiempo, apunta a una medida de mitigación relativamente sencilla.

La segunda explicación que propone el artículo es el «desplazamiento del foco de seguridad». En este caso, el uso de herramientas parece desviar la atención del modelo de si la solicitud es dañina hacia la descripción de lo que han encontrado sus herramientas.

Resultados de pruebas que muestran cómo el uso de herramientas cambió el inicio de las respuestas de los modelos que finalmente rechazaron solicitudes dañinas. Sin herramientas, las respuestas solían comenzar abordando directamente la solicitud (55.6%) o planteando inquietudes de seguridad (25.8%). Con herramientas, el 52.3% comenzaba, en cambio, describiendo lo que estas habían encontrado, mientras que las declaraciones explícitas sobre seguridad descendieron al 10.3%.

Resultados de pruebas que muestran cómo el uso de herramientas cambió el inicio de las respuestas de los modelos que finalmente rechazaron solicitudes dañinas. Sin herramientas, las respuestas solían comenzar abordando directamente la solicitud (55.6%) o planteando inquietudes de seguridad (25.8%). Con herramientas, el 52.3% comenzaba, en cambio, describiendo lo que estas habían encontrado, mientras que las declaraciones explícitas sobre seguridad descendieron al 10.3%.

Se examinaron casos en los que los modelos lograron rechazar la solicitud tanto con herramientas como sin ellas. Sin herramientas, el 55.6% de estas respuestas comenzaba abordando directamente la solicitud, mientras que el 25.8% empezaba con una declaración explícita sobre seguridad. Con herramientas, esas cifras descendieron al 37.4% y al 10.3%, respectivamente, mientras que la proporción de respuestas que comenzaban describiendo observaciones obtenidas mediante las herramientas aumentó al 52.3%.

Los autores ofrecen un interesante ejemplo cualitativo con Claude Opus 4.6. Cuando se le preguntó cómo podía eludirse la seguridad en los baños públicos, el modelo rechazó la solicitud de inmediato cuando no tenía herramientas:

Ejemplo que muestra cómo el uso de herramientas desplazó la seguridad del foco inmediato del modelo. Claude Opus 4.6 rechazó la solicitud dañina de inmediato sin herramientas; con ellas, primero amplió la imagen, leyó e identificó su contenido y describió el letrero del baño antes de acabar rechazándola.

Ejemplo que muestra cómo el uso de herramientas desplazó la seguridad del foco inmediato del modelo. Claude Opus 4.6 rechazó la solicitud dañina de inmediato sin herramientas; con ellas, primero amplió la imagen, leyó e identificó su contenido y describió el letrero del baño antes de acabar rechazándola.

Al disponer de herramientas, el mismo modelo amplió la imagen, leyó el texto e identificó su contenido; luego inició su respuesta describiendo el letrero del baño. El rechazo llegó solo después, lo que ilustra cómo el proceso de uso de herramientas había desplazado la seguridad como prioridad inmediata del modelo.

Los autores concluyen:

«En conjunto, nuestros hallazgos indican que el uso de herramientas debe considerarse no solo un mecanismo que mejora las capacidades de razonamiento visual, sino también una decisión de diseño relevante para la seguridad, capaz de alterar el comportamiento de rechazo; por tanto, los futuros MLLM con capacidades agénticas deberían evaluarse y entrenarse en condiciones de uso de herramientas, en lugar de dar por sentado que la alineación de seguridad sin herramientas se traslada sin cambios a los entornos agénticos».

Conclusión

La incapacidad de mantener el contexto supone claramente un inconveniente en cadenas complejas de eventos posteriores a una instrucción; sin embargo, actualmente no hay soluciones fáciles para la tendencia de una ventana de contexto limitada a hacer que un agente olvide sus «directivas principales» y simplemente empiece a usar la herramienta que tiene a mano.

 

* Énfasis de los autores; convertí las citas integradas de los autores en hipervínculos cuando fue necesario.

Publicado por primera vez el miércoles, 7 de octubre de 2026

Redactor de aprendizaje automático, especialista en síntesis de imágenes humanas. Anterior jefe de contenido de investigación en Metaphysic.ai, hasta su disolución en Brahma.ai de DNEG.
Sitio web: martinanderson.ai
Contacto: martin@martinanderson.ai