Does the EU AI Act apply to your Indian company? Probably, and here is how to tell

The question we are asked most often about the EU AI Act by Indian organisations is whether it applies to them. The question they should be asking is in what role, because the answer determines whether their obligations are substantial or merely significant.

The territorial hook is output, not establishment#

The Act reaches beyond the Union in a way that catches a lot of Indian technology and services businesses. The relevant trigger for most is straightforward: it applies to providers and deployers established outside the EU where the output produced by the AI system is used in the Union.

Note what that does not require. It does not require an EU entity. It does not require EU personal data. It does not require you to know your output crossed a border.

Concretely, the following are all in scope:

• An Indian SaaS product with an AI feature, sold to a German customer who uses its output in hiring decisions.
• An Indian GCC building a credit model for its European parent, where the model scores EU applicants.
• An Indian BPO operating an AI-assisted claims triage workflow for an EU insurer.
• An Indian IT services firm delivering a recruitment screening system to a French client.

The following generally are not:

• An internal AI tool used only by Indian employees, on Indian operations, with no EU output.
• An AI product sold exclusively to customers in Asia, the Gulf and North America.

Provider or deployer — and why it matters enormously#

This is the determination that shapes everything downstream.

A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority.

For a high-risk system, the gap between the two is large.

There is also a rule that converts a deployer into a provider: if a deployer puts its name on a high-risk system, substantially modifies it, or changes its intended purpose such that it becomes high-risk, the deployer assumes the provider's obligations. Fine-tuning a foundation model and shipping it as your own feature is exactly the fact pattern this addresses.

Is your system high-risk?#

Most obligations bite only for high-risk systems, so the classification is the second decision.

The Act reaches high-risk status two ways. First, AI systems that are safety components of products already regulated under EU product legislation. Second, systems in the listed areas of Annex III, which for an Indian enterprise most commonly means:

• Employment — recruitment, screening, filtering applications, evaluating candidates, promotion and termination decisions, task allocation, monitoring performance.
• Creditworthiness — evaluating natural persons' credit standing or credit scores, excluding fraud detection.
• Insurance — risk assessment and pricing for life and health insurance.
• Education — admission decisions, assessing learning outcomes, monitoring during tests.
• Essential services — eligibility for public benefits, emergency dispatch triage.
• Biometrics — remote identification, emotion inference, biometric categorisation.

If your product touches hiring, lending or insurance pricing for EU-affected individuals, plan on high-risk.

There is a narrow carve-out where a listed system performs only a preparatory task, or a narrow procedural task, or improves the result of prior human activity without replacing human assessment. It is genuinely narrow. Relying on it requires a documented assessment, and a "recommendation engine that a human always reviews" will not qualify if the human approves four hundred recommendations an hour.

The prohibitions apply to everyone#

Separate from the high-risk regime, certain practices are banned outright. Two catch organisations by surprise:

Emotion inference in the workplace and education. If your product infers emotional state from voice, face or text in an employment or educational context, that is prohibited — not high-risk, prohibited. Sentiment scoring of employee communications and "engagement detection" in remote learning both sit squarely here.

Untargeted scraping of facial images to build or expand facial recognition databases.

These need screening first, because no amount of governance makes a prohibited practice compliant.

What to actually do, in order#

Where ISO 42001 helps, and where it does not#

ISO/IEC 42001 is a management system standard; the AI Act is law. Certification does not confer compliance and no auditor will tell you it does.

What a well-run AI management system does is produce most of the evidence the Act requires you to hold. Risk management, data governance, impact assessment, lifecycle controls, monitoring, supplier controls and documented human oversight are all Annex A territory in 42001 and all obligations under the Act. Harmonised standards under the Act are expected to align closely with it.

So the practical answer for organisations facing both: build the AIMS, cross-map it explicitly to the Act's obligations, and treat certification as the assurance layer over compliance work you had to do anyway.

The cross-map is the part that gets skipped, and it is the part that makes the difference when a client's procurement team asks how your certificate relates to their conformity obligations.

General-purpose models change the supply chain question#

Most Indian organisations in scope are not training models — they are building on someone else's. That puts general-purpose AI in the middle of the analysis.

GPAI providers carry their own obligations: technical documentation, information for downstream providers, a copyright policy, and a public summary of training content. Models presenting systemic risk carry more, including evaluation, adversarial testing and incident reporting.

For you as a downstream builder, three consequences follow.

You inherit documentation you must actually read. The provider supplies information enabling you to comply. If you have not read it, you cannot demonstrate you used the model within its intended purpose — and "we assumed it was fine" is not a defence.

Fine-tuning may make you the provider. Substantially modifying a model, or putting your name on it, transfers provider obligations. Teams frequently cross this line without noticing, because fine-tuning feels like configuration rather than development.

Version pinning becomes a compliance control. If your provider silently swaps the underlying model, your output distribution changes with no change record. For a high-risk system that is a control failure. Ask for version pinning and change notification in the contract; if the provider cannot offer either, that constrains what you can responsibly build on it.

The dates that matter#

The Act applies in stages rather than all at once, which is genuinely useful — it means the work can be sequenced rather than attempted in parallel.

The prohibited-practices provisions and AI literacy obligations came into effect first. GPAI obligations followed. The high-risk regime for Annex III systems comes later still, and systems that are safety components of regulated products later again.

Practically, that argues for a specific order:

1. Screen for prohibited practices now. Fast, cheap, and eliminates the worst exposure. Emotion inference in workplace or education contexts is the one that catches people.
2. Build the inventory and settle roles. Everything downstream depends on both, and both take longer than expected because embedded vendor AI is hard to find.
3. Then do high-risk conformity work, on the systems where classification actually lands.

Organisations that start with conformity assessment before settling role determination routinely do the work twice: producing full technical documentation as a provider, then discovering on contract review that they were a deployer — and that the documentation they needed was a different artefact entirely.

We publish our analysis of deployer-side obligations — including the vendor question set for foundation model providers — as Governing AI You Did Not Build.