¿Demo o sistema? Cómo distinguirlos antes de pagar, o antes de lanzar

Una buena demo emociona. Alguien escribe una pregunta, la pantalla responde, todos en la sala asienten. Ya sea que estés por aprobar un presupuesto o por lanzar algo que construiste tú mismo con una herramienta de IA, ese momento se siente como una prueba. Y lo es, pero de una sola cosa: que la idea puede funcionar una vez, en buenas condiciones.

Un sistema es otra cosa. Sigue funcionando un martes en la tarde cuando los datos vienen desordenados, un usuario hace algo raro y nadie del equipo está mirando. La distancia entre los dos es donde vive la mayor parte del costo y del riesgo. Así puedes verla antes de que te cueste.

Lo que esconde una demo

Una demo es como una casa modelo: amueblada, limpia, con la luz perfecta. En el recorrido no puedes saber si la plomería funciona. Casi siempre faltan cinco cosas detrás de las paredes:

• Solo el camino feliz. La demo sigue la ruta que quien la hizo sabe que funciona. Los usuarios reales toman todas las demás: dejan campos vacíos, pegan un correo entero en la casilla del nombre, hacen clic dos veces en el botón.
• Datos de muestra. Diez registros ordenados, elegidos para verse bien. Tus datos reales tienen duplicados, valores faltantes, formatos viejos y algún registro que nadie sabe explicar.
• Sin errores. ¿Qué pasa cuando un servicio externo está lento o la IA da una respuesta extraña? En una demo, eso nunca aparece.
• Sin usuarios. Una persona, una pantalla. No cincuenta personas a la vez, cada una con permiso para ver cosas distintas.
• Sin seguridad. Contraseñas en el código, sin inicio de sesión, todo abierto, porque era “solo una demo”. Eso está bien para una demo y es peligroso para cualquier cosa con clientes reales.

Nada de esto significa que la demo fuera deshonesta. Las demos son útiles: muestran si vale la pena seguir con una idea. El problema empieza cuando una demo se vende, se compra o se lanza como si estuviera terminada.

Señales de que estás frente a un sistema real

No necesitas leer código para verlas. Solo tienes que pedir que te las muestren.

• Datos reales. Ya corrió con tus propios datos, o con una copia realista, no con una muestra escogida a mano. Pregunta qué se rompió la primera vez.
• Pruebas. Las pruebas son pequeños controles automáticos que confirman que el software sigue haciendo lo que debe después de cada cambio, como la lista que revisa un piloto antes de cada vuelo. Pregunta qué cubren y cuándo se ejecutan.
• Monitoreo. Monitorear significa que el sistema informa sobre su propia salud: errores, respuestas lentas, costos fuera de lo normal. Sin eso, la primera persona en notar un problema es un cliente.
• Manejo de fallas. Hay un plan para cuando algo sale mal: un mensaje claro para el usuario, un reintento, el paso del caso a una persona. Pide ver qué pasa cuando el servicio de IA no está disponible.
• Alguien responsable. Una persona o un equipo con nombre que recibe la alerta, arregla el problema y contesta tu llamada. Un sistema sin dueño poco a poco vuelve a ser una demo.

Qué preguntar antes de pagar, o antes de lanzar

Si alguien te está vendiendo el trabajo, pregúntale. Si lo construiste tú con una herramienta de IA, pregúntate a ti mismo, y pregúntale también a la herramienta: muchas veces te dice qué se saltó si se lo preguntas directamente.

1. ¿Qué pasa con datos desordenados, incompletos o equivocados?
2. ¿Qué pasa cuando la IA da una respuesta equivocada o extraña? ¿Quién lo notaría, y cómo?
3. ¿Qué pasa cuando un servicio externo se cae?
4. ¿Quién puede entrar, y qué puede ver y cambiar cada persona?
5. ¿Dónde se guardan las contraseñas y las claves?
6. ¿Cómo sabemos que sigue funcionando después de un cambio?
7. ¿Cómo nos vamos a enterar de un problema antes de que nos lo diga un cliente?
8. ¿Quién es responsable una vez que está en producción, y cuánto cuesta eso al mes?

Las buenas respuestas son concretas y un poco aburridas: “los errores llegan a este panel y le avisan a esta persona”. Las respuestas vagas, como “es bastante robusto” o “eso lo vemos después”, te dicen que todavía estás viendo una demo.

El problema no es la demo. Es cobrarla como sistema.

Convertir una demo en un sistema es trabajo normal, y muchas veces es la mayor parte del trabajo. La versión honesta de la conversación suena así: “Esto prueba la idea. Hacerlo seguro para usuarios reales significa agregar estas piezas, y va a tomar este tiempo”. Si escuchas eso, estás hablando con alguien que conoce la diferencia. Si el precio y el plazo asumen que la demo está casi lista, espera sorpresas después del lanzamiento, y espera pagarlas entonces.