La demo salió redonda. El modelo leyó el correo, entendió la petición, redactó una respuesta perfecta y la sala aplaudió. Tres meses después, ese piloto sigue siendo exactamente eso: una demo que alguien enciende cuando viene un directivo. Nunca pasó a producción. No es mala suerte ni falta de presupuesto para "más IA": es el patrón más común del sector. La demo impresiona porque enseña la parte fácil. Producción es todo lo que la demo, por diseño, se saltó.
Por qué fracasan los pilotos de IA (y casi nunca es por el modelo)
Los números del último año son incómodos. La encuesta Voice of the Enterprise de S&P Global Market Intelligence (2025) encontró que el 42% de las empresas abandonó la mayoría de sus iniciativas de IA en 2025 —frente a un 17% el año anterior—, descartando casi la mitad de sus pruebas de concepto antes de que llegaran a producción. IDC, por su parte, calculó que el 88% de los pilotos de IA no superan el salto a despliegue amplio: solo 4 de cada 33 pruebas de concepto graduaron a producción. No es que el modelo no fuera capaz en la demo. Es que "capaz en la demo" y "en producción" son dos cosas distintas, y la segunda no se compró.
Conviene separar dos preguntas que la demo mezcla a propósito. La primera —"¿puede el modelo hacer esto?"— casi siempre tiene un sí. La segunda —"¿puede tu empresa operar esto todos los días, con tus datos, tus sistemas, tus permisos y tus excepciones?"— es la que decide si hay proyecto. La demo responde la primera y esconde la segunda. Por eso una demo brillante es tan mala señal como buena: prueba lo que ya casi nunca falla y calla lo que siempre falla.
El 70% que la demo se salta
BCG lo resume en un principio que se ha vuelto famoso por lo bien que envejece: el éxito de un proyecto de IA es 10% algoritmos, 20% datos y tecnología, y 70% personas, procesos y cambio cultural. La demo vive entera en el primer 10%. El foso entre el piloto y la producción es ese 70% —más el 20% de fontanería de datos— que ninguna presentación de ventas enseña porque no da vídeo bonito.
Ese 70-90% invisible es, en concreto, esto:
- Datos de verdad, no de laboratorio. La demo corre sobre tres ejemplos limpios. Producción recibe PDFs torcidos, campos vacíos, duplicados y el correo que no sigue ninguna plantilla. Sin datos fiables y accesibles, el mismo modelo que brilló en la demo empieza a inventar.
- Integraciones. El resultado tiene que entrar y salir de tus sistemas —CRM, ERP, correo, base de datos— con autenticación, permisos y trazabilidad. Ese cableado es el 80% del trabajo real y el 0% de la demo.
- Casos raros y manejo de errores. La demo no tiene casos raros; el martes sí. ¿Qué pasa cuando el modelo no está seguro, cuando la API cae, cuando el dato llega a medias? Un sistema en producción tiene respuesta para eso. Una demo, no.
- Observabilidad y coste. En producción necesitas ver qué hace el sistema, cuándo se equivoca y cuánto cuesta cada ejecución a escala. Un piloto sin instrumentación no se puede gobernar: se apaga al primer susto.
- Propiedad y adopción. Alguien tiene que ser dueño del sistema, mantenerlo y conseguir que el equipo lo use de verdad en lugar de volver al Excel de siempre. Sin dueño y sin adopción, hasta el mejor sistema se muere solo.
Demo vs producción: no es el mismo proyecto
| Dimensión | En la demo | En producción |
|---|---|---|
| Datos | Tres ejemplos limpios y elegidos | Todo lo que entra, sucio y a cualquier hora |
| Errores | No aparecen | Son la mitad del diseño |
| Integración | Copiar y pegar el resultado | Entra y sale de tus sistemas con permisos |
| Coste | Irrelevante (una ejecución) | Se mide por ejecución, a escala |
| Dueño | El que hizo la demo | Alguien que lo mantiene cada día |
| Éxito | Que impresione en la sala | Que funcione sin que nadie mire |
Hay una versión de este fallo que es de operación —el 70% de arriba— y otra que es de diseño: prometer que el sistema se gobierna solo y soltarlo sin la persona que lo gobierna. Esa segunda la desarrollamos aparte en el mito del agente 100% autónomo. Y a veces la conclusión honesta es que ese proceso no había que automatizarlo entero: eso lo tratamos en cuándo NO automatizar un proceso con IA. Aquí el foco es otro: aunque el proceso sea buen candidato y el humano esté bien colocado, el piloto se muere igual si nadie construye el 70% aburrido.
Cómo se cruza el foso
El orden que funciona invierte el de la demo. La demo empieza por el modelo y espera que lo demás encaje solo. Un sistema empieza por el proceso y trata el modelo como una pieza más:
- Empieza por el proceso, no por el modelo. Mapea cómo se hace el trabajo hoy —dónde se atasca, qué excepciones aparecen, quién decide qué—. Es lo que separa automatizar procesos con IA de comprar una herramienta y rezar.
- Presupuesta el 70% desde el día uno. Datos, integraciones, manejo de errores y adopción no son "fase dos": son el proyecto. Si el plan solo cubre la demo, ya sabes cómo acaba.
- Instrumenta antes de escalar. Mide acierto, coste por ejecución y qué se escala a un humano. Un sistema que no se puede medir no se puede gobernar.
- Pon un dueño y un humano en el bucle. Alguien mantiene el sistema y una persona revisa justo donde el criterio pesa más que la velocidad. Es la lógica de montar procesos internos con agentes: la IA hace el pico y pala, el humano decide lo que importa.
Nada de esto sale en un vídeo de noventa segundos, y por eso el sector prefiere venderte la demo. Nosotros hacemos lo contrario: montamos el 70% aburrido, lo conectamos a tus sistemas, lo instrumentamos y lo dejamos corriendo un martes cualquiera sin que nadie lo mire. Se llama automatización de operaciones, y se cobra por lo que funciona en producción, no por lo que impresiona en la sala.