Data Privacy in Synthetic Market Research: Key Checks
Review source permissions, personal data, access, providers, retention and transfers before a synthetic study, with facts from Sapien’s published privacy policy.

Data privacy in synthetic market research starts with the information supplied to the study. Simulated responses do not make real customer inputs anonymous. Identify what the question needs, who may receive it, how it will be processed and what happens to the material afterward. Use the project’s actual arrangements to answer those questions.
Using a simulated audience changes how a study gathers reactions. It does not, by itself, decide whether the information supplied to the study is appropriate to share or how it should be handled. A practical review starts with the material the project needs, where it will go and who will use the result.
This guide explains the questions to resolve and what our public policy says about Sapien. The answers for a particular project should be reflected in the arrangements agreed for that work.
Example: preparing customer data for a delivery study
Vale is a hypothetical homewares retailer comparing delivery offers. It has purchase summaries, support transcripts and an order spreadsheet with customer names and addresses. The team wants to compare a more predictable delivery window across buyer situations.
The study may need delivery constraints, buying frequency and current alternatives. It may not need names, phone numbers, full addresses or order IDs. Start with the decision to identify useful context instead of copying every export field.
Prepare material for the work. A purchase summary and reviewed excerpts may answer more directly than a full database. Read free text too: transcripts can identify someone through names, unusual events or sensitive details after obvious contact columns are removed.
Check permission for the intended use and sharing. An agency should confirm that with its client. Being able to open a document does not decide how another service may process it.
A study data checklist to complete before transfer
Write down the project’s answers before transferring customer material. Keep the checklist with the study brief so everyone reviews the same files, recipients and retention terms.
Part of the arrangement | Question to settle |
|---|---|
Source and use | What are the original files, who can supply them and what permits the proposed use? |
Minimum detail | Which attributes does the choice need? Could a summary or broader group answer the question? |
Processing | Who can access the input, which services process it and which processing locations apply? |
Retention | What stays available, for how long, and what happens to working copies and backups? |
Reporting | Who receives detailed material and what can appear in the wider readout? |
Website data and study data have different roles
Our privacy policy, effective October 13, 2026, identifies Sapien as a trade name of Outrove Inc. It covers account information, information submitted through forms and communications, technical and usage information, and business contact information supplied by our visitor-identification provider.
For that policy data, Outrove is the controller. The policy separately states that when customers upload information about their own respondents or contacts, Sapien processes it on their behalf as a processor, while the customer is the controller.
A demo requester differs from a person described in a customer research file. For Vale, review the actual proposed material, processing purpose and who is authorized to supply it.
Agree the project arrangements before transferring that material. Where a data-processing agreement or a client approval is required, a general website notice does not replace it. The relevant documents should describe the work being done and the responsibilities attached to it.
“Synthetic” does not mean every input is anonymous
A simulated answer differs from an answer collected from a person. Its supporting information can still concern real people. Removing a name may leave someone identifiable through other details.
The UK Information Commissioner’s Office explains that effective anonymization depends on people no longer being identifiable, including through information combined with other sources. Its anonymization guidance distinguishes this from pseudonymization, where personal data remains personal data. These are context-dependent judgments; the ICO also flags its current guidance as under review following legislative changes.
Replacing names with numbers does not resolve an excerpt about a recognizable person and incident. Review the full material and intended use. If less identifying detail answers the question, prepare the smaller source set instead of treating “synthetic” as an exemption.
Ask about the actual processing path
Ask who can access project inputs and outputs, which services process them, where processing occurs and what happens when the work ends. Tie the answers to the data and workflow you propose to use.
Our policy identifies service providers used to operate Sapien, including Google, Vercel, PostHog, RB2B, scheduling and email providers. It describes PostHog site analytics and privacy-protected session recordings, with form and input values masked, and RB2B business-visitor identification. Those descriptions should not be read as a complete technical map of how a particular research file is processed.
If your procurement decision depends on a particular control, request evidence for that control and its scope. Examples include the handling of uploaded research by model providers, access restrictions, security assurance reports and any required regional processing arrangement. A claim about one provider or part of a service should not be extended to the entire workflow.
Our public policy states that we use reasonable safeguards. It does not establish a security certification or specify an encryption architecture. Its statement that we do not sell personal information also answers a different question from whether a particular input may be retained or used by a model provider. Resolve the question your project actually depends on in the applicable terms and supporting documentation.
Retention and location need specific agreements
The policy says we retain information for as long as needed to provide the service, maintain legitimate business records and comply with law. That is a retention principle, rather than a fixed deletion date for every research artifact.
For a study, agree which inputs, working copies and outputs need to remain available and for how long. If the project requires deletion by a particular date, establish the applicable arrangement, including the treatment of backups and legally required records. The same review should cover copies retained by your own team and anyone receiving the results.
Sapien is based in the United States, and the policy says service providers may process data in the US and other countries. It describes safeguards for relevant international transfers, including Standard Contractual Clauses and the UK Addendum in providers' processing terms, or another lawful transfer mechanism. A team with a regional hosting requirement should resolve that requirement specifically before sharing data.
The privacy review continues into the report
Reports can reveal details removed during preparation. A memorable quotation or tiny group may make someone recognizable despite aggregated results. Decide who needs detailed material and what can appear in a wider presentation.
Label simulated reactions as simulated. Do not present a generated interview excerpt as a real customer quotation. Keep the source and permitted use with genuine background quotes. Make the two sources easy to distinguish.
Vale's useful outcome is a study with enough context to compare the delivery offers, supported by an agreed treatment of its source material. The review should make the research usable, with clear responsibilities for the information it actually needs.
For questions about Sapien’s privacy policy or a privacy request, contact saif@asksapien.ai. Describe the data types you propose to share, their intended use and any procurement requirement, such as a deletion deadline or processing region. That gives the discussion a specific project to review.


