The EU AI Act can reach an Indian IT services firm or GCC even when no developer sets foot in Europe. It applies when you place an AI system on the EU market, or when its output is used in the EU. For Indian delivery teams, the practical question is which role you hold in each engagement (provider, deployer, importer or distributor), because that role decides who owns the documentation, logging, human oversight, transparency and incident duties you will end up building. The timeline also changed in 2026: the Digital Omnibus amendment is now law and pushes the main high-risk deadlines to December 2027 and August 2028, while transparency duties started in August 2026.
Not legal advice. This is a simplified engineering guide to Regulation (EU) 2024/1689 and its 2026 amendment, as published at the time of writing (October 2026). Role and risk classification depend on the facts of each engagement, and Commission guidance and harmonised standards are still arriving. Work with your client's counsel and your own legal team, and check the consolidated text on EUR-Lex before making compliance decisions.
The EU AI Act timeline in one page
The Artificial Intelligence Act is Regulation (EU) 2024/1689. It entered into force on 1 August 2024 and applies in stages. In November 2025 the Commission proposed a "Digital Omnibus on AI" to simplify it and delay the high-risk deadlines. That proposal is no longer pending: Parliament approved it on 16 June 2026, the Council adopted it on 29 June 2026, and it was published as Regulation (EU) 2026/1744, entering into force on 27 July 2026. Many articles written in early 2026 still show the old dates, so check which version a source describes.
| Date | What applies |
|---|---|
| 1 August 2024 | The Act enters into force |
| 2 February 2025 | Prohibited practices (Article 5) and the AI literacy duty (Article 4) |
| 2 August 2025 | Obligations for providers of general-purpose AI (GPAI) models; governance and penalty provisions |
| 2 August 2026 | General application, including Article 50 transparency duties and the Commission's enforcement powers over GPAI providers |
| 2 December 2026 | New prohibition on systems generating non-consensual intimate imagery or child sexual abuse material; end of the marking grace period for generative systems already on the market before 2 August 2026 |
| 2 December 2027 | High-risk obligations for stand-alone Annex III systems, such as employment, education and credit (originally 2 August 2026) |
| 2 August 2028 | High-risk obligations for AI in products under Annex I EU product laws, such as medical devices (originally 2 August 2027) |
The Omnibus also adjusted aspects of the AI literacy duty (check the consolidated text for the exact wording), kept registration of high-risk systems in the EU database, extended some SME relief to small mid-cap companies, and allowed limited processing of special-category data for bias detection where strictly necessary. For delivery teams the delay is not a reprieve: a high-risk system designed in 2026 will be in production when the 2027 date arrives, and retrofitting logging and oversight is far harder than building them in.
Does it apply to an Indian company?
Article 2 covers providers placing AI systems or GPAI models on the EU market "irrespective of whether those providers are established or located within the Union or in a third country", and providers and deployers outside the EU "where the output produced by the AI system is used in the Union". Importers, distributors and authorised representatives are covered too. Research and development before a system is placed on the market is excluded; real-world testing is not. Three patterns are common:
- You build, the client deploys in Europe. Whether you or the client is the provider depends on whose name the system carries and who defines its intended purpose. The contract should say so.
- Your own product, sold to EU customers. You are the provider, and for a high-risk system you must appoint an authorised representative in the EU.
- A GCC serving its European parent. The group usually carries the provider or deployer role, but the Hyderabad or Bengaluru engineers produce most of the evidence.
The risk tiers
The Act regulates by use, not technology. A chatbot and a CV ranker can share a model and still sit in different tiers.
- Prohibited. For example social scoring, harmful manipulation, emotion recognition in workplaces and schools (with narrow exceptions), untargeted scraping of facial images and, from December 2026, nudifier-style systems.
- High-risk. Safety components of products under Annex I laws, or systems in the eight Annex III areas: biometrics; critical infrastructure; education; employment and workers' management; access to essential private and public services; law enforcement; migration and border control; and justice and democratic processes. An Annex III system may fall outside the tier if it only performs a narrow or preparatory task, but a system that profiles people stays high-risk.
- Transparency obligations. Systems that interact with people, generate synthetic content, recognise emotions or produce deepfakes carry Article 50 disclosure duties.
- Minimal risk. Most internal productivity tools, code assistants and search features, with no specific duties beyond AI literacy.
GPAI model providers (the model labs) must publish technical documentation and a training-content summary and keep a copyright policy, with extra safety duties for models with systemic risk. The Commission published the voluntary GPAI Code of Practice on 10 July 2025, with chapters on transparency, copyright, and safety and security. Teams that only call a model API are usually not GPAI providers, but they depend on the documentation providers publish.
Identifying your role in each engagement
Role is decided per system and per engagement, not per company.
| Role | Who it usually is | Core duties |
|---|---|---|
| Provider | Develops the system, or has it developed, and places it on the market under its own name | Risk management, data governance, documentation, logging, oversight design, quality management, conformity assessment, registration, monitoring, incident reporting |
| Deployer | Uses the system under its authority in a professional context | Use per instructions, competent human oversight, input data checks, logs kept at least six months, inform affected people and workers |
| Importer | EU entity placing a non-EU provider's system on the EU market | Verify conformity assessment, documentation and CE marking |
| Distributor | Makes the system available in the supply chain | Verify markings and documentation |
The trap for services firms is Article 25. A deployer, distributor, importer or other third party becomes the provider of a high-risk system if it puts its name or trademark on it, makes a substantial modification, or changes the intended purpose of a system (including a general-purpose one) so that it becomes high-risk. If your team wires a client's generic HR chatbot into shortlisting decisions, someone has just become a high-risk provider.
Contract clauses Indian vendors should negotiate
Most of a vendor's exposure is settled, or left dangerously vague, in the statement of work. Ask legal to cover:
- Role allocation: who is provider for each system, and who approves the intended purpose.
- Classification: who classifies the system, with recorded reasoning and re-classification when scope changes.
- Documentation: technical documentation, instructions for use and test reports as named, accepted deliverables.
- Supply chain: which GPAI models and datasets are used, and approval for model changes.
- Change control: a substantial-modification gate before anyone changes purpose or design.
- Logs and incidents: who stores logs and for how long, and party-to-party notification timelines shorter than the legal deadlines.
The AI Act does not replace GDPR; pair these clauses with data processing terms. Teams already doing this for India's data law will find the patterns in our DPDP Act guide for AI applications transfer well.
Obligation to engineering artefact
Put this table in front of your delivery lead. Articles are high-risk provider requirements unless noted.
| Obligation | Engineering artefact |
|---|---|
| Risk management (Art. 9) | Living risk register linked to test cases and mitigations, reviewed each release |
| Data governance (Art. 10) | Versioned dataset cards: source, lineage, labelling, representativeness and bias analysis |
| Technical documentation (Art. 11, Annex IV) | Architecture document, model and prompt versions, evaluation results, partly generated from CI |
| Record-keeping (Art. 12) | Automatic event logs tying each output to model version, inputs, reviewer action and time; tamper-evident storage |
| Transparency to deployers (Art. 13) | Instructions for use: intended purpose, limitations, accuracy metrics, oversight steps |
| Human oversight (Art. 14) | Reviewer UI with evidence, override and stop controls |
| Accuracy, robustness, cybersecurity (Art. 15) | Evaluation thresholds in CI, adversarial and prompt-injection tests, drift monitoring |
| Quality management (Art. 17) | Documented SDLC, change control and release approvals |
| Monitoring and incidents (Art. 72, 73) | Production dashboards, alert rules, incident runbook with reporting clocks |
| Transparency, all tiers (Art. 50) | AI disclosure in the UI, machine-readable marking of generated media, deepfake labels |
If your organisation is pursuing ISO/IEC 42001, many of these artefacts double as management-system evidence. Certification is not AI Act conformity, but it gives you the process skeleton.
Documentation and logging
Treat documentation as a build output. Generate model, prompt and dataset versions, evaluation scores and dependencies from the pipeline, and let humans write only what needs judgment: intended purpose, limitations and risk reasoning. Design the log schema early so every output links to the model, prompt template, retrieval context and reviewer decision that produced it, with personal data masked. Our AI observability guide covers the tracing that makes this practical.
Human oversight design
Article 14 asks that people overseeing a high-risk system can understand its limits, detect anomalies, stay alert to automation bias, interpret outputs, and override or stop it. A reviewer clicking "approve" on a ranked list meets none of that. Show the evidence behind each output, make overriding as easy as accepting, sample cases for blind review to catch rubber-stamping, and give a stop control that actually halts processing. Deployers must also assign reviewers with the competence and authority to act. Patterns for approval gates and reviewer load are in our human-in-the-loop AI guide.
Transparency to users: chatbots and deepfakes
Article 50 applies whatever the risk tier. Providers must tell people they are interacting with an AI system unless that is obvious, and mark synthetic audio, image, video and text output in a machine-readable way. Deployers must disclose deepfakes, and AI-generated text published to inform the public on matters of public interest unless it has had human editorial review. For a support bot your team ships to a European retailer, that means a disclosure at the start of the conversation, a route to a human, and content marking applied in the generation pipeline, not bolted on later. Check the Commission's transparency guidelines alongside the article.
Data governance and incident reporting
Article 10 requires training, validation and test data for high-risk systems to be relevant, sufficiently representative and, as far as possible, error-free and complete, with documented examination for bias. Build that analysis into the data pipeline and record the GDPR legal basis for any EU personal data.
Providers of high-risk systems must report serious incidents to the market surveillance authority where they occurred within 15 days of becoming aware, 2 days for widespread infringements or serious disruption of critical infrastructure, and 10 days where a death is involved; an incomplete initial report is allowed. Deployers must inform the provider first, so a vendor's runbook needs a client-notification step measured in hours. Fold this into the incident process in our enterprise AI governance framework.
Penalties
Article 99 sets maximum fines of up to EUR 35 million or 7 per cent of worldwide annual turnover, whichever is higher, for prohibited practices; up to EUR 15 million or 3 per cent for most other breaches, including provider, deployer and transparency duties; and up to EUR 7.5 million or 1 per cent for misleading information to authorities. SMEs face the lower of the two amounts. GPAI provider fines sit separately in Article 101.
Illustrative example: a CV-screening tool for a European client
Consider an Indian IT services firm in Hyderabad engaged by a German logistics group to build a tool that parses CVs, scores candidates against job requirements and produces shortlists for recruiters, using a hosted LLM for extraction and a ranking model trained on past hiring outcomes.
Classification. Annex III point 4 lists systems intended "to analyse and filter job applications, and to evaluate candidates". Ranking candidates is profiling, so the narrow-task exception does not help. It is high-risk, with obligations from 2 December 2027.
Roles. If the client deploys it under its own name and defines the purpose, the client is likely both provider and deployer, and the vendor builds to provider requirements and delivers the evidence. If the vendor sells it as a branded product to several employers, the vendor is the provider. The SOW must pick one.
CV upload -> parse (LLM) -> PII mask -> score
| |
v v
event log <- reviewer UI (evidence, override)
| |
v v
bias + drift reports shortlist to recruiterWhat the team builds. A dataset card showing historical hiring data was examined for bias, with names, photos and age proxies removed or tested; per-subgroup evaluation thresholds in CI; a reviewer screen explaining each score and letting recruiters reorder freely; logs linking every shortlist to model and prompt versions; instructions for use forbidding automatic rejection; and notice templates so the client can inform candidates and workers' representatives. GDPR rules on automated decision-making apply in parallel.
What changes for the vendor. Fixed-bid estimates must include documentation, evaluation and oversight work a prototype would skip. That move from AI demo to enterprise outcome is what Forward Deployed Engineers handle on client sites, and Cloudsoft's FDE PRO program trains engineers for it.
Getting your delivery teams ready
The AI literacy duty applies to every provider and deployer, and Indian teams building for EU clients are the people operating those systems. Readiness means an AI inventory with role and tier per engagement, a classification checklist in pre-sales, artefact templates from the table above, and shared vocabulary across architects, testers and project managers. Cloudsoft runs corporate AI training for IT services and GCC teams covering governance, evaluation and production engineering with hands-on labs.
FAQ
Does the EU AI Act apply to Indian IT companies?
It can. It covers providers placing AI systems on the EU market wherever they are located, and non-EU providers and deployers whose AI output is used in the EU. Coverage depends on the facts and your role in each engagement.
Was the EU AI Act delayed by the Digital Omnibus?
Partly. Regulation (EU) 2026/1744, in force since 27 July 2026, moved Annex III high-risk obligations to 2 December 2027 and Annex I product obligations to 2 August 2028. Prohibitions, AI literacy, GPAI duties and Article 50 transparency duties were not delayed.
Is a CV-screening tool high-risk under the EU AI Act?
Usually yes. Annex III lists AI used for recruitment or selection, including filtering applications and evaluating candidates, and systems that profile people stay high-risk.
If we only build the system for a client, are we the provider?
Not necessarily. The provider places the system on the market under its own name, often the commissioning client. A vendor that brands it, substantially modifies it or repurposes it into a high-risk use can become the provider. Settle this in the contract.
Do we need to follow the GPAI Code of Practice?
The Code is voluntary and aimed at providers of general-purpose AI models. Teams that only build applications on a model API are usually not GPAI providers.
What must a chatbot built for European users disclose?
Users must be told they are interacting with AI unless it is obvious, and generated content must be machine-readably marked. Deployers must disclose deepfakes. These Article 50 duties apply from 2 August 2026 in every risk tier.
Is this article legal advice?
No. It is an engineering guide that simplifies the regulation. Work with counsel and check the consolidated text on EUR-Lex before making compliance decisions.
If your delivery teams see AI Act clauses in European SOWs, a shared foundation across the team helps more than a policy document. Talk to Cloudsoft about customised corporate training for architects, developers and testers, in Ameerpet, Hyderabad, on-site or live online. Call +91 96660 19191 to discuss a programme.
