The overlap between the AI Act and the GDPR. Compliance challenges for Romanian companies using artificial intelligence

I. A two-stage regulatory framework

There is a certain unpleasant symmetry in the way Romanian companies have come to confront Regulation (EU) 2024/1689 on artificial intelligence, or the AI Act in business terminology. Just as, in 2018, organisations suddenly discovered that they had accumulated years of practices that failed to comply with data protection requirements, today many economic operators are already using artificial intelligence systems without having assessed which risk category these fall into or what obligations arise from such use.

The difference from 2018 is that, this time, they are not starting from scratch, or at least they should not be. The compliance infrastructure built around the GDPR provides a useful skeleton, although the architecture of the AI Act does not map perfectly onto it. The two instruments follow different logics, pursue different purposes and establish distinct oversight mechanisms. Where they intersect, the tensions are real and, at times, difficult to resolve.

This article is not intended as a compliance guide, but rather as a map of regulatory conflicts, a description of the operational dilemmas that companies will encounter in practice and, where possible, a proposal for a reasonable response.

II. Two regulations, one company

The AI Act and the GDPR are instruments with different DNA. The GDPR is, in essence, a regulation of individual rights, aimed at protecting the natural person against the processing of personal data, regardless of the technical context in which such processing takes place. The AI Act, by contrast, operates according to an entirely different logic. It does not start from the affected person, but from the system that may affect them, which it classifies according to the risk it presents and around which it distributes obligations among all the actors involved, from the one who designed the algorithm to the one who uses it in the course of their professional activity.

This difference in perspective matters enormously in practice. Under the GDPR, the unit of analysis is the natural person and the extent to which their rights are respected by the organisation. Under the AI Act, the unit of analysis is the technical system (i.e., the algorithm, the model, the application) and its effects on categories of persons or on vital fields. An artificial intelligence system may not process personal data and yet still fall within the scope of the AI Act. Conversely, a personal data processing tool may not be an artificial intelligence system within the meaning of the AI Act.

But the grey area - namely, the scenario in which an artificial intelligence system processes personal data - is vast and populated by almost all of today's relevant commercial applications: automated recruitment systems, credit scoring, AI-assisted medical diagnosis, fraud detection, recommendation systems, chat applications that integrate AI. Companies using any of these must apply both regulatory frameworks simultaneously, which raises a fundamental issue of compliance architecture.

III. Areas of tension: a collision between the two regulations

1. Input data and the data minimisation principle

Through the data minimisation principle, the GDPR requires that the data processed be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed. This principle is both a standard of conduct and a criterion for the lawfulness of processing.

The AI Act does not contain a symmetrical principle. Moreover, the data quality requirements imposed on high-risk systems implicitly presuppose extensive, representative data sets free of systematic errors. Testing an automated recruitment model to detect and eliminate discrimination on grounds of age or gender requires, by its very nature, access to large volumes of historical data, including data which, from a GDPR perspective, may exceed the current purpose of the processing.

The tension is not irreconcilable, but nor does it resolve itself. The solution involves two distinct measures. The first is establishing a clear legal basis for the processing of data carried out for the purpose of testing and validating the model, usually the legitimate interest of the controller or a specific legal provision. The second is separate documentation for each phase of the system's life cycle, whether we are talking about training, testing or production. Without this separation, a company may find itself in a paradoxical situation, in which the artificial intelligence model complies with the AI Act precisely because it was trained on large volumes of data, but those same volumes place it in breach of the GDPR, by exceeding the stated purpose of the processing.

2. The right to explanation between the GDPR and the AI Act

Article 22 GDPR prohibits decisions based solely on automated processing which produce legal effects concerning the data subject or which significantly affect them, subject to certain exceptions. Where the exceptions apply, the European rule requires the controller to ensure the data subject's right to human intervention, the right to express their point of view and the right to contest the decision. Although the “right to explanation” does not appear as a distinct right in the text of the article, it has been inferred from the recitals of the GDPR, and implies that the data subject should be able to obtain an explanation regarding the automated decision taken in relation to them.

The AI Act comes with a more explicit construction. Article 86 recognises the right of persons affected by decisions taken with the support of a high-risk system to obtain an explanation of the role of that system in the decision-making process, as well as the right to a human review of the decision.

The two instruments thus turn out to be closer to one another than they appear at first reading. If the decision was exclusively automated, and the artificial intelligence system is the decision-making mechanism itself, explaining its role and the main elements of the decision covers a good part of what the GDPR requires under the right to an explanation. The remaining difference is one of depth, not of subject-matter. The GDPR points to the logic applied to the individual case of the data subject concerned, not merely to the main elements of the decision as a type. This apparently technical nuance becomes significant when the data subject wants to understand not what the system weighed in general, but why it weighed matters differently in their case.

The practical consequence is that a company receiving a request to exercise this right to an explanation must construct a response that simultaneously satisfies both levels: the one regulated by art. 86 AI Act, concerning the role of the system and the main elements of the decision, and the one indicated by Art. 22 GDPR, concerning the individualised logic applied to the specific case. If the organisation has not documented how the system's outputs translated into the individual decision, the response will inevitably be incomplete as regards one of the two instruments.

There are at least three tensions that further complicate this construction.

The first concerns the scope of application. Art. 22 GDPR targets decisions based solely on automated processing, that is, those in which no human judgment intervenes in the causal chain. Art. 86 AI Act also applies to decisions taken with the support of an artificial intelligence system, including where human intervention formally exists. A company that introduces a human validation step may fall outside the scope of art. 22 GDPR, but remains within the scope of art. 86 AI Act if the system used is classified as high-risk. The obligation to provide an explanation survives, even if the legal basis shifts.

The second concerns opaque models, and is perhaps the most significant. Neural network-type systems (in English large language models), by their very nature cannot provide a clear description of the system's role in the decision, nor an individualised explanation of the logic applied, without additional interpretability tools. A company using such a model may find itself unable to simultaneously honour the requirements of both instruments, not out of lack of legal willingness, but out of lack of technical capacity. For every organisation that has acquired a black-box system and integrated it into decision-making processes with significant effects on individuals, this appears to be becoming a pressing issue with the entry into force of the AI Act.

The third concerns the timing and form of the explanation. Art. 86 AI Act requires an explanation of the main elements of the decision, a formulation that can be satisfied by a response describing the categories of factors taken into account. The GDPR, by contrast, points to something more specific, namely the logic applied to that person's case. The difference is not one of principle, but of granularity, and becomes visible when the data subject is not content to learn what generally matters in such decisions, but wants to understand what mattered in the decision taken in their regard. If the deployer acquired the system from an external provider and did not receive adequate technical documentation, it finds itself owing an explanation it cannot formulate.

3. Impact assessments: DPIA versus FRIA

The GDPR requires a data protection impact assessment (DPIA) to be carried out whenever the processing is likely to result in a high risk to the rights and freedoms of natural persons. The National Supervisory Authority for Personal Data Processing (ANSPDCP) has published lists of types of processing that mandatorily require a DPIA, including large-scale profiling, systematic monitoring, and the processing of sensitive data.

The AI Act introduces, for deployers of high-risk systems, a fundamental rights impact assessment, also known by the acronym FRIA. This follows a different logic from the DPIA required under the GDPR, since it does not focus exclusively on personal data, but on the broader impact of the artificial intelligence system on the rights and freedoms guaranteed by the Charter of Fundamental Rights of the European Union.

The practical problem is that few companies have the capacity to run both simultaneously. The methodologies differ, the deadlines differ, and the competent supervisory authorities are not the same. The Regulation itself anticipated this difficulty, allowing deployers who have already carried out an impact assessment under the GDPR to make use of it for FRIA purposes as well. The template that should practically facilitate this exercise has not yet been published, which leaves organisations to build their own methodologies based on the requirements of the Regulation.

Romania's supervisory landscape adds a further layer of complexity. Competence for the AI Act does not rest with a single authority, but with several, depending on the sector concerned. What is relevant to the relationship between the two instruments is that the ANSPDCP, which supervises compliance with the GDPR, also takes on a portion of AI Act supervision, for certain high-risk systems in the areas of law enforcement, border management and the administration of justice. Where the same organisation answers to the same authority under both instruments, the picture is clearer. Where it does not, coordination remains an unformed mechanism, and companies still do not know to whom they must account and to whom they must justify themselves.

To this is added a question that few companies have explicitly asked themselves, namely the internal distribution of responsibility for both assessments. The most frequent answer in practice, and the most questionable one, is the data protection officer. Why this is questionable will be examined in the following section.

4. The controller-processor relationship in AI system supply chains

Under the GDPR, the distinction between controller and processor is well established, both doctrinally and in case law. Under the AI Act, the same entities appear under the names of provider, that is, the one who places the AI system on the market or puts it into service, and deployer, that is, the one who uses the system within its business activity.

The two pairs of concepts do not overlap. A company may be a controller under the GDPR, in the sense that it decides the purpose and means of processing personal data, while at the same time being a deployer under the AI Act, in the sense that it has not developed the artificial intelligence model but uses it. The provider of the artificial intelligence model may be a processor under the GDPR, processing data on behalf of the controller, and a provider under the AI Act, being responsible for the technical documentation and compliance of the AI system.

This lack of correlation has direct legal consequences for the allocation of liability. An AI chatbot based on a large language model, supplied by a company outside the European Union, can simultaneously generate liability for the provider under the AI Act and for the Romanian company under the GDPR. Contracts for the acquisition of such services must be drafted with careful attention to both levels of liability allocation, which at present does not happen in the vast majority of cases.

IV. Who is responsible? The DPO and its new reality

The GDPR required the appointment of a data protection officer (DPO) for certain categories of controllers, including public authorities, controllers carrying out large-scale systematic monitoring, or those processing special categories of data on a large scale. Its role is clearly delimited, with duties relating to informing and advising, monitoring compliance, cooperating with the supervisory authority, and serving as a point of contact for data subjects. Crucially, the GDPR guarantees its independence. The DPO does not receive instructions regarding the exercise of its tasks and cannot be dismissed or penalised for performing them.

The AI Act does not establish an equivalent role. There is no regulated artificial intelligence officer as such, although some large European companies have chosen to voluntarily create such a function. In this legislative vacuum, the practical pressure coming from management structures wishing to have a single point of responsibility for all digital compliance matters naturally shifts towards the data protection officer, this already being an existing function within the organisation, with potentially suitable training to also deal with the AI Act.

This is, however, a flawed logic, given that this solution raises legal and organisational dilemmas in at least three respects.

1. The structural conflict of interest

By the very nature of its mandate, the DPO has a potentially conflictual relationship with the rest of the organisation. Its role is to identify non-compliance and report it, not to approve or validate business decisions. Its independence is guaranteed precisely because otherwise it would be tempted or pressured to minimise the issues identified.

If the same DPO becomes responsible for AI Act compliance, they end up assessing artificial intelligence systems that process personal data, in other words, evaluating whether a system complies with both the GDPR and the AI Act. But assessing the compliance of an artificial intelligence system under the AI Act often involves validating technical and organisational choices which, viewed from a GDPR perspective, could raise objections. A DPO who approves an automated recruitment system from an AI Act perspective is placed in a position of minimising, consciously or not, the reservations they would otherwise raise as guardian of GDPR compliance.

In other words, the accumulation of roles de facto transforms an independent control mechanism into a self-validation one. The DPO's independence, guaranteed by the GDPR, becomes merely formal where the DPO is assessing systems which, from another angle, they ought to be critically supervising.

2. Technical competence and the limits of the mandate

The GDPR allowed the DPO to be appointed on the basis of legal and regulatory knowledge in data protection matters. The AI Act requires a technical-functional understanding of artificial intelligence systems, including the management of training datasets, technical documentation, risk management procedures, robustness testing, and the avoidance of systematic errors. These are competences which most data protection officers do not possess, and cannot be expected to possess, under their current mandate. Imposing them retroactively means either changing the profile of the role without a clear regulatory basis, or accepting that AI Act compliance is carried out superficially.

3. The problem of the external DPO

A characteristic of the Romanian market is the relatively high proportion of companies which have secured DPO services through outsourcing, either by engaging a lawyer or by turning to a specialised consultancy firm. This structure, perfectly legal under the GDPR, raises further questions in the context of the AI Act.

The first question that arises is who is liable for the non-compliance of an artificial intelligence system - the company or the external DPO who approved the implementation? The rigorous legal answer is that the DPO cannot be held directly liable for the controller's non-compliance, as this remains the organisation's responsibility, but the DPO may incur contractual or professional liability if they issued erroneous or incomplete opinions. The problem is that, in practice, outsourced DPO contracts are not structured to cover compliance with AI Act, and the boundaries are often blurred.

Secondly, there is a risk of horizontal conflict of interest. An external DPO providing services to several companies in the same sector, and approving similar systems, may find themselves applying inconsistent standards or, even involuntarily, favouring one client over another in how they interpret the requirements. The current framework does not explicitly regulate this situation, nor does it provide a mechanism for flagging it.

Conclusions

Romanian companies using artificial intelligence systems currently find themselves within a window of time that will not last long. The obligations set out in AI Act for high-risk systems have entered, or are about to enter, into force in stages. Supervisory authorities will begin enforcing the rules, and experience with GDPR shows that, after an informal grace period, sanctions follow consistently.

The tensions described in the previous sections are not implementation accidents. They are the natural consequence of two legislators who started from different premises and built instruments with different logics, without first resolving the issue of how they interact. GDPR protects the individual in relation to the processing of their data. AI Act manages the risk that a technical product poses to categories of persons or to social values. When the two perspectives intersect, which happens whenever an artificial intelligence system processes personal data, there is no pre-established reconciliation mechanism. There are two sets of rules, two sets of authorities, and an organisation caught between them.

The risk is not abstract; it is concrete and twofold. A company that has not mapped its artificial intelligence systems and has not integrated compliance with AI Act into its existing data protection infrastructure risks being sanctioned by two different authorities, for two different sets of non-compliance, with fines that, combined, can reach significant thresholds.

There is also a subtler risk, of a reputational and contractual nature. Business partners, especially those in jurisdictions with a more advanced compliance culture, will increasingly request evidence of compliance with AI Act. Companies that have not prepared this documentation will lose out, not only before the authorities, but also in the market.

The paradox is that GDPR infrastructure, if built seriously and not merely formally, offers a valuable starting point. Impact assessments, processing registers, incident response mechanisms, contractual structures with suppliers - all of these can be adapted, rather than built from scratch. But adaptation requires understanding the differences, not assuming the similarities. And, at present, this understanding is lacking in too many organisations.

The most costly thing will not be compliance. It will be ignoring the need for it until there is no other option left.