Un checklist fail-closed para cuando una función de IA sale a producción

Un desarrollador ha publicado un checklist para el momento en que una función de IA deja la rama y aterriza en producción. La tesis es incómoda: un despliegue en verde no demuestra que hayas cortado el paso al entorno de laboratorio, solo demuestra que el proceso arrancó.

El fallo que describe no es "usamos un modelo". Es una ruta sin nombre: alguien pegó una URL base en un helper, un cliente generado la horneó como valor por defecto, un envoltorio de reintentos interpreta un 429 de producción como motivo para llamar al host de borrador. Nada de eso aparece en un test unitario que hace mock de complete().

Qué significa cortar el paso

Cuatro condiciones a la vez. La URL base de producción es un origen de una lista blanca, no un valor heredado de .env.local. El identificador de modelo es un contrato explícito, no default, latest ni cadena vacía. Los timeouts, los techos de tokens y el número de reintentos viven en la configuración de producción. Y el fallback es denegar por defecto: sin host de laboratorio, sin proveedor alternativo sin revisar, sin segundo intento contra el servidor de borrador.

Después vienen seis puertas, cada una con su recibo. Origen de producción nombrado, con el secreto coincidiendo con una lista blanca versionada: cualquier manifiesto que aún contenga localhost, 127.0.0.1, ngrok o trycloudflare falla. Identidad de modelo anclada y documentada en el runbook. Lista negra de hosts comprobada en CI, y aquí está el detalle que se suele pasar por alto: hay que mirar los ficheros desplegables —Helm, Terraform, overlay de Compose— y no solo src/. Presupuestos numéricos, con reintentos que no cambian de destino. Fallback que no puede volver al laboratorio: ante timeout, 5xx o error de cuota, la función devuelve un fallo visible y una métrica interna, sin un segundo cliente. Y identidad de tráfico, con cabeceras estables y una etiqueta prod para que los logs respondan qué aplicación, qué modelo y qué URL base sin abrir el código.

El recibo importa. Un visto bueno en Slack no cuenta. Vale el SHA del commit, el identificador de versión del gestor de secretos o la URL del job de CI del merge.

Un fichero de política que CI pueda rechazar

La pieza reutilizable es un inference-policy.json con la lista de URLs base permitidas, subcadenas de host prohibidas, las variables de entorno obligatorias (URL base, identificador de modelo, timeout, reintentos máximos y techo de tokens de salida), un máximo de reintentos y un campo booleano que prohíbe expresamente un base URL de fallback. El aviso del autor: el host de borrador no se cuela "solo para staging" en el mismo fichero que carga producción, staging lleva su propio overlay.

Todo esto lo firma alguien que ha visto el patrón repetirse. No hay demo ni herramienta publicada detrás, solo la lista de comprobación y un validador que inspecciona entorno y texto sin llamar a ningún modelo. Para quien tenga un chatbot o un resumidor a punto de salir, las puertas son accionables tal cual, y el sitio donde mirar es la parte que más se descuida: la configuración de despliegue, no el código de la aplicación. Queda por ver si alguien lo empaqueta como acción de CI o si cada equipo acaba reescribiendo su propio fichero.