La arquitectura de inferencia local debe basarse en la premisa de confianza cero en el perímetro. La teoría de la privacidad es inútil si el diseño de la red es una chapuza. El objetivo es simple: una API de IA que corra en hardware propio, con una capa HTTPS cifrada para clients locales, sin depender de Let’s Encrypt ni de la exposición a la nube que ha demostrado ser un coladero. No hay excusas cuando se ven titulares de más de 64 millones de registros expuestos por fallos de configuración, o la brecha en Oracle Cloud que comprometió millones de records.

Requisitos Previos: El Stack Mínimo Viable

Para este setup, asumimos un host Linux (Ubuntu/Debian) con Docker y Docker Compose instalado. Necesitarás una GPU con suficiente VRAM para la inferencia, que es donde Ollama va a trabajar. El reverse proxy será Caddy, un binario robusto que simplifica el SSL autofirmado para redes LAN u offline. El objetivo es que la API de inferencia (Ollama, puerto `11434`) solo sea accesible a través del puerto `443` cifrado de Caddy.

Paso 1: Instalación de Ollama y Caddy en Docker

La forma más limpia y reproducible es mediante `docker-compose.yml`. Primero, instala el runtime si no lo tienes.

sudo apt update && sudo apt install docker.io docker-compose -y sudo systemctl enable docker && sudo systemctl start docker

Ahora, define la estructura del servicio. Ollama se mapea a su puerto estándar (`11434`) y Caddy al `80`/`443`. Crea el directorio de trabajo y el archivo de configuración de Docker.

mkdir -p /opt/ia-local/caddy/data cd /opt/ia-local nano docker-compose.yml

El `docker-compose.yml` para el stack es el siguiente. Nótese la directiva `ollama` para la inferencia y `caddy` como capa de acceso.

version: '3.8' services:   ollama:     image: ollama/ollama     restart: unless-stopped     ports:       - "11434:11434"     volumes:       - ./ollama/data:/root/.ollama     # Descomenta y ajusta para soporte GPU:     # deploy:     #   resources:     #     reservations:     #       devices:     #         - driver: nvidia     #           count: all     #           capabilities: [gpu]    caddy:     image: caddy:latest     restart: unless-stopped     ports:       - "80:80"       - "443:443"     volumes:       - ./caddy/Caddyfile:/etc/caddy/Caddyfile       - ./caddy/data:/data       - ./caddy/config:/config     depends_on:       - ollama

Paso 2: Descarga del Modelo e Inicialización de Ollama

Antes de arrancar Caddy, verifica que Ollama está funcional y descarga un modelo base. Esto asegura que la API de inferencia está listening en `11434`. Usa el flag `-d` para ejecución en background.

docker-compose up -d ollama docker exec -it ia-local-ollama-1 ollama pull llama3:8b

Paso 3: Configuración Caddyfile para SSL Autofirmado

El firewall local protege la red, pero el tráfico entre clients y el proxy debe estar cifrado para evitar sniffing en la LAN. Caddy lo hace trivial con `tls internal`. Esto genera un SSL autofirmado automáticamente, perfecto para offline.

cd /opt/ia-local/caddy nano Caddyfile

Este `Caddyfile` redirige cualquier tráfico al hostname local `ia.local.net` (que se mapea a `127.0.0.1` en el entorno Docker) al contenedor `ollama:11434` bajo HTTPS.

ia.local.net {   # Caddy genera y firma un certificado local con su propia CA.   tls internal    # Reverse Proxy al endpoint de Ollama dentro de la red Docker.   reverse_proxy ollama:11434    # Headers de seguridad recomendados   header {     -Server     Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"     X-Content-Type-Options "nosniff"     X-Frame-Options "DENY"     Content-Security-Policy "default-src 'self' https: http: ws: wss: data: blob:;"   } }

Paso 4: Despliegue y Test Funcional

Arranca Caddy y el stack completo. El runtime de Caddy se encargará de levantar el proxy, generar el certificado internal y esperar por la inferencia.

docker-compose up -d docker ps

Verifica que tanto Ollama como Caddy están en estado `Up`.

docker logs ia-local-caddy-1

Ahora, el test funcional. Para curl, se debe usar la flag `–insecure` o `–cacert` para confiar en el certificado autofirmado que Caddy generó. Dado que es un entorno cerrado, la flag insegura es el camino directo para probar la conexión con HTTPS.

curl -k -X POST https://ia.local.net/api/generate \   -H "Host: ia.local.net" \   -d '{ "model": "llama3:8b", "prompt": "Dime un comando Linux para un SysAdmin" }'

El resultado debe ser la respuesta de Llama 3 a través del proxy cifrado, garantizando que el dato de inferencia (prompt) nunca sale de la máquina. Esto es ingeniería, no filosofía de datos. La infraestructura de SharePoint fue comprometida por zero-days en julio de 2025, y el almacenamiento de la nube sigue sufriendo fugas de datos sensibles. La única forma de mitigar el riesgo de exfiltración es no usar el Cloud en absoluto.

La seguridad real reside en el control físico y lógico del hardware. Un reverse proxy local como Caddy con `tls internal` es la capa de transporte cifrada que cualquier sysadmin debería implementar en sus endpoints privados. Es una solución de ingeniería auditable: tu prompt permanece en tu disco, cifrado de client a proxy, y sin dependencias externas para el SSL. El resto es solo ruido de mercadeo.