EU AI Act + DPDPA + Sectoral Rules: How Indian Enterprises Navigate a Multi-Jurisdiction Compliance Maze

An Indian fintech serving European customers while processing Indian user data now answers to the EU AI Act, the GDPR, the DPDP Act and Rules, and RBI master directions - simultaneously, with different definitions, different deadlines, and different regulators.

The instinct is to run four programmes. That is how compliance teams end up testing the same encryption control four times for four different auditors while the actual risk goes unexamined. There is a better structure, and the timing to adopt it is now.

Why This Became Urgent This Month

Three clocks converged.

The EU AI Act entered into force in August 2024 with staggered application. Prohibited practices and AI literacy obligations applied from February 2025. General-purpose AI model obligations followed in August 2025. The high-risk system obligations under Annex III became applicable on 2 August 2026 - which means the classification work that was theoretical last year now determines whether a deployed system is lawful.

India's DPDP Rules were notified on 13 November 2025. Penalties and appeals commence 13 November 2026. Full compliance is due 13 May 2027.

Sectoral regulators have moved in parallel. RBI's Master Direction on IT Governance, Risk, Controls and Assurance Practices set board-level accountability for technology risk. SEBI's Cybersecurity and Cyber Resilience Framework brought a standardised control baseline to market participants. IRDAI's information and cybersecurity guidelines did the same for insurers.

The result is that an enterprise which deferred this work now faces three live obligations rather than one pending one.

The Overlap Matrix

The frameworks classify risk on different axes. Understanding which axis each uses is what makes a unified control set possible.

Read the table by column and you have four programmes. Read it by row and the structure becomes visible: four regimes asking related questions about the same systems, the same data, and the same controls.

The Highest-Common-Denominator Strategy

The strategy is to implement each control at the strictest applicable standard once, then map that single implementation to every regime that requires it - rather than implementing a distinct control per regime.

Where it works well:

• Security safeguards. DPDPA requires reasonable security safeguards. GDPR requires appropriate technical and organisational measures. Sectoral frameworks specify baselines. Implement to the strictest, evidence once.
• Breach notification. DPDPA and the Rules require notification to the Board within 72 hours. GDPR requires 72 hours to the supervisory authority. Sectoral regulators impose shorter incident reporting windows. Build one detection and escalation pipeline calibrated to the shortest clock, with regime-specific notification templates hanging off it.
• Records of processing. A well-built RoPA satisfies GDPR Article 30, provides the evidence base for DPDPA obligations, and feeds EU AI Act technical documentation for data governance.
• Access control, logging, encryption. Essentially universal. One implementation, many mappings.

Where it fails, and where you genuinely need jurisdiction-specific controls:

• Lawful basis. GDPR offers six bases including legitimate interests. The DPDP Act offers consent plus a narrow set of certain legitimate uses, and there is no general legitimate-interests ground. A processing activity resting on legitimate interests in the EU may have no lawful basis in India. This cannot be harmonised; it must be assessed per jurisdiction.
• Consent mechanics. DPDPA requires notice in English or any language in the Eighth Schedule, and contemplates a registered Consent Manager. GDPR has no equivalent intermediary construct.
• Data subject and Data Principal rights. The right sets overlap but are not identical. DPDPA includes a right of nomination with no GDPR analogue. GDPR includes portability and objection rights that the DPDP Act does not replicate in the same form.
• AI system classification. The EU AI Act's Annex III high-risk categories are specific use cases - employment, creditworthiness, essential services, education. Nothing in DPDPA classifies systems this way.

The honest version of the strategy is therefore hybrid: a large shared control core, with a deliberately maintained jurisdiction-specific layer for lawful basis, consent mechanics, rights, and AI classification.

Data Localisation and Cross-Border Transfer

This is where Indian enterprises most often carry an outdated mental model.

The DPDP Act takes a negative-list approach under Section 16. Transfer of personal data outside India is permitted by default, and the Central Government may restrict transfer to countries it notifies. This is materially different from the GDPR's positive-list model, where transfer requires an adequacy decision, Standard Contractual Clauses, binding corporate rules, or a derogation.

Three consequences follow:

Section 16 is a floor, not a ceiling. The Act expressly preserves stricter sectoral requirements. RBI's payment system data storage directive remains binding on payment system operators regardless of the DPDPA's more permissive default. Telecom and health-sector requirements likewise continue to apply. An enterprise concluding "DPDPA permits transfer, so we are fine" has read one instrument and ignored the one that actually binds it.

Significant Data Fiduciaries may face additional restrictions. The Rules contemplate restrictions on transferring specified categories of personal data outside India for entities notified as significant. Plan architecture on the assumption that this may apply to you.

The EU direction is the harder one. Moving EU personal data into India requires a GDPR transfer mechanism, and India has no adequacy decision. That means SCCs plus a transfer impact assessment, and the TIA has to survive scrutiny of Indian government access powers.

For AI pipelines specifically, there is a trap worth naming. Inference may run in a local region while fine-tuning, evaluation, or logging runs elsewhere. Residency assessed at the inference endpoint alone will miss the training and telemetry flows entirely, and those are the flows most likely to carry the largest volume of personal data.

One Control, Many Mappings

The operational pattern that makes this manageable is a control library with many-to-many mapping to regulatory clauses.

A single control - "Personal data at rest is encrypted using approved algorithms with keys managed in a hardware security module" - maps simultaneously to DPDPA reasonable security safeguards, GDPR Article 32, the applicable sectoral baseline, and the EU AI Act's accuracy and robustness requirements for high-risk systems.

Test it once. Collect the evidence once. Present it four times, each time filtered to the clauses that regulator cares about.

The arithmetic is what sells this internally. An enterprise with 200 controls across four regimes, testing each regime separately, performs 800 tests annually. With a mapped library where roughly 70 percent of controls are shared, the same assurance requires closer to 320 tests. The saving is not primarily the tester's time - it is the elimination of the situation where the same control is found compliant by one team and deficient by another because they tested it differently.

A Worked Example

Consider a mid-size Indian IT services firm: 4,000 employees, delivery centres in India, clients across the EU and the US, and an internally built AI system that screens inbound job applications.

Regulatory footprint. DPDPA applies to employee and candidate personal data. GDPR applies to EU client personal data processed under delivery contracts, and to EU-based candidates. The EU AI Act applies to the CV screening system, because employment-related screening sits in Annex III as a high-risk category, and it applies regardless of where the system was built if the output is used in the EU. Client contracts add ISO 27001 and SOC 2 obligations on top.

The naive approach. Four workstreams, four owners, four evidence repositories, four audits. The CV screening system gets assessed for GDPR by the privacy team and for the AI Act by nobody, because it was built internally and never went through vendor review.

The mapped approach. One control library. The screening system is registered once in the AI inventory with its Annex III classification, its DPDPA purpose and lawful basis, and its GDPR DPIA reference all attached to the same record. Access control, logging and encryption controls are tested once and mapped to all four regimes. The genuinely jurisdiction-specific work - the Annex III conformity documentation, the DPDPA consent basis for candidate data, the GDPR transfer mechanism - is scoped as a small, visible delta rather than being buried inside four parallel programmes.

The second approach is not less rigorous. It is more rigorous, because the single highest-risk system in the example is one that the first approach never assesses at all.

Conclusion

Multi-jurisdiction compliance is not a volume problem. It is a structure problem. Enterprises that organise by regulator produce duplicated testing, inconsistent findings, and systematic blind spots where a system falls between two teams. Enterprises that organise by control - implementing to the strictest applicable standard and mapping outward - produce less work and better coverage at the same time.

The convergence of the EU AI Act's high-risk obligations, the DPDPA's phased commencement, and sectoral technology governance means the cost of the wrong structure compounds from here.

Actionable recommendations:

• Build the control library before the next audit, not during it. Retrofitting mappings while an auditor waits produces mappings designed to pass rather than mappings that reflect reality.
• Assess lawful basis per jurisdiction, and expect divergence. Processing resting on legitimate interests under GDPR may have no equivalent ground under the DPDP Act. This is the single most common finding in multi-jurisdiction reviews.
• Treat Section 16 as a floor. Sectoral localisation requirements survive the DPDPA's permissive default. Check the instrument that licenses you, not only the one that governs personal data generally.
• Classify AI systems against Annex III now. The high-risk obligations became applicable on 2 August 2026. A system in scope that has not been classified is already exposed.
• Trace AI data flows end to end, not at the inference endpoint. Training, evaluation and telemetry flows commonly cross borders that the serving path does not.

One control, multiple regulatory mappings. Test once, evidence once, and report to each regulator in its own language - with the delta between regimes made explicit rather than discovered at audit. See how Dedups.ai unifies DPDPA, EU AI Act, ISO 27001 and sectoral control sets in a single library.