Who this is for: Data Protection Officers, AI product teams, legal counsel, and compliance officers at organizations processing personal data digitally in India or offering AI-driven goods and services to data principals in India. Also relevant to SEBI-regulated entities and RBI-supervised financial institutions deploying AI systems.
Phase II Deadline: November 13, 2026 (34 days)
DPDP Rules Phase 1 (notified August 2026) operationalizes the Consent Manager framework under Section 6. Key requirements effective November 13, 2026:
- Consent Manager registration: Entities operating as Consent Managers must register with the Data Protection Board. Registration requires demonstrating technical capability to manage consent on behalf of data principals, including consent collection, storage, withdrawal, and audit trail.
- Interoperability standards: Consent Managers must implement the Board's prescribed interoperability framework, allowing data principals to transfer consent preferences across platforms.
- Data fiduciary integration: Organizations processing personal data through AI systems must integrate with registered Consent Managers or implement equivalent consent management capabilities that meet the Rules' technical specifications.
- Board-designated DPO: Significant Data Fiduciaries must appoint a Data Protection Officer based in India with direct reporting access to the board of directors.
Three-phase enforcement timeline. India's DPDPA 2023 is entering force in stages. Phase I (November 2025): Data Protection Board of India established. Phase II (November 13, 2026): Consent Manager provisions effective. Phase III (May 13, 2027): All substantive provisions in force, including data principal rights, obligations on data fiduciaries, and penalties up to INR 250 crore (~$30M). The IT Rules Amendment of February 10, 2026 adds India's first binding AI-specific obligations -- deepfake labeling, watermarking, and intermediary liability for AI-generated content.
Contents
1. Overview 2. DPDPA + IT Rules 2026 + SEBI/RBI: The Indian AI Compliance Stack 3. Key Obligations for AI Systems 4. Obligation-to-Procedure Mapping 5. Detailed Procedure Cards 6. Quick Reference 7. Quick Start 8. References1. Overview
India does not yet have a standalone AI law. What it has is something arguably harder to navigate: three overlapping regulatory layers that together create binding obligations for any AI system processing personal data of Indian data principals. The Digital Personal Data Protection Act (DPDPA) 2023 establishes the foundational data protection regime. The IT Rules Amendment of February 10, 2026 adds India's first AI-specific requirements -- deepfake identification, content watermarking, and intermediary liability for AI-generated outputs. And sector regulators like SEBI and RBI layer additional obligations on top for financial services AI.
The challenge for compliance teams is not that any single obligation is unclear. It is that no single document tells you everything you must do. An AI system used by a SEBI-regulated entity to process personal data of Indian consumers must simultaneously satisfy the DPDPA's consent and erasure requirements, the IT Rules' watermarking mandate, and SEBI's strict liability for AI-driven decisions. Without cryptographic evidence of each obligation being met, you are assembling a compliance argument from scattered documents and hoping the Data Protection Board agrees with your interpretation.
Key characteristics of the Indian AI compliance landscape:
- Territorial scope: DPDPA applies to personal data processed digitally within India and to processing outside India if it relates to offering goods or services to data principals in India
- Data fiduciary obligations: Organizations determining the purpose and means of processing bear primary compliance responsibility, including when AI systems process data on their behalf
- Consent architecture: Lawful processing requires free, specific, informed, unconditional, and unambiguous consent with clear notice -- automated consent assumptions by AI systems do not satisfy this standard
- Data principal rights: Right to access, correction, erasure, and grievance redressal -- each enforceable against the data fiduciary even when AI systems perform the processing
- Significant Data Fiduciary: Entities designated by the government face enhanced obligations including Data Protection Impact Assessments, mandatory DPO appointment, and periodic auditing
- Penalties: Up to INR 250 crore (~$30M) per instance, with the Data Protection Board of India as the adjudicating body
- No private right of action: Enforcement flows through the Data Protection Board, not through civil courts
2. DPDPA + IT Rules 2026 + SEBI/RBI: The Indian AI Compliance Stack
Understanding India's AI compliance requirements means understanding three layers that interact but are administered by different regulators. Organizations that treat these as separate compliance workstreams inevitably discover gaps -- usually when a regulator asks a question that spans two layers.
Layer 1: DPDPA 2023 -- The Foundation
The DPDPA establishes India's horizontal data protection framework. For AI systems, its most consequential provisions are:
- Purpose limitation (Section 4): Personal data may only be processed for the purpose stated in the consent notice. AI systems that repurpose training data, derive new inferences, or use personal data for model improvement without specific consent face enforcement risk.
- Consent notice requirements (Section 5): Data principals must receive a clear description of what personal data is being processed and for what purpose -- before processing begins. AI systems that collect data through conversational interfaces must deliver this notice in-context, not buried in a privacy policy.
- Data principal rights (Sections 11-14): Access, correction, erasure, and grievance redressal. For AI systems, the erasure right is particularly challenging -- it may require demonstrating that personal data has been removed from training datasets, embeddings, or derived models.
- Children's data (Section 9): Processing personal data of children (under 18) requires verifiable parental consent. AI systems with open access must implement age verification or assume all users may be minors.
Layer 2: IT Rules Amendment (February 10, 2026) -- AI-Specific Obligations
The Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules amendment of February 2026 introduces India's first binding AI-specific requirements:
- Deepfake labeling: AI-generated or AI-manipulated content must be clearly labeled as such. Platforms hosting AI-generated content bear liability for unlabeled deepfakes.
- Content watermarking: AI-generated synthetic content must carry machine-readable watermarks or metadata identifying it as AI-generated.
- Intermediary liability: Platforms that host or distribute AI-generated content must implement reasonable measures to detect and label synthetic content. Failure to do so may result in loss of safe harbor protections under Section 79 of the IT Act.
Layer 3: Sector Regulators -- SEBI and RBI
Financial services AI faces additional obligations from India's two primary financial regulators:
- SEBI: Regulated entities (brokers, investment advisors, AMCs) are strictly responsible for all AI-driven decisions. SEBI's position is that algorithmic recommendations are the entity's recommendations -- the AI is not a separate actor. This means audit trails must trace from the AI output back to the entity's governance controls.
- RBI: The Reserve Bank of India's framework for AI in financial services requires explainability for credit decisions, bias testing for lending models, and human oversight for high-impact automated decisions. RBI-supervised entities must demonstrate that AI-driven credit scoring does not produce discriminatory outcomes.
When the Data Protection Board or a sector regulator asks "how does your AI system comply," they are not asking about one layer in isolation. A complete evidence package must show DPDPA consent + IT Rules watermarking + sector-specific obligations as a connected chain. SWT3 anchors from different procedures, linked by the same session or model identifier, demonstrate that all three layers are addressed for a single AI interaction.
3. Key Obligations for AI Systems
| Source Law | Requirement | Timeline |
|---|---|---|
| DPDPA S.5 | Deliver clear consent notice describing personal data collected and purpose before AI processing begins | Phase III -- May 13, 2027 |
| DPDPA S.6 | Obtain free, specific, informed, and unambiguous consent; no bundled or pre-ticked consent for AI processing | Phase II -- Nov 13, 2026 (Consent Managers); Phase III -- May 13, 2027 (full) |
| DPDPA S.11-12 | Honor data principal rights: access to personal data being processed by AI, correction of inaccurate data, erasure on withdrawal of consent | Phase III -- May 13, 2027 |
| DPDPA S.8(7) | Maintain accuracy of personal data used by AI systems to ensure decisions are not based on outdated or incorrect data | Phase III -- May 13, 2027 |
| DPDPA S.10 | Significant Data Fiduciaries must conduct Data Protection Impact Assessments for high-risk AI processing and appoint a Data Protection Officer | Phase III -- May 13, 2027 |
| DPDPA S.8(4) | Implement appropriate technical and organizational measures to protect personal data processed by AI systems | Phase III -- May 13, 2027 |
| IT Rules 2026 | Label AI-generated or AI-manipulated content with clear disclosure; implement machine-readable watermarks on synthetic content | Effective -- Feb 10, 2026 |
| IT Rules 2026 | Intermediaries must take reasonable measures to detect and label AI-generated deepfakes or lose safe harbor | Effective -- Feb 10, 2026 |
| SEBI | Regulated entities bear strict responsibility for AI-driven investment recommendations; full audit trail required from AI output to governance decision | Ongoing |
| RBI | Explainability for AI-driven credit decisions; bias testing for lending models; human oversight for high-impact automated decisions | Ongoing |
| DPDPA S.9 | Verifiable parental consent before processing children's personal data (under 18); no behavioral monitoring or targeted advertising directed at children via AI | Phase III -- May 13, 2027 |
4. Obligation-to-Procedure Mapping
| DPDPA / IT Rules / Sector Obligation | SWT3 Procedure | What It Witnesses | Evidence Produced |
|---|---|---|---|
| Personal data processing (S.4-5) | AI-DATA.1 | Data lineage and purpose limitation for AI training and inference | Anchor with data source, processing purpose, retention period, classification level |
| Consent management (S.6) | AI-CONSENT.1 | Consent collection, verification, and withdrawal tracking | Anchor with consent type, granularity, collection method, withdrawal status |
| Erasure / right to be forgotten (S.12) | AI-DEL.1 | Data deletion or anonymization upon consent withdrawal | Anchor with deletion scope, verification method, completion status, affected systems |
| Non-discrimination / bias (RBI, DPDPA S.8) | AI-FAIR.1 | Fairness evaluation across protected attributes | Anchor with bias metric, demographic group, threshold, evaluation result |
| Explainability (RBI credit decisions) | AI-EXPL.1 | Decision rationale generation and accessibility | Anchor with explanation method, addressee type, comprehensibility score, decision factors |
| AI content watermarking (IT Rules 2026) | AI-WATERMARK.1 | Watermark embedding in AI-generated content | Anchor with watermark type, embedding method, content hash, verification endpoint |
| Transparency / AI disclosure (IT Rules 2026) | AI-TRANS.1 | Disclosure of AI involvement in content generation or decision-making | Anchor with disclosure type, recipient category, delivery method, timestamp |
| DPIA / periodic audit (S.10) | AI-AUDIT.1 | Audit integrity and completeness verification | Anchor with audit scope, methodology, findings count, assessor identity |
| Revocation / consent withdrawal response | AI-REV.1 | Revocation of a previously minted anchor upon consent withdrawal or regulatory order | Anchor with revocation target, reason code, effective timestamp |
| Human oversight (SEBI, RBI) | AI-HITL.1 | Human-in-the-loop review for high-impact AI decisions | Anchor with review type, reviewer role, decision override status, escalation path |
5. Detailed Procedure Cards
Data Lineage and Purpose Limitation
DPDPA requires: Personal data may only be processed for the specific purpose stated in the consent notice (Section 4). Data fiduciaries must maintain records demonstrating that AI systems use personal data only for the declared purpose -- not for secondary model training, inference enrichment, or undisclosed analytics.
How SWT3 addresses it: The witnessDataLineage() call records the data source, the declared processing purpose, the retention period, and the classification level at each stage of the AI pipeline. When personal data flows from collection through embedding generation to inference, each stage produces an anchor that links back to the original purpose declaration. This creates a verifiable chain from consent notice to actual data use.
Query AI-DATA.1 anchors by session or data subject identifier. Each anchor's processing purpose field must match the purpose stated in the corresponding consent notice. Any anchor with a purpose that diverges from the consent notice indicates a purpose limitation violation. Cross-reference with AI-CONSENT.1 anchors to verify purpose alignment.
Consent Collection and Withdrawal Tracking
DPDPA requires: Consent must be free, specific, informed, unconditional, and unambiguous (Section 6). It must be obtained through a clear affirmative action -- pre-ticked boxes, bundled consent, or inferred consent do not satisfy the standard. Data principals may withdraw consent at any time, and the data fiduciary must cease processing as quickly as technically feasible. By Phase II (November 13, 2026), Consent Managers -- registered intermediaries -- become the authorized channel for managing consent on behalf of data principals.
How SWT3 addresses it: The witnessConsent() call records the consent type (explicit, granular), the collection method (affirmative action, Consent Manager), and the withdrawal status. Each consent event produces an anchor that proves when consent was obtained, what it covered, and whether it remains active. When a data principal withdraws consent through a Consent Manager, a new anchor records the withdrawal timestamp and triggers downstream processing cessation.
AI-CONSENT.1 anchors form a timeline: collection, active processing, and withdrawal. Each collection anchor must show consent type as "explicit" and method as "affirmative action" or "consent_manager." A withdrawal anchor must have a timestamp preceding any subsequent AI-DATA.1 or AI-INF.1 anchors for that data principal. If AI processing anchors appear after a withdrawal anchor, the compliance chain is broken.
Data Erasure and Right to Be Forgotten
DPDPA requires: Upon withdrawal of consent or when the specified purpose is fulfilled, the data fiduciary must erase personal data and ensure that any data processor acting on its behalf does the same (Section 12). For AI systems, this raises the difficult question of whether personal data embedded in trained models, vector stores, or derived features constitutes "personal data" that must be erased.
How SWT3 addresses it: The witnessDataDeletion() call records the deletion scope (raw data, embeddings, model derivatives), the verification method used to confirm deletion, the completion status, and the list of affected systems. This does not solve the technical challenge of machine unlearning, but it does create a verifiable record of what was deleted, how deletion was verified, and where residual data may persist -- which is what a regulator will ask for.
AI-DEL.1 anchors should appear within a reasonable time after the corresponding AI-CONSENT.1 withdrawal anchor. The deletion scope field should enumerate all systems (training pipeline, vector store, inference cache, backup). The verification method field should indicate how deletion was confirmed (hash comparison, storage audit, certificate of destruction). Incomplete deletion scope is acceptable if documented -- the Board expects transparency about technical limitations, not perfection.
Fairness and Non-Discrimination
RBI requires: AI-driven credit scoring and lending decisions must not produce discriminatory outcomes across protected attributes. DPDPA Section 8(7) requires data accuracy, which indirectly supports fairness -- decisions based on inaccurate data are more likely to produce biased outcomes. SEBI-regulated entities must demonstrate that AI-driven recommendations do not systematically disadvantage specific investor categories.
How SWT3 addresses it: The witnessFairness() call records the bias metric used (disparate impact ratio, equalized odds, demographic parity), the demographic group evaluated, the threshold applied, and the evaluation result. This creates auditable evidence that fairness testing is performed systematically, not as a one-time exercise during model development.
AI-FAIR.1 anchors should appear on a regular cadence -- not just at model deployment but during ongoing production monitoring. Factor A (bias metric) should be appropriate for the use case (disparate impact for lending, demographic parity for recommendations). A consistent stream of anchors with passing thresholds demonstrates continuous monitoring. Gaps in the anchor timeline suggest periods where fairness was not being evaluated.
Decision Explainability
RBI requires: AI-driven credit decisions must be explainable to the affected individual. When a loan is denied or terms are set algorithmically, the borrower is entitled to understand the key factors that influenced the decision. This is not a general transparency requirement -- it is a specific obligation to produce individualized explanations for consequential financial decisions.
How SWT3 addresses it: The witnessExplainability() call records the explanation method (feature importance, counterfactual, rule extraction), the addressee type (data principal, regulator, internal reviewer), the comprehensibility score, and the key decision factors. Each explanation event is anchored to the specific inference that produced the decision, creating a verifiable link between the AI output and the explanation provided.
AI-EXPL.1 anchors should be linked to corresponding AI-INF.1 anchors by session or request identifier. The addressee type field distinguishes explanations generated for data principals (consumer-facing) from those generated for regulators (technical). For RBI compliance, every denied credit application should have a corresponding AI-EXPL.1 anchor. Missing explanation anchors for adverse decisions represent the highest-priority gap.
AI Content Watermarking
IT Rules 2026 require: AI-generated or AI-manipulated synthetic content must carry machine-readable watermarks or metadata identifying it as AI-generated. Platforms that fail to watermark AI content or that strip watermarks from AI-generated content risk losing safe harbor protections under Section 79 of the IT Act. This obligation is already in force as of February 10, 2026.
How SWT3 addresses it: The witnessWatermark() call records the watermark type (steganographic, metadata, visible), the embedding method, a hash of the content at the point of watermarking, and the verification endpoint where the watermark can be validated. This creates evidence that watermarking was applied at the point of generation -- not retrofitted after publication.
AI-WATERMARK.1 anchors should appear for every AI-generated content output. The timestamp must precede any distribution or publication event. The content hash allows verification that the watermarked content matches the distributed content -- if they differ, the watermark may have been stripped or the content modified post-watermarking. For IT Rules compliance, the absence of AI-WATERMARK.1 anchors for published AI content is the primary gap indicator.
AI Involvement Transparency
IT Rules 2026 and DPDPA require: Users must be informed when they are interacting with AI or when content has been AI-generated. The IT Rules impose specific labeling requirements for deepfakes and synthetic content. The DPDPA's consent notice provisions (Section 5) require that data principals understand how their data will be processed -- including whether AI is involved in the processing.
How SWT3 addresses it: The witnessTransparency() call records the disclosure type (AI-generated content, AI-assisted decision, AI interaction), the recipient category (consumer, data principal, regulator), the delivery method (in-context label, metadata tag, notice), and the timestamp. This creates evidence that transparency obligations were met at the point of interaction, not retroactively.
AI-TRANS.1 anchors must precede the corresponding AI-INF.1 or content distribution events in the timeline. For conversational AI, the disclosure must appear at interaction start. For content generation, the disclosure must accompany the output. Cross-reference with AI-WATERMARK.1 anchors for synthetic content to verify both disclosure and watermarking were applied.
Audit Integrity and DPIA
DPDPA requires: Significant Data Fiduciaries must conduct periodic Data Protection Impact Assessments (Section 10) and submit to audits by independent data auditors. The audit must evaluate whether the data fiduciary's processing activities -- including AI systems -- comply with DPDPA provisions. Audit reports must be submitted to the Data Protection Board.
How SWT3 addresses it: The witnessAuditIntegrity() call records the audit scope, the methodology applied, the number of findings, and the assessor identity. Each audit cycle produces anchors that document what was evaluated, by whom, and what was found. This creates a tamper-evident audit trail that the Data Protection Board can independently verify.
AI-AUDIT.1 anchors should appear at the cadence required by the Data Protection Board (typically annual for Significant Data Fiduciaries). The audit scope field should cover all AI systems processing personal data. The assessor identity field should match the independent data auditor registered with the Board. Multiple AI-AUDIT.1 anchors per audit cycle (one per system or processing activity) demonstrate thoroughness.
Anchor Revocation on Consent Withdrawal
DPDPA requires: When a data principal withdraws consent, the data fiduciary must cease processing. In the SWT3 context, this means previously minted anchors that attest to lawful processing may need to be revoked to reflect the changed consent status. Similarly, regulatory orders from the Data Protection Board may require revocation of compliance attestations that are no longer valid.
How SWT3 addresses it: The revoke() call mints an AI-REV.1 anchor targeting a previously minted anchor's fingerprint. The revocation records the reason code (consent_withdrawal, regulatory_order, error_correction, or others from the 7 standard codes), the effective timestamp, and the target fingerprint. The original anchor is not deleted -- it is marked as revoked, preserving the full audit history while reflecting the current compliance state.
AI-REV.1 anchors should appear promptly after the corresponding AI-CONSENT.1 withdrawal event. The reason code field distinguishes consent-driven revocations (consent_withdrawal) from regulatory-driven revocations (regulatory_order). The target fingerprint links the revocation to the specific anchor being invalidated. An AI-DATA.1 or AI-INF.1 anchor that continues to appear after its corresponding AI-REV.1 without a new consent anchor indicates processing without valid consent.
Human Oversight for High-Impact Decisions
SEBI and RBI require: High-impact AI-driven decisions in financial services must include human oversight. SEBI's position that regulated entities bear strict responsibility for AI recommendations implies that a human must be accountable for the decision, not just the system. RBI requires human review for consequential credit decisions, especially when the AI output would result in adverse action against a borrower.
How SWT3 addresses it: The witnessHumanReview() call records the review type (approval, override, escalation), the reviewer's role, whether the AI decision was overridden, and the escalation path followed. This creates evidence that a qualified human was in the loop for high-impact decisions -- not that a human rubber-stamped an automated output.
AI-HITL.1 anchors should appear for every high-impact decision as defined by the organization's risk framework. The reviewer role field should indicate appropriate seniority for the decision type (credit officer for lending, compliance officer for regulatory decisions). Override status is critical -- a stream of AI-HITL.1 anchors with zero overrides may indicate rubber-stamping rather than genuine review. Some non-zero override rate demonstrates that the human reviewer is exercising independent judgment.
6. Quick Reference
| Examiner Question | Where to Look |
|---|---|
| How do you obtain consent for AI processing? | AI-CONSENT.1 anchors showing explicit consent collection via affirmative action or Consent Manager. Consent type must be "explicit" and method must not be "pre-ticked" or "bundled." |
| Can you demonstrate purpose limitation? | AI-DATA.1 anchors with processing purpose fields. Cross-reference with AI-CONSENT.1 to verify the declared purpose matches actual data use across the AI pipeline. |
| How do you handle erasure requests? | AI-DEL.1 anchors appearing after AI-CONSENT.1 withdrawal events. Deletion scope field enumerates affected systems. Verification method confirms how deletion was validated. |
| Is AI-generated content watermarked? | AI-WATERMARK.1 anchors for each content output. Content hash field enables verification that watermarks were not stripped post-generation. Already required since Feb 2026. |
| Do users know they are interacting with AI? | AI-TRANS.1 anchors preceding AI interactions or content distribution. Disclosure type field confirms what was disclosed. Delivery method shows how the disclosure was presented. |
| How do you ensure fairness in AI credit decisions? | AI-FAIR.1 anchors on a regular cadence, with bias metrics appropriate for the use case. Continuous presence demonstrates ongoing monitoring, not one-time testing. |
| Can borrowers get explanations for AI credit decisions? | AI-EXPL.1 anchors linked to specific AI-INF.1 decision anchors. Addressee type "data_principal" confirms consumer-facing explanations were generated. Missing anchors for adverse decisions are the primary gap. |
| Who is accountable for AI-driven financial recommendations? | AI-HITL.1 anchors showing human review with appropriate reviewer role. Override status demonstrates genuine oversight. Link to AI-INF.1 anchors proves review covered the specific decision. |
| Have you conducted a DPIA for AI processing? | AI-AUDIT.1 anchors with DPIA scope, independent assessor identity, and findings summary. Cadence should match Significant Data Fiduciary requirements. |
| What happens when consent is withdrawn? | AI-REV.1 anchors with reason code "consent_withdrawal" targeting previously minted anchors. No AI-DATA.1 or AI-INF.1 anchors should appear for that data principal after revocation without new consent. |
7. Quick Start
pip install swt3-ai
# Initialize with DPDPA-aligned profile
swt3 init --profile nist-ai-rmf --tenant YOUR_TENANT
# Run the demo to see consent, data lineage, and transparency anchors
python -m swt3_ai.demo
# Or use TypeScript
npm install @tenova/swt3-ai
npx swt3-init --profile nist-ai-rmf
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup
8. References
- Digital Personal Data Protection Act, 2023 -- Ministry of Electronics and Information Technology, Government of India
- Digital Personal Data Protection Rules, 2025 -- DPDP Rules notified November 2025
- Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules -- IT Rules Amendment, February 10, 2026
- Securities and Exchange Board of India (SEBI) -- Regulated entity AI governance requirements
- Reserve Bank of India (RBI) -- AI in financial services framework
- EU AI Act Crosswalk -- comparable comprehensive AI governance framework
- SWT3 UCT Registry -- 279 procedures across 10 namespaces
- SWT3 Bidirectional Framework Crosswalks -- machine-readable JSON, 84 frameworks
- SDK Documentation -- Python, TypeScript, and 5 additional language SDKs