Demo vs. realidad: qué exigir a un proveedor de IA antes de firmar el contrato

Toda demo de un agente de voz con IA funciona bien. El entorno está controlado, la conexión es estable, los casos de uso están preseleccionados y el comercial sabe exactamente qué decir para que el sistema brille. El problema es que tu negocio no funciona así. Y lo que falla en producción rara vez se ve en una demo.

La brecha entre la demo y el día a día real

Existe un patrón que se repite en la adopción de tecnología de voz con IA: la demo genera entusiasmo, el piloto genera dudas, y la producción genera problemas que nadie anticipó. No es mala fe del proveedor necesariamente. Es que las condiciones de una demo no reproducen la variabilidad del mundo real.

En una demo, el agente escucha preguntas limpias, formuladas con claridad, en un entorno sin ruido de fondo. En producción, recibirá llamadas de usuarios que hablan con acento, que interrumpen, que cambian de pregunta a mitad de la frase, o que llaman desde un móvil con cobertura deficiente.

La diferencia no es anecdótica. Según análisis internos de proyectos de automatización de voz en Europa, entre el 30% y el 45% de las incidencias graves en producción no aparecen durante el periodo de prueba controlado. Y la mayoría de esas incidencias estaban perfectamente prevenibles con las pruebas adecuadas antes de firmar.

Qué tipo de pruebas hacer antes de comprometerte

La mayoría de compradores aceptan la demo del proveedor como evidencia suficiente. Error. Tú debes diseñar tus propias pruebas, con tus propios escenarios, antes de firmar nada.

Pruebas con llamadas reales grabadas

Si tienes grabaciones de llamadas de tu negocio (y si no las tienes, deberías empezar a tenerlas), envíaselas al proveedor y pídele que procese esas llamadas con su sistema. No las llamadas que ellos elijan: las tuyas, incluyendo las complicadas.

Una clínica dental que evalúa un agente de voz debería enviar grabaciones de pacientes confundidos con los precios, llamadas con ruido de fondo en consulta, o personas mayores con dicción poco clara. Un restaurante debería incluir llamadas de grupos que modifican reservas en el último momento o clientes que preguntan por alérgenos de forma indirecta.

Si el proveedor se niega o pone excusas para no procesar tus llamadas reales, eso ya es información valiosa.

Tests de degradación

El sistema funciona bien cuando todo va bien. La pregunta relevante es cómo se comporta cuando algo falla: ¿qué pasa si hay un pico de llamadas simultáneas? ¿Qué ocurre si la conexión con tu CRM tiene latencia? ¿Cómo gestiona el agente una pregunta para la que no tiene respuesta entrenada?

Pide al proveedor que te demuestre el comportamiento de fallo. Un buen sistema no solo funciona en condiciones óptimas: falla con elegancia y deriva la llamada al humano correcto sin dejar al usuario colgado.

Prueba de carga

Si tu negocio recibe 50 llamadas simultáneas en hora punta — una inmobiliaria en campaña de captación, una aseguradora durante un temporal, un restaurante el viernes noche — el proveedor debe demostrarte que su infraestructura lo aguanta sin degradación de latencia ni errores de reconocimiento.

Pide datos de latencia media y percentil 95 bajo carga. La latencia media puede ser de 300ms, pero si en el percentil 95 sube a 2 segundos, eso es lo que experimentarán tus peores llamadas.

Las métricas que debes pedir por escrito, no de palabra

Los proveedores hablan de "alta precisión" y "tasas de resolución elevadas". Esos términos no significan nada sin un número y un contexto. Estas son las métricas que debes exigir documentadas antes de firmar:

Tasa de resolución sin escalado humano: qué porcentaje de llamadas resuelve el agente de forma autónoma, sin transferir a un agente humano. Un proveedor serio debería poder darte este dato para un sector similar al tuyo.

Latencia de respuesta (P50 y P95): el tiempo medio no es suficiente. El percentil 95 te dice qué sienten tus usuarios en las peores condiciones. Por encima de 1,5 segundos de latencia, la conversación empieza a sentirse antinatural.

Word Error Rate (WER) para tu idioma y variante dialectal: si tu negocio atiende clientes con acento andaluz, canario o con fuerte presencia de turistas angloparlantes, el WER debe medirse en esas condiciones, no en castellano neutro de estudio.

Tasa de abandono atribuida al agente: cuántos usuarios cuelgan durante la interacción con el agente, sin haber completado su gestión. Un abandono elevado puede indicar frustración con el sistema, y eso tiene un coste directo en conversiones y en reputación.

Si el proveedor no puede darte estas métricas con datos históricos de clientes reales (anonimizados), es legítimo preguntarse si tiene experiencia en producción o solo en demos.

Qué incluir en el contrato: más allá de las funcionalidades

El contrato de un agente de voz con IA no debería parecerse a un contrato de software estándar. La naturaleza del servicio exige cláusulas específicas que raramente aparecen en los modelos predeterminados de los proveedores.

Antes de firmar, revisa el artículo 15 preguntas que debes hacer antes de contratar un agente de voz IA para asegurarte de que no te dejas nada en el proceso de evaluación previo. Una vez llegues al contrato, estos son los puntos críticos que debes negociar:

SLA con penalizaciones reales

Un SLA que promete "99,5% de disponibilidad" sin penalizaciones económicas asociadas es papel mojado. Exige que el contrato incluya créditos o descuentos concretos si el proveedor incumple los niveles de servicio pactados.

La disponibilidad debe medirse en horas de tu horario operativo, no en tiempo calendario. Si tu negocio opera de 9 a 21h, el 0,5% de caída permitida equivale a 36 horas de downtime al año en ese rango horario. Negocia el SLA sobre horas productivas.

Derecho a auditar el rendimiento

El contrato debe garantizarte acceso a datos de rendimiento del agente: tasas de resolución, tiempos de respuesta, llamadas fallidas, derivaciones. No como favor, sino como derecho contractual. Sin visibilidad sobre el rendimiento, no puedes tomar decisiones informadas ni exigir mejoras.

Cláusulas de salida y portabilidad de datos

¿Qué pasa si decides cambiar de proveedor? ¿Puedes llevarte los datos de conversación, las transcripciones, los flows configurados? ¿En qué formato? ¿En qué plazo?

Un proveedor que dificulta la portabilidad de tus datos está creando dependencia artificial. La cláusula de salida debe especificar un plazo máximo de entrega de tus datos (razonable: 30 días naturales) y el formato en que los recibirás.

Responsabilidad ante errores del agente

Si el agente comunica información incorrecta al usuario — un precio equivocado, un horario desactualizado, una instrucción médica errónea — ¿quién es responsable? Esta cláusula rara vez aparece en los contratos estándar y es precisamente donde pueden surgir conflictos serios.

El contrato debe aclarar el reparto de responsabilidades ante errores de información, especialmente en sectores regulados como sanidad o seguros.

El piloto: cómo estructurarlo para que sea útil

Un piloto de dos semanas en el que solo atiende el 10% del tráfico no es un piloto real: es una demo extendida. Para que el piloto te dé información accionable, debe cumplir tres condiciones.

Primero, debe exponer al agente a volumen real y variedad real. Si habitualmente recibes 200 llamadas al día, el piloto debe gestionar al menos 100. Los patrones estadísticos no emergen con 20 llamadas.

Segundo, debe incluir los casos de uso complicados, no solo los sencillos. Reservas con condiciones especiales, reclamaciones, peticiones fuera de guión. Si el agente solo maneja los flujos estándar, no sabrás cómo se comporta ante la excepción, que es exactamente lo que determinará la experiencia de tus usuarios.

Tercero, debes medir. Antes de iniciar el piloto, establece con el proveedor qué métricas váis a recoger y cuál es el umbral de éxito. Sin criterios de éxito previos, el piloto se convierte en una negociación subjetiva al final del periodo.

Las señales de alerta que no debes ignorar

Hay comportamientos durante el proceso comercial que predicen problemas en producción con notable fiabilidad.

Un proveedor que solo enseña demos en su entorno, nunca en el tuyo, tiene algo que esconder. Un proveedor que no puede facilitarte referencias de clientes en tu sector — o que te da referencias que no puedes contactar directamente — no tiene el track record que afirma tener.

La resistencia a incluir SLAs con penalizaciones reales o a garantizar la portabilidad de datos son señales inequívocas de un proveedor que prioriza la retención sobre la satisfacción del cliente.

Y si durante el proceso comercial te presionan para cerrar rápido antes de que puedas completar las pruebas, el mensaje implícito es claro: las pruebas no les favorecen.

---

En Nolam.ai facilitamos procesos de evaluación transparentes, incluyendo pilotos con datos reales y contratos con SLAs auditables, porque entendemos que la confianza en producción no se puede vender en una demo. Si estás evaluando proveedores de agentes de voz con IA, el equipo de Nolam.ai puede acompañarte en el proceso de comparación sin compromiso.

Preguntas frecuentes

¿Qué métricas debo exigir a un proveedor de agente de voz IA antes de firmar?

Las métricas imprescindibles son la tasa de resolución sin escalado humano, la latencia de respuesta en percentil 95 (no solo la media), el Word Error Rate para tu idioma y variante dialectal, y la tasa de abandono atribuida al agente. Sin estos datos históricos de clientes reales, es imposible evaluar el rendimiento real del sistema.

¿Cómo hacer una prueba real a un proveedor de IA de voz?

La prueba más fiable consiste en enviar al proveedor grabaciones reales de llamadas de tu negocio, incluyendo las más complicadas, y evaluar cómo las procesa su sistema. Complementa esto con tests de carga para simular picos de tráfico y pruebas de comportamiento en fallo, para ver cómo deriva las llamadas cuando no puede resolverlas.

¿Qué cláusulas debe incluir un contrato de agente telefónico IA?

Un contrato sólido debe incluir SLAs con penalizaciones económicas reales, derecho auditado a datos de rendimiento, cláusulas de portabilidad de datos con plazo máximo de entrega, y un apartado de responsabilidad ante errores de información del agente. Sin estas cláusulas, el proveedor no tiene incentivos contractuales para mantener el nivel de servicio post-firma.

¿Cuánto tiempo debe durar un piloto de IA de voz para ser válido?

Un piloto válido debe durar un mínimo de dos semanas con al menos el 50% del volumen real de llamadas habitual. Con menos volumen, los patrones estadísticos no emergen y los fallos puntuales no son representativos. Antes de iniciar el piloto, deben pactarse por escrito los criterios de éxito y las métricas a medir.

¿Cómo sé si un proveedor de IA de voz tiene experiencia real en producción?

Pide referencias directas de clientes en tu sector que puedas contactar tú mismo. Solicita datos históricos de rendimiento anonimizados de despliegues similares. Un proveedor con experiencia real en producción puede facilitarte estos datos sin problema; si pone obstáculos o solo ofrece casos de éxito no verificables, su experiencia probablemente sea más comercial que operativa.