La mayoría de las empresas todavía lanza agentes de IA igual que antes lanzaba scripts. Alguien prueba ocho o diez prompts, concluye que las respuestas parecen razonables y el agente sale a producción frente a los clientes. Eso funcionaba cuando una prueba fallida producía un stack trace. No funciona con un agente que habla con sus clientes, lee sus sistemas y actúa en nombre de su empresa. Julio de 2026 dejó explícito el nuevo estándar: OpenAI anunció Presence el 22 de julio y lo describe como la integración de simulación previa al despliegue, evaluadores y barreras de protección en tiempo de ejecución dentro del propio producto de despliegue, y Google afirma que las capacidades agénticas de Google Threat Intelligence alcanzaron disponibilidad general ese mismo mes. Cada descripción de proveedor en este artículo es el posicionamiento de ese proveedor, no evidencia verificada, y así conviene tomarla en una conversación de compra.
Las pruebas de demostración fallan porque miden si la respuesta se lee bien y no si el agente llegó al resultado correcto. Un agente puede producir una respuesta fluida y convincente que es incorrecta en los hechos; correcta en los hechos pero fuera de su política de reembolsos; correcta en política pero llamando a la herramienta equivocada; o correcta en todo salvo que debió haber pasado la conversación a una persona tres turnos antes. Las cuatro se ven idénticas en una demostración. Todas parecen una buena respuesta.
El modelo mental correcto es la evaluación de un empleado, no el control de calidad de una funcionalidad. Usted no califica a una persona recién contratada en soporte por la gramática de sus correos. Le pregunta si resolvió el problema, si siguió la política sobre créditos y excepciones, si usó los sistemas correctos y si escaló lo que requería un supervisor. Esos cuatro ejes son los que revisan las herramientas de evaluación modernas. Los prompts manuales, además, solo muestrean la parte fácil y central de su distribución de solicitudes, y los agentes presentan regresiones por su cuenta cuando se actualiza la versión de un modelo o se refresca una fuente de conocimiento.
Probar un agente significa calificar si llegó al resultado correcto, si cumplió su política, si usó sus herramientas de forma adecuada y si escaló cuando debía, sobre un banco de escenarios que usted pueda volver a ejecutar cada vez que algo cambie.
Un banco de escenarios es un conjunto mantenido de conversaciones de prueba realistas con los resultados correctos definidos de antemano, y se construye extrayéndolo de sus propios tickets cerrados, escalamientos, quejas e intentos malintencionados, en lugar de inventar casos. La materia prima ya está en su sistema de tickets, en sus grabaciones de llamadas y en sus transcripciones de chat. Sus casos límite son específicos de su negocio, y ningún proveedor los trae incluidos.
Un escenario no es solo un prompt. Necesita el mensaje inicial y los seguimientos probables, el estado de la cuenta, el resultado correcto en lenguaje claro, las reglas de política aplicables, qué herramientas deben y no deben llamarse, y si el escalamiento es el final correcto. Escriba primero el resultado, o terminará calificando la respuesta contra sí misma.
Doscientos escenarios bien elegidos superan a dos mil recopilados sin criterio: aproximadamente la mitad de solicitudes comunes, un tercio de casos límite y el resto de situaciones de mayor riesgo que involucran dinero, datos personales o exposición legal. Constrúyalo junto con la base de conocimiento de la que se alimenta el agente, porque la mayoría de las respuestas incorrectas se debe a que el contenido de origen falta o está desactualizado, y no al modelo.
Los evaluadores revisan cuatro cosas distintas en cada escenario: si el agente llegó al resultado correcto, si cumplió su política, si usó sus herramientas de forma adecuada y si escaló cuando debía. Según OpenAI, los evaluadores de Presence revisan justamente ese conjunto. Califique cada eje por separado: un agente que resuelve correctamente el 90% de los escenarios pero incumple la política en el 4% de ellos no es un agente al 90%, y promediar ambas cifras oculta justo el problema que genera la queja. El escalamiento es el eje que los equipos prueban menos, porque una respuesta incorrecta pero fluida puntúa mejor en los otros tres ejes que un traspaso adecuado.
Los evaluadores suelen ser una mezcla: verificaciones deterministas para todo lo que se pueda comprobar por código (si se emitió un reembolso, si se llamó a la API correcta, si la transcripción contenía un compromiso no aprobado), y jueces basados en modelos para los criterios más subjetivos. Prefiera las verificaciones deterministas: son más baratas, más rápidas y no se desvían. Valide los jueces basados en modelos contra revisión humana sobre una muestra, porque un juez sin validar no es más que otro agente sin probar.
Sí: la simulación debe ejecutarse automáticamente con cada cambio y bloquear la liberación cuando los resultados caigan por debajo de los umbrales que usted fijó de antemano, igual que una prueba unitaria fallida bloquea una fusión. Una suite que se ejecuta cuando alguien se acuerda de ejecutarla no ofrece ninguna garantía. OpenAI dice que las simulaciones de Presence prueban al agente contra solicitudes comunes, casos límite y escenarios de mayor riesgo, que es la forma correcta de plantearlo, pero la compuerta es una decisión de proceso y no una función del producto: su pipeline de despliegue tiene que hacerla cumplir. Fije umbrales por eje, con tolerancia casi nula en política y escalamiento para los escenarios de mayor riesgo y una detención total ante cualquier llamada no autorizada a una herramienta, y publíquelos para que la discusión ocurra antes de la liberación y no después del incidente.
Las pruebas le dicen qué hizo el agente en los escenarios que usted imaginó; las barreras de protección intervienen en los que no imaginó. OpenAI describe las barreras de Presence como una intervención a mitad de la conversación cuando una interacción en vivo se sale de los límites definidos: una capa que puede detener, redirigir o escalar antes de que el agente actúe. La consecuencia es que las barreras de protección corresponden a quien es responsable de los sistemas a través de los cuales actúa el agente, no al equipo que escribe los prompts, porque ahí es donde una acción se puede bloquear de verdad.
El resto de los lanzamientos de julio de 2026 aterrizó en esa capa. Alterion anunció Draco el 16 de julio y lo posiciona como una plataforma de control en tiempo de ejecución que da a los líderes de seguridad, riesgo y cumplimiento una gobernanza aplicada sobre los agentes en distintas nubes, proveedores y endpoints. Codenotary afirma que AgentMon 3 adapta la política de seguridad en tiempo de ejecución al comportamiento observado del agente. Ambas descripciones son posicionamiento de proveedor y no resultados medidos, así que pida una prueba de concepto contra sus propios escenarios antes de creer cualquiera de las dos. Haga que la configuración de las barreras de protección forme parte de su programa de seguridad, acompañada de verdadera observabilidad sobre lo que hacen sus agentes en producción.
Las herramientas del proveedor cubren la maquinaria, es decir, la infraestructura de simulación, los marcos de evaluadores y la aplicación de controles en tiempo de ejecución, mientras que sus políticas, sus escenarios, sus datos de prueba, sus rutas de escalamiento y la evidencia que usted retiene siguen siendo suyos. La demostración no trazará esa línea, así que trácela antes del contrato.
La portabilidad importa más de lo que parece. OpenAI dice que Presence está en despliegue limitado con clientes empresariales seleccionados, y todas las plataformas mencionadas aquí se mueven rápido. Un banco que vive únicamente dentro de la consola de un proveedor pone sus costos de cambio en manos de ese proveedor. Mantenga las definiciones en control de versiones junto con el resto de la configuración de sus agentes.
Tres áreas asumen piezas distintas del programa (un responsable de negocio con nombre y apellido, riesgo o cumplimiento, y TI), y los primeros 90 días transcurren en tres etapas: definir y recolectar, calificar y poner compuertas, y luego barreras de protección y retroalimentación. El responsable de negocio define los resultados correctos y aprueba las reglas de política, porque solo esa persona puede decir qué es una respuesta correcta. El área de riesgo fija los umbrales y define qué cuenta como mayor riesgo. TI construye el entorno de pruebas y mantiene los controles en tiempo de ejecución. El modo de falla es que TI se quede con las tres piezas: los criterios de aprobación escritos por ingeniería se desvían hacia lo que resulta fácil de medir, y nadie fuera del equipo cree en los resultados. Recorra una lista de verificación de gobernanza de agentes de IA antes de la primera liberación, como lo haría con cualquier programa serio de automatización de procesos.
Mida el resultado, la política, el uso de herramientas y el escalamiento como tasas separadas, más la rapidez con que las fallas de producción se convierten en escenarios nuevos, y espere que los programas fracasen ahí donde un único puntaje promediado reemplaza la lectura de las fallas individuales. La métrica de vanidad es la tasa de contención, la proporción de conversaciones atendidas sin una persona. OpenAI informa que opera su propia línea telefónica de soporte en inglés con Presence y que el 75% de las llamadas entrantes se resuelve sin una persona. Es útil como punto de referencia, y es exactamente la cifra que se cita fuera de contexto: la contención sin una cifra de cumplimiento de políticas no dice nada sobre si esas resoluciones fueron correctas.
La falla más común es una suite que se mide pero nunca se lee: los equipos observan el puntaje agregado y dejan de investigar las fallas individuales en cuanto el número se ve aceptable. El puntaje es un resumen, las fallas son la información. Muy cerca le siguen los bancos que nunca crecen después del lanzamiento, los criterios de evaluación escritos por la misma persona que escribió el prompt, que producen pruebas que el agente aprueba por construcción, y tratar las mejoras sugeridas por el proveedor como cambios ya aprobados. Si usted está en una etapa anterior de este recorrido, el problema más difícil suele ser pasar de una demostración que funciona a algo que se pueda desplegar, y las pruebas son el puente.
Tenga un programa documentado de pruebas de agentes antes de comprar herramientas para agentes, porque las plataformas ahora asumen que usted llega con los escenarios, las políticas y los umbrales que esas plataformas ejecutan. Los lanzamientos de julio de 2026 no inventaron las pruebas de agentes, las volvieron obligatorias. La pregunta en su próxima conversación con un proveedor no es si necesita un programa de pruebas, sino si el suyo es lo bastante bueno para aprovechar lo que está comprando. Escribir las políticas, extraer de su propio historial los escenarios que romperán al agente y decidir quién aprueba es un trabajo que solo usted puede hacer. Si desea ayuda para construir ese programa, nuestro equipo de consultoría trabaja en sitio en todo Dallas–Fort Worth y entrega de forma remota para empresas en todo el país.
Infonaligy construye, prueba y gobierna agentes de IA en producción para empresas medianas, en sitio en todo Dallas–Fort Worth y de forma remota a nivel nacional.
Infonaligy construye y prueba agentes de IA en producción: bancos de escenarios extraídos de sus propios tickets, evaluadores atados a su política y compuertas de liberación conectadas a su pipeline. Hablemos del agente que está a punto de poner frente a sus clientes.
Infonaligy