EU AI Act: Scope (1 of 10)

By Kevin M. Hyams 

Why I wrote this article

I wrote this article because EU AI Act scope decisions are too important to rest on convenient assumptions. Compliance practitioners need a practical way to determine which requirements apply to each AI system, model, use case and operator role, while recognising that organisations outside the EU and users of free and open-source AI may still be in scope.

Many organisations begin their EU AI Act assessment with one of two assumptions:

• “We do not have an office or legal entity in the European Union, so the Act does not apply to us.”
• “We use a free and open-source AI product, so we are exempt from the Act.”

Neither assumption is a safe basis for a compliance decision.

For most compliance practitioners, the immediate priority will be determining how the EU AI Act applies to AI systems developed, supplied or used within their own EU-based organisation. However, a reliable scope assessment must look beyond the organisation’s location and beyond the licence attached to the technology.

The EU AI Act applies through a combination of factors, including:

• what the organisation does in relation to the AI system or model;
• where the system or model is placed on the market or put into service;
• where the organisation using the system is established;
• where the system’s output is used;
• the intended purpose and actual use of the system;
• whether a statutory exclusion applies; and
• whether the system is high-risk, involves a prohibited practice or creates a transparency obligation.

The practical message is straightforward: assess scope for each relevant AI system, model, use case, legal entity, and operator role. It should not be inferred from one fact alone.

This is the practical problem NORVA is designed to solve. NORVA helps compliance teams answer one simple question:

“Are we meeting the requirements that apply to us?”

Answering that question begins with a clear, evidence-based determination of scope, role, exclusions and classification. Without that foundation, organisations can overlook obligations, activate the wrong assessment path or rely on an exclusion that does not apply.

EU organisations should start with their activities, not just their location

For organisations established in the EU, location is an important starting point, but it is not the complete assessment.

Article 2 brings several different participants within the Act’s scope, including:

• providers placing AI systems on the EU market or putting them into service;
• providers placing general-purpose AI models on the EU market;
• deployers established or located within the EU;
• importers and distributors;
• product manufacturers placing an AI system on the market or putting it into service with their product and under their own name or trade mark;
• authorised representatives of providers not established in the EU; and
• affected persons located within the EU.

An EU-based organisation may therefore need to assess more than whether it “uses AI”.

It may be:

• deploying a third-party AI system under its authority;
• importing or distributing an AI system;
• integrating an AI system into a product;
• providing an internally developed system to another entity;
• placing a system on the market under its own brand;
• modifying an existing system in a way that changes its responsibilities; or
• performing several roles at the same time.

The organisation’s role can determine which obligations apply. A role assessment should therefore consider contracts, branding, supply arrangements, operational authority and what happens in practice, not merely the description used by the organisation or its technology supplier.

The first misconception: “No EU office means no EU AI Act”

The EU AI Act is an EU regulation, but its scope is not restricted to organisations incorporated or physically located in the EU.

It applies to providers placing AI systems on the EU market, putting AI systems into service in the EU or placing general-purpose AI models on the EU market, regardless of whether those providers are established in the EU or in a third country. It can also apply to providers and deployers located outside the EU where the output produced by the AI system is used in the EU.

Recital 22 explains the reasoning. An EU operator might contract with an organisation outside the EU to perform an activity using AI. The overseas system could process data transferred from the EU and return its output to an EU organisation without the system itself being placed on the EU market or used directly within the EU. The Act addresses that possibility by extending scope to third-country providers and deployers where the output is intended for use in the EU.

This means that an organisation outside the EU should not base its scope conclusion solely on the absence of:

• an EU office;
• an EU subsidiary;
• EU-based servers;
• EU-based developers; or
• a physical installation within the EU.

Instead, it should examine whether it:

• provides an AI system or general-purpose AI model for the EU market;
• puts an AI system into service in the EU;
• supplies an AI-enabled product under its own name or trade mark;
• acts through an EU importer, distributor or authorised representative; or
• produces AI system outputs that are intended to be used in the EU.

This remains an important implication for global organisations and international supply chains. However, it should form part of the overall scope assessment rather than being treated as the entire EU AI Act story.

The second misconception: “Open-source AI is automatically exempt”

The use of free and open-source AI does not automatically remove an organisation or every affected system from the EU AI Act.

Article 2 provides that the Regulation does not apply to AI systems released under free and open-source licences unless they are placed on the market or put into service as:

• high-risk AI systems;
• AI systems falling under Article 5; or
• AI systems falling under Article 50.

This qualification is critical.

A compliance practitioner should not stop the assessment after confirming that software, a model or another AI component is described as “open source”. The practitioner must still determine:

• Whether the relevant product genuinely falls within the applicable free and open-source provision.
• What the organisation does with it.
• Whether the resulting AI system is high-risk.
• Whether its intended purpose or use may involve a prohibited practice under Article 5.
• Whether its functions or outputs create transparency obligations under Article 50.
• Whether modification, fine-tuning, integration, branding or onward provision changes the organisation’s role or responsibilities.

The licence is therefore one part of the assessment. It does not replace role determination, use-case analysis or risk classification.

H3: Open-source components and deployed systems are not necessarily the same thing

Compliance teams should also distinguish between:

• an open-source model or component;
• the AI system into which it is integrated;
• the organisation that modifies or configures it;
• the organisation that provides the completed system; and
• the organisation that deploys the system under its authority.

An organisation may use open-source technology as one component of a commercial or operational AI system. The finished system may have a different intended purpose, operating context and risk classification from the underlying component.

For example, the relevant compliance issue may not be the licence attached to the base model. It may be how the completed system is used to:

• support access to an essential service;
• influence employment or worker-management decisions;
• perform biometric functions;
• generate or manipulate content;
• make recommendations affecting individuals; or
• support another use case covered by the Act.

The correct question is not simply, “Is this open source?”

It is:

What is the resulting AI system, what is it intended to do, who performs each operator role, and which EU AI Act provisions apply to that particular use?

Scope exclusions are conditional, not blanket exemptions

The free and open-source provision is not the only area in which organisations may reach an overbroad conclusion.

Article 2 also addresses circumstances involving:

• military, defence and national-security purposes;
• qualifying scientific research and development;
• research, testing or development before market placement or putting into service;
• purely personal, non-professional use; and
• certain uses by third-country public authorities or international organisations.

These provisions contain specific conditions.

For example:

• The military, defence and national-security exclusion depends on exclusive use for the excluded purpose. The official recitals explain that a system with both excluded and non-excluded purposes can fall within the Act.
• The scientific research and development exclusion concerns systems or models specifically developed and put into service for that sole purpose.
• The pre-market research, testing and development exclusion does not cover testing in real-world conditions.
• The personal-use provision concerns deployers who are natural persons using AI in a purely personal, non-professional activity.
• The free and open-source provision does not remove high-risk systems or systems falling under Articles 5 or 50 from the Act’s scope. The practical risk is treating a limited exclusion as if it removed the technology, organisation or use case from every requirement indefinitely.

A defensible assessment should record:

• the precise legal provision relied upon;
• every condition that must be satisfied;
• the facts supporting the conclusion;
• the available evidence;
• the person approving the conclusion; and
• the changes that would trigger reassessment.

Scope assessment should be system-specific and evidence-based

A reliable scope assessment should follow a structured sequence.

1. Identify the relevant AI system or model

Define what is being assessed. Avoid treating an entire technology portfolio, supplier relationship or business unit as one undifferentiated item.

2. Identify the legal entities and operating locations

Record who develops, provides, imports, distributes, modifies or uses the system, and where each relevant entity is established.

3. Determine each operator role

An organisation may perform several roles. Each role and its resulting obligations should be assessed separately.

4. Trace market placement, use and outputs

Determine where the system or model is supplied, made available, put into service and used. Where an overseas organisation is involved, trace where the system’s output is intended to be used.

5. Test every claimed exclusion

Identify the exact provision, confirm every condition and retain evidence supporting the conclusion.

6. Complete the relevant classification

Determine whether the system:

• involves a prohibited practice;
• is high-risk under Article 6;
• may qualify for the Article 6(3) exception;
• creates an Article 50 transparency obligation; or
• involves a general-purpose AI model and any related classification.

The Act uses a risk-based approach that includes prohibited practices, requirements for high-risk AI systems and transparency obligations for certain other systems.

7. Route the result to the applicable obligations

A scope assessment should produce an actionable outcome. It should identify which further compliance requirements apply, who owns them, and what must be assessed next.

8. Establish reassessment triggers

Scope and role conclusions may change when the organisation changes:

• the system’s intended purpose;
• its functionality or model;
• the data used;
• the deployment context;
• the parties in the supply chain;
• its branding;
• where outputs are used; or
• how the system is marketed or supplied.

The practical conclusion for compliance practitioners

The EU AI Act’s scope cannot be reduced to a simple test of organisational location or software licensing.

For EU organisations, the central task is to understand their systems, use cases, roles, classifications and supply-chain relationships.

For organisations outside the EU, the absence of an EU establishment does not automatically place them outside the Act. Market activity, operator roles, and the intended use of AI output within the EU may still bring them within scope.

For organisations using free and open-source AI, the licence does not automatically remove every EU AI Act requirement. High-risk systems and systems falling under Articles 5 or 50 remain expressly outside the general open-source exclusion.

The better approach is to ask:

• What is the AI system or model?
• What is its intended and actual use?
• Who performs each regulated role?
• Where is it supplied, used or producing outputs for use?
• Does an exclusion genuinely apply?
• What classification follows?
• Which obligations must now be activated?

That is the difference between assuming an organisation is out of scope and producing a clear, traceable and supportable EU AI Act determination.

How NORVA can help

Do not leave EU AI Act scope, role, and classification decisions to assumption.

NORVA’s Excel-native compliance assessment tools help organisations and advisers work through complex applicability questions in a familiar, structured format, with regulatory source links, practical assessor guidance, evidentiary support and automatically generated reporting. They help teams move from the core question, “Are we meeting the requirements that apply to us?”, to a clear, traceable and supportable assessment outcome.

Clear compliance assessment. Practical evidence. No heavy GRC platform required.

Source and Legal Review Note

This article is based primarily on Regulation (EU) 2024/1689, including Article 2 and the relevant recitals. It is written for practical compliance-assessment purposes and should be reviewed against the current consolidated legal text, applicable European Commission guidance and relevant regulatory or judicial developments before publication or reliance. Organisations should obtain qualified legal advice where scope, operator role, an exclusion or classification remains uncertain.

This article provides general information and does not constitute legal advice.