After the consultation version appeared in April 2021, the European umbrella of privacy regulators (EDPB) adopted the final version of their Guidelines on Virtual Voice Assistants (hereafter RSA) during this summer. This guideline explains how parties offering (or developing) voice assistants should handle the personal data they process in the process. In this article we discuss the most important and salient points of this guideline.
Voice is a relatively young channel with many unexplored opportunities for marketing (among other things). The rules were there before the channel, so applying the rules requires a bit more interpretation. The EDPB therefore provides these guidelines so developers and marketers know how to apply the legal framework to it.
To begin with, it is good to know what rules to consider. Recording someone's voice is considered processing personal data which makes the AVG applicable and thus you must have a valid basis. In addition, the data (like cookies) is collected from a device owned by a user. This also makes the ePrivacy Directive (transposed into the Telecommunications Act) applicable. According to the EDPB, this means that the main rule for RSAs is that consent is required to process the personal data. You can read further below in which cases an exception to the main rule may apply.
Roles
Both the user and the parties involved should have a clear understanding of who processes what data. From this it is possible to find out who are (sub)processors and who are processors. After all, the controller is the one who must ensure valid consent and inform users. The tricky thing about this is that the roles may differ for each processing operation, and the roles may be intertwined. Indeed, a designer of the RSA will initially be qualified as the controller because they determine the purpose of its use but in some situations the designer will also qualify as a processor. For example, when they collect data on behalf of the developer of the application in which the RSA is embedded. This will often involve joint responsibility.
In understanding the roles, we can distinguish between the process that takes place between the user and the RSA and the technical process that takes place at the back end between the provider of an RSA, the designer of an RSA and (for example) the advertiser.
Users
It is also good to categorize the groups of users:
- Registered users (Interactors with an account)
- Unregistered users (Interactors without an account)
- Unintended users (Persons who interact by mistake)
Depending on the type of user, you need to take different steps to AVG-proof this data. According to the EDPB, the greatest danger lies in processing personal data of users who accidentally activate the RSA. This is because this data is stored without the user's knowledge or consent. It is therefore emphasized to the designers of an RSA that great care is taken to protect these users from unintentional processing of their personal data.
Also, according to the EDPB, it is important for a user to know what state the RSA is in. So is it activated, switched off or on standby. Indeed, this makes it verifiable for the user that voice is being recorded by the RSA. These are functionalities that lie with the RSA provider, but the person deploying the RSA may need to inquire about them.
As a data controller, you must ensure that the user is properly informed. So this can be an advertiser. This is best done at the moment an account is created for an environment within which an RSA can be used. For example, as an advertiser you can do this within its own application. But with a Google Home, this responsibility will lie with Google.
To ensure that a user is well informed, the EDPB provides a number of recommendations, the following are relevant to an advertiser:
Supplement your privacy statement with a dependent section that includes information about the RSA.
- In it, name the exact data that is collected, what processing takes place and for what purpose. It is also recommended to mention what audio is actually recorded. For example, consider ambient noise from other people.
Make it clear which parties are processing the personal data and why.
- It is important that it is clear to the user which parties in the chain actually hold the data.
Purpose of processing
Another important aspect is determining the purpose for which personal data are collected. The EDPB discusses among other of these "ordinary" purposes at an RSA:
1. Carrying out a request
The ePrivacy Directive has an exception to the main rule of consent. When the processing of personal data is strictly necessary to fulfill a request from the user, you do not need consent. A user request here means, for example, giving the RSA an order, such as: ''Hey Google, what is my bank balance''. In this case, the bank and Google process the data to carry out the user's instruction and no consent is needed. In many cases, an account will have been created and linked to, for example, the bank data. According to the EDPB, it is therefore possible to apply this exception to these registered users. Indeed, when a user registers with an RSA, a contractual relationship is created that simply aims to execute requests from the user.
Please note accepting terms and conditions when creating an account is not the same as giving permission for your personal data to be processed. So, for example, you cannot assume that if the terms and conditions for an application have been accepted, the user has also given consent to the use of an RSA.
Profiling for personalized content and ads
When using an RSA, it is also possible to return content that is personally relevant to the user. An example is a user who regularly instructs an RSA to display news. Gradually, the RSA can learn what interests the user has and only display relevant news based on those interests. Building such a profile for personalized content, can be an essential (and expected) part of an RSA. But this is certainly not always the case. Factors that come into play are: the nature of the service, the expectations of those involved in the set goals and whether the service can be offered without personalization.
When it comes to registered users, this form of profiling may fall within the contractual relationship established between the user and the RSA provider when the account was created. But again, the question here is: is profiling limited to what is strictly necessary? However, it is still unclear what the EDPB considers necessary in this context.
However, it is clear that according to the EDPB it is not possible to collect personal data for profiling on the basis of the legitimate interest. Indeed, it is not possible to inform the user correctly about the processing of these data on the basis of the legitimate interest and to give them the opportunity to oppose this.
Note that profiling for personalized advertising based on data from an RSA cannot, according to the EDPB, take place without obtaining consent. Indeed, this can never be seen as a request from the end user.
This article previously appeared on the DDMA website.
