La manía de la IA está destrozando la toma de decisiones (y nadie quiere medirlo)

El Cuñado ya lo tiene claro

El Cuñado dice: "Bro, mi empresa ya está full IA. Hemos pivotado a flujos agentivos, tenemos chatbot interno, otro de atención al cliente y el CEO dijo en el all-hands que la productividad se ha disparado. El que no se suba se queda fuera."

La realidad es: un consultor que pasó un año metido en ventas y técnica de su empresa, con unas 300 reuniones con gente de nicho hasta ejecutivos de Fortune 500, y su equipo, cuenta otra película. En el último año y medio, todos los proyectos de IA que observaron (los suyos y los que vieron de refilón) fracasaron. Tasa de éxito del 0%. Lo cuenta Ludicity en AI Mania Is Eviscerating Global Decision-Making (ludic.mataroa.blog, 2026-07-18).

Por qué importa saberlo: porque si tu organización llama "éxito" a comprar licencias, montar un chatbot que nadie abre o pivotar dos veces a "lo agentivo" sin usuarios, no estás adoptando IA. Estás destruyendo la capacidad de decidir con datos. Y eso sale más caro que el modelo.

No vamos a convertir un artículo de un tipo en evangelio universal. Es una fuente, con sesgo de quien ve muchos cadáveres de proyecto. Pero el patrón que describe encaja con lo que se ve cuando se deja de mirar demos y se mira uso real, métricas y arquitectura. Vamos a desmontarlo sin piedad y sin convertir el desmontaje en llorera moral.

Qué vio Ludicity (y qué no podemos inventar)

Ludicity no es un think tank con encuesta a 10.000 CIOs. Es alguien que gestionó ventas y lo técnico, que se sentó en cientos de reuniones y que miró de cerca sector público y privado. Su afirmación fuerte es estrecha y hay que respetarla tal cual:

• En su observación directa y lateral del último año y medio, ningún proyecto de IA de los que su equipo tocó o vio de cerca salió bien.
• Eso no prueba que "todas las empresas del planeta fracasan con la IA". Prueba que en el circuito que él recorrió la tasa fue cero. Punto. Quien lo convierta en ley universal está haciendo el mismo truco que los vendedores de humo, pero al revés.

Los fallos, dice, no siempre nacen de la IA en sí. Nacen de empresas que ya eran terminalmente malas ejecutando software… y encima le suman modos de fallo nuevos por lo novedoso del bicho. Si no sabes sacar un CRUD a producción sin drama, meter un LLM no te convierte en empresa de producto. Te convierte en empresa con dos incendios y un slide de "AI-first".

Eso importa porque el debate público suele polarizarse entre "la IA lo arregla todo" y "la IA no sirve para nada". La lectura útil es más sosa y más dura: la IA amplifica la calidad del sistema que ya tienes. Si tu sistema de decisión, documentación y entrega es una trituradora, el LLM es un altavoz.

Chatbots internos: el LLM no lee lo que no escribiste

Uno de los cadáveres recurrentes es el chatbot interno. La promesa del Cuñado es obvia: "pregunta lo que quieras a la base de conocimiento de la empresa". La realidad que describe Ludicity es casi ofensiva de lo simple que es:

Las empresas tienen documentación de baja calidad. Un LLM no puede saber lo que no está escrito y accesible. No hay magia de embeddings que invente el procedimiento que solo vive en la cabeza de María de Contabilidad y en un hilo de Slack de 2019.

Traducido a lenguaje de bar: si tu wiki es un cementerio de PDFs, páginas huérfanas y "TODO: actualizar", montar RAG encima es ponerle GPS a un coche sin ruedas. El retrieval te devuelve basura elegante. El modelo resume la basura con confianza. El empleado prueba dos veces, se cabrea y vuelve a preguntarle al compañero de al lado.

Por eso "rara vez son usados por empleados". No porque la gente sea ludita. Porque la herramienta no resuelve el problema real (información mala, dispersa o inexistente) y encima introduce uno nuevo: respuestas que suenan bien y están mal.

Si de verdad quieres un asistente interno útil, el trabajo feo va antes del modelo:

1. Inventariar qué preguntas se hacen de verdad (tickets, Slack, onboarding).
2. Escribir y mantener esas respuestas en sitios recuperables.
3. Medir si la gente usa el bot y si la respuesta evita el ticket.
4. Solo entonces pelearte con chunking, embeddings y evaluación del retrieval.

Sin eso, tu "proyecto de IA" es un buscador caro de documentación que nadie cuida. Y eso no es un problema de modelo frontier: es un problema de producto y de higiene informativa.

Atención al cliente: la victoria inventada del ticket cerrado

Los chatbots de cara al cliente salen igual de mal en la observación de Ludicity, con una excepción que él mismo acota: la transcripción en vivo en consultas médicas. Útil, sí. Justificación para reorientar toda una organización alrededor de "IA conversacional", no.

El ejemplo que clava el patrón es el de Mitsubishi: un chatbot de asistencia tras una avería automotriz prometió una devolución de llamada que no ocurrió en seis meses. Al autor le quitó las ganas de volver a comprar la marca. Y aquí viene el detalle que debería quitar el sueño a cualquier responsable de métricas: el sistema probablemente reportó una resolución exitosa.

Eso es el corazón del desmontaje. No solo falla el flujo. Falla el instrumento de medida. Si el bot cierra el caso porque "se generó la promesa de callback", el dashboard se pone verde, el proveedor cobra, el sponsor interno presenta el slide… y el cliente se va a la competencia con una historia que cuenta en cenas.

No vamos a afirmar que Mitsubishi perdió X millones o que "todos los chatbots de automoción son así". No consta. Lo que sí consta es el mecanismo: optimizar la métrica fácil enmascara el fracaso real. Llamada prometida ≠ problema resuelto. Ticket cerrado ≠ cliente atendido. "Conversación completada" ≠ valor entregado.

Si tu OKR de IA es "porcentaje de conversaciones resueltas por el bot" sin muestreo humano de calidad ni seguimiento de recontactos, estás entrenando a la organización a mentirse.

El pivote agentivo sin usuarios: teatro de roadmap

Hay un relato dentro del artículo que resume la comedia del ciclo de hype. Una editora cuenta que su división pivotó hacia flujos de trabajo agentivos. Resultado: solo 10 usuarios llegaron a usar los productos creados para agentes. Después volvieron a pivotar… al soporte de flujos agentivos. En un espacio saturado. Con, dice el texto, solo unas pocas cosas realmente posibles que hacer.

Lee eso despacio. No es "la IA agentiva no sirve". Es algo más indigno: se construye para la narrativa, no para la demanda. Primero se fabrica el producto para el fantasma del agente. Como no hay usuarios, se fabrica infraestructura para el mismo fantasma. El organigrama se mueve. Los decks se actualizan. El cliente interno real sigue haciendo el trabajo igual.

Eso conecta con otra pieza del puzzle: en empresas grandes (Ludicity habla de más de 500 empleados), cuestionar la IA es peligroso para la carrera. El avance y la permanencia dependen de no alzar la voz contra la narrativa dominante. No hace falta un memo de despidos por herejía. Basta el clima: el que pregunta por uso real, por baseline o por coste marginal se convierte en "el negativo", "el que no entiende el momento", "el que frena la transformación".

Cuando el coste social de decir la verdad supera el coste de mentir con un dashboard, la organización deja de decidir. Empieza a ritualizar.

Comprar Copilot no es un proyecto de IA

Ludicity apunta a un truco especialmente limpio en empresas cotizadas: anunciar ganancias de productividad por IA después de comprar licencias de Copilot y declarar victoria, sin proyectos reales detrás.

Repitamos la distinción porque es donde se va el dinero:

• Licencia desplegada ≠ adopción.
• Adopción ≠ cambio de proceso.
• Cambio de proceso ≠ resultado de negocio medible.

Puedes tener 10.000 asientos, un mail del CEO y un badge en la web de "AI-powered" y seguir sin saber si el tiempo de ciclo bajó, si la calidad subió o si solo moviste el café de la stand-up a mirar sugerencias del autocompletado.

Y aquí entra el incentivo colectivo que describe el artículo: consejos, ejecutivos, empleados, proveedores y consultores tienen motivos para ocultar y falsear el éxito. A casi nadie le conviene ser el primero en decir "esto no se usa" o "el ROI no aparece". El proveedor vende renovación. El sponsor interno vende promoción. El consultor vende fase 2. El empleado vende tranquilidad. El consejo vende narrativa a mercado.

En ese equilibrio, la verdad es un bien huérfano.

Incluso si se acepta (y Ludicity lo deja abierto) que las herramientas de IA aceleran ciertas cargas de trabajo, el método y la escala actuales de inversión no tienen sentido según su experiencia. Eso es una afirmación de criterio, no un meta-análisis. Trátala como tal. Pero obliga a una pregunta incómoda: ¿cuánto de lo que tu empresa llama "estrategia de IA" es solo miedo a quedarse fuera del comunicado de prensa del sector?

La toma de decisiones es lo que se está comiendo el hype

El título del texto original no habla de modelos. Habla de decision-making: identificar problemas u oportunidades, evaluar alternativas y elegir con una mezcla de análisis y juicio. Eso es lo que se eviscera cuando:

• se prohíbe de facto la duda,
• se sustituye la medición por vanity metrics,
• se confunde comprar software con transformar operaciones,
• se castiga al que pide un baseline.

Una organización que no puede decir "esto ha fracasado" no puede aprender. Una que no mide uso real no puede priorizar. Una que declara victoria a los 30 días de un rollout no está gestionando riesgo: está haciendo marketing interno con presupuesto de tecnología.

El daño no es solo el dinero tirado en pilots zombis. Es el atrofiamiento del músculo de decidir. Cuando todo proyecto debe ser "AI-enabled" para conseguir sponsor, dejas de financiar el arreglo aburrido que sí movería la aguja: limpiar datos, simplificar un proceso, automatizar con reglas lo que ya es determinista, escribir la documentación que falta.

Y sí: a veces la pieza correcta es un LLM. Parsear lenguaje natural sucio, redactar borradores, clasificar con contrato tipado, proponer. Pero eso exige diseño. No fe.

Mi criterio: el LLM no es el motor de estados

Aquí no voy a reescribir a Ludicity con otras palabras. Voy a decir cómo se construye para no acabar en su cementerio de proyectos.

Diseña primero la máquina de estados. Transiciones legales, auditoría, permisos, qué puede pasar y qué no. Después coloca el LLM en los bordes: entrada (parser), salida (redacción) y decisiones puntuales con contrato tipado. El modelo nunca muta estado directamente. Propone. El motor valida. Si la propuesta no encaja en el esquema, se rechaza o se manda a humano. Sin drama místico.

En criollo: el LLM planifica y parsea; el código ejecuta y toca la red, la base de datos y el dinero. Cuando inviertes eso (cuando dejas que el modelo "llame herramientas" sin cinturón de seguridad y sin máquina de estados) estás un prompt injection o una alucinación educada lejos de un incidente de verdad.

Eso enlaza con algo que en Domina IA hemos martillado en otra clave: el human-in-the-loop convertido en placebo no te salva si la arquitectura ya es un coladero. Supervisar un desastre no lo convierte en proceso.

El baseline determinista no puede ser un espantapájaros

Otro error clásico que infla el hype y también infla ciertos "fracasos heroicos": comparar el LLM contra un baseline ridículo.

Si tu punto de comparación es un if-else escrito en servilleta o un proceso manual caótico, cualquier demo brilla. La ganancia atribuida al modelo está hinchada. Y entonces decides mal el presupuesto, el proveedor y el nivel de riesgo.

El baseline honesto es el que un ingeniero competente montaría sin IA en un par de días: reglas, búsquedas, formularios bien hechos, colas, validaciones. Ni tonto a propósito, ni sobreajustado solo a los casos del test (el espantapájaros contrario).

Solo cuando ese baseline está en pie tiene sentido preguntar:

• ¿Qué parte sigue siendo lenguaje natural sucio o redacción abierta?
• ¿Dónde el modelo gana de verdad al sistema de reglas?
• ¿Cuál es el coste de error y quién lo paga?
• ¿Qué métrica no se puede falsear con un "ticket cerrado"?

Sin eso, "metemos agentes" es cosplay de modernidad.

Si vas a evaluar modelos o flujos, deja de fiarte del leaderboard genérico y monta evaluación con datos propios. El 80% en un benchmark de marketing no te dice si tu bot de averías miente con la callback.

Por qué los líderes no miden (y cómo olerlo en cinco minutos)

Ludicity es explícito: los líderes de proyecto evitan métricas básicas como el uso real, o rastrean indicadores fáciles de manipular. Eso no es incompetencia inocente siempre. A veces es supervivencia.

Señales de olor a teatro:

• Se celebra el número de licencias, no de usuarios activos semanales.
• "Resolución automática" sin auditoría de una muestra aleatoria.
• Ningún grupo de control ni comparación con el proceso anterior.
• El piloto no tiene criterio de kill escrito antes de empezar.
• El vendor define las métricas de éxito del vendor.
• Preguntar por recontactos, escalados o CSAT post-bot se considera "poco alineado".

Una organización seria hace lo contrario aunque duela:

1. Define el problema de negocio en una frase sin la palabra IA.
2. Fija la métrica que un escéptico respetaría.
3. Publica el baseline.
4. Acota el modo de fallo (qué pasa cuando el modelo se inventa la callback).
5. Reserva presupuesto y autoridad para apagar el invento.

Si no puedes apagarlo por política interna, no tienes un producto. Tienes un altar.

Qué hacer el lunes si estás hasta los huevos del humo

Sin receta mágica y sin curso de 997€. Lista operativa:

• Congela los pilots zombis. Si lleva tres meses en "promesa" sin usuarios reales, o se mata o se reescribe el problema.
• Exige el flujo sin LLM. Dibuja el proceso con reglas y humanos. Marca en rojo solo los pasos donde el lenguaje o la variación de verdad lo piden.
• Contrato tipado en cada salida del modelo. JSON schema, validación, rechazo. El modelo propone; el motor dispone.
• Métrica de uso + métrica de resultado. Abrir el bot no cuenta. Resolver el caso sin recontacto, sí.
• Documentación como dependencia de producción. Si el RAG depende de una wiki muerta, el backlog es de contenidos, no de "mejorar el prompt".
• Protege al que duda. Si el único camino de carrera es aplaudir el pivote agentivo, tus datos de adopción están podridos de origen.

Y si te venden que "hay que pivotar toda la compañía a agentes" porque el mercado lo pide, recuerda el caso de los 10 usuarios. El mercado pide demos. Tus usuarios piden que la devolución de llamada exista.

El desmontaje en tres líneas (para el grupo de WhatsApp)

Cuñado: "Hemos fallado menos desde que somos AI-first; el consejo está flipando."

Realidad (según la observación de Ludicity): proyectos de IA al 0% de éxito en su muestra; chatbots sin uso por documentación basura; atención al cliente que reporta éxito mientras el humano espera meses; ejecutivos que confunden licencia de Copilot con transformación; incentivos alineados para mentir.

Por qué importa: porque el coste no es solo el pilot. Es la destrucción de la capacidad de mirar un número incómodo y decidir. Sin eso, da igual el modelo que compres el trimestre que viene.

La IA útil es aburrida de describir: un parser aquí, un redactor allá, un clasificador con tests, un humano en los bordes de verdad, un motor determinista que no se deja enchufar tonterías. La IA que destroza decisiones es la que necesita ser el protagonista del relato corporativo.

Si tu proyecto necesita que nadie pregunte por el uso real para seguir vivo, ya tienes la respuesta. No es inteligencia artificial. Es miedo artificialmente amplificado.

Preguntas frecuentes

¿Fracasan todas las empresas con sus proyectos de IA?

No. Lo que consta es la observación de Ludicity: en un año y medio, los proyectos de IA que su equipo tocó o vio de cerca tuvieron un 0% de éxito. Eso no es un censo global ni un estudio con muestra representativa. Es una señal fuerte de un circuito concreto (público y privado, muchas reuniones, muchos cadáveres) y un aviso sobre ejecución, métricas e incentivos, no una ley universal.

¿Por qué los empleados no usan los chatbots internos de IA?

Porque suelen montarse sobre documentación mala, incompleta o inaccesible. Un LLM no puede recuperar lo que nadie escribió ni mantuvo. El empleado prueba, recibe respuestas flojas o inventadas con seguridad, y vuelve al compañero o al buscador interno viejo. Sin higiene de contenidos y sin medir resolución real, el chatbot interno es un juguete caro.

¿Comprar Microsoft Copilot cuenta como adoptar IA con éxito?

No por sí solo. Desplegar licencias y declarar ganancias de productividad, como describe Ludicity en el comportamiento de algunas cotizadas, confunde compra con resultado. Hace falta uso real, cambio de proceso y una métrica de negocio que no se pueda maquillar. Sin baseline ni evidencia de impacto, el anuncio es narrativa, no adopción.

¿Qué arquitectura reduce el riesgo de estos fracasos?

Una máquina de estados determinista con auditoría y transiciones claras, y el LLM solo en bordes: parseo, redacción y decisiones puntuales con salida tipada. El modelo propone; el código valida y ejecuta. Compáralo siempre con un baseline serio sin IA, no con un espantapájaros. Si no puedes medir uso y apagar el flujo cuando falla, no tienes sistema: tienes demo.