Por qué los proyectos de IA no pasan del piloto (y cómo evitarlo)

· · Summum IA

Antes de seguir. El Gobierno presentó el Plan IA360 el 21 de septiembre de 2026: es un anuncio, no una convocatoria abierta, y hoy no hay bases ni plazo para pedir nada. Lo que viene a continuación no depende de esa ayuda para ser cierto — es la explicación de por qué tantos proyectos de IA se quedan atascados en el piloto, con bono público o sin él.

Una empresa prueba un asistente que responde correos, un clasificador de facturas o un chatbot para atención al cliente. Funciona bien en la demo, con los ejemplos que alguien preparó para enseñarlo. Tres meses después, nadie lo usa: el equipo volvió al proceso manual, o el piloto sigue "en pruebas" sin que nadie recuerde por qué no pasó a producción. No es un problema del modelo. Casi siempre es un problema de cómo se planteó el proyecto antes de escribir la primera línea de código.

Es también, en parte, la explicación de una cifra que el propio Plan IA360 pone como diagnóstico de partida: solo el 21,1 % de las empresas españolas de diez o más empleados utilizaba inteligencia artificial en el primer trimestre de 2025, según la encuesta del INE sobre TIC (Plan IA360, proyecto tractor 10). El objetivo del plan es llegar al 55 % en 2030. Muchas de esas empresas ya han probado la IA en algún momento; lo que arrastra la cifra hacia abajo es que buena parte de esos pilotos nunca llegó a convertirse en un uso real y sostenido.

El caso de uso que nadie pidió

El error más común no está en la tecnología, está en el punto de partida. Alguien en dirección decide "vamos a meterle IA a algo" y elige el proceso que suena más impresionante en una presentación, no el que de verdad le quita horas al equipo. Un generador de contenido llamativo compite mal, en horas de trabajo ahorradas, con un clasificador aburrido que ordena cien correos al día. El piloto que sobrevive no es el más vistoso: es el que resuelve un cuello de botella que alguien puede señalar con el dedo.

No hay línea base que medir

Si nadie escribió, antes de empezar, cuánto tardaba el proceso a mano y cuántos errores tenía, no hay forma honesta de decir después si el piloto mejoró algo. La comparación se vuelve subjetiva — "parece que va mejor" — y una impresión subjetiva no convence a quien tiene que decidir si el proyecto sigue o se cierra. La línea base se mide antes del primer despliegue, no se reconstruye de memoria cuando alguien pregunta si funcionó.

El piloto no tiene dueño después de la demo

Un piloto que depende de la persona que lo impulsó se muere cuando esa persona cambia de prioridad. Falta quien revise las excepciones, quien decida si el modelo se equivocó o si fue el proceso el que cambió, quien apruebe pasar de diez casos de prueba a los cien que llegan cada semana. Sin un responsable operativo, el piloto no fracasa de forma ruidosa: se apaga solo, y tres meses después nadie sabría explicar cuándo dejó de usarse.

Los datos no estaban listos, y eso se descubre demasiado tarde

El documento que iba a alimentar el sistema resulta que tiene tres formatos distintos según quién lo rellenó. El histórico de conversaciones con clientes está repartido entre un CRM, una bandeja de correo y los apuntes de una persona que ya no está en la empresa. Nada de esto se ve en la demo, porque la demo se construye con los datos más limpios que hay a mano. Se ve en la semana tres de producción real, cuando entra el primer caso que no encaja en ningún patrón previsto.

El método que el propio plan describe para el bono, sin necesidad de esperarlo

El Plan IA360 fija cómo prevé implantar el bono empresarial de IA: «diagnóstico previo de madurez, identificación de un caso de uso concreto y medición posterior del impacto en productividad, con una primera fase que permita validar el modelo antes de su escalado» (Plan IA360, proyecto tractor 11). No hace falta que exista convocatoria para copiar ese orden: primero se mide de dónde se parte, después se elige un único proceso concreto, y solo entonces se despliega, con la forma de comprobar si funcionó ya decidida de antemano. Es la secuencia que separa un piloto que llega a producción de uno que se queda en la carpeta de proyectos pendientes — el plan prevé exigirla para dar dinero público a través del bono; una empresa puede aplicarla sin esperar a que exista convocatoria.

El responsable operativo no es un detalle administrativo

En un despliegue de agentes bien planteado, la persona con autoridad sobre el proceso firma la acción que cuesta dinero o que llega directamente al cliente hasta que el modelo demuestra estabilidad por encima de un umbral definido de antemano — ese umbral es, literalmente, la línea base convertida en criterio de decisión. Cuando el proyecto es más sencillo — conectar el CRM, el correo y una hoja de cálculo con un modelo de lenguaje en medio, sin construir un agente completo —, la vía de entrada más barata suele ser automatización con n8n: el flujo y sus credenciales quedan en la infraestructura de la empresa, aunque el propio texto que se envía al modelo de lenguaje sale o no según dónde se ejecute ese modelo — la misma pregunta que trata dónde viven tus datos cuando usas IA. Si funciona, es la propia automatización la que revela si conviene subir a algo más sofisticado.

Cuatro señales de que tu piloto no va a escalar

Preguntas frecuentes

¿Qué se hace con un piloto que lleva meses "en pruebas" sin que nadie lo cierre?

Se le pone una fecha de revisión y un responsable con autoridad para decidir, aunque sea con retraso. Un piloto sin esos dos elementos no muere de forma visible: se queda abierto indefinidamente, consumiendo atención sin que nadie lo note hasta que alguien pregunta por qué sigue ahí.

¿Quién debe ser el dueño del piloto dentro de la empresa?

Alguien con autoridad operativa sobre el proceso que se está tocando, no solo quien tuvo la idea. Esa persona revisa las excepciones, decide si un fallo es del modelo o del proceso y autoriza el paso del volumen de prueba al volumen real.

¿Un piloto que no escala significa que la IA no sirve para mi empresa?

No necesariamente. La mayoría de las veces significa que el caso de uso, la métrica o los datos de partida no estaban bien definidos antes de empezar, no que la tecnología fallara. Repetir el mismo error con otro proceso da el mismo resultado.

¿Necesito un proyecto complejo para empezar, o puedo probar con algo pequeño?

Lo segundo suele funcionar mejor. Un flujo acotado con automatización y un modelo de lenguaje como un nodo más es, para muchas pymes, la forma más barata de comprobar si el proceso escala antes de construir algo más ambicioso.

Para seguir

Este método de validar antes de escalar es el mismo que prevé la guía completa del Plan IA360 para el bono empresarial. Y es también la lógica que sostiene la Red NEURONA, pensada para que una pyme pruebe con sus propios datos antes de comprometerse.