Del piloto de ChatGPT a la IA en producción: los pasos de ingeniería que los fundadores se saltan

Cada paso existe porque saltárselo es lo que hace fracasar el despliegue.

Paso uno: definir los modos de fallo en producción. Una demo solo tiene que funcionar; una funcionalidad en producción debe fallar correctamente. ¿Qué hace la funcionalidad cuando el modelo es lento, cuando el modelo se equivoca, cuando la entrada está malformada, cuando el usuario se comporta de forma adversaria? La mayoría de los pilotos no tienen respuesta; las funcionalidades en producción necesitan una para cada caso. Paso dos: construir el arnés de evaluación. Un conjunto de datos congelado de 100 a 500 entradas representativas, las métricas que importan, el umbral por debajo del cual la funcionalidad se desactiva. Hasta que la evaluación no existe, el modelo puede cambiar pero no puedes decir si el cambio fue una mejora.

Paso tres: presupuestos de coste y de latencia. ¿Cuál es el tope de coste por petición, el presupuesto de latencia p95, el tope de gasto mensual? Si no se especifican, la funcionalidad superará en silencio los tres ya desde el segundo mes. Paso cuatro: guardarraíles en la frontera. Anonimización de la información personal en la entrada, detección de inyección de prompt, filtrado de las salidas para las categorías de política aplicables, taxonomía de rechazo para los casos que el modelo no debería tratar. El piloto no hacía nada de eso y se salía con la suya porque el único usuario era el fundador. Paso cinco: el respaldo sin IA. Todo flujo asistido por la IA necesita un camino sin IA al que la empresa pueda volver en unos minutos cuando el modelo se rompe, deriva o se vuelve carísimo. El respaldo no es un cuadro de diálogo de experiencia de usuario; es un proceso manual funcional.

Paso seis: observabilidad. Registro por petición de las entradas, las salidas, la latencia, el coste y la puntuación de evaluación cuando aplica. Sin eso, el equipo depura a ciegas. Paso siete: el traspaso. Documentación, runbooks, conjunto de evaluación, panel, rotación de guardia. La funcionalidad no está en producción mientras el equipo que la operará no pueda hacerlo sin el equipo que la construyó. La mayoría de los sobrecostes que vemos provienen de saltarse el paso siete, el equipo de construcción se convierte en el equipo de operación permanente, y la economía unitaria se ve alterada por ello.

A través de los proyectos que hemos salvado, tres de los siete pasos se saltan casi siempre: el arnés de evaluación, el respaldo sin IA y la capa de observabilidad. La evaluación se salta porque parece superflua, el modelo funciona sobre las entradas que el equipo ha probado, y un conjunto de tests congelado «queda para más adelante». Luego el equipo necesita cambiar el prompt, o cambiar el modelo, o añadir una fuente de contexto, y no tiene ninguna manera de saber si el cambio dejó la funcionalidad mejor o peor. La mayoría de los desastres de ingeniería de prompts en producción son desastres de disciplina de evaluación y no desastres de prompts.

El respaldo sin IA se salta porque parece pesimista, el equipo acaba de construir la funcionalidad de IA, en lo último que quiere pensar es en el mundo donde no funciona. Luego seis meses después, el proveedor del modelo tiene una caída parcial, o el coste se triplicó, o el modelo fue retirado, o el entorno regulatorio cambia, y la empresa no tiene ningún respaldo. El coste de la caída es lo que el respaldo habría costado construir, tres veces en lugar de una.

La observabilidad se salta porque el piloto no la necesitaba. El único usuario era el fundador; el fundador recordaba lo que había tecleado. En producción, el equipo tendrá que depurar una queja llegada hace tres días, sobre un flujo que tocó ocho entradas, ninguna de las cuales se registró. El equipo pasará una semana intentando reproducir el bug de memoria y fracasará. Añadir la observabilidad de forma retroactiva es más caro que integrarla desde el principio.

Una funcionalidad de IA lista para producción posee, como mínimo, lo siguiente: un conjunto de datos de evaluación congelado integrado en el repositorio; el arnés de evaluación ejecutándose en cada cambio de prompt o de modelo; paneles de latencia, coste y calidad revisados cada semana; la anonimización de la información personal y la detección de inyección de prompt en la frontera; un respaldo sin IA documentado con un procedimiento de conmutación probado; un registro por petición con una retención dimensionada a la ventana de depuración más larga esperada; un runbook para el ingeniero de guardia; y un propietario documentado responsable de las métricas de la funcionalidad al duodécimo mes.

Cada elemento existe porque hemos visto el fallo que ocurre cuando falta. Cada elemento cuesta también menos de construir que el coste del fallo. La economía no es sutil, el equipo que entrega esas siete cosas pasa unas semanas adicionales en el lanzamiento y ahorra unos trimestres adicionales de depuración y reconstrucción.

Nos negamos a desplegar IA sin la lista de verificación. No porque queramos parecer rigurosos, sino porque la alternativa es un despliegue que el cliente no puede mantener una vez nos hemos ido, lo que no es un entregable. El traspaso comprende cada elemento de la lista de verificación, bajo gestión de versiones, con la documentación escrita para el ingeniero que la heredará.

La verdadera prueba de un despliegue de IA en producción es cómo se ve doce meses después, y no el día del lanzamiento.

Los despliegues que envejecen bien comparten tres propiedades. El conjunto de evaluación se ha actualizado al menos dos veces a medida que el flujo ha evolucionado, y no se ha abandonado. El respaldo se ha probado de verdad al menos una vez, aunque el modelo nunca se haya roto, confirmando que el camino sigue funcionando. El equipo que opera la funcionalidad no es el equipo que la construyó, el traspaso transfirió de verdad la propiedad.

Los despliegues que fracasan comparten las tres propiedades inversas. El conjunto de evaluación está caducado de seis meses, porque nadie lo posee. El respaldo existe únicamente en la documentación, sin probar. Y el equipo de ingeniería original sigue siendo el equipo de soporte de facto, porque la documentación nunca permitió que otra persona tomara el relevo.

Cuando SDEN termina un proyecto de IA, el traspaso es aquello por lo que se juzga el entregable. La funcionalidad funciona el primer día; eso es el mínimo. La funcionalidad sigue funcionando el día trescientos sesenta y cinco, poseída por tu equipo, eso es la culminación del proyecto.