---
title: "Customer Feedback Data: Retention, Privacy, and the Decisions CX Teams Must Make"
date: "2026-08-21"
description: "Customer feedback data privacy is decided less by what the law says than by what your CX team does on autopilot — retention windows nobody set, verbatims nobody scanned, and AI processing nobody disclosed."
keywords: ["customer feedback data privacy", "feedback data retention", "voc data governance"]
author: "Perspective AI Team"
category: "AI Customer Interviews & Research"
slug: "customer-feedback-data-retention-and-privacy"
excerpt: "Customer feedback data privacy is decided less by what the law says than by what your CX team does on autopilot — retention windows nobody set, verbatims…"
image: "https://getperspective.agency/assets/9a7e3a65-0536-4968-bd53-c2bc472b8db6"
tags: ["feedback data retention", "customer research", "guides", "product management", "how-to"]
lastModified: "2026-08-21"
definition: "Customer feedback data privacy is decided less by what the law says than by what your CX team does on autopilot — retention windows nobody set, verbatims nobody scanned, and AI processing nobody disclosed. The open-ended response is the highest-risk field in the stack: unlike a 1–5 rating, a free-text comment can carry a customer's full name, an account or policy number, a health detail, or an allegation about a named employee, and none of that appears where your data map says personal data lives. GDPR Article 5(1)(e) sets no fixed retention period, so the window is yours to justify — while California's CCPA, as amended by the CPRA, requires businesses to disclose \"the length of time the business intends to retain each category of personal information, including sensitive personal information.\" The response clocks are short: one month under GDPR Article 12(3), extendable by two further months, and 45 calendar days under the CCPA, extendable once to 90. AI processing adds a disclosure layer, because the EU AI Act requires that people interacting directly with an AI system be told so unless it is obvious, and California's automated decisionmaking technology (ADMT) rules phase in significant-decision obligations from January 1, 2027. The practical fix is a one-page policy that fixes six things per feedback source: purpose, lawful basis, retention window, PII handling in verbatims, storage region, and the deletion path. Every decision below is a business decision to make with your counsel and privacy team — nothing here is legal advice."
faqs: [{"question": "How long should you keep customer feedback data?", "answer": "Keep customer feedback only as long as a documented purpose requires it, which in practice means 30–90 days for identified service-recovery records, 12–24 months for de-identified trend analysis, and 24–36 months of aggregate data for year-over-year benchmarking. No regulation names a fixed number — GDPR Article 5(1)(e) requires only that data not be kept longer than necessary. Set separate clocks for the raw verbatim and the structured response, and enforce expiry automatically rather than by reminder."}, {"question": "Is customer feedback personal data under GDPR?", "answer": "Yes, customer feedback is personal data under GDPR whenever it can be linked to an identifiable person, which includes most feedback collected through an invitation, login, or email link. Open-text verbatims can also contain special category data such as health or religious details, triggering stricter conditions. Replacing an identifier with a hash produces pseudonymous data, which the ICO confirms is still personal data and still in scope."}, {"question": "Do you need consent to analyze customer feedback with AI?", "answer": "Consent is not always required, because legitimate interests can support service-improvement research if you document a balancing assessment — but disclosure of AI involvement generally is required. The EU AI Act requires informing people that they are interacting with an AI system unless it is obvious. Separately, if AI output drives a significant decision about an individual, additional obligations such as California's ADMT rules may apply, so confirm the classification with counsel."}, {"question": "What happens to feedback data when a customer requests deletion?", "answer": "You must delete the customer's feedback from every store that holds it, including the raw response, the analytics warehouse, vector indexes, cached reports, and vendor backups, unless a GDPR Article 17(3) exemption applies. Those exemptions cover legal obligations, defence of legal claims, and narrowly defined research or statistical purposes. Response deadlines are one month under GDPR, extendable by two further months, and 45 calendar days under the CCPA, extendable to 90."}, {"question": "Can you store customer feedback verbatims outside the EU?", "answer": "You can store EU customer feedback outside the EU only with a valid transfer mechanism, such as reliance on the EU-U.S. Data Privacy Framework adequacy decision for certified US recipients or Standard Contractual Clauses supported by a transfer impact assessment. With AI processing, storage region is not sufficient on its own — you also need to know and contractually fix the inference region, the embedding store location, and the full sub-processor chain."}, {"question": "Who owns VoC data governance — CX, legal, or IT?", "answer": "CX owns the collection decisions, legal owns the lawful-basis and transfer determinations, and IT or security owns the retention enforcement and deletion propagation — which is why single-owner models fail. The workable pattern is a named CX program owner accountable for the per-source one-pager, with legal and security as required reviewers before any new collection surface goes live."}]
---

## TL;DR

Customer feedback data privacy is decided less by what the law says than by what your CX team does on autopilot — retention windows nobody set, verbatims nobody scanned, and AI processing nobody disclosed. The open-ended response is the highest-risk field in the stack: unlike a 1–5 rating, a free-text comment can carry a customer's full name, an account or policy number, a health detail, or an allegation about a named employee, and none of that appears where your data map says personal data lives. GDPR Article 5(1)(e) sets no fixed retention period, so the window is yours to justify — while California's CCPA, as amended by the CPRA, requires businesses to disclose "the length of time the business intends to retain each category of personal information, including sensitive personal information." The response clocks are short: one month under GDPR Article 12(3), extendable by two further months, and 45 calendar days under the CCPA, extendable once to 90. AI processing adds a disclosure layer, because the EU AI Act requires that people interacting directly with an AI system be told so unless it is obvious, and California's automated decisionmaking technology (ADMT) rules phase in significant-decision obligations from January 1, 2027. The practical fix is a one-page policy that fixes six things per feedback source: purpose, lawful basis, retention window, PII handling in verbatims, storage region, and the deletion path. Every decision below is a business decision to make **with your counsel and privacy team** — nothing here is legal advice.

## Why the Verbatim Is the Riskiest Field in Your Feedback Stack

The verbatim is the riskiest field because it is the only one whose contents you did not define. Every other column in a feedback dataset is constrained by design: NPS is an integer from 0 to 10, CSAT is a five-point scale, channel is an enum. The open-text box is unbounded — customers put whatever they want in it, and what they want is often exactly the category of information your privacy notice never promised to collect.

In practice, feedback verbatims routinely surface five things a CX data map rarely accounts for:

- **Direct identifiers** — customers sign comments, paste email addresses, or reference order, policy, and account numbers to "help you look it up."
- **Special category data** — health conditions explaining a cancellation, disability accommodations, religious or dietary constraints, pregnancy, immigration status.
- **Third-party personal data** — details about a spouse, child, caregiver, or colleague the customer never consented on behalf of.
- **Named-employee allegations** — "the agent, Marcus in the Tulsa office, was rude," which is simultaneously customer feedback, employee personal data, and potentially an HR matter.
- **Financial and payment fragments** — partial card numbers, bank names, dispute amounts.

None of this is hypothetical, and none of it is the customer's fault. Free text collects it because free text is where humans behave like humans. That is exactly why it is the most valuable field you own — as anyone who has worked through [what 40,000 open-ended responses actually reveal](/blog/verbatim-analysis-40000-open-ended-responses) can attest — and simultaneously the field that turns a routine feedback program into a data-protection surface.

The risk compounds when an AI layer reads those verbatims. A traditional survey tool stored the comment and showed it to three analysts. A modern platform embeds it, clusters it, quotes it in an executive summary, and pipes the summary to Slack. The same sentence containing a policy number now exists in a vector index, a report, a notification, and a warehouse table. If you cannot enumerate those copies, you cannot honor a deletion request — which is where most programs quietly fail their first real audit.

This is the gap between having a governance policy and having governance. If you have already worked through the broader [CX AI governance policy decisions for 2026](/blog/cx-ai-governance-policy-decisions-2026), this guide is the data-layer companion: the retention, PII, consent, residency, and rights-request specifics that policy document assumes someone else already settled.

## Feedback Data Retention: How Long Should You Keep Verbatims?

There is no statutory retention period for customer feedback, which means your retention window is a documented business judgment rather than a lookup. [GDPR Article 5(1)(e)](https://gdpr-info.eu/art-5-gdpr/) requires only that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." The regulation deliberately declines to name a number. California takes the same posture from the other direction: [Civil Code §1798.100](https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.100) says a business "shall not retain a consumer's personal information or sensitive personal information for each disclosed purpose for which the personal information was collected for longer than is reasonably necessary for that disclosed purpose" — and, critically, that you must *publish* the intended duration per category.

That publication requirement is the part most CX teams miss. It converts retention from an internal hygiene question into a public commitment, which means an unset default is now a disclosure problem, not just a storage-cost problem.

The usable approach is to stop asking "how long can we keep feedback?" and start asking "how long does each *purpose* need it?" Purposes have natural expiry dates; datasets do not.

| Purpose | Typical working window | What justifies it | What to do at expiry |
|---|---|---|---|
| Individual service recovery / closing the loop | 30–90 days | The follow-up conversation is the purpose; after that the ticket is closed | Delete the identified record, keep the resolution outcome |
| Trend and driver analysis | 12–24 months | Enough cycles to separate seasonality from real movement | De-identify: keep themes and scores, drop verbatim + identifiers |
| Year-over-year benchmarking | 24–36 months | Comparability across two to three annual cycles | Aggregate to cohort level; no row-level retention |
| Model or taxonomy training | Tied to model lifecycle | The training corpus is the purpose, not the customer relationship | Retrain on de-identified text or retire the corpus |
| Legal hold / dispute | Duration of the matter + limitation period | Legal claims exemption applies | Release the hold explicitly; do not let holds become permanent |
| Regulated-industry records | Set by the sector rule, not by CX | Financial, health, and insurance record rules override CX preference | Follow the sector schedule; document the override |

Three rules make this hold up in review. First, **write the window down before you collect**, because a retroactively invented window is indistinguishable from no window. Second, **separate the verbatim's clock from the record's clock** — you can almost always delete the raw text far earlier than the structured score, and doing so removes the majority of your exposure while preserving the analytics your dashboards depend on. Third, **make expiry automatic**. A retention policy enforced by a quarterly reminder is a retention aspiration. If your platform cannot express "delete raw verbatim text at day 180, retain coded theme indefinitely," that is a requirement to add to your [CX platform requirements checklist](/blog/customer-experience-platform-requirements-checklist-to-write-before-you-shortlist) and a scored line item in any [vendor-neutral evaluation framework](/blog/how-to-evaluate-a-customer-experience-platform-vendor-neutral-scoring-framework) you run.

Retention is also a cost line, not only a risk line. Storage, index, and reprocessing costs scale with the corpus, which is why retention discipline shows up in a realistic [CX platform total cost of ownership](/blog/cx-platform-total-cost-of-ownership) model rather than only in the privacy register.

## PII Inside Open-Ended Responses: Detect, Redact, or Separate

Handling PII in verbatims comes down to choosing one of three postures per feedback source — detect-and-flag, redact-at-ingest, or separate-and-restrict — and applying it consistently rather than case by case.

**Detect-and-flag** runs a classifier over incoming text, tags likely identifiers, and routes flagged responses to a restricted queue. It preserves the original text for service recovery, which matters when a customer *wants* you to look up their account. It also means the raw identifier still exists, so the tag is a control, not a cure.

**Redact-at-ingest** replaces detected entities with placeholders before the text lands in the analytics store — `[NAME]`, `[ACCOUNT_NUMBER]`, `[EMAIL]`. Redaction is the strongest option for pure analytics use cases and the wrong option when the same response must drive a follow-up. The honest caveat: no detector is perfect on messy human text, and recall on unusual formats, misspelled names, and mixed-language responses is meaningfully below the vendor demo. Treat redaction as substantial risk reduction, not as anonymization.

**Separate-and-restrict** keeps identified verbatims in a limited-access store with a short clock, and pushes only de-identified text into the analytics and AI layer. This is the posture most large programs converge on, because it lets the analytics corpus live for two years while the identified copy lives for ninety days.

The vocabulary matters here more than teams expect. The UK Information Commissioner's Office is explicit that [pseudonymisation is not the same as anonymisation](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/): pseudonymous data still concerns people who can be identified using additional information held separately, so it remains personal data and stays in scope for retention limits and rights requests. Swapping a customer ID for a hash does not take a dataset out of scope. Genuine anonymisation of free text is hard precisely because the *content* re-identifies — "the flood claim on the barn in Cedar Rapids last March" names no one and identifies one person.

Two further specifics that catch CX programs:

- **Voice and video raise the floor.** A recorded call is personal data in a form that also carries voiceprint characteristics, accent, and emotional signal. If you run voice interviews, decide explicitly whether you retain audio, transcript, or both — and default to transcript-only unless audio serves a purpose you can name.
- **Screenshots and attachments are unscanned verbatims.** Feedback widgets that accept image uploads collect whatever was on the customer's screen, which regularly includes other people's data. Apply the same posture, or don't accept attachments.

If you are picking a platform, the practical test is not whether PII detection appears on the feature list but whether it is configurable per source, auditable, and reversible. That is the level of specificity that belongs in your [CX platform RFP questions](/blog/cx-platform-rfp-questions-for-vendors), and it is one of the [capabilities that separates a real CXP from a survey tool](/blog/customer-experience-platform-features-12-capabilities-that-separate-a-cxp-from-a-survey-tool).

## Consent and Notice for AI-Processed Feedback

Notice for AI-processed feedback requires disclosing three distinct things — that an AI system is involved, what it does with the response, and whether the response trains anything — because a generic privacy-policy link covers none of them specifically.

Start with the interaction itself. [Article 50 of the EU AI Act](https://artificialintelligenceact.eu/article/50/) requires providers to ensure that AI systems "intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious." For an AI interviewer or concierge, the compliant pattern is trivially cheap: say so in the first message. The same article requires deployers of emotion-recognition and biometric-categorisation systems to inform the people exposed to them — relevant if you are scoring sentiment from voice or facial signal rather than from text.

Then separate consent from lawful basis, because CX teams routinely conflate them. Consent is one lawful basis among several; legitimate interests often fits ongoing service-improvement research better, and it requires a documented balancing assessment rather than a checkbox. Where consent *is* your basis, it has to be as easy to withdraw as to give, and withdrawal has to actually propagate to the analytics copy.

Three disclosures are worth making explicit in the collection experience rather than burying:

1. **Who sees the verbatim.** "Your comments may be quoted in internal reports" is a materially different promise from "your comments are read only in aggregate."
2. **Whether responses train models.** Many buyers now require a contractual "no training on customer data" term. Get it in writing from the vendor and confirm it covers sub-processors and any foundation-model provider in the chain.
3. **Whether AI output drives a decision about the individual.** This is the trigger that matters most in California: the CPPA's finalized ADMT regulations took effect January 1, 2026, with obligations for businesses using ADMT to make *significant decisions* about consumers applying from January 1, 2027, alongside risk-assessment duties whose first attestation and summary filing is due to the agency by April 1, 2028. Most CX feedback analysis is not significant-decisionmaking. But feedback that feeds a churn-risk score which then gates pricing, credit, or service tiers plausibly is — and that is a determination to make deliberately, with counsel, before the workflow ships.

The design implication runs the other way too. A conversational interview can ask for consent contextually, in language a person actually reads, and can decline to record a detail the respondent flags as sensitive — something a static form cannot do because the form has already captured the field before anyone evaluated it. If you are mapping this into a delivery plan, it sequences naturally inside a [90-day AI-for-CX rollout](/blog/ai-for-cx-90-day-rollout-sequence-2026), and the readiness gaps usually surface first in a structured [CX AI readiness assessment](/blog/cx-ai-readiness-the-assessment-to-run-before-you-buy-anything).

## Data Residency and Cross-Border Transfer

Data residency for feedback programs is decided by three questions: where the data is stored at rest, where it is processed (including by AI inference), and which sub-processors touch it in transit. Storage region alone answers one-third of the question, and it is the only third most vendor datasheets address.

The processing question is the one AI changed. A platform can store EU responses in an EU region and still route inference to a model endpoint elsewhere. Ask vendors to name the inference region, not just the storage region, and to commit to it contractually. Ask the same about the embedding store, the analytics warehouse, and any support tooling through which staff can read verbatims.

For EU-to-US flows, the European Commission's adequacy decision for the EU-U.S. Data Privacy Framework, adopted in July 2023, is the primary mechanism for certified US recipients, with Standard Contractual Clauses plus a transfer impact assessment as the fallback. Both remain subject to ongoing legal challenge and periodic review, so treat the specific mechanism as a live item your privacy team re-confirms rather than a setting you configure once. Other jurisdictions add their own constraints — sectoral localization rules in financial services, health, and public sector work frequently override whatever the CX team preferred.

Two practical habits reduce the surface area. First, **do not consolidate globally by default.** A single worldwide feedback lake is convenient for analysis and expensive for compliance; regional stores with aggregated cross-region reporting is often the cheaper posture overall. Second, **maintain the sub-processor list as a living document** and require notice of changes. Sub-processor churn is the most common way a compliant architecture silently stops being one.

Residency requirements are also a migration constraint, not just a procurement one. Teams [pulling historical data out of Qualtrics](/blog/getting-your-data-out-of-qualtrics) discover that export includes years of un-scanned verbatims that now have to land somewhere with a defensible region and clock — which is why residency belongs on the [60-day CX platform migration checklist](/blog/cx-platform-migration-checklist-60-days) rather than in a post-launch cleanup ticket.

## Handling Subject Access and Deletion Requests for Feedback Data

Subject access and deletion requests for feedback data are hard for one structural reason: feedback is usually stored by response, not by person, so "find everything about this individual" is a search problem your schema was never designed to answer.

The clocks are unforgiving. Under GDPR Article 12(3), controllers must respond without undue delay and in any event within **one month**, extendable by **two further months** for complex or numerous requests, provided the individual is told within the first month and given reasons. Under the CCPA, per the [California Attorney General](https://oag.ca.gov/privacy/ccpa), businesses "must respond to your request within 45 calendar days" and "can extend that deadline by another 45 days (90 days total) if they notify you," with the right-to-know disclosure covering the 12-month period preceding the request.

A workable request-handling path for feedback data has five steps:

1. **Step 1: Maintain a feedback data inventory.** Every collection surface, its store, its region, its retention window, and its owner. Without this, step 2 is guesswork.
2. **Step 2: Resolve identity to response.** You need a join key — email, customer ID, or invitation token — persisted at collection. Anonymous feedback is genuinely out of scope for access requests, which is a strong argument for collecting some feedback anonymously on purpose.
3. **Step 3: Search the verbatim body, not just the metadata.** A customer may appear in someone *else's* comment. Full-text search across the corpus is part of a complete response, and it is the step most teams skip.
4. **Step 4: Redact third parties before disclosure.** A verbatim naming an employee or another customer cannot be handed over wholesale; the access right is not a license to disclose other people's data.
5. **Step 5: Propagate deletion to every derived copy.** Raw store, analytics warehouse, vector index, cached reports, BI extracts, Slack notifications, and any vendor-side backups. Enumerate these once and keep the list current.

Deletion has real limits worth knowing before you promise anything. [GDPR Article 17](https://gdpr-info.eu/art-17-gdpr/) grants erasure on defined grounds — data no longer necessary, consent withdrawn, unlawful processing, objection — but Article 17(3) carves out processing necessary for legal obligations, for the establishment or defence of legal claims, and for archiving, scientific, historical, or statistical purposes where erasure "would render impossible or seriously impair" those objectives. That research exemption is narrower than CX teams hope; it is not a general license to keep verbatims for analysis.

The pragmatic move is to make deletion cheap by design: if the identified verbatim already expires at day 90 and the analytics corpus is de-identified, most deletion requests resolve to a small, well-bounded operation. Governance that is expensive to execute does not get executed — a pattern that shows up whenever you compare the operational cost of running a program in-house against a managed platform in a [build-versus-buy decision framework](/blog/build-vs-buy-a-customer-experience-platform-decision-framework).

## A One-Page Customer Feedback Data Privacy Policy Checklist

The deliverable that closes this out is one page per feedback source, not a fifty-page manual nobody opens. If you can fill this in for every collection surface you run, you have a defensible position and a real answer when legal asks.

**Per feedback source, record:**

- [ ] **Source and surface** — what it is, where it appears, who owns it
- [ ] **Purpose(s)** — stated specifically enough to expire
- [ ] **Lawful basis** — and, if legitimate interests, a link to the balancing assessment
- [ ] **Categories collected** — including "free text may contain special category data"
- [ ] **Retention window** — separately for raw verbatim, structured response, and derived themes
- [ ] **Published retention disclosure** — the customer-facing statement, per CCPA §1798.100
- [ ] **PII posture** — detect-and-flag, redact-at-ingest, or separate-and-restrict
- [ ] **Voice/attachment decision** — retain audio, transcript-only, or refuse uploads
- [ ] **AI disclosure** — the exact in-experience wording that says an AI system is involved
- [ ] **Training commitment** — contractual no-training term, including sub-processors
- [ ] **Significant-decision assessment** — does any output gate a decision about the individual?
- [ ] **Storage region and inference region** — named separately
- [ ] **Transfer mechanism** — DPF certification, SCCs plus transfer impact assessment, or intra-region only
- [ ] **Sub-processor list** — current, with change-notice terms
- [ ] **Access-request path** — join key, full-text search step, third-party redaction step
- [ ] **Deletion propagation map** — every derived copy, named
- [ ] **DPIA status** — completed, not required, or scheduled, with the rationale recorded
- [ ] **Review date** — because none of the above survives a year of product change

Two organizational notes. First, this checklist has an owner problem, not a knowledge problem: it fails when it sits with a privacy team that does not know how feedback is collected, or a CX team that does not know what a transfer impact assessment is. Getting privacy and security onto the [CX buying committee](/blog/cx-buying-committee-who-sits-on-it) early, rather than at contract review, is the single highest-leverage change most programs can make. Second, run the checklist during a [CX platform pilot](/blog/how-to-run-a-cx-platform-pilot) while switching costs are still near zero — that is when a vendor's honest answer about inference regions is cheapest to act on.

VoC data governance done this way also improves the research. Shorter retention forces you to act on feedback in-cycle instead of hoarding it. Purpose-specific collection produces cleaner datasets. And explicit AI disclosure raises completion quality, because respondents who know what they are talking to and what happens to their words tell you more, not less — which is the same dynamic that makes conversational depth the ranking axis in a comparison of [voice of customer software by listening depth](/blog/voice-of-customer-software-2026-ranked-by-listening-depth) and a recurring theme in [the complete guide to voice of customer programs in 2026](/blog/the-complete-guide-to-voice-of-customer-programs-in-2026).

## Frequently Asked Questions

### How long should you keep customer feedback data?

Keep customer feedback only as long as a documented purpose requires it, which in practice means 30–90 days for identified service-recovery records, 12–24 months for de-identified trend analysis, and 24–36 months of aggregate data for year-over-year benchmarking. No regulation names a fixed number — GDPR Article 5(1)(e) requires only that data not be kept longer than necessary. Set separate clocks for the raw verbatim and the structured response, and enforce expiry automatically rather than by reminder.

### Is customer feedback personal data under GDPR?

Yes, customer feedback is personal data under GDPR whenever it can be linked to an identifiable person, which includes most feedback collected through an invitation, login, or email link. Open-text verbatims can also contain special category data such as health or religious details, triggering stricter conditions. Replacing an identifier with a hash produces pseudonymous data, which the ICO confirms is still personal data and still in scope.

### Do you need consent to analyze customer feedback with AI?

Consent is not always required, because legitimate interests can support service-improvement research if you document a balancing assessment — but disclosure of AI involvement generally is required. The EU AI Act requires informing people that they are interacting with an AI system unless it is obvious. Separately, if AI output drives a significant decision about an individual, additional obligations such as California's ADMT rules may apply, so confirm the classification with counsel.

### What happens to feedback data when a customer requests deletion?

You must delete the customer's feedback from every store that holds it, including the raw response, the analytics warehouse, vector indexes, cached reports, and vendor backups, unless a GDPR Article 17(3) exemption applies. Those exemptions cover legal obligations, defence of legal claims, and narrowly defined research or statistical purposes. Response deadlines are one month under GDPR, extendable by two further months, and 45 calendar days under the CCPA, extendable to 90.

### Can you store customer feedback verbatims outside the EU?

You can store EU customer feedback outside the EU only with a valid transfer mechanism, such as reliance on the EU-U.S. Data Privacy Framework adequacy decision for certified US recipients or Standard Contractual Clauses supported by a transfer impact assessment. With AI processing, storage region is not sufficient on its own — you also need to know and contractually fix the inference region, the embedding store location, and the full sub-processor chain.

### Who owns VoC data governance — CX, legal, or IT?

CX owns the collection decisions, legal owns the lawful-basis and transfer determinations, and IT or security owns the retention enforcement and deletion propagation — which is why single-owner models fail. The workable pattern is a named CX program owner accountable for the per-source one-pager, with legal and security as required reviewers before any new collection surface goes live.

## The Governance Decision You Are Already Making

Customer feedback data privacy is not a project you start; it is a set of decisions your program is already making by default. Right now something is retaining verbatims for an unspecified period, something is or is not scanning free text for identifiers, something is processing responses in a region nobody named, and some customer somewhere is about to send an access request that will test all of it. The difference between a governed program and an exposed one is whether those choices were made deliberately and written down — retention windows tied to purposes, a stated PII posture per source, AI disclosure in the collection experience, named storage and inference regions, and a deletion path that reaches every derived copy.

The good news is that the governed version is also the better research program. Purpose-bound retention forces action in-cycle. De-identified analytics corpora are easier to share, which means more teams actually use the insight — the practical unlock behind moving [from dashboards to the why behind the numbers](/blog/customer-experience-analytics-from-dashboards-to-the-why-behind-the-numbers). And transparent AI disclosure earns depth rather than costing it, a shift that separates modern platforms from the survey-suite era described in [what a customer experience platform is and why AI is replacing the survey suite](/blog/what-is-a-customer-experience-platform-cxp-and-why-ai-is-replacing-the-survey-suite) and in the account of [what enterprise feedback management became](/blog/enterprise-feedback-management-2026-what-the-category-became).

Perspective AI is built for this posture. AI interviewers disclose that they are AI in the first message, ask for context conversationally instead of pre-collecting fields a form would capture before anyone assessed them, and produce analyzable themes without requiring you to warehouse raw verbatims forever. It is purpose-bound listening rather than indefinite collection — which is what [CX teams](/roles/cx-teams) need when the retention question finally arrives from legal.

Take the concrete next step: run one purpose-bound study against the checklist above. Start from a [voice-of-customer interview template](/templates/voice-of-customer-survey) or a [customer journey interview](/templates/customer-journey-interview), set the retention window before you launch, and [start your first interview](/research/new) with the disclosure and deletion path already decided. Configuration details, data handling, and export options are documented in the [product documentation](/docs).