Does the EU AI Act apply to us? Start with three questions
A customer questionnaire, a tender or a board member has asked whether the EU AI Act applies to you. The short answer is yes if you place an AI system or a general-purpose AI model on the EU market, put one into service in the EU, or use one in the EU. The Act also reaches providers and deployers established outside the EU when the output of their AI system is used in the EU. Article 2 sets that reach, and an exclusion can still take a given system out of scope. Whether it applies to *you* depends on three questions: what role you hold for each system (Article 3 defines provider, deployer, importer, distributor and the other operators), where the system is used or its output lands, and whether an exclusion such as military, defense or national security use, pure research before market placement, or a free and open-source release applies. The answer changes system by system, so the same company can be a deployer of one tool and a provider of another.
Start by listing every AI system your organization builds, buys, embeds or runs, including tools that a business unit adopted without central approval. For each entry, record who develops it, under whose name it is placed on the market or put into service, where it is used, and whether its output reaches people in the EU. Then test each entry against the three questions above. Check the exclusions against the Article 2 text rather than against the name of a product, and confirm with your legal team whether a free and open-source license covers the system as released or as you modified it. Your organization owns the scope decision and signs off on it. An implementation partner can help build the inventory and prepare the written analysis, but it cannot give the binding view. Only legal counsel or the relevant national market surveillance authority can do that, so ask counsel to review the analysis before you rely on it. The risk tier that follows is covered in the classification section, and the dates that apply to each tier should be confirmed against the official timeline.
How to run the scope check in five steps
The sequence answers four questions in order: is it an AI system, what is your role, does the Act reach you, and which exclusions or risk tier and dates apply. Each step leaves a record you can show an auditor or a regulator.
Confirm the item is an AI system
Start with each tool, model or feature in your inventory and test it against the definition in Article 3(1): a machine-based system with varying levels of autonomy, which may adapt after deployment and infers from its input how to generate outputs such as predictions, content, recommendations or decisions. The Commission's non-binding guidelines on the AI system definition, published on 6 February 2025, explain how to apply the test to borderline software. Ask the product owner and the vendor to describe how the system produces its outputs, not only what it is called. The step is complete when each item has an inventory line that records the yes or no answer and the reasoning behind it. Items that fail the test leave the AI Act scope, but keep the memo so the decision can be defended later.
Identify your role for each system
For each system that passes step one, record whether your organization is a provider under Article 3(3), a deployer under Article 3(4), or another operator under Article 3(8), such as an importer, distributor, product manufacturer or authorized representative. A provider develops the system, or has it developed, and places it on the market or puts it into service under its own name or trademark, whether for payment or free. A deployer uses the system under its authority, except in a personal non-professional activity. One organization can hold more than one role for the same system, so record each role separately. The output is a role record per system that names the legal basis for each role and the evidence behind it, such as the contract, the build history or the procurement file.
Test EU reach under Article 2(1)
Next, check whether the Act reaches the system from where you stand. Article 2(1) covers providers placing systems or general-purpose AI models on the EU market, wherever they are established, and deployers established or located in the EU. It also reaches non-EU providers and deployers when the output of the system is used in the EU. Importers, distributors, product manufacturers, authorized representatives and affected persons located in the EU are covered too. Confirm where each system is placed or used, where its outputs are used, and where the affected people are located. Record the answer as a reach note on the role record. A system that is used only outside the EU, with no EU output, normally falls outside Article 2(1), but confirm this with counsel if your customers or staff are in the EU.
Check the Article 2 exclusions
Work through the exclusions in Article 2 for each system that is in scope. These cover systems placed on the market, put into service or used exclusively for military, defense or national security purposes, whatever the type of entity. They also cover AI developed and put into service solely for scientific research, and research, testing or development before a system reaches the market. Testing in real-world conditions is not covered by that research exclusion. Deployers who are natural persons using AI in a purely personal, non-professional activity are excluded, and so are AI systems released under free and open-source licenses, unless they are placed on the market or put into service as high-risk systems or fall under Article 5 or Article 50. Write an exclusion memo for each system, state which exclusion is claimed or that none applies, and have legal review any claim that depends on a grey area.
Assign a risk tier and the applicable dates
For each system still in scope, assign one of the Commission's four risk levels: unacceptable risk, high risk, transparency risk, or minimal or no risk, which the Act does not regulate. Check the nine prohibited practices in Article 5 first, then the two routes to high-risk status and the transparency duties in Article 50. Then map the tier to its dates. Chapters I and II, which include Article 4 on AI literacy, have applied since 2 February 2025, so Article 4 covers all AI systems in scope. The high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, as amended in 2026. The output is a tier and date list for the inventory, which feeds the compliance plan and the next review when the Act or its guidance changes.
Is the system an AI system under Article 3(1)?
Before you ask whether the EU AI Act regulates a tool, you have to ask whether it is an AI system under Article 3(1) at all. The definition describes a machine-based system designed to operate with varying levels of autonomy, which may adapt after deployment, and which infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions. Those outputs must be able to influence physical or virtual environments. Each element is a test you can answer yes or no, and the answers belong in your inventory. Simple rules-based software, where a person has written every condition and the system only executes them, usually fails the inference test and falls outside the definition. Fixed scripts, spreadsheet formulas and workflow engines with hard-coded thresholds are the common examples.
The definition is not always obvious. A statistical model that scores credit applications, a ranking model in a recruitment tool or a classifier that flags suspicious transactions usually passes, because it infers patterns from data rather than following written rules. Borderline cases need more care. The Commission published non-binding guidelines on the AI system definition on 6 February 2025, and you should read them alongside the Article 3 text in the consolidated EUR-Lex text of the Act. Confirm with your legal team whether any component you rely on, such as a vendor's scoring engine or an open-source library, is inferring outputs or only executing rules.
Document the reasoning for every inventory item, whether the answer is yes or no. For each system, record the component you assessed, the evidence you used (design documents, model training method, vendor statements), the point at which the system infers outputs, and who approved the conclusion. A negative finding is as important to defend as a positive one, because a regulator or auditor will ask why a system was left out. The classification is your organization's decision, and an external adviser can review the reasoning, but only you can own it. Revisit each decision when a system changes, for example when a vendor adds learning after deployment or a rules engine is replaced with a model.
Provider, deployer, importer or distributor: which role are you?
Article 3(3) makes you a provider if you develop an AI system or general-purpose AI model, or have one developed, and place it on the market or put it into service under your own name or trademark. Payment is not required, so free or open-source distribution under your name can still make you a provider. The test turns on who controls the system's purpose and who presents it to the market, not on who wrote every line of code.
- Develop or commission: You build the system internally or contract a developer to build it for you.
- Own the name or trademark: The system is offered to others or used internally under your brand.
- Place or put into service: The system is made available on the EU market or put into use in the EU.
- Illustrative example: A bank builds a credit-scoring model and offers it to other lenders under its own product name, so it acts as a provider.
- First duty: Establish a quality management system and technical documentation for any high-risk system before it is placed on the market.
Confirm with counsel whether a system you commission from a vendor becomes yours once you rebrand or substantially modify it.
Article 3(4) makes you a deployer if you use an AI system under your authority, except in a personal non-professional activity. You do not need to build or own the system. Using a vendor's product inside your operations is enough, which is why most organizations with AI in their workflows are deployers for at least some systems.
- Use under your authority: You decide when and how the system runs within your processes.
- Vendor-supplied tools: Purchasing or subscribing to a third-party system makes you its deployer.
- Non-professional use excluded: Individuals using AI for purely personal activity fall outside the deployer duties.
- Illustrative example: An insurer licenses a claims-triage tool from a vendor and runs it on its own customer files, so it is the deployer.
- First duty: Ensure AI literacy among staff who operate or oversee the system, and follow the provider's instructions for use.
Check your contracts to see whether the vendor's instructions, logging and human oversight features are sufficient for your deployer duties.
Importers and distributors sit between a non-EU provider and the EU market. An importer places a system from a third country on the EU market under the name of a non-EU provider. A distributor makes a system available on the market without being the provider or importer. Article 3(8) groups both among operators, and Article 2(1) brings them within scope. Their checks are about verifying what the provider has done before the product reaches users.
- Importer test: The system carries a non-EU provider's name and you place it on the EU market.
- Distributor test: You supply the system in the supply chain without changing it or branding it.
- Illustrative example: A reseller in Germany sells a high-risk screening tool made by a US developer that has no EU presence, so the reseller is a distributor and must check the provider's conformity documents.
- First duty: Verify that the provider has completed the conformity assessment, drawn up documentation and affixed the required marking before you supply the system.
- Role change: If you put your own name or trademark on the system or substantially modify it, you may become a provider.
Request the provider's EU declaration and documentation before signing any supply agreement.
Article 2(1) covers product manufacturers that place an AI system on the market together with their product, under their own name. This applies where AI is a component of a regulated product, such as a medical device or machinery, and the manufacturer sells the combined product. The manufacturer's obligations for the AI component are tied to the product rules that apply to that device, so the sector legislation shapes the route.
- Product placement: The AI system is supplied as part of a product that carries your name.
- Combined sale: The AI component is not sold separately but with the product.
- Illustrative example: A manufacturer of industrial equipment embeds an AI safety function and sells the machine under its own brand, so it is a product manufacturer for that AI system.
- First duty: Identify which Annex I product legislation applies and whether it requires a notified body for the product.
- Dates: Annex I product systems follow the dates set out in the amended Article 113, so confirm the applicable date with your product regulator.
Ask your notified body or product regulator whether the AI component is treated as part of the product conformity file.
Authorised representatives act for providers established outside the EU. Article 2(1) brings them within scope, and Article 3(8) lists them among operators. A non-EU provider appoints an authorised representative in the EU to hold documentation and act as the contact point for authorities. The appointment does not transfer the provider's responsibility for compliance.
- Appointment: The non-EU provider designates a representative established in the EU by written mandate.
- Documentation access: The representative must be able to hold the technical documentation and declaration for authorities.
- Illustrative example: A non-EU developer of a high-risk HR system appoints a Dutch firm as its representative, and that firm answers requests from a national market surveillance authority.
- First duty: Accept the mandate in writing and confirm you can access the documentation the provider must keep.
- Scope: Confirm with the provider which systems and models the mandate covers.
Ask the provider to show the written mandate and confirm that the representative holds the documents it will need to produce.
Which exclusions can take you out of scope?
Article 2 removes some uses from the Act entirely, but each exclusion depends on facts about who uses the system, why, and where it runs. Treat each one as a claim you must be able to show with records, not as a default position.
Military, defense and national security
Article 2(3) excludes AI systems placed on the market, put into service or used exclusively for military, defense or national security purposes, whatever the type of entity. The word that matters is exclusively. A system that also serves a civilian HR or lending function does not fall under this exclusion for that function. Check the intended purpose in the system documentation, confirm who operates it, and record any civilian use that could surface later. Ask counsel to confirm how the exclusion applies to contractors and dual-use suppliers.
Scientific research and pre-market testing
Article 2(6) and 2(8) exclude AI developed and put into service solely for scientific research, and research, testing or development before a system is placed on the market. This exclusion ends once the system reaches customers or real users. Testing in real-world conditions is not covered by it, so a pilot with live users, customer data or operational decisions may bring the system into scope. Document the research purpose, the test environment, and the date the system first touches real use.
Purely personal, non-professional use
Article 2(10) excludes the obligations of deployers who are natural persons using an AI system in a purely personal, non-professional activity. The test is who uses the system and for what. An employee using a general assistant for a work task, a freelancer serving clients, or a sole trader running a business process is not acting in a personal capacity. Confirm that any individual relying on this exclusion uses the system only for private matters, and that business tools are provided and governed by the organization.
Free and open-source release
Article 2(12) excludes AI systems released under free and open-source licenses. The exclusion does not apply where the system is placed on the market or put into service as a high-risk system, or where it falls under Article 5 (prohibited practices) or Article 50 (transparency duties). Commercial hosting, paid support packaged with the model, or deployment in a regulated use case can remove the protection. Check the license terms, the commercial model, and every intended use before relying on this exclusion.
Does the Act reach companies outside the EU?
Yes, the Act can reach a company with no EU establishment. Under Article 2(1), a non-EU provider that places an AI system or general-purpose AI model on the EU market is in scope, and so is a non-EU provider or deployer whose AI output is used in the EU. The test is where the output is used, not where the company, its servers or its engineers sit. A US SaaS vendor whose scoring feature runs for customers in Germany, or a non-EU hiring platform whose rankings are used on EU candidates, should assume the Act applies until its counsel has confirmed otherwise.
Two roles carry specific duties for non-EU operators. A non-EU provider of a high-risk system must appoint an authorised representative established in the EU, and importers must check that the provider has met its conformity obligations before placing a system on the market. Affected persons located in the EU are also covered by Article 2(1). Ask your legal team to map which of your products reach EU users, which entity places each system on the market, and whether a designated EU representative is already in place for each one.
The detail on authorised representatives, importer checks and enforcement by national authorities and the AI Office sits on the non-EU page of this guide, so use it once this scope check points to a high-risk or general-purpose model use. Confirm the current text of the articles against the consolidated Regulation as amended in 2026, since the Digital Omnibus changed several operator duties.
Questions buyers ask before deciding the scope
Does the EU AI Act apply to an internal tool we build for our own staff?
Often yes, if the tool is an AI system under Article 3(1) and you use it in the EU. The Act does not exempt internal use. Your role is usually deployer, because you use the system under your authority, and deployers in the EU carry duties under Article 4 (AI literacy) from 2 February 2025 whatever the risk tier. If the tool falls into a high-risk category, deployer duties apply too, and if you build it and put it into service under your own name, you may also be the provider. Start by confirming whether the software meets the definition of an AI system at all, since plain rules-based software does not. The Commission's non-binding guidelines on that definition, published 6 February 2025, are the natural next read: AI system definition guidelines.
Does using a third-party AI model make us a provider?
Not by itself. Under Article 3(3), a provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. If you call a vendor's model through an API and use the output internally, you are normally a deployer. The position changes when you fine-tune the model, rebrand it as your product, or substantially modify a high-risk system, because you may then take on provider duties. Check your contracts for who holds documentation, and confirm with counsel where your integration crosses that line, since the answer depends on what you change and how you release it.
Are small companies exempt from the EU AI Act?
No. The Act has no general exemption for small organizations. It applies by role, risk tier and use, not by company size. Some relief exists for small and medium enterprises and small mid-caps, but it is limited to specific rules, such as simplified documentation and lower fines in certain cases, as amended in 2026 by Regulation (EU) 2026/1744. Whether that relief helps you depends on the obligation in question. Ask your advisor which provisions give you relief for your role and risk tier, and get that answer in writing before you rely on it.
How long does a scope check take, and what does it need from our staff?
The duration depends on how many AI systems you run, how many are built in-house, and how well your software inventory is kept. A small estate with clear ownership can be checked far faster than one where teams have adopted AI tools informally. Expect to need a named owner for each system, a description of its purpose and users, the data it processes, the decisions or outputs it produces, and the vendors and models behind it. Legal or compliance staff should confirm the role analysis, and a technical lead should confirm how each system works. Ask any provider of this work to state the scope, inputs and deliverables in writing before starting.
Can we run the scope check ourselves, or do we need outside help?
You can run it internally if you have people who understand the Act's definitions, roles and risk tiers, and time to document each system. Many organizations do the inventory in-house and bring in outside help for the classification of borderline systems, the role analysis for vendor-supplied models, and a second review before the results go to a board or regulator. Remember that an implementation partner prepares systems and evidence, but the organization owns its compliance decisions. Only an independent auditor, assessor or certification body issues reports or certificates. DeployOpen plans and implements self-hosted open-source platforms in the client's own infrastructure and does not issue legal opinions or audit reports, so pair any technical review with qualified legal advice.
Does a tool built on open-source software fall outside the Act?
Not automatically. Article 2(12) excludes AI systems released under free and open-source licenses, but the exclusion does not apply if the system is placed on the market or put into service as a high-risk system, or if it falls under Article 5 (prohibited practices) or Article 50 (transparency). Free licensing also does not remove deployer duties for a system you run in your own organization in a way the exclusion does not cover. Check the license terms, how the system is released, and which use case it serves. Open-source components inside a commercial product can change the analysis, so document the license and the use case for each system in your inventory.
Does the Act reach us if we are outside the EU but our AI output is used in the EU?
Yes, potentially. Article 2(1) applies the Act to non-EU providers and deployers where the output of the AI system is used in the EU, so the question is where the output is used, not where your servers sit. Non-EU providers of high-risk systems generally need an authorised representative in the EU. Check whether your customers, users or affected persons are located in the EU and whether your outputs feed into decisions made there. Get a written view from counsel in the relevant member states, because enforcement and interpretation can vary.
Which dates should our scope check plan around?
Start from the dates in the Act itself. Chapters I and II, covering definitions, AI literacy and prohibitions, have applied since 2 February 2025. The general-purpose AI, governance, notified body and penalty chapters have applied since 2 August 2025, with the exception of Article 101. Under Regulation (EU) 2026/1744, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Confirm each date against the consolidated text before you set a deadline, because the amendment changed earlier dates.
Who owns the scope decision and who prepares the evidence
Your legal and compliance team owns the scope determination. It decides whether each AI system or general-purpose AI model falls within Article 2, which role your organization holds under Article 3, whether an exclusion applies, and which risk tier and dates follow. Counsel may interpret ambiguous terms, and that interpretation is the organization's own position, not an external finding. The team should record the reasoning for each system so the file can be reviewed later.
- Final determination: Sign off on the scope decision for each system and keep the signed record with its date.
- Role analysis: Decide whether you act as provider, deployer, importer, distributor or product manufacturer for each use, including cases where you modify or rebrand a system.
- Exclusions: Document the basis for any reliance on the military, research, personal use or free and open-source exclusions.
- Interpretive questions: Route unclear points, such as whether a tool meets the Article 3(1) definition, to counsel and record the answer.
- Ongoing review: Reopen the determination when a system changes purpose, provider or market.
Before relying on any conclusion, confirm that the legal owner has reviewed the written scope and the inventory facts behind it.
Business and system owners hold the facts that decide scope. They know what a system does, who uses it, which decisions it informs, where its output goes and whether it was built in-house, bought or modified. Without accurate answers from these owners, any scope analysis rests on guesses. Their input is factual, and they should not be asked to make the legal call.
- Purpose and use: Describe what the system is for, the decisions or outputs it produces, and the people or processes affected.
- Data and outputs: State where the output is used, including whether it reaches people or markets in the EU.
- Origin and changes: Identify the vendor or model, whether you have altered it, and whether you have put your name on it.
- Human involvement: Explain how humans review or act on outputs, which the risk analysis later depends on.
- Change notices: Report new features or new use cases to the inventory owner promptly.
Check that each owner has signed off on the facts for their system, since those facts become part of the evidence file.
An implementation partner such as DeployOpen prepares the materials the organization needs to make and defend its scope decision. Under a fixed scope agreed in writing, the partner can compile the AI system inventory, map each system's data flows and supplier relationships, draft role analysis worksheets for counsel to review, and assemble the evidence files that support the decision. The partner works on the organization's own infrastructure and records. It does not decide scope and does not issue opinions or certificates of compliance.
- Inventory: Build a register of AI systems and general-purpose models in your environment, with owners and sources.
- Role analysis drafts: Prepare worksheets that set out the facts for each Article 2 and Article 3 question, for legal review.
- Evidence files: Organize logs, contracts, documentation and version records that show how the decision was reached.
- Technical verification: Confirm which models and services run where, using configuration and deployment records.
- Written boundaries: Agree in writing which deliverables are produced, who reviews them and what is excluded.
Ask any partner to state in its proposal that the legal determination remains with your organization and that it issues no compliance opinion.
The national market surveillance authority and, ultimately, the courts are the only parties whose view of your scope is binding. Under the Act, national market surveillance authorities enforce the rules for AI systems, and the Commission's AI Office enforces the general-purpose AI model rules. The AI Office is also exclusively competent for certain AI systems built on a provider's own general-purpose model and for AI in very large online platforms and search engines. Your own determination, a consultant's view and a partner's analysis are inputs to that process, not substitutes for it.
- Binding view: Only an authority decision or a court ruling settles a contested scope question.
- Competent authority: Identify which national authority would supervise your systems, and check whether the AI Office is involved.
- Guidance: Non-binding Commission guidance, including the guidelines on the AI system definition, informs how authorities read the Act.
- Engagement: Know how to respond to information requests and keep records that can be produced quickly.
- Independent review: Where you need an independent assessment, that comes from an auditor or assessor, not from an authority.
Confirm your competent authority and its procedures with the relevant national body, because these vary by Member State.
How DeployOpen prepares a scope check for your environment
DeployOpen works on the scope question as a written, fixed-scope piece of work inside your own environment. We map which AI systems and general-purpose models you use or supply, your role for each, and the dates that follow, then document the result so your legal, compliance and security teams can review it.
How we scope
- We inventory the AI systems and models in your environment, including vendor tools and internal builds, before any role is assigned.
- We record your role for each system as provider, deployer, importer, distributor or product manufacturer, with the reasoning written down.
- The written scope states which systems, business units and EU touchpoints are covered, so the agreed boundary is explicit before work starts.
How we build
- We build a classification worksheet that tests each system against the prohibited practices, the two high-risk routes and transparency duties.
- We check exclusions such as military use, scientific research and free and open-source licensing against the facts of each system.
- We set up a repeatable inventory in your own tooling so new AI systems are screened when they are introduced or changed.
How we hand over
- You receive a scope memo listing each system, its role, its risk tier and the application dates that apply to it.
- The handover includes open questions for legal counsel, with the points you should confirm against the official text and your own contracts.
- We document the method so your team can rerun the check when systems, vendors or EU rules change.
How we support
- Engagements are fixed-scope, so the deliverables and timelines are agreed in writing before work begins.
- Ongoing support, updates to the inventory and re-screening after changes are available as a retainer.
- DeployOpen prepares the scope and evidence. Only your legal advisers and, where required, independent assessors determine and certify compliance.
