Published on 30 October 2026
What is a local AI?
A local AI is an artificial intelligence that runs on a machine the company owns or rents for itself alone: what you give it to read and what you ask it never leave that machine. It is also called « private AI », or « on-premise AI ». At the other end, a public assistant receives your questions on its vendor's servers, along with everything you paste into it.
The question deserves to be asked layer by layer, because an AI platform is not a single program. With us, three processes follow one another when someone asks a question, and they don't give the same answer to "does it run on my own machine?". This page separates them, says what already runs on your side, what leaves, and what it would take for everything to stay.
Three layers, three answers
The first layer reads your documents: it splits them into passages and turns them into vectors, so a search finds the right paragraph however the question is worded. The second sorts: among the passages retrieved, it reranks the most useful ones. The third writes: from the question and the selected passages, it writes the answer in plain French, with its source.
The first two run on your own machine, live, with no key and no bill. The third goes to a model vendor, by default; it can also run on your side, and that's where everything is decided.
| The layer | What it does | Where it runs on our side | Where it stands on 30 October 2026 |
|---|---|---|---|
| Indexing | Splits your documents into passages and turns them into vectors (e5-large model). | On your machine, in your instance. | Live from the start. |
| Reranking | Sorts the retrieved passages to keep only the most useful ones (bge-reranker-v2-m3). | On your machine, in your instance. | Live since 7 September 2026 on up-to-date instances. |
| Writing | Writes the answer from the question and the passages selected, never from the whole knowledge base. | At the provider chosen in the admin settings, Anthropic by default; or at your place, on a model installed on your own machine (Ollama, vLLM, any service that speaks OpenAI's dialect). | Via API: in service. Locally: built, not yet tried for real at a client. |
What goes out, and what doesn't
When the writing step goes out to the provider, it takes with it the question and the passages the first two layers judged useful. Not the knowledge base, not the whole document, not the company's history. The default provider's programming interface (API) doesn't use what's sent to it to train its models. The provider isn't hard-wired into the product: the code calls an abstraction, and the choice is made in the admin settings.
That vendor is an American company, and that is the degree of sovereignty we do not hold today. The page on sovereign AI sets out the four degrees we do hold, and that one. What stays with you in every case: your instance, its database, your documents, their indexing, and the memory the assistant builds up. The data security page gives the technical detail.
Which machine, for what result: our measurements
On 7 September 2026, we ran a seven-billion-parameter writing model on a server with no graphics card, the machine we supply by default, only bigger: it produced between three and six words per second, and it asked for 16 GB of memory, twice what that machine has.
Six words per second means a two-hundred-word answer arriving in more than half a minute. For a background task running overnight, sorting messages or preparing summaries, that is acceptable. For a conversation, nobody uses it twice. To make local chat pleasant, you need a graphics card, and the bill changes order of magnitude: we are not giving a figure, because we have not measured it on that kind of machine.
The chunking and the indexing, for their part, run on a server with 4 cores and 8 GB, alongside everything else on the platform. That is what makes the first half of the journey free: your documents are read on your own premises from the day it is installed.
Our position: the API by default, local later
We think the future belongs to local AI, and that it's worth waiting a little for prices to come down and capabilities to settle. In the meantime, we're pragmatic rather than maximalist: an API provider by default, a local model already possible today for anyone with the hardware, recommended later, and supported when it makes economic sense.
In practice, the product already knows how to talk to a model installed on your premises: the provider is changed in Administration, and any service that speaks OpenAI's dialect is accepted, Ollama and vLLM included. We have not yet run this configuration at a client, and we say so plainly. The day fully local becomes reasonable, switching over will not mean changing product: it is planned in the architecture, and one admin page will be enough.
What you can do right now
Keeping what matters on your side doesn't have to wait for a fully local setup. One instance per company, its own database, indexing on site, a full copy handed over at the end of the contract: that is the foundation, described on the ownership page, and it holds whoever does the writing.
Choose a tool where the model provider is a setting, not a dependency. Cut what leaves down to the strict minimum, and be able to say so to your teams in the AI policy. And when you compare internal chatbots, ask the question layer by layer rather than all in one go: 'is it local?' has no one-word answer, and a vendor who gives you one owes you the rest.
The questions we get asked
- What exactly is a local AI?
- An AI that runs on a machine of your own, on your premises or rented for you alone, and that sends out neither your documents nor your questions. In a full platform, several processing steps follow one another, and each one can be local or not: with us, reading and sorting your documents is local, the writing goes out to a provider by default and can stay with you if you have the machine.
- What machine do you need for a local AI?
- To read and index your documents, an ordinary server is enough: on our side, 4 cores and 8 GB handle that job alongside everything else. To write the answers with a local model, you first need memory (16 GB for a seven-billion-parameter model, in our measurement of 7 September 2026) and, for a fluid conversation, a graphics card. Without one, expect three to six words per second.
- Is a local AI safer?
- It removes one journey: nothing leaves for a vendor. It does not remove the rest: who is allowed to see what, how the machine is backed up and protected, who administers it. A badly administered local AI is less safe than an isolated instance, encrypted and backed up every night, from which only the writing step goes out, reduced to the question and the relevant extracts.
- Local AI or sovereign AI: what's the difference?
- Local says where the software runs. Sovereignty says who decides: what the AI reads, who can question it, what goes into the knowledge base, what you take with you when you leave, and under which law. You can be sovereign over all of that with a writing step that goes to a vendor, and you can run an AI locally without deciding anything at all. Our page on sovereign AI sets out the degrees.
- Can IntraIA run as a hundred per cent local AI?
- Not today as a setup we put into service: it's planned, and it's the direction we're heading. What exists: local indexing and reranking, in service, and a product that knows how to talk to a model installed on your own premises, built, not yet tried for real at a client. We'll support it when a reasonable machine gives a fluid conversation.
To see it
The demo of a manufacturing company is open without signing up. What you will see running locally: the company's procedures read and indexed on site, and every answer citing the passage it comes from. The writing itself goes through the API, as it does with our clients today. Try the demo, or read how the setup works.
