Elegir un socio para el desarrollo de agentes de IA: preguntas más allá de la demostración.

Una demostración puede parecer excelente hasta que se enfrenta a un entorno empresarial real. En uno típico, un agente encuentra información, redacta una respuesta y actualiza un registro en menos de un minuto, y parece listo para ser utilizado. Luego surgen numerosas cuestiones prácticas: ¿qué pasa si el registro está incompleto? ¿Podría el agente ver datos a los que el empleado no tiene acceso? ¿Repetirá la acción tras un tiempo de espera de la API? ¿Quién investiga cuando el cambio resulta incorrecto?

Esas preguntas determinan cómo se debe evaluar a un proveedor de desarrollo de agentes. La pregunta más importante no es cuál empresa cuenta con la demostración más fluida, sino cuál equipo comprende todo lo relacionado con ella. Los proveedores más sólidos ofrecen menos demostraciones impresionantes, pero plantean mejores preguntas sobre flujos de trabajo, permisos, integraciones, fallos y responsabilidades.

Qué cambió para 2026

Hace poco, las demostraciones se centraban en planificar tareas, utilizar herramientas o mantener conversaciones prolongadas. Esas habilidades son importantes, pero ya no distinguen a los equipos serios de los implementadores básicos. Los compradores ahora esperan que los agentes trabajen con CRM, almacenes de documentos, bases de datos, herramientas de gestión de tickets, aplicaciones internas y cadenas de aprobación.

Eso representa un problema más complejo. El agente debe comprender la tarea, obtener la información adecuada, elegir la herramienta correcta, respetar los permisos, registrar sus acciones y saber cuándo detenerse. Los proveedores más sólidos hablan menos sobre inteligencia autónoma y más sobre las condiciones de operación, y plantean preguntas como:

• ¿Quién inicia el flujo de trabajo?
• ¿Qué sistemas están involucrados?
• ¿Qué puede cambiar el agente?
• ¿Dónde necesita un empleado aprobar algo?
• ¿Cómo se recupera una tarea fallida?

¿Quién es el propietario del agente después del lanzamiento?

Estas preguntas son menos interesantes que una demostración en vivo, pero están mucho más cerca del trabajo que determina si un agente sobrevive en producción.

Comience con el flujo de trabajo

Los proveedores más competentes parten del trabajo y no del modelo. Pedir un agente de ventas es demasiado vago como punto de partida, mientras que un flujo específico es fácil de analizar: revisar un nuevo lead, buscar la cuenta, redactar un seguimiento, solicitar aprobación, actualizar el CRM. Tiene un desencadenante, pasos ordenados y un resultado que cualquiera puede ver.

Antes de comenzar el desarrollo, el equipo debe haber definido lo siguiente.

• El desencadenante que inicia el flujo de trabajo.
• La información que necesita el flujo de trabajo.
• Los sistemas a los que se conecta.
• Los puntos en los que se toman decisiones.
• Las acciones que están permitidas.
• Las aprobaciones que se requieren.
• Las condiciones que se consideran un fallo.
• Los criterios para la finalización.

En esta etapa también se determina si es necesario contar con un agente. Algunas tareas se adaptan mejor a la automatización fija, mientras que otras requieren recuperación de datos además de revisión humana. Un proveedor que recomienda la opción más simple cuando un comportamiento de agente abierto aporta poco valor está dando una señal útil de honestidad.

Las integraciones son más importantes que la ventana de chat

Las demostraciones favorecen la interfaz de usuario porque es fácil de mostrar, pero es en la capa de integración donde se invierte el verdadero esfuerzo. Un agente puede leer un registro de cliente, obtener una póliza, actualizar un ticket, verificar existencias, elaborar un informe o enviar un mensaje aprobado, y cada paso depende de que algún sistema empresarial funcione como se espera.

Los sistemas reales son poco cooperativos. Las credenciales caducan, las APIs se ralentizan, los registros desaparecen, dos aplicaciones devuelven datos diferentes, y una solicitud puede tener éxito sin que la confirmación llegue nunca al agente. Los proveedores más sólidos planifican esto antes del lanzamiento y abordan:

• la autenticación y el almacenamiento de credenciales,
• las verificaciones de permisos,
• los tiempos de espera de las solicitudes,
• las reintentos seguros,
• la prevención de acciones duplicadas,
• la finalización parcial de una tarea,
• el registro de actividades,
• la recuperación manual.

Una conversación impecable no puede compensar una integración poco fiable. Una vez que un agente comienza a modificar registros o a activar acciones, la calidad de esas conexiones forma parte del producto.

Los permisos muestran cómo se maneja el riesgo

Los permisos son una de las líneas divisorias más claras entre los equipos orientados a prototipos y aquellos orientados a la producción. Un prototipo suele ejecutarse con una cuenta de desarrollador que ofrece acceso amplio. Esto acelera la creación de la primera versión, pero plantea una pregunta clave: ¿qué acciones debe poder realizar el agente?

Un agente de soporte puede necesitar ver un pedido y redactar una respuesta. Probablemente no necesite todos los registros financieros ni la capacidad de emitir un reembolso elevado. Un proveedor competente debe definir:

• quién puede activar al agente,
• qué información puede obtener,
• qué herramientas puede usar,
• qué registros puede modificar,
• qué acciones requieren aprobación,
• qué condiciones deben detener el flujo de trabajo.

Estos límites forman parte del proceso operativo. Un documento de políticas almacenado en otro lugar no impedirá que un agente realice una acción para la cual técnicamente tenga permiso.

Conocimiento fiable

Muchos agentes empresariales dependen de documentación interna como manuales, contratos, tickets anteriores, procedimientos, políticas y archivos de clientes. Sin embargo, el hecho de utilizar dicha documentación no garantiza que las respuestas sean fiables. Todavía es necesario resolver cuestiones como la autoría, la actualidad y las reglas de conflicto: qué versión de un documento es válida, quién lo mantiene actualizado y qué debe hacer el agente cuando dos fuentes son contradictorias.

La capacidad de recuperar información de una amplia colección interna permite al agente obtener pasajes relevantes antes de responder o decidir su siguiente paso. La calidad es el factor clave, ya que una respuesta segura y bien redactada puede basarse aún en el documento incorrecto. Los revisores también se benefician al poder ver qué leyó el agente: cuando este propone algo importante, la persona que lo verifica debe poder examinar el material en el que se basa la propuesta.

Varios agentes no siempre son mejores

Los sistemas multiagente suenan impresionantes, pero a menudo son innecesarios. Un solo agente es suficiente cuando un flujo de trabajo utiliza unas pocas herramientas y sigue una secuencia manejable. Agregar más agentes implica más comunicación, más estados y más posibilidades de que algo salga mal.

Varios agentes tienen sentido cuando el trabajo requiere roles verdaderamente separados, por ejemplo:

• un agente recopila información,
• otro verifica los requisitos de la política,
• un tercero prepara la acción propuesta,
• una persona aprueba el último paso.

La pregunta importante no es si un proveedor puede crear un sistema multiagente, sino si la estructura adicional mejora el resultado. Un proveedor confiable puede explicar por qué existe cada agente, qué recibe, cómo fluye el trabajo entre ellos y qué ocurre cuando no están de acuerdo.

Manejo de fallos

Los demos siguen el camino sencillo, pero la producción rara vez lo hace, por lo que un proveedor debe ser capaz de manejar entradas complejas. Un plan de pruebas útil somete al agente a situaciones difíciles y verifica el resultado:

• una solicitud con detalles faltantes,
• una búsqueda que no devuelve nada,
• políticas que se contradicen entre sí,
• una aplicación posterior que ha dejado de funcionar,
• un usuario que solicita algo prohibido,
• una llamada a una herramienta dirigida al destino incorrecto,
• un envío duplicado de una solicitud,
• una tarea que no puede finalizar de forma segura.

Resolver cada caso no es el objetivo. A menudo, el comportamiento correcto es detenerse, hacer una pregunta para aclarar, intentarlo un número limitado de veces o derivar el caso a una persona. La fiabilidad incluye reconocer cuándo continuar sería un error.

El despliegue es más que alojamiento

El alojamiento es la parte más pequeña de una plataforma de despliegue. Una vez que los empleados comienzan a depender de un agente, los operadores deben supervisar su comportamiento y explicar los fallos. Esto requiere registros de las llamadas a las herramientas, el material recuperado, los pasos del flujo de trabajo, los resultados de las aprobaciones, los errores, los intentos de reintentar, la latencia, los costos y las transferencias de tareas a otras personas.

Si no existe tal registro, el equipo solo ve que el resultado final fue incorrecto y no puede determinar si el modelo, los datos, el conector o las instrucciones son los responsables. La versionado y la reversión de cambios cierran este ciclo. Los modelos, los prompts, las fuentes de datos y las reglas de negocio cambian constantemente, por lo que debe ser posible saber qué configuración produjo un resultado determinado y volver a una configuración conocida y funcional después de una actualización defectuosa.

Revisión humana acorde a la consecuencia

Requerir aprobación para cada acción del agente tiene poco valor y puede convertir un sistema útil en una versión más lenta del proceso anterior. Eliminar por completo la revisión humana genera el problema opuesto. La solución sensata es colocar la aprobación donde surgen las consecuencias. Un agente puede clasificar una solicitud, organizar información o redactar un borrador por su cuenta, mientras que un pago, un cambio en un contrato, una restricción en la cuenta o un mensaje con valor legal enviado fuera de la empresa aún pueden requerir la intervención de un empleado autorizado.

Los revisores también necesitan contexto. Un botón de Aprobar no sirve de mucho si la persona no puede ver la información de origen, la acción propuesta, el registro afectado y la razón por la que el caso le llegó. En flujos de trabajo sensibles, las prácticas de gobernanza deben vincular los permisos, las aprobaciones, la supervisión, la responsabilidad y el manejo de incidentes con las operaciones diarias.

Responsabilidad después del lanzamiento

Otra diferencia surge cuando se habla de implementación. Algunos proveedores consideran que el lanzamiento es la meta final, mientras que los equipos más sólidos analizan las semanas y meses posteriores. El entorno del agente sigue cambiando: los manuales se revisan, las APIs se sustituyen, el personal encuentra formas no planificadas de utilizar el flujo de trabajo, y aparecen tipos de solicitudes que el conjunto de pruebas original nunca abarcó.

Varias tareas requieren un responsable: supervisar el rendimiento, investigar las tareas fallidas, actualizar los conocimientos relevantes, aprobar los cambios en el flujo de trabajo, hacer un seguimiento de los gastos, responder a incidentes y decidir cuándo desactivar al agente. Un proveedor puede seguir ofreciendo soporte técnico, pero debe haber una persona designada dentro de la empresa que asuma esa responsabilidad. De lo contrario, los pequeños errores se acumulan hasta que el personal deja de confiar en el sistema.

Preguntas que hacer antes de elegir

La presentación impecable debe tener menos importancia que las respuestas a un puñado de preguntas directas.

• ¿Cómo planea el proveedor mapear el flujo de trabajo existente, y por qué se necesita un agente?
• ¿Qué sistemas se verán afectados, y cómo se transfieren los permisos de los usuarios a ellos?
• ¿Qué evita que la misma acción se ejecute dos veces, y qué ocurre cuando una herramienta falla?
• ¿Dónde debe firmar un humano para dar su aprobación?
• ¿Cómo se mantiene actualizada la base de conocimientos?
• ¿Cómo se mide el rendimiento en tiempo real, y quién se encarga del soporte una vez que el sistema está en funcionamiento?
• ¿Se puede rastrear y deshacer cualquier cambio?

Un proveedor competente responde en lenguaje sencillo y relaciona cada elección técnica con el flujo de trabajo propuesto.

El punto clave

Los buenos equipos no buscan aparentar total independencia. Construyen un sistema que realiza un trabajo útil dentro de límites definidos, el cual cuenta con un flujo de trabajo claro, integraciones fiables, acceso controlado, conocimientos confiables, pruebas de fallos realistas, revisión humana, monitoreo y responsabilidad posterior al lanzamiento. Una demostración impresionante es una buena forma de iniciar una conversación, pero una base deficiente para la decisión final.

Leer más

• Cómo construir un agente de voz AI en 2026: Arquitectura y stack — Una guía práctica para crear agentes de voz: diseños en cascada, semicascada y de voz a voz, el stack de cinco capas, ajuste de latencia, cumplimiento normativo, pruebas y costos.
• Notas prácticas: Lo que aprendí al enviar un agente de IA de producción con Google — Guía paso a paso de las Notas prácticas: Lo que aprendí al enviar un agente de IA de producción con Google: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
• Diseño de un proceso de pago basado en agentes: Autoridad delegada, cotizaciones obsoletas y reintentos — Guía de diseño de sistema para compras gestionadas por agentes: mandatos, ofertas caducadas, claves de idempotencia que fallan, comerciante registrado, rastreos de auditoría y una guía de puntuación.
• Orquestación de full stack para agentes de IA empresariales: seis capas más allá del modelo — Por qué los agentes empresariales fallan alrededor del modelo y no dentro de él: integraciones, estado, observabilidad, gobernanza y transferencias humanas, además de una verificación de madurez con diez preguntas.
• Interfaz de usuario generativa desde agentes ADK con el protocolo A2UI: mensajes y ejemplos — Aprenda cómo A2UI permite que un agente devuelva una interfaz de usuario interactiva en formato JSON, cómo difiere de AG-UI y cómo ejecutar localmente el ejemplo del buscador de restaurantes de Google ADK.