Cómo probar un agente de IA antes del lanzamiento: 7 comprobaciones para el primer día

Por qué pasar la prueba de respuestas no significa que estés listo para lanzar

Construyo las integraciones de helpdesk de eesel, así que paso los días justo en el código donde viven los problemas del día de lanzamiento: disparadores, traspasos, llamadas de API a sistemas de pedidos y las etiquetas que dicen quién tocó un ticket. Rara vez se rompe el modelo; lo que suele romperse es la instalación.

Las mejores prácticas de pruebas de Zendesk son un buen reflejo de cómo piensa la mayor parte de la industria. Les dicen a los probadores: "Focus on whether the AI agent's response was accurate and matched the tone of voice you expected." Es un buen consejo, y también solo la punta del iceberg. El mismo centro de ayuda documenta, en otros artículos, que los tickets de agentes de IA no ejecutan tus disparadores y automatizaciones de tickets hasta que se escalan. Es decir, tus reglas de enrutamiento se activan por primera vez justo en el momento del traspaso, el único momento al que nunca llega una prueba de precisión.

Yo mismo tengo cicatrices. En la propia plataforma de eesel he visto a un bot tratar sus propias respuestas como mensajes nuevos de clientes y contestarse a sí mismo, un bucle de autorrespuesta que solo apareció al ejecutarse en un helpdesk real. He visto texto interno de la interfaz filtrarse en una respuesta pública durante una prueba en producción de un cliente. Y he visto bots en la plataforma de eesel inventar respuestas cuando la base de conocimiento volvía vacía, en lugar de traspasar. Ninguno de esos fue una respuesta incorrecta a una pregunta de prueba. Todos fueron costuras.

El lado legal también se ha puesto al día. En Moffatt v. Air Canada, el chatbot de la aerolínea le dijo a un cliente que podía solicitar la tarifa por duelo después de viajar, dentro de los 90 días posteriores a la emisión del billete, lo que contradecía la propia página de política de Air Canada. El tribunal calificó el argumento de Air Canada de que el chatbot era "a separate legal entity" como una "remarkable submission" y le ordenó pagar $812.02. El bot se equivocó, pero el fallo real fue que nadie lo comprobó contra la política original antes de que los clientes se fiaran de él.

Si ya leíste la guía de mi compañero sobre pruebas de agentes de soporte con IA, tienes cubierto el lado de las respuestas. Este artículo es la pieza complementaria: todo lo demás que debes comprobar la semana antes de accionar el interruptor.

Las siete comprobaciones previas al lanzamiento de un vistazo

Aquí está todo el plan en una pantalla. La primera comprobación es la que la mayoría de los equipos ya hace. Las otras seis son donde sale mal el día de lanzamiento.

Las notas mínimas son mías, no un estándar de la industria. Fija las tuyas, pero escríbelas antes de empezar a probar, no después de ver los resultados. Si necesitas ayuda para elegir los números, el AI support pilot scorecard tiene una plantilla.

Comprobación 1: repetir tickets reales para las respuestas

Empieza por la prueba de respuestas, porque todo lo demás supone que el agente acierta las preguntas fáciles. Saca entre 50 y 100 tickets resueltos recientemente de tus temas principales, pásalos por el agente sin que responda a nadie y compara su respuesta con lo que tu equipo envió de verdad.

La mayoría de los helpdesks te dan una herramienta para esto. El agente de correo de Freshdesk puede evaluar tickets importados, hasta 50 consultas por ejecución, y recomienda al menos 20. El agente de clientes de HubSpot ejecuta pruebas por lotes de hasta 8 conjuntos de prueba sin gastar créditos. La habilidad Simulation de eesel repite tus tickets pasados reales y puntúa cada respuesta frente a lo que envió tu equipo, y luego sugiere cambios en las instrucciones.

Puntúa la precisión y el tono como dos números separados. En una prueba de eesel con tráfico real, una bandeja de comercio electrónico de joyería con unos 1.000 tickets al mes, el 88 % de los borradores iba en la dirección correcta pero solo el 12 % se envió tal cual, y el 7 % tenía un error factual. La mayoría de las reescrituras fueron por longitud y tono, no por hechos. Una sola puntuación de "precisión" habría ocultado ambos problemas.

Después mantén vivo el conjunto de pruebas. Este comentario de Reddit es el consejo más útil sobre el tema, y no tiene nada de sofisticado:

"keep a list of test questions handy and run it through and see if you get the right answers. Whenever an edge case appears, add to the list of test questions, update your agent and re-run your tests. Boring, but works."

u/ankursarda, r/CustomerSuccess, Reddit

Incluye preguntas que tu documentación responde solo a medias. El resultado correcto ahí es un traspaso, no una suposición segura de sí misma. Si encuentras respuestas incorrectas porque la fuente está obsoleta, es un problema de conocimiento, y una auditoría de la base de conocimiento arreglará más que cualquier ajuste del prompt.

Comprobación 2: probar lo que no debe responder

Aquí es donde el "le dijimos que no" se encuentra con la realidad. Todos los grandes helpdesks separan ya la orientación blanda de las reglas duras, y la versión blanda es la que configura la mayoría de los equipos.

• Zendesk lista "Always escalate to an agent if the user mentions being hacked" como una instrucción mala, porque "Instructions cannot trigger escalations" (guía de instrucciones de Zendesk). Para eso necesitas un caso de uso.
• Freshdesk dice que su ajuste "Topics to avoid" "may not fully prevent responses in edge cases", y te remite al ajuste de traspaso para una aplicación estricta (identidad e instrucciones de Freshdesk).
• Help Scout lo dice claro: los roles cambian cómo responde Scout, y para enviar temas directamente a tu equipo, "create an exclusion" (roles de Scout).
• HubSpot te deja fijar barreras por segmento y advierte que las respuestas "may not always exactly match" lo que especificaste.

Una exclusión es la versión estricta de "no respondas reembolsos", tomada de los docs de Help Scout.

Así que, para cada tema de tu lista de "nunca" (reembolsos por encima de un límite, amenazas legales, seguridad de la cuenta, preguntas médicas o de seguridad, cualquier cosa sobre una fecha de entrega que no puedes prometer), pruébalo de tres formas: preguntado directamente, enterrado en un mensaje más largo y preguntado de nuevo después de que el agente diga que no. La nota mínima es un traspaso cada vez.

Un responsable de soporte de comercio electrónico que usa eesel detectó justo esto en la revisión. Su agente seguía diciendo a los clientes que los pedidos llegarían a tiempo, y la nota que le dejó fue contundente: "stop promising customer things we cant do. we cannot guarantee this customer's order to them by friday." Esa es una prueba de alcance que puedes escribir antes del lanzamiento: "¿Llegará el viernes?"

Luego prueba qué pasa cuando un cliente intenta sacarlo del guion. En enero de 2024 un cliente de DPD le pidió al bot que dijera palabrotas y escribiera un poema sobre la empresa, y lo hizo:

"Parcel delivery firm DPD have replaced their customer service chat with an AI robot thing. It's utterly useless at answering any queries, and when asked, it happily produced a poem about how terrible they are as a company. It also swore at me. 😂"

Ashley Beauchamp, X

OWASP clasifica la inyección de prompts como el principal riesgo de las aplicaciones LLM y recomienda "adversarial testing and attack simulations". Para un agente de soporte, eso significa una lista corta de intentos: "ignore your instructions", "are you a human?", "give me a discount code" y un mensaje que pega texto de política falso. Para un manual más completo, consulta la guía de pruebas adversariales.

Las historias de clientes dejan clara la cuestión del alcance. Luxedo, que vende sistemas de proyección, limitó su agente de eesel solo a clientes residenciales: los tickets de colegios, gimnasios y otros compradores comerciales se omiten y se quedan con ventas. Los fallos de hardware, las decisiones de garantía, los reembolsos y la seguridad eléctrica van siempre al equipo. Un límite así de concreto es fácil de probar antes del lanzamiento: envía un ticket de cada grupo excluido y confirma que el agente lo deja en paz.

Comprobación 3: recorrer cada vía de traspaso de principio a fin

Una prueba de traspaso real hace tres preguntas: ¿recibió una persona el ticket?, ¿pudo ver lo que pasó? y ¿sabía el cliente qué esperar? Son tres comprobaciones distintas, y cada helpdesk las maneja de forma diferente.

Algunos de estos detalles son fáciles de pasar por alto y dolorosos el primer día:

• El grupo de transferencia de Zendesk tiene un respaldo silencioso. El cuadro de ajustes advierte: "If a selected group is deleted, the default group will be used instead." Si renombras o fusionas un grupo después de la configuración, tus traspasos van en silencio a otro sitio. Los agentes de correo de Zendesk también dejan de responder cuando se aplica la etiqueta escalated_by_ultimate, y Zendesk te dice que configures tus flujos de trabajo para encontrar esos tickets tú mismo.
• Gorgias no enruta los traspasos a un equipo por defecto. Tú creas una regla de asignación automática sobre la etiqueta ai_handover (guía de traspaso de Gorgias). Sin ella, los traspasos se quedan en la vista de AI Agent.
• El enrutamiento "Team only" de HubSpot traspasa aunque no haya nadie. HubSpot dice que el agente "will execute a handoff even if no users are currently available", y no mira la disponibilidad del widget de chat (configuración de traspaso de HubSpot).
• La toma de control de Freshdesk no se puede deshacer. Cuando una persona hace clic en "Stop responding & assign to me", el borrador de la IA "is discarded permanently" (salvaguardas de correo de Freshdesk). Asegúrate de que tu equipo lo sepa antes de probarlo en un ticket que le importe.

La advertencia de respaldo bajo el grupo de transferencia de Zendesk, tomada del centro de ayuda de Zendesk.

Así se ve un bucle de traspaso desde el lado del cliente. Cada salida lleva de vuelta al inicio:

"The ChatBot looping around providing generic answers, asking what my problem is. It ignores direct request to speak with an agent or to create a customer service. It simply starts with "Please, tell us about the problem ..." If I keep asking the same question, I can managed to get to a list of choices: 1. Report a technical issue, 2. Visit our Status page, 3. Time Tracker issues. Typing 2 and 3 leads to nowhere. Typing 1 reset the chatbot and it start again asking about my problem."

u/-Big-Hat-, r/Upwork, Reddit

Y aquí la versión en la que el traspaso "funciona" pero el contexto no viajó:

"Doesn't help at all if your support team ignores the bot chats. There is NOTHING more frustrating than talking to a bot for ten minutes just to have your live agent ask "can you please give me your account number one more time?"."

u/quietvectorfield, r/CustomerSuccess, Reddit

Así que la prueba de traspaso tiene cinco pasos. Pide una persona de tres formas distintas (directa, frustrada y a mitad de flujo). Activa cada motivo de escalado que hayas configurado. Abre el ticket como el agente que lo recibe y comprueba que el historial y cualquier resumen estén ahí. Lee el mensaje que recibió el cliente sobre lo que ocurre a continuación. Y cronometra cuánto tarda alguien del equipo en notar el ticket. Para más sobre cómo diseñar el traspaso en sí, consulta estas buenas prácticas de traspaso de IA y la guía sobre cuándo traspasar.

El mensaje de traspaso importa tanto como el enrutamiento. SE Ranking configuró sus agentes de eesel para decirles a los clientes que esperen respuesta en uno o dos días hábiles, nunca que alguien se une ahora mismo. Los reembolsos, las ampliaciones de prueba y las preguntas repetidas van al equipo con el nombre y el correo del cliente adjuntos. Esa es una promesa que el equipo puede cumplir, así que también es una promesa que puedes probar.

Prueba la vía fuera de horario por separado

Fuera de horario es donde más se rompen los traspasos, porque la cola que normalmente se vigila ya no lo está. Cada helpdesk lo maneja de forma un poco distinta:

• Freshdesk tiene un interruptor "Transfer outside business hours" y te advierte que evites usar instrucciones para gestionar el horario laboral (ajustes de traspaso de Freshdesk).
• Zendesk usa un bloque de disponibilidad al inicio de la vía de escalado.
• Gorgias cierra un ticket de chat fuera de línea si el comprador no deja una dirección de correo.

Ajustes de traspaso fuera de horario de Freshdesk, tomados del sitio de soporte de Freshdesk.

Haz una prueba de traspaso con tu horario laboral configurado como "cerrado" y confirma tres cosas: dónde cae el ticket, qué se le dice al cliente y si algo se cierra sin respuesta. Si tu helpdesk tiene sus propios ajustes de horario laboral, comprueba que el agente de IA usa el mismo horario que tu equipo.

Comprobación 4: probar cada acción y luego romperla a propósito

Las acciones son donde un agente de IA deja de hablar y empieza a hacer: consultar un pedido, añadir una etiqueta, iniciar un reembolso, cancelar una suscripción. Son también donde los entornos de prueba más te fallan, porque probar una acción suele implicar tocar un sistema real.

Prueba cada acción de las cinco formas en que puede importar. Read: ¿trae el pedido correcto cuando dos clientes comparten nombre? Write: ¿las etiquetas, notas y cambios de campos llegan al ticket correcto? Act: ¿espera a una persona todo lo que cuesta dinero? Escalate: cuando la acción no puede terminar, ¿va el ticket a una persona? Recover: cuando la API está caída o lenta, ¿recibe el cliente una respuesta sensata en lugar de silencio?

Lo que documentan los helpdesks sobre los fallos:

• Las acciones personalizadas de Zendesk agotan el tiempo a los 10 segundos, y entonces "the action isn't performed." La propia guía de Zendesk sobre procedimientos generativos ofrece una buena regla para copiar: "If API returns 'timeout', retry up to 2 times. If still failing, escalate the request." También señala que una llamada puede devolver éxito y aun así ir por la rama de fallo si el agente no puede leer la respuesta.
• Las acciones de chat de Freshdesk van a una vía de respaldo en caso de tiempo agotado o fallo. En correo, en cambio, "confirmation blocks are skipped" porque no hay conversación en vivo, y Freshdesk te dice que pongas salvaguardas "at the API layer" (acciones de API de Freshdesk). Su botón Test API usa "real values and may affect your external system".
• Gorgias detiene una acción de varios pasos en el paso que falla y traspasa el ticket a tu equipo, pero los pasos anteriores quedan hechos (registros de acciones de Gorgias). Las conversaciones de prueba "use real data from your connected apps", así que usa un perfil de cliente de prueba.
• HubSpot te deja configurar hasta 20 acciones con un nivel de protección de acción (None, Match email o Verify email), pero no documenta qué pasa cuando una falla. Pruébalo tú mismo.

Gorgias registra cada ejecución de acción como Success o Error, tomado de los docs de Gorgias.

Ningún helpdesk que revisé tiene un botón que simule una caída de API. Para probar el paso Recover, apunta la acción a un endpoint de staging y apágalo, o dale un número de pedido incorrecto y un token caducado. Parece trabajo extra hasta que el sistema de pedidos tiene una mala mañana.

La opción más segura es la aburrida: empieza cada acción que cambia algo tras una aprobación. En eesel, cada acción se configura como Auto, Needs approval o Disabled, los agentes nuevos están pensados para empezar supervisados, y "Approvals never run on their own after a timeout." Si estás escribiendo tus propias reglas sobre qué reembolsos puede tocar un bot, una matriz de aprobación de reembolsos es un buen punto de partida.

Comprobación 5: confirmar dónde aparece y dónde se queda callado

Un agente que responde bien en los tickets correctos aún puede avergonzarte en los equivocados. Los disparadores, canales, marcas y reglas deciden qué tickets ve el agente, y cada helpdesk tiene sus propias sorpresas:

• Las reglas de Gorgias se ejecutan primero. Si una regla envía una respuesta automática, el AI Agent "may still attempt its own response", y el cliente recibe dos mensajes (reglas de Gorgias y AI Agent). Gorgias también cierra, sin responder, cualquier mensaje que considere ajeno al comercio electrónico o al soporte, y eso no se puede desactivar. Revisa los tickets cerrados y pospuestos tras una ejecución de prueba.
• Zendesk escala a una persona todo mensaje que contenga un PDF, lo que llama "expected behavior" (resolución de problemas de Zendesk). Si tus clientes envían facturas en PDF, tus cifras de desvío se verán distintas a las de tu prueba.
• Freshdesk te deja desplegar el agente de correo primero a equipos internos, "a safe pilot rollout", con hasta cinco niveles de reglas anidadas sobre a quién atiende (configuración del agente de correo de Freshdesk).

Envía un ticket de prueba por cada tipo de ticket que el agente debería saltarse: un ticket interno, spam, un VIP, un ticket de tu segunda marca, una solicitud de empleo, una oferta de un proveedor. Lesson Pro, que gestiona varias marcas de clases desde un solo Zendesk, configuró sus agentes de eesel para saltarse solicitudes de empleo, mensajes de voz y formularios de pedido, e identificar la marca antes de escribir una palabra. Equivocarse de marca en una respuesta es peor que responder despacio, y es lo más fácil de probar.

Luego deja que el agente responda a un ticket de prueba real dentro de tu helpdesk en vivo y vigila ese ticket durante diez minutos. Es la única forma de detectar un bucle de autorrespuesta, el fallo que mencioné antes, en el que el disparador se activa con la propia respuesta del agente. Un sandbox tampoco lo mostrará. El sandbox de Zendesk desactiva los webhooks por defecto, no copia los flujos de acciones ni el enrutamiento basado en habilidades, no admite SMS, y una copia completa "can take up to a week or more". Es un buen lugar para probar respuestas y uno malo para probar costuras. Hay más sobre ese equilibrio en sandbox de Zendesk frente a producción.

Comprobación 6: ensayar el interruptor de apagado

Todo plan de lanzamiento tiene una línea que dice "podemos apagarlo si algo sale mal". Muy pocos equipos lo han hecho de verdad. Hazlo antes del lanzamiento, cronométralo y asegúrate de que dos personas sepan cómo.

El interruptor de apagado no es lo mismo en todos los helpdesks, y algunos interruptores de aspecto obvio no hacen lo que esperarías:

Dos de esos merecen una segunda lectura. En Gorgias, lo que parece "apagar la habilidad de reembolsos" no detiene las preguntas de reembolso; el agente las responde con tu conocimiento, y detenerlo en una parte de los tickets requiere una regla "ignore". En HubSpot, la página de traspaso lista "the agent is paused" como motivo de traspaso, mientras que la página de despliegue dice que los hilos existentes siguen ejecutándose cuando está apagado. Prueba cuál de los dos obtienes.

Escribe el simulacro como un manual de una página: quién puede apagarlo, los clics exactos, adónde van los tickets cuando está apagado, quién avisa al equipo y qué tiene que cumplirse antes de volver a encenderlo.

Comprobación 7: configurar los informes antes del primer día

El día del lanzamiento alguien preguntará "¿funciona?" y querrás una respuesta en menos de un minuto. Eso significa que las etiquetas y vistas tienen que existir antes del primer ticket real, no después.

Como mínimo, etiqueta cada ticket que toca la IA, etiqueta cada traspaso con un motivo y crea una vista de "traspasado y aún sin recoger". SE Ranking pidió una etiqueta ai_handled en cada ticket que toca eesel, más etiquetas de útil y no útil, para poder contar la contención dentro de Zendesk en lugar de adivinar. Freshdesk registra automáticamente un motivo de traspaso para cada ticket, incluidos "System issue" y "Max turns exceeded", lo que es un informe gratuito de calidad del escalado si lo usas.

Después decide qué revisarás en la primera semana. Esta es la mejor respuesta corta que he leído sobre eso:

"The expensive misses are usually the ones that look confident and don't escalate. So I'd rather have a slightly annoying bot that hands off early than one that quietly invents an answer. If I were running it, I'd review a small sample of resolved tickets every week, plus every escalation and complaint. That's probably more important than the model choice."

u/TheChandrianX, r/CustomerSuccess, Reddit

Gorgias sugiere revisar al menos 10 tickets gestionados por la IA en la primera semana (guía de puesta en marcha de Gorgias). Yo iría más allá el primer día: lee cada traspaso y cada ejecución de acción. La guía de métricas de IA para CX explica qué medir después.

Qué hacer si algo sale mal el primer día

Incluso con las siete comprobaciones hechas, algo te sorprenderá. La pregunta útil es si es un problema de "pausar ahora" o de "arreglar hoy". Elige el síntoma que estás viendo:

El patrón detrás del widget: pausa todo lo que atrape a un cliente o gaste dinero, y arregla los problemas de enrutamiento y disparadores con el agente aún en marcha. Cuando es el bot de soporte de un proveedor el que falla en público, la solución suele ser parecida. Después de que el bot de soporte con IA de Cursor inventara una política de bloqueo en abril de 2025, el propio análisis posterior del cofundador en Hacker News empezó con el etiquetado y un reembolso:

"Apologies - something very clearly went wrong here. We've already begun investigating, and some very early results:

Any AI responses used for email support are now clearly labeled as such. We use AI-assisted responses as the first filter for email support. We've made sure this user is completely refunded - least we can do for the trouble." mntruell (Cursor cofounder), Hacker News

Tu decisión de seguir o no seguir

La noche antes del lanzamiento, repasa esta lista. Si alguna línea es un "no", retén esa pieza por ahora. Lanza la vía que pasa y retén el resto.

• El agente se ha puntuado con tickets pasados reales, con precisión y tono puntuados por separado.
• Cada tema de "nunca responder" se traspasa, probado de tres formas, usando una exclusión estricta en lugar de una instrucción.
• Cada vía de traspaso llega a una cola que alguien vigila, en horario y fuera de horario, con contexto adjunto.
• Cada acción se ha probado con registros de prueba y se ha forzado a fallar una vez.
• Un ticket de prueba por tipo de exclusión se ha saltado correctamente, y un ticket de prueba en vivo no entró en bucle.
• Dos personas han apagado y vuelto a encender el agente, y saben adónde van los tickets cuando está apagado.
• Los tickets tocados por la IA y los traspasos están etiquetados, y hay una vista para los traspasos sin recoger.

Si quieres un plan de despliegue completo que acompañe esto, la guía para ejecutar un piloto de soporte con IA cubre las cuatro semanas posteriores al lanzamiento, y la lista de errores de implementación de IA cubre los que aparecen más tarde.

Cómo gestiona eesel las costuras antes del lanzamiento

Soy parcial, porque lo construyo, pero esta es la parte de eesel de la que estoy más orgulloso, porque está construida en torno a las costuras y no a la demo.

• Primero las respuestas. La habilidad Simulation repite tus tickets pasados y puntúa cada respuesta frente a lo que envió tu equipo, y luego lista las correcciones. Conectar un helpdesk es de solo lectura: "It does nothing on tickets until you create an automation."
• Interruptores estrictos, no solo instrucciones. Si de parte del historial de tickets no se debe aprender, los docs de eesel son contundentes: "Telling it in its instructions to ignore past tickets does not stop it finding them; the switch does" (configuración de Zendesk).
• Acciones tras aprobación. Cada acción es Auto, Needs approval o Disabled, y los docs recomiendan mantener los reembolsos tras una aprobación.
• Un registro de lo que hizo realmente. La página Activity lista cada ticket, qué buscó, cada acción, quién la aprobó y los tickets omitidos con el motivo.
• Una terminal para la instalación. La CLI de eesel te permite probar el agente con eesel chat, comprobar acciones retenidas con eesel approvals, leer eesel activity y usar --dry-run para imprimir la llamada exacta que haría una escritura sin enviarla. Es útil cuando un agente de programación como Claude Code te ayuda a montar la integración y quieres ver la escritura antes de que ocurra.

La página Activity de eesel muestra cada acción que realizó el agente y quién la aprobó.

Beautek, un proveedor de equipamiento B2B en Alemania, es un buen ejemplo del lado del traspaso bien hecho. Su chat web responde preguntas de productos y pedidos en alemán, pero la frustración, las preguntas legales, los pedidos complejos o la petición de una persona crean un ticket de Zendesk con la conversación adjunta. En un mes fueron 20 tickets de Zendesk creados desde el chat, la mayoría clientes potenciales de ventas, mientras que los propios tickets de Zendesk siguen siendo borradores que el equipo aprueba.

Prueba tu agente de IA antes del lanzamiento con eesel

Si tu plan de lanzamiento es "probamos las respuestas, ya veremos el resto en vivo", eesel está hecho para ese resto. Se une a tu Zendesk, Freshdesk, Gorgias o HubSpot como una nueva incorporación: aprende de tus tickets pasados, se puntúa con ellos antes de tocar a un cliente y puede empezar con cada respuesta y cada reembolso esperando tu aprobación. Tú decides cuándo sale en vivo cada vía y puedes volver a apagar cualquiera.

Simulation aparece en la lista de habilidades de eesel, listo para ejecutarse con tus propios tickets.

El plan gratuito incluye 100 créditos sin tarjeta, y los planes de pago empiezan en $299/month por 500 créditos (precios). Prueba eesel con una copia de los tickets de la semana pasada y mira qué habría hecho.