This is not legal advice. It is operator-level guidance from people who have shipped GDPR-compliant self-hosted AI deployments in 2026. Treat it as a starting point. For specific situations involving high-risk processing, consult a real lawyer.
Section 1: Why self-hosted helps with GDPR (and where it doesn't)
GDPR is, in practice, a question of "who controls the data, where does it go, and who else touches it." Self-hosted AI gives you stronger answers to those questions than managed AI does: typically:
- You control the data because it lives on your hardware.
- The data goes only where your config tells it to.
- The set of "who else touches it" is short: your VPS provider, your LLM provider (if you use cloud LLMs), your TLS certificate authority, and whichever monitoring tool you've wired in.
That makes GDPR compliance more tractable than "it's all on AWS via twelve sub-processors and we'll send you a DPA when we get around to it." It does not make GDPR compliance automatic.
The two places self-hosted setups commonly trip:
- The LLM provider when you call Anthropic, OpenAI or Google. They are processors. You need a DPA with them. They have one ready.
- The credential storage when you don't lock it down. Plaintext credentials on a shared host are a personal data leak waiting to be classified as a breach.
Section 2: Lawful basis
For most self-hosted AI operations, the relevant lawful bases are:
- Consent: when the agent processes data the user has explicitly opted in to (newsletter, account creation).
- Contract: when processing is necessary to deliver a service the user signed up for.
- Legitimate interest: when processing is for a legitimate purpose (security monitoring, abuse prevention) and the user's rights don't override it. Requires a documented Legitimate Interest Assessment (LIA).
Concretely:
- Newsletter subscriber data → consent (the user opted in).
- Pro-tier customer email and Stripe ID → contract.
- Server-side rate limiting based on IP → legitimate interest.
- Sending agent prompts to Anthropic for processing → either contract (if the user signed up for an agent service) or legitimate interest (if internal tool).
Document the lawful basis for each processing operation. Most teams have a one-page Record of Processing Activities (RoPA). Build yours.
Section 3: Data minimisation in agent contexts
GDPR requires you to collect only what you need. Agent runtimes are prone to over-collecting because:
- They log full prompts by default, which can include personal data.
- They keep conversation history indefinitely by default.
- They record tool execution arguments, which may include personal data passed in.
- They cache LLM responses, which may include personal data.
What to do:
- Check what gets written to disk: prompts included. Hermes Agent documents no
LOG_PROMPTSsetting: its full message history lives instate.dbby design, its logs redact secrets, andHERMES_DUMP_REQUESTSwrites API request payloads to the log files, so leave it unset in production (environment variables). OpenClaw redacts logs when they leave the machine (tailing, exports) but not its raw log files (logging). Until October 2026 this line named aLOG_PROMPTS=falsedefault in both; neither documents one. - Set conversation retention to the shortest interval that meets your operational need. 30 days is a defensible default for most agentic use cases.
- Hash tool call arguments in audit logs rather than logging them verbatim. The hash is enough for forensic correlation; the content isn't needed.
- Don't cache LLM responses unless you have a specific reason to, and if you do, treat the cache like the conversation memory.
Section 4: Where each agent stores what
A practical inventory of where personal data ends up in a default install, read from each project's documentation on 18 October 2026:
| Storage | Hermes Agent | OpenClaw 2026.4+ | ZeroClaw | Nanobot |
|---|---|---|---|---|
| Conversation history | SQLite, ~/.hermes/state.db (full message history, full-text search) | SQLite, ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite; archived transcripts in ~/.openclaw/agents/<agentId>/sessions/ | SQLite, ~/.zeroclaw/data/sessions/sessions.db | JSONL files in ~/.nanobot/sessions/<workspace-id>/ |
| Long-term memory | ~/.hermes/memories/MEMORY.md and USER.md | MEMORY.md in the workspace (~/.openclaw/workspace) | SQLite (brain.db) in ~/.zeroclaw/data/memory/ and in each agent's workspace | ~/.nanobot/workspace/memory/MEMORY.md and the append-only history.jsonl |
| Credentials | API keys in ~/.hermes/.env (its docs: chmod 600), OAuth tokens in auth.json, website logins encrypted in ~/.hermes/vault/ | Plaintext in openclaw.json or .env unless you move them to SecretRefs; channel state in ~/.openclaw/credentials/ | Secret fields of ~/.zeroclaw/config.toml, encrypted with ~/.zeroclaw/.secret_key | Plaintext in ~/.nanobot/config.json unless you use ${VAR} references (its docs: chmod 600) |
| Logs and audit | ~/.hermes/logs/ (errors.log, gateway.log), secrets redacted | /tmp/openclaw/openclaw-YYYY-MM-DD.log, rotated at 100 MB with five archives; the raw files are not redacted | An audit log, on by default, that covers certificate issuance only: commands are not audited | ~/.nanobot/logs/nanobot.log; its security policy lists the missing audit trail as a known limit |
Until October 2026 this table listed memory.db, vault.enc and
audit.jsonl files for Hermes Agent, OpenClaw and ZeroClaw, and an
in-memory history lost on restart for Nanobot. None of those appears in
their documentation: the history sits in the SQLite and JSONL files
above, and Nanobot writes its sessions to disk.
Retention defaults matter too. Hermes Agent keeps ended sessions until
you delete them: automatic pruning (sessions.auto_prune) is off by
default and, once on, removes ended sessions older than
sessions.retention_days, 90 days unless you change it;
hermes sessions prune does the same by hand.
For each location, ensure: encrypted at rest, regular backup with the backup also encrypted, and retention policy documented.
Sources, read on 18 October 2026. Hermes Agent: sessions, memory, configuration, passwords and logins. OpenClaw: sessions, agent workspace, memory, secrets, logging. ZeroClaw (v0.8.6): runtime state and persistence, agent filesystem, security model. Nanobot (v0.3.5): concepts, architecture, memory, SECURITY.md.
Section 5: Sub-processors
Your privacy notice needs to disclose every third party that processes personal data on your behalf. For a typical self-hosted setup that's roughly:
- Hosting provider (Hetzner, Cloudflare, etc.)
- LLM API provider (Anthropic, OpenAI, Google, OpenRouter)
- Email delivery (AWS SES, Resend, Postmark)
- Payment processor (Stripe) if you have a paid tier
- Analytics if any (Vercel Analytics, Plausible, etc.)
- TLS certificate authority (Let's Encrypt)
Each of these is a sub-processor. Each needs a DPA on file. Each must appear in your privacy notice.
The good news: every credible vendor in this list has a DPA template ready, signed via DocuSign or similar in 5-15 minutes. Stop putting it off.
Section 6: DPIA triggers
A Data Protection Impact Assessment is required when processing is likely high-risk to data subjects. Self-hosted AI scenarios that typically trigger:
- Automated decision-making with legal effects (e.g. an agent making hiring or credit decisions).
- Large-scale processing of special category data (health, race, political opinions, etc.).
- Systematic monitoring of public spaces.
Self-hosted AI scenarios that typically don't trigger:
- Internal developer assistant.
- Personal-use agent.
- Customer support bot for a small to medium business.
- Content moderation tooling at small scale.
If your use case is in doubt, do the DPIA: it's not that expensive in operator time and it gives you defensible documentation.
Section 7: Breach notification
GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach, and to data subjects "without undue delay" if there's likely high risk to their rights.
For self-hosted AI, the practical breach scenarios are:
- Agent host compromised (CVE exploitation, weak auth, credential theft).
- Conversation memory exfiltrated (rare but possible).
- Credential vault compromised: leads to LLM provider account abuse, potentially with personal data in cached responses.
- Audit log exfiltrated: depends on what your audit log contains.
Have a plan: who notifies the supervisor authority, who drafts the user notice, what backup of evidence you preserve. Don't wait until the breach to figure this out.
The OpenClaw CVE-2026-25253 wave generated several notifiable breaches in early 2026: assume your install will eventually need this process.
Section 8: Data subject rights
Under GDPR, data subjects have rights to access, correction, erasure, portability, objection and to lodge complaints. For a small self-hosted AI deployment, the realistic implementation is:
- Access: provide a JSON export of all data you hold on the subject within 30 days. Include conversation history, account data, newsletter subscription, audit log entries.
- Correction: let the subject correct their email and account data via account settings.
- Erasure: delete on request within 30 days. For backups, document that erasure happens at the next backup rotation cycle.
- Portability: same JSON export as access.
- Objection: pause processing on request, document the reason, notify the subject of the outcome.
Give yourself a working email address for these requests
([email protected] or [email protected]) and a documented
internal SLA for handling them.
Section 9: Transfer mechanisms
If your sub-processors are in the US (Anthropic, OpenAI, Google, AWS, Stripe, etc.), you need a transfer mechanism. The current options:
- Adequacy: UK, Switzerland, some others.
- Standard Contractual Clauses (SCCs): the dominant mechanism for US transfers post-Schrems II. All major US vendors offer these.
- Data Privacy Framework (DPF): for vendors certified under DPF. As of 2026, this remains operative but legally precarious; most operators dual-document with SCCs as a fallback.
Concretely: every US sub-processor in your list needs SCCs (or equivalent) referenced in the DPA you have on file with them.
The minimum viable GDPR posture
If you're a solo operator with a self-hosted agent serving EU users, here's the realistic minimum:
- Privacy notice published, listing sub-processors and lawful basis per processing op.
- Cookie banner only if you actually set non-essential cookies (most self-hosted agents don't need one).
- DPAs on file with every sub-processor.
- Conversation memory retention set to a defensible number (30 days default, document why).
- Credentials in OS keyring or encrypted vault.
[email protected]working, monitored, documented internal SLA.- Breach notification process written down: even a half-page document is fine, you just need it to exist before you need it.
Beyond that you're in DPIA / specialised lawyer territory. Most self-hosted operators don't need to go there.
What this guide does not cover
We've stayed in the GDPR lane. Adjacent regulatory regimes you may also need to think about:
- EU AI Act for high-risk deployments, separate post coming.
- Sector-specific regs (HIPAA, PCI-DSS, SOX): out of scope here.
- Member state derogations: France's CNIL, Germany's BfDI etc. occasionally add specifics.
For specifics, talk to a lawyer who actually does data protection work, not a generalist who'll quote ChatGPT at you.