Privacy and Compliance

The current and authoritative privacy and compliance policy lives in the app help pages. Read it at manage.qualiainterviews.com/help#compliance. It includes our standard UK GDPR Data Processing Addendum. This page is for data protection officers, procurement reviewers and ethics committees, and where it differs from the help, the help is correct.

Summary

Qualia stores interview data on behalf of the account holder. Respondents are not Qualia users; they take part in a single conversation through a link, and are anonymous unless the researcher chooses otherwise.

EU hosting

Switch on EU-only routing in your account to keep all data storage and AI processing inside the EU. This is the right setting for GDPR-strict work. With the button off, you can use a wider range of AI models, with the standard implications for cross-border data transfer.

• EU-only on: data is stored in Amsterdam, the Netherlands. The AI interviewer and audio transcription run on Google Vertex AI and Google Speech-to-Text at EU locations, and the platform refuses to send an EU request to a location that is not in the EU. A model that is not on the EU list cannot serve an EU interview.
• Claude models: Claude, made by Anthropic, runs on Google Vertex AI in both regions. Google does not share prompts or responses with Anthropic.
• EU-only off: data is stored in Virginia, USA.
• Separate regions: each region has its own database. Neither app reads from the other region’s database.

Security of the researcher editor

The editor is the application researchers use at manage.qualiainterviews.com. As of 30 September 2026:

• Every route requires sign-in unless it is on a short list of open routes. A route that is not on the list is refused.
• Each route that names an interview checks that the signed-in person has rights on that interview.
• Who is calling is taken from a verified sign-in token. Nothing the browser sends in a request can change it.
• Respondent text shown to researchers is escaped, and generated reports are sanitised before display, so text in an answer cannot run as code in a researcher’s browser.
• Every response carries HSTS, X-Content-Type-Options nosniff, a Referrer-Policy and X-Frame-Options SAMEORIGIN. A Content Security Policy is sent in report-only mode and is not yet enforced.
• PDF export reads only the application’s own static files and the report content sent to it, never other files on the server or network addresses.
• Data is encrypted in transit and at rest. The database cannot be reached from the internet, and the applications connect to it over TLS 1.3.

Security of the respondent chat

• Only our own sites can embed the interview chat, and it accepts messages only from those same sites.
• Respondents do not create an account or sign in. A researcher who wants one submission per person can give each respondent their own key.
• Server logs record lengths, counts and identifiers. They do not contain what respondents or researchers wrote.

Personal details and safeguarding

• The interviewer asks respondents not to share identifying details, and warns them if they start to.
• A researcher can switch on removal of personal details before storage, at one of three levels. An AI model finds the details and each is replaced with a label such as [NAME], so the original is never saved. It can miss a detail, so treat it as an additional safeguard rather than a guarantee.
• When a respondent may be at risk, the interviewer tells them that the research team will be told, and the interview’s owner and editors receive an email alert. The alert names the interview and session and does not include what the respondent said.

Accessibility

We reviewed the respondent interview pages ourselves against WCAG 2.2 level AA in September 2026. They are partially compliant. Fixes from that review went live on 30 September 2026, and the axe-core checker reported no failures at any stage of an interview afterwards.

The pages have not been independently audited, and we have not yet tested them with screen readers or with disabled respondents. The researcher editor has not been reviewed. A full accessibility statement is to be published at /accessibility.

Data retention and deletion

• Retention periods: each interview can keep its transcripts for 30 days, 90 days, 6 months, 1 year or 2 years after their last activity, or until you delete them. Transcripts past the period are deleted automatically within the hour, and the interview’s owner is emailed a receipt.
• Deleting data yourself: you can delete selected transcripts, whole interviews or your whole account at any time. Closing an account deletes every interview it owns in both regions and removes your address from interviews other people own.
• Every table: a deletion removes each row belonging to what was deleted, wherever it is held: the interview and its saved versions, transcripts, logs, summaries and reports, translations and safeguarding alerts. The platform refuses to delete anything if the database holds a table its list of tables does not cover.
• A written receipt: each deletion runs as a single transaction, and afterwards every table is checked again to confirm nothing still refers to what was deleted. You then receive a receipt listing the number of rows removed from each table, what was kept and why, and what the deletion does not reach.
• What is kept: credit usage records (model names, token counts and dates, without any interview content) and payment records, with names and addresses replaced by one-way codes.
• Backups: deletion does not alter database backups, which roll off within 89 days.

Questions

Email hello@causalmap.app if anything in the policy is unclear, or if you need a Data Processing Agreement for an institutional contract. Our Data Protection Officer is Steve Powell, at the same address.