The extraterritorial reach of the EU AI Act: a compliance framework for Turkish companies

The EU Artificial Intelligence Act was approved by the European Parliament on 14 March 2024 and its provisions have entered into force in stages. A significant proportion of companies established in Türkiye proceed on the assumption that the regulation does not concern them.

That assumption is mistaken. Its source is a misreading of the connecting factor the regulation uses.

The legal basis of extraterritorial reach

The AI Act looks not at where the system was developed but at where its output is used. A provider that places products or services on the EU market, or whose AI system produces output used within the EU, falls within scope even though it is established in Türkiye.

In this respect the regulation affects not only actors in EU member states but every actor seeking access to the EU market or interacting indirectly with the EU.

In practice this covers a wide field: manufacturers that export; technology companies supplying software services to customers in the EU; service providers processing the data of a customer established in the EU; and manufacturers whose products generate output in the EU through an embedded model.

The name given to this effect in the literature is the Brussels effect: EU regulation determining, by virtue of market size, the conduct of actors outside the Union.

Risk classification: which category are we in?

The AI Act divides systems into four categories by risk level and imposes different conformity, transparency, accountability and safety requirements on each.

Unacceptable risk. Set out in Article 5/1 (a)–(f). Practices that interfere with individuals’ decision-making through subliminal, manipulative or deceptive techniques and thereby cause harm to that person or to others are prohibited.

High risk. This is where obligations concentrate. Conformity assessment procedures apply: technical documentation, conformity testing, checklists and CE marking.

Limited risk and minimal risk attract transparency obligations in essence.

The first step in any compliance exercise is this classification. Without it the scope of the obligations cannot be determined; and if the classification is wrong, the entire compliance exercise is aimed at the wrong target.

The obligations are organisational, not technical

A frequently overlooked feature of the regulation is that its obligations do not end at the software layer.

For high-risk systems the headings required are:

• establishing and maintaining a risk management system
• data governance — requirements as to the quality of training, validation and testing data
• technical documentation and record-keeping
• transparency and the provision of information to users
• human oversight
• accuracy, robustness and cybersecurity

None of these is a software feature on its own. Each requires a process to be defined, an owner to be identified and the result to be documented. Compliance is therefore a matter of organisational process design, not of development work.

Obligations continue after placing on the market

The assumption that compliance is a one-off certification exercise is another common error.

The provider is obliged to carry out post-market monitoring of performance and to assess risks that may arise. Where a system gives rise to serious risk, the provider must initiate a recall and notify the Commission and the competent authority.

This obligation takes on particular weight in continuously learning systems. A system that was conforming when placed on the market may lose that conformity during the learning process. Monitoring is therefore an audit not of the fact that conformity has been maintained, but of whether it has been.

Allocation of obligations among actors

Rather than conferring legal personality, the AI Act establishes a human-centred chain of responsibility. Providers, deployers, importers and distributors assume obligations according to their roles.

In practice the division operates as follows:

• The manufacturer is responsible for design, development and first placing on the market, and for technical preparation and the risk-class conformity assessment.
• The software developer is responsible for the algorithmic architecture, the preparation of training data and the training of the model. The quality of the data set and its freedom from bias, and the transparency, traceability and explicability of the system, fall to this actor.
• The user is obliged to use the system for its defined purpose and to ensure human oversight.

This division arises from the regulation; how it is reflected in the internal relationship between the parties, however, depends on contract. If the supply agreement does not record who assumes which obligation, then when a public-law obligation is not met the right of recourse in the internal relationship is left unresolved.

Interaction with other instruments

The AI Act cannot be assessed in isolation. The GDPR governs the administrative and technical requirements for collecting and processing the data sets that are the primary input of AI systems. The Digital Services Act (DSA) and the Digital Markets Act (DMA), in force since 2022, provide for algorithmic audit mechanisms for systems operating on online platforms.

On the institutional side, the European Artificial Intelligence Board coordinates application, while CEN/CENELEC JTC 21 develops the technical standards. As those standards are still maturing, any compliance exercise must include tracking that process.

Where to begin

For a company uncertain whether it is within scope, the sequence is:

1. Inventory. Which AI systems are used in the company, which are being developed, and whose output is used in the EU?
2. Role identification. For each system, is the company a provider, a deployer, an importer or a distributor?
3. Risk classification. Into which category does each system fall?
4. Gap analysis. Which of the obligations required by that category are already met?
5. Contractual reflection. Is the allocation of obligations recorded in supplier and customer agreements?

The first three steps are an exercise in legal characterisation and not something a technical team can carry out alone. The last determines which party bears the cost of compliance; it is here that the most expensive clause usually turns out to be the one never written into the contract.

---

This article is provided for general information purposes and does not constitute legal advice. Assessment of the scope and risk class of a specific system requires separate examination.