A founder building an AI-powered customer support tool called me recently. He seemed fairly confident about his setup. “We’re just using our own customer chat logs to fine-tune the model. It’s our data, our customers, our systems. Surely that’s fine?”
It’s not automatically fine. This exact assumption trips up more businesses than you’d expect. If your company builds, fine-tunes, or even just uses AI tools that touch personal data, the DPDP Act applies to you. It doesn’t matter whether you built the AI yourself or you’re using a third-party tool. Let’s go through what the law actually requires here, because the gaps are more common than most founders realize.
The Act Doesn’t Mention AI, and That’s the Point
Here’s something worth understanding upfront. The DPDP Act doesn’t single out artificial intelligence by name anywhere in its text. It doesn’t need to. The Act governs the processing of digital personal data. Any AI system that ingests, learns from, or acts on personal data falls under that definition, full stop.
In other words, AI compliance isn’t some separate workstream sitting apart from your existing data protection obligations. It’s the exact same compliance framework. You’re just applying it to a system that often processes far more data, far faster, than your regular business applications ever did.
Your Existing Consent Doesn’t Automatically Cover AI Training
This is where most businesses run into trouble first. Consent for delivering a service doesn’t automatically extend to training a model on the resulting data. Say a customer agreed to your terms so you could process their support ticket. That consent doesn’t quietly cover using their chat transcript to fine-tune an AI model later.
The DPDP Act requires consent to be free, specific, informed, unconditional, and unambiguous, backed by a clear affirmative action. Broad, vague consent language like “we may use your data to improve our services” generally doesn’t hold up as specific consent for AI training. Similarly, you can’t simply reuse consent collected for one product to train a model deployed somewhere else in your business.
Practically, this means most Indian companies sitting on years of customer chat logs, call recordings, and support tickets don’t actually have a clean legal basis to train models on that historical data. They need to go back and obtain fresh, specific consent for that purpose.
Public Data Isn’t as Safe to Scrape as It Sounds
A common assumption holds that publicly available data is fair game for training. The DPDP Act’s actual carve-out here, under Section 3(c)(ii), is narrower than most people expect. It only excludes personal data that the individual made publicly available themselves, or that someone legally obligated to publish it released.
That distinction matters enormously in practice. Someone who wrote and published their own blog post made that information public themselves, so it may fall outside the Act’s scope. But someone whose phone number shows up in a leaked database, a scraped directory, or an aggregator listing didn’t make that public themselves. The exclusion doesn’t apply to them. Most large-scale scraping doesn’t carefully distinguish between these two categories. That’s why training a model on broadly scraped Indian data is legally shakier than it might first appear.
The Erasure Problem Nobody Talks About Enough
Here’s a genuinely tricky structural issue that’s specific to AI, and it deserves more attention than it usually gets. Under Section 12(3), individuals have the right to request erasure of their personal data, and businesses generally must comply.
But once personal data trains a machine learning model, it doesn’t sit there as a deletable file anymore. It gets absorbed into the mathematical structure of the model itself, essentially becoming part of how the model behaves. There’s no simple button to remove one specific person’s information from an already-trained model, because that data doesn’t exist in an identifiable, extractable form anymore.
This creates a real compliance bind. Suppose a customer whose data contributed to your training set requests erasure, and you genuinely can’t fulfill that request because of how you built the model. That inability to comply is itself a separate violation, distinct from whatever concerns exist about the original training’s legality. This is precisely why thinking through data retention and consent before training, not after, matters so much for any business building AI products.
What Regulators Actually Expect From You
The core principles running through the DPDP Act apply fully to AI systems, not just your traditional databases. That includes purpose limitation, data minimization, accuracy, storage limitation, security, and accountability. These apply equally to your training data, retrieval systems, embeddings, prompt logs, and output records, not only your original transactional data.
In practical terms, an audit-ready AI system should demonstrate, on request, the consent status of every individual whose data appears anywhere in your training corpus or vector store. If you can’t currently produce that, it’s a genuine gap worth addressing before it becomes someone else’s problem to discover during an audit or a regulatory inquiry.
What Your Business Should Actually Do
If your business builds, fine-tunes, or deploys AI systems that touch personal data, here’s where I’d start.
Separate consent for AI training from your general service consent. If you want to use customer data to train or fine-tune a model, that needs its own specific, clearly worded consent. Don’t bury it in a repurposed clause in your general terms.
Audit what’s already sitting in your training pipelines. Support transcripts, chat logs, call recordings, product reviews, and historical customer data used in any AI project all need a genuine legal basis. The assumption that “we already had it, so it’s fine” doesn’t hold up.
Be cautious with scraped or third-party datasets. Unless you can confirm the specific individuals published that data themselves, or another party was legally obligated to, treat scraped data as a real compliance risk, not a free resource.
Build retention and deletion planning into your AI projects from day one, not as an afterthought. Since erasure from a trained model is technically difficult, your best protection is having a defensible, well-documented process for how and why data entered your training pipeline in the first place.
Don’t assume internal-only AI tools are exempt. Whether your AI system is customer-facing or purely internal, the DPDP Act applies the same way if it processes personal data of individuals in India.
Why This Matters More With Every Passing Month
AI adoption inside Indian businesses is accelerating fast, often faster than internal compliance processes can keep up with. Meanwhile, the DPDP Act’s enforcement timeline continues moving toward full effect by 2027. Regulators increasingly expect to scrutinize exactly this kind of gap — businesses that built genuinely useful AI tools without properly working through the data protection implications underneath them.
The uncomfortable truth is that fixing this after the fact is far harder than building it correctly from the start. That’s precisely because of the erasure problem described above. Once personal data gets baked into a trained model, unwinding that is nowhere near as simple as deleting a row from a database.
If your business is building or deploying AI systems and you’re not confident your data practices would hold up under scrutiny, it’s worth finding out now. I help businesses across Delhi NCR work through exactly this kind of AI and data protection overlap through my DPDP Act Compliance Consulting services. For ongoing support as your AI initiatives grow, take a look at DPO services as well. Book a free consultation — Advocate Nitin Kumar Vashista, DPDP Act & GDPR Compliance Consultant, Gurgaon.