AgentOps
Cómo elegir una plataforma para gestionar agentes de inteligencia artificial en la empresa
Un cliente de una operadora informa que su conexión está cayendo. Antes de derivar el caso, el representante debe revisar el registro, comprobar si hay una falla en la región y consultar el historial técnico del acceso. Hoy, ese trabajo puede exigir consultas en pantallas distintas e intercambio de mensajes con operaciones.
La empresa decide probar agentes de inteligencia artificial para reunir esa información y preparar la derivación. Un agente consulta el registro, otro verifica las señales técnicas y un tercero organiza el caso. El representante recibe el caso con la información disponible y aprueba las acciones que requieren su participación.
Para elegir una plataforma que acompañe a esos agentes, la operadora puede llevar ese mismo escenario a la demostración del proveedor. La prueba debe mostrar cómo llega la información al soporte, qué ocurre cuando una consulta falla y cómo el equipo hace seguimiento del trabajo realizado.
Este artículo utiliza ese escenario ilustrativo para convertir los criterios de elección en comprobaciones prácticas. Los ejemplos no describen un despliegue real ni suponen que toda plataforma ofrece las mismas funciones.
Qué llevar a la demostración
El primer paso es describir la atención que se desea mejorar. El equipo puede seleccionar casos anteriores, retirar los datos personales y registrar qué consultas fueron necesarias, quién participó y qué caracterizó una derivación correcta.
Ese material permite comparar la rutina actual con el flujo apoyado por agentes. El objetivo puede ser reducir el tiempo de preparación del caso sin aumentar las derivaciones incorrectas. No hace falta inventar una meta de mercado. La referencia debe venir de los datos y de las necesidades propias de la operación.
Una plataforma debe evaluarse por el trabajo que ayuda a concluir, considerando el esfuerzo necesario para mantenerla en operación.
En la demostración, el proveedor debe aclarar si la solución crea los agentes, acompaña agentes externos o combina esas funciones. Si la empresa ya posee un agente que consulta el registro, conviene usarlo en la prueba y observar el esfuerzo para incorporarlo.
Esa elección se relaciona con el AgentOps y la operación de agentes en producción. AgentOps, abreviatura de Agent Operations, reúne prácticas para acompañar el comportamiento y la operación de los agentes a lo largo del tiempo. Aquí, el foco es comprobar cómo esas prácticas funcionan en la atención elegida para la evaluación.
Inventario y responsabilidad a lo largo del ciclo de vida
El seguimiento de las ejecuciones debe estar asociado a una visión de los agentes que la empresa mantiene en operación. En la orientación de gobernanza del Cloud Adoption Framework, Microsoft recomienda un registro organizacional que identifique responsable, finalidad, plataforma y alcance de acceso de cada agente, además de una identidad distinta para atribuir sus acciones [3].
En la demostración, pida localizar los tres agentes de la atención e identificar quién responde por cada uno. El agente que consulta el registro debe tener accesos distintos del que organiza el caso. El equipo debe poder comprobar esos permisos y saber cómo se actualizará el registro cuando haya un cambio. El proveedor debe mostrar qué se descubre automáticamente, qué llega por integración y qué exige registro manual.
A continuación, retire el permiso de consulta de un agente en el entorno de prueba e intente ejecutar la tarea de nuevo. Observe si el acceso queda bloqueado, dónde aparece el intento y quién recibe la información necesaria para actuar. Un nombre en el inventario no demuestra, por sí solo, que los permisos se están aplicando. Esa relación entre gestión común y herramientas distribuidas se discutió en el artículo sobre el AI Control Plane, el plano de control para agentes de distintas plataformas.
Las integraciones deben funcionar también en las excepciones
La conexión inicial con un sistema muestra solo parte de lo que hay que evaluar. Una consulta puede devolver datos incompletos, una respuesta puede demorar y un cambio puede concluir sin que la confirmación llegue al agente.
En el caso de la operadora, interrumpa la confirmación después de que el sistema de casos haya recibido la solicitud. Si el agente repite la operación, ¿abrirá otro caso para el mismo asunto? Pida que demuestren cómo la integración evita o identifica la duplicidad y cómo el agente descubre qué registro debe usar.
La prueba de integración debe mostrar qué ocurre cuando el flujo deja de seguir el camino esperado.
También es importante separar lo que ofrece la plataforma de lo que dependerá de configuración, desarrollo adicional o recursos de los sistemas conectados. Esa distinción hace más realista la estimación del despliegue y ayuda a distribuir responsabilidades entre equipos y proveedor.
IBM, empresa de tecnología y consultoría, recomienda una capa de orquestación que coordine agentes entre plataformas y respete los límites de los procesos [4]. Como criterio de elección, conviene verificar la transferencia del trabajo entre etapas. Si el agente que consulta los datos concluye su parte, pero el agente de derivación falla, el equipo necesita saber qué queda pendiente y quién debe asumir la continuidad.
La demostración también debe aclarar cómo llega el contexto necesario a la siguiente etapa y cómo una persona recibe el caso cuando debe intervenir. El historial debe permitir retomar la atención sin obligar al cliente o al profesional a reconstruir todo desde el inicio. Esas son pruebas propuestas para la evaluación de la empresa, y su implementación depende de la arquitectura y de las integraciones disponibles.
En la práctica, la evaluación debe incluir un agente ya utilizado por la empresa, cuando sea posible. Eso permite verificar el esfuerzo para incorporarlo al entorno de gestión, qué información queda disponible y qué limitaciones permanecen.
Visibilidad sobre la ejecución y sobre el entorno
Cuando varios agentes participan en una atención, registros aislados pueden dificultar la investigación. El equipo necesita relacionar la solicitud inicial con las consultas realizadas, las herramientas activadas y el resultado producido.
La documentación de arquitectura de Google Cloud, plataforma de computación en la nube de Google, incluye observabilidad y evaluación entre los componentes a considerar en aplicaciones agénticas [1]. Al seleccionar una solución, esa orientación puede traducirse en una prueba en la que el propio equipo reconstruye una ejecución y localiza la etapa en la que el proceso se desvió de lo esperado.
En el ejemplo de la atención, una información incorrecta en el registro exige una respuesta distinta de una falla en la consulta o de un error de derivación. La observabilidad de agentes de IA ayuda a comprender esas diferencias, siempre que los registros tengan calidad y puedan relacionarse entre sí.
Pida, por ejemplo, que un profesional de operaciones abra la ejecución e identifique si faltó información en el registro, si la consulta técnica falló o si la derivación se hizo de forma incorrecta. Después, verifique si alguien sin autorización puede consultar los datos personales registrados. Las dos pruebas ayudan a evaluar la utilidad de los registros y los límites de acceso.
El equipo necesita comprender tanto la ejecución del agente como las condiciones en las que actuó.
Cuando la actividad depende de infraestructura y servicios, AIOps, aplicación de inteligencia artificial a las operaciones de TI, puede complementar ese análisis. Al relacionar eventos técnicos con el trabajo de los agentes, puede ayudar a distinguir una falla del agente de un deterioro en el entorno. Esa combinación enriquece el contexto operativo, pero no es prerrequisito para adoptar AgentOps.
Autonomía con supervisión proporcional
Consultar el historial de un cliente y cambiar una configuración en producción tienen consecuencias distintas. Los controles deben acompañar el alcance y la reversibilidad de cada acción, permitiendo automatizar tareas rutinarias y reservar la intervención humana para situaciones que la justifiquen.
AWS, plataforma de computación en la nube de Amazon, recomienda asociar autonomía a supervisión humana proporcional y definir rutas de escalonamiento [2]. Para evaluar una plataforma, conviene probar una acción que exija aprobación y observar qué información llega a la persona responsable.
En la operadora, suponga que el flujo puede solicitar un cambio de configuración, pero depende de la aprobación de un profesional. La pantalla debe mostrar el cliente afectado, el cambio propuesto y la información que lo justifica. Rechace la solicitud y verifique si la acción sigue bloqueada. En otra ejecución, deje la aprobación sin respuesta y observe cómo se encamina el caso, sin presumir autorización por silencio.
Interrumpir nuevas acciones no significa deshacer automáticamente lo ya ejecutado.
Si el agente alteró un registro o envió una solicitud a otro sistema, la recuperación puede exigir una acción compensatoria o un procedimiento específico. La evaluación debe aclarar esos límites e identificar cómo el equipo recupera el control, preservando el registro de lo ocurrido.
Los cambios deben evaluarse antes y después del despliegue
Una plataforma se utilizará en un entorno que sigue cambiando. Nuevas instrucciones, herramientas o versiones de modelos pueden alterar el comportamiento de un agente que antes cumplía los criterios definidos por la empresa.
IBM recomienda incorporar evaluación al ciclo de AgentOps, con pruebas antes del despliegue y de forma continua en producción [4]. Para la selección de la plataforma, la implicación es verificar cómo se identifican los cambios y cómo sus resultados pueden compararse con una referencia anterior.
En la prueba de concepto, el equipo puede seleccionar casos representativos de la atención, incluyendo situaciones con datos incompletos o necesidad de derivación humana. Después de un cambio controlado, debe comparar la conclusión correcta de las tareas, el retrabajo y el consumo. Un empeoramiento tras el cambio debe distinguirse de variaciones en el perfil de las solicitudes.
En la atención de prueba, incluya un caso sin falla regional, otro con falla confirmada y un tercero con consulta no disponible. Tras cambiar las instrucciones del agente, verifique si continúa distinguiendo esas situaciones y si evita presentar la ausencia de información como confirmación de normalidad. La evaluación debe aclarar qué pruebas son nativas, cuáles dependen de herramientas externas y cómo los resultados se relacionan con la versión evaluada. También debe mostrar el procedimiento para retirar una versión problemática o volver a una configuración anterior, cuando eso esté soportado. Esa posibilidad no sustituye la recuperación de acciones ya ejecutadas en otros sistemas.
El artículo Cómo evaluar agentes de IA en producción profundiza la distinción entre una ejecución técnicamente exitosa y una tarea verdaderamente concluida. En la selección de la plataforma, esa distinción debe aparecer en las pruebas y en los informes presentados.
Costos relacionados con los resultados
La comparación financiera incluye licencias, integración, infraestructura, consumo de modelos y esfuerzo operativo. Una ejecución aparentemente barata puede exigir nuevos intentos y correcciones que eleven el costo del trabajo concluido.
Pida comparar dos atenciones que llegaron a la derivación correcta. En una, los agentes hicieron las consultas necesarias. En la otra, repitieron llamadas por una integración inestable. ¿El informe permite identificar la diferencia de consumo y su causa? ¿El equipo puede relacionar ese costo con la atención y con el agente involucrado?
Además del consumo de los modelos, contabilice el tiempo que el profesional dedica a revisar o corregir cada caso. El artículo Cuánto cuesta operar un agente de IA discute esos costos más allá de los tokens, las unidades utilizadas para medir el procesamiento de contenido en los modelos de lenguaje. Una reducción del gasto en modelos puede perder relevancia si aumenta el retrabajo.
También conviene verificar si los datos pueden separarse por agente, equipo o proceso, según la necesidad de la organización. Ese detalle ayuda a comprender los costos y a orientar mejoras. Los informes disponibles y sus limitaciones deben formar parte de la demostración.
Una prueba de concepto que ayude a decidir
La evaluación puede comenzar con un proceso delimitado, pocos usuarios y los sistemas necesarios para representar el flujo. El alcance debe bastar para observar una ejecución exitosa, una falla de integración y una acción dependiente de aprobación.
El guion debe definir con antelación los resultados esperados y las evidencias que se examinarán. Además de asistir a la demostración del proveedor, ayuda que el propio equipo investigue una ejecución, consulte los registros e identifique qué se concluyó. También debe verificar qué datos pueden exportarse y en qué formato, considerando la continuidad de la operación y un eventual cambio de solución.
Al final, la decisión puede orientarse por siete comprobaciones.
- Registro de los agentes, responsables y accesos, con actualización a lo largo del ciclo de vida.
- Integración y coordinación entre agentes, personas y sistemas, con esfuerzo de despliegue conocido.
- Capacidad de acompañar el proceso e investigar situaciones inesperadas.
- Funcionamiento de permisos, aprobaciones y mecanismos de intervención en los escenarios probados.
- Evaluación de cambios con casos de prueba y comparación de resultados entre versiones.
- Costos y resultados compatibles con el objetivo definido para la actividad.
- Acceso y exportación de los registros necesarios para la continuidad y la investigación.
La prueba de concepto debe producir evidencias que el equipo pueda usar para decidir y operar.
Esas pruebas no eliminan todas las incertidumbres. Permiten una elección más fundamentada y ayudan a definir los próximos pasos de expansión. La confianza para ampliar la autonomía de los agentes se construye también con la capacidad de comprender sus resultados, corregir problemas y mantener responsabilidades claras.
De la visión a la práctica: ARGUS
La evaluación de una plataforma debe mostrar cómo sus recursos ayudan a acompañar a los agentes en el proceso elegido por la empresa. ARGUS, plataforma de Inteligencia Operacional y Agéntica de Target Solutions, utiliza sus capacidades de AgentOps para apoyar la orquestación, el monitoreo, la observabilidad y la gobernanza de los agentes de IA.
Al conectar agentes, personas y herramientas en un contexto operativo compartido, ARGUS ofrece una perspectiva para comprender las ejecuciones y sus relaciones con la operación. La capa AI Gateway, que intermedia el acceso a modelos y servicios de IA, complementa esa propuesta al apoyar políticas de acceso y utilización de esos recursos. Cuando se combinan con capacidades de AIOps, los datos sobre los agentes pueden relacionarse con eventos de infraestructura y servicios, según las integraciones disponibles.
Una evaluación puede partir de un proceso de la empresa y verificar, en demostración, la adherencia de las capacidades disponibles a las necesidades de integración, seguimiento y supervisión. El alcance y los criterios de éxito deben acordarse para ese escenario.
Conozca las capacidades de AgentOps de ARGUS.
Sobre Target Solutions
Target Solutions lleva más de 15 años apoyando a organizaciones en la evolución de sus operaciones de infraestructura, monitoreo, observabilidad, automatización e inteligencia operacional. A lo largo de esa trayectoria, participó en proyectos en entornos complejos de telecomunicaciones, tecnología, gobierno, energía y grandes empresas, contribuyendo a aumentar la eficiencia operativa y la confiabilidad de los servicios.
Sobre el autor
Paulo Florêncio de Menezes es cofundador de Target Solutions y lleva más de 15 años en proyectos relacionados con infraestructura, monitoreo, observabilidad, automatización y operaciones de TI y telecomunicaciones.
Se graduó en Procesamiento de Datos por la Universidad Federal de Amazonas (UFAM), tiene MBA en Gestión Empresarial por la Fundación Dom Cabral (FDC) y Maestría Profesional en Economía por la Fundación Getulio Vargas (FGV).
En su investigación de maestría, desarrolló el IBEOP-IA (Índice Brasileño de Exposición Ocupacional Potencial a la Inteligencia Artificial), investigando la exposición potencial de las ocupaciones brasileñas a las capacidades de la IA mediante la combinación de datos ocupacionales, patentes de inteligencia artificial y técnicas de procesamiento de lenguaje natural.
Referencias
[1] Google Cloud. Choose your agentic AI architecture components. Documentación técnica. Consultado el 20 de octubre de 2026.
[2] AWS. Design principles. AWS Well-Architected Agentic AI Lens. Documentación técnica. Consultado el 20 de octubre de 2026.
[3] Microsoft. Gobernar y proteger agentes de IA en toda la organización. Cloud Adoption Framework. Secciones sobre plano de control, registro, identidad y ciclo de vida. Consultado el 20 de octubre de 2026.
[4] IBM. Scale AI agents for business. Recomendaciones sobre orquestación entre plataformas, evaluación en el ciclo de AgentOps y resultados empresariales. Documentación técnica. Consultado el 20 de octubre de 2026.