89% de los pilotos de IA nunca llega a producción
El motivo casi nunca es el modelo. Son cinco condiciones alrededor de él, y las cinco se pueden diagnosticar antes de firmar nada.
Hay una conversación que se repite en los comités este año. Alguien presenta un piloto de agentes de IA que salió bien, el equipo aprueba seguir, y doce meses después el proyecto sigue siendo un piloto.
No es mala suerte ni mala ejecución. Es un patrón, y está medido.
El tamaño del problema
| Deloitte tendencias tecnológicas 2026 | 89% |
|---|---|
| Estudios independientes rango reportado en 2026 | 86% a 88% |
El dato que más ordena la conversación es otro: el 78% de las empresas tiene al menos un piloto corriendo, y solo el 14% ha escalado alguno a toda la organización. Casi todo el mercado está en el mismo punto intermedio.
Lo que falla no es el modelo
Conviene decirlo con claridad porque ahorra meses: el mismo modelo que corre en el piloto corre en producción. Si el piloto funcionó, el modelo sirve.
Lo que cambia es todo lo que rodea al modelo. Los cinco motivos que más se repiten en los análisis de 2026 son siempre los mismos:
- Integración con los sistemas que ya existen. El piloto leyó una copia de los datos. Producción exige leer y escribir en el sistema real, con sus permisos, su latencia y sus casos raros.
- Calidad inconsistente a volumen. Cien casos escogidos se comportan distinto que cien mil casos reales.
- Falta de monitoreo. Si nadie ve qué decidió el agente y por qué, nadie puede autorizarlo a seguir.
- Nadie es el dueño. El piloto fue de innovación o de tecnología. La operación que debe absorberlo no participó, y no lo reclama.
- Datos propios del dominio insuficientes. El agente sabe de todo y no sabe de esta institución.
Ninguno de esos cinco se resuelve cambiando de modelo. Los cinco se detectan antes de firmar.
Un piloto y una operación no miden lo mismo
Aquí está la raíz de ese 89%. Un piloto está diseñado para demostrar que algo puede funcionar, y una operación para que funcione sin que nadie esté mirando. Son dos pruebas distintas, y aprobar la primera no dice casi nada sobre la segunda.
| Criterio | El piloto | La operación |
|---|---|---|
| Los casos | Escogidos, representativos, conocidos de antemano. | Todos los que entren, incluidos los raros que nadie previó. |
| Los datos | Una copia preparada para la prueba. | El sistema real, con sus permisos, su latencia y sus inconsistencias. |
| La supervisión | Alguien revisa cada caso. Es lo que hace que salga bien. | Nadie mira en tiempo real. El control es posterior y por muestreo. |
| El dueño | Innovación o tecnología, que lo presentan. | La operación, que responde por el resultado todos los días. |
| La economía | El costo del piloto, que casi siempre está subvencionado. | El costo por gestión a volumen real, que decide si el proyecto vive. |
| Qué demuestra | Que la tecnología puede resolver el caso. | Que la institución puede sostener el proceso sin vigilarlo. |
La diferencia concreta entre una columna y la otra es quién define los límites y dónde quedan escritos.
Esa es también la diferencia práctica entre contratar a alguien que opere el proceso por usted y construir el agente dentro de su propia institución. En el primer caso, las reglas son del proveedor. En el segundo, son suyas, están escritas y sobreviven a un cambio de proveedor.
Qué significa esto para quien decide
Si su institución está en la fase de piloto, la decisión relevante no es si continuar. Es si el piloto está midiendo la columna correcta.
Shimli opera hoy con 160 clientes activos en 15 países, con agentes en producción sobre cobranza, crédito, atención y operaciones internas. Esa es la diferencia que este artículo intenta hacer visible: no la de un modelo mejor, sino la de un proceso que ya pasó de la prueba a la operación.
Preguntas sobre este tema
- ¿Por qué un piloto que funcionó no llega a producción?
- Porque un piloto se evalúa con casos escogidos y supervisión constante, y producción exige lo contrario: volumen, casos raros, datos reales y nadie mirando. Los cinco motivos que más se repiten son la integración con sistemas heredados, la calidad inconsistente a volumen, la falta de monitoreo, la ausencia de un dueño claro dentro de la organización y la escasez de datos propios del dominio.
- ¿Qué distingue un piloto que sí va a escalar?
- Tres cosas medibles antes de firmar: que el agente ya lea y escriba en los sistemas reales y no en una copia, que exista una persona con nombre responsable del resultado dentro de la institución, y que el costo por gestión esté calculado a volumen y no solo en la prueba.
- ¿Conviene cambiar de modelo si el piloto se estanca?
- Casi nunca. El mismo modelo que corre en el piloto corre en producción, así que si el piloto funcionó, el modelo sirve. Lo que cambia es lo que rodea al modelo, y ninguno de los cinco motivos habituales se resuelve cambiándolo.
