GDPR questions to ask any AI sales training vendor (and what good answers sound like)

Procurement asks for a SOC badge. Legal asks for a DPA. Enablement asks when the buyer can interrupt. Security asks where the audio goes. AI sales training sits in the overlap: voice, transcripts, playbooks, model providers, and scores that look like people data even when they are coaching evidence.

This article is a practical question list for vendor diligence under GDPR and Swiss FADP, with a short note on EU AI Act Article 50 transparency duties for conversational AI. It is not legal advice. It is not a certification. Your counsel owns the contract. Use it to stop accepting slideware answers.

Public Kulissa references for the same topics: /security, /privacy, /dpa, /ai-transparency, /subprocessors.

Why AI roleplay triggers privacy review

A typical session includes:

• Learner identity and organisation membership
• Voice audio and derived transcript
• Customer-provided playbook content (which may contain personal data if someone pasted it carelessly)
• Model prompts and completions needed to run the buyer and the score
• Rubric outputs that refer to a named employee

That mix is why "we are just a training toy" fails diligence. Treat it like a system that processes personal data for a business customer, because that is what enterprise buyers are buying.

Controller vs processor (get this straight first)

In a standard B2B deployment:

• The customer organisation decides why employees practice, which scenarios exist, and how scores are used in coaching. That organisation is typically the controller for learner data.
• The vendor processes audio, transcripts, and related metadata to provide the service. That vendor is typically the processor for that customer content.

If a vendor claims to be controller for your employees' practice data by default, ask why. There are legitimate consumer products where the individual is the customer. Enterprise training usually expects an Article 28-style processor relationship (and the Swiss FADP analogue). Kulissa's DPA framing is published at /dpa.

Separate the website and Maya demo from the customer workspace. Public demo visitors and marketing leads are a different processing story than employee rehearsal inside a paid tenant. Do not let a vendor blur them in the questionnaire.

Voice is not "just another field"

Audio is biometric-adjacent in the way security teams think, even when you are not building a voiceprint product. Ask:

• Is audio stored, for how long, and in what regions?
• Who can replay it (learner, manager, vendor support)?
• Is retention configurable?
• Are transcripts the primary coaching artifact so audio can be minimized?
• Are model providers allowed to train on your audio or transcripts?

Good answers are specific. "Industry standard encryption" without retention and access detail is not an answer. Kulissa's privacy and security pages are the starting public packet: /privacy, /security.

Swiss FADP alongside GDPR

If you have Swiss entities, Swiss users, or Swiss customer commitments, ask vendors to map GDPR answers to FADP explicitly. Controller/processor language has corresponding meaning; data subject rights routes should be clear; cross-border transfer tools should be named. A GDPR-only appendix with "Switzerland TBD" is a delay waiting to happen. Kulissa documents FADP alongside GDPR in /privacy and /dpa.

EU AI Act Article 50, in plain terms

Article 50 concerns transparency obligations so people know they are interacting with AI in relevant cases. For voice buyers that sound human, disclosure matters. Product surfaces should identify the counterpart as AI. Public demos should not imply a human is on the line.

Ask vendors:

• Where is the disclosure shown before and during a session?
• How are managers and learners told scores are AI-assisted coaching evidence, not automated HR decisions?
• What prohibited uses exist if someone tries to turn practice scores into sole-basis employment decisions?

Kulissa's public position: /ai-transparency. This is still not legal advice; it is product transparency you should demand from any conversational training vendor.

Training data and subprocessors

The scary sentence in every AI RFP is "do you train on our data?" Demand a precise reply:

• Customer content used to produce the next turn or score for that request: expected.
• Customer content used to train the vendor's own models: usually unacceptable for enterprise coaching data unless separately contracted.
• Provider training: require contractual no-train commitments where offered, and name the providers.

Then open the subprocessor list. Names, roles, and update mechanics matter more than a logo wall. Kulissa publishes /subprocessors and commits to notice mechanics in the DPA.

Twelve vendor questions (use verbatim)

1. Who is controller and who is processor for employee audio, transcripts, and scores in a paid workspace?
2. Will you sign a GDPR Article 28 / Swiss FADP processing contract, and is a public DPA URL available for review before redlines?
3. Where is personal data stored and processed (regions), and can residency be constrained for our tenant?
4. What is the retention period for audio vs transcripts vs scores, and can we shorten it?
5. Who can access session content inside our org and inside your company (support, engineering, success)?
6. List subprocessors that touch prompts, audio, transcripts, or embeddings, with change-notification terms.
7. Do you or your model providers train on our Customer Content? Quote the contract language.
8. How do you handle data subject requests (access, deletion) when we are controller?
9. How is AI interaction disclosed to users (Article 50-style transparency), especially for voice?
10. What bans exist on using scores as sole basis for hiring, firing, or promotion decisions?
11. How do you prevent prompt leakage across tenants, and what isolation model do you claim?
12. What is the incident notification timeline, and who is on the email path?

Score answers as specific, vague, or evasive. Evasive on training and subprocessors is usually disqualifying for regulated buyers.

How this fits a roleplay bake-off

Run privacy in parallel with product, not after the CRO falls in love with a demo. The AI sales roleplay software buyer's guide covers capability scoring and landscape naming. Privacy can kill a first-place product score overnight; plan for that.

Bring your own playbook excerpt to the demo, but scrub personal data from past emails before you upload anything to a vendor tenant. Vendors should also warn you not to paste unnecessary personal data into scenarios. That warning is a positive signal.

What "good" looks like in writing

A strong vendor packet usually includes:

• Security overview with encryption, access control, and auth basics (/security as an example shape)
• Privacy notice that names GDPR and FADP where relevant (/privacy)
• DPA with subprocessors and international transfer language (/dpa, /subprocessors)
• AI transparency note for conversational systems (/ai-transparency)
• Acceptable use limits that forbid abusive or deceptive uses

Bad packets bury training rights in a linked TOU nobody reads, or point to a subprocessor email alias with no list.

Practical tips for enablement owners

You do not need to become privacy counsel. You do need to:

• Stop uploading real customer contact lists into scenario builders
• Prefer fictional personas even when industry context is real
• Treat practice scores as coaching evidence in manager guidance
• Involve security early if voice leaves your region
• Keep the bake-off narrow so you are not scattering personal data across five vendors

Forgetting science and ramp pressure still matter. Bridge Group 2026 and ATD/Gartner numbers explain why teams buy these tools. They do not excuse skipping diligence. Skill systems that ignore privacy get blocked at the finish line.

Special cases: works councils and co-determination

In some European contexts, employee monitoring and recording require deeper consultation. Even a training tool can trigger questions if audio is stored and managers review scores. Bring employee relations into the conversation early when your footprint includes those jurisdictions. Surprises mid-pilot create distrust that no model quality can repair.

Provide a one-page description of purpose limitation: coaching readiness, not covert surveillance. State access controls. State retention. State that customer personal data is banned from practice prompts. That page will do more work than a generic AI ethics brochure.

Prompt logs and shadow copies

Ask vendors whether prompts, model logs, and temporary caches can contain session content, and how long those shadows live. Many AI stacks have more copies than the primary database table. Your questionnaire should include:

26. Are prompts logged? Where, by whom, for how long?
27. Can vendor staff access customer transcripts in support workflows?
28. Is support access audited?
29. Are there separate environments for production and model evaluation?

If vendor staff can open transcripts to debug, require contractual confidentiality and a break-glass process. Debugging convenience is not a blank badge.

DPIA triggers for enablement tools

A data protection impact assessment may be appropriate when you process voice at scale, score employees, or combine practice data with HR systems. Your counsel decides. Your job as buyer is to supply accurate system description. Vendors who cannot support a DPIA questionnaire with concrete answers are not ready for cautious enterprises.

Practical timeline for a privacy-safe pilot

Week 0: questionnaire sent, DPA draft requested.
Week 1: architecture review meeting with security.
Week 2: residual risks documented, employee notice drafted.
Week 3: limited pod enabled with retention set deliberately.
Week 4: access review and deletion test performed on a dummy user.

Skipping the deletion test is how you discover restore problems during a real offboarding. Test it while everyone is calm.

Buying AI roleplay without a privacy packet is how teams create a second incident response stream inside enablement. Treat the questionnaire in this article as a gate, not as paperwork to skim after the champion falls in love with a demo voice. Require written answers on roles, subprocessors, training use of customer content, retention, deletion, and staff access to transcripts. Run a deletion test on a dummy user before any real cohort starts. Tell employees what is recorded and why, especially when scores will be visible to managers. Keep real customer personal data out of practice prompts even when agents and reps are tempted to paste tickets for realism. Realism comes from patterned scenarios, not from leaking production PII into a vendor workspace. If a vendor markets itself as automatically GDPR compliant without artifacts, walk. If a vendor is small and honest about certification status while providing a clear data map, you can evaluate residual risk like an adult. Kulissa publishes stack and posture details on the security page and does not use customer data to train models; still ask every vendor, including us, to show the same receipts in writing. Privacy is part of readiness. A team that rehearses brilliantly on a careless stack has simply moved the failure mode from the call to the audit.

Write the answers down, attach them to the pilot brief, and refuse to start audio capture until the critical rows are green.

Sources

• EU GDPR (Regulation 2016/679), especially controller/processor duties and Article 28 processing contracts
• Swiss Federal Act on Data Protection (FADP / nDSG)
• EU AI Act transparency duties (Article 50) as commonly applied to conversational AI disclosures
• Kulissa public documents: /security, /privacy, /dpa, /ai-transparency, /subprocessors
• The Bridge Group, AE Models, Motions and Metrics 2026 (context for why teams buy training systems; not a privacy authority)

FAQ

Is this legal advice?

No. It is a diligence checklist for commercial and security conversations. Have qualified counsel review contracts and your risk profile.

Do we need a DPA for a short pilot?

If personal data of employees will be processed, treat the pilot like production for contract basics. A public DPA URL plus a short order form reference is common; your counsel may still want a countersign.

Are practice scores "profiling" under GDPR?

They can involve evaluation of individuals. That is one reason vendors and customers should ban sole-basis employment decisions from AI scores and keep human oversight. Ask for explicit product and contract language.

What is different about voice versus text roleplay?

Audio increases sensitivity, storage, access, and retention questions. Text-only tools still process personal data, but voice widens the review.

Where should we start with Kulissa specifically?

Read /privacy, /dpa, /subprocessors, /security, and /ai-transparency, then send remaining questions to hello@kulissa.com with a [Legal] subject. Product capability shopping stays on /compare and the buyer's guide.