La creciente adopción de agentes basados en inteligencia artificial en entornos de producción ha transformado la forma en que se resuelven tareas, haciendo que el trayecto entre la petición inicial y el resultado final sea cada vez menos lineal y previsible. Estos agentes pueden seleccionar sus propias herramientas y modificar su estrategia en tiempo real, lo que dificulta enormemente la identificación y depuración de errores cuando no existe una falla evidente que seguir.
En una entrevista reciente con The New Stack, Adel el Hallak, vicepresidente de producto en Nvidia, destacó la necesidad de ofrecer a los desarrolladores una mayor visibilidad para afrontar las complejidades que surgen cuando los agentes asumen tareas más sofisticadas.
Como parte de este esfuerzo, Nvidia participa en una iniciativa colectiva respaldada por alrededor de 140 empresas llamada Secure Agent Findings Exchange (SAFE). Este proyecto tiene como objetivo crear una infraestructura común para compartir información sobre los fallos de agentes, inspirándose en los métodos tradicionales para la divulgación y corrección de vulnerabilidades de software. 
«Cuando detectamos estas vulnerabilidades, no es solo para una empresa, es para que todos puedan aplicar las soluciones», aseguró el Hallak.
El reto de depurar errores en agentes frente al software tradicional
En el desarrollo de software convencional, los programadores suelen partir de indicios claros, como excepciones, solicitudes fallidas o caídas de servicio, cuando algo sale mal. Sin embargo, los agentes pueden continuar ejecutándose incluso habiendo cometido un error previo, extendiendo el fallo a lo largo de un proceso sin producir una aparente anomalía típica de un error de software. En palabras de El Hallak, el agente puede decidir “ser creativo” cuando no debería hacerlo.
Además, estudios recientes muestran que incluso los agentes de código mejor diseñados fracasan más del 60% de las veces en tareas extraídas de bases de código reales. Saber que el agente falló es una cosa, pero entender la causa raíz es otra completamente distinta.
«No basta con analizar los logs o comparar entradas y salidas. Es fundamental comprender cómo llegó a esa respuesta, rastrear su razonamiento, identificar qué herramientas utilizó, en qué puntos se bloqueó o cuándo decidió cambiar de estrategia», explicó el directivo.
Para ello, a menudo es necesario reproducir la ejecución del agente para descubrir en qué momento se desvió del camino correcto. La causa de una anomalía puede encontrarse en cualquier capa de la arquitectura, y no siempre reside en el modelo en sí.
“No basta con revisar registros o resultados; hay que entender las trazas de pensamiento y las decisiones tomadas durante el proceso.”
El tiempo de ejecución como punto central de recopilación
Nvidia considera que es en el entorno de ejecución —el runtime— donde se debe recopilar la información más valiosa. El runtime propio de Nvidia, llamado OpenShell, que funciona bajo la plataforma NemoClaw, ofrece funciones de aislamiento en entornos seguros y políticas de gobernanza, además de proporcionar visibilidad exhaustiva sobre cómo se desarrolla la actividad del agente.
El Hallak subraya que OpenShell es un componente irrenunciable dentro de las arquitecturas de referencia de la compañía. «Puedes modificar la capa de orquestación que necesites, incluso emplear cualquier modelo que prefieras, pero la gobernanza y seguridad durante la ejecución siempre deben estar garantizadas a través de OpenShell», afirma.
En términos generales, Nvidia divide la pila tecnológica de agentes en tres capas: el modelo que aporta la inteligencia, el arnés que coordina su trabajo y el runtime que controla la ejecución. Por ello, cuando un agente falla, el problema no siempre está en el modelo.
Investigaciones como las realizadas con el framework NOAH de Nvidia demostraron que modificar el arnés de ejecución mientras se mantiene el mismo modelo puede mejorar el rendimiento del agente. Esto implica que un arnés inapropiado puede entorpecer incluso a un modelo de gran capacidad.
«Cada modelo es diferente, algunos son más ‘charlatanes’ que otros. Lo importante es que el arnés y el modelo se desarrollen conjuntamente o cuenten con perfiles adaptados a cada uno, algo que abre nuevas posibilidades», señala el vicepresidente de Nvidia.
La seguridad como problema de ingeniería de sistemas
Jensen Huang, CEO de Nvidia, ha definido la seguridad en IA como un desafío de ingeniería que debe abordarse con rigurosidad similar a la prueba de software convencional.
«Si detectas un error en tu software, no lanzas el producto hasta que esté arreglado y cumpla con todas las pruebas», recuerda El Hallak.
Sin embargo, con los agentes esta dinámica se complica, porque reproducir con exactitud un fallo puede requerir reconstruir detalladamente qué sucedió en todo el sistema. Esto exige mecanismos de instrumentación que, a su vez, incrementan la carga computacional; OpenAI, por ejemplo, estimó que monitorizar agentes persistentes añade alrededor del 20% en consumo de cálculo durante la inferencia.
La estrategia de Nvidia combina arnases gobernados, ambientes en sandbox y computación confidencial para proteger tanto los modelos como los datos de los usuarios.
«Hay maneras de garantizar seguridad hasta el nivel del silicio», concluye El Hallak.
La iniciativa SAFE se extiende más allá de la frontera de cada empresa, promoviendo un modelo colaborativo para compartir y aprender de los errores cometidos en los agentes.
«Si hay un fallo en tu producto, no lo lanzas hasta haberlo corregido y haber pasado todas las pruebas.»
Agentes que ayudan a depurar a otros agentes
Un caso destacado es el de CrowdStrike, que está afinando modelos Nerotron de Nvidia con años de datos en seguridad para crear pares de agentes especializados: uno detecta vulnerabilidades y el otro genera parches para corregirlas.
El problema es que cuando alguno de estos agentes falla, el resultado final no deja claro el motivo. Por ejemplo, un parche defectuoso podría deberse a errores en el modelo, en la trayectoria de ejecución o en las herramientas usadas durante el proceso.
«No necesito un agente que sea generalista para una tarea, sino uno especializado», destaca El Hallak.
A medida que las compañías construyen agentes a medida para workflows cada vez más especializados, estos fallos pueden no aparecer reflejados en métricas o pruebas de seguridad diseñadas para modelos generalistas, aumentando la presión sobre los desarrolladores para entender qué ocurrió en cada ejecución.
Un futuro con reportes compartidos de fallos
Para los equipos de plataforma, localizar el fallo es solo el primer reto; reconstruir la secuencia completa de ejecución para comprender la causa raíz es otra tarea compleja. SAFE pretende facilitar que los hallazgos de una organización puedan ser útiles para otras, evitando que cada equipo tenga que descubrir por su cuenta los mismos errores.
En el mundo del software tradicional existen mecanismos consolidados para compartir vulnerabilidades y soluciones, sin embargo, aún no se ha establecido una infraestructura equivalente para los fallos de agentes. SAFE aspira a llenar ese vacío, promoviendo una mejora continua y colaborativa en los sistemas de inteligencia artificial.
