EU AI Act for Israeli Companies: How Article 2 Reaches Israeli AI Providers

A Tel Aviv startup whose AI tool is used by an employer in Berlin is bound by the EU AI Act — even with no European office, no European entity, and a home approach that deliberately avoids a binding AI statute. This is the trap for Israeli companies: Israel's own AI policy is principles-based and sector-led, which can make the EU's hard-law regime feel like someone else's problem. It is not. The EU AI Act is not Israeli law and never becomes Israeli law; there is no Israeli application date and no Israeli "AI Act competent authority" to register with. But Article 2 gives Regulation (EU) 2024/1689 deliberate extraterritorial reach, and it carries turnover-based penalties Israel's framework does not.

For an Israeli company touching the EU market — and a large share of Israel's export-heavy tech sector does — Article 2 is the entire and permanent basis on which the Act binds you.

---

Israel is a third country: the Act never becomes Israeli law

Israel is not an EU Member State and not part of the European Economic Area (EEA). No mechanism — no transposition, no EEA incorporation — turns Regulation (EU) 2024/1689 into Israeli law. So the only question that matters for an Israeli company is the extraterritorial one: does your activity bring you within Article 2?

Israel's approach is principles-based, not a binding AI Act

Israel has deliberately chosen a policy-led, principle-driven path rather than a horizontal AI statute. As of mid-2026 there is no Israeli AI Act. Governance rests on:

• Israel's Policy on Artificial Intelligence Regulation and Ethics (published December 2023), built on "Responsible Innovation," which directs sectoral regulators to craft fit-for-purpose rules rather than imposing one broad horizontal law.
• An emerging AI Policy Coordination Center within the Ministry of Innovation, Science and Technology, expected to support sector regulators with risk-management tooling.
• Existing law — notably privacy and data-protection rules enforced by the Privacy Protection Authority (PPA) — which carries the binding obligations where personal data and automated decisions are involved.

The contrast with the EU matters. Israel's policy is guidance plus sector-specific action; the EU AI Act is hard law with Article 99 fines up to EUR 35 million or 7% of worldwide turnover. Following Israeli policy does not satisfy the EU AI Act, and the EU AI Act does not satisfy Israeli sectoral or privacy obligations. An Israeli company selling into the EU faces both pictures in parallel — treat the Israeli side as a matter for separate local counsel.

No Israeli application date to wait for

For an EU company the Act applies on fixed EU calendar dates. For an Israeli company those dates are not a domestic switch-on; they are simply the dates on which Israeli companies already in scope through Article 2 must comply. There is no separate "Israeli date," and waiting for one is waiting for something that will never come.

---

Article 2: the two limbs that catch Israeli companies

Article 2 sets the Regulation's scope, written to reach beyond EU borders precisely so non-EU providers cannot undercut EU ones by staying offshore.

Placing AI on the EU market (Article 2(1)(a))

Under Article 2(1)(a), any provider that places an AI system on the EU market or puts it into service in the Union is in scope, regardless of where it is established. An Israeli company that sells, licenses, or makes its AI product available to customers in Germany, France, or Ireland is caught — incorporation in Tel Aviv and servers in Israel change nothing. For Israel's export-driven SaaS, cybersecurity and AI-product firms, an EU customer base is the trigger.

Output used in the Union (Article 2(1)(c))

Under Article 2(1)(c), a provider or deployer established in a third country is in scope where the output of the AI system is used in the Union. The test is where the effect lands, not where the company or server sits. An Israeli firm whose model scores, ranks, or generates content about people in the EU is caught on this limb even with no EU customer contract.

The authorised-representative obligation (Article 22)

An Israeli provider of a high-risk system must, before placing it on the EU market, appoint an authorised representative established in the Union under Article 22 — a designated in-Union point of contact and accountability, not a full office. This parallels the EU-representative structure many Israeli exporters already meet under the GDPR (GDPR Article 27) — relevant because Israel holds an EU adequacy decision for data transfers, but adequacy concerns data protection and does nothing for AI Act conformity. It is a separate appointment under a separate statute.

---

Timeline: the EU dates apply to in-scope Israeli companies

There is no separate Israeli date. An Israeli company in scope through Article 2 plans against the EU statutory calendar.

The Digital Omnibus high-risk deferral

The Digital Omnibus is law: Regulation (EU) 2026/1744 was published in the Official Journal on 24 July 2026 and has been in force since 27 July 2026. Stand-alone Annex III high-risk obligations apply from 2 December 2027, and product-embedded Annex I high-risk obligations from 2 August 2028. The Commission's November 2025 "stop the clock" proposal would have tied the delay to standards availability, with backstop dates; the adopted text uses fixed calendar dates.

What did not move

Article 5 prohibitions and Article 4 literacy have applied since 2 February 2025; GPAI obligations under Articles 51-55 since 2 August 2025. For Israeli foundation-model or GPAI providers placing models on the EU market, the GPAI duties are live now — and models on the EU market before 2 August 2025 have until 2 August 2027 to comply under the transitional provision.

---

What in-scope Israeli companies actually have to do

The obligations are the EU obligations

Because the Act binds through Article 2 rather than any Israeli transposition, an in-scope Israeli provider or deployer faces the same role-based duties as an EU company. There is no Israel-lite version, and following Israel's principles-based policy will not discharge them. The roles map identically: provider, deployer, importer, distributor — with importer duties at Article 23 and distributor duties at Article 24.

The Article 25 role-shift

A deployer, distributor, or importer becomes a provider under Article 25 the moment it puts its own name or trademark on a high-risk system, substantially modifies it, or changes its intended purpose. An Israeli company that fine-tunes a base model into a new high-risk purpose, or rebrands a high-risk EU tool, can inherit the full provider stack without realising it.

High-risk duties and penalties

For a stand-alone Annex III high-risk system, the provider stack applies in full: risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness (Articles 9-15), conformity assessment, the Article 49 registration, and provider obligations under Article 16. Penalties are the Article 99 tiers — identical figures, calculated on worldwide turnover, not EU or Israeli revenue: up to EUR 35 million or 7% for Article 5 breaches (Article 99(3)); up to EUR 15 million or 3% for most other obligations including high-risk provider duties (Article 99(4)); up to EUR 7.5 million or 1% for supplying incorrect or misleading information (Article 99(5)). For SMEs, Article 99(6) caps the fine at the lower of the fixed amount or the percentage. The third tier is 1%, never 1.5%. This is the sharpest contrast with Israel's voluntary policy: real, turnover-based fines. Separately, GPAI model providers are fined by the Commission under Article 101 (up to EUR 15 million or 3%), not under Article 99.

---

Worked example: a Tel Aviv cybersecurity firm with a workforce-analytics module

Sela Security Ltd is a roughly 120-employee Tel Aviv cybersecurity company with around EUR 16 million in annual revenue. Its core product is threat detection, but it ships an add-on that scores employee behaviour to flag "insider risk," sold to enterprise customers including several in Germany and France.

Why classification turns on the specific feature

As a provider placing systems on the EU market, Sela is in scope under Article 2(1)(a) today. But its core threat-detection product, on its own, most likely sits at minimal or limited risk — cybersecurity tooling is not in itself an Annex III use case. The insider-risk module is the exposure: scoring and monitoring employees can fall within Annex III point 4 (employment and worker management), which would make that feature high-risk and trigger the full provider stack under Articles 9-15. Classify feature by feature, not product by product.

The prohibited-practice gate comes first

If the insider-risk module infers employees' emotional states from their behaviour, it can collide with Article 5(1)(f) — emotion recognition in the workplace is a prohibited practice, not merely high-risk. A prohibited feature must be removed for the EU market; it cannot be cured by documentation, and it carries the heaviest fine tier (Article 99(3)).

Sela's checklist

• Classify each feature separately: confirm the core product's risk level; assess the insider-risk module against Annex III point 4 and the Article 5(1)(f) gate.
• If high-risk, appoint an Article 22 authorised representative in the Union and build the Article 11 / Annex IV documentation and Article 47 / Annex V declaration of conformity; register under Article 49.
• Apply Article 50 transparency where any feature interacts with people or generates synthetic content.
• Note the exposure: a high-risk provider breach sits in the Article 99(4) tier; as an SME, Article 99(6) caps the fine at the lower of the fixed amount or the percentage, so 3% of roughly EUR 16 million revenue is the operative ceiling, not the EUR 15 million figure.
• Keep Israeli obligations — privacy/PPA duties and any sectoral guidance — running in parallel; the EU file does not discharge them, and vice versa.

---

What Israeli companies should do now

Map your EU exposure, not your Israeli status

Do not start from "are we covered under Israeli policy?" — and do not assume the EU regime is as discretionary as Israel's. Start from "do we touch the EU market?" If you place AI on the EU market or your output is used in the Union, the EU timeline binds you through Article 2, with enforceable penalties.

A five-step starting checklist

1. Map your AI systems against Article 2 to confirm where you place systems on the EU market or your output reaches the Union.
2. Classify each system — and each AI feature — by use: clear the Article 5 prohibited-practice gate first, then assess Article 6 / Annex III for high-risk status.
3. Assign roles — provider, deployer, importer, distributor — and run the Article 25 conversion check on anything you rebrand, fine-tune, or repurpose.
4. For high-risk systems, appoint an Article 22 authorised representative in the Union before market placement.
5. Build the compliance file: risk management, Annex IV documentation, conformity assessment, and the Annex V declaration of conformity — and keep your Israeli obligations running in parallel.

A note on data adequacy

Israel's EU adequacy decision eases personal-data transfers and may already have you appointing a GDPR representative — but adequacy is a data-protection mechanism. It says nothing about AI Act conformity and discharges none of the high-risk duties. Do not let "we're adequate" stand in for an AI Act assessment.

How Confir helps Israeli companies

Confir derives your provider, deployer, importer, or distributor role and classifies your systems — feature by feature — under Articles 5 and 6 with Annex III logic from plain-language intake. The engine is deterministic and rule-based — no model inference, no hallucination — so the same intake always yields the same audit-defensible finding with a human-readable explanation of which rule fired.

Confir generates the Article 11 / Annex IV technical-documentation pack and the Article 47 / Annex V declaration of conformity, and supports the Article 27 Fundamental Rights Impact Assessment where it applies. The aim is to give an Israeli company an EU-market compliance file that stands on its own, separate from Israeli privacy duties and the country's principles-based AI policy. The GPAI workflow (Articles 51-55) is partial and on the roadmap, not presented as complete. Confir is EU-hosted, at confir.eu.

Related guides

• EU AI Act for US companies: extraterritorial reach
• EU AI Act extraterritorial reach for non-EU companies
• EU AI Act scope explained (Article 2)
• Provider vs deployer under the EU AI Act
• EU AI Act deadlines and application dates