What you need to know
- It is a draft. Published 1 July 2026, open for public comment until 31 August 2026. Nothing in it is enforceable today, and provisions may change materially before Parliament sees a bill.
- Four risk tiers, mirroring the EU model: minimal risk, limited risk, high risk and critical AI. Obligations scale with the tier.
- High-risk systems — the draft names healthcare, critical infrastructure and credit decisions among the examples — would need a conformity assessment before deployment and registration with MeitY.
- Strict liability for critical AI. India's first statutory AI liability framework drops the negligence standard entirely for the top tier — stronger than the EU AI Act on liability.
- MeitY is the enforcement agency, centralising powers that are currently scattered across the IT Act 2000, the IT Rules and sector regulators.
The four risk tiers, decoded
The classification will look familiar to anyone who has worked through European compliance. The draft sorts AI systems into minimal risk, limited risk, high risk and critical AI, with obligations rising at each step. For most teams, the practical question is not "which tier is intellectually correct?" but "which tier will a regulator put my product in?" — and the draft's illustrative domains give a reasonable steer.
Minimal risk is where the bulk of products land: spam filters, recommendation logic in low-stakes contexts, productivity copilots, internal tooling. The draft leaves this tier essentially unregulated beyond baseline duties elsewhere in the Act.
Limited risk broadly maps to transparency territory — systems that interact with people or generate synthetic content, where the main duty is disclosure. This dovetails with India's 2026 IT Rules amendment on AI-generated content labelling and deepfake takedowns, which we unpacked in our builder's checklist on the deepfake and DPDP rules. If you already label synthetic media for the IT Rules, you are most of the way to limited-risk hygiene.
High risk is where the compliance bill arrives. Systems in domains such as healthcare, critical infrastructure and credit decisions would need a conformity assessment before deployment, plus registration with MeitY. If you run a diagnostic triage model in a Pune hospital chain, an underwriting model at an NBFC, or grid-optimisation software for a discom, assume this tier is aimed at you. The same goes for a London fintech selling credit-scoring APIs to Indian lenders: the obligations attach to the system being deployed in India, not to where the company is headquartered.
Critical AI is the tier the EU does not have in this form — a category above high risk that carries the strict-liability regime discussed below. The draft does not read as targeting ordinary SaaS; it is aimed at systems whose failure causes irreversible harm at scale. But the boundary between "high risk" and "critical" is exactly the kind of line that consultation feedback should sharpen, because today it is the difference between a compliance workload and an uninsurable one.
Do not build your 2027 roadmap around the draft's current tier boundaries. This is a consultation text — the examples, thresholds and even the number of tiers can move before the bill reaches Parliament. Treat the tiers as a signal of regulatory direction, not as final scope.
Strict liability: the provision that changes product decisions
The most consequential part of the chapter is India's first statutory AI liability framework. For harms caused by systems in the critical AI category, the draft proposes strict liability — the claimant does not need to prove the operator was negligent, only that the system caused the harm. That is a stronger position than the EU AI Act, which polices high-risk systems through conformity obligations and leaves compensation to general liability law.
For builders, strict liability is not an abstract legal nicety; it reprices entire product categories. Under a negligence standard, a well-documented evaluation pipeline, red-team reports and audit trails are a defence. Under strict liability, they reduce the probability of harm but not your exposure when harm occurs. Three practical consequences follow:
- Insurance becomes a gating input. If your product could plausibly be classed as critical AI, your insurability — and the premium — becomes a line item in the business case before a single sprint is planned.
- Human-in-the-loop stops being a UX choice. Keeping a human decision between model output and real-world action is one of the few architectural moves that can keep a system out of the top tier, or at least contain the causal chain a claimant must show.
- Scope discipline pays. A model that "also does" credit decisions as a side feature drags the whole product up the tiers. Splitting risky capabilities into separately deployed, separately assessed systems is likely to become standard practice, as it already is for EU high-risk work.
Early legal commentary describes further provisions beyond the core framework, but we could not verify them — or the draft's clause numbering — against a primary source at the time of writing, so we are deliberately not citing section numbers. Read the consultation text itself before relying on any specific provision.
How DIA, DPDP and the IT Rules stack together
The Digital India Act does not arrive on empty ground. Indian AI teams are already juggling two live regimes, and the draft is best understood as the third layer of a stack:
- DPDP Act — governs the personal data your models train on and process, and is now entering its enforcement phase. Our DPDP Phase 2 checklist on Consent Manager rules and AI training compliance covers the obligations that already bite.
- IT Rules (2026 amendment) — governs AI-generated content: labelling duties and deepfake takedown timelines, enforceable now against intermediaries and platforms.
- Draft Digital India Act — would govern the AI system itself: its risk classification, pre-deployment assessment, registration and liability. Not yet law.
The clean way to think about it: DPDP regulates the data, the IT Rules regulate the content, and the DIA would regulate the system. A compliance programme built around those three nouns will survive the inevitable redrafting better than one built around today's clause map. For UK and other overseas teams, the parallel is exact — GDPR, the Online Safety Act and the EU AI Act occupy the same three slots, which means an EU-shaped compliance function can be extended to India rather than rebuilt.
DIA draft vs EU AI Act: side by side
| Dimension | India — DIA draft (July 2026) | EU AI Act |
|---|---|---|
| Status | Draft; comments open until 31 August 2026 | In force; GPAI enforcement and Article 50 transparency duties from 2 August 2026 |
| Risk tiers | Four: minimal, limited, high risk, critical AI | Prohibited practices, high risk, transparency (limited) risk, minimal risk |
| High-risk gate | Conformity assessment before deployment + MeitY registration | Conformity assessment + EU database registration; regime deferred to 2027–28 by the Digital Omnibus |
| Liability | Statutory strict liability for critical AI — no negligence standard | No dedicated strict-liability tier; relies on conformity duties and national liability law |
| Regulator | MeitY, centralised | EU AI Office + national market-surveillance authorities |
| Enforceable today? | No — nothing until Parliament passes it | Partially — GPAI and transparency duties yes; high-risk regime not yet |
Two comparisons matter most. First, on timing: the EU's GPAI enforcement and fines go live on 2 August 2026 — days after this piece publishes — while India's framework is a consultation document. Teams selling into both markets should sequence EU work first. Second, on trajectory: the EU has been softening, with the Digital Omnibus pushing the high-risk regime to 2027 and 2028, while India's opening bid is in some respects harder than Brussels ever proposed. If the strict-liability provision survives consultation intact, India — not the EU — becomes the jurisdiction that defines your worst-case exposure.
If you have already built an EU AI Act evidence pack — intended-purpose statement, risk assessment, data-governance log, post-market monitoring plan — you can reuse much of it for a future DIA conformity assessment. Build one canonical evidence pack per system and map it to each jurisdiction, rather than one pack per law.
Timeline realism: nothing is enforceable yet
It is worth being blunt about sequencing, because the first wave of LinkedIn commentary has already blurred it. The draft was published on 1 July 2026. Comments close on 31 August 2026. MeitY must then digest the feedback, produce a revised bill, and get it through both houses of Parliament — a process that for legislation of this scale rarely takes less than a year, and the DPDP Act's journey from draft to enforcement took considerably longer. After passage there will be transition periods before conformity assessments and registration become mandatory.
Realistically, the earliest builders face binding DIA obligations is 2027, and the high-risk machinery may not bite before 2028. That is not a reason to ignore it — it is a reason to engage now, while the text is still soft. The UK's experience is instructive: by the time the Regulating for Growth Bill reached its final shape, the practical scope had been substantially negotiated through consultation responses from industry. India's window for that influence is open for another five weeks.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →What to do before 31 August
Concretely, for the five weeks the comment window is open:
- Read the AI chapter yourself. It is a draft, which means the version you comment on is the version you can change. Do not outsource your understanding to summaries — including this one.
- Self-classify your systems. Run every deployed and planned system through the four tiers and write down the tier you believe applies, with reasoning. This becomes both your comment-letter evidence and your internal risk register.
- File comments where the boundaries hurt you. The high-risk/critical boundary, the conformity-assessment process for small teams, and the strict-liability scope are the three areas where specific, example-laden feedback from working builders will carry the most weight. Industry bodies such as NASSCOM will file; a founder describing a real system failure mode is rarer and more useful.
- UK and overseas teams: respond too. The consultation is public. If you sell into India, your future obligations are being drafted now, and "we did not think an Indian consultation applied to us" is the same mistake EU-bound firms made in 2022.
- Do not pause shipping. Nothing in the draft is enforceable. The regimes that bind you today are DPDP, the IT Rules and — if you touch Europe — the EU AI Act's August obligations. Keep compliance effort pointed at those, with the DIA as a watching brief.
The larger story is that India has moved from "AI advisories and light-touch guidelines" to drafting hard law with arguably the most aggressive liability stance of any major market. Whether that stance survives contact with consultation is precisely what the next five weeks will decide. Builders who engage now get a say; builders who wait get a statute.