Asistentes personales locales: de chatbot a compañero con memoria

Le pedí a mi asistente que me resumiera el día. No me dio la previsión del tiempo ni las noticias generales. Me dijo que tenía una reunión en 45 minutos, que el contenedor de Plex llevaba tres días reiniciándose cada hora, que ayer había mencionado querer comprar un Mac Mini M2, y que el último commit del zettelkasten era de hacía dos días. Todo sin que yo se lo pidiera explícitamente.

Esa es la diferencia entre un asistente que responde y uno que conoce el contexto. No es magia. Es arquitectura.

El límite de los asistentes comerciales

Siri, Alexa y Google Assistant entienden comandos. Pero no entienden a la persona que los da. Cada interacción empieza de cero. No recuerdan que ayer preguntaste por precios de hardware. No saben que estás trabajando en un proyecto específico. No tienen acceso a tus servicios, tus notas, tu calendario de forma real.

Además, cada petición sale de tu casa, se procesa en servidores ajenos, y vuelve. No controlas qué se guarda, ni durante cuánto tiempo, ni para qué se usa. La privacidad es una promesa, no una garantía técnica.

Qué hace diferente a un asistente local

Un asistente local no es solo un LLM corriendo en tu hardware. Es un sistema que combina tres cosas que los asistentes comerciales no tienen —o no te ofrecen—:

1. Memoria persistente: sabe quién eres, qué proyectos tienes, qué preferencias tienes, qué conversaciones habéis tenido.
2. Herramientas propias: puede leer tu calendario, consultar el estado de tus servicios, enviar mensajes por tus canales, buscar en tus notas.
3. Privacidad real: los prompts no salen de tu red. Tus datos son tuyos.

El resultado es algo que se siente menos como interactuar con un altavoz inteligente y más como hablar con alguien que te conoce.

Arquitectura: cómo se construye

No hace falta ser ingeniero de Google. Con hardware modesto y software open source se puede montar algo funcional en un par de tardes. Mi stack actual:

• Ollama: sirve modelos de lenguaje localmente. Uso Gemma 4 12B para conversación general y Qwen 3 8B para tareas técnicas.
• OpenClaw: el runtime que orquesta conversaciones, gestiona la memoria entre sesiones, y conecta el modelo con herramientas.
• MCP (Model Context Protocol): define qué herramientas tiene disponibles el modelo y cómo usarlas de forma segura.
• Mattermost: el canal de comunicación. Recibe notificaciones, comandos slash, y actúa como interfaz cuando no estoy en el ordenador.
• n8n: ejecuta flujos automáticos que el asistente puede disparar: backups, checks de salud, generación de resúmenes.

Todo corre en un Mac Mini M2 con 16GB de RAM y un par de contenedores Docker. Coste de infraestructura: cero mensual. Coste de API: cero.

La memoria: el ingrediente clave

Lo que transforma un chatbot en algo útil es la memoria. No la memoria de la conversación actual —eso ya lo hace cualquier LLM— sino la memoria entre sesiones, la que persiste días, semanas, meses.

Mi asistente mantiene varias capas de memoria:

• Contexto de sesión: lo que hablamos ahora. Se pierde cuando termina la sesión, como cualquier chat.
• Memoria a corto plazo: notas del día, decisiones recientes, tareas pendientes. Se guarda en archivos diarios.
• Memoria a largo plazo: preferencias, proyectos activos, lecciones aprendidas, relaciones entre ideas. Se mantiene en un archivo curado que el asistente lee al empezar cada sesión principal.

Esto significa que si ayer le dije que estaba evaluando un Mac Mini M2, hoy puedo preguntar '¿cuál es el mejor precio que has visto?' y sabe de qué hablo. No necesito repetir el contexto cada vez.

Herramientas: de hablar a actuar

La parte más potente no es que entienda lo que dices. Es que puede hacer cosas con esa información. Gracias a MCP, el modelo descubre qué herramientas tiene a su disposición y decide cuándo usarlas.

Ejemplos reales de mi setup:

• Consultar el estado de contenedores Docker y decidir si reiniciar uno que está fallando.
• Leer archivos de configuración antes de responder preguntas técnicas, para no inventar rutas o parámetros.
• Enviar mensajes a canales de Mattermost cuando detecta algo que requiere atención.
• Buscar en el zettelkasten para conectar ideas nuevas con notas antiguas.
• Generar posts para el blog (como este) y guardarlos directamente en el sistema de archivos.

El modelo nunca tiene acceso directo a todo. Pide al servidor MCP que ejecute acciones, y el servidor decide si esa acción está permitida. Es como darle a alguien un juego de llaves limitado en lugar de la llave maestra.

La privacidad como efecto secundario inevitable

Cuando todo corre en tu red local, la privacidad no es una función que tengas que activar. Es el estado por defecto. Tus conversaciones no entrenan modelos ajenos. Tus datos no se envían a ningún lado. No hay políticas de privacidad que leer porque no hay terceros involucrados.

Esto es especialmente relevante cuando el asistente accede a información sensible: estado de salud financiera, conversaciones personales, proyectos profesionales, contraseñas (aunque nunca debería tener acceso directo a ellas). Saber que nada sale de tu casa cambia cómo interactúas con él. Te permite ser más honesto, más específico, más tú.

Limitaciones actuales

No todo es perfecto. Los modelos locales, por muy buenos que sean en 2026, siguen por detrás de los modelos de nube en razonamiento de varios pasos y conocimiento actualizado. Si necesito investigar algo que pasó ayer, el asistente local no lo sabe a menos que yo se lo diga o use una herramienta de búsqueda web.

También hay un coste de mantenimiento: actualizar modelos, curar la memoria para que no crezca descontrolada, revisar que los flujos automáticos sigan funcionando. Es un proyecto activo, no un producto que instalas y olvidas.

Y por supuesto, necesitas cierta comodidad técnica. No es tan sencillo como desempaquetar un altavoz inteligente. Pero tampoco requiere ser experto. La documentación de Ollama, los contenedores Docker preconfigurados, y las comunidades activas han reducido mucho la barrera de entrada.

Hacia dónde va esto

El siguiente paso evidente es la integración con hardware local: asistentes de voz que funcionen sin nube, reconocimiento facial para presencia, sensores que alimenten contexto al sistema sin que yo tenga que escribir nada.

También quiero que el asistente sea más proactivo. Ahora responde cuando le hablo y ejecuta tareas programadas. Me gustaría que iniciara conversaciones cuando detecta algo relevante: 'He visto que no has sincronizado el zettelkasten en dos días, ¿quiero que lo haga?' o 'El precio del Mac Mini M2 que estabas mirando ha bajado 50€'.

Eso ya es posible técnicamente. La diferencia entre posible y útil está en no cruzar la línea donde el asistente pasa de ser útil a ser intrusivo. Ahí es donde la curación humana sigue siendo necesaria.

Conclusión

Un asistente local no es una versión peor de Siri. Es algo diferente: un sistema que conoces, que conoces tú, que opera en tu territorio con tus reglas. No es para todo el mundo. Pero si valoras el control, la privacidad y la posibilidad de que la tecnología se adapte a ti en lugar de al revés, 2026 es un buen momento para empezar.

Mi asistente sigue siendo imperfecto. A veces se equivoca, a veces no entiende el contexto, a veces falla una herramienta. Pero cuando funciona, se siente menos como tecnología y más como tener a alguien en el equipo que se encarga de las cosas. Y eso, en mi experiencia, vale cada hora invertida en montarlo.

¿Tienes un asistente personal local? ¿Lo has intentado? Cuéntalo en los comentarios o en el canal #proyectos.