12. Industrialización: CI/CD, contenedores y ciclo de vida

1 · QUÉ ES — PARA PROFANOS

Industrializar es la diferencia entre una demo y un servicio. La demo funciona delante de ti;

el servicio funciona de madrugada, se actualiza sin romperse, y si algo sale mal, vuelve atrás

solo. Todo lo que sigue son las herramientas de ese oficio.

Tres metáforas, una por pieza:

- CI/CD — el robot que comprueba y despliega. Cada cambio pasa los tests (CI: continuous

integration) y, si todo está verde, sale a producción solo (CD: continuous delivery). El

objetivo: que desplegar sea aburrido. Si desplegar da miedo, el sistema no está

industrializado.

- Docker — la maleta. Metes tu programa y todo lo que necesita (versión de Python, librerías,

configuración) en una caja que funciona igual en tu PC y en cualquier servidor. Adiós al "en mi

máquina funciona".

- Kubernetes — el jefe de mudanzas. Decide en qué servidor va cada maleta, duplica las

importantes, reinicia las rotas y amplía en horas punta.

Y una pieza específica de IA — MLflow, el cuaderno de laboratorio + vitrina: cada experimento

queda registrado (qué modelo, qué parámetros, qué métricas), y ningún modelo pasa a producción sin

pasar de staging a production en la vitrina. Todo versionado, todo reversible. El principio

que hay debajo es más viejo que la IA: nada entra en producción sin pasar una puerta, y todo lo que

pasa queda registrado.

El pipeline estándar de una solución de IA:

Lo específico del mundo IA frente al software clásico: además de los tests de código, hay

evals — el sistema se prueba contra el conjunto dorado antes de desplegar (documento 07). Y la

"configuración" incluye prompts y modelos versionados, no solo variables. Un despliegue de IA

sin evals en el pipeline es un despliegue a ciegas.

Las prácticas que separan un senior:, Práctica, Qué es,, Infraestructura como código, la infraestructura es un archivo (Bicep, Terraform), no clics en un portal,, Despliegues graduales, canary: primero el 5 % del tráfico, luego todo,, Rollback real, volver atrás en minutos, no "arreglarlo sobre la marcha",, Mocks locales, desarrollar contra datos falsos para no gastar cuota ni tocar producción,, Observabilidad desde el día uno, métricas, logs y trazas antes de que algo falle, Los errores típicos: desplegar a mano ("funcionaba cuando lo probé"), no tener rollback (y

descubrirlo el día que hace falta), y el peor de todos — el prototipo que llega a producción por

inercia, sin puertas, sin versionado y sin saber qué versión corre dónde.

- LLMOps: el MLOps clásico (entrenar y versionar modelos) se transforma: con LLMs ya no se

entrena tanto, pero se versionan prompts, índices y guardrails. Los pipelines llevan evals

automáticos y el "model registry" guarda configuraciones de sistema, no solo pesos.

- Serverless para IA: Workers de Cloudflare, Azure Functions, y modelos servidos sin servidor.

El coste pasa de "servidores siempre encendidos" a "pago por uso real". Es la dirección de

nuestros despliegues.

- Inferencia en el borde: modelos pequeños en WebAssembly, en el dispositivo del cliente. Latencia

mínima, datos que no salen de casa. Es exactamente la dirección de LUMEN: 22 KB de WASM.

- GitOps: la verdad del sistema es el repositorio — cualquier cambio de configuración es un

commit revisable. El portal de gestión deja de ser fuente de verdad.

- Evaluación en el pipeline como estándar de compliance: con DORA y la AI Act, el registro de

evals en cada despliegue empieza a ser exigible, no recomendable.

Dos pilas de industrialización, según la nube, con el mismo criterio.

En Azure — SentryAI: FastAPI en App Service, Bicep como infraestructura como código,

despliegue por GitHub Actions, y desarrollo contra mocks locales para no gastar cuota. Todo

reproducible: la infraestructura es un archivo, no clics.

En Cloudflare — Contorn: Workers desplegados por wrangler, 13 despliegues versionados

(último en julio, respondiendo hoy con /api/health en verde), base de datos, almacén y colas como

servicios gestionados. Desplegar es un comando; volver atrás es otro.

Y el ciclo de vida de modelos, hecho con nuestra herramienta propia — el gate determinista:

Lo que MLflow llama model registry — nada entra en producción sin pasar la puerta y quedar

versionado — lo tenemos como política de promoción con rollback automático. No versionamos

pesos de modelos entrenados: versionamos agentes, prompts y pruebas de evaluación, que es lo

que un sistema LLM realmente cambia.

Lo que corre sin intervención, cada día: la batería de evaluación cada 6 horas, la revalidación

de la cadena de modelos dos veces al día, y el ciclo semanal de pruebas nuevas. Todo con su

registro — y es ese registro el que convierte la operación en evidencia (documentos 07 y 08).

Y la honestidad de la pieza que no operamos: Kubernetes. Usamos contenedores gestionados (App

Service, Workers) y conocemos el modelo, pero no hemos administrado un clúster K8s — y no

diríamos lo contrario. Dicho con 29 años de sistemas detrás, eso no resta: suma.

> "Participar en la industrialización y puesta en producción de soluciones de IA." ·

> "Documentar arquitecturas, decisiones técnicas y componentes desarrollados." — y como

> plataformas valorables: "Docker y Kubernetes", "CI/CD", "MLflow u otras herramientas relacionadas

> con el ciclo de vida de modelos".

"¿Cómo pones una solución de IA en producción?"

> "Con puertas y con registro. El código pasa tests y evals contra el conjunto dorado antes de

> desplegar; la infraestructura es código (Bicep en Azure, wrangler en Cloudflare); el despliegue es

> un comando, y el rollback también. Y la regla de casa: nada entra en producción sin pasar la

> puerta de evaluación y quedar versionado. Si desplegar da miedo, es que falta una de las dos

> cosas."

"¿Has trabajado con Kubernetes?"

> "He trabajado con contenedores gestionados — App Service por debajo son contenedores — pero no

> he administrado un clúster K8s, y prefiero decirlo a fingirlo. Conozco el modelo: qué resuelve,

> cuándo merece la pena y cuándo es peso muerto para un equipo pequeño. El día que el tráfico lo

> justifique, se aprende; la parte difícil —industrializar y operar con rollback real— ya la

> practico a diario."

"¿Has usado MLflow?"

> "No la herramienta. Tengo la función que cumple: un gate de evaluación con promoción versionada

> y rollback automático — nada entra en producción sin pasar la puerta. Tú no entrenas modelos

> igual que yo no los entreno: versiono agentes, prompts y pruebas. Aprender MLflow son días; lo

> que no se aprende en días es qué merece la pena versionar y a partir de qué umbral se para un

> despliegue."

"¿Cómo documentas las decisiones de arquitectura?"

> "Como decisiones, no como descripciones: qué problema había, qué opciones se consideraron, cuál

> se eligió y por qué, y qué condición haría replanteársela. Ese formato es el que permite que un

> compañero nuevo entienda el porqué en una tarde — y es el que sobrevive a las auditorías."