Vi cómo una IA de drive-thru interrumpió a una persona que tartamudea. Entonces construí algo diferente.

Hay un video que ha estado circulando por Reddit. Una mujer en el drive-thru de un Wendy's intenta pedir un Baconator. Tartamudea —un bloqueo en la «b»— y la IA la interrumpe a media palabra, sugiriéndole alegremente un Frosty. Lo intenta de nuevo. El sistema interpreta su repetición como un nuevo pedido. Tres intentos después, está gritando «AGENTE» a una caja de altavoz a la que no le importa.

He visto ese video probablemente treinta veces. No porque sea gracioso —no lo es— sino porque cada fallo en esa interacción se corresponde con precisión con una decisión arquitectónica que alguien tomó en una sala de reuniones, probablemente mientras miraba una diapositiva que decía «tasa de éxito del 86 %».

¿Ese 14 % restante? Son personas reales. Y yo diría que la arquitectura nunca se construyó para ellas, para empezar.

Esta es la historia de por qué mi equipo en Veriprajna pasó la mayor parte de dos años rechazando el camino más rápido al mercado en la IA de voz, y de lo que construimos en su lugar.

¿Qué significa realmente «IA de voz de nivel empresarial»?

La mayoría de las empresas de nuestro sector hacen algo notablemente simple: conectan un micrófono a una API. OpenAI, Google, Anthropic: elige tu modelo de lenguaje grande favorito, canaliza el audio, recibe el texto de vuelta, genera una respuesta. Y a producción.

A esto lo llamo el enfoque de envoltorio de API, y funciona de maravilla en una demo. Sala silenciosa, hablante claro, petición simple. La demo siempre funciona.

La demo siempre funciona. El drive-thru a las 11:47 p. m. con un camión diésel al ralentí detrás de ti y un niño pequeño gritando en el asiento trasero: ahí es donde la arquitectura realmente importa.

El sistema FreshAI de Wendy's —construido sobre Vertex AI de Google Cloud— es probablemente el ejemplo más destacado de este enfoque a escala. Y las experiencias de los clientes que se han reportado te dicen todo lo que necesitas saber sobre sus límites: clientes que necesitan tres o más intentos para pedidos simples, el sistema interrumpiendo a la gente a media frase para sugerir productos que no pidieron, y una experiencia descrita como «inutilizable» para cualquiera con una disfluencia del habla.

Y sin embargo, Wendy's se está expandiendo a entre 500 y 600 locales. La razón es matemática simple: el sistema aumenta el importe medio del ticket mediante ventas adicionales, y las cifras de eficiencia laboral quedan bien en una llamada trimestral de resultados. Si optimizas para el promedio, la arquitectura es un éxito. Si eres la persona para la que no funciona, la arquitectura está rota.

Exploré esta tensión en profundidad en la versión interactiva de nuestra investigación. Pero el argumento central es uno que quiero exponer personalmente, porque moldeó cómo lo construimos todo.

La noche en que nos dimos cuenta de que el micrófono era el punto de partida equivocado

Eran alrededor de las 9 p. m. de un jueves a finales de primavera. Mi cofundador, dos ingenieros y yo, de pie en el estacionamiento de un Taco Bell cerrado que nos habían dado permiso para usar en las pruebas. Teníamos nuestro prototipo montado en un poste: un altavoz, un micrófono, algo de cinta adhesiva que lo mantenía todo unido. Lo habíamos estado ejecutando en el laboratorio durante semanas con una precisión de cerca del 95 %. Nos sentíamos listos.

El primer auto que se acercó era una mujer en un Honda Civic con la ventanilla a medio bajar. Dijo «Quiero un combo número tres» con suficiente claridad. El sistema oyó «island numb recon bowl». Miré a mi cofundador. Él miró al suelo.

La precisión no solo era mala: era inutilizable. Nos quedamos en ese estacionamiento otras dos horas, ejecutando prueba tras prueba, y las cifras solo empeoraban a medida que aumentaba el tráfico de la noche. Recuerdo el momento exacto en que dejé de sentir frustración y empecé a sentir algo más cercano al pavor: esto no era un problema de ajuste. Todo nuestro enfoque estaba equivocado.

El problema no era el modelo de lenguaje. El modelo estaba bien. El problema era todo lo que ocurría antes de que el audio llegara al modelo. Ruido de viento. El retumbar del motor. El zumbido mecánico de una unidad de climatización a seis metros de distancia. La bocina de un auto a tres cuadras. Nuestro sistema no podía distinguir entre una voz humana y un motor diésel porque, a nivel de señal, nadie le había enseñado a hacerlo.

Ese fue el momento en que comprendí algo que creo que la mayoría de la gente en este espacio aún no ha interiorizado: la IA de voz no es un problema de PLN. Es, ante todo, un problema de procesamiento de señales; en segundo lugar, un problema de lingüística; y en tercer lugar, un problema de PLN. Si tu primera capa está rota, nada de lo que venga después puede salvarte.

¿Por qué la IA de los drive-thru sigue interrumpiendo a la gente?

El culpable es algo llamado detección de actividad de voz, o VAD (por sus siglas en inglés). Es el sistema que decide cuándo has empezado a hablar y cuándo has terminado. En la mayoría de las soluciones de tipo envoltorio, es un simple umbral de energía: el sonido supera una línea, empieza la grabación; el sonido cae por debajo de una línea, se detiene la grabación.

Piensa en eso en un drive-thru. Haces una pausa de medio segundo para echar un vistazo al tablero del menú. La energía cae. El VAD decide que has terminado. Envía un fragmento de frase al modelo, el modelo alucina una respuesta a una pregunta que nunca terminaste de formular, y ahora estás discutiendo con una caja de altavoz.

Reconstruimos nuestro VAD desde cero. En lugar de umbrales de energía, usamos modelos neuronales —Silero, Cobra— que producen una puntuación de probabilidad de voz humana a través de diversas frecuencias. En lugar de un encendido/apagado binario, nuestro sistema ofrece un nivel de confianza. Y en lugar de una tolerancia de pausa estática de 500 milisegundos, usamos una ventana dinámica de 600 a 1000 milisegundos que se ajusta según el contexto conversacional.

El truco que marcó la mayor diferencia, sin embargo, fue lo que llamamos transcripción especulativa. El sistema empieza a procesar el audio a los 250 milisegundos, pero no se compromete con un punto final hasta que hay 600 milisegundos de silencio confirmado. Ese solapamiento reduce la latencia percibida en 350 a 600 milisegundos y, al mismo tiempo, elimina los cortes prematuros.

Mi cofundador sostuvo durante semanas que la ventana de pausa dinámica estaba sobrediseñada. Estábamos en la oficina una noche, ya tarde —café frío, pizarras cubiertas de diagramas de latencia— y él echó su silla hacia atrás y dijo: «Estamos gastando tres semanas de ingeniería en una función que ahorra medio segundo. Nadie hace una pausa de un segundo entero en un drive-thru. Esto es un problema de vanidad». Yo dije algo como: «Y si te equivocas, habremos construido un sistema que interrumpe a todos los clientes que necesitan pensar». No hablamos durante el resto de la noche. Se fue cerca de la medianoche. Yo me quedé y seguí ejecutando simulaciones.

Luego lo probamos con clientes reales. Resulta que la gente hace pausas constantemente: mirando el menú, girándose para preguntarle a un acompañante qué quiere, pensando si de verdad necesita papas fritas. Un segundo entero de pausa natural no es silencio. Es pensar. Mi cofundador me envió un mensaje de una sola línea después de ver los resultados de las pruebas: «Tenías razón. Perdón por lo de la silla».

Cuando optimizas para la velocidad por encima de la paciencia, construyes un sistema que solo funciona para las personas que ya saben lo que quieren.

80 millones de personas

El tartamudeo afecta a más de 80 millones de personas en todo el mundo. Esa cifra me caló de otra manera después de lo del estacionamiento.

Se manifiesta como repeticiones («b-b-b-baconator»), prolongaciones («mmmmilk») y bloqueos: pausas silenciosas en medio de una palabra en las que la persona físicamente no puede producir sonido.

Ahora piensa en lo que un VAD estándar hace con un bloqueo. La persona deja de producir sonido a media palabra. El sistema interpreta el silencio como el final del turno. Responde a media palabra. La persona lo intenta de nuevo. El sistema trata la repetición como un nuevo pedido. En diez segundos, tienes una IA confundida, un humano frustrado y una fila de autos acumulándose detrás.

Esto no es un caso límite. Es una decisión de diseño. Cuando entrenas un modelo ASR (reconocimiento automático del habla, por sus siglas en inglés) casi exclusivamente con inglés estadounidense «estándar» —bien articulado, con pausas mínimas—, estás tomando una decisión sobre para quién es tu sistema. La investigación muestra que los modelos ASR basados en Conformer (una arquitectura neuronal que combina convolución con autoatención para el procesamiento de audio), la columna vertebral de la mayoría de los sistemas modernos, ven su rendimiento degradarse tan gravemente con el habla desordenada que algunos devuelven negativas puntuaciones de similitud semántica. No solo inexactas: semánticamente invertidas.

Cuando tu modelo de IA devuelve puntuaciones semánticas negativas con el habla desordenada, no has construido un sistema que tenga dificultades con casos límite. Has construido un sistema que nunca fue diseñado para oír a una porción significativa de la humanidad.

Un inversor me dijo una vez, sin rodeos: «Simplemente usa la API y haz el ajuste fino más tarde. Estás quemando capital operativo en un problema que afecta a un pequeño porcentaje de clientes». Saqué las cifras en mi teléfono: 80 millones de personas solo con tartamudeo, antes de contar los acentos, los hablantes de ESL (inglés como segunda lengua), los clientes mayores, cualquiera que pida en un auto ruidoso. Vi cómo cambiaba su cara. «Eso no es un pequeño porcentaje», dijo. «No», dije yo. «No lo es».

Ajustamos con precisión modelos autosupervisados sobre conjuntos de datos de habla disfluente reanotados. Usamos la inserción sintética de disfluencias: tomamos transcripciones fluidas, añadimos bloqueos y repeticiones, y las sintetizamos en audio de entrenamiento. Es un trabajo minucioso. No es el tipo de cosa que aparece en un cuadro comparativo de funciones. Pero es la diferencia entre un sistema que funciona para todos y un sistema que funciona para el promedio.

¿Qué pasa cuando la IA de voz se ejecuta en el borde en lugar de en la nube?

Cada palabra pronunciada en el micrófono de un drive-thru de Wendy's viaja por la internet pública hasta un centro de datos de Google y de vuelta. Ese viaje de ida y vuelta cuesta de 100 a 500 milisegundos antes de que el modelo siquiera empiece a procesar. En la interacción por voz, el estándar de referencia es un tiempo de respuesta inferior a 300 milisegundos; cualquier valor por encima de eso, y la conversación deja de sentirse natural. A los 700 a 900 milisegundos, se siente como una mala llamada telefónica. A los dos segundos, la gente empieza a hablar por encima del sistema.

Lo trasladamos todo al borde. Procesamiento local en hardware especializado en el propio restaurante. Nuestra latencia bajó a entre 5 y 10 milisegundos.

Pero la verdadera clave no era solo la velocidad, sino el tamaño del modelo. Un LLM de propósito general necesita saberlo todo sobre todo. Un modelo de lenguaje pequeño específico de un dominio necesita saber que «Dave's Single» es una hamburguesa, no un álbum de música. Ese enfoque significa una inferencia más rápida, respuestas más predecibles y una fracción del coste computacional. Hemos visto mejoras de velocidad de 3x y costes operativos entre un 30 y un 40 % más bajos en comparación con los enfoques basados en la nube.

La arquitectura de borde también resolvió un problema que no habíamos anticipado del todo: la fiabilidad. Cuando internet se cae —y se caerá—, un sistema dependiente de la nube se convierte en un pisapapeles muy caro. Nuestro sistema sigue funcionando. Para el desglose técnico completo de nuestra arquitectura de borde frente a los enfoques en la nube, puedes profundizar en el artículo de investigación.

El muro regulatorio del que nadie habla

La norma CAN-ASC-6.2:2025 llegó a mi escritorio a principios de 2025, y recuerdo haberla leído con algo entre alivio y reivindicación: aquí había un estándar que por fin decía aquello hacia lo que habíamos estado construyendo: las personas con discapacidad deben participar en el diseño, las pruebas y la gobernanza de los sistemas de IA. No como una ocurrencia tardía. Desde el principio. La Ley Europea de Accesibilidad comienza a aplicarse en junio de 2025 con multas cuantiosas, y la ADA se está reinterpretando para cubrir las barreras digitales para las personas con discapacidades del habla. Readaptar un sistema que no cumple la normativa en 600 locales cuesta aproximadamente cinco veces lo que cuesta construirlo bien desde el principio.

«¿Y si solo estamos construyendo una forma realmente cara de tomar un pedido de hamburguesa?»

Ese pensamiento me golpeó a eso de las 2 de la madrugada, quizá a los seis meses de desarrollo. Estaba solo en la oficina, mirando fijamente el espectrograma de una palabra tartamudeada que nuestro sistema aún no lograba interpretar. Llevábamos meses en esto. Habíamos consumido la mayor parte de nuestra financiación inicial. Y las empresas de envoltorio de API estaban lanzando producto mientras nosotros seguíamos depurando canalizaciones de procesamiento de señales.

Casi lo dejo. Casi decido simplemente envolver la API, lanzar algo e iterar más tarde como todos los demás.

Pero «iterar más tarde» es una mentira en la IA de voz. Una vez que has construido tu arquitectura en torno a supuestos que dependen de la nube, de umbrales de VAD y de habla exclusivamente fluida, cada interacción con un cliente refuerza esos supuestos en tus datos de entrenamiento. No iteras hacia la accesibilidad. Iteras alejándote de ella.

Construye primero para el caso límite, y el caso promedio se resuelve solo. Construye para el promedio, y el caso límite nunca se soluciona.

El problema de los turnos de palabra que me hizo replantearlo todo

Hay una sutileza en la conversación humana que damos completamente por sentada. Cuando dices «Quiero un Baconator y...» —esa «y» al final señala que no has terminado. Un cajero humano esperaría. La mayoría de las IA de drive-thru no.

Incorporamos lo que considero una gramática conversacional en nuestra lógica de detección de fin de turno. El sistema analiza las señales lingüísticas en tiempo real: conjunciones que señalan continuación, cambios de tono que señalan finalización, la frase «eso es todo» que significa exactamente lo que dice. Cuando un cliente dice «eso es todo», nuestro sistema responde en menos de 200 milisegundos porque la intención es inequívoca. Cuando se queda a medias con «y...», espera, incluso a lo largo de un segundo entero de silencio.

Aquí es también donde vive nuestra filosofía de humano en el circuito. No creemos que la IA deba gestionar toda la transacción sin supervisión. Las peticiones simples y transaccionales: de esas se encarga la IA. Las situaciones complejas, los clientes frustrados, los momentos de alta fricción: esas se derivan a un humano antes de que la interacción se venga abajo, no después.

El objetivo nunca fue reemplazar al humano en el drive-thru. Fue asegurarnos de que ningún cliente tenga que gritar jamás «AGENTE» a una máquina que no está escuchando.

Sigo volviendo a esa tasa de éxito del 86 % que Wendy's reportó. En la mayoría de los contextos de software, un 86 % sería un fracaso. Imagina una aplicación bancaria que procese correctamente el 86 % de las transacciones. Imagina un sistema de navegación que te lleve al destino correcto el 86 % de las veces. El drive-thru de algún modo ha normalizado una tasa de fallo que sería inaceptable en cualquier otra interacción de consumo.

Esto es un problema de arquitectura, no un problema de IA

El patrón que veo en toda la industria son empresas que tratan la IA de voz como una capa de software: algo que atornillas sobre la infraestructura existente con la clave de API adecuada. Y entiendo por qué. Es rápido, es barato, y las demos son increíbles.

Pero el drive-thru no es una demo. Son motores diésel y viento y niños pequeños y acentos y tartamudeo y gente que se detiene a pensar. Es la complejidad plena e irreducible de la comunicación humana ocurriendo en el peor entorno acústico posible. No puedes abrirte camino a través de eso con un envoltorio.

Las empresas que ganarán este mercado —y digo esto con el sesgo de alguien que se ha jugado su carrera en ello— son las que están dispuestas a ir a fondo. A fondo en el procesamiento de señales. A fondo en el modelado acústico. A fondo en la lingüística de cómo habla realmente la gente, no de cómo los datos de entrenamiento de ASR dicen que debería hacerlo. A fondo en la infraestructura de borde que no depende de un centro de datos a mil kilómetros de distancia.

No hay atajos en la IA de voz. Solo existe el trabajo riguroso, poco glamuroso y profundamente técnico de construir sistemas que oigan a cada cliente. No al 86 % de ellos. A todos y cada uno.

Eso es lo que significa nivel empresarial. Y hasta que la industria acepte esa definición, seguiremos viendo videos de altavoces de drive-thru que no pueden entender la palabra «Baconator».