Two regulatory frameworks, one system

Most AI systems process personal data. This means that both the GDPR and the AI Act apply simultaneously. They are not alternatives nor mutually exclusive: they are cumulative. A high-risk system that processes personal data must comply with all Title III requirements of the AI Act and all principles and obligations of the GDPR.

Article 2(7) of the AI Act expressly states: "This Regulation shall be without prejudice to Union law on the protection of personal data, privacy and confidentiality of communications." There is no precedence of one regulation over the other. Both apply in full.

Critical intersection points

• Data governance: Article 10 of the AI Act requires representative, complete and statistically adequate training data. The GDPR requires minimisation, purpose limitation and storage limitation. These requirements can create tension.
• Transparency: the AI Act (Art. 13) requires information about the system's capabilities and limitations. The GDPR (Arts. 13-14) requires information about data processing, including the logic involved in automated decisions.
• Human oversight: the AI Act (Art. 14) requires effective human oversight. The GDPR (Art. 22) grants the right not to be subject to decisions based solely on automated processing.
• Impact assessment: the AI Act requires a fundamental rights impact assessment (FRIA, Art. 27). The GDPR requires a data protection impact assessment (DPIA, Art. 35). In many cases, both are mandatory for the same system.

Legal bases for AI with personal data

All processing of personal data needs a legal basis under Article 6 of the GDPR. AI systems are no exception. These are the most relevant bases:

Consent (Art. 6(1)(a) GDPR)

For use of data in model training: consent must be specific (not generic), informed (including the nature of AI processing), freely given (not conditional on a service) and revocable (with clear practical consequences). The challenge with AI: revoking consent may not be feasible if the model was already trained with that data. The EDPB has indicated that revocation of consent does not require "unlearning" a model if it is technically and proportionately unfeasible, but it does require ceasing the future use of that data.

Legitimate interest (Art. 6(1)(f) GDPR)

A frequent basis for AI systems in areas such as fraud prevention, network security, product improvement. Requires the three-part test: real legitimate interest, necessity of processing, and balancing against the data subject's rights. The necessity assessment is particularly demanding for AI: you must demonstrate that there are no less intrusive means to achieve the same objective.

Performance of a contract (Art. 6(1)(b) GDPR)

Applicable when AI is necessary to deliver a contracted service (for example, a support chatbot for a service the user has contracted). Not valid for inferences about the user that go beyond what is necessary for the service.

Legal obligation (Art. 6(1)(c) GDPR)

If a law requires the processing (for example, anti-money laundering detection), this basis may cover the use of AI. But the legal obligation must be sufficiently specific: "we have to comply with anti-fraud regulation" is not enough.

Special category data (Art. 9 GDPR)

AI systems that process biometric data, health data, genetic data, data revealing racial or ethnic origin, political opinions, religious beliefs, trade union membership or sexual orientation additionally need an exception under Article 9(2) GDPR. Explicit consent is the most common pathway, but not always possible (especially in the employment context where consent is not freely given).

Coordinated DPIA: GDPR + AI Act

Article 27(4) of the AI Act expressly states that the fundamental rights impact assessment (FRIA) may be integrated with the DPIA under Article 35 GDPR. This integration is the recommended approach: it avoids duplication and generates a holistic view of the system's impact.

Structure of an integrated DPIA/FRIA

Part 1: System and processing description

• AI system description: provider, functionality, model type, input/output data.
• Data processing description: purpose, data categories, data subject categories, recipients, retention periods.
• Role in the value chain: provider or deployer under the AI Act; controller or processor under the GDPR.

Part 2: Necessity and proportionality (GDPR)

• Legal basis and justification.
• Minimisation principle: are only necessary data processed?
• Purpose limitation: are data used only for the declared purpose?
• Accuracy: mechanisms to ensure data quality.
• Storage limitation: how long are data retained and why.

Part 3: Risk assessment for rights and freedoms (GDPR + AI Act)

• Discrimination risks (algorithmic bias by gender, age, origin, disability).
• Opacity risks (inability to explain decisions to the data subject).
• Exclusion risks (persons excluded from services by automated decisions).
• Risks to individual autonomy (manipulation, excessive nudging).
• Risks to physical safety (if the system controls physical environments).
• Impact on vulnerable groups: minors, persons with disabilities, older persons, persons in situations of economic vulnerability.

Part 4: Mitigation measures

• Technical measures: anonymisation, pseudonymisation, fairness testing, adversarial testing, encryption.
• Organisational measures: human oversight, staff training, escalation procedures, periodic audits.
• Transparency measures: information to data subjects, instructions for use for the deployer, labelling of generated content.
• Governance measures: AI committee, internal policies, updated records of processing activities.

Part 5: Conclusion and action plan

• Is the residual risk acceptable? Yes/no and justification.
• Need for prior consultation with the data protection authority (Art. 36 GDPR)?
• Action plan with measures, responsible parties, deadlines and monitoring metrics.
• Next review date.

Data subject rights before AI systems

GDPR rights apply in full when an AI system processes personal data. But their exercise poses specific challenges:

Right of access (Art. 15 GDPR)

The data subject has the right to know whether their data is processed by an AI system, the purpose of processing, the categories of data and, in the case of automated decisions, "meaningful information about the logic involved". This last point is the most complex: what does "logic involved" mean when the system is a neural network with millions of parameters? The majority position of data protection authorities: it is not required to reveal the algorithm, but to explain the main factors influencing the decision and their relative weight.

Right to rectification (Art. 16 GDPR)

If the data used by the system is inaccurate, the data subject can demand its rectification. In AI systems, this raises the question of whether rectifying the input data produces a change in the system's decision. The controller must be able to demonstrate that corrected data is reflected in future inferences.

Right to erasure (Art. 17 GDPR)

The right to be forgotten applies to personal data processed by AI. The challenge: if the data was used to train a model, "deleting" the data does not undo the model's learning. The EDPB has indicated that deletion of training data is sufficient if retraining the model is disproportionate, provided that the model does not allow reconstruction of the original data.

Right to object (Art. 21 GDPR)

Especially relevant when the legal basis is legitimate interest. The data subject may object to processing on grounds relating to their particular situation. The controller must demonstrate "compelling legitimate grounds" to continue processing. In the AI context, mere operational convenience is usually not a sufficient ground.

Article 22 GDPR and AI Act human oversight

Article 22 GDPR grants 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. Article 14 of the AI Act requires effective human oversight.

Key differences

• Scope: Art. 22 GDPR applies to all automated decisions with legal or significant effects. Art. 14 AI Act applies only to high-risk systems.
• Approach: Art. 22 GDPR is a data subject right (prohibition with exceptions). Art. 14 AI Act is a provider/deployer obligation (system design).
• Exception: Art. 22(2)(c) GDPR permits automated decisions with explicit consent. The AI Act does not have this exception: human oversight is mandatory for high-risk systems regardless of consent.

Joint practical implementation

For a high-risk system that processes personal data and makes decisions with significant effects:

1. The decision cannot be "solely" automated: meaningful human intervention is needed (not rubber-stamping).
2. The human overseeing must have the competence, authority and access to the information necessary to modify or reverse the decision.
3. The data subject must be able to request human intervention, express their point of view and contest the decision (Art. 22(3) GDPR).
4. The system must be designed to enable all of the above (Art. 14 AI Act).

Data governance: Article 10 AI Act and GDPR principles

Article 10 of the AI Act establishes specific requirements for training, validation and testing data of high-risk systems. These requirements interact with (and sometimes conflict with) GDPR principles.

Representativeness vs. minimisation

The AI Act requires data to be "representative" of the system's context of use. To avoid bias, this may require collecting data from protected groups (racial or ethnic origin, gender, age, disability). The GDPR requires minimisation: only the data strictly necessary. Article 10(5) of the AI Act partially resolves this tension: it allows the processing of special category data (Art. 9 GDPR) "to the extent strictly necessary" for bias detection and correction, with appropriate safeguards. This is a legal basis from the AI Act that complements the GDPR.

Data quality vs. storage limitation

The AI Act requires data to be "free from errors, complete and up to date". Maintaining this quality may require retaining data for long periods. The GDPR requires that data not be kept longer than necessary for the purpose. The practical solution: documentedly justify that extended retention is necessary for AI system quality, with periodic reviews of whether retention remains proportionate.

Integrated documentation

Maintaining separate documentation for GDPR and AI Act generates duplication, inconsistencies and maintenance costs. The recommended approach is an integrated documentation system:

Document map

• Records of processing activities (Art. 30 GDPR): extend with additional fields: AI Act classification, AI system type, risk level, classification date.
• Technical documentation (Annex IV AI Act): include a GDPR compliance section: legal basis, integrated DPIA, data protection measures.
• Integrated DPIA/FRIA: as described above.
• Information to the data subject (Arts. 13-14 GDPR + Art. 13 AI Act): a single privacy notice that includes both GDPR information and AI Act information (capabilities, limitations, human oversight).
• Contracts with providers: GDPR clauses (data processor) + AI Act clauses (provider/importer obligations).

DPO and AI Officer: practical coordination

The GDPR requires a DPO in certain organizations. The AI Act does not formally create an "AI Officer", but practice and AI Office guidance recommend designating a person responsible for AI governance. Coordination between both roles is essential.

Coordination model

• Option 1: DPO takes on AI governance. Viable in small/medium organizations with few AI systems. Advantage: unified vision. Risk: DPO overload, lack of technical competence in AI.
• Option 2: Separate AI Officer reporting to the DPO. The AI Officer manages classification, technical documentation, conformity. The DPO oversees the personal data dimension. They meet periodically (recommended: biweekly).
• Option 3: AI committee with DPO participation. A multidisciplinary committee (legal, technical, business, DPO) governs AI in the organization. The DPO has voice and vote on all decisions affecting personal data.

Mandatory coordination points

• Any new acquisition or development of an AI system that processes personal data.
• Integrated DPIAs/FRIAs.
• Incidents affecting both personal data and AI system security.
• Data subject rights requests related to automated decisions.
• Internal and external audits.
• Regulatory changes (AI Act delegated acts, EDPB guidance, AESIA guidance).

International transfers and AI

International transfers of personal data in the AI context present specific challenges:

AI as a Service (AIaaS) models

When your organization uses an AI model hosted outside the EEA (for example, OpenAI in the US, DeepSeek in China), the input data sent to the model is an international transfer. You need a valid mechanism under GDPR Chapter V: adequacy decision (Data Privacy Framework for the US), standard contractual clauses (SCCs) or Article 49 GDPR derogations.

Training with European data outside the EEA

If a provider trains their model with European personal data on servers outside the EEA, the GDPR applies. This includes web scraping of European data. The provider needs a legal basis for the processing and a mechanism for the transfer.

Practical implication

For organizations subject to ENS Alto, NIS2 or with sensitive data: the preferred solution is to use models hosted in the EU (self-hosted models, providers with EU regions) to avoid the complexity of international transfers and the risk of access by third-country authorities.

Ejercicio practico

Puntos clave