La prueba de IA funcionó. Por eso lleva siete meses siendo una prueba.
He visto la misma escena lo suficiente como para reconocerla por el olor. Alguien del equipo monta en dos tardes algo que clasifica los correos de soporte, o que resume las llamadas de ventas, o que redacta el primer borrador de una respuesta. Lo enseña en una reunión. Todo el mundo asiente. Se aprueba seguir. Y medio año después eso sigue siendo exactamente lo mismo: un script que una persona ejecuta a mano los martes, con un archivo que se pasa por WhatsApp.
Nadie lo llama fracaso. Y ese es el problema, porque un fracaso se entierra y se aprende. Una demo eterna se mantiene con vida, consume atención cada trimestre y ocupa el hueco del proyecto que sí habría cambiado algo.
Una demo y un sistema no se parecen en nada
Una demo tiene que funcionar una vez, delante de gente, con datos que eliges tú. Un sistema tiene que funcionar todos los días, sin que nadie mire, con los datos que le lleguen. Son dos problemas distintos, y el segundo no es “el primero pero más grande”.
La demo se construye eligiendo veinte casos que representan bien el problema. Producción no elige: te manda el correo reenviado tres veces con una firma corporativa de cuarenta líneas, el PDF escaneado torcido, el cliente que escribe en tres idiomas en el mismo párrafo y el registro que viene con el campo de teléfono vacío porque alguien renombró el formulario el jueves.
Ahí es donde revienta. No por el modelo. Por todo lo de alrededor.
Lo que separa una cosa de la otra casi nunca es la parte de IA:
- Dónde entran los datos y dónde salen. Un piloto vive de copiar y pegar. Un sistema necesita que el dato entre solo y aterrice en el sitio donde el equipo ya trabaja: el CRM, el ticket, la ficha del cliente. Si el resultado acaba en un documento que hay que abrir aparte, no lo abrirá nadie.
- Qué pasa cuando falla. Y va a fallar. La API caerá, el modelo devolverá algo raro, el documento vendrá vacío. Un piloto se queda colgado y ya. Un sistema reintenta, registra y avisa a alguien con nombre y apellidos.
- Cómo sabes que sigue acertando. Un piloto se valida a ojo la semana que se construye. Un sistema necesita una medida: sobre una muestra fija, cuántas veces acierta y cuántas no. Sin eso no puedes saber si ha empeorado.
- Quién es el dueño. El piloto lo lleva el que lo montó, en sus ratos. Producción necesita a alguien responsable de que funcione, con tiempo asignado para ello.
- Qué decide el modelo y qué no. Esto es lo que más se salta. Un piloto puede permitirse que el modelo “decida” porque hay un humano revisando cada salida. En producción, cualquier cosa que toque accesos, cobros o precios tiene que decidirla código determinista. Hablo de eso largo y tendido en cómo se construyen agentes sin perder el control.
Ninguno de esos cinco puntos es “más inteligencia”. Son fontanería, contabilidad y responsabilidad. Aburrido. Por eso no sale en las demos.
Por qué pasa: el piloto se diseñó para convencer, no para funcionar
Esta es la parte incómoda. Muchos pilotos de IA no se montan para resolver un proceso. Se montan para conseguir un sí en una reunión.
Y cuando el objetivo es convencer, tomas decisiones distintas sin darte cuenta: eliges el caso de uso que mejor se ve, no el que más duele; trabajas con datos limpios, no con los reales; enseñas el resultado, no la tasa de acierto. Todo eso es legítimo para explorar. El error es creer que lo que has construido es un principio de sistema, cuando en realidad es una maqueta que se ha quedado sin camino por delante.
Hay un segundo motivo, más prosaico. Casi nadie pone en el presupuesto inicial lo que cuesta llevar algo a producción. Se aprueba el piloto porque es barato. Y cuando llega la factura de verdad (integraciones, permisos, logs, alertas, el proceso de revisión, el dueño), el proyecto se compara con su propia versión barata y parece caro. Así que se queda donde está, en la demo, que al menos ya está pagada.
Qué hago yo en su lugar
Antes de tocar nada, pongo por escrito una frase: qué proceso deja de hacerse a mano si esto funciona. Una frase, con un nombre de proceso real y una persona que hoy lo hace. Si no soy capaz de escribirla, el piloto no es un piloto, es una curiosidad. Y las curiosidades se hacen un viernes, no con presupuesto.
Después, el piloto se prueba contra los datos feos. Los de verdad, los del mes pasado, con las firmas, los reenvíos y los campos vacíos. Si la tasa de acierto sobre una muestra real no te vale, mejor saberlo la primera semana que después de firmar tres meses de desarrollo.
Y en el diseño, los caminos de vuelta antes que el camino de ida. Qué pasa si el modelo no responde. Qué pasa si responde una cosa que no encaja en el formato esperado. Quién recibe el aviso. Esto es lo mismo que exijo a cualquier automatización, con IA o sin ella: un proceso que puede fallar en silencio no está terminado.
Lo que queda casi siempre es más pequeño de lo que se aprobó en la reunión. Un trozo del proceso, no el proceso entero. Pero ese trozo sí entra en producción, sí se mide y sí se puede ampliar. Un sistema pequeño funcionando le gana a un sistema grande imaginado, todos los días de la semana.
El criterio que te llevas es este: un piloto no se evalúa por lo bien que sale en la demo, sino por lo cerca que está de aguantar un martes cualquiera sin que nadie lo mire. Si nadie ha respondido a “quién lo arregla cuando falla”, todavía no estás construyendo. Y construir sin entender es fracaso con buena pinta.
