EU · GDPR · AI Act · NIS2 · DORA

GDPR and EU AI Act: self-hosted AI that keeps personal data in the EU

Most AI stacks send personal data to at least three outside services: an embeddings API, a hosted vector database and an LLM API. Each one is a processor, a contract and often a transfer to a third country.

SynapCores puts SQL, vector search, graph, in-database ML and local LLM inference in one engine that you run in your own EU data centre or EU sovereign cloud. The data path stays where your data already is.

Book an EU sovereignty briefing Self-host the free Community Edition

Not legal advice. This page describes technical controls; your DPO and counsel decide how they apply to your processing.

Short answer

The simplest way to use AI under GDPR is to avoid creating new transfers. Run the model and the retrieval layer inside the EU environment you already control. With SynapCores, EMBED(), vector search and agent reasoning execute on a local model (an in-process GGUF model or your own Ollama), so prompts, documents and embeddings never reach a third-country provider. Your DPIA then covers one self-hosted system instead of a chain of AI vendors.

No third-country transfer by design

Embeddings, retrieval and generation run on your hardware. No US AI API is required anywhere in the data path.

One processor instead of five

Database, vector store, graph, ML and inference are one self-hosted system, so there is one Art. 28 question, not five.

Logs that hold up

Every agent run is written to a hash-chained ledger. Edits are detectable with a single query, which supports AI Act record-keeping.

Runs where you need it

EU data centre, EU sovereign cloud, private cloud or fully air-gapped. Native Linux and macOS binaries plus a Docker image.

GDPR: where AI stacks create transfers, and how to remove them

GDPR does not ban cloud AI, but every external AI service you add brings obligations: a processing agreement under Art. 28, security measures under Art. 32, data protection by design under Art. 25, a DPIA under Art. 35 when processing is high-risk, and a transfer mechanism under Chapter V (Art. 44–49) whenever data reaches a provider outside the EEA.

In a typical retrieval-augmented generation (RAG) setup, personal data leaves your environment three times: documents go to an embeddings API, vectors go to a hosted vector database, and prompts with retrieved context go to an LLM API. Each hop needs its own legal basis, contract and transfer assessment.

A self-hosted AI database removes those hops instead of papering over them. Here is how each GDPR question changes when the whole pipeline runs inside SynapCores:

GDPR question	Typical cloud AI stack	SynapCores, self-hosted in the EU
Chapter V transfers	Embeddings, vector store and LLM often hosted or supported from the US	Inference and retrieval run on your EU infrastructure; no transfer is created for AI processing
Art. 28 processors	One contract per AI vendor, plus their sub-processors	One self-hosted system that you operate; no AI sub-processor chain
Art. 25 by design	Data minimisation depends on what each vendor retains	Prompts, embeddings and outputs stay in tables you control and can delete
Art. 32 security	Spread across several vendor environments	One engine, one network boundary; Enterprise adds SSO, row- and column-level policies and encryption at rest
Art. 17 erasure	Copies may sit in vendor logs and vector indexes	A `DELETE` removes the row and its embedding from the same database
Art. 35 DPIA	Must assess every vendor and transfer	Scope is one system you host

Schrems II and the CLOUD Act: why "EU region" is not the whole answer

In Schrems II (C-311/18, 2020) the Court of Justice struck down the EU-US Privacy Shield because US surveillance law could reach transferred data. The EU-US Data Privacy Framework (2023) now provides an adequacy basis for certified US companies, and it remains under legal challenge. Many European organisations prefer an architecture that keeps working whatever happens to it.

The US CLOUD Act (2018) lets US authorities require US-based providers to hand over data in their possession or control, including data stored in EU regions. An AI service operated by a US company in Frankfurt is still operated by a US company.

Self-hosting answers both points with architecture instead of contracts. When the model, the vector index and the data run on infrastructure you or an EU provider control, no US AI provider holds your data, so there is nothing for a foreign order to reach through that provider.

EU AI Act: record-keeping, data governance and human oversight

The AI Act (Regulation (EU) 2024/1689) applies in stages. Prohibited practices apply since February 2025, obligations for general-purpose AI model providers since August 2025, and the Commission has been able to enforce them since August 2026. Obligations for high-risk systems phase in after that.

Most enterprises are deployers, not model providers. For high-risk use cases the Act expects deployers to keep automatically generated logs (Art. 26), and providers to build in record-keeping (Art. 12), data governance (Art. 10) and human oversight (Art. 14). These are much easier to show when the system that runs the AI also keeps the records.

Record-keeping (Art. 12, 19, 26)

Each AGENT_RUN is chained into an audit ledger: entry_hash = sha256(prev_hash ‖ fields). If a stored run is edited, its verified column turns false. Included in Community Edition.

Data governance (Art. 10)

Training data for in-database ML (AUTOML.TRAIN) and retrieval sources are ordinary tables with SQL lineage. You can see which rows a model or an answer used.

Human oversight (Art. 14)

Agents run where reviewers already have SQL access. Outputs land in tables that can be queried, approved or rejected before anything acts on them.

Open, swappable models

Use the open-weight GGUF model you choose, or a local Ollama. You decide which model is in scope and when it changes.

NIS2 and DORA: fewer third parties, smaller attack surface

NIS2 (Directive (EU) 2022/2555) requires essential and important entities to manage supply-chain security risk. Member states are transposing it into national law; Germany's implementation act (NIS2UmsuCG) took effect in December 2025. DORA (Regulation (EU) 2022/2554), in force for financial entities since January 2025, asks for a register of ICT third-party arrangements, concentration-risk analysis and tested exit strategies.

Every hosted AI service is another ICT third party to register, assess and plan an exit from. A single self-hosted engine replaces several of them. Exit is simple because the engine and its data are already on your infrastructure, in standard SQL tables. COPY ... TO LAKE writes any query result as open Parquet files to your own object store.

One dependency instead of a chain: database, vector search, graph, ML and inference are one binary or container.
No mandatory outbound connection: run fully air-gapped. Anonymous install telemetry is opt-out and never contains SQL, schemas, prompts or data; turn it off with one setting.
Your patch cadence: upgrades are a binary or image swap that you schedule, not a vendor-side change.

Reference setup: an EU-only RAG pipeline in one engine

This is the complete AI configuration for a deployment where nothing leaves the host. The default provider runs a quantised GGUF model in-process through llama.cpp. If you already run Ollama, point SynapCores at it instead. The engine also speaks the Ollama API, so ollama-python, LangChain Ollama and LlamaIndex clients can connect to SynapCores directly.

gateway.toml: local inference, telemetry off

# /etc/synapcores/gateway.toml
# Option 1: in-process GGUF model via llama.cpp (default, fully offline)
[query.ai_service]
provider        = "native"
model           = "llama-3.2-1b-instruct-q4_k_m"
embedding_model = "minilm"

# Option 2: a local Ollama on the same host or network
# [query.ai_service]
# provider = "ollama"
# base_url = "http://localhost:11434"
# model    = "llama3.2"

# Anonymous install telemetry is opt-out; switch it off for air-gapped sites
[telemetry]
enabled = false

Embeddings and semantic search without an external API

Once the model is local, AI becomes a SQL function. Documents, embeddings and the search over them sit in the same database, under the same backups, access rules and erasure process as the rest of your personal data.

-- Embeddings are computed by the local model, inside the database
CREATE TABLE policies (
  id        INT PRIMARY KEY,
  clause    TEXT,
  embedding VECTOR(384)
);

INSERT INTO policies (id, clause, embedding)
VALUES (1, 'Personal data is processed only within the EU.',
        EMBED('Personal data is processed only within the EU.'));

-- Semantic search: no external embeddings API, no export to a vector SaaS
SELECT id, clause,
       COSINE_SIMILARITY(embedding, EMBED('cross-border transfer')) AS score
FROM policies
ORDER BY score DESC
LIMIT 5;

Checklist for your DPO and security review

List every place personal data goes in the current AI design: embeddings, vector store, LLM, logging, evaluation tools.
For each hop, record the provider, its country of incorporation and the Chapter V mechanism in use.
Move inference and retrieval into the EU environment you control, and check that the remaining hops can be removed.
Turn off telemetry for regulated or air-gapped sites ([telemetry] enabled = false) and document it.
Keep agent and model activity in the hash-chained ledger, and set retention to match your AI Act and sector obligations.
Run the DPIA on the resulting design: one self-hosted system, one network boundary.

GDPR and EU AI Act: frequently asked questions

Is a self-hosted LLM automatically GDPR compliant?

No architecture is compliant by itself; compliance depends on your lawful basis, purposes, retention and security. Self-hosting removes the hardest parts for AI: there is no transfer to a third-country AI provider and no chain of AI sub-processors, so the remaining questions are the ones you already answer for your own databases.

Does SynapCores send any data outside our infrastructure?

Not for AI processing. Inference runs on a local model, and hosted providers are an option you have to configure yourself. The only outbound traffic by default is an anonymous install heartbeat (installation ID, version, OS). It never includes SQL, schemas, prompts, embeddings or rows, and you can switch it off with [telemetry] enabled = false or DO_NOT_TRACK=1.

Can we run SynapCores in an EU sovereign cloud?

Yes. SynapCores is a native Linux binary and a Docker image, so it runs on any EU provider's VMs or Kubernetes as well as on-premises. Your provider's certifications (for example BSI C5 or SecNumCloud) then cover the whole AI stack, because the AI stack runs on that infrastructure.

How does this help with the EU AI Act?

The AI Act asks high-risk systems for logging, data governance and human oversight. SynapCores records every agent run in a tamper-evident, hash-chained ledger, keeps training and retrieval data in SQL tables with lineage, and lets reviewers inspect outputs where they already work. These are technical controls that support your conformity work; they do not replace it.

Which models can we use?

Any GGUF model you choose for the in-process provider (for example a quantised Llama 3.2), any model in your own Ollama, and a local embedding model for EMBED(). Open-weight models from European developers work the same way.

What does the Enterprise edition add for regulated EU deployments?

SSO (SAML/OIDC), LDAP/AD, row- and column-level access policies, KMS-backed encryption at rest, audit retention beyond 30 days with SIEM export, clustering with failover, point-in-time recovery and immutable tables verified with VERIFY TABLE.