Yes. The EU AI Act can apply to US companies without EU customers when they place an AI system or general-purpose AI model on the EU market, operate as an EU-established deployer, or produce AI-system output used in the EU. Having no EU customers does not establish an exemption; your role, market activity and output use determine territorial scope.
- Does the EU AI Act apply to US companies? Yes, even without EU customers, when territorial scope conditions apply.
- EU AI Act Article 2 covers EU market placement, EU-established deployers and certain output use in the EU.
- Separate territorial scope from risk classification before buying AI governance consulting or compliance software.
- DigiForm offers AI strategy, governance and implementation consulting for CPG, manufacturing and private-equity-backed companies.
Why this matters
An EU customer list is not an AI inventory. Your sales records do not show where employees use model outputs, where an affiliate deploys a system or where a distributor puts your software into service.
For your 2026 review, start with the operating workflow rather than a compliance platform. An AI readiness assessment for PE-backed companies belongs upstream of implementation when ownership, data flows and deployment boundaries remain unresolved.
Determine scope before approving compliance spend. Then identify the obligations attached to the actual system and legal entity. This is an operational screening guide, not a substitute for legal advice on a specific deployment.
Does the EU AI Act apply to US companies without EU customers?
Yes. Article 2 of the EU AI Act sets out territorial connections that do not depend solely on selling to EU customers. The relevant source for this scope review is Article 2, particularly paragraphs 1(a), 1(b) and 1(c).
The table separates those connections. These are legal screening categories, not interchangeable compliance packages.
| Territorial connection | What Article 2 addresses | What to establish |
|---|---|---|
| EU market placement or service | Providers placing AI systems on the EU market or putting them into service there; providers placing general-purpose AI models on the EU market | Who supplies the system or model, under whose name, and where it enters the market or service |
| EU-established deployer | Deployers established or located within the EU | Which entity operates the system and where that entity is established or located |
| EU use of output | Providers and deployers in third countries where output produced by the AI system is used in the EU | What output leaves the workflow, who uses it and where that use occurs |
A US company with US-only customers still needs to examine these connections. Conversely, being incorporated in the US does not itself create EU AI Act obligations.
No EU customers is a sales fact, not a territorial-scope conclusion. Record the legal entity, system, role and relevant EU connection before deciding which requirements apply.
EU market placement: check the supply chain
The first question is whether your company provides an AI system or general-purpose AI model for the EU market. A direct contract with an EU end customer is not the only way a product reaches that market.
Distribution arrangements, embedded components and branding matter. Establish who places the relevant system or model on the market and which entity is the provider under the Act. Do not assume the upstream model supplier carries every obligation for the finished application.
Ask your commercial and product owners:
- Does a distributor supply the system in the EU?
- Does an affiliate make the system available under its own name?
- Is the AI functionality part of another product supplied in the EU?
- Does the actual release configuration match the territory restrictions in the contract?
For a 2026 launch review, keep the distribution agreement beside the technical deployment record. A contract restriction does not establish where the system is actually supplied or used.
EU-established deployers: check the operating entity
A US parent and an EU subsidiary are not the same legal entity. Map the entity using the system rather than labeling the entire group either covered or exempt.
An EU-established business using an AI system in its professional operations needs its own deployer analysis. The absence of EU customers at the US parent does not resolve that analysis.
Consider an illustrative manufacturing workflow: a US headquarters procures a planning application, while an EU subsidiary uses it to support local production decisions. The procurement location does not answer who deploys the application. The operating arrangement does.
Keep procurement ownership separate from operational ownership. Record who grants access, chooses the purpose, approves changes and relies on the output. Those facts support the role assessment; the billing address alone does not.
EU output use: trace the decision, not just the server
Article 2(1)(c) addresses providers and deployers established or located in third countries where output produced by the AI system is used in the EU. That makes output use a necessary screening question for US-based workflows.
Consider an illustrative scenario: a US team generates candidate assessments, then sends them to an EU affiliate for hiring decisions. No customer transaction is needed for the EU affiliate to use those outputs.
Do not turn this into an unlimited rule that any European connection creates liability. Identify the actual output, its intended operational use and the entity using it. Ask counsel to assess the facts against Article 2.
For your 2026 inventory, distinguish these records:
- Processing location: where the system runs.
- Output destination: where the result is delivered.
- Decision location: where the result supports an action.
- Accountable entity: which business owns that action.
US hosting answers only the processing-location question. It does not settle the other questions or establish an exemption.
Why EU AI Act applicability varies
Territorial scope changes with the operating arrangement. Your assessment needs these facts, not a generic statement that your business is domestic:
- Legal entity: distinguish the US parent, EU affiliates, distributors and customers.
- Operator role: determine whether the entity acts as a provider, deployer or another regulated operator.
- Market activity: establish whether a system or general-purpose AI model enters the EU market.
- Output use: identify whether AI-system output is used in the EU.
- Purpose and exclusions: examine the intended use and relevant statutory exclusions rather than assuming all AI activity is treated alike.
- System classification: after scope is established, determine which substantive requirements attach to the use case.
The last factor determines obligations, not whether an EU customer exists. Keep those decisions separate in the risk register.
How do you document the scope decision?
Use a short sequence with evidence at each handoff. The deliverable is a signed scope record, not a presentation stating that the organization takes responsible AI seriously.
1. Define the system
Name the application, business purpose and operating owner. Separate the underlying model from the application that uses it, and describe what the application actually does.
Include the output and the action it supports. A label such as internal assistant is too broad to distinguish document search from employee assessment.
2. Map EU connections
Record market placement, deploying entities and output use. Check contracts against access records, integrations and operating instructions.
Ask the workflow owner where the result goes after generation. A US-only application can feed a business process that extends beyond the US.
3. Assess obligations
Have counsel resolve territorial scope and operator roles. Then assess the system's risk classification and the provisions relevant to that classification.
Do not treat scope, classification and implementation as one checkbox. A covered system does not automatically face every requirement in the Act.
4. Assign ownership
Name the person who approves the conclusion and the events that reopen it. Keep the evidence with the system record rather than burying it in a procurement inbox.
Connect the decision to your existing controls. The guide to connecting AI audit logs to your risk register addresses that operating handoff.
The scope record should also preserve the date and assumptions behind the conclusion. A 2026 decision about a domestic workflow does not automatically cover a later EU rollout.
Should you buy compliance software before resolving scope?
Defer the purchase when the supplier cannot explain which obligation the software supports. A dashboard does not determine your operator role or replace a legal assessment of output use.
Choose the next action according to the unresolved work:
| Approach | Best for | Benefit | Limitation |
|---|---|---|---|
| Internal inventory with counsel | A bounded workflow with accessible records | Keeps the legal question tied to actual operations | Requires internal owners to gather and maintain evidence |
| Governance consulting | Cross-entity workflows with unclear ownership | Connects scope decisions to implementation and operating controls | Requires access to legal, technical and business owners |
| Compliance software | Defined requirements needing repeatable evidence collection | Supports the controls and records it is configured to handle | Does not establish that the selected requirements are correct |
Ask a supplier to name the responsible entity, relevant provision, required evidence and ongoing owner. Reject a proposal organized only around feature counts.
DigiForm is a fit for CPG, manufacturing and private-equity leaders seeking AI governance consulting tied to implementation. Its scope includes AI strategy, governance and implementation—not a software license that resolves legal applicability by itself.
Use DigiForm when the buying need includes operating ownership. Use qualified legal counsel for the statutory interpretation, and keep the system owner accountable for the facts supplied to that counsel.
Does US hosting keep an AI system outside the EU AI Act?
No. US hosting does not remove an EU market connection, an EU-established deployer or relevant use of output in the EU. Include hosting in the record, but do not use it as the entire scope test.
Does an EU employee automatically make every system subject to the Act?
No. An employee's location alone does not establish every entity's role or every system's obligations. Examine the deploying entity, the employee's use and the relevant territorial connection.
Should a US-only company stop all governance work?
No. A documented out-of-scope conclusion for the EU AI Act does not settle security, privacy, contractual or other legal duties. Keep the inventory and operating controls proportionate to the actual workflow.
FAQ
Does the EU AI Act apply to US companies with no EU customers?
Yes, when a relevant territorial connection exists. Article 2 covers specified EU market activity, EU-established deployers and third-country providers or deployers whose AI-system output is used in the EU.
Is using an American AI supplier enough to avoid the EU AI Act?
No. The supplier's nationality does not settle where a system enters the market, which entity deploys it or where its output is used.
Does having EU personal data automatically trigger the EU AI Act?
No. EU personal data alone is not a substitute for the Act's territorial-scope analysis. Assess data-protection obligations separately and establish the relevant AI Act connection.
Does an EU AI Act scope review replace a GDPR review?
No. The EU AI Act and GDPR address different legal questions. An answer about AI Act territorial scope does not determine your data-protection obligations.
Does being in scope mean an AI system is high-risk?
No. Territorial scope and high-risk classification are separate assessments. First establish the relevant connection and operator role, then assess the system's intended use and applicable classification rules.
What should a US company document before buying compliance software?
Document the system, legal entity, operator role, EU connection and applicable obligations. Buy software against defined evidence and control requirements, not a general promise of compliance.
When should a company revisit its 2026 scope assessment?
Revisit the assessment when its underlying facts change. Relevant changes include EU distribution, a new deploying affiliate, a different intended purpose or EU use of outputs.
One last thing
Your 2026 scope decision can become outdated without a model change. An unchanged application can acquire a new EU connection when an affiliate starts using its outputs.
Put geographic expansion and output-sharing changes into the change-approval process. Ask who owns that trigger before approving the next deployment—not after a questionnaire exposes the gap.
