When choosing a tool people look at the features, the price and the interface. The question that comes before all three, and rarely appears on the product page, is where it runs: on the machine where the work happens, or on somebody else’s server.
What actually changes
If the program runs locally, the document is not disclosed to anyone. There is no recipient to write into the record of processing, no processor to appoint, no transfer to justify. The tool is like the practice software installed in the office: it processes the data, but inside the perimeter of whoever already had it.
If it runs in the cloud, every document is a disclosure to a third party. From then on you need the Article 28 agreementopens in a new tab, the line in the record, the transfer assessment if the supplier sits outside the Union, and the ability to answer a client asking where their files went.
The cloud is not forbidden. The cloud moves the problem from a technical choice to a set of obligations, and each of those has to be kept alive over time.
The hidden cost of each route
Cloud costs less to build and more to explain. Every time the supplier changes sub-processor, data centre or terms, something you wrote stops being true, and that something is your document.
Local costs more to build, a model running on a laptop is a real engineering problem, and almost nothing to explain, because the sentence “the documents do not leave” has no maintenance.
The middle case that looks local and is not
Between the two routes sits a third that presents itself as the first and behaves like the second: the application installed on the computer that, every time it has to do anything, sends the text to a server. Technically it is installed software; from the data’s point of view it is cloud with an icon on the desktop.
Telling it apart takes no expertise, because it leaves three traces. The first is the download size: a model that really runs on the machine is a file, and model files weigh gigabytes. A program that installs in twenty megabytes and claims to reason on its own is reasoning somewhere else. The second is sign-in: if using it means registering and staying connected, somebody is counting the requests, and to count them they have to receive them. The third is the test worth more than the other two: unplug the network and try to work.
It is worth adding that there is nothing dishonest about the second model, as long as it is declared. What should not be accepted is the word “local” used to mean “installed”: those are two statements about two different things, and only one of them answers the client’s question about where their filings went.
What kind of machine it actually takes
The reasonable objection to going local is always the same: it needs a computer we do not have. The answer depends entirely on which job you want done on the machine, and the two jobs are very different sizes.
Recognising a name, a tax code, an IBAN and a land registry reference in an Italian document is a narrow task: a small model does it, helped by check algorithms for the values that have one, and it runs on the laptop already in the office. It is also the task that has to be local, because it is the one that sees the document in the clear. Reasoning over sixty pages is a wide task: it wants a large model, and a large model wants memory an office machine does not have.
Which is where the technical, not ideological, case for the mixed setup comes from: put the small part that needs the real data on the machine, and leave outside the large part, which on substituted text no longer needs to know who anyone is. It is the opposite of a compromise: it is putting each job where it costs least.
The questions that survive going local
Running locally does not settle everything, and three questions remain. Does the program send telemetry? A client shipping usage statistics opens a channel, and on a product promising the opposite that is the fastest way to contradict itself. Where does it keep its intermediate data, and is it encrypted? A mapping dictionary sitting in the clear in a temporary folder is an archive of personal data. And does it really work without a network, or does “local” only mean the interface is installed?
The third one takes thirty seconds to check: unplug the network and try. It is the most honest test there is on this category of product.
The mixed setup, and why it makes sense
The route a firm almost always ends up on is a mixed one, and it is not a compromise: the analysis and the substitution happen locally, and only the already pseudonymised text goes to the cloud, to the large model you need for the real reasoning.
It works because it separates two different jobs. Recognising a tax code and a name in an Italian document is a small job that a small model does well on the spot; reasoning over sixty pages is a large job that needs a large model and that, on substituted text, is about nobody.
That is how Omissia is built. What a model remembers about what it receives is in the other piece; how it works, step by step, is in How it works.