GDPR-compliant feedback analysis: what it actually requires

A note before anything else: we build a feedback-analysis product, we are not lawyers, and this is not legal advice. What follows is the practical engineering shape of the problem — the questions that actually determine whether your feedback pipeline is defensible, and a checklist you can hold any vendor to, including us.

Yes, customer feedback is personal data

Teams often assume feedback text is anonymous because it has no name field. Under GDPR that reasoning doesn’t hold in three common cases:

• It’s linked to an account. A review, ticket or survey response tied to a user id is personal data about an identifiable person, full stop.
• The text identifies people anyway. Free text is where people write their email address, their colleague’s name, an order number, sometimes a phone number. You did not ask for it; you received it.
• It can wander into special categories. “I couldn’t use the app during my chemo” is health data, volunteered in a support ticket. Rare, but you cannot promise it won’t happen, so your architecture has to assume it will.

And AI analysis is processing. Sending feedback to a model to be classified, clustered or summarised makes whoever runs that model a processor or sub-processor in your chain — which is exactly where most informal setups quietly fall apart.

The four requirements that actually bite

1. A lawful basis, and honesty about the purpose

You need a defensible reason to process the feedback. For most product teams this is legitimate interest (improving the service the customer uses), which is workable — but legitimate interest is a balancing test, not a magic phrase. It requires that your use is what a reasonable customer would expect. Analysing complaints to fix the product: expected. Scoring individuals to feed a sales-targeting model: a different conversation, and one your privacy notice had better mention.

2. Data minimisation — the one with architectural consequences

You should not be holding personal data you don’t need. For feedback analysis, here’s the thing worth internalising: you almost never need the personal details inside the text. To learn that checkout is broken, you need the complaint; you do not need the complainant’s email address sitting in your database forever.

This creates a real architectural fork, and it is the difference between a compliant design and a tidy-looking one:

Ask any vendor which one they do. It is a single question that separates privacy as a policy from privacy as an architecture, and the answer is rarely on the marketing page.

3. Where the data physically lives, and where it travels

EU personal data leaving the EEA needs a transfer mechanism, and the chain includes every sub-processor — including the AI provider doing the analysis. A tool hosted in the EU that ships your text to a model in another jurisdiction has a transfer to account for, whether or not its homepage says “EU-hosted.”

The practical questions are: where is the database, where do the AI calls go, who are the sub-processors, and is there a list you can actually read. Any vendor should answer all four without a sales call.

4. Erasure that actually reaches everywhere

When a customer asks to be deleted, the obligation covers every copy — including the feedback they left, its derived analysis, and any backups within your stated cycle. Two traps show up constantly:

• Derived data. Deleting the message but keeping an embedding, summary or score derived from it is not deletion. If it came from their data and still describes them, it goes.
• The spreadsheet fork. The CSV somebody exported for last quarter’s analysis is a copy you now cannot find. Every manual export is a future erasure request you will fail.

Erasure needs to be an API or a button, not a project. If deleting one user requires a person to remember where the copies went, you don’t have deletion — you have intentions.

The elephant: pasting customer text into a general AI chat

It is now standard practice to export feedback to CSV and paste it into a general chatbot for a quick theme analysis. We wrote about the analytical limits of that in our App Store review guide. The compliance limits are sharper. Before you paste, you need answers to:

• Is this account a consumer plan (usually no data-processing terms) or a business tier with a DPA in place?
• Is the content excluded from model training, contractually rather than by a settings toggle someone might flip back?
• Where is it processed, how long is it retained, and can you get it deleted when a customer asks?
• Is this vendor on your privacy notice as a processor? If not, you just introduced one nobody has documented.

There are perfectly compliant ways to use a general AI tool for this — a business agreement, redacted inputs, a documented processor. The problem is that the fast version skips all four questions, and it usually happens on a Friday afternoon under deadline.

The vendor checklist

Copy this into your evaluation of any feedback tool. Every question has a factual answer; vagueness on any of them is itself the finding.

• Where is the primary database physically located, and can I choose?
• Is personal data redacted before storage, or masked at display time?
• Which AI providers process my text, and where do those calls run?
• Is my data used to train shared models — and is that a contractual commitment?
• Can I delete one end user’s data via API, including derived analysis?
• Can I export everything, on any plan, without asking support?
• Is a DPA available, and is the sub-processor list published?
• What is the retention default, and can I shorten it?

Our answers, since we just handed you the questions

It would be cowardly to publish that list without answering it. Sentriment stores data in the EU (Frankfurt). Personal data is redacted at ingestion, in two stages — pattern matching for well-formed identifiers, then an AI sweep for the messier things humans write — so the raw text is never written to the database. Feedback is never used to train shared models. Individual end-user erasure is an API call and a one-click action, and it removes the derived analysis with the source. Export works on every plan including the free one. A DPA is available on request, and our processing is described in our privacy policy.

Two honest limitations, stated because a compliance page that admits nothing is a marketing page: we are not SOC 2 certified — it’s on the roadmap and we won’t claim it before it’s true — and redaction, however good, is probabilistic on free text; our defence is the two-stage design plus a flag raised when the analysis itself spots leaked personal data, not a promise of perfection.

The underlying philosophy is simple enough to state in a sentence: the safest personal data is the personal data you never stored. Everything above is the engineering consequence of taking that seriously.

Related reading

• How to analyze customer feedback: a method that survives contact with reality — where privacy fits into the workflow (step two, before analysis).
• Analyzing Intercom conversations: the feedback channel nobody reads in aggregate — the most personal-data-dense channel you have.