The ADGM Data Protection Regulations 2021 mention artificial intelligence once, in section 31(4)(c). When a firm would otherwise have to delete, anonymise, pseudonymise or encrypt personal data, that provision lets it keep data that “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”. Before relying on it, the firm must complete a data protection impact assessment. The exception is narrower than it first appears, and it does not answer every question a training dataset raises.
This article reads the published ADGM instruments and the Office of Data Protection's guidance at a general level for orientation. It is not legal advice. Whether a firm may keep personal data in a training dataset, and on what terms, depends on its own processing and should be decided on its own facts. References are to the consolidated Data Protection Regulations 2021 (consolidated version August 2025).
What section 31 requires
Section 31 deals with what happens to personal data when processing has to stop. Section 31(1) applies “Where the basis for Processing changes, ceases to exist or a Controller is required to cease Processing due to the exercise of a Data Subject’s rights under section 15”, the right to erasure. In those cases the Controller must ensure that all the personal data, “including Personal Data held by Processors”, is securely and permanently deleted, anonymised, pseudonymised or securely encrypted.
Where none of those is possible, section 31(2) requires the data to be archived so that it is “put beyond further use”. Section 31(3) defines that phrase: the Controller and any relevant Processor must be unable to use the data to inform any decision about the Data Subject or in any way that affects them (other than automated cross-checking solely to prevent further processing), no one else may have access to it, it must be protected to the standard of live data, and there must be a strategy for its eventual deletion, anonymisation, pseudonymisation or encryption with which the firm complies and can demonstrate compliance.
For a firm building or tuning AI tools, section 31 is the point at which a dataset that was lawfully assembled has to be dealt with, because the basis for processing has changed or ended, or an individual has exercised the right to erasure.
The AI training exception
Section 31(4) begins “Notwithstanding section 31(1)” and lists three cases in which a Controller and any relevant Processor is not required to delete, anonymise, pseudonymise or encrypt the data or put it beyond further use. The first covers data needed for legal claims or retained under Applicable Law. The second covers scientific research in the public interest or in the interests of ADGM, again in a manner that does not present risks to the rights of Data Subjects. The third, section 31(4)(c), covers data that “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”.
Read closely, the exception has four elements, each of which has to be true:
- The data is part of a dataset used to train or refine an AI system. On our reading, data held only in case it becomes useful later is not described by the words.
- The training or refinement is lawful. The exception assumes a lawful basis for that processing; it does not supply one.
- The system is an artificial intelligence system. The Regulations do not define the term; the definitions in section 62 contain no entry for it.
- The training is carried out in a manner that does not present risks to a Data Subject’s rights. The test is stated without a qualifier such as “high” or “material”.
The Office of Data Protection repeats the exception in its Guidance on the DPR 2021, Part 5, and adds the practical consequence: if a firm relies on it, it “must have a policy and process for managing the relevant personal data when the exception no longer applies”.
The conditions attached
Section 31(5) reads: “A Controller or Processor seeking to rely on sections 31(4)(b) or 31(4)(c) must conduct a data protection impact assessment in accordance with section 34 before doing so.” It continues: “Any Processing of Personal Data in accordance with section 31(4) must be limited to the extent necessary for such purposes.”
Section 31(6) then requires a policy and process for managing data held under section 31(4) “when the grounds for retention no longer apply”, and requires the data to be deleted, anonymised, pseudonymised, encrypted or put beyond further use when that happens. Guidance Part 4 notes, in a footnote, that the research and AI training exceptions are the only exceptions in section 31 that require a DPIA.
In practice that gives three written items before the exception is used: the impact assessment, a record of why each category of data kept is necessary for the training purpose, and a policy that says what happens to the data when the model is retired, the purpose ends, or the training no longer needs it.
One drafting point is worth noting. Section 31(5) places the DPIA duty on “A Controller or Processor”. Guidance Part 4, at paragraph 8, asks whether processors need to perform DPIAs and answers: “No. Only controllers are required to perform DPIAs under the DPR 2021.” It adds that processors must contractually commit to assist controllers with section 34, and paragraph 3.1 describes the section 31(5) duty as falling on the controller. The guidance describes itself as non-binding. On our reading, a Processor that wants to rely on section 31(4)(c) for data it holds should follow the text of section 31(5), whatever the guidance says about DPIAs in general.
The impact assessment
Section 34 sets the content and process. The DPIA must “describe the nature, scope, context and purpose of the Processing”, “assess necessity, proportionality and compliance measures”, “identify and assess risks to individuals” and “identify any additional measures to mitigate the risks identified” (section 34(5)(a) to (d)). The Controller must seek the advice of its DPO, where one is designated (section 34(3)), and must review the processing against the DPIA where necessary, including when the risk changes (section 34(6)).
Section 34(7) requires the Controller to notify the Commissioner of Data Protection before carrying out processing where a DPIA indicates that it would be likely to result in a high risk to the rights of natural persons. Guidance Part 4 adds that the notification can be made through the Registry Platform and that the Commissioner “may require corrective action to be taken prior to commencement”.
The two tests sit together awkwardly. Section 31(4)(c) asks whether the training presents risks to a Data Subject’s rights at all; section 34 asks the firm to identify and assess those risks and mitigate them. On our reading, the DPIA for a training dataset is the document that has to show why the residual risk is low enough for the exception to be relied on, and a DPIA that concludes the training is likely to result in a high risk is difficult to square with the exception’s own condition. The Office of Data Protection's published DPIA template already asks the relevant question: “Is it novel in any way? For example, will the processing involve AI or Blockchain technologies?”
Our reading of the DIFC impact assessment for an AI tool covers the equivalent DIFC requirement, which differs in its content.
What the exception does not do
Section 31(4)(c) is an exception to the duty to delete or neutralise data when processing stops. It is not a lawful basis and it is not a rule about purpose. Three other provisions still apply to the training itself.
First, lawfulness. Section 5(1) says processing “is lawful only if and to the extent that” one of its listed bases applies, such as consent, contract or legitimate interests. On our reading, the word “lawfully” in section 31(4)(c) points back at least to that test. Where the dataset includes Special Categories of Personal Data, a section 7(2) condition is also needed.
Second, purpose. Section 4(1)(b) requires personal data to be collected for specified, explicit and legitimate purposes “and not further Processed in a manner that is incompatible with those purposes”. Where data collected for one purpose, such as servicing a client, is used to train a model, section 5(3) lists the factors for judging compatibility, including the link between the purposes, the context of collection, whether Special Categories are involved, the possible consequences for Data Subjects, and safeguards such as encryption or pseudonymisation. Section 11(3), or section 12(4) where the data was not obtained from the Data Subject, requires the Data Subject to be told about the new purpose before the further processing.
Third, minimisation and storage. Section 4(1)(c) and (e) require data to be limited to what is necessary and kept in identifiable form for no longer than necessary. Section 31(5) restates the point for data kept under the exception: the processing “must be limited to the extent necessary”.
Erasure requests
The hardest case is an individual who asks for erasure. Section 15(1) gives the Data Subject the right to obtain erasure “without undue delay” where, among other grounds, the data is no longer necessary for its purposes, consent is withdrawn and there is no other legal ground, or the individual objects under section 19 (for most objections, where there are no overriding legitimate grounds). Section 15(3) disapplies that right only to the extent processing is necessary for listed purposes: legal obligations and public functions, public health, Archiving and Research Purposes in defined circumstances, and legal claims. AI training is not among them.
Section 31(1) expressly covers a Controller that “is required to cease Processing due to the exercise of a Data Subject’s rights under section 15”, and section 31(4) applies “Notwithstanding section 31(1)”. Part 5 of the guidance also places erasure requests within the cessation duty to which the exceptions attach. But section 15(3), which lists the limits on the right to erasure itself, contains no AI training case. On our reading, the two provisions are not reconciled, and a firm should not treat section 31(4)(c) as an answer to an erasure request without specific advice.
Section 15(4) is the provision written for data that cannot be removed. Where erasure “is not feasible for technical reasons”, the Controller is not in violation for failing to comply with a request if two things are true: it collected the data from the Data Subject, and the information given under section 11(2)(h) “was explicit, clear and prominent with respect to the manner of Processing the Personal Data and expressly stated that erasure of the Personal Data at the request of the Data Subject would not be feasible”. Section 11(2)(h) requires that notice where a Controller intends to process data in a way that will restrict or prevent erasure, rectification or objection, together with a clear and explicit explanation of the expected impact and steps to satisfy itself that the Data Subject understands and acknowledges the restriction.
Two consequences follow for training data. The section 15(4) route has to be prepared in advance: section 11(2) requires the information “at the time when Personal Data is obtained”, and on our reading a section 11(3) notice before repurposed data is used for training is the latest point it could be given. It cannot be added after the model is trained. And it is available only for data collected from the Data Subject, not for data obtained in another way, where section 12 governs the information to be given.
Other AI provisions
Section 31(4)(c) is the only express mention of AI, but the Regulations and guidance reach AI tools in several other places.
- Section 20(1): the right not to be subject to a decision based solely on automated Processing, including Profiling, which produces legal effects or similarly significantly affects the individual, with the exceptions and safeguards in sections 20(2) to 20(4).
- Section 11(2)(g): where automated decision-making under section 20 exists, the notice must give meaningful information about the logic involved and the significance and envisaged consequences.
- Section 23(1): data protection by design and by default. Guidance Part 3 illustrates it with an insurer using AI to profile customers, which should consider the principle when choosing a supplier’s AI application and deciding how to train it.
- Guidance Part 4, paragraph 3.5: the Commissioner’s non-exhaustive list of processing that needs a DPIA includes using profiling, automated decision-making or special category data to help decide on access to a service, opportunity or benefit, and profiling on a large scale.
Section 55(1) allows the Commissioner of Data Protection to impose a fine for a contravention of the Regulations of an amount it determines to be appropriate, taking into account the factors in section 55(3). The amount “must not exceed USD 28 million”. That is a maximum, not a tariff.
What to have on file
A firm in ADGM that keeps, or plans to keep, personal data for training or refining an AI system would want the following in writing before it relies on section 31(4)(c):
A register of training datasets
The lawful basis and the purpose test
A section 34 DPIA completed first
A necessity record
The section 31(6) policy
An erasure position
Where to start
The register of datasets and AI tools is the input everything else depends on. It is the first thing the two-week AI Governance Assessment produces: a written baseline across a firm's AI tools and a costed roadmap, at a fixed AED 5,000.