Sesenta de cada cien organizaciones evaluaron una herramienta de IA para empresa, veinte llegaron a piloto y cinco a producción. Es el embudo que publicó MIT Project NANDA en julio de 2025, y dice algo incómodo: lo que mata una prueba de concepto casi nunca es el modelo, sino cómo se planteó.

Un caso que duela, aunque cueste medirlo

El mismo informe reparte el presupuesto y encuentra que cerca de la mitad se va a ventas y marketing. Su lectura es la que interesa: ese sesgo responde a que la métrica se atribuye fácil, no a que ahí esté el valor.

En una POC la tentación aparece igual de disfrazada: elegir el caso que encaja con una métrica que ya existe. Elige el proceso que duele. Si nadie del negocio se queja de él hoy, ningún resultado va a convencer a nadie de pagarlo mañana.

Una pregunta, un umbral y una fecha

Una POC responde una pregunta, no explora posibilidades. Y el umbral que decide si sigue o se mata se escribe antes de la primera línea de código, porque luego se mueve solo: con tres semanas invertidas, ese 70% de acierto que ibas a rechazar, pongamos, empieza a parecer prometedor.

Conviene aplicarle la misma vara a la fuente de arriba. El 95% de fracasos que hizo viral ese informe está discutido, y con razón: los críticos señalan que la cifra no se puede rastrear hasta los datos que el propio documento publica. Sirve de advertencia para tu prueba: un número que no puedes seguir hasta lo que mediste no es un resultado, es una sensación.

Al sistema del cliente no te conectas: lo doblas

Conectar con el ERP, el sistema de reservas o el core bancario es lo que más tarda y casi nunca es lo que estás probando. Un fake en el sentido de Fowler, una implementación que funciona de verdad pero toma atajos que la hacen inadecuada para producción, devuelve la semana que la integración se iba a comer. Así corre nuestro concierge de hotel cuando todavía no hay credenciales: el mismo agente, contra un doble que responde como el sistema real y con datos realistas.

La contrapartida cabe en una línea: el doble esconde justo los fallos de integración, así que la fecha en la que se cambia por el sistema de verdad se fija el primer día, no cuando la demo ya gustó.

Lo prueba quien no lo construyó

Quien lo escribió sabe qué frase funciona y la dice sin darse cuenta. Por eso la prueba la hace alguien de fuera, y sin jerga: nada de nombres de herramientas ni de vocabulario del manual. Si hay que dictarle la frase mágica para que el agente acierte, eso no es un detalle de la demo, es el hallazgo.

Lo que aprendemos operando agentes está en nuestros casos, y el gobierno que los sostiene en el OS de agentes. ¿Tienes un caso que duele y quieres saber si un agente lo resuelve? Hablemos.