El piloto eterno: por qué las pruebas de IA no llegan a producción en PYMEs (y cómo evitarlo)

Solo el 25% de los pilotos de IA llega a producción; 3 de cada 4 se quedan en demo o en prueba de concepto. En pymes el patrón se aprieta porque el piloto atascado consume la energía y la confianza del único equipo que iba a operar el sistema. Las tres causas son siempre las mismas: el piloto se diseñó para impresionar y no para integrarse (datos limpios de demo en lugar de datos sucios reales), nadie definió quién iba a operarlo cuando el proveedor se fuera, y no había criterio explícito de qué significaba “pasar a producción”. La salida son tres cláusulas firmadas antes de tocar código: criterios de salida medibles (por ejemplo, el 80% del flujo procesado durante 4 semanas sin proveedor), transferencia de capacidad como entregable (1 o 2 personas con nombre formadas como dueñas), y fecha vinculante de paso a producción en el calendario. Sin esas tres, el sistema no sale del piloto por inercia.

Y en PYMEs el patrón se aprieta todavía más, porque el piloto que se queda atascado consume el único recurso que no podéis reponer: la energía y la confianza del equipo que iba a operar el sistema.

Llamamos a esto el piloto eterno. Es el proyecto que arrancó con buena intención, dio resultados decentes en un entorno controlado, y se quedó congelado en ese estado. Ni se mata oficialmente — porque “lo retomaremos en Q3” — ni se pasa a producción — porque “todavía hay que ver lo de la integración con el ERP”. Pasan los meses y el sistema sigue ahí, con un usuario, sin métricas operativas, sin nadie del equipo del cliente que lo opere de verdad.

Hemos visto este patrón en empresas que invirtieron seis cifras y, 3 trimestres después, no podían responder a una pregunta simple: ¿quién opera esto cuando vosotros no estáis?

Por qué se queda en piloto

El piloto eterno casi nunca es un problema técnico. Cuando hacemos retrospectiva con clientes que vienen de una experiencia así, las causas son siempre las mismas tres, en este orden.

1. El piloto se diseñó para impresionar, no para integrarse. El proveedor enseña una demo brillante con datos de muestra, escenarios limpios, formatos previsibles. En cuanto se enchufa al ERP real con sus excepciones, sus campos sin rellenar y sus reglas no escritas, la cosa se atasca. No porque el modelo no funcione, sino porque el piloto no se diseñó pensando en los datos sucios que produce vuestra operación de verdad.

2. Nadie definió quién iba a operarlo cuando el proveedor se fuera. Esta es la más invisible. Se asume que “el equipo se encargará”, pero el equipo nunca participó en el diseño, no entiende la lógica del sistema, y cuando aparece la primera excepción, la respuesta es llamar al proveedor. La consultora cobra por hora cada llamada, y el sistema entra en un equilibrio raro: funciona técnicamente, pero el cliente nunca llega a ser dueño de él.

3. No había un criterio explícito de qué significaba “pasar a producción”. Sin esa definición, el momento del salto se posterga indefinidamente. Siempre falta un caso por probar, una integración por validar, un visto bueno por conseguir. El piloto se queda como puerto seguro porque mover el sistema a producción exige tomar una decisión y nadie quiere firmarla.

Las tres causas son resolubles. Pero hay que abordarlas antes de empezar el piloto, no cuando ya está atascado.

El contrato que evita el piloto eterno

En cada proyecto que arrancamos en Zero Ops, hay tres cláusulas que se firman antes de tocar código. Son pesadas de leer y aburridas de explicar. Pero ahorran trimestres enteros.

	Piloto eterno	Piloto productivo
Datos	Demo con datos limpios y casos felices	Datos sucios reales desde la semana 1
Operador	”El equipo se encargará” en abstracto	1-2 personas con nombre formadas como dueñas
Salida	”Cuando esté listo”	Fecha vinculante en el calendario
Criterio de éxito	Sensación general	80% del flujo procesado sin proveedor durante 4 semanas
Modelo del proveedor	Cobra cada llamada de soporte	Se va cuando se cumplen los criterios

Las tres cláusulas, en detalle:

Una. Criterios de salida explícitos y medibles. Antes de la primera línea de código se escribe en el contrato qué tiene que ser cierto para que el piloto se considere completado. Nada de “queda satisfactoriamente desplegado”. Frases como: el equipo de administración procesa el 80% de las facturas mensuales con el sistema sin intervención del proveedor durante 4 semanas seguidas. Si eso no pasa, el piloto no está cerrado y nosotros no nos vamos. Si pasa, nos vamos sí o sí, aunque el cliente nos quiera retener.

Dos. Transferencia de capacidad como entregable, no como cortesía. El sistema final lo opera el equipo del cliente, no nosotros. Y eso significa que durante el proyecto formamos a 1-2 personas concretas — no a “el equipo” en abstracto — para que sepan modificar el sistema cuando aparezca el primer caso raro. Si la administrativa que va a usarlo cada día no participa en las decisiones de diseño desde la semana 2, el proyecto está mal estructurado y lo paramos.

Tres. Pasaje a producción con fecha en el calendario. No “cuando esté listo”. Una fecha concreta, acordada al principio, que actúa como deadline forzado. Lo que no esté listo para esa fecha se escala o se descarta, pero el sistema pasa. Forzar el salto a producción saca a la luz todos los detalles que el piloto eterno mantiene en la sombra.

Estas tres cláusulas son incómodas para el proveedor, porque cierran la puerta al modelo de negocio basado en alargar el piloto facturando horas. Por eso casi nadie las firma. Y por eso casi todo el mundo se queda en piloto.

Lo que pasa cuando el contrato funciona

Contamos dos casos concretos donde lo aplicamos.

Caso 1 — OCR de facturas y albaranes en un distribuidor industrial. La empresa recibía decenas de facturas al día de proveedores con formatos completamente distintos. El equipo de administración tardaba 3 a 5 minutos por factura, con tasa de error del 2-5%, y las discrepancias de precio se detectaban semanas después de haber pagado.

La administrativa que llevaba una década procesando esas facturas a mano participó en el diseño desde la semana 2. El criterio de salida era: el sistema procesa el grueso del flujo diario sin intervención nuestra durante un mes natural completo. Lo cumplimos. Hoy esa misma persona pasó de teclear 400 facturas al mes a auditar las 400 que el sistema extrae y propone. Su criterio sigue siendo la capa crítica. Y cuando aparece un proveedor nuevo con un formato que el sistema no reconoce, ella ajusta las reglas. Sin llamarnos.

Caso 2 — Categorización de catálogo en la misma empresa. 508 tablas de productos, más de 3 millones de filas, 327 marcas con todas sus variaciones (MARCA-A, MARCA-A FILTER, MARCA-A+GROUP — todas la misma marca pero registradas como tres). El sistema corrió la normalización en 27 minutos.

Pero el entregable real no fue el script: fue que el equipo de operaciones del cliente puede volver a lanzarlo cuando integran un fabricante nuevo, sin nosotros. Eso es lo que hace que el sistema sea suyo.

En ninguno de los dos casos hablamos de “transformación digital” ni vendimos “ahorrar dos personas”. El equipo no se redujo. Se apalancó. Y los proyectos están en producción precisamente porque desde el día 1 había escrito en el contrato qué significaba estarlo.

Cómo saber si estás en un piloto eterno

Tres preguntas que cualquier director de operaciones puede hacerse esta semana sobre cualquier piloto de IA en marcha:

1. ¿Está escrito en algún sitio qué tiene que ocurrir para que este piloto se considere completado? Si la respuesta es “más o menos sí pero no exactamente”, el piloto se va a alargar.

2. ¿Hay alguien de tu equipo, con nombre y apellido, que pueda modificar el sistema cuando aparezca un caso que el proveedor no había previsto? Si la respuesta es “tendríamos que llamarles”, el piloto va a generar dependencia, no capacidad.

3. ¿Hay una fecha concreta de paso a producción en el calendario de alguien, además de en una diapositiva? Si la respuesta es no, el sistema no va a salir del piloto por inercia. Las cosas no se mueven solas.

Si las tres respuestas son “no” o “más o menos”, no estás en un piloto. Estás pagando por un sistema que nunca va a llegar a serlo.

El primer paso es operativo, no técnico

Cuando una PYME nos contacta diciendo que tiene un piloto atascado, lo primero que pedimos no es acceso al código. Es ver el contrato y el plan de transferencia. La mayoría de las veces no existe ninguno de los dos. A partir de ahí, la conversación cambia: ya no estamos hablando de IA, estamos hablando de cómo se opera la empresa.

Y eso, casi siempre, empieza por un diagnóstico operativo. 2 semanas. Mapear los procesos clave tal como funcionan hoy, detectar dónde se pierde tiempo y dinero, y entregar un plan con ROI estimado línea a línea. Sin compromiso de continuar. El entregable es del cliente para ejecutar con quien quiera.

Porque el problema con la IA en PYMEs no es la tecnología. La tecnología funciona. El problema es que se aplica a operaciones que nadie ha revisado, con contratos que no obligan a salir del piloto, y con equipos que nunca se diseñaron para operar el sistema final.

Resolver eso primero — antes de tocar IA — es lo que hace que el cuarto proyecto, ese del que casi nadie habla, llegue por fin a producción.

---

Si tu empresa tiene un piloto de IA atascado y quieres una segunda lectura honesta de qué hace falta para sacarlo de ahí, el diagnóstico operativo de 2 semanas es el primer paso. Sin pitch encubierto. El plan es tuyo, lo ejecutes con quien lo ejecutes.