Does private LLM chat avoid GDPR processor and transfer obligations?
Self-hosting removes an external processor and a third-country transfer from the chat flow, but it does not remove the controller's duties. If staff paste customer records, HR files or case notes into an assistant, the organization decides why and how that processing happens, so it stays the controller under Article 4(7) wherever the servers sit. Article 24 still requires the controller to implement measures that demonstrate compliance, Article 25 requires data protection by design and by default in the choices made for the assistant, and Article 32 requires security of processing for the prompts, uploads and chat history. Hosting the stack in your own cloud account or data center changes who must be contracted and who can access the data, not whether those obligations exist.
The practical gain is a shorter chain. When the models, the chat interface and the vector store all run in infrastructure the organization controls, there is no external provider storing prompts under Article 28 and no sub-processor list to track for that flow. The EDPB guidance on Chapter V also treats remote access from a third country, even just viewing data for support, as a transfer, so the reader should confirm that no vendor support session, telemetry export or update channel can expose chat content from outside the EEA. Check the Ollama configuration as well: the local API has no authentication by default, and cloud features can be disabled with OLLAMA_NO_CLOUD=1, so any request that leaves the host would reintroduce a processor.
For the DPO, the decision is to document the processing in the record of activities, confirm the data flows end to end, and decide which contracts still apply. Any managed component, such as a hosting partner, a backup provider or an implementation partner with access to logs, needs an Article 28 contract and an Article 28(3) clause set. Implementation partners that operate the platform are processors as well, so their access to chat history should be written into the contract and limited to what the engagement requires. The reader should also confirm with counsel how the Article 32 measures, breach notification under Articles 33 and 34, and retention limits for chat logs will be evidenced, because the GDPR requires no certificate and a self-hosted deployment is evidence of design, not proof of compliance.
Which GDPR requirements the chat platform must meet and how to configure them
This table maps the GDPR provisions that apply to a self-hosted staff chat assistant to the platform functions that meet them and the settings to check. Read each row as a requirement, the configuration that addresses it, and the evidence an assessor will ask for. The main takeaway is that self-hosting removes external processors and transfers from the chain, but the controller still owns access control, logging, retention and security of the chat history.
| Requirement | What to configure | Evidence to keep |
|---|---|---|
| Controller duties (Article 4(7), 24, 25): purposes, means and default settings stay with the organization | Document the assistant's purposes and which data may be pasted or uploaded. Set defaults so new users get the minimum features and file types, and confirm who approves changes to models or retention | Written purpose statement, data-use rules, change approvals for model and setting updates |
| Processor sufficient guarantees (Article 28(1)): any vendor, hoster or support party touching chats | Inventory every party with access to hosts, backups, logs or remote sessions. Confirm each has a contract and security measures, or remove it from the chain | Processor register with contracts, due diligence notes, support access records |
| Sub-processor control (Article 28(2)): changes to parties in the chain | Where a vendor is used, require notice of sub-processor changes and a right to object. Keep the list of parties current, including software supply chain sources for images and models | Dated sub-processor list, change notices, objection log |
| Processor contract terms (Article 28(3)): documented instructions, confidentiality, audits, deletion | Confirm that any service contract covers these terms. For an in-house or self-hosted stack, set the equivalent internal rules for staff access and data deletion at end of use | Signed contract clauses, staff confidentiality terms, deletion procedure |
| Access control (Article 32): limit who sees which chats and files | Connect Open WebUI to SSO through OIDC or LDAP, provision groups with SCIM 2.0, and apply role-based access control with per-resource permissions. Enable MFA for administrators | Group-to-role mapping, access review records, MFA enforcement settings |
| Model endpoint isolation (Article 32): no uncontrolled inference path | Set OLLAMA_HOST so Ollama listens only on an internal interface, not the default 127.0.0.1 binding unless a reverse proxy sits in front. Put vLLM behind authentication. Set OLLAMA_NO_CLOUD=1 so prompts do not go to cloud features | Configuration files, firewall rules, scan results showing the endpoint is unreachable from outside |
| Chat history and database security (Article 32): storage and retention | Use PostgreSQL instead of SQLite for multi-instance deployments. Encrypt volumes and backups, set retention periods for chats and uploaded files, and document deletion on user request | Retention schedule, backup encryption settings, deletion test results |
| Breach detection and notification (Article 33): time to report | Enable authentication and access logs for the chat platform, and route them to a monitored store. Document who decides on a breach and how the 72-hour clock is tracked | Incident runbook, log retention settings, tabletop exercise notes |
| Third-country transfers (Chapter V): no external service in the chain | A transfer arises if any party outside the EEA, or any remote administrator in a third country, can view or store data. Keep hosting, backups, support access and model downloads inside the EEA or document a valid transfer mechanism. Model weights and container images pulled from outside do not carry chat data, but confirm that no telemetry or update check sends prompts or files out | Not applicable |
| Transfer tools if a vendor is used (Chapter V): where a vendor is involved | Ask the vendor where data is stored and accessed from, and whether support staff in third countries can see it. Confirm the transfer mechanism and any supplementary measures with counsel before go-live | Not applicable |
Which open-source chat and model stacks fit a GDPR-scoped deployment
The chat interface, model runtime, gateway and observability layer each touch prompts, files or logs, so each one either adds a processor relationship or stays inside the controller's infrastructure. The cards below cover the components most often proposed for a staff assistant and the checks that decide whether each one keeps the deployment within the organization's own boundary.
Open WebUI as the chat interface
Open WebUI provides the ChatGPT-style front end and can connect to Ollama or any OpenAI-compatible endpoint. Its code moved to the Open WebUI License in v0.6.6, and clause 4 prohibits altering or removing branding in deployments above 50 users in any rolling 30-day period unless the operator holds an enterprise license or written permission. Check the branding terms before rollout, since the enterprise license is quoted on request and pricing is not published.
LibreChat under MIT
LibreChat is an MIT-licensed chat interface, so the license imposes no branding limit and no seat threshold. It is a useful alternative when the organization wants permissive terms on the front end. Confirm which identity, file storage and database components the chosen configuration uses, since each one stores personal data and must sit inside the controller's infrastructure or under an Article 28 contract.
Ollama with local-only defaults
Ollama is MIT-licensed and binds to 127.0.0.1 on port 11434 by default. Its local API does not require authentication, so anything that changes OLLAMA_HOST must sit behind an authenticating proxy and a network boundary. Set OLLAMA_NO_CLOUD=1 so that cloud features cannot send requests to ollama.com, and confirm this in the server configuration file rather than assuming it.
vLLM for shared GPU serving
vLLM is an Apache-2.0 inference and serving engine suited to a shared internal model service with higher concurrency than a single workstation runtime. Its license is permissive, but the GDPR question is where the GPUs run and who operates them. Confirm that the hosts, the administrators with access to model logs and any remote support sessions sit within the EEA or the controller's own environment, because remote viewing from a third country counts as a transfer.
LiteLLM as an optional gateway
LiteLLM can sit between the chat interface and model endpoints to route requests, record usage and apply guardrails in one place. It is MIT-licensed except its enterprise directory, so confirm which features the team needs fall inside the open-source scope. If the gateway logs prompts, those logs become personal data stored in the controller's infrastructure and must follow the same retention and access rules as the chat history.
Langfuse or Phoenix, self-hosted only
Langfuse and Arize Phoenix record traces, prompts and outputs, which makes them personal data stores when staff use the assistant. Langfuse is MIT except its ee directories. Phoenix is under the Elastic License 2.0, which prohibits offering the software to third parties as a hosted or managed service, so a managed Phoenix deployment run by an outside provider is not an option under that license. Keep either tool in the controller's own environment and confirm the license terms with counsel before any hosted variant is considered.
What security of processing still applies to chat history
Keeping prompts on a self-hosted model does not switch off Article 32. The controller must still ensure a level of security appropriate to the risk for every stored prompt, uploaded file, embedding and log, wherever they sit. In practice that means encryption at rest for the database, the file store and the vector index, encryption in transit between the browser, the Open WebUI or LibreChat interface, the model server and any retrieval store, and access control per group so that a user only reads the chats, knowledge collections and models their role allows. Pseudonymization is worth applying where feasible, for example by keeping user identifiers out of inference logs and by linking chats to identities only in the directory-backed user table. Ask the implementation partner to document which of these controls are configured by default in the chosen version and which must be set by hand.
Backup and deletion are where chat history usually fails an audit. Chat history is copied into backups, replicas and sometimes exported files, so the deletion of a user's conversations must reach every copy within a defined period. Write a retention and deletion rule before rollout that states how long chats, uploads and logs are kept, who can request erasure, and how backups are expired. Article 33 also applies to the logs. If the chat database, the file store or the log pipeline is breached, the controller has to assess whether personal data is affected and, where required, notify the supervisory authority within 72 hours of becoming aware. That only works if the logs can show who accessed what, so confirm early which access events the platform records and where they are shipped.
The multi-replica setup adds three systems to protect. Open WebUI's scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, and Redis for shared sessions, websocket connections and application state, plus shared file storage so uploads and knowledge stay reachable from every replica. Each one holds personal data or access tokens and each needs its own encryption, network restriction, credentials, backups and patch cadence. Redis in particular can hold session state that identifies logged-in users, so it should not be reachable outside the application network. Confirm with the partner which versions of PostgreSQL, Redis and the file store are supported and who owns their hardening, because every service that a processor or sub-processor operates is also part of the Article 28 chain.
What a DPO or auditor asks to see for the chat deployment
This table maps each item a data protection officer or auditor is likely to request to the component or record that produces it. Use it to prepare the evidence pack before a review, not after. The main point is that the GDPR requires no certificate, so the evidence is documentation and configuration the controller can show.
| Evidence item | What it shows | Component or owner that produces it |
|---|---|---|
| Record of processing activities | Purpose, categories of data, recipients, retention and security measures for the chat assistant | Controller's privacy team, using the data flow and configuration inventory |
| Data flow diagram | Where prompts, uploads, embeddings and chat history are created, stored and processed | Solution architect, covering the chat interface, model server and any vector store |
| Processor and sub-processor register | Every external party with access to personal data, or a statement that none exists | Controller's procurement and legal teams, verified against the deployed stack |
| Article 28 contracts | Documented instructions, confidentiality, security, audit rights and deletion for each processor | Legal team with any hosting, support or implementation provider, where applicable |
| Model server configuration export | Bind address on 127.0.0.1 or an internal interface, and OLLAMA_NO_CLOUD set to 1 | Platform engineering, from the Ollama or vLLM service files and environment |
| Network policy and firewall rules | Confirmation that the model endpoint is not reachable from outside the approved network | Infrastructure team, from firewall and reverse proxy configuration |
| RBAC and SSO settings | Which identity provider, groups and roles can access chats, files and admin functions | Open WebUI or LibreChat admin settings, with the identity provider's group mapping |
| Retention and deletion settings | How long chats and uploaded files persist and how users or admins delete them | Chat platform configuration, plus database and file storage settings |
| Backup and deletion logs | That backups are encrypted, access-limited and purged on the stated schedule | Backup platform logs and database or object storage job records |
| Incident response runbook | Steps and timelines for breach assessment and notification under Articles 33 and 34 | Security team, tested against the chat platform's logging and alerting |
What tooling alone does not satisfy under GDPR
Self-hosting removes an external processor from the chat path, but the organization stays the controller and still owns the legal and operational duties around staff use. The cards below cover the gaps that a well-configured model server cannot close on its own.
Lawful basis and purpose for chat use
Staff chats can contain personal data about customers, colleagues and applicants, so the controller must set a documented lawful basis and purpose for the assistant before rollout. Tooling does not decide whether summarizing a complaint file or drafting an HR letter is compatible with the original collection purpose. Check that the purposes are written down, that the records of processing list the assistant, and that use cases outside those purposes are blocked by policy. Ask counsel to confirm the basis for each user group.
Staff rules on what may be pasted
A self-hosted model keeps prompts on your infrastructure, but it does not stop an employee from pasting data the organization should never process in an assistant. Write an acceptable use standard that names data classes allowed, restricted and prohibited, with examples drawn from real workflows. Pair the standard with a short training module and a visible reminder in the interface. Confirm that the chat front end can display this notice at login and in the upload dialog.
DPIA where the risk warrants it
Where the assistant processes special category data, employee monitoring information or large volumes of customer records, a data protection impact assessment under Article 35 is likely to be needed. The assessment should cover the chat history, uploaded files, retrieval indexes, logs and any model memory. Tooling produces inputs for the assessment but not its conclusions. Ask your data protection officer whether a DPIA is required and document the answer either way.
Data subject rights for chat history
Access, rectification and erasure requests can reach chat transcripts, uploaded documents, embeddings in a vector store and audit logs, each held in a different place. Map every store that retains personal data and define how each record is found by user and exported or deleted. Test a full erasure on a staging copy, including backups and retrieval indexes. Confirm with your platform team that deleting a chat in the interface also removes the related vectors and files.
Plugins, model weights and hidden calls
Open-weight models and interface plugins can still make outbound requests, such as telemetry, model downloads, web search tools or update checks. Each external call either removes the no-transfer position or adds a processor, so inventory every outbound route from the chat host, its model server and its connectors. Ollama documents that cloud features can be turned off with OLLAMA_NO_CLOUD=1 or the server configuration file, but confirm the setting on your version and test it with network egress logging.
Documented decisions on updates and sub-processors
Model updates, interface upgrades and new connectors can change what data is processed and where it flows, so each change needs a recorded decision. Keep a register that lists every component, its version and any party that supports it, and require a written approval step before a model swap. Article 28(2) requires a processor to inform the controller of intended changes under general authorization. Confirm the register is reviewed on each release cycle, since the interface and model server ship often.
Questions buyers ask before hiring a partner for GDPR-scoped private chat
Does self-hosting remove the need for a data processing agreement?
No. Self-hosting does not change who is the controller. The organization still determines purposes and means, and it remains responsible for the Article 24 measures, Article 25 design and default settings and Article 32 security wherever the processing runs. A data processing agreement under Article 28(3) is needed only when an external party processes personal data on your behalf, such as a partner that installs, operates or supports the platform and can access it. If that party is removed from the chain, the contract and its sub-processors are removed with it, but the controller's own obligations stay. Confirm with your counsel which parties would have access to prompts, files and logs during installation, support and backup, and document each one.
What fines apply under Article 83 for security failures?
Article 83 sets maximum administrative fines of EUR 10 million or 2% of total worldwide annual turnover for infringements such as Articles 25 to 39, whichever is higher. Security of processing under Article 32 falls within that band. Infringements of the principles, lawful basis, data subject rights and transfer rules carry a higher maximum of EUR 20 million or 4% of worldwide annual turnover, whichever is higher. The amount actually imposed depends on the circumstances of each case, and fines are set by independent national supervisory authorities under Article 51. Regulators also weigh the measures you took, so the evidence of what was configured and tested matters as much as the platform choice.
How long does a GDPR-scoped private chat deployment take?
The timeline depends on scope, which is set in a written, fixed-scope agreement before work starts. The main drivers are the number of identity and data sources to connect, whether a data protection impact assessment and records of processing need updating, how many models and GPUs must be sized and procured, and how quickly your legal and security teams can approve the processor and sub-processor list. Ask any partner for a phased plan with named milestones, and confirm which of your teams must supply access, approvals and sign-off at each step. Timelines and durations should appear only in the signed scope, not in a sales conversation.
Can our own team run the platform after the engagement?
Often yes, but only if the skills and the runbooks are transferred deliberately. Operating Open WebUI or LibreChat with Ollama or vLLM requires people who can manage containers or Kubernetes, PostgreSQL, Redis and shared file storage for multiple replicas, GPU drivers, identity integration and upgrades. Open WebUI's scaling guide requires PostgreSQL rather than SQLite for multi-instance deployments, and Ollama's default concurrency is one parallel request per model, so capacity planning is a skill in itself. Ask the partner for documented handover, a list of components that need patching, and a clear statement of which operational tasks you would keep in-house and which you would retain as support.
What drives the cost of a fixed-scope quote?
Most cost sits in four components: the partner's fees for planning, installation, integration and hardening, the hardware or cloud GPUs that serve the models, the software licenses that apply, and the internal time for approvals and testing. Recurring costs include hardware, power or cloud usage, patching, upgrades and support. The main cost drivers are the number of users and peak concurrency, the number of SSO and data sources to integrate, the amount of documentation required for the assessment, and the level of testing. When requesting a quote, ask for a line-by-line breakdown of one-time and recurring costs, the assumptions behind concurrency and GPU sizing, the exclusions, the change-request process and the acceptance criteria. DeployOpen does not publish a price list; a quote follows from the written scope.
Does the Open WebUI license restrict use above 50 users?
Yes, the branding clause can apply. Since v0.6.6 (April 19, 2025), Open WebUI code is distributed under the Open WebUI License, which forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. Code through v0.6.5 remains BSD-3-Clause. Open WebUI's enterprise licenses allow white-labeling and custom branding, and pricing is quoted after contacting its sales team with an expected seat count. Confirm the exact clause and your user count with counsel before rollout, and ask the partner to show where the branding appears in your configuration.
Which parts of the chat history still need security of processing controls?
Even with no third-country transfer, the chat history is personal data and Article 32 applies. The main controls are access control through SSO groups and role-based permissions, encryption in transit and at rest, backups with restore testing, retention limits that you set and document, logging of administrative and access events, and tested incident response that supports the 72-hour notification window in Article 33. Confirm where the database, uploads, vector store and logs reside, who can read them, and how they are deleted when a user leaves or a data subject asks for erasure.
What to confirm with your DPO and with the vendor
Do not assume that a self-hosted assistant is free of outbound data flows. Ask your engineering team and the implementation partner to confirm in writing that no telemetry or cloud feature is enabled. Ollama states that cloud features can be turned off with OLLAMA_NO_CLOUD=1 or the server configuration file, and that a local instance does not see your prompts, but the setting must be verified on each host and in each container, not inferred from the vendor's description. Check the same for Open WebUI, LibreChat and any gateway or observability component in the chain, and record the result as evidence for your DPO. Also confirm where model weights and container images came from, and whether the organization accepts those sources, because a copy pulled from an unapproved registry becomes a supply chain question of its own.
Next, confirm whether any support access crosses a border. The EDPB Guidelines 05/2021 treat remote access from a third country, even just viewing data for support or administration, as a transfer. A vendor engineer who troubleshoots a chat node from outside the EEA can therefore create a transfer that no hosting location change would remove. Ask the partner to name every person and organization that can reach the production environment, where each is located, and how access is granted, logged and time-limited. Ask the DPO to decide whether that support model is acceptable, and whether an Article 28 contract covers any vendor that touches the system. Also confirm the Open WebUI license terms for your expected user count: the license restricts altering or removing branding above 50 end users in any rolling 30-day period unless an exception applies, so the number must come from your own rollout plan, not from the pilot.
Finally, confirm whether the assistant is high-risk under the EU AI Act. If it is, Article 12(1) requires the system to technically allow for the automatic recording of events (logs) over its lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Whether a staff chat assistant falls into a high-risk category depends on its intended use, so the DPO and legal counsel should classify the use case before the log schema, retention period and export path are designed. Write the answers into a short decision record that lists the owner of each item, the date it was checked and the evidence attached. That record is what an auditor or supervisory authority will ask to see, and DeployOpen prepares such evidence without issuing any attestation of its own.
How a GDPR-scoped chat rollout is sequenced
The sequence turns a self-hosted chat assistant into a documented processing activity with a defined trust boundary, so the controller can show that prompts and files never reach an unapproved processor or third country. Each phase produces an artifact that the next phase depends on.
Scope the processing and open the record
The controller, usually the privacy lead with IT and the business owner, defines what the assistant is for, which staff use it, and which categories of personal data may appear in prompts, uploads and chat history. The output is an entry in the record of processing activities that names the purpose, the data subjects, the recipients and the retention intent. Confirm internally who is controller for each business unit, because self-hosting does not change that role under Article 4(7). The step is done when the purpose and data categories are signed off by the controller.
Classify data and set pasting rules
Information security and the business owners agree which data classes may be typed into the assistant, which may be uploaded, and which are excluded, such as special category data or client secrets. The output is a short written rule set that staff can read, plus the classification labels the platform will enforce or reference. Ask the team to test the rules against real workflows so the exclusions are practical rather than theoretical. The step is done when the rules are approved and mapped to the user groups that will receive them.
Decide the architecture and trust boundary
Architects document where the interface, model runtime, vector store, database, file storage and logs will run, and which of those components any external party can reach. The key decisions are whether every component sits in the organization's own cloud account or data center, whether any remote administration or support access is permitted from outside the EEA, and whether the model weights and inference endpoints are reachable only internally. The output is a data flow diagram with each processor and sub-processor listed. The step is done when the diagram shows no unplanned transfer path.
Harden and configure the platform
Engineers configure SSO and group-based access, disable features that send data out, bind model runtimes to internal addresses and place an authenticated proxy in front of them, and set the database and file storage to the approved location. They also set retention for chat history and uploads and confirm that Article 32 controls such as encryption, access logging and backup restore are in place. The output is a configuration baseline with each setting recorded. The step is done when a test of the deployed configuration matches the baseline.
Confirm processor contracts and collect evidence
Where any external party still touches the data, such as a hosting provider, a support firm or a software vendor with remote access, the controller checks that an Article 28 contract exists with the required terms and that the processor list is kept current. The team gathers the evidence set: the processing record entry, the data flow diagram, the configuration baseline, access review results and test outputs. Note that DeployOpen prepares this evidence but does not issue an audit report or certification. The step is done when the evidence pack is complete and the controller has reviewed it.
Run a pilot with a limited user group
A small, named group of users works with the assistant under the approved rules. The team monitors access logs, reviews sampled prompts for policy breaches in line with the agreed privacy controls, and records any incident that needs assessment against the breach notification steps in Articles 33 and 34. Feedback goes to the owners of the pasting rules and the configuration baseline. The step is done when the pilot findings are logged, resolved or accepted, and the controller confirms the rules still hold in practice.
Widen the rollout in controlled waves
Access expands in waves by group, with each wave starting only after the previous one's access reviews and incident log are clean. Capacity, model concurrency and database load are checked before each expansion, and any change to the processor list triggers an update to the record of processing and the Article 28 terms. The output is a rollout log tying each wave to its approvals. The step is done when all intended user groups are live and the record of processing matches the running system.
How DeployOpen scopes and delivers a GDPR-ready private chat
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a GDPR-ready private chat, we deliver the chat interface, model serving, identity integration and the security and records evidence that a controller needs, while the compliance assessment itself stays with the organization and its auditors.
How we scope
- We map which personal data staff would paste or upload, and which processors and sub-processors would touch it.
- We agree the written scope in advance, covering deliverables, timelines and the systems in and out of scope.
- We confirm with you where the chat history, file uploads and vector stores will physically reside.
How we build
- We deploy Open WebUI or LibreChat with models served by Ollama or vLLM inside your cloud accounts, data centers or air-gapped network.
- We connect SSO, groups and role-based access, and test that disabling cloud features keeps prompts off external endpoints.
- We configure retention, backup and encryption settings for chat history and files, then test restore and access controls.
How we hand over
- We document the processing flow, data locations, sub-processor inventory and the Article 32 measures implemented.
- We deliver configuration records and logging evidence that your DPO and auditors can review against your own controls.
- We train administrators on the runbook for upgrades, access reviews and handling of data subject requests.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
- We track upstream releases, test updates in a staging copy and roll them out under the agreed change process.
- We re-verify configuration when the model, interface or hosting location changes, and reflect those changes in the documentation.
