Del POC a producción: por qué los prototipos de IA acaban en un cajón

La demo salió bien. El modelo respondió a las cinco preguntas que todos habían preparado, la sala asintió y alguien dijo "vamos a desplegarlo". Seis meses después, el prototipo sigue en un portátil y quien lo construyó está en otro proyecto.

Mientras tanto, el director general, que lo vio funcionar, sigue preguntando por qué no está en marcha. Oímos esta historia a menudo en las primeras llamadas sobre IA. El problema rara vez es el modelo. Es todo lo que la demo no tuvo que hacer.

Una prueba de concepto de IA responde a una sola pregunta: ¿puede esto funcionar? Tiene permiso para hacer trampa. Corre sobre veinte documentos limpios, con un solo usuario, sin inicio de sesión y con una clave de API pegada en un archivo de configuración.

El problema empieza cuando se trata la demo como si fuera casi todo el producto. La demo es, como mucho, una décima parte del trabajo. El resto son flujos de datos, pruebas, permisos de acceso, registros y alertas de facturación.

Nada de eso se ve en una demo, y todo eso decide si el producto llega a producción.

Datos reales, no una carpeta escogida a mano

La demo usó una carpeta que alguien preparó a mano. En producción entra lo que sus sistemas contienen de verdad: PDF escaneados, duplicados, tres versiones del mismo contrato, un CRM con la mitad de los campos vacíos.

El modelo que parecía certero con datos limpios empieza a adivinar. Las respuestas se desvían, las fuentes desaparecen y los usuarios dejan de confiar en él tras la segunda respuesta errónea. Rara vez se lo dicen; simplemente vuelven a trabajar como antes.

Así que la primera tarea de producción es poco vistosa. Averiguar dónde están los datos, de quién son, con qué frecuencia cambian y cómo llegan al modelo. En muchos proyectos esto lleva más tiempo que la parte de IA, y hay que planificarlo así desde el primer día.

Evaluación: nadie sabe decir si funciona bien

Pregunte al equipo de un prototipo estancado qué precisión tiene. La respuesta honesta suele ser "en las pruebas parecía ir bien". Nadie puede dar el visto bueno con eso.

Un producto necesita un conjunto de evaluación: unos cientos de casos reales, con la respuesta que daría una persona competente. Parta de las preguntas que hicieron los usuarios reales durante el piloto, no de las que el equipo preparó para la demo: sobre esas se ajustó la demo.

Cada cambio en el prompt, el modelo o los datos se prueba contra ese conjunto. Sin él, cada corrección rompe algo de lo que solo se enterará por un cliente.

También obliga a una conversación que la demo se saltó: qué tasa de error es aceptable para esta tarea. Un borrador de correo que falla una vez de cada diez es útil. Una decisión de reembolso que falla una vez de cada diez es un riesgo.

Lo que la demo nunca tuvo que gestionar

Nadie lo vigila

Un prototipo no tiene monitorización porque nadie depende de él. En producción alguien dependerá, y la primera mala respuesta le llegará como una captura de pantalla en un ticket de soporte, sin ningún registro que la explique. Necesita registros de lo que el modelo recibió y devolvió, alertas cuando cambian la latencia o la tasa de errores, y una forma de reproducir una mala respuesta para entenderla.

El modelo que probó también cambiará sin avisar: los proveedores retiran versiones y las actualizan, y sin el conjunto de evaluación no verá qué se ha roto.

La factura que nadie puso en la demo

Una demo atiende unas decenas de peticiones al día. Póngala delante de toda la plantilla, o en cada petición de cliente, y multiplique eso por mil, con contextos más largos de los que la demo vio nunca. La caché, los modelos más pequeños para los pasos sencillos y los límites por usuario son decisiones de diseño, y salen más baratas antes del lanzamiento que después de la primera factura.

Antes del lanzamiento, calcule el coste mensual con el volumen de producción, a partir del tamaño real de las peticiones, no de la factura de la demo.

El departamento jurídico hará preguntas que la demo no puede responder

Antes del lanzamiento, alguien tiene que responder a tres preguntas:

• Quién puede ver qué documentos a través del asistente, y si respeta los permisos de acceso de cada fuente.
• Dónde se guardan los prompts y las respuestas, durante cuánto tiempo y en qué país.
• Si un usuario puede hacer que el modelo revele lo que no debe, mediante una inyección de prompt o una búsqueda mal acotada.

Sus equipos jurídico y de seguridad lo preguntarán. El prototipo no tiene respuestas porque nunca le hizo falta. Decida primero el alojamiento (Europa, su propia nube o en sus instalaciones), porque condiciona qué modelos puede usar.

Un responsable: alguien tiene que operarlo en producción

Es el motivo menos técnico y el que más prototipos funcionales acaba enterrando. El prototipo lo construyó un equipo de innovación, un becario o una agencia con presupuesto cerrado. Cuando funciona, nadie queda designado para operarlo.

Un producto en producción necesita un responsable: alguien que lea los registros, actualice el conjunto de evaluación, gestione la próxima subida de precios del proveedor del modelo y decida qué mejorar. Sin esa persona, el sistema se degrada poco a poco y el negocio deja de usarlo sin hacer ruido.

Aquí es también donde fallan la mayoría de los traspasos. Quienes construyeron la demo se van, quienes la heredan no tomaron las decisiones, y el primer incidente tarda semanas en entenderse. Nosotros trabajamos al revés: las personas de la primera llamada construyen el producto y lo llevan a producción; después lo operan tras el lanzamiento o se lo traspasan ordenadamente a su equipo, con la documentación y el conjunto de evaluación que lo hacen mantenible.

Qué hacer con un POC de IA que ya tiene

Antes de que nadie escriba más código, envíe estas seis preguntas al equipo que lo construyó:

La mayoría de los prototipos estancados no necesitan rehacerse. Necesitan un alcance por escrito que diga qué falta entre la demo y el producto, y una respuesta honesta sobre si el caso de uso vale la pena. A veces no la vale: el volumen es demasiado bajo, los datos aún no existen o una herramienta más sencilla resuelve el problema.

Esa también es una respuesta útil, y sale más barata antes del segundo presupuesto que después. Cuando vale la pena, el camino es corto: un alcance que dice qué construimos y qué no, una demo cada semana y una primera versión en producción entre 3 y 6 semanas después del arranque.

Si tiene un prototipo en un cajón, tráigalo a una auditoría gratuita: basta con una grabación de la demo, y el repositorio y una muestra de datos si puede compartirlos. Una hora sobre su negocio y después un documento breve que dice qué hace falta para llevarlo a producción, o por qué debería quedarse donde está.