Todos los agentes de IA quedan preciosos en una demo. Le das tres preguntas limpias, responde con una voz cálida y todos en la sala asienten. Luego lo pones frente a 4.000 llamadas reales al día y descubres que la demo era el 5% fácil. La producción es el otro 95%: la persona que llama con un niño gritando de fondo, el número de cuenta de 11 dígitos leído en desorden, el caso límite que tu prompt nunca previó y el momento en que el modelo inventa con total seguridad una política de reembolsos que no existe.
Este no es un artículo de "cómo crear un chatbot". Esta es la lista de verificación de despliegue que usamos realmente para poner agentes de voz en producción y mantenerlos ahí. Si ya superaste la demo y estás frente a la brecha que te separa de una operación fiable y a escala, este es el manual: los cinco modos de fallo reales, el diseño de escalado, guardrails, observabilidad, SLOs y un despliegue por fases que no se juegue tu CSAT el día del lanzamiento.
Por qué fallan los agentes de IA en producción (los 5 modos de fallo reales)
Los listículos te dirán que existen "11 desafíos de los agentes de IA". En la práctica, casi todos los incidentes en producción se reducen a uno de estos cinco:
- Picos de latencia. Un agente de voz que responde en 800 ms se siente humano. Uno que responde en 2,5 s se siente roto: quien llama le habla encima, lo interrumpe, cuelga. Lo letal no es la latencia media, sino la cola p95 cuando tu proveedor de LLM está bajo carga o una llamada a herramienta se bloquea.
- Alucinación / respuestas erróneas con seguridad. El modelo no dice "no lo sé". Dice lo incorrecto con fluidez. En una llamada telefónica no hay ningún enlace que hacer clic y verificar: quien llama simplemente lo cree, actúa en consecuencia y vuelve a llamar enfadado.
- Escalado roto. El agente debería haber transferido hace tres turnos, pero siguió intentándolo, o pasa la llamada a una persona sin contexto alguno, así que quien llama repite todo. Ambas cosas destruyen la confianza.
- Pérdida de estado / contexto. Las llamadas de varios turnos pierden el hilo: el agente olvida la cuenta que acaba de autenticar, vuelve a pedir el número de pedido, entra en bucle.
- Falta de observabilidad. Algo está saliendo mal y te enteras por un pico en tu tasa de rellamadas una semana después, porque nadie registró la transcripción turno a turno, las llamadas a herramientas ni las señales de confianza.
Fíjate en lo que no está en esta lista: la inteligencia del modelo. Los modelos de frontera son lo bastante inteligentes. Los fallos de despliegue son casi siempre fallos de infraestructura y de operaciones disfrazados de fallos del modelo.
Diseño del escalado: cuándo y cómo el agente transfiere a una persona
El escalado no es un plan B. Es una función de primer nivel que se diseña, se instrumenta y se ajusta. Si lo haces mal, todos los demás guardrails tienen fugas.
Cuándo escalar: dispara con señales, no con intuiciones:
- Petición explícita. Quien llama dice "agente", "representante", "persona". Inmediato, sin negociar, sin "déjame intentar ayudarte primero".
- Fallo repetido. Dos turnos consecutivos en los que el agente no logra resolver o quien llama se repite → escalar.
- Baja confianza. El paso de recuperación no devuelve nada fundamentado, o el clasificador de intención está por debajo del umbral → no adivines, transfiere.
- Intención de alto riesgo. Disputas de pago, cancelaciones, cualquier cosa legal o médica → derivar a una persona por política, incluso si el agente pudiera responder.
- Sentimiento. Frustración detectada o un tono de voz elevado → escalar antes de que se convierta en una queja.
Cómo escalar: lleva el contexto contigo. Una transferencia asistida significa que la persona recibe un paquete estructurado: identidad de quien llama (ya autenticada), intención, resumen de la transcripción, lo que el agente ya intentó y cualquier acción pendiente. Quien llama nunca debería repetir el número de cuenta que acaba de dar. Ese único detalle marca la diferencia entre "la IA me hizo perder el tiempo" y "la IA dejó esto perfectamente preparado".
Guardrails y fundamentación: cómo frenar las respuestas erróneas dichas con seguridad
No puedes salir de la alucinación a base de prompts. Se resuelve mediante ingeniería en tres capas:
- Fundamentación / RAG con rechazo. Las respuestas salen de tu base de conocimiento recuperada, no de la memoria del modelo. Y la regla dura: si la recuperación no devuelve nada relevante, el agente dice "déjame buscar a alguien que pueda confirmarlo", no una suposición plausible. Un rechazo es un éxito, no un fallo.
- Llamadas a herramientas acotadas, no texto libre, para las acciones. El agente no "decide" emitir un reembolso en prosa. Llama a una herramienta
refund()con argumentos tipados, tu backend valida la elegibilidad y la API —no el modelo— es la fuente de verdad. Las claves de idempotencia evitan el doble reembolso cuando una llamada se cae a mitad de una acción. - Validación de la salida. Antes de que el TTS lo pronuncie, comprueba la respuesta contra la política: nada de importes fuera de los rangos permitidos, nada de promesas de fechas que no puedes cumplir, nada de leer datos personales en una llamada sin autenticar.
El modelo mental: el LLM es un gran enrutador y conversador y un pésimo sistema de registro. Mantenlo fuera del registro.
Observabilidad: qué registrar, arnés de evaluación, pruebas de regresión
Si no puedes verlo, no puedes operarlo a escala. Registra cada turno: transcripción, confianza del ASR, fragmentos recuperados, llamadas a herramientas y sus resultados, latencia por etapa (ASR → LLM → TTS) y el motivo del escalado cuando se dispara uno. Vincúlalo todo a un ID de llamada que puedas reproducir.
Arnés de evaluación. Mantén un conjunto de referencia de llamadas reales —empieza con 50, crece hasta 500— etiquetadas con el resultado correcto. Cada cambio de prompt, cambio de modelo o actualización de la base de conocimiento se ejecuta contra ese conjunto antes de salir a producción. Estás midiendo la contención, la tasa de respuestas correctas, la tasa de rechazos falsos y la tasa de escalados no deseados.
Pruebas de regresión. El cambio peligroso es el que corrige la intención A y rompe en silencio la intención B. La puntuación con LLM-as-judge sobre el golden set detecta esto, pero calibra primero al juez frente a etiquetas humanas o solo estarás automatizando tus propios puntos ciegos. Controla los despliegues intención por intención: un cambio que provoca una regresión en "disputa de facturación" no se publica aunque mejore todo lo demás.
SLOs para un agente de voz (latencia, contención, CSAT)
Los objetivos vagos ("que funcione bien") no sobreviven al contacto con una guardia. Define SLOs numéricos y configura alertas sobre ellos:
| SLO | Objetivo | Por qué importa |
|---|---|---|
| Latencia de respuesta (p95) | < 1.2s | Por encima de esto, quienes llaman interrumpen y hablan por encima del agente |
| Tasa de contención | 60–75% | Resuelto sin un humano; una tasa demasiado alta suele significar que la escalada funciona mal |
| Tasa de respuestas correctas | > 95% | Medida sobre el golden eval set, no a ojo |
| Tasa de falsos rechazos | < 5% | Escalar de más se come el ROI |
| CSAT (posterior a la llamada) | ≥ la referencia humana | El agente debería igualar o superar tu cola de agentes humanos |
| Disponibilidad / respuesta de llamadas | 99.9% | Un agente de voz que no contesta es peor que no tener ninguno |
Fíjate en la tensión: la contención y la tasa de respuestas correctas tiran en direcciones opuestas. Perseguir un 90 % de contención suele significar que el agente está adivinando en llamadas que debería escalar. Ajusta para lograr una resolución correcta, no un desvío bruto.
Plan de despliegue por fases: shadow → asistencia → autónomo
No acciones el interruptor de golpe. Gana confianza en tres fases:
- Shadow (2–4 semanas). El agente funciona sobre llamadas reales pero no habla: escucha, genera lo que diría y tú lo puntúas frente a lo que hizo realmente la persona. Cero riesgo para quien llama, datos reales. Estás validando el arnés de evaluación y encontrando los modos de fallo antes de que estén en producción.
- Asistencia. El agente gestiona una porción estrecha y bien fundamentada —por ejemplo, estado del pedido y horarios de tienda— con escalada rápida para todo lo demás. Empieza con el 10 % del tráfico, vigila los SLOs y sube hasta el 100 % de esa intención antes de añadir la siguiente.
- Autónomo. El agente se encarga de extremo a extremo de todo el conjunto de intenciones validadas, con humanos en la cola de escalada y un panel de SLOs en vivo. "Autónomo" sigue significando monitorizado: nunca eliminas la observabilidad, solo dejas de vigilar cada llamada.
Cada fase tiene una puerta de salida ligada a la tabla de SLOs anterior. No avanzas porque hayan pasado dos semanas; avanzas porque los números lo permiten.
Cuándo NO usar Finn (la nota de honestidad)
Si tu volumen de llamadas está por debajo de unos pocos cientos al mes y cada llamada es genuinamente novedosa y de alto contacto —venta empresarial a medida, admisión de casos legales sensibles—, el ROI de un agente de voz es escaso y la carga de las escaladas puede superar al ahorro. La AI de voz rinde con volumen repetible: las mismas 20 intenciones, miles de veces. Si tus llamadas no se agrupan, contrata personas y vuelve a plantearlo cuando sí lo hagan. Preferimos decírtelo a venderte un despliegue que vas a desmontar en un trimestre.
Preguntas frecuentes
¿Cuánto se tarda en desplegar un agente de voz con AI en producción? Prevé entre 6 y 10 semanas para llegar a un despliegue autónomo a escala: de 2 a 4 semanas en modo shadow y, después, una ampliación escalonada del modo asistido por cada intención. Los equipos que se saltan el modo shadow lanzan más rápido y sufren regresiones más ruidosas.
¿Cuál es la mayor causa de fallos de los agentes de AI en producción? No es la calidad del modelo, sino la infraestructura y las operaciones. Las colas de latencia, la falta de grounding y las escalaciones rotas causan la gran mayoría de los incidentes. El modelo suele ser lo bastante inteligente; el sistema que lo rodea no está construido para el 95%.
¿Cómo evito que el agente se invente respuestas? Fundamenta cada respuesta en la recuperación de información, convierte la negativa a responder en una vía de éxito y encamina todas las acciones a través de llamadas a herramientas validadas en lugar de texto libre. Si la recuperación no devuelve nada, el agente escala: nunca adivina.
¿Qué SLO debo fijar para un agente de voz? Empieza con una latencia p95 < 1,2 s, una tasa de respuestas correctas > 95% sobre un conjunto de evaluación de referencia, falsos rechazos < 5% y un CSAT igual o superior a tu línea base humana. Ajusta para lograr resoluciones correctas, no la contención bruta.
(Genera el JSON-LD de FAQ a partir de los cuatro pares de pregunta y respuesta anteriores.)
Enlaces internos
- Finn frente a Retell
- Alternativas a Vapi
- API de agentes de voz: arquitectura en producción
- Cómo escalar la atención al cliente con AI de voz
- Transferencia en caliente frente a transferencia en frío en centros de llamadas con AI
¿Ya pasaste la demo y te enfrentas a producción? Finn incluye de fábrica las barreras de seguridad, la escalación, el arnés de evaluación y el panel de SLO de este manual, no añadidos a posteriori. Reserva una demostración guiada del despliegue de Finn →
