Por qué algunas empresas pierden dinero implementando IA
La mayoría de los proyectos de IA no fracasan por el modelo. Fracasan por cómo se plantearon antes de escribir una sola línea de código.
El piloto que nunca iba a llegar a producción
Muchos proyectos empiezan como una demo: un prototipo vistoso, construido en semanas, que convence en una reunión. El problema aparece después — nadie diseñó ese prototipo pensando en autenticación, en volumen real de datos, en qué pasa cuando falla o en quién lo mantiene. Llevarlo a producción exige rehacer la mitad del trabajo, y esa segunda mitad no estaba presupuestada. El dinero perdido no es el de la demo — son las semanas de ingeniería adicionales que nadie planificó.
El caso de uso elegido para impresionar, no para rendir
Un chatbot de cara al cliente es visible, fácil de enseñar en un comité y fácil de justificar internamente. Pero muchas veces no es donde más rentabilidad hay. El proceso administrativo repetitivo que consume veinte horas a la semana de un equipo entero no luce en una demo, pero es donde de verdad se recupera la inversión. Elegir el caso de uso por su capacidad de impresionar, en lugar de por su impacto medible, es una de las formas más comunes de gastar presupuesto sin ver retorno.
Sin dueño ni métrica, no hay forma de saber si funcionó
Si nadie define, antes de empezar, qué significa éxito — una métrica concreta, un responsable de negocio, una fecha de revisión — el proyecto se evalúa por sensación, no por datos. Meses después, nadie puede decir con certeza si el sistema ahorró dinero o simplemente cambió dónde se gastaba el tiempo. Esa ambigüedad es cara: impide tanto escalar lo que funciona como cortar lo que no.
La factura que llega después del lanzamiento
Un modelo desplegado no es un gasto único. Los prompts se degradan cuando cambia el proveedor, los datos de referencia envejecen, y el uso real casi siempre es mayor de lo estimado en la prueba de concepto. Pocas empresas presupuestan el mantenimiento con el mismo rigor que la construcción inicial — y cuando la factura mensual sorprende, la reacción habitual es apagar el sistema, no ajustarlo. La inversión inicial se pierde por completo.
Comprar la herramienta antes de arreglar los datos
Ninguna plataforma de IA compensa una base de datos inconsistente, documentación desactualizada o procesos que ni el propio equipo tiene claros. Cuando la herramienta se compra antes de ese trabajo de base, el proyecto absorbe en silencio el coste de arreglar los datos sobre la marcha — normalmente más caro, y menos visible, que haberlo hecho primero. Y cuando el equipo, sin gobernanza clara, empieza a resolverlo por su cuenta pegando información sensible en herramientas públicas de IA generativa, el riesgo deja de ser solo de presupuesto.
Ninguno de estos patrones tiene que ver con la calidad del modelo. Tienen que ver con cómo se plantea el proyecto antes de tocar código — qué caso de uso, con qué métrica, sobre qué datos y con qué plan de mantenimiento. Es exactamente lo que cubre un diagnóstico de viabilidad: una hoja de ruta priorizada antes de comprometer presupuesto en construcción.