Un modelo de lenguaje local se prueba rápidamente. Un asistente de IA compartido requiere además acceso regulado, flujos de datos claros y alguien responsable de la operación. Ollama y Open WebUI pueden trabajar juntos: un componente ejecuta los modelos y el otro ofrece la interfaz para el trabajo diario.
En una empresa, la planificación comienza con una tarea concreta: redactar desde notas aprobadas, organizar apuntes internos o ayudar con preguntas técnicas. Antes de elegir hardware hay que definir entradas permitidas, revisión de resultados y tiempos de respuesta adecuados.
Dos componentes con tareas diferentes
Ollama proporciona el entorno de ejecución y una API para modelos de lenguaje. Open WebUI añade una interfaz web administrable. Sin embargo, instalar una interfaz localmente no indica dónde procesa cada modelo conectado. Los modelos cloud, la búsqueda web y las herramientas adicionales pueden usar otros flujos de datos.
En este concepto operativo, el personal llega a la interfaz mediante un acceso autorizado. Open WebUI se conecta internamente con Ollama. La API del modelo queda limitada a los servicios que realmente la necesitan. Las conexiones entre contenedores o servidores separados deben planificarse expresamente: localhost se refiere al entorno de red propio de cada componente.
Del puesto individual al servicio compartido
La diferencia está sobre todo en lo que ocurre después del primer chat satisfactorio. La comparación describe una posible evolución para una pequeña empresa; es una ayuda de planificación, no un proyecto de cliente documentado.
| Área | Prueba individual | Uso compartido |
|---|---|---|
| Acceso | Una persona prueba en su propio ordenador. | Cuentas personales, roles definidos y retirada regulada del acceso. |
| Datos | Datos de ejemplo no sensibles. | Tipos de datos autorizados, retención y permisos demostrables sobre las fuentes. |
| Disponibilidad | El ordenador permanece encendido durante la prueba. | Horarios de uso acordados y recuperación documentada. |
| Capacidad | Una petición proporciona una respuesta útil. | Se miden tareas simultáneas, esperas y entradas más largas. |
| Cambios | Se prueban el modelo y el software. | Versiones probadas, copia antes de los cambios y retorno fiable. |
Proteger por separado acceso y API del modelo
Según el fabricante, la API local de Ollama no exige autenticación propia. Exponerla a la red no sustituye al control de acceso. Para un servicio empresarial, la API del modelo debería ser accesible solo por las conexiones internas necesarias. Un puerto abierto a todos los puestos o a Internet no es un punto de partida adecuado. Ollama: autenticación (enlace externo).
La autenticación, aprobación de usuarios y los permisos administrativos de la interfaz deben configurarse deliberadamente. Un servicio de identidad existente puede ser una integración útil; la opción adecuada depende del entorno. Un proxy solo debe transmitir una identidad autenticada mediante información fiable que él mismo establezca. Open WebUI: acceso y permisos (enlace externo).
HTTPS protege la conexión del navegador al punto de acceso. Si intervienen varios sistemas, el trayecto posterior al backend también se cifra y limita según las necesidades de protección. Certificados, redirecciones y conexiones necesarias para la interfaz se prueban conjuntamente. Open WebUI: HTTPS y proxy inverso (enlace externo).
Comprobar lo «local» mediante el flujo real de datos
Para llamadas exclusivamente locales, Ollama ofrece un modo sin sus funciones cloud. Esto no sustituye la revisión de otras conexiones en Open WebUI o herramientas añadidas. Las descargas de modelos y actualizaciones también requieren una vía de obtención planificada. Ollama: uso local y funciones cloud (enlace externo).
- Modelo: ¿Qué versión exacta procesa la petición y dónde se ejecuta?
- Documentos: ¿Dónde se almacenan archivos subidos, textos extraídos, índices y copias de seguridad?
- Servicios adicionales: ¿Se contacta con otros proveedores para búsqueda, reconocimiento de texto, voz o embeddings?
- Herramientas: ¿Qué conexión puede leer datos o activar acciones, y con los permisos de quién?
Cloud y soluciones híbridas pueden ser complementos adecuados. En ese caso se definen expresamente proveedores, tipos de datos y autorizaciones. El cambio a un servicio externo no debería ocurrir inadvertidamente solo porque el modelo local esté ocupado.
El conocimiento empresarial necesita permisos específicos
La autenticación determina inicialmente quién utiliza la interfaz. No concede automáticamente el derecho a ver todos los documentos subidos. En el ejemplo, una guía aprobada podría estar disponible para todos los usuarios piloto mientras los expedientes de personal quedan totalmente fuera.
Al conectar más fuentes después, deben revisarse permisos por colección, documento y usuario. También resultados de búsqueda, citas, chats compartidos y respuestas guardadas pueden revelar información. Los cambios en grupos o permisos de las fuentes deben hacerse efectivos en la solución de conocimiento. Más información en Conocimiento empresarial y RAG y Seguridad de IA y permisos.
Copias y actualizaciones forman parte del concepto
Se guardan los datos realmente utilizados: base de datos, archivos y configuración, además de las claves necesarias para restaurar. Se documentan nombre y versión exacta del modelo, también modelos adaptados y extensiones propias. La copia se conserva separada del sistema activo y con acceso protegido.
Antes de actualizar hacen falta una copia restaurable, revisar las notas de versión y probar fuera del servicio productivo. Tras migrar la base de datos, una imagen antigua del contenedor no restablece necesariamente por sí sola el estado anterior. Open WebUI: actualizaciones, copias y retorno (enlace externo).
Una prueba útil de restauración comienza en un entorno separado. Allí se comprueban autenticación, conexión al modelo, una tarea no sensible y permisos previstos. Solo entonces puede estimarse cuánto duraría realmente una interrupción. Una VM activa o un directorio de copias existente no bastan para demostrarlo.
Una interfaz activa no implica un modelo funcional
La supervisión debe distinguir interfaz accesible, modelo seleccionado disponible y petición completa funcional. La documentación Open WebUI también separa estos niveles. Open WebUI: supervisión funcional (enlace externo).
Para la operación acordada se observan además ocupación de almacenamiento, capacidad disponible, errores y esperas. Las peticiones de prueba no contienen información confidencial. Los registros deben servir para diagnosticar sin duplicar sistemáticamente todas las conversaciones. Antes de ampliar el uso se define quién atiende incidentes y quién aprueba actualizaciones.
Una aceptación manejable antes del inicio
- Comprobar acceso: Un usuario autorizado entra; un usuario no autorizado y una zona de red no permitida quedan excluidos.
- Comprobar flujos de datos: Modelo, interfaz y todos los servicios adicionales usan únicamente las conexiones acordadas.
- Comprobar permisos: Dos roles de prueba reciben solo su contenido autorizado. La revocación también actúa tras una búsqueda que anteriormente tuvo éxito.
- Comprobar carga: Las tareas típicas se ejecutan individualmente y a la vez; se registran esperas aceptables y límites.
- Comprobar recuperación: Una copia puede restaurarse aparte; responsabilidades y retorno están documentados.
El hardware necesario depende del modelo, longitud de contexto, uso simultáneo y objetivo de calidad. La arquitectura no permite deducir un número universal de personas atendidas a la vez. El artículo existente Probar IA local: un piloto con carga representativa profundiza en esta evaluación de capacidad.
Empezar con una tarea delimitada
DAXS puede evaluar la infraestructura existente, planificar flujos y accesos e integrar la solución en la operación acordada. Un caso de uso delimitado con utilidad comprobable es un buen primer paso. Permite determinar si conviene económica y organizativamente un servicio local, una conexión cloud o una combinación.
LLM locales e infraestructura · MCP e interfaces · Solicitar consultoría de IA y automatización
Fuentes: el ejemplo describe una arquitectura y un proceso de comprobación posibles, no instrucciones universales de instalación. Funciones, licencias de modelos y compatibilidad concreta se revisan para las versiones utilizadas.
