EU AI Act After the Digital Omnibus: Outsourcing AI to India

As of 3 October 2026. This guide is for founders, CTOs and procurement leads in the EU and UK who build AI features with a development partner in India, and for Indian teams serving them. After reading you will know which dates changed, which did not, who carries which obligations in an outsourcing deal, and what to put in the contract. It is general information, not legal advice.

What did the Digital Omnibus change in the EU AI Act

The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, mainly pushes back high-risk deadlines and softens some duties to ease the burden on smaller companies.

It was published in the Official Journal on 24 July 2026. The European Commission proposed the package on 19 November 2025. Council and Parliament negotiators reached a provisional agreement in May 2026 and the Parliament gave final approval in June 2026, according to published legal summaries. The original Act is Regulation (EU) 2024/1689 on EUR-Lex.

Obligation	Original date	After the Omnibus
Prohibited AI practices	2 February 2025	Unchanged and already in force
AI literacy (Article 4)	2 February 2025	Reworded: support the development of AI literacy, no guaranteed level per person
General-purpose AI model rules	2 August 2025	Unchanged
Transparency (Article 50)	2 August 2026	Unchanged; short grace period reported for machine-readable marking on existing generative systems
High-risk, stand-alone (Annex III)	2 August 2026	2 December 2027
High-risk, in regulated products (Annex I)	2 August 2027	2 August 2028

Legal summaries of the final text also report two new prohibited practices, concerning non-consensual intimate imagery and child sexual abuse material, applying from 2 December 2026.

Which AI systems count as high-risk under Annex III

Annex III lists stand-alone uses where AI can seriously affect people's rights or safety, including recruitment and worker management, education and exams, credit scoring, access to essential services, critical infrastructure, law enforcement, migration and justice.

For outsourcing buyers the common cases are:

• HR technology: CV screening, candidate ranking, promotion or termination decisions, task allocation and performance monitoring.
• Education technology: admissions decisions, grading, proctoring and detecting cheating.
• Fintech and insurance: creditworthiness assessment and certain life and health insurance pricing.
• Utilities and infrastructure: AI as a safety component in managing critical infrastructure.

A customer service chatbot, a document search assistant or a sales forecasting tool is usually not high-risk, though Article 50 transparency may still apply. Classification depends on intended purpose, so write the purpose down early.

What the delay does and does not change for your project

The delay gives high-risk builders until December 2027 to meet requirements such as risk management, data governance, logging, human oversight and conformity assessment, but it does not pause transparency, prohibited-practice, GPAI or GDPR obligations.

Treat the extra time as build time, not waiting time. A high-risk system started in late 2026 will likely reach users after December 2027, so its architecture must support the requirements from the first sprint. Retrofitting logging, human oversight controls and technical documentation into a finished system costs far more than designing them in.

For systems that are not high-risk, nothing about the delay matters. If your product includes a chatbot or generates images, audio, video or text for EU users, the Article 50 disclosure and marking duties already apply.

Who is the provider and who is the deployer when you outsource to India

When an EU company commissions an AI system from an Indian partner and markets or uses it under its own name, the EU company is usually the provider and the Indian team a supplier.

Scenario	Likely provider	Likely deployer	Indian partner's role
EU SaaS company sells an AI feature built by an Indian team under the SaaS brand	EU SaaS company	The SaaS company's customers	Developer, supplier of components and documentation
EU employer commissions a hiring tool for internal use only	EU employer (puts it into service under its own name)	EU employer	Developer
Indian company sells its own AI product to EU customers	Indian company	EU customers	Provider, must meet provider duties and appoint an EU representative where required

The Act applies outside the EU when a system is placed on the EU market or its output is used in the EU, so location does not remove obligations. It also expects third parties that supply components for high-risk systems to give the provider the information it needs, through a written agreement. That is a contract question, covered below.

What EU firms should put in contracts with Indian AI developers

A sound contract names the provider and deployer, records the intended purpose and risk classification, and obliges the development partner to deliver the documentation, logs, test evidence and cooperation the provider needs to meet its legal duties.

1. Roles: who is provider, who is deployer, and who decides intended purpose.
2. Risk classification: a written assessment, revisited if the purpose changes.
3. Technical documentation: architecture, data sources, model choices, known limitations, delivered with each release.
4. Logging: automatic event logs the provider can retain and inspect.
5. Human oversight: the controls a person uses to review, override or stop the system.
6. Testing and accuracy evidence: evaluation sets, metrics and bias checks.
7. Data protection: a GDPR data processing agreement, transfer mechanism such as Standard Contractual Clauses, and access controls for staff in India.
8. Incident handling: how quickly the partner reports a serious malfunction to the provider.
9. Article 50 features: AI interaction notices and content marking built in.
10. IP and model ownership: code, prompts, evaluation sets and fine-tuned weights.

Our guide to GDPR when outsourcing software development to India covers the data protection side in detail.

What Indian development partners should prepare now

Indian teams serving EU clients should be ready to supply the evidence a provider needs: written intended purpose, technical documentation, evaluation results, event logs, human oversight controls and a clear data protection setup for staff who access client data.

• Documentation templates for architecture, data sources, model and prompt versions, known limitations and change history, updated with every release.
• Evaluation practice: versioned test sets, accuracy and error-rate reports, and checks for uneven performance across user groups where the use case calls for it.
• Logging by default: who used the system, what it produced and what a human changed, retained according to the client's policy.
• Access controls in India: named engineers, masked data in development, and audit trails for production access.
• A contact point who can answer the client's compliance questions quickly when a regulator or customer asks.

None of this is exotic. It is good engineering practice written down, and EU buyers increasingly ask for it in the first call. Teams that already deliver it shorten procurement and win the work.

How we handle EU AI Act work for European clients

At JK Tech Hub, AI projects for European and UK clients start with a written intended purpose and risk classification agreed with the client's legal team, with documentation and logging built from sprint one.

• A European HR software client wanted an AI feature that summarises candidate interviews. Because it sat close to recruitment decisions, we designed it as a summarisation aid with a recruiter review step, kept full logs, and documented its limits so the client's counsel could classify it with evidence.
• A UK ecommerce client added a product-advice chatbot. It was not high-risk, but we added a clear AI disclosure at the start of every conversation and a route to a human, matching the transparency approach the client applies across EU markets.
• A Dutch logistics firm asked for a data processing agreement and access rules before sharing any production data. Development used masked data; production access was limited to named engineers.

We are engineers, not lawyers. The value we add is building systems that make the client's legal position easy to evidence.

What this means for your business

If you build a high-risk system, use the extra time to design compliance into the architecture; if not, focus on Article 50 and GDPR now, and always write provider and deployer roles into the contract.

A practical next step: list every AI feature in your roadmap, record its intended purpose, mark whether it touches an Annex III area, and check that your development partner's contract covers the ten points above. Penalties for prohibited practices reach up to 35 million euros or 7% of worldwide annual turnover, whichever is higher, so the classification step deserves care.

This article is general information and not legal advice. Confirm your obligations with qualified EU counsel.

Related reading and next step

• Software development for European clients
• GDPR when outsourcing to India
• Software development for UK clients
• AI agent security checklist

For a fixed quote in euros or pounds on an AI project built with documentation and logging from day one, contact us through the contact page or WhatsApp at +91 7265004040.