On this page · 10 sections
- The two rules, stated correctly
- What the RBI FAQ actually says about processing
- The GPU bill, priced against Amazon's published rates
- Which model, and the break-even nobody runs
- Where private deployment is genuinely the answer
- India-specific considerations
- What we build, and how
- FAQ
- How eCorpIT can help
- References
Summary. Two claims drive most private LLM sales conversations in India, and both are wrong as stated. The Digital Personal Data Protection Rules, notified on 14 November 2025 with an eighteen-month phased compliance window running to May 2027, impose no blanket data localisation on Indian businesses. Local storage applies only where the government issues directions on restricted categories of data to Significant Data Fiduciaries. Separately, the Reserve Bank of India's circular of 6 April 2018 does require payment system data to be stored only in India, but its own FAQ states there is no bar on processing payment transactions outside India, provided the data is deleted abroad and returned within one business day or 24 hours, whichever is earlier. Storage and processing are different obligations. Getting that distinction wrong costs real money: an 8x H200 reservation to serve a 975B open-weights model runs $29,053 a month at Amazon's published Mumbai rate of $39.799 per hour. Penalties under the DPDP Act reach ₹250 crore. Both numbers deserve to be spent against the actual rule, not a misreading of it.
The two rules, stated correctly
Indian data law is not one regime. It is at least two, they apply to different entities, and they say different things. Conflating them is the most common error we see in AI architecture reviews.
| Obligation | DPDP Act 2023 + Rules 2025 | RBI Storage of Payment System Data |
|---|---|---|
| Who it binds | Data Fiduciaries processing digital personal data | PSOs, banks, gateways, intermediaries under the PSS Act 2007 |
| Localisation | No general mandate; local storage only via government direction on restricted categories | Entire payment system data stored only in India |
| Offshore processing | Not prohibited by the Rules | Permitted, but data deleted abroad and back within 24 hours |
| Key date | Notified 14 Nov 2025; 18-month phased window | Circular dated 6 April 2018; six-month deadline then |
| Maximum penalty | ₹250 crore for security-safeguard failure | Directive under PSS Act 2007; system audit via CERT-In empanelled auditor |
The Press Information Bureau's own summary of the DPDP Rules is explicit about the narrow scope of localisation. Significant Data Fiduciaries face stronger duties, including independent audits and impact assessments, and "in some cases, they must follow government directions on restricted categories of data, including local storage where needed." That is a conditional obligation on a specific class of entity, triggered by a government direction that names categories. It is not a rule that says Indian personal data must stay in India.
The penalty structure is worth quoting precisely, because it is routinely inflated in sales decks. The highest penalty, up to ₹250 crore, applies to a Data Fiduciary's failure to maintain reasonable security safeguards. Failure to notify the Board or affected individuals of a breach, and violations of obligations relating to children, each attract up to ₹200 crore. Any other violation attracts up to ₹50 crore. Note what the ₹250 crore ceiling is actually for: weak security, not offshore hosting.
What the RBI FAQ actually says about processing
The RBI directive is the stricter of the two, and it is the one that genuinely reshapes architecture for anyone in payments. Circular DPSS.CO.OD.No 2785/06.08.005/2017-18, dated 6 April 2018, told all system providers to ensure the entire data relating to payment systems is stored in a system only in India.
Its scope is broad. The RBI's FAQ confirms the directions apply to all Payment System providers authorised under the Payment and Settlement Systems Act, 2007, to all banks operating in India, and to system participants, service providers, intermediaries, payment gateways and third party vendors engaged by those entities. The data covered includes customer data such as name, mobile number, email, Aadhaar and PAN, payment sensitive data, payment credentials including OTPs and PINs, and full transaction data.
Then comes the clause that most private LLM pitches omit entirely. On processing, the RBI FAQ states: there is no bar on processing of payment transactions outside India if so desired by the PSOs, but the data shall be stored only in India after the processing. Where processing happens abroad, the data must be deleted from systems abroad and brought back to India not later than one business day or 24 hours from payment processing, whichever is earlier.
Read that against an LLM call. A model inference is processing. The RBI's rule does not forbid it happening outside India. It forbids the data resting outside India, and it sets a hard deletion clock. Whether a given foreign API provider will contractually guarantee deletion inside 24 hours, and evidence it in a System Audit Report from a CERT-In empanelled auditor, is a procurement question, not a physics question.
That is the honest position, and it cuts against our own commercial interest to state it: for a great many Indian workloads, the law does not force you onto your own GPUs. What forces you onto your own GPUs is usually the inability to get an acceptable contractual and audit answer from the provider, not the text of the directive.
The GPU bill, priced against Amazon's published rates
When residency does drive the decision, the cost is knowable rather than mysterious. Amazon publishes EC2 Capacity Blocks for ML pricing per instance and per accelerator.
As of 15 July 2026, a p5e.48xlarge with 8 NVIDIA H200 GPUs costs $39.799 per hour in Asia Pacific (Mumbai), which is the same rate as US West (Oregon) and US East (Ohio). A p5.48xlarge with 8 H100s costs $31.464 per hour in Mumbai, against $34.608 in Oregon. Mumbai is cheaper for H100 capacity and identical for H200 capacity.
| Configuration | Mumbai hourly | Monthly (730h) | Serves | Note |
|---|---|---|---|---|
| p5e.48xlarge (8x H200) | $39.799 | $29,053 | Inkling at NVFP4 W4A16 | Same rate as Oregon |
| 2x p5e.48xlarge (16x H200) | $79.598 | $58,107 | Inkling at BF16, 2 TB VRAM | Full precision |
| p5.48xlarge (8x H100) | $31.464 | $22,969 | Smaller open models | Cheaper in Mumbai than Oregon |
| p4d.24xlarge (8x A100) | Not listed for Mumbai | - | Older workloads | Check region availability |
| Managed API | $0 idle | Usage only | No GPUs to run | Residency depends on contract |
The residency premium people assume exists, in AWS Capacity Blocks terms, does not. For an Indian team, keeping inference in Mumbai carries no Capacity Blocks surcharge over running it in Virginia, and on H100 capacity it is cheaper. That removes the usual budget objection to residency, and it means the argument should be made on the rule, not on an imagined cost penalty.
One caution on reservations: Amazon states that reservation prices are updated regularly based on trends in supply and demand, with the next update scheduled for July 2026, and that a Capacity Block is charged at the prevailing rate at the time of purchase. The rate you are quoted is the rate you buy, not a rate you keep.
Which model, and the break-even nobody runs
Thinking Machines Lab released Inkling on 15 July 2026 under an Apache 2.0 licence: 975B total parameters, 41B active, a 1M-token context window in the open weights, and native text, image and audio input. Its model card requires at least 2 TB of aggregated VRAM for the BF16 checkpoint, or 600 GB for the NVFP4 checkpoint, which runs W4A16 on 8 H200s. That is what makes the $29,053 Mumbai line above a real option rather than a thought experiment.
Inkling debuted at 41 on the Artificial Analysis Intelligence Index, ahead of Nemotron 3 Ultra at 38, and averages 25K output tokens per Intelligence Index task against 43K for GLM-5.2.
Now the arithmetic almost nobody does before signing. Against Inkling's Tinker API price of $4.68 per million output tokens, the $29,053 monthly GPU bill breaks even at roughly 6.2 billion output tokens a month, which is about 2,362 output tokens every second, sustained, for a month. We work through that calculation in detail in our analysis of Inkling's self-host versus API economics.
If your workload clears that, self-hosting pays for itself and residency is a free bonus. If it does not, and for most BFSI and healthcare workloads it does not, then the GPU bill is the price of compliance and should be entered in the budget under that name. Calling it a cost saving when it is a compliance cost is how AI programmes lose credibility with a CFO in the second quarter.
Mitch Ashley of The Futurum Group framed the strategic side of this to the Wall Street Journal: "It gives Western enterprises a credible alternative positioned on customization economics, shifting spend from per-token API pricing to infrastructure the enterprise controls." The spend shifts. It does not vanish.
Where private deployment is genuinely the answer
Four situations, in our experience, survive scrutiny.
Payment data under the RBI directive where the provider will not contract to the 24-hour deletion clock and evidence it in a System Audit Report. This is the cleanest case. The rule is specific, the auditor is named, and the answer is architectural.
Significant Data Fiduciary status combined with a government direction on restricted categories. This is the only route by which DPDP itself compels local storage, and it depends on directions that name the categories.
Fine-tuning on proprietary data where the tuned weights are the asset. Under Apache 2.0 the resulting weights are yours, and no vendor can reprice or retire them. Tinker retired eleven Qwen models, six Llama models and Kimi-K2-Thinking on 12 June 2026, which is a fair illustration of the deprecation risk you carry on someone else's platform.
Contractual dead ends, where the client's own customers impose residency terms stricter than Indian law requires. This is common in BFSI subcontracting and it is a commercial fact rather than a legal one, but it binds just as hard.
Everything else deserves the managed-API answer with a residency clause, and an honest note in the architecture document explaining why.
India-specific considerations
The Consent Manager requirement is the DPDP provision most likely to catch AI teams unprepared, and it is structural rather than optional. The Rules require Consent Managers to be companies based in India, which rules out simply appointing an offshore affiliate. Our note on DPDP Consent Manager framework readiness covers what that means for product teams.
The phased window matters for sequencing. The Rules were notified on 14 November 2025 and establish the Data Protection Board of India as a four-member digital-first body, with appeals heard by the Appellate Tribunal, TDSAT. The Press Information Bureau describes an eighteen-month period for phased compliance, which places the end of that window in May 2027. Teams treating May 2027 as distant should note that a model fine-tuned this year on personal data will still be in production then, and retrofitting erasure rights into a trained model is materially harder than designing for them now. Our breakdown of DPDP compliance costs for Indian startups sets out the deadline arithmetic.
The ninety-day response requirement for access, correction, updating and erasure requests is the one that interacts worst with LLM architectures. A retrieval index is straightforward to purge. A set of fine-tuned weights is not. Design the boundary between the two deliberately, and keep personal data on the retrieval side of it wherever the use case allows. That single decision saves more compliance pain than any hosting choice.
What we build, and how
eCorpIT designs and runs private and hybrid LLM deployments for Indian organisations, and the engagement usually starts with the question this article is about: does the rule actually require this. We read the applicable directive against your data flows first, because a residency answer that nobody checked is the most expensive kind.
Where private deployment is warranted, the work is concrete: model selection against your workload rather than a leaderboard, capacity sizing and throughput measurement before any reservation is signed, deployment on Kubernetes with the weights distribution and rollback path solved, retrieval architecture that keeps personal data out of the weights, and audit evidence your CERT-In empanelled auditor can actually use. We design applications aligned with DPDP Act requirements and, for payments workloads, aligned with the RBI's storage directive. We do not claim to certify anyone against either.
Where it is not warranted, we say so and design the managed-API path with the residency and deletion clauses that make it defensible. Related work is covered in our managed Kubernetes AI platform service and our RAG knowledge assistant service, and the cost discipline side in our cloud FinOps managed service.
eCorpIT is CMMI Level 5 certified and MSME certified, founded in 2021 and based in Gurugram, with partnerships including AWS, Microsoft and Google. Our teams are senior-led and multi-disciplinary, which matters here because this decision sits across legal interpretation, infrastructure economics and model engineering at once, and getting two of the three right still produces the wrong answer.
FAQ
How eCorpIT can help
eCorpIT's senior engineering teams design private and hybrid LLM deployments for Indian organisations in BFSI, healthcare and regulated sectors, starting from the applicable directive rather than a hosting preference. We read the RBI storage circular and the DPDP Rules against your actual data flows, measure throughput before any GPU reservation is committed, and design applications aligned with DPDP Act and RBI storage directive requirements. Where the managed API is genuinely the right answer, we will tell you that and design the contractual controls instead. Talk to us before you buy a Capacity Block you may not need.
References
- DPDP Rules, 2025 Notified: A Citizen-Centric Framework for Privacy Protection and Responsible Data Use - Press Information Bureau, Government of India, 17 November 2025
- Storage of Payment System Data: Frequently Asked Questions - Reserve Bank of India, 26 June 2019
- Amazon EC2 Capacity Blocks for ML pricing - Amazon Web Services
- Inkling Model Card - Thinking Machines Lab, 15 July 2026
- Inkling: Our open-weights model - Thinking Machines Lab, 15 July 2026
- Models and Pricing - Tinker Documentation, Thinking Machines Lab
- Thinking Machines has released Inkling, the new leading U.S. open weights model - Artificial Analysis, 15 July 2026
- Mira Murati's Thinking Machines drops Inkling, an open-weights model anyone can access - Mike Wheatley, SiliconANGLE, 15 July 2026
- Thinking Machines amps up its bet against one-size-fits-all AI with its first open model, Inkling - Connie Loizos, TechCrunch, 15 July 2026
- Thinking Machines' first model bets big on customization - Madison Mills, Axios, 15 July 2026
- Artificial Analysis: Inkling model page - Artificial Analysis
Last updated: 17 July 2026. Regulatory positions summarised from the primary texts cited above and are not legal advice; AWS Capacity Blocks reservation rates change with supply and demand.