EU Regulator’s guidelines on Virtual Voice Assistants

Virtual Voice Assistants(VVA) bring a lot of ease to our life by helping us execute tasks without having to manually press a button or key in some information. They are run by voice activation, eg: Google Assistant, Siri, Alexa, Cortana and the like.

This involves processing of Personal Data and even Sensitive Personal Data(voice — biometric information).

The EU data protection regulator(EDPB) has published guidelines to the creators, integrators of these VVAs.

Some challenges and risks in using VVAs are

1. Some VVAs require user account registration, while some allow guest use.

2. More than one person may use the same VVA

3. The VVA may be present in a location where there is a lot of background noise, so location(deduced data) can be inferred.

4. User authentication may involve the user to give some key/known value, but in presence of other people in the environment, they may not be able to tell out the confidential key/value to the VVA

5. Third party integrations as part of VVA open the door for more use but bring in more risks eg. banking application integration can cause threat of unauthorised money transfers if authentication (mostly by voice) is not done carefully

6. Processing of biometric information (voice)

7. No displays in most of the VVA systems(eg. Google home, Alexa devices)

8. Ability for users to access the data, rectify incorrect information, delete their history could be challenging in #7 type of uses.

9. Human review may be needed to fine tune the model

10. Being able to deduce information about the user based on the type of queries, thereby discrimination and bias.

The guideline document has about 35 pages. But here’s the summary of the points for the “quick readers” like me.

1. Transparency should be provided to the user on involved parties and their roles. If we integrate VVA into our application, we are the data controllers because we decide to provision the service.
   2. Have to provide the ability to re-listen to consent gaining statements, if we try to gain consent via vocal confirmations/statements.
   3. Separate section in privacy policy have to be incorporated regarding use of VVAs
   4. State changes in the VVA devices must be available in visual and acoustic form at least(eg. mute, listening, sleep etc)
   5. Information about processing must be in line with Article 12 of GDPR
   6. Information provided to user must contain information on derived information such as music in the background, pets etc and how it is used / not used in the processing
   7. No consent(acc. to ePrivacy law) is required for executing user request.
   8. ePrivacy + GDPR is applicable
   9. Using the existing/collected data for improving the service, fixing errors etc cannot rely on Performance of Contract. Must get consent.
   10. Storage/retention should be decided based on type, category and amount of data collected/used.
   11. Providing user the option to delete their history does not remove the data minimisation responsibility from the Controller. Default retention period must be defined.
   12. Must apply mitigation measure to reduce the re-identification risk to an acceptable threshold. Models used should not restrict Controller’s/processor’s ability to stop processing on withdrawal of consent nor from facilitating data subject rights.
   13. When consent is withdrawn, data of that user used for training need not be deleted but measures should be taken to mitigate risk of re-identification.
   14. Avoid making general statement on degradation of service if personal data is deleted, but must explain it clearly and in detail.
   15. Once transactional processing is completed, delete the personal data(voice statement) unless there is another lawful basis to retain it.
   16. If Controller or Processor discovers that data is being stored mistakenly, delete it immediately.
   17. User authentication is key to data confidentiality in the transaction especially in multi user environment.
   18. Software vulnerability management must be done.
   19. Human review must involve only anonymous data, and if involving third parties, contracts should insist on non re-identification.
   20. Instead of waiting for activation word by processing all voices in the premise, that is, processing voice biometric constantly(always listening), let the user say “identify me” or let the software say “do you wish to be identified”.
   21. Store voice templates in local device & not in remote servers.
   22. ISO 24745 is recommended for biometric template (voice template) protection.
   23. Background noise filtering should be done to avoid processing situational data (eg. ability to identify location from the noise).
   24. DPIA must be done, Records of Processing Activities(similar to Activity Register) must be present, consent proof should be maintained (consent can be take in the form of voice also)
   25. Must allow users to exercise their rights. This ability must be made known to user on first use/access.
   26. Provision of a self service tool for exercising their right is recommended especially if the device has no display system.
   27. The right of access(similar to RTI) should not be used to counter / to get around the principles of minimisation and data retention.
   28. Security measures should be adopted for the processing of the data in all stages of processing.