Por qué los pilotos de IA mueren entre la demo y la planta

El piloto se presentó ante el consejo directivo, todos aplaudieron, se aprobó el presupuesto para ’escalar’. Seis meses después, el sistema de visión artificial que en la demo detectaba el 98% de los defectos apenas atrapa la mitad, los inspectores de calidad dejaron de confiar en él y el proyecto migró silenciosamente a la columna de ‘iniciativas aplazadas’. No es un fallo raro ni culpa de un integrador en particular. Según RAND, así termina más del 80% de los proyectos corporativos de IA – y casi siempre por razones que eran visibles antes de empezar.

Lo más incómodo de esa estadística no es el porcentaje de fracasos en sí, sino que la culpa casi nunca es de la tecnología. La corporación RAND, en un estudio de 2024, entrevistó a 65 data scientists e ingenieros con entre 5 y 30 años de experiencia y analizó las razones por las que los proyectos de IA no llegan a producción. La conclusión suena casi ofensiva: la causa más frecuente de fracaso es que los directivos y los técnicos entendieron la tarea de forma diferente. No los datos, no el modelo, no las GPU. La definición del problema.

Para un director de manufactura, esto es una buena noticia. Si el problema fuera la tecnología, solo quedaría esperar la siguiente generación de modelos. Pero si el problema está en las decisiones de gestión, el resultado está en sus manos. A continuación, siete señales de que un piloto está condenado, extraídas de RAND, McKinsey y análisis de fracasos en la industria automotriz. Cada señal es una pregunta que vale la pena hacerle al equipo antes de firmar el presupuesto de escalamiento.

Primero, la escala: por qué ’el piloto funcionó’ no significa nada

Arrancar un piloto hoy no es difícil. Llevarlo a un estado en el que se use a diario en tres turnos y se refleje en el P&L – eso sí es difícil. La brecha entre esos dos puntos es la trampa principal.

McKinsey, en un informe de 2025 sobre el escalamiento de IA en manufactura, ofrece una cifra que debería poner alerta a cualquiera: solo el 2% de los fabricantes considera que la IA está plenamente integrada en sus operaciones. Cerca de dos tercios están atascados en la etapa de exploración e implementaciones puntuales – pilotos interminables, en otras palabras. El informe de MIT, que analizamos por separado, dibuja un cuadro similar: en el 95% de las empresas, la IA generativa no ha producido un impacto medible en las ganancias.

En la industria automotriz, esto se ve en estado puro. Según análisis de Automotive Manufacturing Solutions, la mayoría de los proyectos de visión artificial para control de calidad nunca salen de la celda de pruebas – no porque fallen en la detección de defectos durante la demo, sino porque la demo y la planta real son dos entornos completamente distintos.

Ahora, las señales.

Señal 1. Nadie puede ponerle cifra al problema

RAND coloca la incomprensión de la tarea en el primer lugar de su lista de causas de fracaso, y en manufactura se manifiesta de forma específica. El piloto se lanza porque ‘hay que implementar IA’ o porque un competidor presumió algo en una conferencia. Nadie puede articular qué pérdida económica concreta se supone que el proyecto debe resolver.

McKinsey documenta la misma enfermedad con datos: la mayoría de los fabricantes no vincula sus iniciativas de IA con objetivos concretos de valor. Un proyecto sin precio del problema no puede priorizarse, ni cerrarse, ni declararse exitoso – simplemente no tiene criterio. Cómo construir ese caso de negocio con datos reales lo analizamos aparte.

Antes de lanzar un piloto, intente completar una línea: ’este problema nos cuesta $X al mes porque …’. Si no logra calcular X, eso no significa que la tarea sea mala. Significa que aún no la entiende lo suficiente como para gastar en ella su presupuesto de IA. Elija una donde X sea obvio: tiempo muerto de la línea, reprocesos, penalizaciones por retrasos en entregas.

Señal 2. Los datos para la tarea en realidad no existen

La segunda causa más frecuente en la lista de RAND: la organización no tiene los datos necesarios. En la planta, esto suena especialmente familiar. Se supone que los datos existen – SCADA registra telemetría, MES almacena órdenes de trabajo, control de calidad lleva bitácoras. Pero cuando llega el momento de entrenar o alimentar un modelo, resulta que la mitad de las bitácoras están en papel, SCADA no tiene historial de fallas etiquetado y cada inspector describe los defectos con sus propias palabras.

Es la misma fragmentación de datos de la que se quejan en la industria automotriz: los datos existen, pero están dispersos entre sistemas, sin etiquetar y sin un formato común. Un modelo entrenado con una muestra limpia para la demo se topa con la realidad en producción – y su precisión se desploma.

Antes de contratar un piloto, haga una auditoría honesta: dónde están los datos de la tarea, en qué formato, quién los ingresa y con qué consistencia. Si en esta etapa las cosas se ponen incómodas, es mejor ordenar los datos primero y lanzar la IA después. El enfoque de capa de papel que recomendamos como punto de partida funciona precisamente porque no requiere un conjunto de datos históricos limpio – el modelo trabaja con lo que usted le da en ese momento.

Señal 3. El equipo está enamorado de la tecnología, no del problema

La tercera causa en RAND está formulada sin rodeos: el proyecto está más entusiasmado con aplicar la tecnología más reciente que con resolver un problema real. En manufactura, esto se traduce en querer construir visión artificial con redes neuronales ajustadas donde un simple asistente de texto habría resuelto la tarea en una semana.

El informe de MIT señala un desequilibrio similar: más de la mitad de los presupuestos de IA generativa se destinan a vitrinas vistosas – ventas y marketing – mientras que el mayor retorno viene del aburrido back office. En la planta, el equivalente de la vitrina es la ‘fábrica inteligente’ para las visitas de inversionistas; el equivalente del back office es automatizar reportes de turno y gestiones de reclamaciones, algo que no impresionará a ningún consejo directivo pero que genuinamente ahorra horas.

Una pregunta de verificación para quien impulsa el piloto: ‘Si esta tecnología no existiera, ¿cómo resolveríamos este problema?’ Si no hay respuesta clara, la solución se inventó antes que el problema. Redirija la conversación del modelo hacia la tarea.

Señal 4. La tarea está fuera del alcance de la IA actual

La quinta causa en la lista de RAND: se aplica IA a tareas que son demasiado complejas para ella. No es una condena a la tecnología, sino una cuestión de límites. La IA es buena estructurando texto, reconociendo defectos típicos, encontrando análogos de piezas. Falla donde se necesitan eventos raros sin historial, razonamiento físico sobre equipos desconocidos o decisiones donde el costo del error es una vida humana sin un sistema de respaldo.

Resulta útil clasificar las tareas en tres grupos: ’la IA lo hace sola’, ’la IA prepara un borrador y una persona aprueba’, ‘por ahora sin IA’. La mayoría de las tareas de manufactura caerán honestamente en el grupo intermedio – y eso es normal. Los problemas empiezan cuando una tarea del tercer grupo se fuerza al primero bajo presión de plazos.

Señal 5. La deriva que nadie recuerda seis meses después

Esta es una trampa específica de manufactura que las implementaciones de oficina prácticamente desconocen. Un modelo de visión artificial que funcionaba brillantemente en el lanzamiento empieza a equivocarse unos meses después – y no porque alguien lo haya roto. Cambió la iluminación en la planta, el proveedor cambió a un grado de acero con un brillo ligeramente diferente, una cámara se desgastó, la temporada alteró la humedad. El modelo siguió igual; el mundo a su alrededor se movió.

El análisis de este efecto en la industria automotriz revela un patrón: los sistemas de inspección no se degradan de inmediato, sino meses después de un piloto exitoso, cuando el equipo de implementación ya fue disuelto y nadie pensó en el reentrenamiento. Un piloto sin plan de vida posterior al lanzamiento está condenado sin importar la calidad del arranque.

En el proyecto hay que incluir no solo el lanzamiento, sino la operación continua: quién y con qué frecuencia verifica la precisión, a partir de qué umbral se dispara un reentrenamiento, quién es el responsable. Si la respuesta es ’el equipo de implementación se irá y después vemos’, usted está pagando por un piloto que morirá según lo programado.

Señal 6. Todo depende de dos o tres personas

La cuarta causa en RAND: falta de infraestructura para gestionar datos y desplegar modelos. En la práctica, esto suele disfrazarse de dependencia de personal – el piloto funciona porque dos ingenieros entusiastas lo sostienen con alambre. Se fueron de vacaciones, cambiaron de trabajo o los reasignaron a otro proyecto, y el sistema se detuvo porque la infraestructura que lo mantendría vivo sin ellos no existe.

Verifique si el proyecto sobreviviría a la salida de cualquier persona individual. Si la respuesta es ’no’, usted no tiene un sistema implementado – tiene una demo que accidentalmente llegó a producción. Antes de escalar, necesita infraestructura mínima: un proceso documentado, controles de acceso, monitoreo y un calendario de actualizaciones.

Señal 7. El proyecto no tiene dueño del lado del negocio

Esta es la causa transversal que conecta todas las anteriores. RAND y BCG coinciden en un punto: los proyectos exitosos tienen un responsable de producto del lado del negocio – alguien que rinde cuentas por resultados en dinero, no por que ’el modelo fue entrenado’. Para gerentes de IT y de producto que están construyendo el mismo tipo de proceso dentro de sus equipos, el patrón es idéntico.

BCG describe la proporción de esfuerzo funcional para la implementación como 70/20/10: setenta por ciento se destina a personas, procesos y cambiar la forma en que opera la planta; veinte a tecnología y datos; y solo diez a algoritmos. Si en su proyecto es al revés y el 90% del presupuesto se va en licencias e integración, el desequilibrio es evidente.

El responsable del lado de la planta debe designarse antes de empezar, no después. Debe tener la autoridad para detener el proyecto – y la motivación para llevarlo hasta el uso diario.

Cómo reunirlo en un solo checklist

Antes de firmar el presupuesto para escalar un piloto, recorra siete preguntas. Cada ’no’ no es razón para abandonar la IA – es el punto donde el proyecto se romperá si no lo corrige antes.

• ¿Podemos ponerle cifra al problema?
• ¿Tenemos datos utilizables para esta tarea?
• ¿Estamos resolviendo un problema o admirando la tecnología?
• ¿Está esta tarea al alcance de la IA actual?
• ¿Hay un plan de vida del sistema después del lanzamiento, considerando la deriva?
• ¿Sobreviviría el proyecto a la salida de cualquier persona individual?
• ¿Hay un responsable del lado del negocio con autoridad para detener el proyecto?

El patrón de RAND se lee entre líneas de esta lista: seis de las siete preguntas son sobre gestión, y solo una sobre tecnología.

Y esto es lo alentador en medio de la estadística sombría. La capacidad de definir un problema, calcular su costo y separar ‘al alcance de la IA’ de ’todavía no’ – no es un talento innato ni una habilidad rara de consultores caros. Es una disciplina de gestión que se puede entrenar.

Artículos relacionados

Los managers y la IA: los que más la usan – pero no para dirigir

5 capas del agente IA: lo que un manager necesita saber

40 casos de GigaChat: contrastamos las cifras de Sber con un benchmark

Cómo implementar IA en la manufactura: plan paso a paso para directivos