"Then we will just run the AI locally, and the data stays in house." The sentence comes up in a lot of meetings, right when the data protection question gets uncomfortable, and it is correct. It just answers a narrower question than the one that was asked. A local AI takes two duties under the Swiss Data Protection Act off your plate. The duty that decides whether company data is safe at your firm stays exactly where it was. And a third one arrives the moment the hardware sits in your rack.
What a local AI genuinely clears away
Two chapters of the Data Protection Act fall away, and that is no small gain.
The first is processing by a processor. Art. 9 para. 1 DSG allows you to hand the processing of personal data to a processor if it processes the data only as you would be allowed to yourself, and if no duty of confidentiality prohibits the transfer. Under paragraph 3, the processor may pass the work to a third party only with your prior authorisation. If the model runs on your hardware and nobody outside sees the data, there is no processor for that step. No contract to review, no subprocessor list that could be missing a language model. With a rented service that is precisely the work, and we described it in our article on the data processing agreement for AI tools.
The second is the route abroad. Art. 16 para. 1 DSG permits disclosure of personal data abroad where the Federal Council has determined that the country concerned provides adequate protection; otherwise paragraph 2 requires a separate mechanism, such as standard data protection clauses. Art. 5 let. e DSG defines "disclosing" as "transmitting or making personal data accessible". If the data stays in the building, nothing is transmitted and nothing is made accessible. The whole chapter is settled for that processing step, including the question of which region a provider stores in and where it keeps a copy for abuse monitoring.
That is the honest gain, and for some companies it is reason enough. It comes with a condition that tends to get lost in the discussion.
"Local" does not automatically mean "no processor"
In our experience, very few SMEs with 30 to 250 employees run their server room entirely on their own. The hardware sits in your building, the hands on it are external: the IT service provider who patches, checks backups and holds administrative access.
If that provider works for you on a system holding personal data, it generally qualifies as a processor. Art. 9 DSG is back, just with a different name on the contract. This is not an argument against running it yourself. It only shifts what you check: instead of a software vendor's data processing addendum, the contract with the partner who looks after the box, and the question of who holds administrator rights there.
In our experience, that is the first place where the "local means less paperwork" calculation stops adding up.
The duty that does not get smaller
Art. 8 para. 1 DSG requires the controller and the processor to "ensure data security appropriate to the risk by means of suitable technical and organisational measures". Your company remains the controller, wherever the model does its computing. The Data Protection Ordinance turns that into four objectives in Art. 2: confidentiality, availability, integrity and traceability.
The first of those is the point where local AI and cloud AI are identical. Art. 3 para. 1 let. a DSV requires measures ensuring that "authorised persons have access only to the personal data they need to perform their tasks". That access control is the same rule whether the server sits in Baar or in Dublin.
And it is the rule that AI rollouts hang on, in our experience. An assistant answers with whatever it can reach. If it searches the file server where the folder with the payroll statements is open to everyone, it passes the contents on to everyone, in fluent sentences and without anyone having to search. Before, somebody would have had to find it. Now the question is enough.
The location of the server changes none of that. What it does change is the permissions work beforehand: which stores the system indexes, with which rights it does so, and which data is allowed in at all. Classifying that data is the same step we described for rented services when we wrote about which company data belongs in ChatGPT. A local model does not make that step unnecessary. It only takes away your argument for postponing it.
The second half of the same question belongs here: what the system may do without asking. Reading is one permission, writing and sending are two more. You grant all three yourself, and a model in your own building does not get them handed out any more sparingly than one at a provider.
What arrives once you run AI locally
The Data Protection Ordinance requires in Art. 3 para. 2, among other things, that "operating systems and application software are always kept at the latest security level and known critical vulnerabilities are closed", that availability can be restored quickly after an incident, and that malfunctions are reported.
With a rented service, the provider handles that, and your job is to check that it commits to it and can show evidence. Running it yourself, it is an on-call rota. A model server is software with its own stream of vulnerabilities: graphics card drivers and a search index that has to be rebuilt when permissions change. None of this is exotic. It just needs somebody who has it in the calendar.
The fourth objective in Art. 2 DSV, traceability, gets more concrete depending on the application. Art. 4 DSV requires private companies to log processing steps where sensitive personal data is processed automatically on a large scale, or high-risk profiling takes place, and preventive measures cannot ensure data protection. Art. 5 DSV requires processing regulations in those same two cases.
These thresholds can be named. Under Art. 5 let. c DSG, sensitive personal data includes health data, genetic and biometric data, and information on religious, political or trade union views. For the assistant that summarises meeting notes and drafts quotes, neither case usually applies. For a system that processes health data on an ongoing basis, the first one does. The difference is readable from those two cases, not from a gut feeling.
In our experience this operating question gets asked after the hardware has been bought. That is the wrong order, and it costs more than a conversation beforehand.
When local is the right answer
There are cases where a local AI is not a preference but the only route.
The clearest one is in the law itself. Art. 9 para. 1 let. b DSG permits the transfer to a processor only if "no statutory or contractual duty of confidentiality prohibits the transfer". Anyone bound by professional secrecy, or holding a client contract that lists the permitted subprocessors individually, cannot negotiate that hurdle away. Running it yourself then becomes the precondition for being allowed to use the tool at all.
The second case is plain: no usable connection. Production halls and vehicles in the field. If the service has to work offline, that settles the question without a data protection discussion.
The third is arithmetic. With a rented service you pay per use; running it yourself, you pay for acquisition and operation, and those continue even in a month when the system is barely asked anything. If the same step runs thousands of times a day, that calculation eventually tips towards your own hardware. Where the tipping point sits depends on your volume and on the models you need; we know of no figure that holds for everyone. The honest version is to measure the workflow on a rented service first and then do the maths.
One case we hear regularly does not belong on this list: "We want to be sure nobody trains on our data." The concern is legitimate, but the commitment is already in the business contracts. Microsoft states for Microsoft 365 Copilot that prompts, responses and data accessed through Microsoft Graph are not used to train the foundation models. OpenAI writes for Enterprise, Business, Edu and the API platform that inputs and outputs are not used by default for training or improving the models. That is a contract question, not a location question. It alone does not call for a server.
The order both routes share
Four questions come before the location question, and they are the same in both variants.
Which data does the workflow you want to automate touch? Which stores may the system read, and are the permissions there correct today? What may it do without a human approval? And who operates it in twelve months, when the person who set it up is away for three weeks?
Once those four answers are in place, the location question is settled in ten minutes, usually on the basis of confidentiality duties and volume. If they are not in place, your own hardware does not solve the problem either, it just moves it into your own basement. In AI governance for SMEs we therefore work in this order and start with permissions, not with infrastructure. What that involves on an ongoing basis is set out on our page on AI in day-to-day operations.
If a quote for your own hardware is currently on the table, these four questions are worth the time beforehand. That is what the free initial conversation is for, and it not seldom ends with the observation that a rented service is enough for your case.
The sentence that is not written in the server room
A local AI answers the question of where the computing happens. It does not answer who may see what, and that is the question that counts when it matters. Which folders would a model at your company be able to reach today, before anyone has gone through the permissions?
Frequently asked questions
Is a local AI compliant with Swiss data protection law?
It can be, but not automatically. Running it yourself removes processing by a processor under Art. 9 DSG and disclosure abroad under Art. 16 DSG. Data security under Art. 8 DSG and access control under Art. 3 DSV remain your duty unchanged, regardless of where the server stands.
When is a local AI worth it for an SME?
In three situations. When a statutory or contractual duty of confidentiality prohibits the transfer to a processor, when the service has to work without a connection, or when the volume is high enough that acquisition and operation cost less than paying per use.
Do I need a data processing agreement if the AI runs locally?
Not for the model provider, as long as nobody outside sees the data. But if an IT service provider looks after the hardware and holds administrative access, it generally qualifies as a processor. You then need the contract with that partner, simply with a different name on it.
