On-Prem or EU Cloud for AI on Engineering Data

“Do you also offer on-premise?” is the question asked fastest and justified least often in selection meetings. Behind it sits almost always the same assumption: whatever runs in our own building is safer.

That assumption does not survive scrutiny. On-premise does not change the level of protection, it changes who is accountable. Once those two are separated, the question takes twenty minutes to settle rather than three meetings.

What separates on-prem from EU cloud?

There are not two models but three. The middle one is regularly overlooked in selection processes, even though it fits most often.

Model	Who operates it	Where the data sits	Who patches and monitors
EU cloud (shared)	provider	EU data centre	provider
Dedicated instance	provider	EU data centre, own tenant	provider
On-premise	you	your own data centre	you

The decisive column is the right-hand one. It determines effort, cost and, when it matters, how quickly a security hole gets closed.

Is on-premise safer?

Not on its own. Security comes from four things: current software, controlled access, monitoring and working backups. None of them follows from where the metal stands.

A server in your own building that nobody updates after the project closes is the worse option. It only looks better because you can touch it. Conversely, an EU-hosted solution with a data processing agreement, excluded training use and governed deletion periods meets GDPR requirements in full. Which assurances belong to that is set out in detail in EU hosting and AI.

The honest sentence is therefore this: on-premise relocates responsibility, it does not automatically raise the standard. That is a good trade when you have the team for it. It is a bad one when maintenance after go-live rests on one person whose actual job is something else.

What does running it really cost?

With on-premise the visible part sits in the quote and the more expensive part sits beside it. The full picture includes:

• Hardware including GPUs if language models are to run in house, plus cooling and electricity.
• Updating models and software. A stack untouched for two years falls behind what users have come to expect elsewhere.
• Monitoring and on-call duty. Who gets the call at 10pm when search is down?
• Backups and recovery, rehearsed regularly rather than merely configured.
• Security patching at the speed your own policy prescribes.

None of these items is exotic. They simply do not arrive as an invoice but as working hours, which is why they often never enter the comparison at all.

Which requirement genuinely forces on-premise?

There are good reasons, and you can recognise them by the fact that they come from outside:

• Contractual obligations from your customers, typically in defence and security or for supplies under elevated confidentiality levels.
• Export control requirements covering certain technical documents.
• A manufacturing or development network without internet access. If the network has no route outward, the discussion is moot.
• An internal policy with no exemption clause. Even where it is technically debatable, changing it takes longer than the project.

And the justifications heard most often in practice that are not reasons: “our data is highly sensitive” argues for a good provider, not against the cloud. “Because of the GDPR” is factually wrong as long as EU hosting and a data processing agreement are in place.

Who is liable for what?

This is where the models genuinely differ in legal terms.

In cloud operation you remain the controller under the GDPR and the provider is the processor. The data processing agreement governs what they may do, whom they engage and when data is deleted. You keep audit and inspection rights without running the technology.

With on-premise both roles fall to you. There is nobody contractually bound to deletion periods and subprocessor transparency, because there are no subprocessors. That is a simplification and at the same time the loss of a safeguard: every operational mistake is yours alone.

What does IT ask during selection?

A serious provider answers this list without hesitation:

1. Which data centre, operated by whom, with which certifications?
2. Is there a US parent company? If so, the US Cloud Act applies regardless of server location.
3. Is the use of our data for model training contractually excluded?
4. Which subprocessors are involved, and are changes announced?
5. What deletion periods apply, and are they in the contract rather than available “on request”?
6. How are access rights from our source systems carried over?
7. If on-premise: what exactly falls to us, and what stays with the provider?

Question 7 is the one most often missing. It decides whether on-premise is an operating model or a handover point with nothing attached on the far side.

How do you decide?

If this applies to you	it argues for
Customer obligation, export control or a network without internet	on-premise
Own IT with server operations experience and capacity for it	on-premise viable
A separation requirement but no operations team	dedicated instance
Sensitive data, GDPR requirements, no external compulsion	EU cloud
Fast start, predictable cost	EU cloud

Anyone landing in more than one row should start with the dedicated instance. It is the only path that stays open in both directions later.

How KoAssist handles it

The default is EU cloud: hosting in German data centres, ISO 27001 certified, no transfer to third countries. Your documents are indexed for search and stored encrypted, while your source systems remain authoritative. Any use of your data for model training is excluded, and on written request all data is deleted in full within 48 hours.

On-premise is available where needed. We recommend it when one of the external reasons above applies, and advise against it when none does. The details on encryption, permission handling and deletion are on the security page.

If you want to know which model holds up in your case: in a demo we work through the seven questions above against your actual setup. Including when the answer turns out to be that the cloud is enough.