This seventh part continues Part VI on AI agent compliance under EU law. The question concerns how an EU business establishes lawful processing for training, reuse and deployment while meeting the AI Act. The answer depends on each processing purpose, the applicable GDPR basis and whether the model or its operation involves personal data. (Regulation (EU) 2016/679 (GDPR), Articles 4(1)–(2), 5(1)(b), 6; Regulation (EU) 2024/1689 (AI Act), Article 2(7), as amended by Regulation (EU) 2026/1744, Article 1(2)(b).)
Summary
- AI Act compliance leaves the GDPR's processing requirements applicable. Articles 4a and 59 provide specific permissions for qualifying bias work and sandbox reuse; neither authorises unrestricted AI training. (AI Act, Articles 2(7), 4a, 59.)
- Establish the purpose and legal basis for the actual processing. Training and deployment can involve the same or different purposes. Reusing customer records for another purpose requires the applicable consent, statutory permission or compatibility analysis. (GDPR, Articles 5(1)(b), 6(1), (4); EDPB, Opinion 28/2024, paragraphs 63–64.)
- Legitimate interests can support AI processing only where the interest is legitimate, the processing necessary and the person's interests or rights do not override it. Public availability of data does not settle those conditions. (GDPR, Article 6(1)(f), recital 47; EDPB, Opinion 28/2024, paragraphs 66–76, 91–95.)
- Article 4a provides the specified substantial-public-interest basis for qualifying processing of special-category data. The organisation must still establish Article 6 lawfulness and satisfy every applicable safeguard. Paragraph 2 creates permission without imposing a bias-testing duty. (GDPR, Articles 6, 9(2)(g); AI Act, Article 4a; Regulation (EU) 2026/1744, recital 9.)
- A model's anonymity requires evidence about identifiability under the relevant access and use conditions. Removing names or describing the model as statistical does not establish that result. (GDPR, Article 4(1), recital 26; EDPB, Opinion 28/2024, paragraphs 36–46; CJEU, EDPS v SRB, C-413/23 P, ECLI:EU:C:2025:645, paragraphs 75–87.)
- Unlawful training can affect later processing and expose the model to corrective measures. Effective anonymisation changes the analysis of subsequent use while leaving the earlier processing open to enforcement. (GDPR, Articles 5(1)(a), 6, 58(2); EDPB, Opinion 28/2024, paragraphs 111–135.)
- Shared assessment evidence does not merge distinct statutory procedures. A separately triggered GDPR prior-consultation duty and the authority's corrective powers continue despite an AI Act conformity result. (GDPR, Articles 36, 42(4), 58(2)(f); AI Act, Articles 2(7), 27(3)–(4).)
The legal basis for each processing purpose
The organisation must establish GDPR lawfulness for the processing involved in its AI project. Amended Article 2(7) preserves that requirement while recognising the specific provisions in Articles 4a and 59. The relevant question is whether the particular collection, training, disclosure or later use satisfies its applicable conditions. An AI Act classification or conformity result cannot supply a missing processing basis outside those provisions. (GDPR, Articles 4(2), 5(1)(a), 6; AI Act, Article 2(7), recitals 10, 45.)
The European Data Protection Board (EDPB) explains the GDPR's application to AI models in its nonbinding Opinion 28/2024. It directs supervisory authorities to distinguish processing stages and examine their purposes. Development and deployment may constitute the same processing activity or different activities, depending on the facts. A technical stage does not automatically require a different legal basis; a basis identified for one purpose does not automatically cover every later purpose. (GDPR, Articles 5(1)(b), 6; EDPB, Opinion 28/2024, paragraphs 60–64.)
Consider a hypothetical business that collects customer messages to resolve service requests and later uses them to train a reusable model. The business must identify what the training is intended to achieve, the records it requires and the intended use of the resulting model. Internal deployment, distribution to customers and release for unrestricted use can present different processing conditions. A description limited to improving AI leaves those differences unexplained. The EDPB expects the development purpose to reflect the model's expected functions and the deployment context already known. (EDPB, Opinion 28/2024, paragraph 64.)
Research status does not remove this examination. Article 2(8) excludes specified research, testing and development activities before market placement or putting into service from the AI Act, while expressly preserving applicable Union law. It excludes real-world testing from that exclusion. A business relying on this provision must still establish its GDPR basis for personal-data processing during development. (AI Act, Article 2(8), recital 25; GDPR, Articles 5(1)(a), 6.)
Contract, consent and reuse of existing records
The selected basis must fit the purpose, rather than the company's preferred contractual description. Article 6(1)(b) requires processing necessary to perform a contract with the data subject or take requested pre-contractual steps. An agreement between a business and its model supplier does not itself establish that basis for processing customers' data. (GDPR, Article 6(1)(b).)
The EDPB's final, nonbinding online-services guidance distinguishes objective contractual necessity from processing merely included in terms. It also states that processing to improve a service generally cannot rely on contractual necessity. Applied to the customer-message example, delivering the requested service and developing a reusable model require examination of their respective purposes. A controller relying on Article 6(1)(b) for training must establish the actual necessity; adding a training clause to standard terms cannot establish it alone. (EDPB, Guidelines 2/2019, Version 2.0, paragraphs 23–34, 48–49.)
Consent is another possible basis, subject to its own conditions. It must be freely given, specific, informed and unambiguous; the controller must be able to demonstrate it. Withdrawal must be as easy as giving consent. Making a service conditional on unnecessary processing bears directly on whether consent is freely given. An AI-interaction notice does not itself establish consent to use the conversation for model development. (GDPR, Articles 4(11), 6(1)(a), 7.)
Further use of existing records also engages purpose limitation. Where the new processing is not based on the person's consent or qualifying Union or Member State law, Article 6(4) requires a compatibility assessment. The controller must consider the connection between the original and new purposes, the collection context, the data's nature, possible consequences and safeguards. The qualifying statutory route requires a necessary and proportionate measure protecting an Article 23(1) objective. A general commercial preference for reuse does not meet that description. (GDPR, Articles 5(1)(b), 6(4).)
Compatible further processing can continue without a legal basis separate from the basis permitting collection. That rule does not displace the other GDPR requirements or extend consent beyond its valid scope. A narrowly defined internal improvement and public distribution of a model capable of exposing customer information cannot be treated as interchangeable purposes. The controller must establish compatibility or another permitted route before that reuse. (GDPR, Articles 5(1)(b), 6(4), recital 50.)
Legitimate interests and publicly available data
Article 6(1)(f) can support personal-data processing for AI, provided its cumulative conditions are met. The controller must identify a legitimate interest, establish that the processing is necessary for that interest, and assess competing interests and rights. The EDPB requires an interest that is lawful, precisely stated, real and present. Developing a conversational service or improving threat detection can qualify as an interest, but the other conditions still require examination. (GDPR, Article 6(1)(f); EDPB, Opinion 28/2024, paragraphs 66–69.)
Necessity concerns the processing proposed for that purpose. The assessment should consider less intrusive alternatives reasonably available to achieve the purpose just as effectively. The amount of personal data must also be proportionate to the interest pursued. For a model intended to answer questions about product specifications, a controller should examine whether those specifications can achieve the objective without customer correspondence. If equivalent performance can reasonably be achieved without that personal data, the necessity case for using it fails. (GDPR, Articles 5(1)(c), 6(1)(f); EDPB, Opinion 28/2024, paragraphs 70–75.)
The balancing assessment then examines the people affected, the nature of their data and the consequences of processing. Children, sensitive circumstances and the possibility of exposing or reusing information require attention to the particular harm. Benefits to the business or users can form part of the assessment, but do not make the individual's interests irrelevant. Public authorities cannot rely on Article 6(1)(f) for processing in the performance of their tasks. (GDPR, Article 6(1)(f); EDPB, Opinion 28/2024, paragraphs 76–90.)
Publicly accessible information remains subject to this analysis when it is personal data. Availability is one factor in assessing reasonable expectations. The relationship with the controller, the source and its privacy settings, collection circumstances and the model's expected uses also matter. A person who posts a professional biography does not thereby settle the lawfulness of every training or deployment purpose. The controller must assess what that person could reasonably expect in the actual circumstances. (GDPR, Articles 4(1), 6(1)(f), recital 47; EDPB, Opinion 28/2024, paragraphs 91–95.)
The controller can consider additional measures that reduce the adverse consequences of the proposed processing. The EDPB distinguishes these from measures already required for ordinary GDPR compliance. Limiting accessible sources or restricting extraction can affect the assessment, but an opt-out mechanism cannot substitute for establishing the underlying conditions. Where Article 21(1) applies, an objection based on the person's particular situation requires the controller to stop processing unless it demonstrates the specified overriding grounds or legal-claims necessity. (GDPR, Article 21(1); EDPB, Opinion 28/2024, paragraphs 65, 96–106.)
Data collection from public sources also raises the GDPR's information duties. The exception for impossibility or disproportionate effort in Article 14(5)(b) requires its statutory conditions and protective measures. Neither a large dataset nor publication of an AI Act training-content summary establishes the exception by itself. The controller must assess the actual collection under Article 14 and the information that provision requires. (GDPR, Article 14(1)–(5); AI Act, Articles 2(7), 53(1)(d); EDPB, Opinion 28/2024, paragraph 63.)
Special-category data and bias testing
Processing special-category data requires an applicable Article 9 exception as well as Article 6 lawfulness. Article 9 covers health data, information revealing racial or ethnic origin and the other listed categories. Legitimate interests alone cannot remove its prohibition. The exception for data manifestly made public requires that the data subject made them public; information appearing online through another person's disclosure does not satisfy that condition merely because it is accessible. (GDPR, Articles 6, 9(1), (2)(e).)
Article 4a of the amended AI Act supplies a specific permission for qualifying bias detection and correction. The legislature expressly connects it to the substantial-public-interest condition in GDPR Article 9(2)(g). Providers of high-risk systems fall within paragraph 1. Paragraph 2 extends permission to the specified other providers and deployers where its harm-related conditions are met. (AI Act, Article 4a(1)–(2); Regulation (EU) 2026/1744, recital 9, Article 1(6).)
The interaction requires two distinct legal findings. The organisation must establish that its processing satisfies Article 4a's strict necessity and cumulative safeguards, addressed in Part IV. It must also identify the applicable Article 6 basis. Reliance on Article 6(1)(c) requires processing necessary for an actual legal obligation imposed on that controller. The optional permission in Article 4a(2) does not itself create such an obligation. (GDPR, Articles 6(1)(c), (3), 9(2)(g); AI Act, Article 4a(1)–(2).)
Suppose a provider needs ethnic-origin data to examine discriminatory error rates in a qualifying system. Reliance on Article 4a requires strict necessity and every applicable safeguard. If the provider proposes using those records to improve unrelated model capabilities, Article 4a does not supply permission for that purpose. The provider would need to establish an Article 6 basis and an Article 9 exception for the proposed processing, while respecting Article 4a's reuse and deletion restrictions. (GDPR, Articles 6, 9; AI Act, Article 4a(1)(a)–(b), (e), (2).)
Further processing in an AI regulatory sandbox
Article 59 creates a separate, bounded route for reusing personal data lawfully collected for other purposes. It concerns development, training and testing inside an AI regulatory sandbox, for the listed substantial-public-interest objectives. A private organisation can qualify, but participation alone does not satisfy the provision. All conditions in Article 59(1)(a)–(j) must be met. Recital 140 explains its relationship to GDPR Articles 6(4) and 9(2)(g), while preserving other data-protection duties and rights. (AI Act, Article 59(1), recital 140.)
The personal data must be necessary for the specified high-risk requirements where anonymised, synthetic or other non-personal data cannot effectively achieve compliance. Processing must occur in the prescribed protected environment and must not lead to measures or decisions affecting the data subjects. Restrictions on sharing, retention and other safeguards also apply. A business cannot extend this permission to ordinary commercial training outside the sandbox or treat it as authorisation to decide people's entitlements during an experiment. (AI Act, Article 59(1)(b)–(j), recital 140.)
Article 59(3) preserves laws that restrict processing to expressly specified purposes and other lawful processing bases. A project outside this particular permission therefore needs assessment under the other applicable rules. Consent to participate in an AI trial also remains distinct from consent to personal-data processing. The controller must establish the latter's requirements, or another applicable basis, for the processing proposed. (AI Act, Article 59(3), recital 141; GDPR, Articles 6–7.)
The personal-data status of a trained model
A trained model requires a separate examination of identifiability. The GDPR covers information relating to an identified or identifiable person, including information that permits indirect identification. Removing direct identifiers or keeping names in a separate file can reduce exposure while leaving the information personal for the party holding the link. The relevant assessment takes account of means reasonably likely to be used for identification. (GDPR, Article 4(1), (5), recital 26.)
The EDPB considers that a model trained with personal data cannot be assumed anonymous. Its assessment concerns personal data about people whose data were used for training. It covers direct extraction from the model and intentional or unintended disclosure through queries. Both likelihoods must be insignificant for any such person, taking account of reasonably likely means. Model access, available additional information, cost, time and technology affect that assessment. A claim that the model contains only statistical parameters does not address those conditions. (EDPB, Opinion 28/2024, paragraphs 36–46.)
The Court of Justice's judgment in EDPS v SRB confirms the need to examine the relevant processing circumstances. It concerned pseudonymised information under the EU institutions' data-protection regulation, whose personal-data definition the Court requires to be interpreted consistently with the GDPR. The Court held that effective safeguards can make information non-personal for a particular recipient. That depends on the recipient's inability to overcome those safeguards or identify people through other reasonably available means. The judgment does not determine the status of AI models as a class. (CJEU, EDPS v SRB, C-413/23 P, ECLI:EU:C:2025:645, paragraphs 52, 75–87, 100.)
The collecting controller's information duty was assessed at collection from its own perspective, before the transfer. A recipient's inability to identify people did not remove that earlier duty. Onward disclosure to parties with available identification means also requires its own examination. Applied to models, an anonymity assessment for a restricted recipient cannot simply be carried over to a different release arrangement. (EDPS v SRB, paragraphs 85, 110–113; EDPB, Opinion 28/2024, paragraphs 41–46.)
Evidence should address the model and conditions actually proposed for use. The EDPB recognises that an internally restricted model and a publicly available model may require different testing. It also cautions that successful tests establish resistance to the attacks tested, rather than a conclusive result against every means of identification. Even where the model itself is anonymous, a service can process personal data in new prompts, retrieved records or outputs. Those operations remain subject to the GDPR according to their own characteristics. (EDPB, Opinion 28/2024, paragraphs 46–48, 55, 134–135.)
Later use following unlawful training
The consequences of unlawful development depend on what the model retains and who performs the later processing. The EDPB's analysis addresses failures of lawfulness under GDPR Articles 5(1)(a) and 6. It requires examination of the particular processing and available corrective measures. Its conclusions should not be extended automatically to every other compliance defect or every later operation. (EDPB, Opinion 28/2024, paragraphs 111–118.)
Where the same controller later processes personal data retained in the model, changing the activity's label to deployment does not resolve the earlier unlawfulness. The authority examines whether the purposes differ and how the initial defect affects the later processing. If the controller invokes legitimate interests, the earlier unlawful processing matters to the risks and reasonable expectations considered in that assessment. An applicable order to erase or restrict the data also affects what processing can continue. (GDPR, Articles 5(1)(a), 6(1)(f), 58(2); EDPB, Opinion 28/2024, paragraphs 119–123.)
Where a different controller processes personal data retained in the model from training, it must establish the lawfulness of that processing. The EDPB expects an appropriate assessment of whether development involved unlawful processing. Relevant matters include the data's source and findings of infringement by a supervisory authority or court. The expected depth varies with the type and degree of deployment risk. This assessment cannot be reduced to accepting a general supplier assurance when known facts call the training's lawfulness into question. (GDPR, Articles 5(1)(a), 5(2), 6, 24; EDPB, Opinion 28/2024, paragraphs 124–132.)
A conformity declaration can form part of that evidence. Annex V to the AI Act includes a statement of compliance with the relevant data-protection rules where the system involves personal-data processing. The EDPB explains that this self-declaration is not a conclusive GDPR finding. For the acquiring business, the declaration's scope and supporting information must be considered against its actual proposed use and any known contrary evidence. (AI Act, Annex V, point 5; EDPB, Opinion 28/2024, paragraph 131.)
Effective anonymisation creates a different position for later processing. If the model's subsequent operation demonstrably involves no personal data, the EDPB considers that operation outside the GDPR. If new personal data are processed after anonymisation, the GDPR applies to those new operations, whose lawfulness should not be affected by the initial unlawful training. These conclusions depend on established anonymity; they do not extinguish supervisory powers over the original development or anonymisation processing. (EDPB, Opinion 28/2024, paragraphs 133–135.)
Corrective measures can therefore affect the commercial ability to use a model. The EDPB identifies restrictions and erasure among the available responses. Where removing the unlawfully processed part is not possible, it contemplates erasure of the dataset or model itself, subject to the facts and proportionality. Retraining and other available corrective measures also bear on that assessment. No automatic rule requires destruction of every model associated with an infringement, but retaining an unlawful processing operation cannot be justified solely by the cost of replacing it. (GDPR, Article 58(2); EDPB, Opinion 28/2024, paragraphs 113–116.)
The consequence for a deployment decision
The business should carry these findings into its decision on whether the proposed processing can proceed. The shared assessment evidence discussed in Part IV can establish facts relevant to each regulation. Notification under Article 27(3) does not satisfy a separately triggered GDPR prior-consultation duty. Where a data protection impact assessment identifies high risk that cannot be sufficiently reduced, Article 36 requires consultation with the data-protection supervisory authority before processing. (GDPR, Articles 35–36, recital 94; AI Act, Article 27(3)–(4).)
Article 27 remains subject to the AI Act's applicable commencement and transitional rules. Those rules do not postpone existing GDPR obligations. Nor does an AI Act conformity result displace a supervisory authority's power to limit or ban personal-data processing. Even certification under the GDPR itself leaves controllers' and processors' responsibilities and supervisory powers intact. The proposed training or deployment must satisfy the applicable processing conditions despite the existence of those assessment or certification records. (AI Act, Articles 2(7), 111(2), 113; GDPR, Articles 42(4), 58(2)(f), 99(2).)
