Desplegar un chatbot de IA para tu equipo en intranet

#¿Por qué un chatbot de IA empresarial en una intranet?

Tres razones concretas impulsan a gestionar la IA internamente: la confidencialidad (tus prompts suelen contener fragmentos de código, datos de clientes e información financiera), el coste (una suscripción a ChatGPT Team de 25 €/mes/usuario asciende rápidamente a 5.000 €/año para 20 personas) y el control (eliges los modelos, los prompts de sistema y los registros de conversaciones).

Una stack bien configurada para un chatbot de IA empresarial en la intranet puede funcionar en una sola máquina para equipos de hasta 30-50 personas. Para equipos mayores, se separa el servidor de inferencia del frontend, pero la arquitectura sigue siendo la misma.

#Arquitectura de la pila

Cuatro componentes apilados, cada uno con una función precisa:

Ollama

Daemon de inferencia que aloja los modelos (Qwen 3.5, Granite 4.2, Gemma 4, Mistral Small). Escucha por defecto en http://localhost:11434.

Open WebUI

Frontend multiusuario similar a ChatGPT en Docker. Gestiona cuentas, conversaciones, RAG y roles de administrador y usuario.

Nginx

Proxy inverso como punto de entrada. Termina las conexiones HTTPS, aplica límites de frecuencia a las solicitudes y ofrece el servicio bajo un nombre de dominio interno claro.

Watchtower + cron

Actualización automática de las imágenes Docker y copia de seguridad diaria del volumen de Open WebUI (que contiene cuentas + conversaciones).

#Requisitos de hardware y sistema operativo

El dimensionado depende del modelo objetivo y de la carga concurrente. Referencias prácticas para un equipo:

Equipo pequeño (5-15 usuarios, modelo de 8-9B)

16 GB de RAM, GPU con 8-12 GB de VRAM (RTX 3060 12GB, 4060 Ti 16GB). Qwen 3.5 9B Q4 (6,6 GB, 256k de contexto) o Granite 4.2 8B (5,3 GB, consumo de tokens muy reducido).

Equipo medio (15-30 usuarios, modelo 20-24B)

32 GB RAM, GPU 16 GB VRAM (RTX 4070 Ti Super, 5080). Mistral Small 24B Q4 (14 GB, bueno en francés) o gpt-oss 20B (14 GB, muy rápido en MXFP4).

Equipo grande (30-50 usuarios, modelo 27-30B)

64 GB de RAM, GPU con 24 GB de VRAM (RTX 3090/4090) o Mac Studio M5 Max 64 GB. Qwen 3.8 27B Q4 (18 GB, 262k ctx, visión) o Granite 4.2 30B Q4 (18 GB, orientado a empresas).

Más allá de 50 usuarios simultáneos

Pasa a vLLM o a varias instancias de Ollama detrás de un balanceador de carga. Sal del ámbito de esta guía.

En cuanto al sistema operativo: Ubuntu Server 22.04 o 24.04 LTS sigue siendo la opción más sencilla. Docker Engine y drivers NVIDIA (con nvidia-container-toolkit si se usa GPU) instalados previamente.

#1. Instalar Ollama en el servidor

La instalación en Linux se realiza mediante el script oficial. Detecta la tarjeta gráfica NVIDIA y configura automáticamente el servicio systemd.

curl -fsSL https://ollama.com/install.sh | sh

Por defecto, el demonio solo escucha en localhost. Para que Docker (Open WebUI) pueda llamarlo desde su contenedor, exponlo en todas las interfaces locales del servidor. Edita el archivo de configuración de anulación de systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_NUM_PARALLEL=4"

OLLAMA_HOST=0.0.0.0:11434

Escucha en todas las interfaces. El cortafuegos del sistema operativo mantiene cerrado el puerto 11434 para las conexiones desde el exterior: solo Open WebUI en la misma máquina podrá acceder a él.

OLLAMA_KEEP_ALIVE=30m

Mantiene el modelo cargado en VRAM durante 30 minutos después del último prompt. Evita las costosas recargas del modelo entre dos solicitudes de usuarios.

OLLAMA_NUM_PARALLEL=4

Número de solicitudes paralelas. 4 es un buen punto de partida para un modelo de 8-9B (tipo Qwen 3.5 9B) en 12 GB de VRAM; reduce a 2 en GPUs más pequeños.

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama pull qwen3.5:9b

#2. Open WebUI en modo multiusuario con Docker

Open WebUI se despliega con un solo comando Docker. El volumen open-webui:/app/backend/data contiene toda la base de datos: cuentas, conversaciones, prompts. Es de ese volumen del que tendrás que hacer una copia de seguridad.

docker run -d \
  --name open-webui \
  --restart always \
  -p 127.0.0.1:3000:8080 \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -e WEBUI_AUTH=true \
  -e ENABLE_SIGNUP=false \
  -e DEFAULT_USER_ROLE=pending \
  --add-host=host.docker.internal:host-gateway \
  ghcr.io/open-webui/open-webui:main

-p 127.0.0.1:3000:8080

Open WebUI solo es accesible desde el propio servidor. Nginx hará de puente hacia la red interna. Crucial para la seguridad.

ENABLE_SIGNUP=false

Nadie puede crear una cuenta desde la página de inicio de sesión. Tú creas los usuarios desde el panel de administración.

DEFAULT_USER_ROLE=pending

Toda cuenta nueva queda pendiente de aprobación por parte del administrador. Evita que un empleado invite por accidente a una persona externa.

OLLAMA_BASE_URL

Apunta a Ollama, que se ejecuta en el host. host.docker.internal se resuelve a la puerta de enlace de Docker gracias a --add-host.

La primera cuenta creada a través de la interfaz http://serveur:3000 (mediante reenvío de puertos SSH o directamente) se convierte automáticamente en administradora. Créala inmediatamente después de iniciar el contenedor, antes de exponer el servicio.

#3. Proxy inverso Nginx con SSL interno

Para exponer chat.entreprise.local correctamente, Nginx actúa como punto de terminación HTTPS y reenvía las solicitudes a Open WebUI en 127.0.0.1:3000. En una intranet, puedes usar un certificado emitido por tu PKI interna o un certificado autofirmado desplegado en los equipos mediante GPO.

sudo apt install nginx

server {
    listen 80;
    server_name chat.entreprise.local;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name chat.entreprise.local;

    ssl_certificate     /etc/ssl/certs/chat-intranet.crt;
    ssl_certificate_key /etc/ssl/private/chat-intranet.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    client_max_body_size 100M;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_read_timeout 600s;
        proxy_send_timeout 600s;
    }
}

client_max_body_size 100M

Indispensable para el RAG: permite a tus usuarios subir PDF o documentos de hasta 100 MB.

Upgrade / Connection

Activa el WebSocket. Sin estas dos líneas, el streaming token por token deja de funcionar y la interfaz parece bloqueada.

proxy_read_timeout 600s

Una consulta de generación larga (resumen de un gran documento) puede durar varios minutos. El tiempo de espera predeterminado de Nginx (60s) interrumpe la respuesta en medio.

sudo ln -s /etc/nginx/sites-available/chat-intranet /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

#4. Autenticación, roles y onboarding

Open WebUI gestiona de forma nativa tres roles: admin (configura todo), user (usa el chat), pending (cuenta creada pero no activada). Para una pyme, la autenticación local basta. Si hay más de 30-40 personas o se exige una alineación estricta con los requisitos de TI, conecta OIDC a tu IdP (Keycloak, Authentik, Microsoft Entra).

1. 01
   Crear usuarios

   Panel Admin → Users → Add User. Introduce el correo electrónico, el nombre y la contraseña inicial. El usuario la cambiará cuando inicie sesión por primera vez.
2. 02
   Restringir modelos por rol

   En Admin → Models, puedes ocultar ciertos modelos a los usuarios estándar. Por ejemplo: reservar Qwen 3.8 27B (el que más VRAM consume) únicamente para los administradores si lo has cargado.
3. 03
   Imponer un prompt de sistema por defecto

   Admin → Settings → Interface → Default Prompt Suggestions. Ideal para orientar el uso ('Respondes en francés, rechazas los temas sensibles, etc.').
4. 04
   Desactivar funciones externas

   Admin → Settings → desactiva Web Search (de lo contrario, Open WebUI llama a DuckDuckGo) e Image Generation si no quieres ninguna conexión saliente a la red.

#5. Monitoreo y copias de seguridad de las conversaciones

Tres cosas que vigilar: el estado del servidor (CPU/GPU/RAM), el estado de la API de Ollama y la integridad de la base de datos de Open WebUI. Y una cosa de la que hacer una copia de seguridad: el volumen Docker open-webui.

#Monitoreo rápido

curl -s http://localhost:11434/api/tags | jq '.models | length'

Si usas Prometheus + Grafana, nvidia_smi_exporter para la GPU y node_exporter para el sistema bastan en el 95 % de los casos. El propio Open WebUI expone /health mediante GET, que debes incluir en tu comprobación de disponibilidad.

#Copia de seguridad diaria del volumen de Open WebUI

El volumen de Docker open-webui contiene una base de datos SQLite con todas las cuentas, conversaciones, prompts personalizados y documentos indexados para el RAG. Su pérdida = pérdida completa del historial del equipo.

#!/bin/bash
set -e
BACKUP_DIR=/var/backups/open-webui
TIMESTAMP=$(date +%Y%m%d-%H%M)
mkdir -p "$BACKUP_DIR"

docker run --rm \
  -v open-webui:/data \
  -v "$BACKUP_DIR":/backup \
  alpine tar czf "/backup/openwebui-$TIMESTAMP.tar.gz" -C /data .

find "$BACKUP_DIR" -name 'openwebui-*.tar.gz' -mtime +14 -delete

sudo chmod +x /usr/local/bin/backup-openwebui.sh
echo "0 2 * * * root /usr/local/bin/backup-openwebui.sh" | sudo tee /etc/cron.d/openwebui-backup

El script conserva 14 días de historial. Para un plan de recuperación ante desastres digno de ese nombre, replica /var/backups/open-webui en un NAS o un bucket S3 cifrado cada noche mediante rsync o rclone.

#Solución de problemas

Open WebUI no ve ningún modelo

El contenedor no puede conectarse a Ollama. Comprueba con docker exec open-webui curl http://host.docker.internal:11434/api/tags. Si se agota el tiempo de espera, tu Ollama escucha en 127.0.0.1: vuelve a establecer OLLAMA_HOST=0.0.0.0:11434.

Streaming entrecortado o bloqueado

Faltan las cabeceras WebSocket en Nginx. Comprueba que proxy_set_header Upgrade y Connection "upgrade" estén presentes en la configuración del vhost.

504 Gateway Timeout en solicitudes largas

proxy_read_timeout demasiado bajo. Súbelo a un mínimo de 600 segundos. Para resúmenes de documentos grandes, súbelo a 1200 segundos.

GPU saturada, latencia que se dispara

Demasiadas solicitudes paralelas. Reduce OLLAMA_NUM_PARALLEL a 2 y aumenta OLLAMA_KEEP_ALIVE para evitar que el modelo tenga que cargarse de nuevo.

Error 'no space left' en /var/lib/docker

Los modelos Ollama no están en Docker: es el volumen open-webui el que crece. Ejecuta docker system prune y monitorea el RAG (los documentos indexados enseguida ocupan varios GB).

#Para ir más allá

Tienes una instancia en funcionamiento para tu equipo. Tres vías naturales para profesionalizarla:

Documentar la conformidad con el RGPD

La guía de LLM local y RGPD cubre la auditoría, el registro de tratamientos y las recomendaciones de la CNIL; es esencial si tu equipo trata datos personales.

Ampliar la herramienta con RAG

La guía de RAG con ChromaDB y Mistral muestra cómo conectar tu base documental interna (wiki, exportación de SharePoint, contratos) a Open WebUI.

Automatizar workflows

La guía para automatizar con n8n y Ollama explica cómo conectar tu chatbot al conjunto de herramientas de tu empresa (correos entrantes, tickets, RSS) sin ninguna fuga de datos a la nube.