Ingenieros experimentados aún tropiezan al crear agentes de IA

0
2
Ingenieros experimentados aún tropiezan al crear agentes de IA

En resumen

Una publicación destacada en Google News afirma que incluso ingenieros sénior enfrentan dificultades para construir agentes de IA confiables. El tema importa porque los agentes prometen automatizar tareas complejas, pero aún exigen nuevas prácticas de arquitectura, evaluación, seguridad y operación.

Una noticia agregada por Google News llamó la atención sobre un debate recurrente en el sector de la inteligencia artificial: por qué incluso los ingenieros sénior tienen dificultades para construir agentes de IA que funcionen de forma confiable fuera de demostraciones controladas. El elemento apunta a un texto atribuido a Philipp Schmid, asociado al ecosistema de Google DeepMind, con el título en inglés “Why (Senior) Engineers Struggle To Build AI Agents”. La página original citada en la búsqueda disponible no incluyó el contenido completo, por lo que esta nota se basa en el título, en el contexto técnico conocido del tema y en la fuente indicada, sin tratar detalles específicos del artículo como confirmados.

El tema ganó fuerza porque los agentes de IA se convirtieron en una de las promesas centrales de la fase actual de la IA generativa. La idea es sencilla de explicar y difícil de ejecutar: en lugar de solo responder una pregunta, el sistema debe interpretar un objetivo, dividir la tarea en etapas, usar herramientas externas, consultar datos, revisar sus propios resultados y, en algunos casos, actuar con poca supervisión humana. En la práctica, este cambio transforma un modelo de lenguaje en parte de un sistema operativo de decisiones, integraciones y riesgos.

El problema no es solo escribir mejores prompts

La dificultad para los ingenieros experimentados empieza cuando la lógica del software deja de ser totalmente predecible. En aplicaciones tradicionales, una función recibe una entrada, ejecuta reglas conocidas y devuelve una salida esperada. En agentes basados en modelos de lenguaje, la salida puede variar según el contexto, la formulación del prompt, la versión del modelo, los datos recuperados, la herramienta invocada e incluso el historial de interacciones. Esto exige una mentalidad diferente: menos control línea por línea, más diseño de límites, observabilidad, evaluación y mecanismos de corrección.

Ese desajuste ayuda a explicar por qué profesionales acostumbrados a sistemas distribuidos, API y pipelines robustos aún pueden subestimar a los agentes. El desafío no es solo hacer que el agente “funcione una vez”, sino lograr que funcione de manera repetida, con un costo aceptable, tolerancia a fallos, trazabilidad y comportamiento seguro. Una demostración que agenda una reunión, resume un documento o crea un ticket puede parecer convincente; convertirla en producto exige responder qué ocurre cuando la herramienta falla, cuando el modelo inventa una etapa, cuando hay datos ambiguos o cuando la acción tiene consecuencias financieras, legales u operativas.

  • Los agentes necesitan decidir cuándo responder directamente y cuándo usar una herramienta externa.
  • Cada llamada al modelo o a una herramienta añade costo, latencia y posibilidad de error.
  • Las pruebas unitarias tradicionales no capturan bien las variaciones semánticas ni los comportamientos probabilísticos.
  • Los sistemas con autonomía exigen controles de permisos, auditoría y reversión.
  • La calidad depende tanto del modelo como de la arquitectura de memoria, recuperación de datos y evaluación.

De la investigación al producto, la distancia es grande

En los últimos años, empresas como Google DeepMind, OpenAI, Anthropic, Microsoft, Meta y varias startups comenzaron a tratar a los agentes como el siguiente paso natural de los modelos de lenguaje. El avance de modelos multimodales, ventanas de contexto más amplias y llamadas estructuradas a herramientas hizo posible construir flujos más ambiciosos. Aun así, la mayoría de los agentes comerciales opera mejor en dominios acotados, con permisos limitados y supervisión humana, justamente porque una autonomía amplia aumenta la superficie de error.

La cronología reciente ayuda a entender la frustración. Primero, los chatbots basados en LLM mostraron capacidad para responder, resumir y programar. Luego, los frameworks de agentes popularizaron cadenas de razonamiento, uso de herramientas y múltiples pasos. Después llegaron copilotos corporativos, asistentes de programación y sistemas con acceso a documentos internos. Ahora, la frontera está en agentes que ejecutan tareas completas. Es en ese paso, de asistente a ejecutor, donde surgen los mayores problemas de ingeniería.

Un agente necesita operar en un mundo que cambia. Las API modifican formatos, las páginas web cambian de diseño, las bases de datos quedan desactualizadas, los permisos varían y los usuarios formulan objetivos incompletos. A diferencia de un script convencional, el agente con frecuencia necesita inferir intención y elegir caminos. Si esa elección no es observable, explicable y limitada por políticas claras, el equipo de ingeniería pierde la capacidad de depurar el sistema con la misma seguridad que tendría en un servicio tradicional.

Evaluar agentes aún es una disciplina inmadura

Otro punto central es la evaluación. Medir la calidad de una respuesta de chatbot ya es difícil; medir un agente que ejecuta diez etapas es aún más difícil. El resultado puede ser correcto aunque una etapa intermedia parezca extraña, o puede parecer correcto mientras oculta un error crítico. Las evaluaciones automáticas ayudan, pero deben combinarse con conjuntos de tareas reales, pruebas de regresión, análisis de registros, simulaciones de fallo y revisión humana en tareas de mayor riesgo.

También existe una tensión entre autonomía y control. Cuanta más libertad tiene el agente para elegir herramientas, crear planes e intentar alternativas, mayor es la probabilidad de resolver tareas variadas. Al mismo tiempo, crece el riesgo de bucles, acciones innecesarias, filtración de datos, uso indebido de credenciales o decisiones que el usuario no pretendía autorizar. Por eso, muchos sistemas maduros tratan a los agentes como componentes supervisados: sugieren, preparan, clasifican y ejecutan solo dentro de límites explícitos.

Para las empresas, la implicación práctica es que los agentes de IA no deben verse como una función aislada que se agrega al producto con una biblioteca. Exigen gobernanza de datos, diseño de permisos, contratos claros con herramientas, monitoreo de costos y una capa de producto que comunique límites al usuario. En entornos regulados, como salud, finanzas, jurídico y recursos humanos, la exigencia es aún mayor, porque el error no es solo técnico; puede generar exposición legal y pérdida de confianza.

El papel de los profesionales experimentados, en este contexto, cambia. La seniority sigue siendo importante, pero debe aplicarse a un tipo diferente de incertidumbre. La arquitectura de agentes implica descomponer tareas, reducir grados de libertad, crear puntos de control, registrar decisiones, limitar acciones destructivas y definir cuándo el sistema debe detenerse y pedir confirmación. La habilidad no está en confiar más en el modelo, sino en saber dónde no confiar.

Lo que aún no está confirmado

La fuente disponible para esta investigación es un elemento de Google News que apunta a una publicación con el título citado. La búsqueda extraída de la página original no incluyó el texto completo, datos adicionales, declaraciones directas, ejemplos técnicos ni confirmación independiente de autoría más allá de la atribución en el título. Por eso, no es posible afirmar qué argumentos específicos presentó Philipp Schmid, si hubo mención a proyectos internos de Google DeepMind, ni si el texto se refiere a experiencias personales, una guía técnica o una opinión editorial.

Los próximos pasos para el sector pasan por estandarizar formas de probar y operar agentes. Esto incluye benchmarks más realistas, herramientas de observabilidad específicas para trayectorias de agentes, controles de permisos granulares, evaluación continua en producción y estándares de seguridad para acciones automatizadas. Hasta entonces, el mensaje principal sigue siendo pragmático: los agentes de IA pueden ser poderosos, pero su dificultad está menos en el brillo de la demostración y más en la ingeniería necesaria para volverlos previsibles, auditables y útiles en el día a día.

Nuestro prisma

La discusión importa porque desplaza el foco del hype hacia la ingeniería real: los agentes no son solo prompts largos, sino sistemas distribuidos con partes probabilísticas. El avance práctico debe venir de arquitecturas que reducen la autonomía donde no es necesaria y aumentan la supervisión donde el riesgo es alto. Para las empresas, la pregunta deja de ser “¿tenemos un agente?” y pasa a ser “¿sabemos medir, limitar y recuperar ese agente cuando se equivoca?”.

Fuente: Google News — AI agents

Preguntas frecuentes

¿Qué son los agentes de IA?

Son sistemas que usan modelos de lenguaje para planificar, llamar herramientas, ejecutar etapas y adaptar acciones para cumplir una tarea.

¿Por qué los ingenieros experimentados tienen dificultades con los agentes?

Porque los agentes combinan comportamiento probabilístico, integración con herramientas, memoria, evaluación continua y riesgos operativos que se apartan del software determinístico tradicional.

¿La noticia confirma un nuevo producto de Google DeepMind?

No. Con la información disponible, el caso parece ser un análisis técnico sobre ingeniería de agentes, no un anuncio confirmado de producto.

Recibe Radar de IA todos los días

Las noticias de inteligencia artificial que importan — con nuestro prisma y siempre con las fuentes. Gratis.

Sin spam. Cancela cuando quieras.