La pregunta que las demos nunca responden
Cualquier demo de IA se ve bien cuando todo sale perfecto: la búsqueda funciona, el servidor no se cae, el paso 4 no falla. El problema es que tu empresa no opera en el mundo de las demos — opera en el mundo real, donde una conexión se corta, una API externa tarda de más, o alguien cierra la laptop a mitad de un proceso.
La pregunta que de verdad importa no es "¿funciona cuando todo sale bien?". Es: ¿qué pasa cuando algo falla a la mitad?
Por qué esto no es un detalle técnico menor
Piensa en un proceso de coordinación multi-país, con proveedores en tres ubicaciones distintas y decenas de pasos encadenados. Si ese proceso se cae en el paso 12 de 20, hay dos escenarios posibles:
Escenario malo: todo lo hecho hasta ahí se pierde. Hay que empezar de cero, y encima nadie sabe con certeza qué se alcanzó a hacer y qué no — ¿se le mandó el correo al proveedor o no? ¿se guardó la cotización o hay que pedirla de nuevo?
Escenario correcto: el sistema retoma exactamente desde el paso 12, no desde el paso 1. Y sobre todo: si algo se ejecutó dos veces por error — un reintento automático — eso no significa que se le cobró dos veces al proveedor equivocado, ni que se le mandó el mismo correo duplicado a un cliente.
La diferencia entre ambos escenarios no es un tecnicismo de programadores. Es la diferencia entre poder confiarle a un sistema un proceso real de tu empresa, o tener que revisar manualmente cada ejecución "por si acaso".
Los tres principios que separan un sistema serio de una demo
1. El estado se guarda paso a paso, no solo al final. Si el proceso falla, se retoma desde el último punto guardado — no desde el inicio. Esto es lo que hace que automatizar un proceso largo sea seguro y no una apuesta.
2. Ninguna acción externa se puede duplicar por error. Enviar un correo dos veces, cobrar dos veces, confirmar una cotización dos veces — inaceptable. Un sistema bien construido garantiza que, aunque un paso se reintente, el efecto hacia afuera ocurre una sola vez.
3. Ninguna ejecución se da por terminada sin quedar registrada. El resultado final — qué se hizo, en cuánto tiempo, con qué output — se registra siempre. Eso es lo que permite decir con números reales cuánto tiempo se ahorró, no con una impresión.
Por qué esto importa más cuanto más grande es el proceso
En una empresa que produce eventos, si una búsqueda de proveedores falla a mitad de camino, el costo de rehacerla es una tarde perdida. Molesto, pero manejable.
En una empresa industrial que coordina proyectos de 400 mil a 1,7 millones de horas-hombre entre varios países, un proceso que se cae y no se puede retomar de forma confiable no es una molestia — es un riesgo real sobre decisiones que involucran millones de dólares. Ahí, la pregunta "¿qué pasa si falla a mitad de camino?" deja de ser una curiosidad técnica y se convierte en la pregunta que decide si un sistema es apto para producción o solo sirve para una demo.
La pregunta que hay que hacerle a cualquier proveedor de automatización
No preguntes "¿qué tan rápido es?". Un sistema rápido que se cae sin avisar y no sabes en qué quedó, no sirve.
Pregunta: "si esto falla a la mitad, ¿qué pasa? ¿Se retoma solo, se duplica algo, o desaparece el trabajo hecho hasta ahí?"
Si no hay una respuesta clara a esa pregunta, la respuesta real es que todavía no lo pensaron — y tú vas a ser quien lo descubra en producción, con tu proceso real, no en una demo.