AI does not have to run in the EU in every case. The decision depends on your data, contracts and actual access paths. Start with one process: an approved cloud service may suit public product descriptions. Customer data needs a review of processing and contracts; contractually protected design files may require infrastructure you control.
A server in Frankfurt answers only part of the question. Prompts might be processed there while logs, support access or connected services take other routes. Compare the complete data flow before choosing a hosting location.
What "where does the AI run" means technically
If your company uses a language model, there are essentially four deployment models, and they differ considerably in where your data flows.
Model API with US processing. Inputs are processed on US infrastructure in this setup. Whether that applies to a particular service depends on the product, selected region and contract. The model provider’s headquarters alone do not tell you where processing happens.
EU region of an international cloud provider. An EU region can provide European processing. Check the commitments for model calls, storage, backups and support separately. Selecting a region does not guarantee that every connected service and access path stays in that jurisdiction.
European provider. European headquarters and infrastructure may fit your contractual and control requirements. Still check subprocessors and connected services. Test the available model against your actual tasks and explicit quality criteria.
Own infrastructure and local models. A model you operate can keep sensitive processing inside your network. Logs, backups, telemetry and integrations must be configured accordingly. Hardware, updates, permissions and operations remain your responsibility or your operating partner’s.
The legal level: what is actually required
The GDPR does not impose a blanket requirement to host in a particular EU country. It requires the specific processing to be lawful and protected.
Personal data requires a defined purpose, an appropriate legal basis and safeguards, among other obligations. Where a provider processes data on your behalf, Article 28 requires a processing agreement. Transfers outside the EEA also need to meet Chapter V requirements. These transfer safeguards do not replace the legal basis for processing. See the GDPR.
The EU-US Data Privacy Framework permits transfers to participating US companies within the scope of their certification. Check the recipient and the data covered. Other transfer instruments, such as Standard Contractual Clauses, have their own conditions; an extra signature does not provide blanket protection.
Alongside the GDPR, there is a second, often overlooked source of obligations: your own contracts. Many SMEs have customer contracts with confidentiality clauses, requirements regarding subcontractors, or explicit stipulations about the place of processing. Anyone who works for automotive corporations, public authorities, or the healthcare sector knows this. These contractual obligations can be stricter than the GDPR, and they also cover design data, cost calculations, or source code, meaning data with no personal reference whatsoever.
The most important sorting question is not "Is US cloud allowed?" but: which types of data flow into which system? Personal data, contractually protected data, and non-critical data have different requirements. Throwing them all into one pot makes the location question unsolvable. Separating them makes it answerable.
The strategic level: not a legal requirement, but smart risk management
Even if everything is legally clean, a second question remains: how dependent do you want to be? That is not a data protection question, but an entrepreneurial one.
Three risks deserve attention. First, pricing power: a costly provider switch weakens your negotiating position. Second, change risk: models, prices and features can change, so test how your process would work with an alternative. Third, dependency on transfer conditions: record which data flows would need reassessment if the legal requirements changed.
Which tier for whom: an honest assessment
Not every company needs GPU servers. These three deployment options help narrow the choice to your actual requirements.
Tier 1: EU processing with documented conditions. Consider this option when a managed cloud service covers your process. Record data flows, retention, training use and access. EU hosting and a processing agreement alone do not meet every GDPR obligation.
Tier 2: European providers for additional control. Where contracts or procurement rules require it, consider the provider’s headquarters and jurisdiction too. You must still check for third-country transfers through subprocessors or support access.
Tier 3: local models for core data. A locally operated model may suit sensitive design documents, formulas, or client and patient data. Where tasks can be separated by data type, a hybrid architecture may also fit: approved non-critical tasks use cloud models while protected data is processed locally. Check that integrations maintain that separation.
Location is an architecture decision, not a matter of faith
Assess each process against its data, legal and contractual obligations, and acceptable provider dependency. Then test suitable deployments for quality, effort and cost. Two processes in the same company may need different solutions.
For one process, write down its input data, permitted users and contractual location requirements. Use that to assess providers. If it is unclear which deployment can meet those requirements technically, we can help assess and implement it. Start by describing the process and systems involved, without sending confidential documents. Discuss your AI deployment.
