Evaluar agentes IA en producción tiende a centrarse solo en resultados positivos. ¿El agente completó la tarea? ¿La salida fue precisa? ¿La demostración fue convincente?

Las respuestas a estas preguntas importan, pero omiten el aspecto decisivo para que una empresa pueda confiar realmente en los agentes con trabajo real: ¿qué sucede en el 30% de las veces cuando algo sale mal?

En servicios financieros, por ejemplo, un agente autónomo que maneja mal un flujo de movimiento de dinero no se convierte en un ticket de soporte inocuo. Genera responsabilidad legal que puede abarcar toda la organización.

En la atención sanitaria, accesos no controlados a datos pueden comprometer la seguridad del paciente y provocar violaciones de HIPAA. Las industrias altamente reguladas no pueden tratar el fallo como un simple contratiempo. Y cuando las apuestas son mucho mayores que en la mayoría de los demás sectores, cambia el significado de lo que significa “listo para producción”.

El problema es que la mayoría de los marcos de agentes más populares fueron diseñados por equipos enfocados en conectar grandes modelos de lenguaje con bucles de razonamiento y evaluación. Si bien son valiosos, no son la misma disciplina que la ingeniería de sistemas distribuidos.

Pocos de estos marcos fueron construidos por profesionales que han pasado su carrera pensando en recuperación, consistencia y aislamiento de fallos. Muchas soluciones apenas contemplan qué sucede cuando un agente falla a mitad de camino, y esa brecha puede ser muy costosa cuando los agentes manejan transacciones del mundo real.

Reiniciar desde cero no funciona

Cuando un agente de ventas avanza a través de un flujo de 10 pasos y falla en el paso nueve, la recuperación ingenua es reiniciar todo desde el paso uno. Suena inocuo hasta que se consideran los costos de cada paso. Cada reinicio implica volver a ejecutar cada llamada de LLM que ya tuvo éxito, consumiendo tokens para trabajo ya realizado correctamente. A escala, esa ineficiencia convierte un solo fallo en un problema financiero real.

También genera una peor experiencia para las personas y los sistemas aguas abajo. En un flujo regulado, es un trabajo descuidado que se convierte en un problema de cumplimiento y auditoría que espera su momento.

La solución es la ejecución duradera: puntos de control (checkpointing) que capturan el progreso en cada paso significativo, para que la recuperación reanude desde el paso nueve, no desde el inicio. Esto se ha convertido en una práctica estándar en sistemas distribuidos, y la orquestación de agentes debe seguir el mismo camino.

Al evaluar marcos de agentes, la pregunta clave es: si un agente falla a mitad de una tarea de larga duración, ¿el sistema reanuda desde donde se quedó o vuelve a empezar? La respuesta indicará la diferencia entre marcos creados para producción y los creados para demostraciones.

Existe un problema de acceso del que nadie habla

La seguridad en sistemas agentizados presenta su propia variante de este desafío, y comienza con una pregunta que suena básica pero que la mayoría de las organizaciones no puede responder: ¿puedes demostrar exactamente quién o qué hizo qué y cuándo?

Esa pregunta es más compleja cuando los agentes actúan en nombre de otros agentes, que a su vez actúan en nombre de las personas. Cada capa de delegación añade ambigüedad sobre la responsabilidad. Y cuando se suman los servidores MCP, la exposición se multiplica. MCP otorga a los modelos de lenguaje acceso a registros de la empresa, datos de pacientes y sistemas internos. La gran mayoría de los servidores MCP en producción hoy se conectan a alguna base de datos, y el error común es conceder acceso amplio a toda la reserva de datos en lugar de restringir lo que cada servidor puede ver.

Esa distinción importa cuando algo sale mal. Si un sistema con acceso amplio sufre una brecha o una compromisión en la cadena de suministro, el atacante obtiene acceso a todo el entorno. El acceso limitado, donde un servidor MCP o un agente solo puede acceder a los datos necesarios para la tarea, es una de las decisiones de diseño más pasadas por alto en la arquitectura de agentes hoy y, a la vez, uno de los problemas más costosos de resolver después de una brecha.

La identidad añade otra capa. Muchas organizaciones siguen utilizando protocolos de autenticación tradicionales pensados para usuarios humanos, no para sistemas autónomos que actúan a velocidad y escala de máquina. Sin identidades verificables para cada agente y cada componente, código malicioso puede hacerse pasar por una parte legítima del sistema y operar sin ser detectado.

Lo que se necesita aquí es lo que se conoce como atestación criptográfica: un registro a prueba de manipulaciones de todo lo que ocurrió en el sistema vinculado a la identidad específica que lo realizó. Ese registro permite reproducir el estado del sistema después de los hechos y determinar con certeza que un fragmento de código accedió a un sistema específico en un momento concreto. ¿Por qué? Porque esa identidad fue gestionada y aplicada en tiempo real. Es la diferencia entre una política que dice que un componente debe ser confiable y un sistema que puede demostrar lo que realmente hizo.

Diseño para limitar la radiación de la brecha, no solo parchear el daño

Existe también un problema en la forma en que la mayoría de las organizaciones piensan sobre las vulnerabilidades. El enfoque de la industria está casi exclusivamente en parchear CVEs conocidos, y eso es necesario. Pero al mismo tiempo, se pasa por alto algo importante: una vulnerabilidad solo se convierte en CVE conocido después de una brecha. La gestión de parches es intrínsecamente reactiva y no hace nada mientras un sistema está comprometido, momento en el que el código malicioso ya intenta moverse lateralmente por la red.

Por eso la ejecución en tiempo de dominio (runtime enforcement) merece mucho más atención. El objetivo no es solo la prevención; es la contención. Si un sistema se ve comprometido, ¿puedes detectar que un componente se comporta de forma anómala y restringir inmediatamente su acceso, incluso antes de haber identificado o parcheado la falla subyacente? Limitar la radiación en tiempo real, en lugar de depender solo de la detección post-facto, es lo que separa un incidente contenido de una brecha a gran escala.

Los principios de confianza cero deben aplicarse específicamente a las cargas de IA, no solo heredados de protocolos de seguridad en la nube tradicionales. Eso significa autenticación y autorización estrictas para cada agente y cada servidor MCP, políticas claras sobre lo que cada componente puede acceder, y controles que detengan a los componentes comprometidos de enviar datos fuera de la organización.

Necesitas demostrar seguridad, no solo funcionalidad

No se trata de pesimismo hacia los agentes IA; se trata de madurez en la ingeniería. Cada sistema distribuido que ha madurado hasta convertirse en una infraestructura en la que las empresas confían para cargas críticas pasó por la misma evolución. Pasan de optimizar casos comunes a diseñar explícitamente para fallas raras y costosas.

La IA basada en agentes ha llegado a ese punto. Las organizaciones que lo hagan bien podrán sentarse con auditores o reguladores y demostrar, con evidencia, exactamente cómo se comporta sus sistemas cuando algo falla:

– Recuperación duradera que no desperdicia un solo paso completado.

– Acceso limitado a la tarea, no a toda la base de datos.

– Identidad que puede verificarse criptográficamente, no solo presumirse.

– Contención que se activa en tiempo real, no después de los hechos.

Estos son los criterios que las empresas serias deben cumplir para desplegar IA con agentes a escala.

Listamos las mejores soluciones de almacenamiento en la nube para empresas.

Este artículo fue producido como parte de TechRadar Pro Perspectives, nuestro canal para presentar a las mentes más brillantes de la industria tecnológica hoy en día.

Las opiniones expresadas aquí son de la autoría y no necesariamente las de TechRadarPro o Future plc. Si estás interesado en contribuir, aprende más aquí: https://www.techradar.com/pro/perspectives-how-to-submit