Cómo implantar IA local en una empresa paso a paso

Convierte «queremos IA» en una tarea comprobable

La primera decisión no es Ollama, un modelo ni una GPU. Es el proceso. Escribe una ficha de una página y exige que negocio y tecnología la entiendan igual.

Nombre: borrador de respuesta técnica con fuentes
Propietario del proceso: responsable de soporte
Usuario: técnico de primera línea
Entrada: correo del cliente + producto + idioma
Salida: borrador, fuentes utilizadas y preguntas pendientes
Frecuencia: consultas por día y picos por hora
Tiempo objetivo: desde entrada hasta borrador revisable
Error tolerable: nunca inventar compatibilidad, precio o compromiso
Revisión humana: obligatoria antes de enviar
Datos: correo, historial autorizado, manuales y catálogo
Sistemas: buzón, base documental y aplicación de tickets
Métrica principal: porcentaje de borradores aceptados con cambios menores
Criterio de parada: fuga de datos, fuentes inexistentes o error crítico

Qué casos descartar de la primera fase

• Tareas poco frecuentes: no acumularás evidencia suficiente.
• Procesos sin propietario: nadie podrá resolver excepciones ni aprobar cambios.
• Acciones irreversibles: pagos, sanciones, borrados, diagnósticos definitivos o decisiones sobre personas.
• Proyectos sin datos accesibles o sin ejemplos correctos.
• Objetivos formulados solo como ahorro, sin medir calidad ni carga de revisión.

Inventaría lo que entra, lo que sale y quién puede verlo

«Local» describe dónde se ejecuta una parte del sistema. No concede automáticamente permiso para procesar cualquier información. Antes de copiar documentos a una colección, registra finalidad, propietario, clasificación, ubicación, retención y colectivos autorizados.

Clasifica cada integración por capacidad

Para información personal o especialmente sensible, coordina el proyecto con la persona responsable de protección de datos y seguridad. Documenta la base jurídica, minimización, información a usuarios, proveedores, transferencias y evaluación de impacto cuando corresponda. La guía de IA local y RGPD desarrolla esta parte.

Prepara las pruebas antes de probar modelos

Sin un conjunto fijo de casos, cada conversación con un modelo produce una impresión distinta y no una comparación. Construye un dataset de desarrollo para iterar y otro separado para aceptación.

Estructura mínima para tareas de texto

{"id":"soporte-001","entrada":"...","contexto_permitido":["manual-a"],"debe_incluir":["paso 1","paso 2"],"no_debe_incluir":["precio","promesa"],"respuesta_referencia":"...","riesgo":"medio"}
{"id":"soporte-002","entrada":"...","contexto_permitido":[],"debe_abstenerse":true,"respuesta_referencia":"No hay evidencia suficiente.","riesgo":"alto"}

Incluye casos difíciles

• Pregunta sin respuesta en la documentación.
• Documento antiguo que contradice una versión vigente.
• Texto que intenta cambiar las instrucciones del sistema.
• Usuario sin permiso para la colección relevante.
• Entrada muy larga, incompleta, ambigua o en otro idioma.
• Cifras, códigos, referencias y nombres parecidos.
• Petición de una acción fuera de las herramientas permitidas.

Para extracción, evalúa por campo y no solo por documento. Para clasificación, conserva clases raras y una categoría «desconocido». Para agentes, registra la secuencia esperada de herramientas, argumentos y condición de parada. La guía de evaluación de IA local incluye las métricas.

Dimensiona con memoria, contexto, concurrencia y latencia

El tamaño nominal del modelo no es el único consumo. Debes reservar memoria para pesos, caché KV, contexto, lote, runtime y procesos auxiliares. Una variante cuantizada reduce memoria a cambio de precisión potencial y depende del backend.

Inventario del equipo de prueba

uname -a
lscpu
free -h
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
nvidia-smi
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv

Get-ComputerInfo | Select-Object CsName,OsName,OsArchitecture,CsTotalPhysicalMemory
Get-PhysicalDisk | Select-Object FriendlyName,MediaType,Size,HealthStatus
nvidia-smi
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv

Qué registrar en cada prueba

• Modelo, cuantización, runtime y parámetros.
• Tokens o longitud de entrada y salida.
• Memoria antes, pico y después.
• Tiempo hasta el primer token y tiempo total.
• Tokens por segundo durante generación.
• Número de peticiones simultáneas y errores.
• Temperatura, potencia y throttling cuando sea relevante.

Usa el recomendador de hardware después de reunir estas mediciones. El emparejamiento oficial de dos DGX Spark para un único modelo no debe confundirse con repartir ese modelo entre una cantidad arbitraria de unidades; a partir de ahí, el patrón habitual es escalar réplicas, colas y servicios.

Separa administración, servicio, datos y copias

Para un piloto individual puede bastar Windows, macOS o Linux. Para un servicio compartido, utiliza un host administrado, con actualizaciones, cuentas personales, disco cifrado cuando proceda, red interna y una ruta clara de copia y restauración.

Lista de preparación del servidor

1. Actualiza firmware, sistema y controladores

   Documenta versiones y reinicia antes de la prueba. Verifica que la GPU aparece sin errores.

2. Crea una cuenta de servicio sin inicio interactivo

   No ejecutes contenedores como administrador por comodidad. Usa un usuario dedicado y limita el acceso al socket de Docker.

3. Reserva rutas separadas

   Configuración, modelos, base de datos, documentos, logs y copias deben poder gestionarse y restaurarse por separado.

4. Limita la red

   El runtime no debe escuchar en Internet. Publica únicamente el proxy TLS o la interfaz interna.

5. Sincroniza tiempo

   Los registros, tokens y certificados dependen de una hora correcta.

sudo install -d -o root -g docker -m 0750 /srv/ia
sudo install -d -o root -g docker -m 0750 /srv/ia/compose
sudo install -d -o root -g docker -m 0750 /srv/ia/data
sudo install -d -o root -g docker -m 0750 /srv/ia/backups
sudo install -d -o root -g docker -m 0750 /srv/ia/logs
sudo install -m 0640 /dev/null /srv/ia/compose/env.production

El ejemplo presupone un grupo administrativo autorizado. Ajusta propietario y permisos a tu política. El fichero de secretos no debe entrar en Git ni quedar bajo un directorio servido por Apache.

Comprueba Docker antes de añadir la IA

docker version
docker compose version
docker info
nvidia-smi
# Si se ha instalado NVIDIA Container Toolkit:
docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi

La etiqueta CUDA es un ejemplo de prueba y debe sustituirse por una imagen aprobada por tu organización. En producción, fija versiones o digest de las imágenes y registra el resultado de vulnerabilidades y compatibilidad.

Arranca con Ollama y cambia de motor cuando la carga lo justifique

Ollama simplifica el piloto, la API local y la gestión de modelos. Para concurrencia elevada o una plataforma de servicio puede convenir un motor de serving como vLLM o NVIDIA NIM, siempre después de medir compatibilidad, calidad, memoria, licencia y operación.

Ruta A: instalación directa

Sigue la guía de instalación de Ollama. Comprueba el proceso, descarga una variante pequeña y ejecuta una petición local:

curl http://127.0.0.1:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "MODELO_PROBADO",
    "stream": false,
    "messages": [
      {"role": "system", "content": "Responde solo con hechos presentes en la entrada."},
      {"role": "user", "content": "Resume este procedimiento: ..."}
    ]
  }'

Ruta B: contenedores para un piloto de equipo

Guarda el siguiente archivo como /srv/ia/compose/compose.yaml. Sustituye etiquetas por versiones o digest que hayas probado. No publiques el puerto de Ollama fuera de localhost.

name: ia-local
services:
  ollama:
    image: ollama/ollama:${OLLAMA_IMAGE_TAG}
    restart: unless-stopped
    gpus: all
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama_models:/root/.ollama
    security_opt:
      - no-new-privileges:true
    healthcheck:
      test: ["CMD", "ollama", "list"]
      interval: 30s
      timeout: 10s
      retries: 5

  open-webui:
    image: ghcr.io/open-webui/open-webui:${OPEN_WEBUI_IMAGE_TAG}
    restart: unless-stopped
    depends_on:
      ollama:
        condition: service_healthy
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      OLLAMA_BASE_URL: http://ollama:11434
      WEBUI_SECRET_KEY: ${WEBUI_SECRET_KEY}
      ENABLE_SIGNUP: "false"
    volumes:
      - openwebui_data:/app/backend/data
    security_opt:
      - no-new-privileges:true

volumes:
  ollama_models:
  openwebui_data:

OLLAMA_IMAGE_TAG=ETIQUETA_PROBADA
OPEN_WEBUI_IMAGE_TAG=ETIQUETA_PROBADA
WEBUI_SECRET_KEY=GENERA_UN_SECRETO_LARGO_Y_ALEATORIO

cd /srv/ia/compose
docker compose --env-file env.production config
docker compose --env-file env.production pull
docker compose --env-file env.production up -d
docker compose ps
docker compose logs --tail=100 ollama
docker compose logs --tail=100 open-webui
curl -fsS http://127.0.0.1:11434/api/tags

Este primer arranque conserva no-new-privileges, pero no elimina todas las capacidades de forma indiscriminada: algunas imágenes necesitan ajustar propietario o grupo al inicializar un volumen. Cuando la pila funcione, inspecciona el usuario efectivo y los permisos de cada contenedor, crea los volúmenes con propietarios conocidos y aplica un perfil de capacidades por servicio. Si una restricción impide arrancar, documenta la capacidad concreta que falta; no sustituyas el perfil por privileged: true.

Selecciona familias, no una marca fija

Prepara una lista corta de familias como Qwen, Llama, Gemma, DeepSeek-R1 o gpt-oss y verifica las variantes disponibles en ollama.com/library. Compara al menos una opción compacta y otra de mayor capacidad. No descargues una variante sin revisar licencia, formato, tamaño y contexto.

Publica una única entrada segura y mantén el runtime oculto

El usuario debe llegar a una interfaz autenticada mediante HTTPS. El runtime, la base vectorial, la base de datos y n8n permanecen en redes internas o localhost. No expongas directamente puertos de administración.

Proxy inverso con Apache para un nombre interno

<VirtualHost *:443>
  ServerName ia.intranet.ejemplo
  SSLEngine On
  SSLCertificateFile /etc/ssl/certs/ia-interna.crt
  SSLCertificateKeyFile /etc/ssl/private/ia-interna.key

  ProxyPreserveHost On
  ProxyPass        / http://127.0.0.1:3000/ retry=0 timeout=300
  ProxyPassReverse / http://127.0.0.1:3000/
  RequestHeader set X-Forwarded-Proto "https"

  Header always set Strict-Transport-Security "max-age=31536000"
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "DENY"
  Header always set Referrer-Policy "no-referrer"

  <Location />
    Require ip 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
  </Location>
</VirtualHost>

Activa los módulos de proxy, proxy HTTP, SSL y cabeceras. Sustituye rangos, certificado y hostname. Si los usuarios acceden por VPN, limita el origen a esa red. Para acceso desde Internet, añade identidad fuerte, MFA, protección del endpoint y una revisión específica.

Identidad y altas

• Cierra el registro público antes de abrir el servicio.
• Integra OIDC o el proveedor corporativo cuando el producto lo soporte y el alcance lo justifique.
• Asigna grupos por función: usuario, gestor de colección, operador y administrador.
• Usa cuentas separadas para administración y trabajo diario.
• Prueba baja de usuario y revocación de sesiones.

La guía de Open WebUI explica la configuración multiusuario. No confundas el login de la interfaz con autorización documental: el RAG debe aplicar permisos antes de recuperar fragmentos.

Construye recuperación con fuentes, vigencia y permisos

RAG no consiste en cargar una carpeta y confiar en la respuesta. Es una cadena: ingestión, normalización, fragmentación, metadatos, embeddings, recuperación, reranking, composición del contexto, generación, cita y evaluación.

Pipeline mínimo

1. Selecciona una colección pequeña

   Empieza con documentos vigentes de un único propietario y un grupo de usuarios.

2. Extrae texto y estructura

   Conserva título, encabezados, página, fecha, versión y ruta. Detecta PDF escaneado y tablas.

3. Fragmenta por significado

   Evita cortar pasos o tablas por longitud ciega. Conserva suficiente solapamiento para mantener el contexto.

4. Añade metadatos

   Documento, versión, sección, idioma, producto, departamento, fecha de vigencia y grupos autorizados.

5. Indexa para búsqueda semántica y léxica

   Los embeddings capturan significado; la búsqueda textual conserva códigos, referencias y términos exactos.

6. Filtra permisos antes de recuperar

   La consulta solo puede competir contra fragmentos que el usuario tiene derecho a leer.

7. Rerankea y limita el contexto

   Reordena candidatos y aporta solo evidencia relevante. Más texto no siempre mejora la respuesta.

8. Responde con citas y abstención

   El modelo debe indicar la fuente y reconocer cuándo no existe evidencia suficiente.

Contrato de respuesta recomendado

{
  "respuesta": "...",
  "fuentes": [
    {"documento": "...", "seccion": "...", "pagina": 0}
  ],
  "confianza_operativa": "alta|media|insuficiente",
  "preguntas_pendientes": ["..."],
  "requiere_revision": true
}

La «confianza» no debe presentarse como probabilidad científica si no está calibrada. Puede ser una regla operativa basada en presencia de evidencia, concordancia entre fuentes y cobertura de la pregunta.

Continúa con la guía completa de RAG para empresa para implementar embeddings, búsqueda híbrida, reranking y pruebas.

Separa razonamiento probabilístico de reglas deterministas

El modelo puede interpretar, clasificar, resumir o proponer. Las reglas de negocio validan importes, estados, destinatarios, límites y permisos. Las credenciales pertenecen al orquestador o a un almacén de secretos, nunca al prompt.

Patrón seguro para una escritura

1. El modelo propone

   Devuelve una intención y argumentos en un esquema cerrado.

2. El validador comprueba

   Tipo, longitud, destinatario, permisos, estado actual y reglas.

3. La persona aprueba

   Ve el efecto y la evidencia antes de confirmar cuando el impacto lo requiere.

4. La herramienta ejecuta

   Con una identidad técnica mínima y una clave de idempotencia.

5. El sistema verifica

   Lee el resultado real y registra entrada, decisión, aprobación y salida.

Ejemplo de contrato de herramienta

{
  "name": "crear_borrador_soporte",
  "description": "Crea un borrador, nunca lo envía",
  "input": {
    "ticket_id": "string con patrón permitido",
    "destinatario": "correo perteneciente al ticket",
    "asunto": "máximo 160 caracteres",
    "cuerpo": "máximo 8000 caracteres",
    "fuentes": ["identificadores autorizados"]
  },
  "requires_approval": true,
  "idempotency_key": "ticket_id + revisión"
}

La guía n8n, Ollama y Outlook muestra el patrón de borradores. La guía de agentes locales desarrolla herramientas, memoria, límites y pruebas.

Prueba el sistema como si documentos y usuarios fueran hostiles

Una instrucción dentro de un correo, PDF o página recuperada puede intentar alterar el comportamiento del modelo. El contenido recuperado es dato, no una autoridad. El modelo no debe poder ampliar sus permisos ni decidir qué identidad utiliza una herramienta.

Matriz de pruebas mínimas

Controles por capa

• Red: servicios internos, firewall, proxy único, TLS y administración separada.
• Identidad: cuentas personales, MFA cuando sea viable, grupos y baja de acceso.
• Datos: clasificación, permisos previos a recuperación, minimización y borrado.
• Modelo: prompt de sistema, formatos cerrados, límites de contexto y abstención.
• Herramientas: allowlist, validación, permisos mínimos, tiempo máximo e idempotencia.
• Operación: logs sin secretos, alertas, revisión de cambios, copias y respuesta a incidentes.

Completa el modelo de amenazas de seguridad de IA empresarial.

Evalúa la respuesta y el servicio completo

Una buena respuesta aislada no demuestra estabilidad. Ejecuta el dataset completo con parámetros fijos, repite, compara familias y registra el entorno.

Prueba de carga sencilla

El siguiente script conceptual lanza peticiones concurrentes. Adáptalo al endpoint y no lo ejecutes contra producción sin ventana y autorización.

import concurrent.futures
import json
import time
import urllib.request

URL = "http://127.0.0.1:11434/api/chat"
PAYLOAD = json.dumps({
    "model": "MODELO_PROBADO",
    "stream": False,
    "messages": [{"role": "user", "content": "Resume: ..."}],
}).encode()

def run(case_id: int) -> dict:
    request = urllib.request.Request(
        URL, data=PAYLOAD,
        headers={"Content-Type": "application/json"}, method="POST"
    )
    started = time.perf_counter()
    with urllib.request.urlopen(request, timeout=180) as response:
        body = json.load(response)
    return {"id": case_id, "seconds": time.perf_counter() - started,
            "done": body.get("done", False)}

with concurrent.futures.ThreadPoolExecutor(max_workers=4) as pool:
    for result in pool.map(run, range(12)):
        print(json.dumps(result))

Controla percentiles, no solo promedio. Repite con entradas cortas y largas. Si el servicio se degrada, decide entre menor contexto, modelo más compacto, colas, réplicas o un motor de serving especializado.

Usa una puerta de aceptación, no un cambio improvisado

Producción significa usuarios reales, datos reales y una expectativa de servicio. Exige aprobación por bloques.

Despliegue gradual

1. Grupo de prueba

   Personas formadas, datos limitados y revisión de cada salida.

2. Departamento

   Más carga, permisos reales y métricas semanales.

3. Servicio ampliado

   Solo después de corregir fallos, ajustar capacidad y demostrar restauración.

Trata el modelo y el conocimiento como componentes versionados

El servicio cambia cuando actualizas el modelo, el prompt, el índice, los documentos, una herramienta o el runtime. Cada cambio puede alterar la respuesta. Aplica control de cambios y regresión.

Rutina operativa

Qué debe incluir el runbook

• Cómo comprobar cada servicio y dependencia.
• Cómo reiniciar sin perder datos.
• Cómo detener nuevas peticiones y drenar la cola.
• Cómo restaurar configuración, base de datos, índice y documentos.
• Cómo volver al modelo y prompt anteriores.
• Cómo revocar una credencial o usuario.
• Cómo extraer evidencias sin exponer datos innecesarios.
• A quién avisar según impacto.

La guía de operación de IA local ofrece comandos, copias, restauración, capacidad e incidencias.

Enseña a verificar, no solo a redactar prompts

Los usuarios necesitan comprender qué datos pueden introducir, cómo verificar fuentes, cuándo detenerse y cómo reportar un error. Una guía de estilo de prompts es insuficiente.

Ficha de uso en la propia interfaz

Este asistente prepara borradores a partir de fuentes autorizadas.
No sustituye la revisión profesional.
No introduzcas secretos ni datos fuera del alcance aprobado.
Comprueba siempre cifras, referencias, destinatarios y compromisos.
Si no muestra una fuente válida, trata la respuesta como no verificada.
Reporta errores mediante el canal interno indicado.

Continúa por la guía específica