De "Funciona en Mi Máquina" a Servicio AI de Producción

Hay un momento en el ciclo de vida de toda infraestructura de IA local que marca un antes y un después. No es cuando el modelo genera su primera respuesta. Es cuando alguien que no es el administrador del sistema intenta usarlo y algo falla silenciosamente. El modelo responde pero con latencia inaceptable. El servicio se cae durante una demo porque otro proceso consumió toda la memoria. La base de datos vectorial pierde datos porque nadie configuró persistencia. El acceso está abierto a cualquiera en la red local.

Este artículo aborda lo que sucede después de que el LLM funciona: cómo convertir un prototipo de IA local en un servicio de producción interna confiable. No es glamoroso. No involucra modelos nuevos ni benchmarks. Es infraestructura — y es exactamente donde la mayoría de las implementaciones de IA local se estancan o fracasan.

El gap entre prototipo y producción

La adopción de LLMs locales en organizaciones sigue un patrón consistente. La primera fase es exploratoria: alguien instala Ollama o llama.cpp en una máquina con GPU, carga un modelo, y demuestra que funciona. La organización se entusiasma. Se conectan aplicaciones. Más usuarios empiezan a depender del servicio. Y entonces empiezan los problemas que no existían cuando era un experimento de una persona.

Los problemas son predecibles porque son los mismos que cualquier servicio de infraestructura enfrenta al pasar de desarrollo a producción:

Disponibilidad: no hay monitoreo, no hay alertas, no hay procedimiento de recuperación. Cuando el servicio se cae, alguien se da cuenta por los tickets de soporte.
Seguridad: el API del modelo escucha en un puerto abierto sin autenticación. Cualquiera en la red puede enviar prompts — o peor, modificar la configuración.
Persistencia: las bases de datos vectoriales (Milvus, Qdrant, ChromaDB) almacenan embeddings que tomaron horas en generar. Sin backup, una falla de disco o una actualización fallida los destruye.
Aislamiento: el modelo, la base vectorial, el proxy y las aplicaciones corren en la misma máquina sin aislamiento. Un proceso que consume demasiada memoria afecta a todos los demás.
Acceso controlado: no hay registro de quién usa el servicio, cuándo, ni para qué. Esto es problemático tanto desde perspectiva de seguridad como de gobernanza.

Capa 1: Aislamiento con contenedores

El primer paso es sacar los servicios del sistema operativo host y meterlos en contenedores. Docker Compose permite definir una stack completa como código declarativo: cada servicio tiene sus propios recursos, su propia red, y sus propios volúmenes de datos.

Un stack típico de IA local en producción incluye:

Servicio	Función	Ejemplo
Motor de inferencia	Ejecutar el LLM	TensorRT-LLM, vLLM, Ollama
Base vectorial	Almacenar embeddings	Milvus, Qdrant
Proxy reverso	Enrutar tráfico, TLS, auth	Nginx, Caddy
API Gateway	Exponer servicios con autenticación	FastAPI custom, Kong
Monitoreo	Métricas y alertas	Prometheus + Grafana

La ventaja de contenedores no es solo el aislamiento. Es la reproducibilidad. Si la máquina falla, el docker-compose.yml y los volúmenes persistidos permiten reconstruir el servicio completo en horas, no en días. Si la organización adquiere hardware adicional, la misma definición se despliega sin reconfiguración manual.

Volúmenes y persistencia

El error más común al containerizar servicios de IA es no mapear correctamente los volúmenes persistentes. Los datos que deben sobrevivir a un reinicio de contenedor incluyen:

Modelos descargados: un modelo de 14B parámetros ocupa 8-15 GB. Re-descargarlo por cada reinicio es inaceptable.
Índices vectoriales: los embeddings y sus índices representan horas de procesamiento. Deben persistir en volúmenes externos al contenedor.
Configuración de servicios: archivos de configuración versionados, no editados a mano dentro del contenedor.
Logs: historial de consultas y errores para debugging y auditoría.

La regla es simple: si perder un dato implica trabajo para recrearlo, ese dato debe estar en un volumen persistente con backup.

Capa 2: Red y firewall

Una máquina con GPU que corre servicios de IA tiene una superficie de ataque mayor que una estación de trabajo convencional. Expone múltiples puertos (API de inferencia, API de la base vectorial, panel de monitoreo) y procesa datos potencialmente sensibles.

Firewall con UFW

El principio es deny-all por defecto, con reglas explícitas para cada puerto necesario:

SSH (22): acceso de administración, idealmente restringido a IPs específicas o a la red Tailscale.
HTTPS (443): el único puerto expuesto a usuarios finales, detrás del proxy reverso.
Puertos internos: los puertos de servicios individuales (8000 para la API, 19530 para Milvus, 9090 para Prometheus) no deben ser accesibles desde fuera. Solo el proxy reverso se comunica con ellos.

Un detalle que se omite frecuentemente: Docker modifica las reglas de iptables directamente, bypaseando UFW. Esto significa que un contenedor que publica un puerto con -p 8000:8000 es accesible desde la red incluso si UFW tiene una regla que debería bloquearlo. La solución es usar la red interna de Docker para comunicación entre servicios y exponer solo el proxy reverso al host.

Red privada con Tailscale o WireGuard

Para organizaciones que necesitan acceso remoto al servicio de IA sin exponerlo a internet público, una VPN mesh como Tailscale proporciona cifrado punto a punto y autenticación basada en identidad. El servicio de IA solo es accesible desde dispositivos autorizados en la red privada. Esto es particularmente relevante para equipos distribuidos geográficamente que necesitan acceder a un servidor centralizado de inferencia.

Capa 3: Proxy reverso con autenticación

Nginx (o Caddy) como proxy reverso cumple múltiples funciones simultáneas:

Terminación TLS: las comunicaciones entre el usuario y el servidor se cifran con HTTPS. Esto no es opcional — enviar prompts en texto plano sobre la red es un riesgo de seguridad evidente, especialmente si los prompts contienen datos corporativos sensibles.

Autenticación: el proxy puede implementar autenticación básica, tokens API, o integración con el sistema de identidad corporativo (LDAP, OAuth) antes de permitir acceso a los servicios detrás.

Rate limiting: prevenir que un solo usuario o proceso monopolice el servicio de inferencia. Un rate limit de 10 requests por minuto por usuario es razonable para la mayoría de casos de uso corporativos y evita degradación del servicio.

Enrutamiento: un solo punto de entrada con rutas diferentes para cada servicio. /api/v1/chat va al motor de inferencia, /api/v1/search va a la base vectorial, /monitoring va a Grafana. Los usuarios solo necesitan conocer un dominio.

Separación de configuración

Un patrón que reduce errores operativos es separar la configuración del proxy en snippets modulares: un archivo para la configuración de TLS, otro para las reglas de autenticación, otro para las rutas. Esto evita archivos monolíticos de configuración donde un error tipográfico en la sección de autenticación puede dejar todo el proxy fuera de servicio.

Capa 4: Backup y recuperación

La pregunta que revela si una infraestructura está lista para producción es: “si el disco duro falla ahora, ¿en cuánto tiempo reconstruyes el servicio?”. Si la respuesta es “días” o “no sé”, el servicio no está en producción — está en demo permanente.

¿Qué respaldar?

No todo necesita el mismo nivel de protección:

Dato	Criticidad	Estrategia
docker-compose.yml y configs	Alta	Git (versionado)
Índices vectoriales	Alta	Backup incremental diario
Modelos descargados	Media	Registro de fuentes, re-descargable
Logs de consultas	Media	Rotación + backup semanal
Métricas de monitoreo	Baja	Retención 30 días, sin backup

Automatización de backups

Un backup que depende de que alguien se acuerde de ejecutarlo no es un backup — es una esperanza. Los backups automatizados deben:

Ejecutarse en horario de bajo uso (madrugada).
Verificar integridad después de la copia.
Almacenar en un destino separado del disco principal (NAS, disco externo, o almacenamiento en nube cifrado).
Generar una alerta si fallan.
Probarse periódicamente con una restauración real — no solo verificar que el archivo existe.

La regla 3-2-1 aplica: tres copias de datos críticos, en dos medios diferentes, con una copia offsite. Para una infraestructura de IA interna, esto podría ser: disco local + NAS en la misma red + copia cifrada en S3 o equivalente.

Capa 5: Monitoreo y observabilidad

Un servicio sin monitoreo es un servicio que falla en silencio. Las métricas mínimas para un servicio de IA en producción son:

Infraestructura: uso de GPU (utilización, memoria VRAM), uso de CPU, RAM del sistema, espacio en disco, temperatura del hardware. Una GPU que opera consistentemente sobre 85°C indica problemas de refrigeración que degradarán el hardware.

Servicios: latencia de respuesta (p50, p95, p99), tasa de errores, tokens por segundo de inferencia, disponibilidad (uptime). Un aumento gradual en la latencia p95 puede indicar fragmentación de memoria o degradación de la base vectorial.

Aplicación: número de consultas por usuario, tipos de consultas, tasa de consultas que exceden el contexto del modelo, errores de parsing o formato.

Prometheus para recolección de métricas y Grafana para visualización es la combinación estándar, pero lo importante no es la herramienta sino que existan alertas accionables. Una alerta de “disco al 90%” a las 3 AM es útil si alguien la recibe y sabe qué hacer. Una alerta de “CPU al 60%” es ruido que entrena a las personas a ignorar alertas.

La migración como momento de verdad

Un caso que ilustra la importancia del hardening es la migración de backends de inferencia — por ejemplo, de Ollama a TensorRT-LLM. En un entorno sin contenedores, esta migración implica desinstalar software del sistema operativo, instalar dependencias nuevas con posibles conflictos, reconfigurar puertos y rutas, y rezar para que nada se rompa.

En un entorno containerizado con proxy reverso, la migración es: levantar el nuevo servicio en un contenedor paralelo, verificar que funciona, cambiar la ruta en el proxy, apagar el contenedor anterior. Si algo falla, revertir es cambiar una línea en la configuración del proxy. El tiempo de downtime se mide en segundos, no en horas.

Este mismo patrón aplica para actualizar modelos, cambiar bases de datos vectoriales, o agregar servicios nuevos. La infraestructura como código convierte operaciones riesgosas en cambios incrementales y reversibles.

El costo de no hacerlo

Las organizaciones que evitan el hardening no ahorran tiempo — lo posponen y lo pagan con intereses. Los costos se manifiestan como:

Horas de trabajo perdidas cuando el servicio cae y nadie sabe cómo restaurarlo.
Riesgo de seguridad cuando datos sensibles transitan en texto plano por la red interna.
Erosión de confianza cuando los usuarios internos perciben que “la IA no funciona bien” porque el servicio es intermitente.
Dependencia de la persona clave que configuró todo manualmente y es la única que sabe cómo funciona.

Este último punto es especialmente corrosivo. Si la infraestructura de IA vive en la cabeza de una persona en lugar de en código versionado, la organización tiene un riesgo operativo no documentado.

Conclusión

La capacidad de correr LLMs locales es una ventaja estratégica para las organizaciones — soberanía de datos, latencia predecible, costos controlables. Pero esa ventaja solo se materializa si la infraestructura que soporta esos modelos tiene el mismo nivel de rigor que cualquier otro servicio crítico del negocio. Firewalls, proxies, backups, contenedores y monitoreo no son overhead de operaciones. Son la diferencia entre un experimento que impresiona en una demo y un servicio que la organización puede usar con confianza todos los días.

Referencias

Docker, Inc. (2025). Docker Compose documentation. docs.docker.com/compose.
NVIDIA. (2025). TensorRT-LLM: Optimized LLM Inference. github.com/NVIDIA/TensorRT-LLM.
Tailscale, Inc. (2025). How Tailscale Works. tailscale.com/blog/how-tailscale-works.
Nginx, Inc. (2025). Nginx Reverse Proxy. docs.nginx.com.
Milvus Contributors. (2025). Milvus: Vector Database for AI Applications. milvus.io.
Prometheus Authors. (2025). Prometheus Monitoring System. prometheus.io.
Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook. IT Revolution Press.