10/12/21 – On 25th November 2021, the UK Law Commission published its advice to the Government on smart legal contracts. The advice expands on the UK Jurisdiction Taskforce’s legal statement on cryptoasset and smart contracts – see my post here.
The Law Commission concludes that current legal principles can be applied to smart contracts in much the same way as traditional contracts, with relatively minor developments required in certain contexts. It does, however, identify two specific problem areas that will require further work: the execution of deeds, and determining the geographical location where smart contracts are formed or breaches are committed (and therefore which jurisdiction’s laws apply), particularly where the smart contract concerns a digital asset.
This article considers some of the key observations and findings set out in the Law Commission’s advice.
1. What is a ‘smart legal contract’?
Considering the generally accepted definition of a smart contract as a computer program which run automatically, in whole or in part, without the need for human intervention, the Law Commission suggests that where a smart contract is used to define and perform legally binding contractual obligations it is helpful to refer to it as a ‘smart legal contract’. The Law Commission then defines a smart legal contract as ‘a legally binding contract in which some or all of the contractual obligations are defined in and/or performed automatically by a computer program’, and divides smart legal contracts into three different types, depending on the role played by the computer program code, i.e. the degree of automation of the performance of the contract:
- Natural language contract with automated performance
- Hybrid contract
- Solely code contract
The Law Commission suggests that: ‘Automation should be considered on a spectrum. Smart legal contracts which involve elements of standard automation, such as payment by way of direct debit, have been in use for many years and are therefore unlikely to give rise to novel legal issues. However, a smart legal contract drafted primarily or solely in code […] is likely to give rise to novel legal questions; the automation in question takes the contract out of the realm of legal familiarity‘.
Although it had originally suggested (in its call for evidence) that a smart legal contract must, by definition, be deployed on a distributed ledger technology (DLT) system, the Law Commission has decided that DLT should not be an essential feature, and that a better approach is for smart legal contracts to be technology neutral.
2. What are the legal issues with smart legal contracts?
As stated, natural language contracts with automated performance via code have been in existence for a long time, and do not raise any new issues. However, where the terms of the contract are written in code, whether partly or wholly, new challenges arise in relation to contract formation, interpretation and remedies.
The Law Commission believes that contract terms expressed in computer code can, and should, be ‘susceptible to contractual interpretation‘. It suggests that the appropriate test should not be the traditional ‘what a reasonable person would understand the (coded) terms to mean, having all the background knowledge’ test, but instead a ‘what a person with knowledge and understanding of code would understand the coded terms to mean’ test – what the Law Commission calls the ‘reasonable coder‘ test. The court should ask what a person with knowledge and understanding of computer code what they understand the coded terms to mean, similar to the way that a court would ask for expert evidence in the case of a contract written in a foreign language.
The Law Commission also suggests that there is an increased risk of disputes during the lifecycle of a smart legal contract, given the likelihood of code performing ways that that the parties did not intend or expect, as well as other risk factors such as inaccurate input data, system upgrades, the code being hacked, and normal bugs and errors. The Law Commission notes that the usual legal remedy of rectification (where the court ‘corrects’ the terms of a contract) may in practice prove difficult to obtain where a computer program runs on an immutable DLT system.
3. How should businesses using smart legal contracts address these issues?
In Appendix 3 of its advice, the Law Commission helpfully provides a (non-exhaustive) list of issues that parties proposing to enter into a smart legal contract may want to consider and provide for in their contract. These include:
- Confirming the role of the code in the contract and, in particular, whether the code is intended to define contractual obligations or just perform the obligations. Where contractual terms are expressed in both natural language and in code, confirming which term takes precedence in the event of a conflict.
- Using natural language aids to help with the interpretation, e.g. a business process document or term sheet, and/or a natural language explanation of the code, or natural language comments within the source code itself. Making it clear that the business process document or other explanation forms parts of the parties’ agreement so that the document or explanation can be used by the court when interpreting the contract.
- To satisfy the Consumer Rights Act 2015 requirement that traders’ written terms are ‘transparent’ (i.e. ‘expressed in plain and intelligible language, and be legible‘) in B2C contracts, providing consumers with a clear and informative explanation of the code in natural language.
- Allocating risk amongst the contracting parties in relation to the smart legal contract-specific risk factors mentioned in the previous section.
- Incorporating a ‘kill-switch’ in the smart legal contract to enable suspension or termination of the performance of the code.
4. The problem areas
The Law Commission considers that further work may be needed to support the use of smart legal contract technology in following areas:
- To be validly executed, the signing of a deed must be witnessed and attested. The Law Commission is unable to see how these requirements could be satisfied for deeds which are wholly or partly defined by code, although it acknowledges the possibility of technology being developed to enable a witness to record in a smart legal contract that they have observed the execution of the deed.
- It may be difficult to determine the jurisdiction and applicable law for some smart legal contracts, particularly where the smart legal contract is defined solely in code or performed via the interaction of two or more computer programs. In addition, digital location, i.e. ascribing real-world locations to digital actions and digital objects, also presents difficulties for smart legal legal contracts, particularly when deployed on DLT system. The Law Commission strongly recommends that parties to smart legal contracts stipulate both their choice of law and jurisdiction.
The Law Commission has agreed to undertake a separate project considering the rules around conflict of laws in the context of emerging technology, including smart legal contracts, which is expected to begin in the middle of 2022.
5. Looking to the future
The Law Commission points out that smart legal contracts are already used to some extent in a number of sectors (including insurance, finance, DeFi, and peer to peer), but have the potential to revolutionise the way businesses engage across all sectors. It anticipates that the market will develop established practices and model clauses that parties can use for their smart legal contracts, and hopes that work in this area will be led by LawtechUK and the UK Jurisdiction Taskforce.
23/10/21 – Back in 2013 The Software Incubator was appointed by Computer Associates as a sales agent to promote and market Computer Associates’ application service automation software, which was deployed by CA’s customers to manage applications across data centres. The software was downloaded by customers directly from Computer Associates’ servers, subject to a perpetual licence which restricted use to a specified territory and a maximum number of authorised users.
The relationship was short lived, and The Software Incubator’s appointment was terminated later in 2013. The Software Incubator claimed compensation from Computer Associates under the Commercial Agents (Council Directive) Regulations 1993 (“UK Regulations”), which provides that a ‘commercial agent shall be entitled to compensation for the damage he suffers as a result of the termination of his relations with his principal’ (Section 17(6)). The UK Regulations define “commercial agent” as a ‘self-employed intermediary who has continuing authority to negotiate the sale or purchase of goods on behalf of another person’, but then does not provide a definition of “goods”. As you have probably already guessed, The Software Incubator and Computer Associates had different views on whether the software promoted by The Software Incubator constituted goods for the purposes of the UK Regulations, and the dispute ended up in court.
In 2018 the Court of Appeal decided, in part, in favour of Computer Associates. The Software Incubator appealed to the Supreme Court, which then referred the issue to the Court of Justice of the European Union (CJEU). In short the question for the CJEU was: Does the the supply of computer software to a customer by electronic means, together with the grant of a perpetual licence, constitute a “sale” of “goods” within the meaning of article 1(2) of the Commercial Agents Directive (Council Directive 86/653/EEC), being the original EU Directive that was implemented by the UK Regulations?
CJEU decision
The CJEU decided that:
- the term “goods” could cover computer software, since software has a commercial value and was capable of forming the subject of a commercial transaction, and it was irrelevant whether the software was supplied on a CD ROM or tangible medium, or by electronic download; and
- the making available of a copy of the computer software and the conclusion of a user licence agreement for that copy which entitles use of the software for an unlimited period, in return for payment of a fee, results in the transfer of the right of ownership of that copy, and therefore constitutes a “sale”.
Accordingly, the supply by Computer Associates of its software to a customer by electronic download, together with the grant of a perpetual licence constituted a “sale of goods” for the purposes of the UK Regulations, entitling The Software Incubator to compensation for termination of its sales agent appointment.
Because the question was referred to the CJEU before Brexit, the CJEU’s decision is binding on the Supreme Court.
Comment
The CJEU decision is clearly good news for sales agents which promote the supply of perpetual software licences, and probably fixed term software licences where the term is at least equal to the software’s expected economic lifespan. Less good news for software vendors, who may want to review existing arrangements with their agents and tread carefully if looking to terminate the relationships. More generally it remains to be seen to what extent the UK courts will have regard to the decision when considering the issue of whether software should be considered to be goods or services (or neither) in other contexts, particularly sale of goods legislation.
Part 1 and Part 2 of the What’s been happening with SCCs? updates have tracked the EU’s and the UK’s progress in developing standard contractual clauses (SCCs) to deal with the transfer of personal data to third countries, i.e. countries that are not considered to have an ‘adequate’ level of data protection, as well as the publication of the new EU SCCs. This update focuses on the UK SCCs.
On 11th August 2021 the ICO launched a consultation on ‘how organisations can continue to protect people’s personal data when it’s transferred outside of the UK‘. As part of the consultation the ICO published its proposal for UK standard contractual clauses in the form of a brand new international data transfer agreement (IDTA), as well as its new Transfer Risk Assessment (TRA) and tool. The ICO is also requesting comments on an update of its existing guidance on international transfers. The consultation closes on 7th October 2021.
All very interesting I’m sure. But is any of this relevant to me?
Short version is that if you’re transferring UK citizens’ personal data to a ‘third country’ (i.e. a country which is not considered by the UK to have ‘adequate’ data protection laws (full list here), then yes. You will need to use one of the transfer mechanisms (or ‘appropriate safeguards‘) set out in Article 46 of the GDPR (now incorporated into UK law as the UK GDPR, as amended). And although the UK GDPR provides for a variety of transfer mechanisms, for most businesses the only practical option in these circumstances will be for both the (UK) data exporter and (third country) data importer to enter into an IDTA, having first completed a Transfer Risk Assessment (TRA).
Bear in mind that for these purposes:
- ‘Transferring’ data includes making data stored in the UK available to be accessed by a data importer in a third country, even on a ‘view-only’ basis.
- Whether the data importer ever does access or otherwise process the data that you transfer is irrelevant.
- Following the invalidation of the EU-U.S. Privacy Shield by the ECJ in its ‘Schrems II’ judgment, the U.S. is now a third country.
Ah, ok. So what do I need to know?
The new IDTA and TRA requirements will not not become law until the end of 2021 or, more likely, spring 2022. Between now and then the situation is a bit of a mess. UK law provides that the old EU SCCs must continue to be used as the Article 46 transfer mechanism, even after 27 September 2021 when they cease to be lawful for new EU cross-border data transfers. Although some commentators have suggested that, in a post-Schrems II world, a better approach is for UK data exporters to use the new EU SCCs until the new IDTA is adopted, my view is that for the time being most UK data exporters should stay compliant with UK law and either make Brexit-required changes to their existing SCCs or, for new transfers, put in place a data transfer agreement based on the old EU SCCs.
The timelines for UK data exporters being legally required to use the new IDTA for international data transfers will be 3 months for new transfers and 21 months for existing transfers, each period running 40 days from the date on which the IDTA is laid before Parliament as a regulation.
Some high-level comments on the IDTA:
- In contrast to the modular new EU SCCs (which will need quite a bit of copying and pasting), the IDTA is a single agreement, made up of four parts:
- Part 1 (Parties and signature) sets out a series of tables which capture the variables, including the status of the parties (i.e. controller, processor etc), details of the proposed data transfers, details of the data to be transferred, purposes of the transfers, and the security requirements. If the IDTA forms part of an MSA or other commercial agreement between the exporter and importer, the MSA can be recorded as a ‘Linked Agreement’.
- Part 2 (Extra Protection Clauses) is optional, but enables the parties to include any additional security, organisational and/or contractual protections that are considered necessary following the TRA.
- Part 3 (Commercial Clauses) is also optional, enabling the parties to include any commercial terms that they have agreed.
- Part 4 (Mandatory Clauses) constitutes the bulk of the IDTA, and sets out the parties’ rights and obligations in relation the data transfers.
- The ICO have done their best to use plain English and avoid legal terminology, and generally to keep the IDTA as user-friendly as possible. But the IDTA template (excluding guidance notes and Q&A) runs to 43 pages, and putting one in place will require a fair bit of work.
- For organisations putting in place new EU SCCs for EEA-to-third country data transfers, the ICO has helpfully produced a short addendum which, once completed and signed, will enable the EU SCCs to be used also for transfers from the UK.
- In contrast to the new EU SCCs, which need to be reviewed ‘at appropriate intervals’ the IDTA (and associated TRA) should be reviewed annually, which is perhaps overly onerous for low-risk transfers.
- A more detailed analysis of the Mandatory Clauses of the IDTA to follow once the ICO consultation is completed.
And some comments on the TRA:
- The TRA precedent is intended to be use for medium and low risk transfers. High risk transfers, such as transfers to countries with poor human rights records, are likely to require more sophisticated transfer risk assessments. The TRA is not mandatory – data exporters are free to use what form of risk assessment they consider appropriate.
- As with the IDTA, the ICO have done their best to make the TRA accessible and user friendly. It contains numerous, ‘real life’ practical examples showing when transfers may be permitted. It also explains what constitutes high, medium and low risk in the context of international transfers, and (helpfully) confirms that where the risk of harm that the transfer causes to data subjects is minimal then the transfer is permitted by default.
- But the TRA is 49 pages long, and will constitute a significant undertaking for all but the most well-resourced data exporters. And although the ICO recognises the challenge that data exporters face in obtaining information about the legal framework of the data importer’s country, suggesting that information may be available via ‘reports issued by the Foreign Commonwealth and Development Office and charitable organisations‘, the ICO does not address the obvious question why this information cannot be provided by the ICO (and/or appropriate government department), instead suggesting that data exporter may need to obtain ‘expert advice‘.
- On a positive note, and unlike the new EU SCCs, the objective of the TRA is not necessarily to ensure that the legal framework of the data importer’s country is ‘essentially equivalent’, but whether it provides ‘very similar protections’ to those in the UK. The TRA also makes the point that countries which have surveillance regimes may in fact be more legitimate than countries whose lack of surveillance laws may suggest a lack of safeguards.
- The findings from the TRA must be documented to ensure there a record of the assessment. If a data exporter uses its best efforts to complete the TRA, the ICO will take this into account in any regulatory action resulting from a later GDPR breach.
Hmm… 49-page risk assessments and 43-page data transfer agreements. Doesn’t exactly sound ‘agile’?
You’re referring to the comments of the UK culture secretary, Oliver Dowden, who suggested in his article in the FT last February that that the UK can now be more ‘agile’ when it comes to ‘[striking] our own international data partnerships with some of the world’s fastest growing economies’.
If we accept the importance of ensuring a meaningful level of protection for UK citizens’ data when shared with third parties outside the UK then we either have to provide a mechanism which gives organisations the ability to put in place a framework to ensure a meaningful level of protection, or we go down the data localisation route and make it unlawful for personal data to be transferred from the UK to any ‘third country’.
Despite the reservations mentioned above, the ICO have in my view done a good job striking a balance between the need for ‘agility’, and the need to provide meaningful protection of personal data in a world which, for the most part, falls far behind the ‘gold standard’ of EU and now UK data protection. But the elephant in the room remains why the ICO (or appropriate government department) cannot provide UK data exporters carrying out a TRA with guidelines regarding each third country’s legal framework, third-party surveillance rights and safeguards, and their similarity to those in the UK. It will be interesting to see if this is addressed by the consultation.
05/07/21 (updated) – As part of the Trade and Cooperation Agreement the EU and the UK agreed a six-month ‘bridging period’, allowing transfers of personal data from the EEA to the UK to continue freely until 30th June 2021, to give the European Commission enough time to adopt the adequacy decisions which are necessary to allow personal data to continue to flow from the EEA to the UK. (If you’re not sure what I’m talking about, then you catch up here and here.)
Anyway, good news. With a full two days to spare, the Commission formally adopted the adequacy decisions for the UK on 28th June – one for transfers of personal data under the GDPR and the other under the Law Enforcement Directive. As a result personal data continues to flow freely from EEA countries to the UK after the end bridging period.
Unlike the adequacy decisions adopted by the Commission for other third countries, the ones adopted for the UK have ‘sunset clauses’ which means that, unless renewed by the Commission, the decisions automatically expire in four years’ time. Furthermore, the Commission can intervene at any time during the four-year period if it considers that changes to UK law reduce the level of protection currently in place.
09/06/21 – At the end of last week, and more than three months later than originally expected, the European Commission published final versions of its new standard contractual clauses (SCCs) for the transfer of personal data to third countries (New EU SCCs).
The New EU SCCs replace the standard contractual clauses adopted by the European Commission in 2004 and 2010. They have been significantly updated to be consistent with the GDPR, and also address many of the issues raised by the CJEU in its Schrems II judgment. Unlike their rather inflexible predecessors, the New EU SCCs are modular in format and can be adapted to accommodate various data transfer scenarios, including processor-to-processor transfers which will be welcomed by many B2B service providers.
Until the beginning of last month, it was assumed by most privacy geeks that the New EU SCCs, when adopted, would simply be topped-and-tailed by the ICO and then rolled out for use by UK companies transferring personal data to ‘third countries’ (i.e. countries without a UK adequacy finding, which currently includes the U.S.). However, last month we were somewhat taken by surprise when the ICO announced that it is currently working on bespoke standard contractual clauses for the UK (UK SCCs), expected to be published in draft form for consultation later this month.
Schrems II underlined the importance that the EU attaches to protecting its citizens’ personal data after it has been transferred out of the EU. The UK government on the other hand has stated its post-Brexit intention to ‘strike [its] own international data partnerships’ and to be more ‘agile’. It will therefore be interesting to see if the UK SCCs take a more permissive approach than the rigorous, post-Schrems II approach adopted by the New EU SCCs. And if the UK SCCs are significantly less protective than the New EU SCCs, whether the European Commission will threaten to take another look at the adequacy decisions for the UK… Given that we’re now only three weeks away from the 30th June deadline (when, in the absence of an extension, the UK becomes a ‘third country’ for GDPR purposes), this could be very bad news for UK businesses receiving personal data from customers and other data partners within the EEA.
Part 3 to follow once the UK SCCs have been issued for consultation.
26/05/21 – The UK Jurisdiction Taskforce (UKJT) received extensive and overwhelmingly positive publicity for the Legal Statement on the Status of Cryptoassets and Smart Contracts that it published in December 2019 – you can read more about the Legal Statement here.
On 22nd April 2021 the UKJT published its Digital Dispute Resolution Rules (Rules) which:
- Give legal effect to automatic dispute resolution processes incorporated into digital asset systems, and
- Create a streamlined arbitration process to ensure prompt and cost-effective resolution of disputes arising out of digital technologies such as smart contracts, cryptoassets and cryptocurrencies, as well as DLT-based contracts (think blockchain) where there the parties in dispute may have transacted anonymously.
Key features of the Rules:
- Automatic dispute resolution processes: If a digital asset system includes an automatic dispute resolution process (aka ‘on chain’ resolution), then incorporating the Rules into the system will result in an outcome of the automatic dispute resolution being legally binding on the parties.
- Incorporation: The parties can agree that the Rules will apply either before or after a dispute has arisen. The Rules can be incorporated (including in electronic or encoded form) into any relevant contract or digital asset/system by using the following text: ‘Any dispute shall be resolved in accordance with the UKJT Digital Dispute Resolution Rules’. The parties can also include their preferences, including arbitration or expert determination, procedure to be adopted, and identity (or key characteristics) of the arbitrators and/or experts.
- Starting proceedings: The claimant starts proceedings by giving a notice of claim to the respondent and the Society for Computers and Law (‘SCL‘). The notice may, among other things, include a proposal regarding the way the dispute should be managed.
- Responding to proceedings: The respondent then has three days to send an initial response to the notice of claim. Among other things the initial response may include comments on the claimant’s proposal for managing the dispute.
- Arbitrators and experts: On receipt of the initial response, the SCL appoints the tribunal of arbitrators and any experts. Although the SCL will have regard to the parties’ preferences regarding procedure and identity of the arbitrators etc, it is not bound by those preferences. Similarly, although the tribunal of arbitrators has regard to the parties’ preferences regarding procedure, it is not bound by those preferences, and is free to adopt whatever procedure it considers appropriate, without any requirement for disclosure, witness evidence, expert evidence, or even an oral hearing.
- Anonymity: Unless the tribunal considers that disclosure of the parties’ names is necessary for fair resolution of the dispute or effective enforcement of any order, or disclosure is required by law, the tribunal will respect any agreement of the parties that they are to remain anonymous to each other (but not to the tribunal).
- Determination of dispute: Unless a different period has been agreed, the tribunal will use best endeavours to determine the dispute within 30 days. Yes, 30 days. Except in the limited circumstances set out in the Arbitration Act 1996, the tribunal’s decision is final and binding, i.e. there is no automatic right to appeal.
- Digital assets: To help it to implement or enforce its decision, the tribunal has the right to operate, modify, sign or cancel any digital assets relevant to the dispute using any digital signature, cryptographic key, password or other control mechanism available to it, or to order a party to the dispute to do so.
Since their publication a few weeks ago, the reaction has been largely favourable, with praise for the simplicity, flexibility, speed and certainty of the Rules. Whether the positive initial reaction now translates into broad uptake by participants in the new digital technologies remains to be seen.
05/05/21 – If your organisation does not transfer personal data to ‘third countries’, i.e. countries outside the EEA that do not have a UK adequacy finding, then breathe a sigh of relief and feel free to go and do something else. If, however, your organisation does transfer personal data to a ‘third country’ (which for these purposes includes the U.S.), then this is likely to be relevant to your data processing arrangements.
During an IAPP/LinkedIn Live event last week, the European Commission’s Head of International Data Flows and Protection, Bruno Gencarelli, explained that the delay to the adoption of the EU’s new Standard Contractual Clauses (New EU SCCs) is principally due to the volume of feedback that the European Commission has received since the publication of the draft New EU SCCs last November. However, according to Mr Gencarelli, it is now ‘a question of weeks‘ until the New EU SCCs are adopted by the Commission.
Most privacy lawyers – including me – have been assuming that once the New EU SCCs are adopted by the Commission, then the UK’s ICO will adopt pretty much identical standard contractual clauses for UK data exporters. This assumption has been based in part on the ‘copy & paste’ approach that the UK has so far taken to incorporating the EU GDPR (and for that matter the existing EU SCCs) into UK law, and in part on the fact that the UK is currently looking to secure a ‘clean’ EU adequacy decision while fully aware of the importance that the EU attaches to maintaining ongoing alignment of the EU and UK data protection frameworks.
It therefore came as a bit of a surprise when the ICO’s Deputy Information Commissioner, Steve Wood, announced today that the ICO ‘is working on bespoke UK standard clauses for international transfers, and intend to go to consultation on them in the summer‘. No details yet, but the message is clear – if you’re expecting the UK’s new SCCs to be a ‘copy & paste’ of the EU’s New SCCs, then don’t. And in terms of timing, it looks like UK data exporters may have to wait for another few months before they have access to updated SCCs for their transfers.
Part 2 to follow as soon as we have some more detail.
26/04/21 – The European Commission aims to turn the EU into ‘the global hub for trustworthy Artificial Intelligence (AI)’. With that objective in mind, on 21st April 2021 the Commission published its Proposal for a Regulation on a European approach for Artificial Intelligence.
Very interesting, I’m sure. But presumably not relevant to those of us who are no longer in the EU? Or to those of us who aren’t building robots to conquer the human race, haha?
On the EU point, the regulation applies to both EU and non-EU providers who market or deploy AI system in the EU, all users of AI systems in the EU, as well as providers and users of AI systems that are located outside the EU but where the outputs of the AI systems are used in the EU. In other words, the regulation potentially extends far beyond the EU’s borders.
And for the Asimov fans out there, the regulation’s definition of ‘AI system’ is perhaps a little disappointing: ‘software that is developed with one or more of the techniques and approaches listed in Annex I and [which] can, for a given set of human-defined objectives, generate outputs such as content, predictions, recommendations, or decisions influencing environments they interact with’.
Annex I in full:
‘(a) Machine learning approaches, including supervised, unsupervised and reinforcement learning, using a wide variety of methods including deep learning;
(b) Logic- and knowledge-based approaches, including knowledge representation, inductive (logic) programming, knowledge bases, inference and deductive engines, (symbolic) reasoning and expert systems;
(c) Statistical approaches, Bayesian estimation, search and optimization methods.’
Ah I see what you mean. So what do I need to know?
Well, the proposed regulation runs to 107 pages (not including the Annexes), so there’s quite a bit to digest. But by way of an overview:
- Timing. The regulation will now be reviewed and debated by the European Parliament, and then by the Council of Europe. Given the subject matter, the regulation is also likely to generate extensive comments from AI providers and other interested parties. Once adopted by the Commission, the regulation is then subject to a 24-month grace period before it applies fully (Article 85(2)). Being realistic we’re looking at go-live in 2023, and very possibly 2024.
- Risk-based approach. The regulation takes a risk-based approach, with AI systems falling into one of three categories: prohibited AI practices, high-risk systems, and lower-risk systems.
- Prohibited AI practices. The regulation prohibits four specific practices involving AI (Article 5):
- Marketing or deploying AI systems that ‘deploy subliminal techniques beyond a person’s consciousness’ in order to distort their behaviour in a way that causes or may cause harm.
- Marketing or deploying AI systems that exploit vulnerabilities due to age, physical or mental disability in order to distort someone’s behaviour in a manner that causes or may cause harm.
- Marketing or deploying by public authorities AI systems that evaluate or classify the trustworthiness of people with a social score (social scoring).
- Use of ‘real-time’ remote biometric identification systems (e.g. facial recognition systems) for law enforcement purposes, with broad exemptions for certain criminal justice-related purposes. Biometric testing is likely to be one of the more controversial aspects of the regulation; the European Data Protection Supervisor (EDPS) has already issued a press release criticising the Commission for not adopting a stricter approach.
- High-risk systems. The regulation specifies two categories of high-risk AI systems:
- The first category consists of AI systems used as safety components of products, or AI systems which are themselves products, that are regulated under the ‘New Legislative Framework’ legislation listed in Annex II to the regulation, e.g. toys, medical devices, motor vehicles, gas appliances etc. Checking that these AI safety components, or AI systems, comply with the regulation (‘conformity assessments’) will be incorporated into the existing third-party compliance and enforcement mechanisms for the relevant products.
- The second category are stand-alone AI systems that the Commission considers have ‘fundamental rights implications’. These are listed in Annex III to the regulation, and include AI systems used for:
-
-
-
-
- biometric identification (to the extent not a prohibited AI practice).
- management of road traffic and other critical infrastructure (water, gas, heating and electricity)
- education and vocational training
- recruitment and hiring of candidates
- making decisions in connection with management and termination of workers
Stand-alone systems will be subject to conformity assessments, as well as quality and risk management systems and post-market monitoring. Following the conformity assessments, the AI systems must then be registered in a European Commission-managed database, to ensure public transparency and assist ongoing supervision.
- Lower-risk systems. AI systems which are not prohibited or high-risk are subject to relatively light-touch regulation. There are no conformity assessment for lower-risk systems. And although all providers must inform individual users that they are interacting with an AI system (unless it is ‘obvious from the circumstances and the context of use’), there is no obligation for providers of lower-risk AI systems to provide information about the system’s algorithm or how it operates, as is the case for providers of high-risk systems.
- Data governance. Providers of high-risk systems are required to adopt rigorous data governance and management practices in relation to training, validation and testing datasets to reduce the risk of potential biases and other inaccuracies.
- Sandboxes. The regulation encourages EU member states to establish sandboxes (i.e. controlled environments) to enable providers to test innovative technologies on the basis of an agreed testing plan, and to reduce the regulatory burden (including conformity assessment fees) for SMEs and start-ups.
- Penalties. For corporate providers of AI systems there are three levels of fines:
- Non-compliance with Article 5 (prohibited AI practices, see para 3 above) or Article 10 (data governance, see para 6 above) is subject to a fine of up to €30,000,000 or 6% of total annual worldwide turnover, whichever is the higher.
- For non-compliance of any other provision of the regulation, up to €20,000,000 or 4% of total annual worldwide turnover, whichever is the higher.
- For the supply of incorrect, incomplete or misleading information to regulatory bodies, up to €10,000,000 or 2% of total annual worldwide turnover, whichever is the higher.
I see what you mean about quite a bit to digest. Anything I need to do now?
Although the regulation is likely to be subject to various changes over the next few months – particularly in the areas of biometric testing and social scoring – the fundamental principles are unlikely to change. So if you’re involved with the development, marketing, sale or distribution of software that constitutes a high-risk AI system then you may want to start thinking about how the regulation will impact areas such the accuracy of your datasets, risk of bias, and algorithmic transparency.
15/04/21 – If you’ve been following the progress of the UK adequacy decisions (see updates from December 2020 and March 2021), you will know that we have been waiting for the European Data Protection Board’s opinions on the draft UK adequacy decisions. As per the EDPB’s press release yesterday, these opinions have now been adopted.
Although the full texts are not yet available, the press release suggests that the EDPB’s opinions broadly supports the adequacy decisions, noting that the UK has “for the most part” mirrored the GDPR and the Law Enforcement Directive in its data protection framework, and that as a result many aspects of the UK’s law and practice are “essentially equivalent”.
However, the EDPB also emphasises that the alignment of the EU and UK data protection frameworks must be maintained going forward, and welcomes the European Commission’s decision to limit the duration of the adequacy decisions (to 4 years). The EDPB also urges the Commission to closely monitor how the UK applies restrictions to onward transfers of EEA personal data, including transfers pursuant to adequacy decisions adopted by the UK, international agreements concluded between the UK and third countries, or derogations.
Next step is for the adequacy decisions to be approved by representatives of all 27 EU member states via the so-called ‘comitology procedure’, following which they can be adopted by the Commission. I will keep you posted.
30/03/21 – As part of the Trade and Cooperation Agreement announced just before Christmas, the EU and the UK agreed a six-month ‘bridging period’ allowing transfers of personal data from the EEA to the UK to continue freely until 30th June 2021 – more detail here. Half-way through the bridging period is probably a good time for an update.
Update? Didn’t I read a few weeks ago that the EU issued the UK adequacy decision, and it’s now all done and dusted?
No, not really. What happened is that on 19th February 2021 the European Commission issued two UK adequacy decisions (one for transfers under the GDPR, and the other for transfers under the Law Enforcement Directive), but only in draft form. The drafts have now been passed to the European Data Protection Board (EDPB) for them to review and issue their non-binding (but influential) ‘advisory opinions’. After the advisory opinions have been issued, and any EDPB-recommended changes have been incorporated into the text of the adequacy decisions, the drafts will then need to be approved by representatives of all 27 EU member states via the so-called ‘comitology procedure’. Once approved, the adequacy decisions can be formally adopted by the Commission, and become legally effective.
Ah, so not quite done and dusted. Will this all be wrapped up by 30th June?
Probably. The good news is that the draft adequacy decisions were issued by the European Commission without any material conditions attached to them, i.e. the Commission considers that the UK’s data protection laws and systems are adequate. Also positive was the prediction of the EU Head of International Data Flows, Bruno Gencarelli, who said in a LinkedIn webinar on 27th January 2021 that he was confident the UK adequacy decisions would be adopted “by the end of the bridging period”. Ditto the prediction of the EU Commissioner for Justice, Didier Reynders, who, according to Vincent Manancourt of politico.eu, said on 16th February 2021 that the EDPB’s “opinion on UK data flows decision [is] expected mid-April […] Whole process to be wrapped up by Brussels by end of May/early June”.
Less positive were the widely-publicised comments of the UK culture secretary Oliver Dowden, who in his FT article on 27th February said: “we do not need to copy and paste the EU’s rule book, the General Data Protection Regulation, word-for-word”; and that the UK can now be more “agile” when it comes to “[striking] our own international data partnerships with some of the world’s fastest growing economies. […] The EU has been slow to act on this, declaring only 12 countries ’adequate’ in the past few decades”. Announcing the UK’s intention to diverge from the GDPR and criticising the EU’s historic approach to adopting adequacy decisions, all while the EDPB is busy considering the UK’s application, may not have been Mr Dowden’s best idea.
All very interesting, but I’ve got data flows with EU customers and other data partners which need to continue after 30th June. What do I need to do?
You’ve got a number of options, including:
- Do nothing. If the GDPR adequacy decision isn’t adopted by 30th June 2021 (and the bridging period isn’t extended), then deal with the situation on 1st If this option appeals, then bear in mind that although you may be willing to take a risk-based view on the legality of your post-30th June data flows, your EEA data partner may not.
- Put in place a valid transfer mechanism or safeguard (most likely Standard Contractual Clauses (SCCs)) ASAP, even though they may end up not being needed. This is clearly ‘best practice’, and consistent with the ICO’s recommendation: “If you receive personal data from the EEA, we recommend you put alternative safeguards in place before the end of April”.
- Contact each of your EEA data partners, and suggest to them that if the GDPR adequacy decision has not been adopted by say end of May, or even mid-June, then you will both work together with a view to putting in place SCCs by 30th June.