India is regulating AI mainly through data protection rather than a single AI law. Here is what the Digital Personal Data Protection Act means for anyone using AI tools with customer or personal data.
India has not passed a single sweeping AI law of the kind the European Union produced. Instead the practical rules governing how AI can be used with Indian data come from a combination of the Digital Personal Data Protection Act, sectoral regulators such as the RBI and SEBI, existing IT rules and consumer protection law.
For most people and most businesses, the DPDP Act is the one that actually bites. If you run a business that puts customer information into an AI tool, or if you are simply wondering what rights you have over your own data, this is the framework that matters.
The core idea in one paragraph
The DPDP Act says that personal data belongs to the person it describes, that anyone processing it needs a lawful basis, and that the entity deciding why and how data gets processed is accountable for it. AI is not exempt. If you feed customer records into a chatbot, you are processing personal data and the same obligations apply as if you had put them in a spreadsheet.
The vocabulary you need
| Term | Plain meaning |
|---|---|
| Data Principal | The individual the data is about: you, your customer, your employee |
| Data Fiduciary | The organisation that decides why and how personal data is processed |
| Data Processor | A vendor processing data on the fiduciary's instructions |
| Personal data | Any data about an identifiable individual |
| Consent | Free, specific, informed, unconditional and unambiguous agreement to a stated purpose |
| Significant Data Fiduciary | A larger or higher-risk fiduciary with additional obligations |
The distinction between fiduciary and processor is where AI questions usually land. If you use a hosted AI service to process customer data, you are generally the fiduciary and the AI vendor is generally a processor. Accountability sits with you, not with them.
What businesses actually have to do
The obligations that most commonly apply:
- Have a lawful basis. Usually consent, or a defined legitimate use. Consent must be for a specific stated purpose, and a vague blanket clause in your terms of service will not carry the weight.
- Give clear notice. Tell people what you collect, why, and how they can withdraw consent or complain. Notice must be available in English and the languages listed in the Eighth Schedule of the Constitution.
- Collect only what you need. Data minimisation is an obligation, not a best practice.
- Delete when the purpose ends. Retaining data indefinitely because it might be useful later is not permitted.
- Keep it secure. Reasonable security safeguards are required, and a breach must be notified.
- Honour rights requests. Individuals can ask for access, correction, erasure and grievance redressal.
- Contract properly with processors. If a vendor processes personal data for you, that relationship needs a contract.
The penalties for failures are significant, running into large sums for security lapses and breach notification failures. The exact figures and the phasing of enforcement depend on the rules notified under the Act, so verify the current position rather than relying on a summary.
Where AI creates specific problems
Purpose limitation versus model training. If you collected data to provide a service, using it to train a model is generally a different purpose requiring its own basis. Many organisations discover this only after the fact.
Erasure versus trained models. If someone exercises their right to erasure, deleting their row from a database is straightforward. Removing their influence from a model already trained on that data is not. The practical mitigation is to avoid training on identifiable personal data in the first place.
Cross-border transfer. Sending data to an overseas AI service is a transfer. The framework permits transfers except to countries specifically restricted by the government, but sectoral regulators may impose stricter localisation requirements. Financial data is the obvious example, where RBI rules on payment data storage apply independently of the DPDP Act.
Vendor terms. Many AI services distinguish between consumer tiers, where inputs may be used to improve the service, and business or API tiers, where they contractually are not. If you are putting customer data into a consumer tier, read that distinction carefully. It may be the difference between compliant and not.
Children's data. Processing data of individuals under 18 requires verifiable parental consent, and behavioural tracking and targeted advertising directed at children are restricted. Any consumer AI product with young users needs to take this seriously.
A practical compliance checklist for a small business
- Map what you hold. List every category of personal data, where it lives, and why you have it. Most organisations are surprised by the answer.
- Identify every AI tool in use. Include the ones staff adopted without telling anyone, which are usually the riskiest.
- Classify each use. Does it touch personal data? Is it a consumer tier or a business tier? Where is the data processed?
- Fix the obvious gaps first. Move sensitive processing off consumer tiers. Turn off training on your inputs where the vendor offers that setting.
- Write a short internal policy. What staff may and may not paste into an AI tool, in one page that people will actually read.
- Update your privacy notice. If AI processing is happening, say so in plain language.
- Set retention periods. Decide how long each category is kept and delete on schedule.
- Keep records. Being able to demonstrate what you did and why is a large part of accountability.
What individuals should know
Your rights under the framework include being told what is collected and why, asking for correction of inaccurate data, asking for erasure when the purpose has ended, nominating someone to exercise rights on your behalf, and raising a grievance with the organisation before escalating.
Practical habits that matter more than the law:
- Do not paste identity documents, bank statements, salary slips or medical records into consumer AI tools.
- Check whether a service offers a setting to exclude your conversations from training, and turn it on.
- Assume anything typed into a free consumer service may be retained and reviewed.
- For financial calculations, use tools that run locally in your browser rather than services that transmit your figures. The calculators on this site are built that way for exactly this reason.
Why India chose this route
Rather than a horizontal AI act defining risk tiers, India's approach so far has been to rely on data protection as the backbone, sectoral regulators for domain-specific risk, and advisory guidance for emerging concerns. Advisories on deepfake labelling and content authenticity have addressed specific harms without attempting a comprehensive AI statute.
The arguments in favour are flexibility and avoiding premature rules on a fast-moving technology. The arguments against are uncertainty for businesses and gaps around harms that are not principally about personal data, such as algorithmic discrimination in hiring or lending.
This is an evolving area. Rules under the Act have been notified in phases and sectoral guidance continues to develop, so treat any summary, including this one, as a starting point rather than a compliance opinion.
The gaps this framework does not close
Being honest about the limits matters as much as listing the obligations.
Data protection law governs personal data. It does not directly address several AI harms that have nothing to do with whether data identifies someone: an automated lending model that systematically disadvantages a group, a hiring filter trained on biased historical decisions, a pricing system that charges different customers differently for opaque reasons, or synthetic media used to defraud.
Some of these are partially covered elsewhere. Sectoral regulators impose fairness and explainability expectations on regulated lenders. Consumer protection law addresses misleading practices. IT rules address certain categories of harmful content. But the coverage is patchwork rather than systematic, and accountability for an automated decision is harder to establish than accountability for a human one.
For businesses this cuts both ways. There is less prescriptive compliance burden than under a comprehensive AI act, but also less certainty about what will be considered acceptable in hindsight. The defensible position is to document why an automated system was chosen, what it was tested for, and how a person can contest its output, regardless of whether a specific rule currently requires it.
Disclaimer
This article is for general educational purposes and is not legal advice. The DPDP Act and the rules under it are subject to phased notification and ongoing change, and sectoral regulators impose additional requirements. Consult a qualified legal professional for advice on your specific obligations before making compliance decisions.