Synthetic Personas, Privacy, and Ethics: No PII, No Consent Debt, No Re-Identification Risk

Governance · 10 min read

TL;DR: Consumer research on live panels processes personal data. Under GDPR that triggers lawful-basis requirements, data-subject rights, retention limits, cross-border transfer controls, and re-identification risk for any dataset that is later shared or reused. Synthetic personas built from aggregated public statistics process no personal data, which removes the trigger. The compliance argument is not that synthetic research is unregulated (it is not); it is that the regulatory surface is dramatically smaller because no natural person is involved as a data subject. This article lays out the argument in the terms that legal, privacy, and procurement teams actually care about: what data flows in, what is stored, what could be re-identified, what has to be disclosed, and what happens under a data-subject request. It is written for research leads who need to satisfy an enterprise privacy review, and for privacy counsel who need to evaluate a synthetic research platform against their own framework.

Do synthetic personas process personal data under GDPR?

No. Personal data under GDPR Article 4(1) is 'any information relating to an identified or identifiable natural person'. A synthetic persona is a fabricated profile generated from aggregated statistical distributions with no linkage to any real individual, and no natural person is identified or identifiable through the profile. The processing that produces the persona uses aggregated public statistics, which are not personal data. GDPR obligations therefore do not attach to the persona itself.¹

The Article 29 Working Party opinion on anonymisation techniques is the canonical guidance on when a dataset stops being personal data.² The three tests are singling out, linkability, and inference. A synthetic persona fails all three tests as an identifier of any real person: it does not single out any individual (it is generated, not drawn), it cannot be linked to any individual (no real record was used), and it cannot be used to infer information about any specific individual (aggregated distributions do not encode individual-level data).

That is the compliance argument. It rests on the input data being genuinely aggregated. National census outputs are the paradigm case: statistical offices apply disclosure control before publication so that aggregated tables cannot be reversed into individual records. That work has already been done before the data reaches the synthesis engine.⁵

The argument is narrower than 'synthetic research has no privacy obligations'. It is 'the synthetic persona is not personal data'. Obligations still attach elsewhere in the workflow: the user account is personal data, the research questions may carry confidentiality obligations, and any client-supplied stimulus (a real product image, a real name) is treated on its own terms.

What are the three risks that live panels carry and synthetic panels do not?

Three risks that shape enterprise privacy reviews: personal data processing (with all associated lawful basis, retention, and transfer obligations), consent management (recruiting, documenting, and honoring participant consent including withdrawal), and re-identification risk (any dataset that is later shared or reused can be joined against other datasets to reveal individuals). Synthetic personas eliminate all three at the source, because no natural person is involved as a data subject.

Personal data processing on live panels requires Article 6 lawful basis (consent, contract, or legitimate interest), Article 13/14 transparency notices, Article 15 to 22 data subject rights (access, rectification, erasure, portability, objection), Article 30 record of processing activities, and Article 44 to 49 cross-border transfer controls if respondents are in a different jurisdiction from the processor.¹ Every one of these is real work that consumes privacy team time on every study.

Consent management on live panels means recruiting participants under a lawful basis (typically consent for research), documenting that consent, allowing withdrawal at any time, and honoring withdrawal by deleting the participant's data from the study. This is operationally hard for longitudinal panels and impossible for studies where the raw data has already been shared with downstream partners.

Re-identification risk on live panels is well documented. Even aggregated survey outputs can be reversed against publicly available data (electoral rolls, credit records, social media, breach dumps) to identify individual respondents, particularly for rare demographic combinations. This is the risk the ICO and EDPB flag most aggressively in their anonymisation guidance.³⁴

All three risks trace back to one root cause: real people were involved as data subjects. Synthetic personas remove the root cause.

What happens under a data-subject access request?

Nothing, because there is no data subject. Under GDPR a data-subject access request under Article 15 can be made by any identified or identifiable natural person about data relating to them. A synthetic persona is not a natural person, and no real individual has data in the panel. A DSAR routed to a synthetic research platform about persona data therefore has no responsive material. The platform still has to handle the request under its own account-level obligations, but the study data itself is out of scope.

This is one of the practical operational benefits that privacy teams recognize immediately. Live panels have to build and maintain a DSAR workflow that can locate and produce all data relating to a requesting individual across current and historical studies, including derivatives and downstream shares. Synthetic panels do not, because the query returns null by construction.

The caveat is scope discipline. The platform still processes personal data at the account level (research users, billing contacts, support tickets) and those are in scope for standard DSAR obligations. What is out of scope is the study data itself, which is where the operational cost of DSAR compliance normally lives.

Is there any residual privacy risk to manage?

Yes, and pretending otherwise would be irresponsible. The residual risks are all upstream or downstream of the persona layer: research users' account data, any client-supplied stimulus containing personal data, any custom data uploads used to steer a study, and the operational security of the platform itself. Each has an established treatment; none is unique to synthetic research.

Account-level personal data (researcher names, emails, billing information, support interactions) is standard SaaS personal data and is handled under the platform's own privacy policy and processor agreement.

Client-supplied stimulus can carry personal data (a customer testimonial, a named executive quote, a product image of a real person). This is treated the same way any research vendor handles client stimulus: the client remains the controller, the platform is a processor for the duration of the study, and the stimulus is deleted on the standard retention schedule.

Custom data uploads for steering (a client's own segmentation description, a category taxonomy, a competitive brand list) rarely contain personal data but should be reviewed by the client before upload.

Operational security (encryption in transit and at rest, access control, audit logging, breach notification) applies to the platform as a whole, unchanged by the synthetic nature of the study data.

None of these are novel privacy problems and all have well-established treatments in standard vendor procurement.

How does this compare to research using anonymized real-respondent data?

Anonymized real-respondent datasets sit in a legally contested zone. Regulatory guidance from EDPB and ICO increasingly treats 'anonymized' datasets as still personal data if any reasonable means could re-identify individuals, which is often true.³⁴ Synthetic data avoids the debate entirely because there is no source individual to re-identify. That is why synthetic data is being adopted rapidly in regulated industries where the anonymization argument is under active challenge.

The regulatory trend since 2022 has been to raise the bar on what counts as anonymized. EDPB guidance and ICO opinions both emphasize that the standard is 'reasonably likely means' of re-identification, that this standard changes as auxiliary data becomes more available, and that most pseudonymization arrangements do not clear the bar.³⁴ The practical effect is that datasets that were treated as anonymized five years ago are being reclassified as pseudonymized personal data today.

Synthetic data is not affected by that trend because the argument does not rest on de-identification of source records. It rests on the absence of source records entirely. That structural difference is why financial services, healthcare, and public-sector organizations are increasingly commissioning synthetic research for use cases where anonymized real-respondent data would previously have been the default.

ESOMAR's global guideline for research and data analytics addresses synthetic data explicitly and treats it as a distinct category with its own ethical considerations, chiefly around transparency (disclosing that a study used synthetic respondents) and appropriate use (not passing synthetic findings off as human ones).⁶

What should procurement and privacy teams verify before onboarding a synthetic research vendor?

Six items: named sources for the underlying statistical data, documentation that persona generation uses only aggregated data, a data-processing agreement covering account-level personal data, standard security certifications (SOC 2 or ISO 27001), a clear statement on residual personal data flows (stimulus, uploads), and disclosure practice around use of synthetic respondents in published outputs.

Named sources. The vendor should name the statistical office and reference (American Community Survey for the US, Eurostat SILC for the EU, ONS for the UK, and equivalent national offices). Vague references like 'public data' should be pushed back on.

Aggregation documentation. The vendor should be able to state that persona generation uses only aggregated tables (typically published cross-tabs) and does not ingest any respondent-level records from any source.

DPA coverage. A standard processor DPA covering account-level personal data, with the appropriate SCCs or adequacy references for cross-border processing.

Security posture. SOC 2 Type II or ISO 27001 as baseline. Any vendor without one of the two is not enterprise-ready.

Residual data flow disclosure. The vendor should articulate what happens to client-supplied stimulus and custom uploads (retention, access, deletion).

Disclosure practice. The vendor should encourage clients to disclose the use of synthetic respondents in any publicly-shared output, in line with ESOMAR guidance.⁶

All six are answerable in a standard procurement questionnaire. A vendor that struggles to answer any of them is not ready for an enterprise engagement.

Sources

• Regulation (EU) 2016/679 (General Data Protection Regulation) — European Union
• Opinion 05/2014 on Anonymisation Techniques — Article 29 Data Protection Working Party
• EDPB Guidelines on Anonymisation and Pseudonymisation — European Data Protection Board
• ICO Guidance on Anonymisation and Pseudonymisation — UK Information Commissioner's Office
• U.S. Census Bureau: American Community Survey — U.S. Census Bureau
• ESOMAR Global Guideline for Research and Data Analytics — ESOMAR
• AAPOR Standards and Best Practices — American Association for Public Opinion Research