AI and DPDP Act Compliance: India's Requirements

India's digital personal data protection legislation reaches AI systems through notice, consent, and fiduciary duties. The mechanic that shapes architecture most is withdrawal: a consent you cannot act on is a consent you cannot rely on. This guide covers the position, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

What does the legislation require?

Fiduciary duties built around notice, consent, and accountability.

Obligation	What it means for AI systems
Notice	Plain language, purposes stated, language options
Consent	Free, specific, informed, and withdrawable
Purpose limitation	Repurposing for training is a live question
Security safeguards	Across every store, including logs and indexes
Breach reporting	Defined notification obligations
Significant fiduciary duties	Assessments, audits, designated officer

What do notice and consent require?

Clear notice of the personal data collected and the purposes, in plain language and available in specified languages, with consent that is free, specific, informed, unconditional and unambiguous.

The language requirement is worth noting for products serving India's linguistic diversity: notice that exists only in English may not meet it for all users, and that is a product decision rather than a legal one.

Why does withdrawal shape architecture?

Because processing based on withdrawn consent must cease, which requires knowing which records rest on which consent.

A system that stores data without linking it to the consent it was collected under cannot act on a withdrawal except by deleting everything or nothing. Build that linkage at collection, because reconstructing it later means reprocessing the entire dataset with incomplete information.

What does significant data fiduciary status bring?

Additional obligations which can include appointing a data protection officer, engaging independent data auditors, and conducting periodic impact assessments and audits.

Whether you fall into that category depends on factors including volume and sensitivity of data processed. Establishing the position early matters, because the obligations differ materially and the audit requirement in particular takes planning. See what is a data protection impact assessment.

What evidence do you need?

Notice and consent records linked to individuals and purposes, evidence that withdrawal is actioned across all stores, security measures, breach records, and impact assessment and audit evidence where significant fiduciary duties apply.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes consent linkage, deletion enforcement, and store mapping into the build. The frequently missed stores are prompt logs, response caches, vector indexes, and evaluation datasets, all of which can hold personal data and none of which most retention jobs reach by default.

At Indian consumer scale, a gap in any of those is replicated across very large numbers of records before anyone notices.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Storing data without linking it to the consent it rests on. Notice available only in English for a multilingual user base. Retention jobs that miss vector stores and caches. And assuming significant fiduciary status does not apply without checking.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How does sector supervision interact?

It adds to the baseline, particularly in financial services where supervisors publish their own expectations and some categories of data carry localisation requirements.

For a regulated firm those are usually the more immediate constraint and they shape architecture before any AI-specific consideration does. See India AI and data protection explained.

What should you do first?

Check whether your systems can identify which stored records rest on which consent. If they cannot, withdrawal is unactionable and that is the first thing to fix.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: consent linked to records so withdrawal can be actioned, every store including caches and vector indexes covered by retention jobs, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read India AI and data protection explained.