Why feedback data is in scope for GDPR
Feedback from your users almost certainly contains personal data under GDPR's definition. A support ticket that says "I am having trouble with my account" contains the submitter's identity by association even if you strip the email address, because it is linked to an account. Feedback that mentions a name, a specific transaction, or an identifiable situation is unambiguously personal data.
This means you need a lawful basis for processing it, you need to be able to respond to deletion requests (the right to erasure), and you need to be able to explain to a user or supervisory authority what you are doing with their data and where it flows.
Note: this post describes how Rereflect's self-hosted architecture supports GDPR compliance; it is not legal advice. Your specific compliance requirements depend on your data, your users, and the advice of your legal counsel.
The third-party transfer problem with SaaS tools
The most common GDPR friction point with managed SaaS feedback tools is international data transfer. If your users are in the EU and the SaaS tool processes data on US servers (or sends it to a US-based LLM API), you need a valid transfer mechanism: Standard Contractual Clauses, a data processing agreement with the vendor, or reliance on another adequacy decision.
In practice, the chain gets complicated. The SaaS tool is the processor; you are the controller. But the SaaS tool may use a sub-processor (the LLM API) that has its own data handling terms. Getting that sub-processor chain documented in a way that satisfies a data processing agreement is real work — and if any link in the chain is in a jurisdiction with inadequacy concerns, you have a problem.
Self-hosting eliminates this chain for the storage and processing steps. Your feedback stays in a database you run, in a region you choose. If you also use a local LLM, the analysis step eliminates the LLM provider from the chain entirely.
Data residency: choosing your region
When you self-host Rereflect, you choose where the PostgreSQL database runs. Run it in the EU and your feedback data never leaves EU infrastructure. This is a meaningful compliance posture that a SaaS tool with US-based infrastructure cannot match without explicit contractual and technical guarantees.
Concretely: if you deploy the docker-compose stack on a server in Frankfurt, Amsterdam, or another EU data centre, and you do not configure an LLM key pointing at a non-EU provider, your feedback data stays in the EU throughout its lifecycle. With a local Ollama model alongside the stack, even the analysis calls are on the same host.
Document this in your Records of Processing Activities (ROPA): "Customer feedback is stored in a PostgreSQL database hosted in [region] and processed by Rereflect running on the same infrastructure." That is a clear, accurate, auditable statement.
Handling deletion requests (the right to erasure)
GDPR Article 17 gives individuals the right to request deletion of their personal data. For feedback data this means you need to be able to find all feedback associated with a specific user and delete it when requested.
With a self-hosted Rereflect, the database is yours. You can write a direct SQL query, or use the admin interface, to find all feedback items linked to a user (by email, user ID, or account reference) and hard-delete them. The deletion takes effect immediately. There is no "submit a request and we will process it within 30 days" queue, because the data is in your own database.
If you use an LLM provider for analysis, be aware that the provider's own data retention policy may mean they retain the text of the prompt for some period (check their terms). If this is a concern, use a local model or the VADER fallback, which sends nothing to any external service.
- Feedback text and derived data (sentiment, categories) are stored in your PostgreSQL database.
- Delete items directly via the Rereflect UI, the API, or SQL queries against your database.
- Deletion is immediate — no vendor queue.
- If using a hosted LLM provider: check their data retention terms for prompts and completions.
- With a local model or VADER: no data leaves your infra, so no external retention concern.
Practical checklist for GDPR and self-hosted Rereflect
This is not an exhaustive compliance checklist — work with legal counsel for your specific situation. These are the self-hosting configuration choices that have the most direct bearing on GDPR considerations for feedback data.
- Host PostgreSQL in an EU region if your users are in the EU.
- Configure SELF_HOSTED=true to disable any calls to Rereflect cloud services.
- Use a local LLM or VADER to eliminate feedback text flowing to a third-party AI provider.
- If using a hosted LLM, ensure you have a DPA with the provider that covers sub-processor use.
- Document data flows in your ROPA: where feedback is stored, how it is processed, how long it is retained.
- Implement a deletion workflow: define the process for responding to erasure requests and confirm you can execute it against your database.
- Set a data retention policy and implement it: decide how long feedback is kept and configure periodic deletion if needed.