Lo Que Tu Agente de IA No Puede Manejar Es el Negocio Que Aún No Has Construido

8 min read

El chatbot de IKEA creó empleos.

No haciendo más, sino revelando lo que no podía hacer.

Billie, el agente de atención al cliente de IKEA, ha estado resolviendo el 47% de las consultas entrantes desde 2021 sin intervención humana. 3.2 millones de interacciones, €13M en ahorros, y ahora cada presentación de transformación empresarial en Europa tiene una diapositiva al respecto. La cifra del 47% se ha copiado y pegado en tantos pitch decks que básicamente es el "funciona en mi máquina" de los casos de negocio de IA: todos la citan, nadie verifica qué está corriendo por debajo.

Nadie cubrió la otra columna.

El 53% que Billie no pudo manejar alimentó un programa de recapacitación: 8,500 trabajadores de call center reentrenados como asesores remotos de diseño de interiores. El canal generó €1.3B en el año fiscal 2022. Para ser precisos sobre lo que eso significa: la cifra cubre toda la operación de venta remota de Ingka, y parte de esos ingresos existían antes de que comenzara el programa de recapacitación. El vínculo causal no es perfectamente limpio. Pero el orden de magnitud se mantiene, y la perspectiva estratégica no necesita que la causalidad sea perfecta. Esta no es una historia de RRHH. Es una señal de producto que todos leyeron al revés.

Ilustración de oficina dividida: izquierda muestra trabajador ansioso celebrando métricas de IA en dashboards; derecha muestra profesional confiado analizando logs de errores y patrones de negocio con lupa
Las métricas de éxito de tu IA son la mina de oro de otro negocio.

El Ratio que Nadie Reportó

La prensa empresarial cubrió el caso IKEA e inmediatamente lo enmarcó como una historia de transformación de la fuerza laboral. "La IA crea empleos, no los destruye." Buen titular. Incluso cierto. Pero enterró la perspectiva real bajo una capa de narrativa tranquilizadora diseñada principalmente para hacer que la alta dirección se sintiera mejor sobre el presupuesto de IA y la óptica de la fuerza laboral al mismo tiempo.

IKEA no encontró €1.3B construyendo un mejor chatbot. Lo encontraron preguntando qué no podía hacer el chatbot y tratando esa respuesta como una oportunidad de negocio. El 53% no era una métrica de fallo. Era un mapa de demanda que nadie había pensado en leer.

Cada vez que Billie transfería una conversación, estaba señalando una necesidad del cliente que el producto aún no podía servir. El 53% de las interacciones de clientes eran demanda insatisfecha sentada en el archivo de log. La demanda insatisfecha no es un problema que sortear, es una brecha de producto con una etiqueta de precio. Y mientras más optimizas el 47%, más invisible se vuelve el 53%, porque el dashboard hace que parezca que el sistema funciona bien.

Estás Leyendo el Dashboard Equivocado

Todos los equipos de agentes de IA que conozco monitorean la tasa de deflexión. Es la métrica obvia: ¿cuántas solicitudes resuelve el agente sin escalar? Más alto es mejor. La optimizas, la reportas, la pones en la presentación de revisión mensual. La curva sube, todos se sienten bien sobre el trimestre.

El problema no es que la tasa de deflexión sea inútil. Es estructuralmente ciega a lo que los usuarios realmente querían en las conversaciones que el agente abandonó. La métrica mide lo que tuvo éxito. No te dice nada sobre la forma de lo que falló.

Piensa en Google Analytics. Las vistas de página te dicen qué está funcionando. Las páginas de salida te dicen dónde tu producto está roto. Las páginas de salida son casi siempre más valiosas para decidir qué construir después. (Me pasó una vez en GA4. 6 meses construyendo funcionalidades basadas en lo que la gente miraba más tiempo, que resultó ser la página de precios porque estaban confundidos, no interesados. Misión secundaria de libro de texto. Estaba farmeando el mob equivocado completamente. Eso dolió.) No arreglas una tasa de salida del 38% en tu página de checkout felicitándote por el 62% que logró pasar. Miras dónde la gente se fue y preguntas por qué.

Los logs de agentes funcionan igual. Estás optimizando el 47%. No estás leyendo el 53%.

Una razón más para empezar: si tus agentes corren en una arquitectura nativa de CLI, esos logs salen estructurados. No una sopa de texto conversacional sino output real legible por máquina que puedes canalizar a un prompt de auditoría sin pasar una tarde limpiando datos primero. Profundicé en el argumento completo de por qué los agentes nativos de CLI producen logs más explotables, vale la pena leerlo antes de intentar esta auditoría en logs desordenados y preguntarte por qué el clustering sale inútil.

Tu Log de Fallos Es un Mapa de Demanda

No todo lo que tu agente rechaza es una oportunidad. Saquemos eso del camino primero. Bloqueos deliberados, muros de autenticación de terceros, operaciones destructivas, cosas que están fuera del alcance por política: esas están funcionando correctamente. No son brechas de producto. El filtro es simple: frecuencia combinada con reformulación equivale a una señal real. Una sola ocurrencia probablemente es ruido.

4 señales que vale la pena leer en lo que tu agente abandona, de la más fuerte a la más sutil.

Señal 1: Preguntas rechazadas recurrentes. Cuando diferentes usuarios chocan con la misma pared con el mismo tipo de pregunta a lo largo de una ventana de 30 días, esa pared es una solicitud de funcionalidad con un tamaño de muestra adjunto. No estás viendo a 1 usuario confundido. Estás viendo demanda que aún no has servido.

Señal 2: Reformulaciones repetidas en sesión. Un usuario que reformula la misma solicitud 3 o 4 veces sin obtener una respuesta útil no está confundido sobre cómo funciona el producto. Es persistente porque la necesidad es real y no puede encontrarla en ningún otro lugar. El conteo de bucles es una medida de cuánto lo quieren.

Señal 3: Patrones sistemáticos de fallback. Mira qué categoría de solicitud consistentemente llega a fallback, no solicitudes individuales, categorías. "Los usuarios quieren comparar 2 opciones directamente." "Los usuarios quieren un seguimiento programado." Estos no son fallos aleatorios. Son el esquema de lo que tus usuarios realmente quieren versus lo que construiste.

Señal 4: Reintentos de alto esfuerzo. Cuando un usuario hace la misma solicitud 5 veces en una sola sesión con especificidad creciente cada vez, no es un usuario confundido. Es alguien que no puede encontrar lo que necesita en ningún otro lugar. El conteo de reintentos es un proxy de disposición a pagar. Mientras más alto el esfuerzo, más probable es que estés viendo una necesidad de nivel premium que no tiene hogar en tu producto actual.

1 advertencia que realmente digo en serio: las señales son reales. Tu interpretación de ellas podría no serlo. Ejecuta la auditoría, pero no construyas directamente del output sin al menos alguna validación informal primero. Una llamada de 30 minutos con 2 usuarios le gana a un clustering de IA de alta confianza cada vez.

El log de fallos es la única especificación de producto que tus usuarios realmente escribieron.

Lo Que 3.5 GB de Logs Me Dijeron

Ejecuté la auditoría en 3.5 GB de transcripciones de Claude Code: 2,801 archivos, 30 días, 101 proyectos.

El patrón más contable fue exactamente lo que el dashboard me había estado diciendo: 112 fallbacks de autenticación en paneles de terceros. Visible, esperado, y completamente no accionable porque la solución depende de proveedores que no tienen razón para preocuparse por mi caso de uso. He sabido sobre esos durante meses.

Ese era mi 47%.

Lo que se escondía en la otra columna se veía así. Alrededor de 20 ocurrencias brutas de un bucle de reformulación, que suena como ruido hasta que miras qué hay dentro de esas sesiones y te das cuenta de que "igual" o "sigue roto" regresaba 2 a 5 veces por sesión, cada vez la misma secuencia desarrollándose: el agente entregaba una funcionalidad de UI y la declaraba terminada, yo probaba manualmente en móvil, algo se rompía, el agente reiniciaba desde un ángulo ligeramente diferente el siguiente turno, aún incapaz de registrar que "terminado" significaba funcionando en todas las superficies y no solo en el sandbox al que tenía acceso durante la sesión, y para el 4to bucle estaba quemando tiempo que no había planeado en un problema que técnicamente había "resuelto" dos veces ya. Para el bucle 4 se sentía como una corrida de Dark Souls donde alguien había patcheado la hoguera y yo seguía intentando el mismo patrón de esquiva en el mismo jefe. (Dark Souls al menos te dice "MORISTE" para que sepas cuándo parar.)

El log de fallos estaba codificando algo específico: necesitaba un hook bloqueante que se rehúse a cerrar un turno sin prueba real de extremo a extremo, una prueba y no una declaración, escritorio y móvil. 1 día de trabajo para construir, y estaba escondido en 20 líneas de log que nadie estaba leyendo.

Luego 7 ocurrencias de algo cualitativamente diferente: contenido que olía a IA, el tipo de taglines genéricos y copy fuera de persona que aterriza en un sitio de lifestyle e inmediatamente señala que un humano no lo escribió. (Siempre puedo decir cuándo pasa. Hay una planitud específica, como si el modelo hubiera alcanzado la primera formulación aceptable y se hubiera detenido ahí.) Esto no era demanda de usuario externo. Era una brecha de especificación interna: ninguna puerta de calidad de contenido con anti-patrones explícitos y restricciones de persona por sitio. El log de fallos no sacó a la superficie una solicitud de funcionalidad de usuario. Sacó a la superficie una ausencia que nunca había formalizado. Mecanismo diferente del patrón de bucle, misma fuente.

El dashboard estaba contando 112 fallbacks de autenticación. El costo real estaba en los bucles y las 7 entregas fuera de tono. Y si 7 de 2,800 archivos suena demasiado pequeño para importar: cada uno me costó una sesión completa de reescritura manual.

Ejecuta la Auditoría del 53% en Tus Logs

3 prompts. Copia y pega en Claude con tus logs de agente. Ejecútalos en secuencia, o solo comienza con el Prompt 1 si andas corto de tiempo.

Prompt 1: Agrupar solicitudes rechazadas y detectar bucles de reformulación (Señales 1+2)

Analiza estos logs de agente y haz lo siguiente:

1. Extrae todas las solicitudes que el agente rechazó, no pudo manejar, o transfirió a fallback.
2. Agrúpalas por tema. Nombra cada grupo en lenguaje simple.
3. Para cada grupo: cuenta frecuencia, marca cualquier sesión donde la misma solicitud
   fue reformulada 2+ veces sin éxito.
4. Clasifica cada grupo: brecha de funcionalidad | bug | fuera del alcance por diseño | poco claro.
5. Estima valor potencial: bajo | medio | alto (basado en frecuencia y esfuerzo de reintento).

Para cada grupo, output: nombre, frecuencia, sesiones de reformulación, categoría, valor potencial.

Cierra con 1 oración: "Si tuvieras que construir 1 cosa de este output, sería ___."

Prompt 2: Aislar bucles de reformulación (Inmersión profunda en Señal 2)

De estos logs de agente, encuentra todas las sesiones donde el usuario reformuló la misma 
solicitud 2 o más veces sin una respuesta exitosa.

Para cada sesión:
- ¿Cuál fue la solicitud original?
- ¿Cuántas veces reformuló el usuario?
- ¿Cuál fue el resultado final (fallback / parcial / abandonado)?
- ¿Este patrón se repite a través de múltiples sesiones, o es algo único?

Agrupa sesiones por necesidad subyacente, no por fraseo exacto. Separa demanda 
recurrente genuina de fricción única.

Prompt 3: Puntuar por frecuencia x esfuerzo (Señales 3+4)

De estos logs de agente, puntúa cada patrón de fallo:
Frecuencia x Esfuerzo del usuario = Puntaje de prioridad

Esfuerzo del usuario = número de reintentos + conteo de reformulación por sesión.

Rankea todos los patrones por puntaje de prioridad, más alto primero.
Para los top 5: ¿qué se necesitaría para manejar esta solicitud exitosamente? 
1 oración por patrón.

Marca cualquier patrón donde el esfuerzo del usuario es alto pero la frecuencia es baja.
Esos son tus valores atípicos de alto valor.

El Prompt 2 específicamente saca a la superficie algo que vale la pena leer con un marco más amplio: los bucles de sesión repetidos no solo significan "el agente falló repetidamente," señalan en qué se le está pidiendo a tu agente que se convierta. Desempaqué qué señalan los bucles de sesión repetidos sobre tu agente en detalle, el marco aplica directamente aquí.

2 Lecturas, Mismos Logs

IKEA no construyó un mejor chatbot. Leyeron la cola de abandonos y preguntaron qué les estaba diciendo sobre el negocio que aún no habían construido.

Tienes los mismos logs. Probablemente no los estás leyendo (tal vez me equivoco sobre eso, tal vez tu equipo ya ejecuta esta auditoría cada sprint y la cola de fallos está vacía y estás construyendo precisamente lo que los usuarios no pueden encontrar en ningún otro lugar). En 3 años ejecutando agentes a través de diferentes productos y pipelines, nunca he visto esa configuración. Lo que veo es una tasa de deflexión en un dashboard y una carpeta de logs que nadie abre.

Pega tus logs en el Prompt 1. Lee la columna de valor potencial. Verifica si lo que sale a la superficie es algo que has sabido durante meses pero nunca construiste.

Si la respuesta es sí, esos son tus €1.3B escondidos a plena vista.

Fuentes

Este post puede contener enlaces de afiliados. Si los clicas, podría ganar una pequeña comisión (no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura).