Integrar un LLM en tu producto (el que ya funciona): qué hace un equipo senior en los primeros 30 días

El proyecto difícil con un LLM no es el que empieza de cero. Empezar de cero te da un repositorio vacío, ningún usuario al que romperle nada y ninguna factura con la que compararte. El proyecto difícil es el producto que ya funciona —clientes que pagan, un modelo de datos que alguien eligió hace tres años, una guardia, un margen— y en el que ahora alguien tiene que meter un modelo de lenguaje sin estropear nada de eso.

He dirigido ese proyecto varias veces, a los dos lados de la mesa, y he visto la otra versión: el hackathon de dos semanas que produce una caja de chat, la demo que impresiona al consejo y la funcionalidad que cuatro meses después alguien apaga sin ruido porque nadie sabe decir si acierta ni cuánto cuesta. La diferencia entre un resultado y el otro se decide en los primeros treinta días. No la decide el modelo, ni el framework. La decide el orden en que un equipo senior hace las cosas.

Este es ese orden, semana a semana. Parte de un producto con tráfico real y de un equipo que, mientras tanto, tiene que seguir entregando todo lo demás.

Semana uno: elige un solo flujo, mídelo y construye el set de evals con tráfico real

El primer error es poner «IA» como alcance. El alcance es un flujo de trabajo con un resultado medible: la respuesta de soporte que a un agente le lleva once minutos, la factura que clasifica una persona, la búsqueda que en un tercio de las consultas no devuelve nada útil. Un flujo que ya tiene un número asociado, porque el único trabajo del LLM es mover ese número.

Después, antes de escribir un solo prompt, el set de evals. Nada de ejemplos inventados: entre cincuenta y doscientos casos reales sacados de los logs de producción, con la respuesta que dio una persona competente, anonimizados donde los datos lo exijan. Este artefacto es el que sostiene todo el proyecto: con él sabrás en la semana cuatro si la cosa funciona, y con él sabrás en el mes seis si la actualización silenciosa del proveedor del modelo la ha roto. Los equipos que se saltan este paso no se saltan la evaluación: se la dejan a sus usuarios.

La semana uno termina también con un mapa de integración: en qué punto del código vivirá la llamada, qué datos verá, cuáles no debe ver nunca y qué servicio existente es el dueño del resultado. En un sistema con tres años encima, ese mapa suele destapar la primera tarea de verdad: un dato de contexto que vive en dos sitios y no coincide.

Semana dos: una rebanada fina detrás de un flag, con recuperación antes que generación

La segunda semana produce el camino de extremo a extremo más pequeño posible, en el código real, detrás de un feature flag que nadie fuera del equipo puede ver. Entrada desde el sistema real, una llamada al modelo, salida escrita donde el producto la espera. Que sea feo no importa. Lo que importa es que pase por tu CI, tu autenticación y tus logs, porque ahí es donde viven los problemas de integración, y salen más baratos en la semana dos que en la siete.

En la mayoría de flujos de producto el modelo necesita tus datos más que ingenio, y por eso la recuperación va antes que la generación. La rebanada fina incluye, por tanto, el camino de recuperación —qué se busca, dónde y con qué permisos—, aunque en la semana dos sea una consulta sencilla y en la cinco se convierta en un índice vectorial. Lo de los permisos no es opcional: un modelo al que se le puede preguntar por los registros de otro cliente es una brecha de datos con una interfaz amable.

Al cerrar la semana, el set de evals corre contra la rebanada. La puntuación será mala. Para eso está el número.

Semana tres: los evals pasan a ser la puerta, y el coste tiene techo antes de tener gráfica

La semana tres es la que separa a un equipo senior de un hackathon, porque la semana tres es aburrida. La ejecución de evals entra en la CI: cada cambio en un prompt, en una consulta de recuperación o en la versión del modelo pasa el set y devuelve la puntuación, y bajar del umbral bloquea el merge. Es la práctica que mantiene viva una funcionalidad con LLM más allá de su primera actualización de modelo. Un prompt sin eval es una opinión; un prompt con eval es un test.

Esa misma semana, el coste. Antes de que exista una gráfica de gasto existe un techo: un presupuesto de tokens por petición, un tope diario por tenant y un cortacircuitos que vuelve al comportamiento antiguo cuando se alcanza. Entre un modelo frontera y uno pequeño el precio cambia en dos órdenes de magnitud, y para la mayoría de flujos de producto la respuesta correcta es el modelo más barato que pase el eval, una decisión que solo puedes tomar si el eval existe. Ya he escrito sobre lo que les pasa a los equipos que tratan los tokens como métrica y no como coste; la versión corta es que la factura llega antes que el valor si el techo no está puesto primero.

La semana tres cierra también los modos de fallo, enumerados y probados: el modelo no responde a tiempo, devuelve algo que el parser no entiende, la recuperación no trae nada, la petición es una inyección de prompt colada por un campo de cliente. Cada uno tiene un comportamiento definido —volver atrás, reintentar una vez, rechazar, registrar— y cada uno está en el set de evals como un caso más.

Semana cuatro: el cinco por ciento del tráfico, con observabilidad y una decisión por escrito

El despliegue es pequeño a propósito. El cinco por ciento del tráfico, o un segmento de clientes, o solo usuarios internos —lo que permita el perfil de riesgo—, vigilando tres cosas: la puntuación de evals sobre muestras en vivo, el coste por petición contra el techo y la métrica humana de la semana uno. Una respuesta de soporte que llevaba once minutos ahora debería llevar menos; si no, la funcionalidad no se amplía, por bien que quedara en la demo.

La observabilidad de una funcionalidad con LLM no es la de un servicio. Necesitas guardar juntos, por petición, el prompt, el contexto recuperado, la versión del modelo y la salida, con una retención que respete tu política de datos, porque la única forma de depurar «la respuesta estaba mal» es ver exactamente lo que vio el modelo. Los equipos que solo registran la salida se pasan el mes dos adivinando.

El mes termina con una decisión escrita, una página: qué se ha construido, qué dice el eval, cuánto cuesta cada mil peticiones, qué ha hecho la métrica humana y uno de tres veredictos: ampliar, iterar o parar. Un veredicto de parar tras treinta días y un solo flujo es un éxito, no un fracaso; es la forma más barata que existe de descubrir que ese flujo no era el bueno. El fracaso es la funcionalidad que llega a todos los usuarios porque nadie escribió la página.

La objeción: treinta días es lento, y un proveedor lo hizo en dos semanas

El argumento en contra más fuerte es que todo esto es más lento que la demo, y la demo es lo que quiere el consejo. Es cierto, y se lo reconozco: si el objetivo es una demo, haz la demo, en una semana, en un sandbox, y no la conectes nunca a producción. Las demos son baratas y útiles, y yo también las hago.

El plan de treinta días no es para la demo. Es para la funcionalidad que seguirá corriendo dentro de un año, facturando tokens sobre tráfico real, después de dos actualizaciones de modelo y de que un ingeniero se haya ido. Esa funcionalidad necesita un set de evals, un techo de coste, una recuperación con permisos y observabilidad por petición, y ninguna de esas cosas se puede añadir después al precio que cuesta en las semanas una a tres. La versión de dos semanas no es más rápida: traslada los treinta días a después del lanzamiento, y entonces los pagan los usuarios.

Qué le pide esto al equipo

Nada de lo anterior requiere un equipo de investigación en IA. Requiere ingenieros senior que conozcan las costuras de tu código, y que al menos uno de ellos haya llevado ya una funcionalidad con LLM a producción y tenga las cicatrices: la inyección por el campo de dirección, la recuperación que filtró datos entre tenants, la actualización que cambió el formato de la respuesta un martes. Esa combinación escasea más que cualquiera de las dos mitades por separado, y por eso el encargo que más repetimos es uno o dos ingenieros senior integrados en el equipo del cliente durante esos treinta días, y no un proyecto de IA aparte entregado desde fuera.

Si tienes un producto que funciona y un flujo con un número encima, la primera conversación dura treinta minutos, y empieza por el set de evals.