Lo que hay que decidir antes de meter IA en un producto que ya funciona

Hay una asimetría curiosa en los proyectos de inteligencia artificial. Levantar algo que funcione en una demo cuesta días. Ponerlo delante de usuarios reales, en un producto que ya está en producción y del que alguien depende para trabajar, cuesta meses. Y la diferencia entre las dos cosas no es técnica.

La demo se juzga por si impresiona. El producto se juzga por si se puede responder de él.

La pregunta que casi nadie hace primero

Antes de elegir modelo, antes de hablar de coste por token o de tiempos de respuesta, hay una pregunta que ordena todo el proyecto: ¿qué pasa cuando se equivoque?

No “si”. Cuando. Un sistema probabilístico se equivoca por definición, y el diseño entero depende de cuánto duele ese error:

• Si el error lo detecta el usuario de inmediato y sólo le hace perder diez segundos, se puede ser agresivo: automatizar, sugerir, arriesgar.
• Si el error es silencioso y se propaga a un documento, a un cobro o a una decisión que alguien tomará dentro de tres semanas, hay que ser conservador: el modelo propone y una persona confirma.

Esta única distinción determina más del proyecto que la elección de modelo. Y es una decisión de negocio, no de ingeniería.

Tres decisiones previas

De ahí salen las tres cosas que conviene tener resueltas antes de construir:

1. Qué error es aceptable, expresado en algo medible. “Que funcione bien” no es un criterio. “Que en el 95% de los casos el usuario acepte la sugerencia sin editarla” sí lo es. Sin un número acordado, cualquier resultado será simultáneamente un éxito y un fracaso, según quién lo mire.

2. Quién responde cuando falla. Si un modelo redacta algo que llega a un cliente, hay alguien de la organización cuyo nombre está detrás de ese texto. Conviene que esa persona lo sepa antes del lanzamiento y no después del incidente. Cuando esta pregunta no tiene respuesta, la respuesta de facto es “nadie”, y eso significa que el sistema se apagará en cuanto haya el primer problema serio.

3. Cómo se sabrá si ha mejorado algo. Esta es la que más se salta. Muchos proyectos de IA no tienen línea base: nadie midió cuánto tardaba el proceso antes. Sin ese dato, al terminar no se puede demostrar valor, y un proyecto que no puede demostrar valor no consigue el segundo presupuesto.

El coste que aparece después

Una cosa más, y es la que más subestimo yo mismo cuando planifico: un sistema con IA tiene un coste de mantenimiento distinto al del software convencional.

El software tradicional, si nadie lo toca, se comporta igual el año que viene. Un sistema que depende de un modelo externo, no: el proveedor actualiza versiones, retira otras, cambia comportamientos sutiles en las respuestas. Y los datos sobre los que opera también cambian. Lo que hoy acierta el 95% de las veces puede acertar el 85% en seis meses sin que nadie haya cambiado una línea de código.

Eso significa que hace falta evaluación continuada, no sólo pruebas antes de lanzar. Es un coste recurrente, y es honesto ponerlo en el presupuesto desde el principio en lugar de descubrirlo cuando ya está en producción.

Por qué insisto en esto

Porque el patrón se repite con cada ciclo de tecnología. Es el mismo que describí en la transformación digital no es un proyecto de tecnología: la parte difícil no es construir la herramienta, es decidir de antemano qué significa que funcione y quién responde de ella.

La IA lo ha hecho más visible porque ha abaratado tanto la construcción que ya no hay ninguna fricción técnica que obligue a pensar antes. Se puede tener un prototipo funcionando en una tarde. Y esa facilidad, paradójicamente, es lo que hace que tantos proyectos se queden encallados en la fase de piloto: se construyó antes de decidir.