Ollama en producción: cómo desplegar IA local en tu pyme

Muchas pymes han probado ya Ollama en un portátil: instalas, descargas un modelo, ejecutas un par de prompts y la IA corre localmente sin enviar nada a la nube. El verdadero reto empieza cuando quieres pasar eso a producción: que responda a todo el equipo, que no se caiga, que sea rápido, seguro e integrado. Ese salto es el que vamos a desgranar.

El objetivo es que una pyme real pueda tener IA local funcionando 24/7 con un coste razonable y sin depender de terceros.

Qué es Ollama y por qué interesa a una pyme

Ollama es una herramienta de código abierto que simplifica ejecutar modelos de lenguaje grandes (LLM) en tu propio hardware. Descargas modelos compatibles —Llama, Mistral, Qwen, Gemma y muchos más— y los sirves a través de una API local. No hace falta saber de PyTorch, ni de CUDA, ni de contenedores complejos. Con un par de comandos ya tienes un modelo corriendo.

Para una pyme, esto cambia las reglas del juego:

• Soberanía de datos. Tus conversaciones, documentos y consultas no salen de tu red.
• Coste predecible. Pagas el hardware una vez; después no pagas por token ni por usuario.
• Sin dependencia de proveedores. No dependes de que OpenAI, Anthropic o Google cambien precios, políticas o disponibilidad.
• Integración sencilla. La API REST de Ollama se conecta fácilmente a n8n, a tus aplicaciones o a agentes internos.

Ollama no es el modelo en sí: es el motor que lo pone a funcionar en tu entorno.

De la prueba al despliegue en producción

La diferencia entre "tengo Ollama en mi portátil" y "Ollama en producción" es la misma que entre un coche de pruebas y un vehículo de flota. En producción necesitas:

• Disponibilidad. El servicio debe arrancar solo, sobrevivir a reinicios y recuperarse de errores.
• Concurrencia. Varios empleados o procesos pueden consultar el modelo a la vez.
• Rendimiento estable. Que el tiempo de respuesta sea predecible, no que a veces tarde 2 segundos y otras 30.
• Monitorización. Saber si el servicio está caído, si la GPU está al 100 % o si hay errores.
• Gestión de modelos. Poder actualizar, cambiar o añadir modelos sin parar todo.
• Seguridad. Que no cualquiera pueda acceder a tu API local desde fuera.

Todo esto se puede montar con hardware modesto y herramientas open source. Lo importante es diseñarlo antes de que los usuarios empiecen a depender de él.

Requisitos hardware realistas

No hace falta un superordenador. Hace falta saber qué modelo vas a correr y cuántos usuarios lo van a usar.

La VRAM es el cuello de botella. Un modelo de 7B a 4 bits suele ocupar unos 4-5 GB de VRAM, pero el contexto largo puede duplicar ese consumo. Si vas a procesar documentos extensos o mantener conversaciones largas, apunta a 12 GB de VRAM como mínimo. Sin GPU, todo funciona en CPU, pero la velocidad baja entre 5 y 20 veces: usable para pruebas, frustrante para producción.

El almacenamiento también importa. Los modelos pesan entre 2 GB y 50 GB. Un disco SSD de 500 GB es suficiente para empezar; 1 TB te da margen para varios modelos, bases vectoriales y logs.

Modelos recomendados según el caso de uso

Ollama permite descargar docenas de modelos, pero no todos sirven para lo mismo. Estos son los que solemos recomendar en Neurosint:

• Llama 3.1 / 3.2 (8B). Equilibrio entre calidad y velocidad. Ideal para chat interno, clasificación de correos y agentes que siguen instrucciones estructuradas.
• Mistral 7B / Mixtral 8x7B. Mistral 7B es rápido y razona bien en español. Mixtral ofrece calidad cercana a modelos mucho más grandes, pero necesita más VRAM.
• Qwen 2.5 (7B-14B). Excelente para tareas multilingües, incluido el español. Útil si tu pyme opera en varios idiomas.
• Gemma 2 (9B). Buena opción para resumir textos largos y responder preguntas sobre documentos si dispones de suficiente VRAM.
• Modelos especializados. Para código, Code Llama o DeepSeek Coder; para embeddings, nomic-embed-text o all-minilm; para visión, Llava si necesitas analizar imágenes.

La clave no es usar el modelo más grande, sino el adecuado. Un modelo de 7B bien configurado resuelve la mayoría de necesidades de una pyme. Si necesitas más precisión, sube de tamaño; si necesitas velocidad, baja de cuantización.

Arquitectura de despliegue típica

La forma más sólida de desplegar Ollama en una pyme es con Docker en un servidor dedicado o en una máquina virtual. Una arquitectura básica sería:

1. Servidor físico o virtual con GPU (si es posible) dentro de tu red local o DMZ.
2. Docker y Docker Compose para levantar Ollama de forma reproducible.
3. Volumen persistente para modelos, de modo que no se descarguen cada vez.
4. Reverse proxy (nginx, Traefik o Caddy) que termine HTTPS y route hacia Ollama.
5. Autenticación en el proxy: clave API, OAuth interno o restricción por IP/VPN.
6. Monitorización básica con logs centralizados y alertas de disponibilidad.
7. Copias de seguridad del volumen de modelos y configuración.

No es necesario exponer Ollama a internet. En la mayoría de los casos, basta con que sea accesible desde tu red local o desde tu VPN. Si quieres que empleados en remoto lo usen, conectan primero a la VPN; no abres el puerto al mundo.

Para alta disponibilidad modesta, puedes tener un segundo servidor con un modelo más pequeño como respaldo, o configurar un plan de contingencia que, ante una caída, encamine las peticiones críticas a otro modelo o a una cola diferida.

API REST e integración con n8n y agentes

Ollama expone una API REST que es el puente hacia tus flujos de trabajo. Los endpoints más útiles son:

• /api/generate: para una única respuesta a partir de un prompt.
• /api/chat: para conversaciones con historial.
• /api/embeddings: para convertir textos en vectores y alimentar una base de datos vectorial en un sistema RAG.

Una llamada básica con curl se ve así:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1",
  "prompt": "Resume este texto en tres puntos: ...",
  "stream": false
}'

En n8n, usas el nodo HTTP Request apuntando a tu Ollama interno. Desde ahí puedes construir flujos como:

• Clasificar correos de atención al cliente y responder borradores.
• Resumir documentos adjuntos y guardar el resumen en tu CRM.
• Generar descripciones de productos a partir de fichas técnicas.
• Alimentar un agente que consulta tu base de conocimiento local.

Si usas frameworks de agentes como LangChain, LlamaIndex o CrewAI, la mayoría permiten apuntar al endpoint de Ollama como si fuera OpenAI. Solo cambias la URL base y el nombre del modelo. Así tus agentes corren enteramente en tu infraestructura.

Seguridad: no es solo por ser local

Correr IA local es un gran paso para la privacidad, pero no es suficiente. En producción, aplica estas capas:

• Aísla la red. Ollama no necesita salir a internet para generar texto. Corta su acceso saliente salvo para descargar modelos, y haz esas descargas desde una máquina de gestión.
• Controla el acceso. Nunca expongas el puerto 11434 directamente. Usa un proxy con HTTPS y autenticación. Limita por IP o VPN.
• Principio de mínimo privilegio. Los agentes que solo leen no deben escribir. Los que escriben no deben borrar. Cada integración, su propia clave.
• Sandbox. Si un agente puede ejecutar acciones (enviar correos, modificar bases de datos), ejecuta esas acciones dentro de un entorno controlado con permisos estrictos.
• Logs y auditoría. Registra quién consulta qué, cuándo y con qué resultado. Sirve para detectar problemas y para cumplir con el RGPD.
• Actualizaciones. Tanto Ollama como el sistema operativo y los modelos deben actualizarse. Los modelos también reciben parches de seguridad y mejoras.

Recuerda: un modelo local con acceso descontrolado a tu correo o ERP puede ser tan peligroso como una API externa mal configurada.

Errores comunes que frenan el despliegue

En Neurosint hemos visto los mismos escollos una y otra vez. Evítalos:

• Esperar velocidad de cloud con CPU. Ollama en CPU funciona, pero no para producción con usuarios reales. Si hay presupuesto, invierte en GPU.
• Elegir un modelo demasiado grande. Un 70B en una GPU de 12 GB ralentiza todo o directamente no entra. Mejor un 7B-8B cuantizado que fluya.
• Dejar la API pública. El puerto 11434 sin protección es un riesgo innecesario.
• Ignorar el tamaño del contexto. Prompts enormes ralentizan la generación y consumen VRAM. Recorta o resume el contexto antes de enviarlo.
• No validar salidas. La IA puede inventar datos. Si el resultado va a un ERP, CRM o base de datos, añade una capa de validación.
• Olvidar el backup. Un día falla el disco y te das cuenta de que no tenías copia de los modelos ni de la configuración.
• Prompt injection. Un usuario o un correo malicioso puede redirigir al modelo. Limita lo que puede hacer y valida las instrucciones.

La mayoría de estos errores se resuelven con buenas prácticas, no con más hardware.

Conclusión: la IA local ya está al alcance de tu pyme

Ollama no es solo una herramienta para hacer pruebas. Con el hardware adecuado y una arquitectura segura, puede convertirse en el motor de IA de tu pyme: atención al cliente, automatización de documentos, agentes internos, asistentes de conocimiento.

La ventaja es también estratégica: controlas tus datos, reduces la dependencia del cloud y amortizas una inversión inicial en meses, en lugar de una suscripción que crece con cada usuario.

Empieza pequeño: un caso de uso, un modelo 7B en GPU, n8n, y mide el ahorro. Escalar después es cuestión de repetir la fórmula.

En Neurosint ayudamos a pymes de Bilbao y del entorno a diseñar, desplegar y asegurar infraestructuras de IA local con Ollama, n8n y modelos open source. Si quieres pasar de las pruebas a producción sin depender de la nube, hablemos.