An AI assistant that never sends data outside and runs entirely on the machine it is executed on.
There are some kinds of data that should never leave the place where they are created.
The blueprints of a plant. Maintenance procedures. Machine anomalies that no competitor should ever see.
And yet, today, when we want to ask an AI to read, interpret, or query them, the almost automatic reaction is to open a browser and send them to the cloud.
I started wondering whether those data really needed to leave in the first place.
That question led to LOCUS: a fully local AI assistant, offline by design rather than by technical limitation, built for environments where data and documents need to remain within the organization’s own infrastructure for reasons of security, privacy, or intellectual property.
I am thinking primarily about industry, but the principle is broader.
Why the cloud is not always enough
This is not an ideological position against the cloud.
It is simply that, in some environments, the cloud is not the most suitable solution. An industrial plant, a regulated environment, or a network without a stable connection may have constraints that make it necessary to keep data and processes within the organization’s own infrastructure.
LOCUS starts from the opposite assumption: everything runs locally, on a language model that lives on the same machine that provides the answers.
No network calls during inference. No data leaves the machine.
The only time a connection is needed is for the initial model download. After that, everything runs offline. By choice.
What I actually built
The easy part would have been to take a model, build an interface around it, and call it a local AI.
That was not what I wanted.
I wanted to build a foundation that could eventually become a product, not a weekend experiment. So I separated responsibilities into independent, testable, and replaceable components.
There is a centralized configuration layer, where language, domain, and model are declared rather than scattered throughout the code.
There is a model registry, which treats each local model as a resource with its own metadata: version, quantization, size, checksum. A model is never just a hard-coded path somewhere in the codebase.
There are Domain Packages: self-contained folders that specialize LOCUS for a specific context. Today that context is industrial. Tomorrow it could be something completely different, without modifying the application core.
There is a System Prompt Builder, which combines identity, language, domain, and style in a deterministic order. Always the same way, always verifiable.
And there is a Context Architecture that already separates what will eventually become system context, conversation context, retrieved knowledge, memory, and tools.
RAG, memory, and agents are not there yet.
But the interface to accommodate them was designed before the features themselves.
It seems like a small detail, but I think it matters: if you already know where you want to go, you can avoid building a new road every time.
The lesson I did not expect
There is one episode that, more than the architecture itself, captures what it means to build something like this.
At one point, I chose the smallest and fastest model available to me.
It was three times smaller and twice as fast according to the metrics I had measured with my benchmark.
Perfect numbers.
Then I tried speaking to it in Italian.
Incorrect grammar. Made-up words. When I asked the simplest possible question, “introduce yourself in one sentence,” it simply repeated the question instead of answering it.
Three attempts out of three.
The benchmark measured speed and size. It did not measure something much simpler: whether the model could actually speak the language I had asked it to speak.
I went back and kept the larger model as the default.
Since then, I have kept one simple rule in mind:
a number that wins on one metric does not automatically win on the real problem.
It applies to AI models. It probably applies to a lot of other things too.
The point is not just running a model locally
LOCUS is still a core, not a finished product.
It does not have RAG yet. It has no persistent memory. It does not orchestrate agents. It does not communicate with external tools through MCP.
But it is built so that these capabilities can be added without having to rewrite what already exists.
It is the difference between designing a foundation and adding rooms one at a time, hoping the house will hold.
The goal is not to prove that you can run an LLM on a laptop.
That, by now, is relatively simple.
The goal is to understand whether it is possible to build an AI that is serious, specialized, and genuinely multilingual. Not multilingual simply because there is a list of supported languages, but because language and domain are part of the design itself.
And above all, an AI that does not have to ask permission from a server you do not control.
I wonder whether, a few years from now, an AI that never leaves the factory will seem like the obvious choice rather than a special solution that needs to be justified every time.
For now, I keep building it.
One layer at a time.
P.S. If you are curious to try LOCUS in its experimental version, drop me a private message at contact@rheorix.com.
