La mayoría de los pilotos de IA se estancan por motivos que poco tienen que ver con el modelo. Los datos están más desordenados que en la demostración, el ERP no tiene una conexión utilizable, nadie es responsable del resultado, nadie aprueba lo que produce y nadie acordó qué significa «terminado». Un piloto llega a producción cuando un flujo de trabajo tiene un responsable, un paso de aprobación y una medida antes de construir nada.
#Ideas clave
- Un piloto que funcionó en una demostración ha probado el modelo, no el flujo de trabajo que lo rodea.
- Los bloqueos habituales son los datos, la integración con sistemas antiguos, la responsabilidad, la aprobación y la falta de una definición de «terminado».
- Integrar la IA en un ERP antiguo sin una API utilizable es un proyecto de integración que la mayoría de los planes de piloto nunca incluyeron.
- Un piloto llega a producción cuando una persona designada es responsable de él y otra aprueba lo que produce.
- Empieza con un flujo de trabajo y usuarios reales, no con tres pilotos y un comité de dirección.
#¿Por qué se estancan los pilotos de IA antes de llegar a producción?
No es el único si tres pilotos acabaron en tres demostraciones. Gartner, julio de 2024 predijo que el 30 % de los proyectos de IA generativa se abandonarían tras la prueba de concepto, por la mala calidad de los datos, unos controles de riesgo débiles y un valor de negocio poco claro. Un informe del MIT, recogido por Virtualization Review sobre el informe MIT NANDA, agosto de 2025, concluyó que el 95 % de las organizaciones no obtuvo ningún retorno de negocio de la IA generativa.
En las empresas con mucho peso operativo aparecen una y otra vez las mismas cinco carencias:
- Datos: el piloto funcionó con una muestra limpia. Las entradas reales llegan como PDF escaneados, formularios a medio rellenar y mensajes en árabe y en inglés.
- Integración: el flujo de trabajo se ejecuta en un ERP de hace quince años. Nunca se definió cómo leer de él y escribir de vuelta.
- Sin responsable: el piloto pertenecía a un equipo de innovación, y el departamento que iba a usarlo nunca lo pidió.
- Sin paso de aprobación: nadie decidió quién revisa el resultado antes de que llegue a un cliente, a un proveedor o a la contabilidad.
- Sin medida de «terminado»: el piloto se juzgó por si impresionaba, no por una cifra que el departamento ya sigue.
#¿Qué cambia cuando un piloto se construye para funcionar en producción?
Cambia el orden del trabajo. En lugar de empezar por un modelo, Stennir empieza mapeando un flujo de trabajo con la persona que lo ejecuta: dónde llega la entrada, qué reglas se aplican, adónde va el resultado y qué excepciones requieren criterio. Ese mapa se convierte en la especificación y muestra pronto si el verdadero bloqueo son los datos o la integración.
Después se acuerdan tres cosas antes de construir: quién es responsable del flujo de trabajo en el cliente, quién aprueba el resultado y qué medida cuenta como «terminado», como el volumen de trabajo pendiente o la proporción de casos gestionados sin repetir trabajo. El desarrollo se hace dentro de los sistemas que el equipo ya usa, con cada acción registrada, y los usuarios reales lo ven desde la primera versión.
#¿Cómo llevar a producción de forma segura un prototipo de hackathon?
Un prototipo de hackathon es una prueba útil. Demuestra que la tarea es posible. Lo que suele faltarle es gestión de errores, controles de acceso, registros, un conjunto de prueba creado a partir de casos reales y una forma de apagarlo. Trata el prototipo como un borrador de especificación, no como la primera versión.
El camino seguro es reconstruir las partes que tocan a clientes o dinero detrás de un paso de aprobación, probarlas con un conjunto de casos reales anteriores y añadir supervisión antes de incorporar más usuarios. El ejemplo práctico sobre cómo llevar un prototipo de IA a producción recorre esos pasos en un flujo de trabajo.
We are
Stennir lleva un flujo de trabajo del piloto a la producción dentro de tus propios sistemas, con un responsable designado, una persona que aprueba el resultado y una medida acordada de antemano.
We aren't
Stennir no es un laboratorio que hace más pilotos, ni un proveedor de plataformas que te pide trasladar tu trabajo a una herramienta nueva.
#Nuestro proyecto está atascado en la fase de prueba. ¿Qué hacemos primero?
Elige el piloto que tu departamento realmente quiere y pide a la persona que lo usaría a diario que describa el trabajo que sustituye. Si no puede, el piloto resolvía el problema equivocado. Si puede, anota las excepciones, designa un aprobador y acuerda la medida. Eso suele revelar si la carencia está en los datos, en la integración o en la responsabilidad.
Los equipos del Golfo suelen añadir un paso más: el flujo de trabajo tiene que gestionar entradas en árabe y en inglés, no solo la muestra en inglés con la que se probó el piloto. Comprobarlo pronto evita otro estancamiento más adelante.
#¿Qué debería hacer ahora un director de operaciones con pilotos estancados?
Elige un piloto estancado y un responsable, y llévelos a una conversación sobre implementación de IA, en la que Stennir construye un flujo de trabajo que funciona con usuarios reales y lo mantiene supervisado después. Si no estás seguro de qué piloto lo merece, la consultoría de IA prioriza antes las opciones. Consulta también IA para operaciones. Puedes hacer la evaluación de preparación gratuita o reservar una llamada de 30 minutos.
#Preguntas frecuentes
¿Qué necesitan de nosotros para reactivar un piloto estancado?
El propio piloto, la persona que lo usaría a diario, un conjunto de casos reales anteriores y acceso a los sistemas de los que debe leer y en los que debe escribir. Designas además quién aprueba el resultado. Stennir usa todo eso para mapear el flujo de trabajo y averiguar cuál de las cinco carencias lo detuvo.
¿Pueden reutilizar lo que ya construyeron nuestros desarrolladores?
A menudo, sí. Un prototipo muestra qué instrucciones y pasos funcionan. Stennir conserva lo que resiste la prueba con casos reales y reconstruye lo que falta para producción: control de accesos, registros, gestión de errores, un paso de aprobación y supervisión. Tus desarrolladores pueden seguir implicados y conservar el código, que permanece en tus cuentas.
¿Funciona con un ERP antiguo que no tiene una API adecuada?
Puede funcionar, pero es trabajo de integración y se define como tal desde el principio. Las opciones incluyen leer exportaciones, usar directamente la base de datos con acceso de solo lectura o trabajar a través de las pantallas que tu equipo ya usa. Stennir concreta el enfoque antes de construir, para que no sorprenda a nadie más adelante.
¿Qué podría fallar en producción que no falló en el piloto?
Las entradas reales están más desordenadas, los volúmenes son mayores y aparecen casos límite que la muestra nunca tuvo. Por eso Stennir mantiene a una persona aprobando el resultado, registra cada acción, hace pruebas con casos reales anteriores y supervisa los resultados en cuanto empiezan los usuarios reales, para que los problemas aparezcan como cifras y no como quejas.
