Is It Safe to Use AI for User Research? (Transcripts, Consent, GDPR)

The short answer: yes for themes, no with raw transcripts. AI is genuinely good at clustering patterns across a set of interviews. But a transcript is personal data. Your participant agreed to you, to your team, to your study. They signed nothing for a third-party AI vendor. The GDPR calls this purpose limitation, in Article 5(1)(b). You use the data for what you said you would. And stripping the name is not enough: the employer, the role and the city re-identify the person. There is a clean method. Anonymise the transcript before the AI, and state in your consent form whether you use AI tools.

What a transcript actually holds

A user interview is not a questionnaire. The person talks freely. They describe their work, their tools, their days. Along the way, they drop details you never asked for. Those details pile up fast in the text file.

• Their name, their voice, sometimes their face if the session is recorded.
• Their employer, their role, their team, the size of their organisation.
• Their city, their commute, the time zone of their meetings.
• Their tools, their volumes, their clients, their internal numbers.
• Their health, their family, their money, their opinions — offered unprompted.

That last point deserves a pause. Participants often explain why they work the way they do. A condition that dictates a rhythm. A dependent parent who takes the evenings. A belief mentioned in passing. You never planned to collect any of it. It is in the file anyway, word for word.

Your participant consented to you, not to an AI

Two things share the same name. Keep them apart. On one side, research consent: the promise written on your information sheet. Who will see the data, what for, for how long. On the other, the lawful basis under the GDPR, in Article 6. Many teams run user research on legitimate interests, not on GDPR consent. They are two different instruments.

That distinction changes what follows. If your original lawful basis was consent, the ICO — the UK data protection regulator — describes stricter reuse rules. In short: a genuinely new use needs fresh consent for that new specified purpose. Unless a narrow listed exception applies. If your basis was legitimate interests, the compatibility route stays open. But in both cases, the promise you made to the participant still stands.

Purpose limitation is written into Article 5(1)(b) of the GDPR. Personal data must be collected for purposes that are specified, explicit and legitimate. It must not be further processed in a way incompatible with those purposes. Here is what happens in practice. You collect transcripts to analyse them in-house. Then you route them through a third-party AI tool. That is a further processing operation. It has to be squared with what you originally specified.

The ICO puts the principle in plain language. You must be clear from the outset about why you are collecting the information. And about what you intend to do with it. If you reuse it for a purpose you did not originally expect, the new use must be compatible with the original before you go ahead. The ICO updated this guidance in October 2022. Controllers now need to consider whether a change of purpose requires a new lawful basis. The original basis may not cover the new use.

Where no listed exception applies, the ICO requires a compatibility assessment. The factors it lists speak for themselves here. The link between the old purpose and the new one. The context of collection, in particular your relationship with the person and what they would reasonably expect. The nature of the data, including whether it is special category data. The ICO notes a new purpose is likely incompatible if it is very different or unexpected. “My interview will be fed to a commercial AI model” lands squarely in that box.

Special-category data shows up on its own

Article 9(1) of the GDPR sets a default prohibition. You do not process special categories of personal data, unless an exception applies. The list is precise.

• Racial or ethnic origin.
• Political opinions.
• Religious or philosophical beliefs.
• Trade union membership.
• Genetic data.
• Biometric data processed for the purpose of uniquely identifying a person.
• Data concerning health.
• Data concerning a person's sex life or sexual orientation.

One useful clarification: criminal convictions are not in Article 9. They sit in Article 10. The rest of the list, though, walks into interviews by itself. One participant explains a constraint through an illness. Another justifies a schedule through a family situation. Your study never planned to collect that. The transcript recorded it regardless.

Recordings call for precision, not shortcuts. A capture of a face or a voice is not automatically Article 9 data. Article 9 catches biometric data only when it is processed for the purpose of uniquely identifying a person. A session analysed for UX themes generally does not meet that bar. Three things stay true all the same. The raw recording is still personal data. It is far harder to anonymise than text. And it becomes Article 9 the moment anything downstream does voice or face matching. Practical takeaway: keep recordings out of consumer AI.

Stripping the name does not make a transcript anonymous

The GDPR gives the test in Recital 26. To decide whether a person is identifiable, you must account for all the means reasonably likely to be used. By the controller, or by another person. To identify them directly or indirectly. Singling out counts: isolating someone within a set is enough. So stripping the name settles nothing on its own. The question is whether the remaining detail still singles the person out.

The UK Data Service, the UK's national research data service, says the same thing on method. Removing direct identifiers is the mandatory minimum. Next, you must look at the more disclosive indirect identifiers. Specific dates. Towns and cities. You must also assess whether combinations of indirect identifiers become disclosive. Its worked example of under-anonymisation is striking. A location and a timeframe left intact (“20 minutes from my home in Norwich”) keep the transcript identifying. Even after a first pass of redaction.

Run the maths on a typical case. You strip the name. What remains: product manager, 40-person software vendor, Lyon, previously in a named sector. How many people match that? Often exactly one. Your transcript is not anonymous. It is merely de-named.

The fix: anonymise before you analyse

Good news: thematic analysis does not need identities. The AI looks for recurring patterns in what people say. A blocker, an expectation, a workaround, a word that keeps coming back. The employer's name adds nothing to that. Nor does the city. The themes survive anonymisation perfectly well.

1. 1Decide the AI question before fieldwork, not after the interviews.
2. 2Write it plainly into your consent form.
3. 3Spot the direct identifiers: name, email, phone, participant ID.
4. 4Then handle the indirect ones: employer, role, city, specific dates, distinctive numbers.
5. 5Replace each value with a reversible token, in the browser.
6. 6Keep one consistent pseudonym per participant, across the team and publications.
7. 7Send the model only the anonymised transcript.
8. 8Aggregate where you can, and leave raw recordings out of it.

The UK Data Service stresses the timing. Plan anonymisation early, not after the fact. Doing so allows more constructive conversations with participants. Where their data will be shared, what steps will be taken. Translated for you: settle the AI question before fieldwork. Not once the transcripts are already sitting in a folder.

One thing not to conflate. Anonymising reduces your data-protection exposure. It does not discharge the promise you made to the participant. If you intend to use AI tools, your form has to say so. The two debts are settled separately.

On tools, stay sober and check for yourself. A signed data processing agreement. Terms that exclude training on your data. A known retention period. Take no vendor's word for it — ours included. Read the terms in force at the moment you decide.

That's what ONYRI Sanitize is for. The engine spots the sensitive data in a transcript — name, employer, location, contact details, amounts — and replaces it with reversible tokens before sending. Detection and the mapping stay in your browser. Only anonymized text reaches the model. The themes survive: thematic analysis never needed to know who was speaking. You restore the real values locally for your write-up. One thing we won't do for you: put AI into your consent form.