AI Assistant Privacy and Security – GDPR, Data Ownership, and BYOK Explained
Data isolation, European hosting, and bring-your-own-key explained
Before you connect an AI assistant to your email, calendar, and task manager, there's a question worth asking: what happens to your data once it's inside the system?
Most AI tools answer this question vaguely. "Your data is secure." "We take privacy seriously." "Industry-standard encryption." These statements are hard to verify and easy to make. The specifics – where your data lives, who can access it, whether it's used for training, and what happens when you leave – matter more than the marketing language.
Here's how these questions are answered when the assistant runs in an isolated container with a bring-your-own-key model and European-hosted infrastructure.
Data isolation
Each user's assistant runs in its own isolated container. Your conversations, memory, files, and integrations are separated from every other user at the infrastructure level – not just at the application level. There's no shared database where one user's data sits next to another's. The containers are isolated by design: separate filesystems, separate processes, separate credentials.
This means a vulnerability in one user's workflow can't cascade to another user's data. It also means your assistant's persistent memory – the context it accumulates across months of conversations – is physically separated from everyone else's.
Your data and model training
Amplify does not use your data to train language models. Your conversations, emails, meeting notes, and files are used only to provide the assistant's services to you.
The language models themselves are separate services. When your assistant processes a conversation, it sends the relevant context to an LLM provider (like OpenRouter) for inference. The provider processes the request and returns the result. With the bring-your-own-API-key model, you choose which providers handle your data – and you can select providers whose data policies match your requirements.
This separation is important: your data flows through the assistant for your benefit, and the model providers process individual requests without accumulating your history. You're not contributing to a training dataset by using the assistant.
Infrastructure and data residency
The infrastructure runs on European-hosted servers – currently in the UK (London, DigitalOcean) and France (Lauterbourg, Contabo). The UK operates under UK GDPR, which mirrors EU GDPR in its core protections. France is within the EU.
This European hosting means your data doesn't cross to US data centers or other jurisdictions unless you explicitly configure a provider that operates there (for example, if you bring your own API key for a US-based LLM provider). The base infrastructure – where your assistant runs, where your memory is stored, where your integrations are managed – stays in Europe.
Data residency matters for professionals and teams subject to regulatory requirements. Knowing where your data physically lives and which legal frameworks govern it is a prerequisite for compliance, and vague "cloud-hosted" answers don't meet that bar.
Bring your own API key
The BYOK model means you can use your own API keys for the underlying services – LLM providers like OpenRouter, media generation providers like fal.ai, and others. When you bring your own key, the requests go through your account with the provider, subject to your own terms and billing.
This gives you three things: full cost visibility (you see exactly what each provider charges), provider choice (you pick the models and services that meet your requirements), and an independent audit trail (your provider account shows exactly what was processed and when).
If you don't want to manage your own keys, the assistant works with shared infrastructure keys – the same capabilities, just managed for you. BYOK is an option for users who want maximum control, not a requirement.
What "secure" means in practice
Beyond data isolation and hosting, the assistant's security model includes several layers:
Sandboxed execution – when the assistant runs tools (generating images, searching the web, processing documents), each operation runs in a sandboxed environment. The sandbox has its own filesystem and limited permissions. It can't access your credentials, your other integrations, or anything outside its designated workspace.
Credential isolation – API keys, OAuth tokens, and other credentials are stored separately from the assistant's runtime. The sandbox environment sees only the tokens it needs for the current operation, injected through a proxy layer that never exposes the raw credentials to the execution environment.
No elevated permissions – the assistant's runtime explicitly disables elevated access. Even if a skill or tool has a vulnerability, it can't escalate to host-level access or read other users' data.
These aren't features you interact with directly. They're infrastructure decisions that determine what happens when something goes wrong – and in security, the question is always "when," not "if."
Amplify builds personal AI assistants on OpenClaw, an open-source agent framework, with isolated containers, European hosting, and a bring-your-own-key model. If privacy and data ownership matter to your workflow, start at getamplify.team.
Frequently Asked Questions
The infrastructure runs on European-hosted servers, currently in the UK (London, DigitalOcean) and France (Lauterbourg, Contabo). The UK operates under UK GDPR, which mirrors EU GDPR; France is inside the EU. Your data does not cross to US data centers unless you explicitly configure a provider that operates there, for example by bringing your own API key for a US-based LLM provider.
No. Your conversations, emails, meeting notes, and files are used only to provide the assistant's services to you. When a request needs a language model, the relevant context is sent to the LLM provider for inference and the provider returns a result – your history is not accumulated into a training dataset by using the assistant.
Each user's assistant runs in its own isolated container. Conversations, memory, files, and integrations are separated at the infrastructure level – not just at the application level. There's no shared database where one user's data sits next to another's, and a vulnerability in one workflow cannot cascade into another user's data.
BYOK means you can use your own API keys for the underlying LLM and media providers. When you bring your own key, requests go through your provider account, which gives you three things: full cost visibility, free choice of provider and model, and an independent audit trail in your provider's dashboard. BYOK is optional – the assistant also works with shared infrastructure keys for users who don't want to manage their own.
Three layers: sandboxed execution per tool run, credential isolation through a proxy that injects only the token a given operation needs, and an explicit no-elevated-permissions policy in the assistant's runtime. Even if a skill has a vulnerability, it cannot escalate to host-level access, read other users' data, or pull raw credentials out of the sandbox.
