India's AI Policy: National Strategy and Implementation

One model, three regulators, three different questions

Suppose an Indian fintech has built a credit-underwriting model that scores loan applicants from their UPI transaction history and bureau data. Two decisions are on the table. First, the company wants to train the next version on rented GPU capacity from a US hyperscaler, because the workload is bursty and IndiaAI Mission's own subsidised compute facility currently has a waitlist for large training jobs. Second, the company has a term sheet to license the underwriting model to a bank's European subsidiary and to a buy-now-pay-later platform operating in the United States. The exact same trained model now has to clear three completely different legal machines, and the differences are not cosmetic.

In India, the relevant question is about the training data: did the customers whose UPI histories feed the model give consent that covers this specific use, or does the processing fall under a narrower exemption, and does shipping that raw data to a foreign GPU cluster trigger a transfer restriction? In the European Union, nobody at the regulator's desk asks about training-data consent at all — that question belongs to a separate law (the GDPR). The AI Act asks a structurally different question: does the finished, deployed system fall into a category the law has pre-classified as "high-risk," and if so, has it cleared a conformity assessment before it is placed on the market? In the United States, there is no AI-specific statute to consult in the first place. The live question is whether a fair-lending law written in 1974, decades before anyone had trained a transformer, already covers what this score does — and it does, which is precisely the point.

That is the actual subject of most of this chapter: after a brief look at what India's national AI strategy actually funds, the focus turns to how India's approach to governing AI is built, mechanically, and how that construction differs in kind — not just in generosity or ambition — from the two other major regulatory architectures a system like this will run into the moment it crosses a border.

What the "national strategy" actually is: NITI Aayog's blueprint and the IndiaAI Mission

India's national AI strategy did not start with the IndiaAI Mission. NITI Aayog published the "National Strategy for Artificial Intelligence" (branded #AIforAll) in June 2018, well before any binding AI-specific instrument existed — a strategy document, not a funded implementation programme, that identified five sectors for priority AI intervention: healthcare, agriculture, education, smart cities and infrastructure, and smart mobility. It set direction; it did not allocate money at implementation scale.

The funded programme came six years later. In March 2024, the Union Cabinet approved the IndiaAI Mission with a total outlay of ₹10,372 crore (roughly $1.25 billion) to be spent across multiple years, administered by MeitY. The Mission is organised into seven pillars: IndiaAI Compute Capacity (subsidised GPU access for startups, researchers, and academia — the waitlisted facility in this chapter's opening hypothetical), IndiaAI Innovation Centre (large-scale foundation-model development), IndiaAI Datasets Platform (a high-quality, non-personal government dataset repository), IndiaAI Application Development Initiative (sector-specific AI deployment in areas such as agriculture and healthcare), IndiaAI FutureSkills (AI education and workforce programmes), IndiaAI Startup Financing (funding support for AI startups), and Safe & Trusted AI (the pillar housing the AI Safety Institute referenced later in this chapter). As of the most recent public reporting, implementation has been uneven across pillars: Compute Capacity is the most visibly operational, having empanelled private cloud providers to offer GPU hours at subsidised rates; the other six pillars are at earlier and less publicly documented stages of rollout.

That funding and capacity-building programme is the "national strategy" half of this chapter's title. The rest of the chapter turns to a separate, harder question the Mission itself does not answer: once a system is built — whether trained on Mission-subsidised compute or not — what law governs how it can be deployed? That is where India's approach diverges most sharply from the EU's and the US's, and it is the actual subject of what follows.

Three architectures for regulating the same technology

Strip away the country names and there are really only two design axes that decide how a jurisdiction regulates AI. The first is timing: ex-ante regulation makes a system clear a compliance bar before it may be deployed at all (a permission model); ex-post regulation lets deployment happen and applies existing law after harm is shown or a complaint is filed (a liability model). The second is scope: horizontal law applies one rule to a category of technology or data across every industry at once (the GDPR applies to personal data whether it is held by a bank, a hospital, or a game studio); sectoral law leaves each industry's existing regulator — banking, employment, medical devices — to decide how its own existing rulebook applies to AI, rather than writing one common AI statute.

Plotted on those two axes, the European Union sits at one corner (ex-ante, and increasingly horizontal for AI specifically), the United States sits at the opposite corner (ex-post, sectoral), and India, as the next three sections show, currently occupies neither corner: a horizontal law for the data feeding AI systems, paired with sectoral, mostly soft-law treatment of the AI systems themselves.

The EU's risk pyramid, and why August 2026 is not a random month to be reading this

The EU AI Act sorts every AI system into one of four risk tiers before asking anything else about it. Unacceptable-risk systems — real-time biometric surveillance of public spaces by law enforcement outside narrow exceptions, social-scoring of citizens, manipulative systems that exploit vulnerabilities — are banned outright. High-risk systems are not banned but must clear a compliance gate before deployment: this tier is defined by an explicit annex (Annex III) that lists specific use cases, including AI used to evaluate a person's creditworthiness or credit score — which is exactly the category our fintech's underwriting model falls into. Limited-risk systems, such as chatbots or deepfake generators, carry transparency duties (tell the user they are talking to a machine). Minimal-risk systems carry no obligations at all.

A high-risk classification is expensive to satisfy: the provider must run a documented risk-management process across the system's lifecycle, maintain technical documentation and automatic logging, ensure a human can meaningfully oversee and override the system's outputs, and register the system in an EU-wide database before it can be placed on the market — all before the first live decision is made about a real applicant. Layered on top of this, a separate chapter of the Act (Articles 51–56) governs general-purpose AI (GPAI) models — the large foundation models other companies fine-tune on top of — independently of any specific use case. A GPAI model is presumed to carry "systemic risk," triggering the Act's strictest obligations (adversarial testing, incident reporting, cybersecurity safeguards), once its cumulative training compute exceeds 10²⁵ floating-point operations (FLOPs), under Article 51(2).

The dates matter for a chapter written now. The Act entered into force on 1 August 2024. Its bans on unacceptable-risk practices became applicable six months later, on 2 February 2025. GPAI obligations became applicable twelve months in, on 2 August 2025. The high-risk-system obligations described above — the ones that would apply to our credit-scoring model — become applicable twenty-four months after entry into force: 2 August 2026. Reading this chapter this month means reading it in the exact window where the EU's central compliance machinery for systems like this one has just switched on.

The US's sectoral patchwork

The United States has no federal counterpart to the AI Act — no horizontal statute that classifies AI systems by risk before they can be sold or deployed. Instead, existing regulators apply their existing law to AI as a new instance of an old problem. The Federal Trade Commission treats an AI system that behaves deceptively or unfairly toward consumers as a violation of Section 5 of the FTC Act, the same general-purpose consumer-protection clause used against any unfair business practice, AI or not. For our credit-scoring example specifically, the relevant law is the Equal Credit Opportunity Act and its implementing rule, Regulation B, which predates modern machine learning entirely: a creditor who denies an application must give the applicant specific, actionable reasons for the denial. This single sectoral rule creates a real engineering constraint that a pure black-box deep model cannot satisfy on its own — a lender using such a model must pair it with a post-hoc explainability layer (reason-code extraction methods such as SHAP are the common industry answer) purely to stay compliant with a 1970s-era statute, independent of any AI-specific law. The Equal Employment Opportunity Commission applies the disparate-impact doctrine from Title VII of the Civil Rights Act to hiring algorithms; the Food and Drug Administration regulates AI-based medical devices as "Software as a Medical Device" under its existing device-approval pathway.

The federal executive branch's own AI policy has also proven unusually volatile compared with the EU's statute, because it is set by presidential order rather than legislation: an October 2023 executive order required labs training foundation models above a stated compute threshold (10²⁶ FLOPs — a full order of magnitude above the EU's systemic-risk line) to report those runs to the government; that order was rescinded in January 2025 by a new executive order explicitly prioritising deregulation and US competitiveness over reporting requirements. Where the EU's obligations are locked into a statute that survives a change of government, the US federal posture reset with a change of administration — and into that federal gap, individual states have started legislating their own horizontal duties, Colorado's AI Act being the most-cited example, requiring developers and deployers of high-risk AI systems to use reasonable care against algorithmic discrimination. The result is not an absence of US AI regulation so much as regulation assembled from spare parts: old statutes, sector regulators, an executive order that can vanish with an election, and a growing patchwork of state law filling the horizontal gap Washington has left open.

Where India actually sits: a horizontal privacy law wearing a sectoral regulator's clothes

India's architecture is neither the EU's pyramid nor the US's patchwork, and describing it as "a smaller, later version" of either misses the actual structure. On the data side, India has a genuinely horizontal law — the Digital Personal Data Protection (DPDP) Act, 2023, which, like the GDPR, applies the same consent-and-processing rules to personal data regardless of industry. But the DPDP Act regulates data, not AI systems as such; it never asks whether a deployed model is "high-risk" the way the EU Act does, because that is simply not the question it was written to answer.

The system-level question — is this specific AI use case dangerous enough to need its own rules — is instead being answered piecemeal, by sector regulators, in a pattern closer to the US model than the EU one. The Reserve Bank of India set up a committee in late 2024, chaired by IIT Bombay's Pushpak Bhattacharyya, to study AI adoption risk specifically in lending, fraud detection, and customer-facing financial services; its report, released under the banner FREE-AI (Framework for Responsible and Ethical Enablement of AI), recommended sector-specific guardrails including a regulatory sandbox for testing financial AI systems before wide deployment and incident-reporting obligations for AI-related failures — RBI acting as India's version of the CFPB for AI in lending, not as a horizontal AI regulator. The securities regulator SEBI has separately required registered market intermediaries to periodically disclose the AI and machine-learning systems and algorithms they use, a disclosure-style obligation it has maintained since 2019, well before "AI policy" was a phrase MeitY used regularly. Above these sector-specific mechanisms sits MeitY's own layer of AI-specific advisories — non-binding guidance that platforms nonetheless tend to follow because non-compliance invites closer scrutiny — the interim tool India has used precisely because it does not yet have a binding AI-systems statute to reach for.

That last gap is the one instrument on the horizon worth naming specifically: the draft Digital India Act, floated by MeitY as the eventual replacement for the outdated IT Act of 2000, has circulated in public consultation with a chapter addressing high-risk AI systems directly — the closest thing India has proposed to an AI Act of its own. Until it is enacted, India's actual position is a four-part hybrid: a binding horizontal law for the training data (DPDP), binding but sector-specific rules for particular AI use cases as individual regulators write them (RBI, SEBI), non-binding advisories filling the rest (MeitY), and no binding, horizontal, risk-tiered AI-systems statute at all.

DPDP mechanics that specifically bite AI systems

The DPDP Act, 2023 uses two terms worth a quick reminder: a Data Fiduciary is the organisation deciding why and how personal data is processed (the fintech, in our example); a Data Principal is the individual the data is about (the loan applicant). Four provisions of the Act do almost all of the work when the "processing" in question is training or running an AI model, and each one lands differently on a training pipeline than a student's first intuition would suggest.

• Consent is purpose-bound, not blanket (Sections 4 and 6). Valid consent must be free, specific, informed, and tied to a stated purpose. If a customer's UPI transaction history was collected under a notice that said "to assess this loan application," that consent does not automatically cover reusing the same data six months later to train a general-purpose spending-behaviour model for a different product. Reusing data collected for one purpose to train an unrelated model is exactly the kind of scope-creep the "specific" requirement in Section 6 exists to block, unless a separate ground — fresh consent, or one of the "legitimate uses" carved out in Section 7 — applies.
• Publicly available data sits outside the Act entirely (Section 3(c)(i) and (ii)). The DPDP Act does not apply to personal data that a Data Principal has made publicly available themselves, or that someone under a legal obligation to publish it has made public. This single carve-out is enormously consequential for large-model pretraining specifically: scraping public social-media posts or public government filings to build a general-purpose language model sits outside DPDP's consent machinery from the start, in a way that would still need a lawful basis under the EU's GDPR (which has generated real litigation over exactly this question — training on publicly scraped personal data — in Europe).
• Research and statistics get a narrow, self-destructing exemption (Section 17). Processing personal data for research, archiving, or statistical purposes is exempted from the Act's full consent machinery — but only for as long as "the personal data is not used to take any decision specific to a Data Principal." The exemption is written to snap shut at the exact moment a model trained under it is used to make a call about a real person: training a statistical credit-risk model under this exemption may be permitted, but the moment that model actually scores a specific applicant's loan, the processing has left "statistical purpose" and re-enters the Act's full consent regime.
• Cross-border transfer is a blacklist, not a whitelist (Section 16). This is the provision most students get backwards on first read, because the GDPR trained the intuition the wrong way. Under GDPR, transferring personal data outside the EU is restricted by default; it becomes lawful only if the destination country is on an approved "adequacy" list or the transfer uses specific contractual safeguards. Section 16 of the DPDP Act inverts this: the Central Government may, by notification, restrict transfer to specific named countries, but until and unless a country is named, transfer to it is permitted by default. For our fintech shipping training data to a US GPU cluster, this means the default legal position is closer to "allowed unless blocked" rather than "blocked unless approved" — a structural inversion, not merely a laxer version, of the EU's model, and one where the government retains a standing, unilateral power to flip that default for any country at any time.

Worked example: does a model cross the EU's systemic-risk line?

Article 51(2) of the EU AI Act draws a bright line at 10²⁵ FLOPs of cumulative training compute: cross it, and a general-purpose model is presumed to carry systemic risk, triggering the Act's toughest GPAI obligations regardless of what the model is used for downstream. Checking whether a model crosses that line uses the same compute-accounting identity used to estimate training cost: for a dense transformer, total training compute in floating-point operations is approximated by C ≈ 6ND, where N is the parameter count and D is the number of training tokens. The constant 6 comes from a forward pass costing roughly 2N FLOPs per token and a backward pass costing roughly twice that, 4N FLOPs per token; together, 2N + 4N = 6N FLOPs per token processed.

def training_compute_flops(N, D):
    # forward pass ~2N FLOPs/token, backward ~4N FLOPs/token -> 6N/token
    return 6 * N * D

# EU AI Act, Article 51(2): a general-purpose AI model is presumed to
# carry "systemic risk" once cumulative training compute exceeds this.
EU_SYSTEMIC_RISK_FLOPS = 1e25

# Case 1: a 70-billion-parameter model trained on 2 trillion tokens
# (the published training scale of Meta's Llama 2 70B, Touvron et al. 2023)
N1 = 70_000_000_000
D1 = 2_000_000_000_000
C1 = training_compute_flops(N1, D1)
print(f"C1 = {C1:.2e} FLOPs")
print(f"C1 is {C1 / EU_SYSTEMIC_RISK_FLOPS:.1%} of the EU threshold")

# Case 2: what parameter count N crosses the threshold, if a lab trains
# compute-optimally, i.e. D = 20N (the Chinchilla ratio, Hoffmann et al. 2022)?
import math
# C = 6*N*(20*N) = 120*N^2  =>  N = sqrt(C / 120)
N_threshold = math.sqrt(EU_SYSTEMIC_RISK_FLOPS / 120)
print(f"N_threshold = {N_threshold:.3e} parameters (~{N_threshold/1e9:.0f} billion)")

Tracing this by hand for Case 1: C1 = 6 × (7×10¹⁰) × (2×10¹²) = 6 × 1.4×10²³ = 8.4×10²³ FLOPs. Dividing by the threshold, 8.4×10²³ ÷ 10²⁵ = 0.084 — a 70-billion-parameter model trained at this scale sits at roughly 8% of the EU's systemic-risk line, about twelve times below it. For Case 2, setting D = 20N (Chinchilla-optimal) gives C = 6N(20N) = 120N²; solving 120N² = 10²⁵ gives N² ≈ 8.33×10²², so N ≈ 2.887×10¹¹ — a compute-optimally trained model needs roughly 289 billion parameters before it crosses the EU's systemic-risk line at all. That is close to four times larger than the Case 1 model, which is why only a handful of frontier labs worldwide have trained anything that actually triggers Article 51's toughest obligations. As of the most recent public reporting, no IndiaAI Mission–backed model has been trained anywhere near that scale — a compute gap wide enough to suggest, as inference rather than a disclosed operating statistic, that the Safe & Trusted AI pillar's AI Safety Institute spends more of its evaluation effort on imported frontier models than on domestically trained ones: the acute systemic-risk category is, for now, populated almost entirely from outside India.

Common misconception

Students who learn about the DPDP Act and the EU AI Act back to back tend to assume they are the same kind of law wearing different national labels — "DPDP is basically India's EU AI Act." They are not the same kind of law at all. The GDPR and the EU AI Act are two separate statutes doing two different jobs in Europe: the GDPR governs whether processing personal data is lawful in the first place (consent, purpose limitation, transfer rules); the AI Act governs whether a deployed AI system is safe enough to place on the market, classified by what it does, independent of whose data trained it. India currently has a working equivalent of only the first law — the DPDP Act plays the GDPR's role for data — and no enacted equivalent of the second. Treating DPDP as India's AI Act leads to a specific, checkable error: assuming that getting DPDP-compliant consent for training data is sufficient to deploy an AI system in India the way clearing a conformity assessment is sufficient in the EU. It is not, because DPDP was never written to ask whether the finished system is high-risk — that question, in India, is currently answered piecemeal by sector regulators like the RBI and by non-binding MeitY advisories, not by a single statute a company can check against once.

Active recall

Attempt each question before reading the answer beneath it.

1. In one sentence each, define "ex-ante" and "ex-post" regulation, and name one Indian mechanism that behaves like each.
2. An ed-tech startup collects data during a free trial under a consent notice that says "to personalise your tutoring experience." Six months later, the product team wants to reuse the same dataset to train a separate ad-targeting model. Is this permitted under the DPDP Act as it stands? What would need to change for it to be permitted?
3. Name the DPDP Act provision that lets a lab train a statistical model on personal data without full consent machinery, and state the exact condition that voids that exemption.
4. A startup wants to send training data to a GPU cluster hosted abroad. Under DPDP's Section 16, what has to be true for that transfer to be restricted? Under the GDPR, what would have to be true for the same transfer to be allowed?
5. Using the worked example's formulas, suppose EU regulators halve the systemic-risk threshold to 5×10²⁴ FLOPs. Recompute the compute-optimal parameter count that crosses this new threshold. Then check both the original Case 1 model (70B parameters, 2T tokens) against this new threshold, and separately against the (now-rescinded) US executive order's old 10²⁶ FLOPs reporting threshold — does either check change?
6. Based on the compute gap described above, why would it be reasonable to infer that India's AI Safety Institute spends more effort evaluating imported frontier models than domestically trained ones, in compute terms?

Answers

1. Ex-ante regulation requires clearing a compliance bar before deployment is allowed; India's closest ex-ante mechanism is MeitY's advisory regime, where platforms are expected to seek guidance or comply with labelling/testing conditions before shipping certain AI features. Ex-post regulation lets deployment happen and applies existing law after harm is shown; India's closest ex-post mechanism is a sector regulator like SEBI acting on its AI/ML disclosure requirement after reviewing what an intermediary has already deployed.

2. Not permitted as-is. The original consent notice was purpose-bound to "personalising your tutoring experience," and Section 6 requires consent to be specific to a stated purpose — training an unrelated ad-targeting model is a different purpose, not a natural extension of the original one. To make this lawful, the company needs either fresh, specific consent covering the ad-targeting use, or must show the processing falls under one of the narrow "legitimate uses" in Section 7 (none of which cover routine ad-targeting); absent either, reusing the dataset this way breaches the purpose-limitation principle the consent was built on.

3. Section 17's research/statistical-purpose exemption. It is voided — the processing falls back under the Act's full consent requirements — the moment the resulting model is used "to take any decision specific to a Data Principal": training under the exemption is fine, but scoring a real individual with the trained model is not.

4. Under DPDP Section 16, the transfer is restricted only if the Central Government has specifically notified that destination country as restricted; silence means the transfer is permitted by default. Under the GDPR, the transfer would be restricted by default unless the destination country is on the EU's approved adequacy list, or the transfer is backed by specific contractual safeguards (such as Standard Contractual Clauses) — silence means the transfer is blocked. The two regimes reach opposite default outcomes for the same fact pattern.

5. New threshold: 120N² = 5×10²⁴ → N² ≈ 4.167×10²² → N ≈ 2.041×10¹¹, about 204 billion parameters — lower than 289 billion, as expected, since a smaller compute budget is crossed by a smaller compute-optimal model. Checking the original 70B/2T-token model (C1 = 8.4×10²³ FLOPs) against the new 5×10²⁴ threshold: 8.4×10²³ ÷ 5×10²⁴ = 0.168, about 17% of the new line — still well below it, so the classification outcome does not flip even though the threshold was halved. Checking the same model against the old US reporting threshold of 10²⁶ FLOPs: 8.4×10²³ ÷ 10²⁶ = 0.0084, under 1% of that far higher bar — also unchanged. The ripple from halving the EU threshold changes which future, larger models would newly qualify (anything trained compute-optimally between 204 and 289 billion parameters now crosses it, and didn't before); it does not change today's answer for this specific 70-billion-parameter model under either regime.

6. This is an inference from the compute gap, not a disclosed operating statistic: the compute scale that triggers acute systemic-risk treatment — on the order of a couple of hundred billion parameters trained compute-optimally — sits well above the scale of any IndiaAI Mission–backed model trained so far. Until a domestically trained model approaches that scale, the models most likely to actually cross the EU's Article 51 line, or warrant the closest safety scrutiny, are the large frontier models built abroad and used or fine-tuned in India, not the ones trained under the Mission itself.

Think About It

Think about this: How would you explain india's ai policy: national strategy and implementation to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Key Takeaways — Summary and Recap

Let us recap what we covered: the core ideas behind india's ai policy: national strategy and implementation, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.