El 80% de los proyectos de IA empresariales no llegan a producción. La causa raíz no es la cultura ni la falta de talento: son cinco fallos técnicos
concretos que se repiten. Datos no representativos, ausencia de observabilidad y evals, integración con sistemas reales relegada a la última fase,
costes operativos no calculados antes de empezar y casos de uso elegidos por su valor para una demo, no por su valor de negocio. Saber identificarlos
antes de aprobar el presupuesto evita el 80%.
Múltiples informes (Gartner, MIT Sloan, S&P Global Market Intelligence, McKinsey) coinciden en una cifra similar: entre el 70% y el 85% de los pilotos de IA en empresa no llegan a producción o lo hacen sin generar valor medible. La explicación pública habitual es “falta de cultura digital”,
“talento insuficiente” o “necesidad de un Chief AI Officer”. Esa explicación es cómoda porque no responsabiliza a nadie técnicamente y porque vende informes y consultorías de cambio cultural. La explicación honesta, desde nuestra experiencia auditando más de noventa proyectos de IA atascados, es más simple: hay cinco fallos técnicos que se repiten en casi todos los casos. Conocerlos por adelantado evita el 80%.
Las PoCs se entrenan o se prueban con datasets limpios, etiquetados y sin ruido. Los datos reales de la empresa son sucios, incompletos, con
etiquetado inconsistente y con casos extremos que no aparecen en ninguna muestra. Cuando el modelo pasa de demo a producción, la calidad cae
entre un 20% y un 60% en las tres primeras semanas. Esto se llama “data drift en el primer día” y no se evita con más entrenamiento: se evita con
un protocolo de validación previo a la PoC que use una muestra representativa de los datos reales, con todos sus problemas.
En software tradicional nadie despliega a producción sin logs, métricas y alertas. En IA es habitual desplegar modelos sin saber qué está respondiendo
el sistema en tiempo real, cuántas alucinaciones hay por día, qué porcentaje de respuestas son rechazadas por el usuario, ni cuánto cuesta
cada llamada al modelo. Sin observabilidad y sin evals automáticos, el modelo se degrada en silencio y nadie se entera hasta que un cliente se
queja en una llamada.
Implantar observabilidad correcta exige tres componentes: logs estructurados con la entrada, la salida y el contexto; métricas agregadas (latencia,
coste, ratio de rechazo); y evals automáticos que ejecuten un conjunto de test prompts cada noche y alerten si la calidad baja. Sin esos tres, el
modelo está ciego.
Es habitual escuchar: “primero hagamos la PoC y la integración la vemos después”. Esa frase predice fracaso. La integración con sistemas internos
(ERP, CRM, herramientas de operaciones, autenticación corporativa) es donde el proyecto se cae normalmente. Latencias inesperadas, formatos
de datos incompatibles, requisitos de seguridad no documentados, problemas de permisos.
La regla práctica: si en la primera semana de PoC no hay un endpoint del sistema interno conectado al modelo (aunque sea de pruebas), el proyecto
está mal planteado. La integración tiene que ser parte del riesgo desde la primera línea de código, no una fase posterior.
Una PoC con cinco usuarios concurrentes y 100 llamadas al día cuesta poco. La misma arquitectura con 10.000 usuarios concurrentes y un millón
de llamadas al día puede costar 50 veces más, y el coste no es lineal: hay tramos donde se necesitan modelos más caros para evitar latencia, o
instancias dedicadas de GPU. Si nadie ha hecho un cálculo de TCO (coste total de propiedad) antes de aprobar el proyecto, llega un punto donde
el modelo funciona, el usuario lo pide, y el CFO descubre que la factura mensual ha pasado de 1.500 € a 35.000 € en cuatro meses. Decisión:
parar el modelo. Proyecto fracasado.
El caso de uso que mejor se vende internamente con una demo no es el caso de uso con más valor de negocio. El primero suele ser visual, cool y
fácil de mostrar en una sala de reuniones (un chatbot conversacional, un agente que reserva viajes, una herramienta de generación de imágenes).
El segundo suele ser aburrido y poco fotogénico (un modelo de clasificación de tickets, un sistema de extracción de entidades en facturas, un
detector de fraude en transacciones).
La paradoja: los casos de uso aburridos generan ROI medible y se mantienen en producción durante años. Los casos espectaculares tienen un
pico de uso de tres semanas y se apagan en silencio. Si tu proyecto se eligió porque era impresionante en la demo del CEO, el riesgo de fracaso
es muy alto.
Para cada uno de los cinco fallos hay un control previo que debería
hacerse antes de aprobar presupuesto:
Cada uno de estos cinco controles cuesta poco. Saltárselos cuesta el proyecto.
Múltiples estudios independientes (Gartner, S&P, MIT) coinciden en cifras entre 70% y 85% de pilotos de IA que no llegan a producción o no generan valor medible. El número exacto varía según definición y sector, pero el orden de magnitud es robusto.
No necesariamente. Tienen más recursos para esconder los fracasos en proyectos paralelos, pero la métrica de “PoCs que llegan a producción y se usan al
cabo de un año” es similar al resto del mercado.
Sí, siempre. Un caso de uso pequeño con datos reales y resultados medibles enseña más
que una PoC ambiciosa que nunca se valida con producción.
En TCG es una cifra cerrada de cuatro dígitos altos por un informe de 10 días que cubre los cinco controles. Casi siempre paga su coste solo evitando un proyecto mal planteado.
Negocio prioriza, tecnología valida viabilidad. Si una de las dos manda en solitario, el proyecto fracasa. La decisión correcta es siempre conjunta y
firmada.
Empeora el ratio en el corto plazo. La facilidad de hacer demos espectaculares con LLMs ha aumentado el número de pilotos espectaculares que no llegan a producción. La parte buena: el coste por demo bajó, así que se puede iterar más rápido.
Saber por qué fracasan los proyectos de IA es la mejor inversión que puede hacer un comité de dirección antes de aprobar uno. Los cinco fallos
técnicos descritos son evitables, pero solo si se identifican antes de empezar. La mayoría se identifican fácilmente con una auditoría previa de
diez días que cuesta una fracción del proyecto. Si vas a aprobar un piloto de IA este trimestre, pide ese filtro previo.
Español 
English 
Français 
العربية