# La mayoría de los agentes de IA nunca llegan a producción

La demo deslumbra. Después, el agente nunca sale a producción. Encuesta tras encuesta en 2025–26 encuentran el mismo abismo: casi todos tienen un piloto de agente, casi nadie lo tiene en producción. La razón no es el modelo: es la ingeniería poco glamorosa que la demo te dejó saltarte. Esto es lo que hace distinto la pequeña minoría que sí lo lleva a producción.

- **Author:** Fedor Chishchin
- **Published:** 2026-06-03
- **Tags:** agents, eval, methodology
- **Source:** https://fedorthinks.com/es/blog/agents-never-reach-production

---

Ya viste la demo. Un agente toma una petición vaga, se abre paso entre varias
herramientas, escribe el código, reserva el viaje, cierra el ticket: sin
fallas, en el escenario, con aplausos. Parece que el futuro llegó antes de
tiempo. Después, meses más tarde, notas en silencio que nunca salió a
producción. El piloto sigue siendo un piloto. Nadie lo está usando de verdad.

Esta es la historia más común en la IA ahora mismo, y vale la pena ser honesto
al respecto, porque la brecha entre "demo increíble" y "algo de lo que la gente
real depende" es donde muere casi cualquier agente.

## El abismo, en números

Esto no es una sensación: está medido, una y otra vez, y los números son
brutales.

La iniciativa NANDA del MIT publicó
[_The GenAI Divide_](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)
en 2025 y encontró que **el 95% de los pilotos corporativos de IA generativa no
generan ningún retorno medible**: solo alrededor del 5% llega a tener un
impacto real. Una encuesta de marzo de 2026 a 650 líderes empresariales
encontró la misma forma:
[**el 78% tenía pilotos de agentes, pero solo el 14% llegó a producción**](https://www.digitalapplied.com/blog/ai-agent-scaling-gap-march-2026-pilot-to-production).
Otro corte de los datos: **el 67% vio ganancias en el piloto, el 10% lo
escaló**, así que aproximadamente **el 90% se queda atascado** en la brecha
entre una prueba de concepto que funciona y un sistema del que alguien depende.

Sea cual sea la cifra exacta, el mensaje es idéntico: lograr que un agente
funcione _una vez, en una demo_ ya es fácil. Lograr que funcione _siempre, en
producción_ es donde se sale todo de control.

## Nunca fue el modelo

Esta es la parte que la gente entiende al revés. El modelo de tu piloto
fallido es el mismo modelo del piloto exitoso de cualquier otro. La frontera es
compartida; es una llamada a una API. Si el cuello de botella fuera la
capacidad pura del modelo, verías a unos pocos ganadores con modelos secretos y
a todos los demás perdiendo. Ese no es el patrón. El patrón son los _mismos
modelos_ teniendo éxito para unos pocos y atascándose para la mayoría.

El MIT fue tajante sobre dónde vive realmente el problema: las fallas se
remontan a una **"brecha de aprendizaje"**: empresas que no logran integrar el
modelo en flujos de trabajo, estructuras y datos reales, **no a la calidad del
modelo.** Un análisis de 2026 encontró que
[cinco brechas explican el **89% de las fallas de escalamiento**](https://www.digitalapplied.com/blog/ai-agent-scaling-gap-march-2026-pilot-to-production):
la integración con los sistemas existentes, la calidad inconsistente de la
salida a volumen, la falta de herramientas de monitoreo, la titularidad poco
clara y los datos de dominio escasos. Mira esa lista. Ninguna de ellas es "el
modelo no es lo bastante inteligente". Cada una es ingeniería y operaciones: el
trabajo que una demo te deja saltarte.

## Una demo es el mejor caso, cuidadosamente armado

La razón por la que las demos mienten es estructural, no deshonesta. En una
demo controlas todo: eliges la entrada, eliges el camino feliz, eliges el
momento. Estás mostrando que el agente _puede_ tener éxito, una vez, bajo
condiciones que tú elegiste.

Producción es lo opuesto a algo curado. Te manda entradas que jamás imaginaste,
a volumen, a las 3 de la mañana, en el formato equivocado, de usuarios que
activamente intentan romperlo. Y el componente en el medio es un
[adivinador no determinista](/blog/grounding-is-a-constraint). Un agente que
acierta el 90% de las veces es una demo triunfal y una pesadilla en producción:
a mil peticiones por día, eso son cien fallas seguras de sí mismas, todos los
días, acumulándose a lo largo de cadenas de varios pasos hasta que el agente se
desvía por completo de su tarea. La demo medía "¿puede funcionar?". Producción
mide "¿sigue funcionando con entradas que yo no elegí?": una pregunta
completamente distinta y mucho más difícil.

## Lo que de verdad hace la minoría que sí lo lleva a producción

Los equipos que cruzan la brecha no son los que tienen un prompt más ingenioso
ni un modelo secreto. Son los que hicieron la ingeniería aburrida que la demo
tentó a todos a saltarse. En concreto:

- **Miden en lugar de guiarse por la sensación.** Una demo se juzga por cómo se
  siente; producción se juzga con números. Los equipos que llegan a producción
  tienen un [conjunto de evals](/blog/evals-or-it-didnt-ship) apartado y
  conocen su tasa de éxito real antes que los usuarios. No puedes mejorar, ni
  siquiera confiar, en lo que no mides.
- **Hacen grounding del modelo.** Para que la respuesta número mil no esté
  equivocada con total seguridad, los hechos vienen de una fuente determinista
  y el modelo solo los redacta: una
  [restricción, no un prompt](/blog/grounding-is-a-constraint). Esta es la
  palanca más grande sobre la "calidad de salida consistente a volumen", que
  era uno de los cinco asesinos.
- **Lo instrumentan.** "Falta de herramientas de monitoreo" está en la lista de
  causas de fallo por una razón. Los sobrevivientes pueden ver qué hizo su
  agente, dónde se desvió y cuánto costó: en producción, no solo en un notebook.
- **Lo acotan en estrecho y le dan un dueño.** No un agente-dios que hace de
  todo en la demo, sino un agente pequeño con un trabajo definido, viviendo
  dentro de sistemas reales, con alguien que responda por él. La "titularidad
  poco clara" mata tantos pilotos como la mala tecnología.

Nada de eso es magia de IA. Es
[la misma disciplina de ingeniería](/blog/cheap-code-is-expensive) que separa
el software que perdura del software que se ve bien en la demo y se desmorona.
El agente simplemente hace la brecha más visible, porque un adivinador castiga
la falta de disciplina más rápido que el código común.

## La demo y el producto son habilidades distintas

Aquí está el núcleo incómodo de todo esto. Una gran demo optimiza para "mira lo
que esto puede hacer": capacidad máxima, un solo intento curado. Un sistema de
producción optimiza para "esto hace lo aburrido de forma confiable, para
siempre, con entradas que nadie filtró". No son la misma habilidad, y a menudo
están en tensión. La demo es esencialmente un artefacto de ventas. El producto
es uno de ingeniería. El 95% que se atasca construyó lo primero y supuso que lo
segundo vendría solo. No viene solo.

Así que si estás mirando un agente que deslumbra en la demo y no sobrevive al
contacto con usuarios reales, la pieza que falta casi con seguridad no es un
mejor modelo ni un prompt más inteligente. Es la parte poco glamorosa: evals,
grounding, monitoreo, alcance, titularidad: la ingeniería que convierte
"funcionó una vez" en "funciona siempre". La minoría que llega a producción no
es más lista respecto a la IA. Simplemente no se saltó el aburrido 80%.

Ese es todo el secreto. La demo es la parte fácil. Todos pueden conseguir la
demo. El producto es la ingeniería que viene después: y esa es la parte que
nunca fue opcional.