Una demo está diseñada para funcionar. Se ejecuta sobre datos preparados, con un usuario que tiene todos los permisos, siguiendo el camino que el producto resuelve mejor y sin ninguna de las excepciones que constituyen la operación real. Nada de esto es engañoso: es lo que una demostración es. El error está en tratarla como evidencia de que el sistema funcionará el lunes por la mañana en tu empresa.
La distancia entre ambas cosas explica una parte sustancial del abandono documentado. S&P Global Market Intelligence cifró en marzo de 2025 que el 42% de las empresas había abandonado la mayoría de sus iniciativas de IA, frente al 17% del año anterior, descartando de media el 46% de sus pruebas de concepto.
Dimensión | En la demo | El lunes en producción |
|---|---|---|
Datos | Seleccionados y completos | Incompletos, duplicados, contradictorios |
Permisos | Usuario con acceso total | Roles distintos, visibilidad restringida |
Volumen | Unos pocos casos | Miles, con picos y concurrencia |
Excepciones | Ninguna | Entre el 15% y el 30% del volumen |
Integración | Copiar y pegar entre pantallas | Conexión real con ERP, CRM e identidad |
Coste | Irrelevante | Coste unitario que decide la rentabilidad |
Ninguna de las seis columnas de la derecha se puede inferir observando la izquierda. Por eso una demo excelente no aporta información sobre el riesgo del proyecto: aporta información sobre la calidad de la interfaz y sobre el mejor caso posible.
La solución no es desconfiar de las demos, sino cambiar quién las diseña. Cinco peticiones concretas que se pueden hacer a cualquier proveedor serio:
Que use tus datos, aunque sean pocos. Cien registros reales, con sus duplicados y sus campos vacíos, enseñan más que diez mil sintéticos.
Que incluya un caso raro elegido por ti. No un caso raro genérico: el tuyo, con tu regla no escrita. Esta petición separa a quien ha construido un sistema de quien ha construido una presentación.
Que la ejecute alguien de tu equipo. No el comercial. La diferencia entre ver a un experto usar una herramienta y usarla uno mismo suele ser considerable.
Que muestre qué pasa cuando falla. Pídele que provoque un error. Cómo lo comunica, qué registra y cómo se recupera dice más del producto que cualquier funcionalidad.
Que dé el coste por caso a tu volumen. Extrapolado, con reintentos incluidos. Si no puede calcularlo, tú tampoco podrás presupuestarlo.
Un proveedor que acepta las cinco condiciones probablemente entrega lo que promete. Uno que aplaza tres de ellas a «una fase posterior de análisis» está indicando dónde aparecerán los sobrecostes.
Antes de firmar, conviene hacer un ejercicio mental concreto: describir el lunes por la mañana.
Un empleado concreto, con su perfil de permisos, abre el sistema y procesa el primer caso del día. Ese caso tiene un dato mal escrito, el cliente tiene una incidencia abierta y hay una condición comercial pactada por teléfono que no está en ningún sistema.
Las preguntas que hay que poder responder:
Si el proyecto no puede responder a las cinco, no está listo para producción, con independencia de lo buena que sea la demo. Es el mismo diagnóstico que planteamos en el purgatorio del piloto [enlace interno], aplicado antes de comprar en lugar de después.
Un piloto es mejor que una demo, pero comparte parte del problema: se ejecuta con usuarios voluntarios, con atención especial del equipo y sobre un subconjunto favorable.
Los tres elementos que convierten un piloto en información fiable:
Usuarios reales, no entusiastas. Quienes van a usarlo obligatoriamente, no quienes se apuntaron.
Casos consecutivos, no seleccionados. Todos los casos de una semana, incluyendo los feos.
Sin soporte extraordinario. Si durante el piloto hay un ingeniero atento a cada incidencia, el piloto mide el sistema más el ingeniero.
Un piloto diseñado así puede dar peores números que uno complaciente. Esos peores números son los verdaderos, y conocerlos antes de escalar vale mucho más que un informe optimista.
La conclusión práctica es sencilla y ahorra mucho dinero: el criterio de compra no debe ser lo bien que funciona la demo, sino lo bien que el proveedor explica dónde falla su producto.
Un proveedor que describe con precisión sus límites, sus casos no soportados y su comportamiento ante datos sucios está demostrando que ha operado el sistema en entornos reales. Uno que sostiene que todo funciona no ha llegado todavía a un lunes por la mañana.
Porque la demo usa datos seleccionados y completos, un usuario con permisos totales, volumen bajo, ninguna excepción y sin integración real con los sistemas existentes. Ninguna de esas condiciones se cumple en producción, y ninguna se puede inferir observando la demostración.
Cinco cosas: que use tus propios datos aunque sean pocos, que incluya un caso raro elegido por ti, que la ejecute alguien de tu equipo y no el comercial, que muestre qué ocurre cuando falla y que calcule el coste por caso a tu volumen real con reintentos incluidos.
Un ejercicio de evaluación consistente en describir el primer caso real de un lunes por la mañana: un empleado concreto, con su perfil de permisos, procesando un caso con un dato mal escrito, un cliente con incidencia abierta y una condición pactada verbalmente. Si no se puede describir qué ocurre, el sistema no está listo.
Solo si está bien diseñado. Debe ejecutarse con usuarios reales y no voluntarios entusiastas, sobre casos consecutivos y no seleccionados, y sin soporte extraordinario del equipo técnico. De lo contrario mide el sistema más las condiciones favorables que lo rodean.
S&P Global Market Intelligence cifró en marzo de 2025 que las empresas descartaban de media el 46% de sus pruebas de concepto, y que el 42% había abandonado la mayoría de sus iniciativas de IA frente al 17% del año anterior.
No lo bien que funciona la demostración, sino la precisión con la que el proveedor explica los límites de su producto: qué casos no soporta, cómo se comporta ante datos incompletos y qué ocurre cuando falla. Esa capacidad indica experiencia real en producción.
¿Vas a evaluar proveedores? Podemos definir los criterios, diseñar la prueba con tus datos y evaluar las ofertas con criterio técnico independiente, sin presentarnos como candidatos. Hablemos →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
