Arquitectura de IA local para empresa: desde el navegador hasta la GPU

Las nueve capas de una plataforma empresarial

El flujo no siempre es lineal. Una aplicación puede buscar información autorizada, preparar las instrucciones que recibirá el modelo, llamar al programa que lo ejecuta y validar la salida. Un agente puede repetir varias herramientas, pero los permisos y los límites deben permanecer fuera del modelo.

Responsabilidad de cada capa

Elige la menor plataforma que cubra el nivel de servicio

Una entrada pública o interna; todos los demás puertos privados

La topología recomendada separa usuarios, proxy, aplicaciones, datos y administración. En un único servidor puedes representar esas zonas con redes de contenedor y puertos ligados a localhost. En varias máquinas, usa VLAN, firewall y reglas explícitas.

Reglas de firewall conceptuales

USUARIOS       -> PROXY_TLS       : 443/TCP
PROXY_TLS      -> OPEN_WEBUI      : 8080/TCP
PROXY_TLS      -> API_EMPRESA     : puerto interno
OPEN_WEBUI     -> RUNTIME         : 11434/TCP o endpoint compatible
API_EMPRESA    -> RUNTIME         : endpoint compatible
API_EMPRESA    -> POSTGRES        : 5432/TCP
API_EMPRESA    -> VECTORIAL       : puerto interno
N8N            -> APIs_APROBADAS  : solo destinos necesarios
MONITORIZACION -> SERVICIOS       : endpoints de métricas
ADMIN_VPN      -> HOSTS           : SSH y administración
CUALQUIERA     -> RUNTIME/DATOS   : DENEGADO si no está arriba

No confíes únicamente en que una aplicación no muestre un enlace. Aplica el control en red, proxy y servicio. Para salida a Internet, utiliza una allowlist o un proxy de egreso cuando el caso requiera descargar modelos, consultar una API autorizada o enviar correo.

Autenticar no basta: cada recuperación y herramienta necesita autorización

Cadena de identidad

1. El proveedor autentica

   OIDC o el sistema corporativo emite identidad y grupos. La interfaz valida emisor, audiencia, firma, caducidad y nonce.

2. La aplicación crea contexto de autorización

   Transforma grupos corporativos en roles de aplicación sin aceptar roles aportados por el prompt.

3. RAG filtra antes de buscar

   El filtro de colección y fragmentos se aplica en la consulta, no después de generar la respuesta.

4. Las herramientas usan identidad técnica o delegada

   La elección depende de la API. Cada una debe tener alcance mínimo y trazabilidad al usuario.

Ollama, vLLM y NVIDIA NIM ocupan posiciones distintas

El runtime debe ser reemplazable para la aplicación. Define una interfaz compatible y una capa de configuración. No permitas que cada equipo llame a un puerto diferente con credenciales propias.

Contrato de inferencia

• Nombre lógico del modelo separado de la imagen o variante concreta.
• Límite de entrada y salida.
• Timeout y cancelación.
• Streaming opcional.
• Formato de errores estable.
• Identificador de petición.
• Métricas de tokens, tiempo y cola.
• Política de logs y datos sensibles.

Enrutado por tarea

routes:
  chat_general:
    model: instruct_compacto
    max_input_tokens: 12000
    max_output_tokens: 1200
  rag_tecnico:
    model: instruct_mayor
    max_input_tokens: 32000
    max_output_tokens: 1800
  clasificacion:
    model: clasificador_compacto
    response_schema: ticket_category_v2
  codigo:
    model: code_family
    tools: [buscar_repositorio, leer_archivo_autorizado]
  visual:
    worker_pool: comfyui_gpu
    queue: visual_jobs

Separa el original, el texto extraído, el índice y la evidencia

Postgres, vectorial y object storage

Una pequeña prueba puede usar la base incluida en una aplicación. En un servicio compartido, una base administrada facilita copia, integridad y concurrencia. Qdrant o pgvector son opciones habituales para vectores; la elección depende de filtros, escala, operación y experiencia. El original puede vivir en el repositorio corporativo o en almacenamiento de objetos, no necesariamente dentro de la interfaz.

Modelo de metadatos mínimo

{
  "document_id": "proc-calidad-042",
  "title": "Control de recepción",
  "version": "rev-c",
  "status": "vigente",
  "owner": "calidad",
  "language": "es",
  "valid_from": "fecha gestionada por el repositorio",
  "source_uri": "repositorio://calidad/proc-calidad-042",
  "allowed_groups": ["calidad", "recepcion"],
  "classification": "interna",
  "content_hash": "sha256:..."
}

El modelo no debe decidir si un usuario pertenece a allowed_groups. Esa decisión se realiza en la aplicación con la identidad validada.

n8n coordina; el LLM participa en pasos delimitados

Un workflow robusto conserva el evento original, asigna un identificador, valida, llama al modelo, valida la respuesta, solicita aprobación y ejecuta la acción. Cada reintento debe ser idempotente.

Separación de credenciales

• El runtime no necesita la contraseña del ERP.
• n8n o el worker conserva la credencial en su almacén de secretos.
• La herramienta expone una operación concreta, no una API genérica.
• El log registra un identificador, no el secreto.
• La rotación no exige volver a entrenar ni cambiar prompts.

Esqueleto para separar redes y persistencia

Este archivo muestra relaciones, no una receta universal. Fija imágenes, comprueba soporte de cada variable, añade healthchecks reales y adapta permisos. Solo el proxy externo debe publicar el servicio a usuarios.

name: ia-empresa
services:
  runtime:
    image: ollama/ollama:${OLLAMA_TAG}
    restart: unless-stopped
    gpus: all
    networks: [inference]
    volumes: [models:/root/.ollama]
    security_opt: [no-new-privileges:true]

  webui:
    image: ghcr.io/open-webui/open-webui:${WEBUI_TAG}
    restart: unless-stopped
    depends_on: [runtime, postgres]
    networks: [frontend, inference, data]
    ports: ["127.0.0.1:3000:8080"]
    environment:
      OLLAMA_BASE_URL: http://runtime:11434
      DATABASE_URL: ${WEBUI_DATABASE_URL}
      WEBUI_SECRET_KEY: ${WEBUI_SECRET_KEY}
      ENABLE_SIGNUP: "false"
    volumes: [webui_data:/app/backend/data]
    security_opt: [no-new-privileges:true]

  postgres:
    image: postgres:${POSTGRES_TAG}
    restart: unless-stopped
    networks: [data]
    environment:
      POSTGRES_DB: ia
      POSTGRES_USER: ia_service
      POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
    secrets: [postgres_password]
    volumes: [postgres_data:/var/lib/postgresql/data]
    security_opt: [no-new-privileges:true]

  qdrant:
    image: qdrant/qdrant:${QDRANT_TAG}
    restart: unless-stopped
    networks: [data]
    volumes: [qdrant_data:/qdrant/storage]
    security_opt: [no-new-privileges:true]

  n8n:
    image: n8nio/n8n:${N8N_TAG}
    restart: unless-stopped
    networks: [automation, data, inference]
    ports: ["127.0.0.1:5678:5678"]
    environment:
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: ia
      DB_POSTGRESDB_USER: ia_service
      DB_POSTGRESDB_PASSWORD_FILE: /run/secrets/postgres_password
    volumes: [n8n_data:/home/node/.n8n]
    security_opt: [no-new-privileges:true]

networks:
  frontend: {}
  inference:
    internal: true
  data:
    internal: true
  automation: {}

volumes:
  models: {}
  webui_data: {}
  postgres_data: {}
  qdrant_data: {}
  n8n_data: {}

secrets:
  postgres_password:
    file: ./secrets/postgres_password.txt

Mide la plataforma sin convertir los logs en una copia de los datos

Política de logging

Registra identificador, usuario o pseudónimo cuando esté justificado, modelo lógico, versión de prompt, colección, herramientas llamadas, tiempos, código de resultado y aprobación. No guardes por defecto prompt completo, documentos, tokens, cabeceras de autenticación o secretos. Para depuración con contenido, habilita una ventana limitada, acceso restringido y borrado explícito.

Replica servicios cuando el impacto lo exija, no por apariencia

Componentes con estado y sin estado

Escalado de modelos

Para un único modelo, primero optimiza contexto, lote y motor. Después añade réplicas para peticiones independientes. El paralelismo tensorial o de pipeline requiere hardware, interconexión y soporte del motor. El enlace oficial de dos DGX Spark es un caso específico para modelos compatibles; no implica que diez unidades formen automáticamente una memoria única.

Cálculo de capacidad

peticiones_hora_pico = usuarios_concurrentes * peticiones_por_usuario
trabajo_total = sum(tokens_entrada + tokens_salida)
capacidad_efectiva = tokens_por_segundo_medidos * factor_utilizacion_seguro
latencia_objetivo = cola + prefill + generacion + herramientas
margen = crecimiento + fallos + actualizaciones + picos

Utiliza percentiles y el caso largo, no una media con prompts cortos. La guía de operación desarrolla capacidad y continuidad.

Secuencia para un técnico júnior

1. Host y GPU

   Actualiza, verifica nvidia-smi, crea rutas, cuentas y red.

2. Runtime aislado

   Arranca Ollama en localhost, descarga un modelo pequeño y prueba API.

3. Proxy e interfaz

   Publica Open WebUI por HTTPS, cierra registro y crea roles.

4. Dataset y modelo

   Compara familias con parámetros fijos y registra memoria.

5. RAG pequeño

   Indexa una colección vigente, añade metadatos y prueba permisos.

6. Automatización de borrador

   Integra un sistema con lectura o borrador; nunca una escritura crítica inicial.

7. Observabilidad y copias

   Activa métricas, logs mínimos y restauración en otro entorno.

8. Pruebas y aceptación

   Calidad, seguridad, carga, rollback y formación antes de ampliar usuarios.