Is a self-hosted LLM automatically GDPR compliant?

No. Self-hosting means prompts are not sent to a third-party model provider, but you remain the controller and still need a legal basis, transparency, security, retention rules and a way to handle data subject requests.

Are embeddings personal data under GDPR?

They should be treated as personal data when they are derived from text about identifiable people and stored next to that text or an ID that links back to it. In a typical RAG setup that is the case.

How do you delete personal data from a vector database?

Store the source document ID and, where relevant, a data subject ID as metadata on every chunk, then delete by that metadata filter. Also remove the source file, caches, logs and backups on their normal rotation, and re-ingest if the document stays but the person must be removed.

Do I need a DPIA for an AI chatbot?

Often yes, when the chatbot processes personal data at scale, handles sensitive categories, profiles people or makes decisions about them. Many supervisory authorities list innovative technology such as AI as a factor that points toward a DPIA, so document your assessment either way.

Does the EU AI Act require chatbots to disclose they are AI?

Yes. Under the AI Act transparency rules that apply from 2 August 2026, people must be informed that they are interacting with an AI system unless that is obvious from the context.

Self-Hosting LLMs for GDPR: A Practical Checklist

Updated 2026-10-26 · 11 min read

Running the model on your own servers removes one big data flow, but you are still the controller for every prompt, log and embedding. This checklist covers the rest.

Not legal advice. This is an engineering checklist written by people who build AI infrastructure, not lawyers. Use it to prepare for a conversation with your data protection officer or counsel, not to replace it.

Self-hosting an LLM helps with GDPR because prompts, documents and answers stay in infrastructure you control, so you avoid sending personal data to an external model provider. It does not make the system compliant by itself. You are still the controller, and everything the system stores (chat logs, prompts, uploaded files, embeddings in a vector database, traces) is personal data whenever it relates to identifiable people. A GDPR compliant AI chatbot needs the same basics as any other system that processes personal data: a legal basis, transparency, minimization, retention limits, security and a working process for access and erasure requests.

The rest of this guide splits that into what self-hosting solves, what it leaves open, and a checklist you can work through.

What self-hosting solves and what it does not

| Concern | Solved by self-hosting? | Notes | |---|---|---| | Prompts sent to a third-party model provider | Yes | No external inference API, no provider-side logging or training on your data | | International transfers to the model vendor | Yes, for inference | Your hosting provider may still be a processor outside the EEA | | Knowing where data is stored | Mostly | Only if you also control logs, backups, monitoring and analytics | | Being the controller | No | You decide purposes and means, so the obligations are yours | | Legal basis and transparency to users | No | Same as any other processing | | Retention of chats, logs and embeddings | No | Self-hosted stacks often keep everything forever by default | | Right of access and erasure | No | Harder, because data is spread across several stores | | Security of the system | No | Now it is entirely your responsibility | | Hosting provider as sub-processor | No | You need a processing agreement with them | | EU AI Act transparency duties | No | Apply regardless of where the model runs |

The honest summary: self-hosting removes the single biggest data flow most legal teams worry about, the model vendor, and moves the rest of the work onto your own engineering team.

Map the data before you write anything

Most GDPR work on an LLM system is knowing where personal data ends up. In a typical self-hosted chatbot or RAG pipeline, list each of these and who can access it:

Chat history in the application database (Open WebUI, a custom app, Flowise).
Uploaded and ingested documents in object storage or a file volume.
Chunks and embeddings in the vector database, usually with the original text stored as payload next to the vector.
Request logs from the reverse proxy, the API gateway and the inference server. Some servers can log full prompts; check the settings.
Traces and evaluation data in observability tools, which often contain complete prompts and answers.
Caches, such as semantic caches or prompt caches stored outside GPU memory.
Backups and snapshots of all of the above.
Fine-tuning datasets and adapters, if you train on your own data.

Embeddings deserve a specific note. It is tempting to think of vectors as anonymous numbers, but in practice they sit next to the source text and a document ID, and research has shown that text can be partially reconstructed from some embedding models. Treat the vector store as containing the same personal data as the documents it was built from.

The checklist

Work through it once per system, and again when you add a new data source or feature.

Governance and documentation

[ ] Controller and roles defined. Who is the controller, who are the processors (hosting, managed Kubernetes, backup provider, monitoring SaaS), and is anyone a joint controller.
[ ] Purpose written down. For example "answer employee questions about internal HR policies". Purpose drives every later decision, including what you may ingest.
[ ] Legal basis chosen per purpose. Contract, legitimate interest (with a documented balancing test), consent or a legal obligation. Internal assistants for employees need extra care because consent is rarely freely given in an employment relationship.
[ ] Records of processing updated. Add the system to your records of processing activities (Article 30 GDPR): categories of data and data subjects, recipients, retention, security measures.
[ ] DPIA assessed. Decide whether a data protection impact assessment (Article 35) is required and record the reasoning. It is likely when you process data at scale, handle special categories (health, union membership and similar), monitor people or let the system influence decisions about them. If in doubt, do one; it is also the best place to record the risks below.
[ ] Privacy notice updated. Tell users what the assistant does with their input, how long chats are kept, whether humans review them and how to exercise their rights.

Data minimization and ingestion

[ ] Only ingest what the purpose needs. A support bot does not need the full CRM export. Filter at ingestion, not at query time.
[ ] Strip or pseudonymize where possible. Remove contact details, IDs and free-text fields that are not needed for retrieval. Tools such as Microsoft Presidio can detect common identifiers, but expect misses and test on your own data.
[ ] No special categories by accident. Scan sources for health, HR or disciplinary data before ingestion and exclude them unless you have a specific basis.
[ ] Avoid fine-tuning on personal data. Data baked into model weights cannot be selectively deleted. Keep personal data in retrieval, where you can delete it, and fine-tune only on data you could publish internally without concern.

Access control

[ ] Authentication in front of everything. The chat UI, the inference API and the vector database. Inference servers such as Ollama and vLLM have no user management of their own; put them behind an authenticating proxy or keep them on a private network.
[ ] Document-level permissions in retrieval. If a user cannot open a document in the source system, the assistant must not retrieve it for them. Store access groups as metadata on each chunk and filter on them in every query. This is the most common real leak in internal RAG systems.
[ ] Least-privilege admin access. Few people should be able to read other users' chat histories or raw traces, and that access should be logged.
[ ] Network isolation. Vector database and model server not exposed to the internet. Egress from the stack restricted so a compromised component cannot send data out.

Retention and deletion

[ ] Retention period per store. Chats, logs, traces, uploads and embeddings each get a defined period that matches the purpose. "Forever" is not a period.
[ ] Automated deletion. A scheduled job that deletes expired chats and log entries. Many self-hosted chat UIs keep history indefinitely by default, so check the configuration.
[ ] Prompt logging off by default in inference servers and proxies, or scoped to short-lived debugging with a documented reason.
[ ] Backups age out. Deleted data disappears from backups when they rotate. Document that rotation period in your privacy notice and records.

Right of access and right to erasure

The right to erasure (Article 17) and the right of access are where self-hosted RAG systems most often fall short, because nobody planned for them at ingestion time.

[ ] Every chunk carries a source ID. Store sourceid (document or record) and, where it makes sense, a subjectid in the chunk metadata so you can find and delete everything derived from a document or about a person.
[ ] Deletion by metadata filter tested. Most vector databases support delete-by-filter (Qdrant, Weaviate, Milvus, Chroma, and plain SQL DELETE with pgvector). Run it in staging and confirm the chunks are gone from search results.
[ ] Re-ingestion path for partial removal. When a document must stay but one person's data must go, redact the source and re-index it. Deleting individual chunks may leave other chunks that mention the person.
[ ] Chat history searchable per user, so you can export or delete it on request.
[ ] Caches and derived stores included in the deletion process, not only the primary database.
[ ] Deadline tracked. Requests must be answered without undue delay and generally within one month, so the process needs an owner.

A deletion in pgvector, for example, is ordinary SQL once the metadata exists:

DELETE FROM chunks WHERE metadata->>'source_id' = 'hr-policy-2024-07';

If the data model has no such field, adding it later means re-ingesting everything. Plan it on day one. The vector database comparison covers how each engine handles metadata filtering.

Security

[ ] Encryption in transit between all components, including internal traffic between the app, vector database and model server when they run on separate hosts.
[ ] Encryption at rest for volumes holding documents, the vector database and backups.
[ ] Pinned and patched images. Pin container image versions so changes are deliberate, and track security releases for the inference server, vector database and UI. Security of processing (Article 32) is your job end to end now.
[ ] Prompt injection considered. If the assistant reads untrusted documents and has tools that can send data out, a hidden instruction can make it leak data. See the security sections of self-hosted AI agents with tool calling.
[ ] Breach process covers the AI stack. Personal data breaches generally have to be reported to the supervisory authority within 72 hours of becoming aware of them (Article 33). Make sure the stack's logs let you work out what was exposed.

Hosting and sub-processors

[ ] Processing agreement with the hosting provider (Article 28), whether it is a GPU cloud, a VPS provider or a managed Kubernetes service. The same applies to backup, monitoring and email services the stack uses.
[ ] Data location documented. Region of compute, storage and backups. A provider based outside the EEA can still raise transfer questions even when the servers are in the EU, so record which transfer mechanism applies.
[ ] Sub-processor list maintained and included in your own processing agreements if you serve customers.
[ ] No hidden external calls. Check that the UI, embedding service and model server do not call out to telemetry, analytics or hosted APIs by default. Some tools have opt-out telemetry; switch it off and block egress as a backstop.

Model license versus data protection

[ ] Keep the two questions separate. A model license (Apache 2.0, MIT, the Llama community license, Gemma terms and so on) governs whether you may use, modify and redistribute the weights. It says nothing about whether your processing of personal data is lawful. A permissive license is not a privacy assessment, and a restrictive one is not a privacy problem.
[ ] Check acceptable-use clauses. Some licenses restrict certain uses or user counts. That is a contract and IP question for counsel, separate from GDPR.
[ ] Training data provenance noted. Open-weight models may have been trained on scraped data that included personal data. The European Data Protection Board published an opinion on AI models and personal data in December 2024. For most deployers using a third-party model for inference, the practical step is to record which model you use and what the publisher documents about training data, and to avoid prompting for information about specific private individuals.

Users and transparency

[ ] Users know it is an AI. See the AI Act section below.
[ ] Users know what not to enter. A short notice in the UI asking people not to paste special category data or other people's details unless the purpose requires it.
[ ] No solely automated decisions with legal or similarly significant effects about people, unless you have assessed and covered the specific GDPR requirements for that. Keep a human in the loop for anything like hiring, credit or disciplinary decisions.

The EU AI Act at a high level

The AI Act is separate from GDPR and applies whether or not you self-host. Dates, as of October 2026:

The Act entered into force on 1 August 2024. Prohibited practices have applied since 2 February 2025, and obligations for general-purpose AI model providers since 2 August 2025.
The transparency obligations for certain AI systems apply from 2 August 2026. For a chatbot, the key one is that people must be informed they are interacting with an AI system unless that is obvious from the context. Providers of systems that generate synthetic text, images, audio or video must also mark the output as AI-generated in a machine-readable way.
Some deadlines, including those for high-risk systems and for marking the output of systems already on the market, were changed in 2026 by the "Digital Omnibus" amendment. Check the current consolidated text in EUR-Lex before planning around a specific date.

Most internal chatbots and RAG assistants are not high-risk systems. That changes if the system is used in areas the Act lists as high-risk, such as employment decisions, education, access to essential services or law enforcement. If your use case is close to one of those, involve counsel early. Check the current consolidated text before relying on any date here, since the timeline has been amended once already.

In practice, for a self-hosted chatbot:

[ ] A visible notice in the chat UI that answers are generated by AI.
[ ] A short note in the privacy notice or help page about which model family is used and its limits.
[ ] A decision recorded on whether your use case falls under any high-risk category.

How this maps onto a self-hosted stack

A concrete layout that makes most of the checklist easy:

Run the model server, embedding service and vector database on a private network with no inbound internet access. Only the chat UI or API sits behind an authenticating reverse proxy.
Store sourceid, subjectid where relevant and access groups on every chunk, and filter on access groups in every query.
Keep chats, logs and traces in stores with scheduled deletion, and switch off prompt logging in the inference server.
Pin image versions and keep a short runbook for erasure requests that lists every store.

The RAG pipeline stack and the LLM chatbot stack are good starting points; the walkthrough in self-hosting a RAG pipeline with Docker Compose shows where each component stores data.

Next steps

Draw the data map for your system and share it with your DPO before you ingest real data.
Add source and subject metadata to your ingestion pipeline now, while re-indexing is cheap.
Browse the stack catalog for deployable chatbot and RAG starting points.
Revisit this checklist when you add a new data source, a new tool or a new group of users.