enaudo
Where your systems run and what they are made of
The systems we build and operate for you run almost exclusively on servers in the EU. They are made almost exclusively of open source or custom code, so usually without subscriptions for third-party software. They can also run on your own infrastructure instead of ours. AI models can run locally on request. We name any exceptions before the project starts.
Four principles for the systems we build
They are our standard for what we develop and operate for you. We name exceptions upfront.
-
Servers in the EU
Your systems run almost exclusively on servers in the EU. We tell you which providers we use before the project starts. We name exceptions up front. On EU servers, operation generally involves no transfer to third countries, provided nobody in a third country accesses the data.
-
Open source or custom code
We rely on open-source software, write the code ourselves or mix both. This means there are usually no ongoing licence fees for third-party software. Your rights to our code are set out in the contract. Examples of open building blocks are PostgreSQL (database), Caddy (web server), Temporal (workflow orchestration) and Zitadel (sign-in). Each building block has its own licence, which we name for you.
-
Local AI models possible
AI models can run on servers that you control, so that content does not go to an external AI provider. Where an endpoint in the EU is enough, we use that. We decide per task, more on this below.
-
API, MCP and central login
What we build ourselves usually offers an application programming interface (API) and speaks MCP, the Model Context Protocol, the open standard through which AI assistants use tools. Where the central login is set up, one login is enough for our own tools (single sign-on). This depends on the project and applies to tools we build ourselves. We do not retrofit third-party programs with it.
Why it matters
Three reasons that make a difference in practice.
Law and access
If a system runs on servers in the EU and no party in a third country accesses it, operating it involves no transfer to a third country within the meaning of Chapter V GDPR. Providers based in the USA can also be subject to the US CLOUD Act, even if their data centres are in the EU. The Act can require US providers to disclose data in their possession, custody or control to US authorities, even if it is stored abroad. This is not legal advice. For what applies in your case, ask your data protection officer or a lawyer.
Sources: GDPR, Chapter V (EUR-Lex)US CLOUD Act, 18 U.S.C. § 2713 (Cornell)
Cost
With subscription software, the provider sets prices and limits and can change them. Open-source components carry no licence fee. The quote sets out what operation and usage rights to our code cost. Hosting and further development still cost money, but they stay plannable and you have a say.
Switching and independence
Closed systems tie data and workflows to one provider. Switching can then become complex and expensive. Open formats and interfaces make switching easier. What applies to our code afterwards is set out in the contract.
The comparison
| Criterion | Closed system on subscription | With enaudo |
|---|---|---|
| Server location | Set by the provider, often outside the EU as well. | Almost exclusively in the EU or on your own infrastructure. Exceptions named in advance. |
| Source code | Usually not viewable. | Almost exclusively open source or custom code. Source code access is set out in the contract. |
| Ongoing licence costs | Subscription per user or module, prices set by the provider. | No licence fees for open-source components. Operation and usage rights are set out in the quote. |
| Switching | Often complex, because data and workflows sit in the provider's system. | Data can be exported via interfaces and open formats. Switching and use afterwards are set out in the contract. |
| AI model | Usually set by the provider. | Chosen per task: local or EU endpoint. |
| Data export | Often limited to the provider's formats and routes. | Via interfaces and open formats. |
The left column describes typical patterns of closed subscription systems, individual products can differ. The right column applies to systems we build, whether we run them or you do.
Local AI models: when they make sense
Local is not mandatory and not always the best choice. We decide with you, task by task.
Local makes sense
Especially for sensitive data.
- HR, contract or other highly sensitive content that should not leave the system.
- When you want to stay independent of an AI provider's prices and terms.
- When a small, well-suited model handles the task reliably.
An EU endpoint is enough
Often sufficient for less sensitive content.
- When the data is uncritical and a larger model clearly solves the task better.
- When you do not want to run your own compute.
- An endpoint in the EU at a provider based in the USA leaves the CLOUD Act question from above open. We assess that with you.
The drawback
Local models need their own compute, meaning servers with powerful graphics cards, bought or rented. And not every local model is equally good for every task.
How we decide
Per task, not across the board. We use the cheapest model that does the task reliably. That can be a small local model or an EU endpoint.
What this does not mean
- Hosting, maintenance and further development still cost money. The open-source components carry no licence fees. That does not automatically apply to our own code.
- “Almost exclusively” means: if a project has an exception, we name and justify it before the project starts.
- Your existing programs, such as accounting or CRM, stay as they are. We connect them where it makes sense and do not replace them.
- Usage rights, source code access and switching support are governed by the contract.
This website itself is not part of that: the booking dialog loads Cal.com, and with it Sentry, both from the USA, only after you confirm, and our email hosting is with Infomaniak in Switzerland. We name all providers in the privacy policy.
Frequently asked questions about sovereignty
Is everything at enaudo open source?
No. The systems we build for you are made almost exclusively of open source or custom code. The “almost” is meant seriously: if there is an exception, for example n8n, whose fair-code licence makes the source code visible but is not open source in the strict sense, we name it before the project starts. Your existing programs stay in place.
Is running on EU servers automatically GDPR compliant?
No. On EU servers, operation generally involves no transfer to third countries, provided nobody in a third country accesses the data. That is all they achieve on their own. Whether a system fits data protection law depends on the legal basis, contracts, access rights and deletion periods, among other things. We build with data minimisation and clarify this with you in advance, but we do not replace legal advice.
Do I need my own hardware for local AI models?
Not necessarily. Local models need powerful servers with graphics cards. They can sit with you or be rented from a provider in the EU, both cost money. Whether that pays off, we decide per task. An endpoint in the EU is often enough.
What does this mean for your project?
In an intro call we clarify which parts should be open or built in-house, where the servers sit and whether local models make sense for you.