Un proveedor te enseña una demo. Lee facturas, clasifica correos o contesta consultas de clientes, lo que necesites. Sale perfecta: rápida, limpia, sin un solo fallo. Firmas, la conectáis a tu operación real y tres semanas después alguien del equipo te dice que no se puede fiar de ella. El proveedor jura que es el mismo producto. Tiene razón, y ese es justo el problema: lo que cambió entre la demo y producción no fue el sistema, fue el material con el que se probó.
La tesis en una línea: la demo no falla por mala fe, falla por selección de muestra. Los documentos que mandaste eran los limpios, los tickets eran los bien escritos, y los casos que rompen el caso de negocio nunca llegaron a entrar. Lo que viste no era una prueba, era un ensayo.
Por qué la demo de IA no se parece a producción
Porque alguien eligió los casos. Casi siempre, tú, con la mejor intención del mundo. Te piden ejemplos para la prueba y mandas los que tienes a mano: los documentos bien escaneados, los tickets que alguien escribió con frases completas, los clientes que siguen el proceso tal como lo dibujaste en el papel. Con esos, cualquier sistema razonable luce bien. Además, el proveedor se prepara con ellos: ajusta el prompt, afina las reglas, resuelve las rarezas que aparecen. Cuando llega la demo, el sistema ya ha visto el examen.
Producción no es esa muestra. Es la distribución entera, con sus colas: el escaneo torcido, el correo de tres líneas sin contexto, el cliente con dos razones sociales, la factura rectificativa que llega un viernes por la tarde. Un sistema evaluado solo sobre la parte fácil de la distribución no está probado, está ensayado. Es la misma lógica por la que un porcentaje de acierto no basta en producción: el número depende de qué casos entran en la cuenta.
Qué se queda fuera de una demo, y por qué es justo lo que cuesta dinero
- Los documentos feos. Fotos hechas con el móvil, PDFs escaneados del revés, tablas partidas entre dos páginas, formatos de hace cinco años que nadie ha dado de baja.
- Los mensajes mal escritos. Frases a medias, dos idiomas en el mismo correo, referencias a una conversación anterior que el sistema no tiene.
- Las excepciones del negocio. El cliente con condiciones especiales, el pedido que mezcla dos tarifas, el caso que solo conoce la persona que lleva diez años en el puesto.
- Lo raro y lo hostil. Entradas vacías, duplicados, adjuntos que no son lo que dicen ser, alguien probando los límites del sistema.
Hay algo peor que la frecuencia: los casos raros no cuestan lo mismo que los normales. Un error en un ticket sencillo se corrige en un minuto. Un error en la factura de un cliente grande, o en la respuesta que llega a dirección, se paga en confianza. Por eso una demo perfecta sobre los casos fáciles dice poco sobre el coste real de poner el sistema en marcha.
El número que importa no es la media, es el tramo malo
Si te dicen que el sistema acierta «casi siempre», pregunta sobre qué. Una media alta puede esconder que los casos fáciles salen casi todos bien y los difíciles casi todos mal, y que tu caso de negocio depende de los difíciles. Si el proceso se justifica porque hoy alguien pierde horas con las excepciones, un sistema que resuelve lo que ya era fácil no te ahorra nada. Mira el peor tramo: qué pasa con los casos más complicados, qué errores comete y con qué frecuencia, cuáles se detectan solos y cuáles llegan hasta el cliente. Eso es lo que exige medir el rendimiento de tus automatizaciones desde el primer día.
Qué pedir en lugar de una demo: un método de compra en cinco pasos
- Una muestra aleatoria, elegida por ti. Coge los últimos casos reales de un periodo, sin filtrar ni limpiar, y no se los enseñes al proveedor antes de la prueba. Si los elige él, volvemos al punto de partida.
- Con los raros dentro. Añade a mano los casos que más te duelen: los que escalaron, los que acabaron en queja, los que solo resuelve una persona del equipo.
- Criterio antes de ver el resultado. Decide por escrito qué error es aceptable en cada tipo de caso y cuál no lo es nunca. Si defines el listón después, acabas defendiendo lo que ya has visto.
- Lee los fallos, no solo el porcentaje. Revisa a mano los casos que fallan. Errores repartidos al azar y errores concentrados siempre en el mismo tipo de cliente son problemas distintos, aunque den el mismo porcentaje.
- Pruébalo con tus datos, en tu entorno. Con tus permisos, tus formatos y tus sistemas conectados. Una evaluación de la calidad de los agentes de IA existe precisamente para repetir esta prueba cada vez que algo cambia, no solo antes de comprar.
Cuándo la demo sí sirve
No todo es desconfianza. Una demo es útil para ver si la interfaz encaja con cómo trabaja tu equipo, si las integraciones existen de verdad y si el flujo tiene sentido. También basta cuando el coste de un error es pequeño y reversible: un borrador que una persona revisa antes de enviarlo no necesita un protocolo de evaluación. La demo responde a «¿esto puede hacerse?». No responde a «¿esto aguanta mi operación?», que es la pregunta por la que se firma.
Qué leer en la reacción del proveedor
Cuando propones la prueba con muestra aleatoria y casos difíciles, la reacción te dice más que la demo. Un proveedor serio la acepta, te ayuda a diseñarla y te enseña los fallos junto con los aciertos. Uno que se pone a negociar la muestra, a pedir «un caso representativo» o a cambiar el criterio de éxito acaba de enseñarte cómo será la relación cuando algo falle en producción.
Si estás comparando opciones, cómo elegir una herramienta de automatización con IA te da el resto de criterios. Y si ya pasaste por un piloto que lució y no llegó a producción, la demo no es el proyecto cuenta lo que viene después de firmar.
La frase para llevarse: una demo no prueba que el sistema funciona, prueba que existe un conjunto de casos para los que funciona. Tu trabajo, antes de firmar, es averiguar qué casos no están en ese conjunto.