¿Tu empresa está pensando en mover parte de su trabajo con IA desde servicios en la nube como ChatGPT a Ollama desplegado dentro de la red corporativa? Si es así, seguro que tienes más de una duda. No es solo instalar un binario: hablamos de proteger datos sensibles, evitar filtraciones hacia Internet y asegurarse de que ningún atacante pueda jugar con tus modelos o tus logs.
En los últimos meses se han descubierto más de 175.000 instancias de Ollama expuestas públicamente en Internet sin la protección adecuada. Muchas pertenecen a startups o equipos técnicos que querían probar rápido… y se dejaron la puerta abierta de par en par. Para que no te pase lo mismo, aquí tienes una checklist completa y aterrizada para desplegar Ollama de forma segura en entornos corporativos.
Entender qué es Ollama y qué implica usarlo en empresa
Antes de tocar nada en producción conviene tener claro que Ollama es una plataforma para ejecutar LLMs en local, sobre tu propio hardware (PC, servidor, VPS, estación con GPU, etc.) sin depender de APIs externas de OpenAI, Anthropic y compañía. Se apoya en la librería llama.cpp, sobre la que añade una capa de gestión de modelos, servidor HTTP y CLI muy sencilla.
Esta aproximación tiene ventajas obvias para una red corporativa: los modelos y los datos no salen de tu infraestructura, no pagas por token y no dependes de las decisiones de precio, privacidad o disponibilidad de un tercero. A cambio, tú te conviertes en responsable de todo: de la seguridad, del rendimiento, de las actualizaciones y de que nada se quede expuesto por error.
Ollama permite usar modelos de lenguaje de gran tamaño (LLM) como Llama 3, Mistral, Gemma, Qwen o DeepSeek, así como sus variantes de código, visión o análisis avanzado. Muchos de ellos están cuantizados (q4_K, q8_0, etc.) para reducir peso y consumo de memoria, a costa de una ligera pérdida de precisión, lo que facilita ejecutarlos en máquinas “normales” sin necesidad de granjas de GPU.
Desde el punto de vista de seguridad, lo más importante es entender que Ollama expone un servidor API por defecto en 127.0.0.1:11434. Si cambias ese comportamiento para ofrecer el servicio a otros equipos dentro de la red (o peor, desde fuera) sin tomar medidas, corres el riesgo de caer en el mismo error que miles de instancias expuestas detectadas en Internet.
Riesgos reales: exposición pública de instancias de Ollama
Los estudios recientes que han identificado más de 175.000 instancias de Ollama accesibles públicamente muestran un patrón claro: despliegues rápidos sin ninguna capa de autenticación ni segmentación de red. Muchos equipos montaron un servidor en un VPS o en un puerto accesible directamente desde Internet y lo dejaron “tal cual”.
El principal problema de esta situación es que cualquiera puede conectarse a la API de Ollama y lanzar prompts, cargar modelos, consumir recursos o incluso intentar exfiltrar información si el servicio está conectado a sistemas internos. Recordemos que Ollama suele usarse para procesar documentos internos, logs, código fuente o información sensible; que eso quede al alcance de un scan global de puertos es un desastre anunciado.
Además, si un atacante puede interactuar libremente con la instancia, tiene margen para descubrir cómo está integrada en tus flujos de trabajo, qué automatizaciones hay con n8n u otras herramientas, y buscar puntos débiles: scripts de respuesta a incidentes, integraciones con bases de datos, conexiones con sistemas críticos, etc.
En entornos corporativos también preocupa la integridad de los modelos. Un Ollama mal protegido podría convertirse en vector para introducir modelos manipulados, reemplazar variantes por otras maliciosas o cambiar configuraciones (por ejemplo, plantillas de prompt) que afecten al comportamiento del asistente interno de la empresa sin que nadie lo note a corto plazo.
Todo esto se agrava cuando Ollama está integrado con automatizadores como n8n o con otros sistemas autoalojados (Nextcloud, aplicaciones internas, pipelines CI/CD). En esos escenarios, un acceso no autorizado a la API de modelos se traduce en movimientos laterales y escalada de privilegios a través de los propios flujos de trabajo automatizados.
Checklist de seguridad previa al despliegue
Antes de poner Ollama a disposición del resto de la organización en una red corporativa conviene seguir un checklist básico que reduzca al mínimo los fallos de configuración típicos. La idea es que, aunque quieras moverte rápido, no sacrifiques controles esenciales de seguridad.
Lo primero es decidir dónde va a vivir la instancia: servidor físico, máquina virtual, contenedor o VPS interno. Sea cual sea la opción, el servidor debe formar parte de un segmento de red controlado (por ejemplo, una VLAN de servicios internos) y no debe exponerse directamente a Internet mediante NAT o redirección de puertos sin un proxy inverso y reglas muy estrictas.
En cuanto a requisitos técnicos, Ollama como binario es ligero, pero los modelos no lo son. Debes contar con memoria RAM suficiente para los tamaños de modelo que quieras cargar (7B normalmente pide al menos 8-16 GB para ir cómodo, 13B apunta a 16-32 GB, y modelos aún mayores disparan la necesidad de memoria). La CPU no suele ser el cuello de botella salvo que tengas máquinas muy antiguas; con 4-8 cores modernos la experiencia mejora bastante.
La GPU es opcional pero en redes corporativas con un SOC o un equipo de desarrollo intenso merece la pena: la inferencia con GPU reduce drásticamente los tiempos de respuesta, lo que hace viable usar modelos más grandes para tareas de análisis, generación de código o automatización sin que se eternicen.
Por último, revisa el espacio en disco. Cada modelo puede ocupar desde ~2-5 GB en versiones pequeñas cuantizadas hasta 40-50 GB o más en modelos grandes, y algunos monstruos superan los 200 GB. Si el servidor va a alojar varios modelos (chat general, uno específico de código, otro de visión, etc.), no es raro necesitar más de 200 GB dedicados solo a ficheros de pesos.
Configuración segura del servicio Ollama
Una vez decidido el entorno, toca configurar el servicio Ollama con cabeza. En Linux, la instalación estándar mediante curl -fsSL https://ollama.com/install.sh | sh arranca un servicio systemd que escucha en 127.0.0.1:11434. Ese comportamiento inicial es razonablemente seguro, porque la API solo es accesible desde el propio host.
El primer punto de la checklist consiste en verificar la configuración efectiva del servicio. En sistemas con systemd puedes usar sudo systemctl status ollama y sudo journalctl -u ollama para revisar logs de arranque y confirmar que el host de escucha es local. Cualquier cambio posterior para exponerlo a otras máquinas ha de hacerse de forma deliberada y documentada.
Para ajustar parámetros, including dónde se guardan los modelos o en qué interfaz escucha el servidor, puedes crear o modificar un override del servicio con sudo systemctl edit ollama.service. Ahí se definen variables de entorno como OLLAMA_HOST, OLLAMA_MODELS, OLLAMA_KEEP_ALIVE o OLLAMA_DEBUG que controlan el comportamiento del daemon.
Un error habitual es cambiar OLLAMA_HOST a 0.0.0.0:11434 para dar servicio a la red y no complementar ese cambio con reglas de firewall o un proxy con autenticación. Esa combinación es la que acaba apareciendo en los informes de “instancias de Ollama expuestas públicamente”. Si necesitas abrir el servicio, hazlo siempre detrás de un reverse proxy con TLS y autenticación fuerte, y limita el acceso mediante listas de control y VPN.
Conviene también decidir qué hacer con OLLAMA_KEEP_ALIVE: mantener modelos cargados en memoria mejora el rendimiento, pero si la máquina es compartida o hay más servicios, quizá te interese soltar memoria agresivamente. Además, desde seguridad, mantener menos cosas residentes puede reducir superficie de ataque en ciertas situaciones muy específicas.
Segmentación de red, VPN y control de acceso
En una red corporativa el objetivo no es solo que Ollama no se vea desde fuera, sino que incluso dentro esté bien acotado. La checklist de red debería empezar por colocar el servidor en una subred interna específica para servicios de IA o similar, aislada del resto de segmentos mediante firewall y sin rutas directas desde redes de invitados o de usuarios sin privilegios.
El acceso a la API de Ollama debe pasar, idealmente, a través de una VPN corporativa o de un túnel seguro, de modo que solo equipos y usuarios autenticados puedan llegar hasta el servicio. Esto es especialmente importante si vas a integrarlo con herramientas que se usan desde portátiles o dispositivos remotos, como n8n, paneles de soporte o aplicaciones internas de los equipos de desarrollo.
Para controlar qué orígenes web pueden llamar al servicio desde el navegador, Ollama dispone de la variable OLLAMA_ORIGINS, que maneja CORS y evita que cualquier dominio pueda lanzar peticiones a la API. En redes corporativas tiene sentido restringirlo a dominios internos concretos o a localhost si solo lo van a usar aplicaciones de backend.
En el plano del sistema operativo, el firewall del servidor (iptables, nftables, ufw o equivalente) debe reflejar exactamente tu modelo de amenazas: puerto 11434 accesible solo desde IPs concretas, sin NAT hacia Internet, sin puertos innecesarios abiertos, y con registros (logging) de conexiones para poder detectar accesos inusuales.
Si finalmente decides ofrecer la API fuera del servidor mediante un proxy tipo Nginx, Caddy o Traefik, asegúrate de configurar TLS fuerte, cabeceras de seguridad y autenticación robusta (por ejemplo, OAuth corporativo, certificados de cliente, etc.). La idea es que nadie deba hablar directamente con Ollama salvo el proxy, y que sea este quien aplique autenticación, autorización y controles de tasa si hace falta.
Gestión de modelos, almacenamiento y logs
En un despliegue corporativo, la parte de gestión de modelos también forma parte crítica de la seguridad. Los modelos descargados por Ollama se almacenan, según la instalación estándar en Linux, en /usr/share/ollama/.ollama/models (o en la ruta que definas en OLLAMA_MODELS). Ese directorio debería tener permisos restrictivos y formar parte de tus estrategias de backup y de control de cambios.
La checklist debe incluir la revisión periódica de los modelos instalados, usando comandos como ollama list para ver qué hay cargado, y ollama show <modelo> para inspeccionar metadatos, configuración y plantillas. Cualquier modelo que no esté autorizado o documentado debe eliminarse con ollama rm y, si hace falta, investigar de dónde ha salido.
Para personalizaciones internas (por ejemplo, modelos adaptados a tu dominio de conocimiento), es habitual usar ollama cp para crear variantes personalizadas referenciando modelos base. Aquí es donde entra en juego el registry de Ollama: puedes subir tus modelos internos con ollama push a un repositorio controlado para asegurarte de que las versiones desplegadas en distintos entornos (desarrollo, preproducción, producción) son coherentes y trazables.
En cuanto a logs, la instancia de Ollama genera información útil mediante journalctl -u ollama. Desde el punto de vista de seguridad y cumplimiento, interesa centralizar esos logs en tu sistema de SIEM o equivalente para poder detectar patrones anómalos de uso, errores recurrentes o intentos de acceso desde orígenes no autorizados.
Finalmente, es recomendable definir una política clara sobre el histórico de conversaciones que Ollama guarda (por ejemplo, en ~/.ollama/history para ciertos usos interactivos). En entornos corporativos, quizá no convenga mantener conversaciones indefinidamente, o puede que deba hacerse cumpliendo políticas de retención específicas, con controles de quién puede acceder a esos historiales.
Integración segura con n8n y otros flujos de trabajo
Uno de los grandes atractivos de Ollama en empresas es engancharlo a herramientas de automatización como n8n para construir flujos de trabajo impulsados por IA: análisis de emails de soporte, generación de respuestas, clasificación de incidencias, revisión de código, moderación de contenido, etc.
La forma más limpia de hacerlo en una red corporativa es desplegar n8n y Ollama en el mismo servidor o en la misma red interna, conectando n8n a la API local de Ollama (por defecto, http://localhost:11434) a través de su nodo dedicado o de un nodo HTTP configurado para enviar prompts y leer respuestas en JSON.
Con este diseño, los datos sensibles (correos de clientes, documentos internos, logs de sistemas, código fuente) se procesan íntegramente dentro de tu infraestructura, y no salen a Internet salvo que tú lo decidas. Para muchos sectores regulados, esto simplifica cumplimiento de RGPD, HIPAA u otras normativas porque puedes demostrar dónde se procesan los datos y bajo qué controles.
En la checklist de integración con n8n deberías incluir: verificación de que la URL configurada apunta a localhost o a una IP interna, pruebas con un flujo simple (trigger manual + nodo HTTP + respuesta) para descartar problemas de red, y validación de que n8n también está protegido con autenticación y no expuesto sin control a Internet.
Un caso de uso típico en empresas es el análisis automatizado de correos de soporte: un nodo de email en n8n detecta mensajes nuevos, envía el cuerpo del correo a Ollama pidiéndole que clasifique el problema y prepare una respuesta, y otro nodo decide si envía la respuesta automáticamente o la pasa a un agente humano. Todo esto se ejecuta sin que los correos salgan de tu VPS o servidor interno, y sin costes variables por token.
Usos de Ollama en ciberseguridad y operaciones
Más allá de los casos de uso generales (asistentes internos, generación de documentación, soporte al desarrollo), Ollama tiene un encaje muy interesante en equipos de ciberseguridad, especialmente si se combina con modelos orientados a análisis técnico como Qwen o DeepSeek.
Un modelo bien escogido puede ayudarte a analizar logs, detectar patrones sospechosos, generar PoCs de vulnerabilidades, explicar exploits, mapear técnicas a frameworks como MITRE ATT&CK o NIST, y proponer medidas de mitigación contextualizadas a tu entorno. La clave es que todo esto se hace sobre datos internos, dentro de la red corporativa, sin que nada viaje a servicios externos.
En entornos de SOC o de respuesta a incidentes, puedes usar Ollama para generar informes post-incidente a partir de volcados de logs, resúmenes de eventos, capturas de tráfico y anotaciones de los analistas. También sirve como asistente para crear scripts y playbooks de respuesta, automatizando parte del trabajo repetitivo y dejando más tiempo libre para las decisiones tácticas.
En DevSecOps, los modelos orientados a código pueden revisar repositorios en busca de patrones inseguros, explicar riesgos asociados a vulnerabilidades (CVE, CWE) y sugerir correcciones. Integrarlos en pipelines CI/CD mediante la API de Ollama permite que ese análisis ocurra antes del despliegue, y siempre de forma local.
Eso sí, en la checklist de seguridad es importante recordar que, aunque el modelo sea muy bueno, no puede sustituir el criterio humano. Las salidas de la IA deben verse como recomendaciones, nunca como oráculos infalibles. Conviene definir explícitamente qué decisiones puede automatizar Ollama y cuáles requieren siempre validación de un profesional de seguridad.
Selección de modelos y gestión de recursos
Para un despliegue seguro y eficiente en una red corporativa, elegir bien los modelos es tan importante como blindar la red. No se trata solo de qué modelo “rinde mejor”, sino de qué modelo puedes permitirte ejecutar con los recursos disponibles y qué tamaño tiene sentido para cada caso de uso.
Para chat general, documentación interna o preguntas frecuentes, suelen funcionar muy bien modelos como Llama 3, Mistral, Gemma o Qwen en tamaños 7B o 13B cuantizados. Ofrecen un equilibrio razonable entre calidad y consumo de RAM/CPU/GPU. Para tareas de programación y análisis de código conviene optar por variantes específicas (DeepSeek-coder, CodeLlama, etc.).
Si necesitas multimodalidad (por ejemplo, que el modelo entienda imágenes, diagramas o capturas de pantalla), toca mirar modelos con capacidad de “vision” como LLaVA, Moondream o Bakllava, que pueden procesar imágenes junto con texto. Eso sí, estos modelos suelen ser más pesados, por lo que el dimensionamiento de hardware debe tenerlo en cuenta.
Una buena práctica de checklist consiste en mantener un catálogo interno de modelos autorizados, con sus versiones, tamaños, cuantización y casos de uso oficiales. Ese catálogo debe actualizarse cuando cambias de modelo, incorporas variantes nuevas o retiras modelos antiguos, y conviene que esté alineado con los requisitos de seguridad y cumplimiento de la organización.
Finalmente, no olvides que la cuantización (q2, q4, q8, fp16, etc.) no es solo una cuestión técnica: afecta directamente a la precisión. En algunos contextos (resúmenes, brainstorming) puedes aceptar modelos muy comprimidos; en otros (decisiones legales, diagnósticos, análisis financiero crítico) quizá prefieras modelos menos cuantizados, con mayor calidad de salida a costa de consumir más recursos.