Un asistente de IA que no envía datos al exterior y funciona completamente en la máquina en la que se ejecuta
Hay datos que nunca deberían salir del lugar donde se generan.
Los planos de una planta industrial. Los procedimientos de mantenimiento. Las anomalías de una máquina que ningún competidor debería llegar a ver.
Y, sin embargo, hoy, cuando queremos pedirle a una inteligencia artificial que los lea, los interprete o nos permita consultarlos, el reflejo casi automático es abrir un navegador y llevarlos a la nube.
Me pregunté si realmente era necesario sacar esos datos de allí.
De esa pregunta nace LOCUS: un asistente de IA completamente local, offline por diseño y no por limitación técnica, pensado para contextos en los que los datos y los documentos deben permanecer dentro de la propia infraestructura por motivos de seguridad, privacidad o propiedad intelectual.
Pienso sobre todo en la industria, pero el principio es más amplio.
Por qué la nube no siempre es suficiente
No es una cuestión ideológica contra la nube.
Es que, en determinados contextos, la nube simplemente no es la solución más adecuada. Una planta industrial, un entorno regulado o una red sin una conexión estable pueden tener restricciones que hagan necesario mantener los datos y los procesos dentro de la propia infraestructura.
LOCUS parte del supuesto contrario: todo funciona localmente, sobre un modelo de lenguaje que vive en la misma máquina que responde.
Ninguna llamada de red durante la inferencia. Ningún dato sale de la máquina.
El único momento en el que se necesita una conexión es para descargar el modelo inicialmente. Después, todo funciona offline. Por elección.
Qué he construido realmente
La parte fácil habría sido coger un modelo, construir una interfaz alrededor y llamarlo IA local.
No era eso lo que quería.
Quería construir una base que pudiera convertirse en un producto, no en un experimento de fin de semana. Por eso separé las responsabilidades en componentes independientes, comprobables y sustituibles.
Hay una capa de configuración centralizada, donde se declaran el idioma, el dominio y el modelo, en lugar de distribuirlos por el código.
Hay un model registry, que trata cada modelo local como un recurso con sus propios metadatos: versión, cuantización, tamaño y checksum. El modelo nunca es simplemente una ruta escrita a mano en algún lugar del código.
Están los Domain Packages: carpetas autónomas que especializan LOCUS para un contexto determinado. Hoy es el industrial; mañana podría ser cualquier otro, sin modificar el núcleo de la aplicación.
Hay un System Prompt Builder, que combina identidad, idioma, dominio y estilo siguiendo un orden determinista. Siempre de la misma manera, siempre verificable.
Y existe una Context Architecture que ya separa lo que serán el contexto del sistema, la conversación, el conocimiento recuperado, la memoria y las herramientas.
RAG, memoria y agentes todavía no están ahí.
Pero la interfaz para incorporarlos se diseñó antes que las propias funcionalidades.
Me parece un detalle importante: si ya sabes adónde quieres llegar, puedes evitar tener que construir un camino nuevo cada vez.
La lección que no esperaba
Hay un episodio que, más que toda la arquitectura, explica lo que significa construir algo así.
En un momento dado elegí el modelo más ligero y rápido de los que tenía disponibles.
Era tres veces más pequeño y dos veces más rápido según las métricas que había medido con mi benchmark.
Números impecables.
Después intenté hablar con él en italiano.
Gramática incorrecta. Palabras inventadas. Ante la petición más sencilla, «preséntate en una frase», respondía repitiendo la pregunta en lugar de contestar.
Tres intentos de tres.
El benchmark medía velocidad y tamaño. No medía algo mucho más sencillo: si el modelo realmente sabía hablar el idioma que le había pedido.
Volví atrás y mantuve el modelo más pesado como predeterminado.
Desde entonces me he quedado con una regla sencilla:
un número que gana en una métrica no gana automáticamente en el problema real.
Vale para los modelos de IA. Probablemente también para muchas otras cosas.
El objetivo no es simplemente ejecutar un modelo localmente
LOCUS es hoy un núcleo, no un producto terminado.
Todavía no tiene RAG. No tiene memoria persistente. No orquesta agentes. No se comunica con herramientas externas mediante MCP.
Pero está construido para que estas funcionalidades puedan añadirse sin tener que reescribir lo que ya existe.
Es la diferencia entre diseñar unos cimientos y añadir habitaciones una a una esperando que la casa aguante.
El objetivo no es demostrar que se puede ejecutar un LLM en un portátil.
Eso, a estas alturas, es relativamente sencillo.
El objetivo es entender si se puede construir una IA seria, especializada y realmente multilingüe. No multilingüe simplemente porque exista una lista de idiomas compatibles, sino porque el idioma y el dominio forman parte del propio diseño.
Y, sobre todo, una inteligencia artificial que no tenga que pedir permiso a un servidor que no controlas.
Me pregunto si dentro de unos años una IA que nunca abandona la fábrica nos parecerá una elección obvia, en lugar de una solución particular que haya que justificar cada vez.
Por ahora sigo construyéndola.
Una capa cada vez.
P. D. Si tienes curiosidad por probar LOCUS en su versión experimental, escríbeme a contact@rheorix.com
