Article 20 of the DIFC Data Protection Law requires a data protection impact assessment before High Risk Processing begins, and Article 20(6) lists what that assessment must contain at a minimum. For an AI tool, much of that content is material Regulation 10 of the Data Protection Regulations already expects the firm to be able to describe or evidence. This piece reads the five items in turn and shows where the two instruments meet.
This article reads the published DIFC instruments at a general level for orientation. It is not legal advice. Whether a given AI tool needs an impact assessment, and what it should say, depends on the firm's systems, data and use, and should be decided on its own facts.
When the assessment is required
Article 20(1) of the Law reads: “Prior to undertaking High Risk Processing Activities a Controller shall carry out an assessment of the impact of the proposed Processing operations on the protection of Personal Data, considering the risks to the rights of the Data Subjects concerned.” The same paragraph allows a Controller to carry out an assessment voluntarily for processing that is not High Risk.
Two features of that sentence matter. The trigger is High Risk Processing Activities, a term defined in Schedule 1 of the Law with four limbs, any one of which is enough; our reading of the four limbs sets them out word for word. And the timing is “prior to”. An assessment written after a tool has gone live does not meet the words of Article 20(1).
Schedule 2 of the Law lists “Failing to carry out a data protection impact assessment prior High Risk Processing Activities in accordance with Article 20 of the Law” with a maximum administrative fine of USD 50,000. That is a ceiling, not a tariff: under Article 62(2) the Commissioner sets an amount he considers appropriate up to the Schedule 2 figure, and Article 62(3) separately allows a general fine not limited to the Schedule 2 amounts.
A second trigger aimed at AI training data
Article 22 of the Law deals with retention and deletion. Article 22(4)(c) provides that a Controller and any relevant Processor is not required to delete, anonymise, pseudonymise or encrypt personal data, or put it beyond further use, where it “is part of a dataset used to lawfully train or refine an artificial intelligence system in a manner that does not present risks to a Data Subject’s rights.” Article 22(5) then provides that a Controller or Processor seeking to rely on Article 22(4)(b) or 22(4)(c) “shall conduct a data protection impact assessment in accordance with Article 20 before doing so.” That trigger does not depend on the processing being High Risk. A firm that relies on Article 22(4)(c) to keep personal data in a training or fine-tuning set, beyond the point it would otherwise have to delete it, needs the assessment first.
Whose duty it is when the tool is a vendor's
Article 20 is addressed to the Controller. For AI tools, Regulation 10.3.4 settles who that is. For the purposes of Regulation 10 and the Law, “a Deployer of a System shall be deemed to act as a Controller” and “an Operator of a System shall be deemed to act as a Processor” in respect of the processing of personal data by that System. A Deployer is defined in Regulation 10.1.1(b) without regard to whether the System is operated, supervised or hosted by that person. A DIFC firm running a vendor's AI tool on its own clients or staff is therefore very likely the one that owes the assessment.
Where the vendor operates or supervises the tool on the firm's behalf, it has a part to play. Article 20(11) requires a Processor appointed, or in the process of being appointed, by a Controller to “assist the Controller by providing all information reasonably requested by the Controller in connection with the relevant data protection impact assessment.” An Operator, deemed a Processor by Regulation 10.3.4(b), falls within that duty. A vendor that only develops and licenses the tool is a Provider, not an Operator, and the firm will need to secure the information contractually instead. The words “in the process of being appointed” mean the request can be made during procurement, which is when the firm has the most leverage to get answers.
Article 20(2) allows a Controller to rely on an assessment carried out by another member of its Group, if it complies with Article 20(6), covers substantially the same processing and remains current and accurate. On our reading, that permission is limited to the Group. A vendor's own risk documentation is information the firm receives, under Article 20(11) where the vendor is an Operator or under contract where it is not. It is not an assessment the firm can adopt as its own.
The five minimum contents
Article 20(6) provides that a data protection impact assessment “shall contain at least” the following. Each is quoted, in whole or in part, from the Law, then applied to an AI tool.
A systematic description and the purposes
(a) “a systematic description of the foreseen Processing operations and the purpose(s) of the Processing, including, where applicable, the legitimate interest pursued by a Controller”.
For an AI tool this means the data that goes in, where it comes from, what the tool does with it, the output it produces, and who acts on that output. Where the tool is used through an application or website service, Regulation 10.2.2(b) requires the notice to users to give a “comprehensive, true and plain description” of, among other things, the human-defined purposes for which the System processes personal data, the human-defined principles and limits within which it can define further purposes itself, and the output it produces and how that output is used. The assessment's description and the notice's description cover the same ground. They should not disagree.
Necessity and proportionality
(b) “an assessment of the necessity and proportionality of the Processing operations in relation to the purpose(s)”.
Regulation 10.2.2(g)(i) asks for the same analysis in another form: a register, provided on request, listing among other things the “use cases, necessity and proportionality of Processing activities” in which Systems are used. The Commissioner's Regulation 10 Accreditation and Certification Framework puts the question sharply. Its Systems Certification Program Requirement 1.2 asks a certification body to assess whether the applicant used a risk-based approach to determine the necessity of High Risk Processing through the System “rather than through a different, lower risk System”, and it lists among its examples of acceptable evidence “An AI Data Protection Impact Assessment that assesses the necessity of the Systems or at a minimum, of processing Personal Data in such Systems”. An assessment that never asks whether a less intrusive tool would do the job is thin on this item.
The lawful basis
(c) “identification and consideration of the lawful basis for the Processing”, including, where legitimate interests are relied on, an analysis of why the Controller believes the Data Subject's interests or rights do not override its own, and, where consent is relied on, validation that consent was validly obtained and “consideration of the impact of the withdrawal of consent to such Processing and of how a Controller will ensure compliance with the exercise of a Data Subject's right to withdraw consent”.
For an AI tool relying on consent, the withdrawal question is practical: what happens to the person's data, and to anything derived from it, when consent is withdrawn. The guidance note to Regulation 10.2.2(a) explains that the notice exists so that individuals can make an informed assessment of the risks and “ultimately decide whether to take steps to object or withdraw the legal basis permitting the processing by the System.” The assessment should show the firm has worked out what it will do when they do.
The risks to Data Subjects
(d) “an assessment of the risks to the rights of Data Subjects”.
Regulation 10.2.2 names some of the risks an AI assessment should address. Where an application or website service employing Systems is used, the Deployer or Operator must be able to provide on request evidence of algorithms that cause the System to seek human intervention where its processing may result in an unfair or discriminatory impact, “as well as a risk and impact assessment of the risk that Processing by the System of information made available to the System may result in unjust bias or High Risk Processing” (10.2.2(d)). Paragraphs (e) and (f) call for risk and impact assessments on access by competent government authorities and on non-compliance with Regulation 9. The Article 20 assessment is a natural place to hold that analysis, so that one document answers both instruments.
The measures
(e) “the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of Personal Data and to demonstrate compliance with this Law, taking into account the rights and legitimate interests of Data Subjects and other concerned persons.”
For an AI tool, the human intervention mechanisms that Regulation 10.2.2(d) to (f) describe are among the measures this item should record, alongside access controls, retention, vendor terms and testing. The item also decides what happens next. Under Article 21(1), where the assessment indicates that, despite the measures referred to in Article 20(6)(e), the risks to the rights of Data Subjects “remain particularly high” and the Controller has already carried out or wishes to commence or continue the processing, the Controller “shall consult the Commissioner”.
The rest of Article 20
The minimum contents are only part of the Article. The other paragraphs shape how the assessment is run.
- One assessment may cover a set of similar processing operations that present similar risks (Article 20(2)). A firm rolling out one tool across several teams may not need several assessments, if the risks are in fact similar.
- A DPO, where appointed, is responsible for overseeing data protection impact assessments (Article 20(3)), and must provide advice where requested in relation to them (Article 18(3)(c)). A firm performing High Risk Processing on a systematic or regular basis must appoint one (Article 16(2)(b)).
- Compliance with approved codes of conduct under Article 48 is taken into account in assessing impact (Article 20(7)).
- The Controller must seek the input of Data Subjects or their representatives on the intended processing, where appropriate, taking into account the protection of commercial or public interests or the security of the processing (Article 20(8)).
- The Commissioner may publish lists of processing considered High Risk and of processing for which no assessment is required (Article 20(4) and (5)). The Commissioner’s 2022 guidance on High Risk Processing (DIFC-DP-GL-09 Rev. 02) includes a list of examples, which it describes as non-exhaustive and non-binding.
After the assessment
Article 20(10) requires the Controller to review whether processing is performed in accordance with the assessment “on a regular basis, proportionate to the extent and type of Processing the Controller conducts”, or “when there is a change in the risk related to the Processing operations.” On our reading, a new model version, a new data source or a new use of the output is the kind of event a firm should test against Article 20(10)(b).
The Commissioner's guidance on High Risk Processing adds a limit in the other direction. It says assessments do not need to be repeated every time High Risk Processing occurs where the activity has already been assessed in terms of the nature and means of the processing, the type of data and the categories of Data Subjects, and gives the example of a non-material increase in the volume of records added to an assessed database.
The assessment also has a place in the firm's records. Regulation 2.1.4 requires the record of processing activities to include, or where possible link to, documentation covering data protection impact assessments, and Regulation 2.1.2 requires that record to be made available to the Commissioner on request.
What a firm would want on file
Before a High Risk AI tool goes live, or before personal data is kept in a training set under Article 22(4)(c), a firm working through Article 20 would normally want, in writing:
- The High Risk view for the tool, with each of the four limbs applied and reasons given.
- A description of the processing that matches the Regulation 10.2.2(b) notice, including inputs, outputs and who acts on them.
- A necessity and proportionality analysis that considers a lower risk alternative.
- The lawful basis, with the legitimate interests balance or the consent and withdrawal analysis that Article 20(6)(c) requires.
- The risks, including the bias and High Risk risk assessment that Regulation 10.2.2(d) refers to, and the measures, including human intervention.
- A conclusion on whether residual risk is particularly high, and so whether Article 21(1) consultation is needed.
- The vendor information requested, under Article 20(11) where the vendor is an Operator or under contract where it is not, with the date it was asked for and received.
- An owner, the DPO sign-off where there is one, and review triggers under Article 20(10).
The first item on that list decides whether the rest is required. A written High Risk view across the firm's AI tools is what the two-week AI Governance Assessment produces, at a fixed AED 5,000, together with a costed roadmap for the assessments and other steps that follow from it.