Despliega tu IA privada con Ollama y Open WebUI en WSL2

¿Qué pasaría si el asistente de IA que usa toda tu familia corriera en tu propia computadora, respondiera en segundos y nunca enviara ni una sola palabra de tus conversaciones a la nube?

Puedes construirlo. Con herramientas gratuitas y de código abierto, y una PC con una GPU decente, una IA privada corre completamente en hardware que ya tienes: sin cuota mensual, sin cuenta con ningún proveedor, sin datos saliendo de tu red. Además, este es uno de los proyectos de home lab más gratificantes que puedes hacer. Al terminar habrás trabajado con Linux, Docker, drivers de GPU y networking en red local, y entenderás cómo encajan entre sí esas cuatro capas.

Esta guía te lleva paso a paso por todo el proyecto: un chatbot privado al estilo ChatGPT, impulsado por Ollama y Open WebUI, acelerado por tu GPU NVIDIA y accesible desde cualquier teléfono, laptop o tablet de la casa.

Lo tengo corriendo en mi casa, y lo más difícil nunca fue la IA. Fueron tres detalles pequeños de red que ningún tutorial me advirtió, así que dejé anotado cada uno justo en el punto donde te los vas a encontrar.

Lo que necesitas antes de empezar

#

• Una PC con Windows 11 y una GPU NVIDIA. La GPU es lo que hace que las respuestas se sientan inmediatas y no lentas. La mía es una RTX 3070 Ti de 8 GB de VRAM, la misma tarjeta de mi guía para armar tu propia PC, y servir este asistente terminó siendo justo el uso al que le apunté ese build. Todos los números de esta guía se midieron ahí, así que puedes calibrar tus expectativas contra una tarjeta de gama media y no contra una workstation.
• El driver NVIDIA de Windows en versión 471.11 o posterior. No hay que instalar nada dentro de Linux.
• Espacio libre en disco para los pesos del modelo, que ocupan varios gigabytes cada uno.
• Acceso de administrador en Windows, porque algunos pasos tocan el firewall y la tabla de reenvío de puertos.

El stack

#

En 2024, Ollama todavía no tenía instalador nativo para Windows, así que la única forma de correrlo en una máquina Windows era a través de WSL2 (Windows Subsystem for Linux). Lejos de ser una limitación, WSL2 es genuinamente la mejor forma de hacerlo: obtienes un entorno Linux real con acceso completo a la GPU, corriendo junto a Windows en hardware que ya tienes.

El stack completo:

• WSL2 en Windows 11: un entorno Linux real corriendo junto a Windows, con acceso directo a la GPU NVIDIA.
• Ollama: se encarga de descargar, administrar y servir modelos de lenguaje open-weight de forma local.
• Open WebUI: una interfaz web limpia, al estilo ChatGPT, que se comunica con Ollama por HTTP.
• Docker: corre Open WebUI como un container dentro de WSL, lo que mantiene el setup portátil y ordenado.
• Portainer (opcional): un dashboard visual para administrar containers Docker sin necesidad de la línea de comandos.
• WSL2 con un port proxy automatizado: la configuración que hace que el chatbot sea accesible desde otros dispositivos en la red local, con una pequeña tarea programada que evita que las reglas de reenvío se rompan en cada reinicio.

Puesto todo junto, una pregunta desde tu celular viaja así:

Celular, laptop o tablet en la LAN       los dispositivos que todos ya traen
        │  http://<IP-LAN-DE-LA-PC>:8080
        ▼
Host Windows (netsh portproxy)           reapuntado en cada inicio de sesión
        │  0.0.0.0:8080 -> <IP-DE-WSL>:8080
        ▼
Open WebUI (Docker, --network=host)      la interfaz al estilo ChatGPT
        │  OLLAMA_BASE_URL=http://127.0.0.1:11434
        ▼
Ollama (servicio nativo, GPU NVIDIA)     descarga, administra y sirve el modelo

No te espantes por WSL. Es una herramienta increíblemente poderosa: tienes la línea de comandos de Linux completa (gestores de paquetes, scripts, Docker, todo) sin salir del entorno Windows que ya conoces. Si nunca lo has usado, este proyecto es una excelente primera experiencia.

Paso 1: Activar WSL2 e instalar Ubuntu

#

Abre PowerShell como administrador y ejecuta:

wsl --install

Esto activa WSL2 e instala Ubuntu por defecto. Después de reiniciar, abre Ubuntu desde el menú de inicio y completa la configuración inicial (nombre de usuario y contraseña).

Si ya tienes WSL instalado y quieres confirmar que usas la versión 2:

wsl --list --verbose

Busca VERSION 2 junto al nombre de tu distribución. Si aparece versión 1, actualízala con wsl --set-version Ubuntu 2.

Paso 2: Verificar tu GPU NVIDIA en WSL

#

WSL2 en Windows 11 expone tu GPU automáticamente, así que no necesitas instalar un driver NVIDIA separado dentro de Linux. El driver vive en el host de Windows; WSL lo conecta. El único requisito es tener el driver NVIDIA de Windows en versión 471.11 o posterior (cualquier driver lanzado después de mediados de 2021 debería funcionar).

Dentro de la terminal de WSL, ejecuta:

nvidia-smi

Deberías ver una tabla con el nombre de tu GPU, la versión del driver y la versión de CUDA.

Si el comando no se encuentra o arroja un error, abre GeForce Experience (o descarga el driver más reciente desde nvidia.com) y actualiza tu driver de Windows, luego vuelve a intentarlo.

Este paso importa: Ollama usará la GPU automáticamente si CUDA es visible, lo que hace las respuestas notablemente más rápidas.

Paso 3: Instalar Ollama y descargar tu primer modelo

#

Dentro de tu terminal de WSL, ejecuta el script oficial de instalación:

curl -fsSL https://ollama.com/install.sh | sh

El script detecta CUDA y configura Ollama para usar la GPU. Una vez que termine, descarga y corre un modelo. Yo usé llama3.1, que era el modelo open-weight más capaz disponible en ese momento:

ollama run llama3.1

La primera ejecución descarga los pesos del modelo (varios gigabytes, según el modelo). Después de eso, quedarás en un chat interactivo directo en la terminal. Haz una pregunta para confirmar que todo funciona y sal con /bye.

Ollama también levanta un servidor HTTP en segundo plano en http://127.0.0.1:11434. Esta es la API que usará Open WebUI.

Qué corro hoy (agosto de 2026): llama3.1 era la elección correcta en 2024, pero los modelos abiertos avanzan rapidísimo y hoy ya ni siquiera está instalado en esta máquina. El motor que atiende a la casa ahora es Qwen3.5 4B (qwen3.5:4b, 4.7B de parámetros, cuantización Q4_K_M, 3.4 GB en disco), y se descarga igualito con ollama run qwen3.5:4b. Nada más de esta guía depende del modelo que elijas, así que empieza con el que esté vigente cuando leas esto. Los resultados medidos más abajo explican por qué un 4B terminó ganándole a un modelo mucho más grande en una tarjeta de 8 GB.

Paso 4: Desplegar Open WebUI con Docker

#

Instala Docker Engine dentro de WSL. La forma más rápida es usar el script de conveniencia oficial:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

Cierra y vuelve a abrir tu sesión de WSL para que el cambio de grupo surta efecto, luego inicia el daemon de Docker:

sudo service docker start

Ahora levanta el container de Open WebUI:

sudo docker run -d \
  --network=host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Una nota sobre OLLAMA_BASE_URL: el valor http://127.0.0.1:11434 le indica al container cómo conectarse a Ollama, y es el que te recomiendo escribir. 0.0.0.0 es en realidad una dirección de escucha, que significa “acepta conexiones en todas las interfaces”, más que un destino. Linux sí la acepta como destino y la enruta a localhost, así que OLLAMA_BASE_URL=http://0.0.0.0:11434 también funciona (mi propio compose lleva mucho tiempo corriendo así), pero funciona por un comportamiento específico de la plataforma y no porque la dirección signifique lo que quieres decir. Escribir 127.0.0.1 dice exactamente lo que buscas y se traslada sin cambios a cualquier otra plataforma. Como el container corre con --network=host, comparte el namespace de red de WSL con Ollama, por lo que 127.0.0.1 resuelve correctamente.

Abre un navegador en tu computadora con Windows y ve a http://localhost:8080. Deberías ver la página de login de Open WebUI. Crea una cuenta (es local, no necesitas verificación de correo) y empieza a chatear.

Paso 5: Llegar a tu IA privada desde cualquier dispositivo de la casa

#

En este punto el chatbot solo es accesible desde la PC donde lo instalaste. Para abrirlo al resto de la casa, reenvías los puertos correspondientes desde el host de Windows hacia WSL con netsh portproxy. Este enfoque tiene una pega conocida: WSL2 recibe una IP interna distinta cada vez que reinicias Windows, por lo que una regla de reenvío fija se rompe silenciosamente después de cada reinicio. La solución no es abandonar el port forwarding, sino automatizarlo: un pequeño script vuelve a apuntar el reenvío a la IP actual de WSL, ejecutado automáticamente por una tarea programada en cada inicio de sesión.

¿Por qué no el modo “espejo”? Windows 11 también ofrece networkingMode=mirrored, que le da a WSL la IP del host directamente y elimina la necesidad de cualquier reenvío. Es tentador, pero enruta las conexiones a 127.0.0.1 a través del stack de red de Windows, lo que rompe el descubrimiento de GPU de Ollama (la sonda de loopback se cuelga y Ollama cae silenciosamente a CPU) y, en mi caso, interfirió con una VPN. El modo NAT más un port proxy automatizado mantiene la GPU funcionando y es igual de confiable una vez que el refresco está en un script.

Mantener WSL en modo NAT

#

NAT es el modo por defecto de WSL2, pero conviene dejarlo explícito. Crea o edita el archivo C:\Users\<tu-usuario>\.wslconfig en Windows (vive en tu carpeta de usuario de Windows, no dentro de WSL):

[wsl2]
networkingMode=NAT
localhostForwarding=true

Luego apaga WSL desde PowerShell para que el cambio surta efecto:

wsl --shutdown

Abrir los puertos en el firewall de WSL

#

sudo ufw allow 8080/tcp
sudo ufw allow 11434/tcp

El puerto 8080 es Open WebUI. El 11434 es la API de Ollama; lo necesitarás accesible en la red si más adelante quieres conectar otras herramientas (o un bot de Discord) directamente al servidor de modelos.

Hacer que Ollama escuche en la red

#

Por defecto, Ollama solo escucha en 127.0.0.1. Para que sea accesible desde otros dispositivos, sobreescribe la configuración de su servicio:

sudo systemctl edit ollama

En el editor que se abre, agrega:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Guarda y reinicia:

sudo systemctl restart ollama

El formato importa: El valor debe ser 0.0.0.0:11434 sin el prefijo http://. Agregar el prefijo hace que Ollama lo interprete como una URL y se enlace a IPv6 [::] en lugar de IPv4, que no recibe de forma confiable el tráfico IPv4 de la LAN. Déjalo como un host:puerto simple.

Reenviar los puertos desde Windows hacia WSL

#

La IP interna de WSL cambia en cada arranque, así que escribirla a mano se rompería tras el siguiente reinicio. En su lugar, escribe un pequeño script de PowerShell que consulte la IP actual de WSL y reconstruya las reglas de reenvío. Guárdalo como C:\Users\<tu-usuario>\wsl-portproxy.ps1:

# Vuelve a apuntar el reenvío de Windows a la IP interna actual de WSL para que
# los dispositivos de la LAN alcancen los servicios dentro de WSL en la IP del host.
# Ejecutar como Administrador.

$ports = @(8080, 11434)

# Obtener la IPv4 interna actual de WSL (la primera de `hostname -I`)
$wslIp = (wsl hostname -I).Trim().Split(" ")[0]
if (-not $wslIp) { Write-Error "No se pudo determinar la IP de WSL. ¿Está WSL corriendo?"; exit 1 }
Write-Host "IP de WSL: $wslIp"

foreach ($p in $ports) {
    # Limpiar la regla vieja de este puerto y agregar una nueva
    netsh interface portproxy delete v4tov4 listenport=$p listenaddress=0.0.0.0 2>$null | Out-Null
    netsh interface portproxy add    v4tov4 listenport=$p listenaddress=0.0.0.0 connectport=$p connectaddress=$wslIp | Out-Null
    Write-Host "portproxy: 0.0.0.0:$p -> ${wslIp}:$p"

    # Asegurar que el firewall de Windows permita la entrada en este puerto (se agrega una sola vez)
    $ruleName = "WSL portproxy $p"
    if (-not (Get-NetFirewallRule -DisplayName $ruleName -ErrorAction SilentlyContinue)) {
        New-NetFirewallRule -DisplayName $ruleName -Direction Inbound -Action Allow `
            -Protocol TCP -LocalPort $p | Out-Null
        Write-Host "firewall: entrada TCP $p permitida"
    }
}

Write-Host "`nListo. Tabla portproxy actual:"
netsh interface portproxy show v4tov4

Ejecútalo una vez desde una PowerShell como Administrador para aplicar los reenvíos de inmediato. Las reglas de firewall que crea aceptan tráfico entrante en esos puertos desde cualquier origen; si prefieres restringirlas a tu red de casa, agrega -RemoteAddress 192.168.1.0/24 a la llamada New-NetFirewallRule, sustituyendo tu propio rango de LAN (el subnet que te reporta ipconfig para tu adaptador Wi-Fi o Ethernet, que muchas veces es 192.168.0.0/24 o 10.0.0.0/24).

Refrescar el reenvío automáticamente en cada reinicio

#

Para no tener que correr el script a mano, regístralo como una tarea programada que se dispare al iniciar sesión. Desde una PowerShell como Administrador:

$action  = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-WindowStyle Hidden -ExecutionPolicy Bypass -File C:\Users\<tu-usuario>\wsl-portproxy.ps1"
$trigger = New-ScheduledTaskTrigger -AtLogOn
Register-ScheduledTask -TaskName "WSL portproxy" -Action $action -Trigger $trigger -RunLevel Highest

Ahora obtén la IP local de tu PC (ipconfig en PowerShell, busca la dirección IPv4 de tu adaptador Wi-Fi o Ethernet) y accede a http://<IP-de-la-PC>:8080 desde cualquier otro dispositivo en la misma red. Tras un reinicio, la tarea vuelve a apuntar el reenvío a la nueva IP interna de WSL automáticamente, así que la dirección en la LAN no cambia.

Advertencia headless: la tarea se dispara al iniciar sesión. Si llegas a la máquina sin iniciar sesión (por ejemplo vía \\wsl$ o una herramienta remota), corre wsl-portproxy.ps1 una vez a mano para levantar el reenvío.

Paso 6: Portainer (opcional)

#

Si prefieres una interfaz visual para administrar tus containers Docker en lugar de usar la línea de comandos, Portainer es una opción ligera. Levántalo junto a Open WebUI:

sudo docker run -d \
  --network=host \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  --name portainer \
  --restart always \
  portainer/portainer-ce

La interfaz web de Portainer quedará disponible en http://localhost:9000, que es el puerto HTTP por defecto de Portainer CE (9443 sirve la misma interfaz por HTTPS). Como el container corre con --network=host, no publica ningún puerto propio: simplemente escucha en los puertos de WSL, así que alcanzarlo desde otro dispositivo requeriría el mismo tratamiento de portproxy del Paso 5. Te permite iniciar, detener e inspeccionar containers con unos clics, lo cual es muy útil cuando quieres actualizar Open WebUI sin tener que recordar los flags exactos de docker run.

Lo que de verdad corro, y por qué se salta el Paso 5 por completo. En mi máquina no hay ningún servidor de Portainer dentro de WSL. Lo que corre ahí es un Edge agent de Portainer (portainer/agent:latest con EDGE=1 más el edge ID y la key que emite el servidor), mientras que el servidor de Portainer vive en el NAS de la casa. El agente marca hacia afuera y mantiene el túnel abierto, así que no publica ni un solo puerto y nunca hay que encontrarlo en la dirección de WSL. Es una inversión elegante del problema que tanto trabajo cuesta resolver en el Paso 5: en vez de enseñarle a la red cómo llegar a un blanco móvil, el blanco móvil mantiene una conexión abierta hacia algo que no se mueve, lo que lo vuelve inmune a la IP cambiante de WSL y a los reinicios. Si ya tienes un servidor de Portainer en tu red, esta es la forma más robusta de administrar los containers que viven dentro de WSL.

¿Qué tan rápido va en realidad? Números medidos en una GPU de 8 GB

#

La razón entera de poner una GPU detrás de este stack es la velocidad, así que aquí van cifras reales en lugar de adjetivos. Las medí en agosto de 2026 en la RTX 3070 Ti (8 GB) con Ollama 0.24.0, llamando directo al endpoint /api/generate y leyendo los propios contadores de Ollama (eval_count / eval_duration), con think: false, tres tamaños distintos de prompt y la mediana de tres corridas en cada punto.

Esa última columna es una lectura absoluta de nvidia-smi tomada en una sesión tranquila, así que cuenta todo lo que hay en la tarjeta: el modelo y lo que el escritorio de Windows traía ocupado en ese momento (434 MiB). El dato de memoria del 4B se midió con mi versión tuneada, que carga los mismos pesos que qwen3.5:4b y ocupa lo mismo.

De esa tabla vale la pena leer tres cosas. Primero, unos 100 tokens por segundo en un modelo de 4.7B con 0.2 s al primer token significa que la respuesta empieza a aparecer en cuanto dejas de escribir y luego llega mucho más rápido de lo que cualquiera alcanza a leer, que es la vara práctica para un asistente familiar. Segundo, la tasa se mantiene plana con la longitud: el 4B sostuvo entre 101 y 105 tok/s lo mismo cuando generó 34 tokens que cuando generó 534. Tercero, cargar un modelo desde disco cuesta entre 3.4 y 6.4 segundos, y solo se paga en la primera petición después de que Ollama lo descarga de memoria.

La “versión tuneada” del último renglón es un Modelfile sobre los pesos originales, no un reentrenamiento, y por eso mi 4B tuneado midió 103 tok/s contra los 102 tok/s del 4B de fábrica: a un punto de distancia. El tuneo cambia el comportamiento del asistente, no su velocidad. Esa personalización es justo el tema de la parte 2 de esta serie.

Dimensiona el modelo a la tarjeta, no al disco

#

Este es el hallazgo que no esperaba y el que probablemente te ahorre una tarde entera.

Un modelo de 6.6 GB en una tarjeta de 8 GB se ve como un ajuste cómodo en papel. No lo es, porque el modelo nunca es el único inquilino, y el otro inquilino no se queda quieto: el escritorio de Windows ocupó 434 MiB de VRAM en una sesión tranquila y entre 1,295 y 1,326 MiB mientras la máquina estaba en uso. Carga el modelo de 9.7B con num_ctx 8192 y la tarjeta se llena hasta 7,921 MiB de sus 8,192 MiB en el caso tranquilo, y hasta 7,883 a 7,939 MiB en el ocupado: entre 250 y 270 MiB de margen en ambos casos, cerca del 97 % de ocupación. El total cae en el mismo lugar bajo las dos condiciones porque Ollama dimensiona su reserva según lo que haya libre, en vez de tomar una cantidad fija. Por fuera nada se veía mal, y ollama ps seguía reportando 100% GPU.

En reposo se portaba bien y de forma reproducible: seis generaciones largas seguidas cayeron todas entre 69 y 72 tok/s, que es la cifra honesta de estado estable para ese modelo en esta tarjeta. Sin embargo, durante una de las corridas de benchmark el mismo modelo respondiendo el mismo prompt se desplomó a 19 a 21 tok/s, con el procesamiento de prompt cayendo de unos 800 tok/s a 133. Eso es lo que compra un cuarto de gigabyte de margen: el margen no solo es chico, además se mueve con lo que Windows esté dibujando, así que en cuanto el escritorio pide más VRAM, parte del trabajo se sale de la GPU. La caída es intermitente y no permanente, y precisamente por eso es una base mala para un servicio del que dependen otras personas. Va rápido todas las veces que lo pruebas y lento la única vez que alguien más lo necesita.

El modelo de 4B resuelve esto no por ser más listo, sino por dejar espacio. Su footprint es fijo, 5,515 MiB, así que lo que varía es el espacio libre y no el modelo: alrededor de 2.2 GB libres cuando el escritorio está en reposo y unos 1.4 GB cuando está ocupado. Un margen que absorbe con holgura ese vaivén del escritorio es justo lo que mantiene estable la velocidad. Mover el asistente familiar del 9.7B al 4B es exactamente la decisión que desarrollo en la parte 2, y el razonamiento se generaliza: cuando elijas modelo, revisa la VRAM libre después de cargarlo, no el tamaño del archivo antes de bajarlo.

Lo que obtienes cuando todo está corriendo

#

Terminas con un asistente de IA rápido, siempre disponible y completamente privado: sin suscripción, sin cuenta, sin datos saliendo de tu casa. Cualquier dispositivo de tu red lo alcanza en http://<IP-de-tu-PC>:8080, y sigue respondiendo esté o no alguien frente a la PC.

Los casos de uso son más prácticos de lo que parecen. En mi casa, la familia lo usa para preguntar la contraseña del Wi-Fi, qué servicio de streaming tiene cierta serie, o cómo volver a conectar un dispositivo del hogar inteligente que se cayó de la red. Son el tipo de preguntas que antes requerían una búsqueda en internet o gritar por toda la casa. Tu hogar encontrará sus propios usos cotidianos rápidamente.

Lo que te enseña el proyecto

#

Más allá del asistente en sí, este es uno de los mejores proyectos de home lab que puedes hacer como ingeniero, porque te obliga a cruzar cuatro fronteras en un solo build: GPU passthrough hacia un entorno Linux virtualizado, networking de containers, un firewall de Linux y el puente entre el host Windows y WSL. Cada una de esas habilidades se transfiere directo a lo siguiente que construyas.

Los obstáculos son el plan de estudios, y cuatro de ellos fueron los que más me enseñaron:

• El atajo tentador no siempre es el correcto. El modo espejo habría eliminado por completo el port forwarding, pero rompió el descubrimiento de GPU de Ollama e interfirió con mi VPN. NAT más un script fue la opción menos elegante y la que sí funcionó.
• Los formatos de configuración no son sugerencias. Un prefijo http:// en OLLAMA_HOST bastó para que el servidor se enlazara a IPv6 y quedara invisible para el resto de la LAN. Leer cómo un programa interpreta su propia configuración cuesta mucho menos tiempo que adivinarlo.
• Un arreglo que tienes que recordar no es un arreglo. Reapuntar el reenvío a mano después de cada reinicio no es algo que nadie sostenga por mucho tiempo. Convertirlo en un script y una tarea programada fue lo que volvió a un demo funcional algo en lo que la familia confía.
• Que quepa no es lo mismo que que corra bien. El modelo de 9.7B cupo en 8 GB con 250 MiB de sobra, y Ollama reportaba felizmente 100% GPU. También perdía la mayor parte de su velocidad cada vez que el escritorio quería su VRAM de vuelta. Medir el margen libre después de cargar, en lugar de confiar en el tamaño del archivo, es un hábito que conviene adoptar temprano.

Aunque ninguno de esos problemas aparecía en las guías con las que empecé, cada uno me dejó entendiendo el stack mejor de lo que lo habría entendido con un primer intento sin tropiezos. Ese es el patrón que sigo encontrando en el home lab: cada contratiempo es simplemente otra oportunidad de aprender de errores pasados y seguir mejorando.

¿Qué sigue?

#

Una vez que tu IA privada esté corriendo, el stack se vuelve una base y no un producto terminado. Estos son los caminos que vale la pena explorar después:

• Probar diferentes modelos: Ollama hace trivial descargar y cambiar entre modelos; comparar tu elección inicial con otras opciones open-weight es el siguiente paso natural, y la tabla de arriba te sirve de plantilla para medirlos con honestidad en tu propia tarjeta.
• Agregar un system prompt personalizado: darle al asistente una personalidad y contexto específico del hogar para hacerlo aún más útil en el día a día.
• Acceder desde fuera de tu red: poner Open WebUI detrás de un reverse proxy (Nginx Proxy Manager es un buen punto de partida) y apuntarle un dominio, para que el chatbot sea accesible desde tu teléfono aunque no estés en casa.
• Conectarlo a Discord: un pequeño bot que reenvíe los mensajes a la API de Open WebUI y publique las respuestas de vuelta en un canal, para que la familia lo use desde una app que ya tienen abierta sin necesidad de navegar a una URL. Justo eso construí, y la parte 2 de esta serie documenta el puente completo: Ponle un bot de Discord a tu IA privada para que tu familia sí la use.

Tomes el camino que tomes, lo importante es que el asistente es tuyo: tu hardware, tus datos, tus reglas. Si construyes tu propia versión de esto, me gustaría mucho saber cómo te fue.