“Legitimate Interests” for AI Training? Remember the common law of confidence.

There is a current debate as to whether “legitimate interests” can be reliably used as a lawful basis by a controller when using personal data to train/test AI algorithms/systems and when AI systems are deployed.

This blog explains how the common law of confidence and two recent CJEU decisions work together to challenge this assumption.

The first half of the blog explains why “legitimate interests” can work as a lawful basis for AI training/testing in some instances.  In the second half, I explain why, because of confidentiality constraints, “legitimate interests” does not work in general.

What is surprising is that reference to the common law of confidence is absent from the ICO’s guidance on AI.

When does legitimate interest work

Suppose a controller wants to explore the use of AI to make “efficiency savings” (e.g. a euphemism for reducing staff numbers) or to “enhance customer experience” (e.g. making it harder for a customer with a difficult problem to talk to a human).

Suppose further, nothing has changed in the controller’s processing environment except the desire to process its existing collection of personal data in order to explore the potential use of AI (i.e. “proof of concept” processing).

There are four key processing assumptions I am making in during this proof of concept phase; these are:

  • the controller ensures that “there is no impact on any data subject of any kind whatsoever”;
  • there are no transfers outside the UK and established security/accountability standards are maintained throughout the testing;
  • no special category of personal data or criminal offence personal data are processed (as this would involve speculating about the Article.9 (UK_GDPR) or Schedule.1 (DPA2018) requirements); and
  • personal data relating to those who have objected to marketing are excluded, if direct marketing is a main objective of the deployment phase of AI.

The CJEU has determined (twice) that a commercial interest of the controller is indeed a legitimate interest (see references). This means that the controller can rely on the legitimate interests lawful basis to assess whether it can improve services and profitability using AI.  In DP terms the “processing is necessary for the purposes of the legitimate interests pursued by the controller (the first part of the balancing test required by A.6(1)(f)).

At the same time, there is little risk that “such interests are overridden by the interests … of the data subject” because there is no impact on any data subject.  Put simply, the counter-balancing risk of an overriding interest on the part of the data subject almost vanishes because of the application of the first bullet-point assumption above.

Second there is no need to do a DPIA (A.35).  A DPIA is only needed when the processing “is likely to result in a high risk to the rights and freedoms of natural persons”.   However, as the controller has determined that its own AI proof of concept processing has no impact on the data subject, there is no high risk to any data subject.  A DPIA is unnecessary.

Third, there is no need to worry about the automated decision making provisions (A.22).  These apply when “a decision based solely on automated processing, including profiling… produces legal effects concerning him or her or similarly significantly affects him or her”.  There again, the controller has determined at the outset the proof of concept processing presents no legal/significant effects on any data subject. So no worries then.

Fourth, there are no incompatibility issues (as per A.6(4) and A.5(1)(b)) as the processing for a further purpose is very similar to the purpose of obtaining (e.g. the exploration of how existing services, known to the data subject can be improved by processing personal data using AI techniques).

This is because there is a strong “link between the purposes for which the personal data have been collected and the purposes of the intended further processing” (the test in A.6(4)(a)). Additionally there is no change in “the relationship between data subjects and controller” (test in A.6(4)(b)),  and “the possible consequences of the intended further processing for data subjects” are negated (test in A.6(4)(d)) because there is no impact on any data subject.

Fifth, there should be no problems concerning the data subject’s right to object (A.21).  This arises because the data subject has to present “grounds in relation to his or her particular situation”, and these grounds are going to be difficult to establish if the processing has no impact on any data subject.

Finally, the Transparency/Privacy Notice might need adjusting, but not if it already says something like “we additionally use your personal data to develop or improve our services to you”.

The above analysis works for the proof of concept phase when using ordinary personal data which, as we shall see, are not subject to an obligation of confidence.

Obviously the provisions that are ignored during the testing phase must be considered before the processing moves beyond the proof of concept phase.  Indeed, there would be no point proceeding with any proof of concept processing, if there were to be no lawful basis for the deployment phase itself.

The common law of confidence

Suppose you tell me something in confidence. What are you expecting me to do after you have told me?  Can I use or disclose this confidential information for my benefit without your consent?

In general, a duty of confidence can arise either expressly or by implication if:

  • the content of the information possesses the “essence” of confidentiality (e.g. something personal or sensitive for whatever reason), and
  • the information has been collected in circumstances where confidentiality can be expected (e.g. in a closed room where you and your GP/solicitor discuss your medical/legal options).

Not all the information imparted is subject to an obligation of confidence, and in general, there needs to be a case-by-case analysis of the specific circumstances surrounding the transfer of information.  Confidential details can easily lose any claim to confidentiality (e.g. if overheard as part of a noisy argument or displayed on a laptop screen when travelling on a crowded train).

In summary, your financial personal data are usually confidential, but not if financial details have been made public on Facebook.  Your medical record is confidential, but your name and address contained in that record might not be confidential.  By contrast, names and addresses of those in witness protection are obviously confidential.

In general, a duty of confidence often arises with the following personal data: financial affairs, tax, benefits, means testing, grants, health, social work, education and policing.  Employee personal data are often confidential (e.g. Occupational Health or disciplinary mechanisms) but your pay grade is unlikely to be confidential (as pay grades are made public in job adverts).

Indeed, special category of personal data and criminal offence personal data are often good examples of confidential personal data.

A breach of confidence

A breach of confidence can arise by a use or disclosure of confidential details for another purpose.  “Disclosure” is widely recognised as a cause of a breach of confidence (e.g. a GP who discusses your medical records in the pub), however much case law relates to “use”.

This historic use case-law often related to the protection of Intellectual Property.  For example, suppose you are a Victorian widget manufacturer (circa 1880).  I come to you with a “super-widget” design and once you have satisfied all my orders, you begin producing a “super-duper widget”, based on my design, in competition with me.  Perhaps you can improve my design – who knows.

The point is that you could only have produced your “super-duper widget” by using the confidential design for my super-widget.  You have not disclosed any confidential information you received, rather you used that information for your benefit instead.

Coming back to data protection, “use” and “disclosure” are “processing” operations.  Hence to use or disclose confidential personal data for other purposes can involve a breach of confidence.

Of course, confidentiality is not an absolute. There are several legal requirements (e.g. Court Order, statutory demand) or public interest reasons (e.g. law enforcement request, protecting children or the vulnerable) where one can lawfully set aside an obligation of confidence in the absence of consent.

However, if these two do not apply, then the only justification for setting aside an obligation of confidence is when the data subject has consented to the further use or disclosure.

This includes using existing confidential personal data for AI training purposes  (and indeed in any deployment phase).

Consequences (CJEU)

There are two decisions of the CJEU that support the above argument. CJEU case 621/22, which concluded that a controller can rely on the legitimate interests lawful basis for commercial reasons so long as the controller ”having regard to all the relevant circumstances, that the interests or fundamental freedoms and rights of those users [a reference to the interests of the data subject] do not override that legitimate interest of the controller”.

In my view, the interests of the data subject in maintaining his or her confidentiality are very likely to override the legitimate interests of the controller who sets confidentiality aside for its own commercial interests.

The relevant conclusion of CJEU case 621/22 added that whilst the legitimate interest pursued by that controller do not require “that such an interest be determined by law, it requires that the alleged legitimate interest be lawful”.

In my view this means that in the UK, the reference to a lawful legitimate interest includes the consideration of the application of the common law of confidence to that legitimate interest.

Concluding comment

It is likely to be difficult to rely on “legitimate interests” as the correct lawful basis if confidential personal data, already processed by a controller, are further used in AI proof of concept processing and in later deployment.

This is because it is usually in the overriding legitimate interest of the data subject to preserve his or her own confidentiality over the commercial interests of the controllers that happen to supply services to the data subject.

Confidentiality constraints, in my view, push one in the direction of consent as the correct lawful basis.

Winter Data Protection Courses

Amberhawk is holding our first session on the changes to the UK’s data protection regime arising from the Data (Use and Access) Bill, by Zoom, on Tuesday January 28th 2025: (10.00am-4.30pm;  £275+VAT).

The following BCS Practitioner or Foundation courses can be attended in person, or via Zoom, or as a mixture (i.e. part Zoom, part attendance just in case “stuff happens on the day”).

  • Data Protection PRACTITIONER Course: London on January 20-24 (5 days: Monday to Friday: 9.30am to 5.30pm) and on March 17 to March 21 (same timings).
  • Data Protection FOUNDATION Course: London on March 11-13 (Tuesday to Thursday, 3 days: 9.45am to 5.00pm).
  • Remember our specialist DP qualification for those in Education.

More details on the Amberhawk website: www.amberhawk.com  or email info@amberhawk.com.

References

CJEU Case C-252/21  (involving Facebook/Meta)

CJEU Case C‑621/22 (involving Koninklijke Nederlandse Lawn Tennisbond)

ICO’s lawfulness guidance on AI: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/how-do-we-ensure-lawfulness-in-ai/#purposes

Leave a Reply

Your email address will not be published. Required fields are marked *

Share this blog post...

Further reading...