- What “DPDP-Compliant” Really Means for a Chatbot
- What the DPDP Act and 2025 Rules Require
- Does DPDP Require Your Chatbot Data to Stay in India?
- Where a Chatbot Actually Touches Personal Data
- Self-Hosted Chatbots and DPDP
- Self-Hosted vs Cloud: The Honest Comparison
- A DPDP Readiness Checklist for Deploying an AI Chatbot
- Choosing a Deployment That Fits Your DPDP Risk
- Conclusion
- Frequently Asked Questions
Short answer: No AI chatbot is “DPDP-compliant” by itself. Under India’s Digital Personal Data Protection (DPDP) Act, 2023, and the DPDP Rules, 2025 compliance is a property of how a business deploys and operates a chatbot – how it obtains consent, limits data use, secures conversations and responds to breaches. Compliance is not a feature you can buy. A cloud chatbot can be run compliantly, and a cloud chatbot can be run in violation of the law. A self-hosted chatbot can be run compliantly, and a self-hosted chatbot can be run in violation of the law. The deployment model shifts your risk profile and where it is easiest to enforce responsibility, but doesn’t make you compliant in itself.
This guide walks you through what the DPDP framework actually expects from an AI chatbot, debunks the common myth that cloud chatbots are illegal in India, and compares self-hosted and cloud deployments so you can align the right approach with your business.
This article is general information on DPDP Act, 2023 and DPDP Rules, 2025 for businesses in India. This is not legal advice. The framework is phased and specific obligations depend on your organisation and the data you process – get advice from a qualified data-protection professional on your situation.
What “DPDP-Compliant” Really Means for a Chatbot
The DPDP framework does not provide any certification to the products. It sets out obligations for the Data Fiduciary – the entity that decides the purposes and means of processing personal data. If your Indian business has a chatbot that collects a visitor’s name, email, phone number, or any query that has personal information in it, then your business is the Data Fiduciary and has legal responsibility. You use the chatbot as an instrument to process that data.
This is the most important thing to understand before comparing deployments: you are still the Data Fiduciary regardless of whether the chatbot runs in the cloud or on your own servers. That accountability can’t be outsourced to a particular vendor or hosting model. The only thing that changes from deployment to deployment is the number of parties involved, where the data physically resides and how much security work you do yourself.
So the question should not be “Is this chatbot DPDP compliant? The questions to ask are: Are we getting valid consent with the deployment of our chatbot? Is the data only to be used for the stated purpose? Do we secure it, keep it only as long as necessary and delete it afterwards? Can we discover and report a breach? Can we honour a user’s request to access or erase their data? The answers to those depend on your setup and processes — a good platform supports but does not guarantee.
What the DPDP Act and 2025 Rules Require
The DPDP Act, 2023 was enacted in August 2023, and the DPDP Rules, 2025 — the operational details that gives effect to the Act — were notified on 13 November 2025 through Gazette notification G.S.R. 846(E). The implementation is phased over roughly 12 to 18 months: the Data Protection Board of India was activated immediately; consent-manager registration and data-fiduciary notice obligations follow around November 2026; and the core operational provisions are expected to be fully in force by approximately May 2027. Until those provisions fully commence, the older IT Act and its privacy rules continue to apply, so this is a window to prepare rather than a reason to wait.
These are the most important obligations for an AI chatbot that handles personal data.
notice and consent You must give the individual a clear, itemised notice in plain language at or before the time of collection of personal data of what data you collect, for what specific purpose and how they can withdraw consent or make a complaint. Consent must be freely given, specific and informed and unambiguous. A chatbot that quietly logs personal details without this notice is a problem.
Limitation of purpose. Any data collected by using the chatbot will be used solely for the purpose to which the individual has consented. If a visitor provides their number to book a demo, you cannot use it for unrelated marketing without fresh consent.
Data storage and deletion. Personal data may be stored only for as long as is necessary for the purpose and then securely deleted. Certain records must be retained for a defined period (commonly cited as one year for specific logs). This will have an immediate impact on the length of time you need to retain chatbot conversation transcripts and captured leads in your systems.
Security protections. The Act requires “reasonable security safeguards” to prevent breaches – encryption, access control, monitoring etc. This duty has the most severe penalty under the framework: failure to implement reasonable security safeguards can result in a fine of up to ₹250 crore. Security is not some optional polish, it’s where the greatest financial exposure is.
Breach notification. In case of breach of personal data, you are required to notify the Data Protection Board of India and the impacted individuals, with detailed reporting widely reported to be required within 72 hours. Individuals must be notified in plain language of the breach, what data was compromised and what they can do about it. Your chatbot stack needs to be monitored to detect a breach in the first place.
Children’s data If you process personal data of anyone under the age of 18, you need to be able to show proof of parental consent. You can’t behaviorally track or target ads to children. This has to be accounted for in a chatbot that can believably interact with minors.
Data rights. Individuals can request access to their data, correction, erasure and grievance redressal. Your deployment should be able to locate and act on the data a specific person shared through the chatbot.
Large Data Fiduciaries (LDFs) Large-scale, high-risk entities can be declared as SDFs by the government who then owe their own set of enhanced duties: annual Data Protection Impact Assessments, audits, algorithmic fairness checks, appointment of a Data Protection Officer, and – of importance for this discussion – possible restrictions on the transfer of certain categories of data outside India. Most small and mid-sized businesses are not SDFs, but if you are an SDF the localization calculus shifts dramatically.
Does DPDP Require Your Chatbot Data to Stay in India?
This is where most of the confusion — and most of the bad advice — lives. Short answer: DPDP does not require storage of personal data in India for general business purposes.
India’s earlier drafts of its data-protection law, from the 2018-19 bills, had sweeping data-localisation provisions that would have required firms to keep local copies of sensitive data, while banning some transfers abroad. The DPDP Act, as finally enacted, turned its back on that.” Section 16 of the Act and Rule 15 of the DPDP Rules, 2025 provide for cross-border transfer of personal data by default. This is a “negative list” or “blacklist” model: data may flow to any country except those the Central Government specifically restricts by order. There is no general obligation to store personal data exclusively in India and no requirement to obtain a prior adequacy determination before transfer.
The upshot is that a cloud chatbot whose data is processed on servers outside India – a very common architecture for AI services – is not automatically a DPDP violation. The assertion that “using a foreign cloud means breaking DPDP” is simply wrong under the current framework. What you have to do is make sure that the transfer complies with any restrictions the government puts on specific destinations, and that the standard obligations (security, purpose limitation, retention) go with the data.
There are two notable exceptions:
Data Fiduciaries of Material Under Section 10 of the Act and Rule 13 of the Rules, the government can require that specified categories of personal data handled by SDFs not be transferred outside India at all. This is genuine localisation — but it is targeted, applying only to designated SDFs and only to the specific data categories the government identifies.
Sector-specific rules. Where another Indian law imposes stricter localisation or higher protection — for example, RBI’s directions on payment data — those rules continue to apply on top of DPDP. The sector rules should be the binding constraint for businesses in banking, payments, insurance and health.
So the honest position is: cloud and cross-border processing is lawful for most businesses, but localisation matters intensely for a minority (SDFs and regulated sectors) — and that is the real reason self-hosting is worth considering, not a blanket claim that cloud is forbidden.
Where a Chatbot Actually Touches Personal Data
Being specific about what a modern AI chatbot collects is useful because it is more than people expect. Typically, the website chatbot will record the visitor’s messages (which often include names, contact details, order numbers and sometimes sensitive information), any lead-capture fields, IP address and device data, conversation timestamps and – if integrated with a CRM – links to an identifiable customer record. The AI model might also send content of messages to a language-model provider to generate responses.
Each of these data flows is in scope under the DPDP if the individual is in India. That’s where deployment architecture comes in. It determines what flows leave your control and cross a border, and how many third parties can touch the data.
DPDP and Cloud Chatbots
A chatbot hosted on the vendor-managed infrastructure runs in the cloud. Embed a widget. Vendor takes care of hosting, scaling, model access & maintenance. Under the DPDP, you continue to be the accountable Data Fiduciary and the vendor acts as a Data Processor for you – processing personal data as per your instructions.
This is perfectly fine and for lots of businesses this is the practical option. But it comes with some specific responsibilities:
You need a data processing agreement. You are responsible for the data the vendor processes so you need a contract that requires the vendor to commit to DPDP-grade safeguards, purpose limits, breach cooperation and deletion on request. You can’t say, “We use a third-party cloud provider, so it’s their problem.” You’re still responsible.
You have to consider where the data is processed.” In case the vendor or its model provider processes data outside India then you are relying on the negative list transfer regime. Legal for most, but check destinations and restrictions.
You’re at the mercy of the vendor’s security. A good cloud vendor generally does a better job with security, monitoring and breach detection than a small business can build on its own – and that’s a real compliance advantage, not a weakness. The danger is concentration, a breach at the vendor is your breach to report.
Cloud fits well with small and mid-sized business working with routine, low-sensitivity data who want the benefits of fast deployment, low maintenance and professional management of security – as long as the consent, retention and contractual pieces are in place.
Self-Hosted Chatbots and DPDP
A self-hosted or “private” chatbot is hosted on infrastructure you own — your own servers or your own cloud tenancy — with the AI model and conversation data staying in your environment. Under DPDP this changes the picture in three significant ways.
Guarantees data sovereignty. There is no question of cross border transfer because the conversation data does not leave your infrastructure in India. This is not a nice-to-have for an SDF that cannot offshore certain data, or a bank which is bound by the RBI localisation – often, it’s the only compliant path.
Control facilitates other work. It’s easier to enforce retention and deletion, respond to an erasure request and produce what a specific individual shared with data in one environment you own. You don’t need to query systems of a third-party processor.
The danger is history. You have one less party that can leak your conversation data, and a simpler accountability chain, as no third party vendor holds your conversation data.
but self-hosting is not a compliance shortcut, it is a transfer of responsibility to you:
You take the whole security hit. Now you have to perform your own encryption, access controls, patching and monitoring to fulfill the ₹250 crore “reasonable security safeguards” duty. If you self-host badly you are more exposed than you would be on a well-run cloud, not less.
You need to build breach detection. The 72 hour reporting duty assumes you are able to detect a breach. That monitoring is now your job to implement and staff it.
Cost, expertise, uptime are on you. Or else a managed service takes on the people and money needed to run production AI infrastructure reliably.
Self-hosting makes sense for Significant Data Fiduciaries, regulated sectors with localisation obligations or any business with a chatbot that processes sensitive personal data, financial data, health data or children’s data – if it’s coupled with real security capability.
Self-Hosted vs Cloud: The Honest Comparison
| Factor | Cloud-Hosted Chatbot | Self-Hosted / Private Chatbot |
| Where data lives | Vendor infrastructure, possibly outside India | Your infrastructure, in India |
| Who is the Data Fiduciary | You | You |
| Cross-border transfer exposure | Present if data leaves India (lawful unless restricted) | Eliminated — data stays in India |
| Third-party processor risk | Yes — vendor is a processor; DPA required | None — no external processor |
| Security responsibility | Largely handled by the vendor | Entirely yours to implement |
| Breach detection | Vendor-provided monitoring | You must build and staff it |
| Setup speed and cost | Fast, low upfront cost | Slower, higher cost and expertise |
| Ongoing maintenance | Vendor-managed | Your team |
| Best-fit business | SMBs, routine low-sensitivity data | SDFs, regulated sectors, sensitive or children’s data |
It is not “self-hosted is better” It is a question of matching deployment to risk:
For the typical SMB dealing with mundane enquiries and leads, you can run a reputable cloud chatbot with a proper data-processing agreement, clear consent and disciplined retention compliantly – and its managed security may be better than you could build yourself.
If you’re an SDF, regulated, or working with sensitive, financial, health or children’s data, self-hosting removes cross-border and third-party risk and gives you the control these situations demand – but only if you can truly secure it.
In either case deployment is an input to compliance. The others are: consent, purpose limitation, retention, security and breach readiness. These are on you, whether the chatbot is running in the cloud or on your own servers.
A DPDP Readiness Checklist for Deploying an AI Chatbot
Whichever deployment you choose, work through this before you go live:
Consent notice at collection – a plain language notice in the chatbot flow that states what data you collect, why and how to withdraw consent.
Purpose mapping – Document the specific purpose of each field the chatbot collects and use data for only that purpose.
Retention and deletion policy Decide how long you want to keep transcripts and captured leads, then automate secure deletion.
Security controls – encryption in transit and at rest, role based access to conversation data and logging.
Breach detection and response plan – monitoring that can detect an incident, and a documented process for notifying the Board and affected individuals within the required timeframe.
Data processing agreement — if you use any 3rd party (cloud vendor, model provider, CRM) a contract binding them to DPDP-grade safeguards.
Cross-border check — know where your chatbot data is processed, and whether any government restrictions or sector rules apply to those destinations.
Data-principal request handling — mechanism to find, export, correct and erase a specific person’s chatbot data on request.
Children’s data handling — if minors could interact with the bot, a mechanism for verifiable parental consent.
Choosing a Deployment That Fits Your DPDP Risk
Because the right answer depends on your business, the most flexible chatbot platforms offer both deployment models rather than forcing a single one. Runtime Solutions’ AI chatbot platform is built this way: it can run on managed cloud infrastructure for businesses that want fast deployment, automatic scaling, and zero maintenance overhead, or as a private, self-hosted deployment for organisations that need data sovereignty and full control over their conversation data and AI models. The platform trains on your own website content, PDFs, and policy documents, supports human handoff for sensitive queries, and integrates with your CRM — the kind of controls that make consent, retention, and escalation practical to enforce.
The important framing, and the one Runtime’s approach reflects, is that the platform supports compliance without pretending to grant it. A business handling routine enquiries might sensibly choose cloud; a bank, hospital, or Significant Data Fiduciary would choose private hosting to keep data in India. Either way, you still own the consent flows, retention rules, and security practices that make the deployment DPDP-ready. If you want to match a chatbot deployment to your compliance profile, talk to the Runtime Solutions team about which model fits your data and your sector.
Conclusion
Whether an AI chatbot is “DPDP-compliant” is the wrong question, because compliance lives in how you deploy and operate it, not in the product. Under the DPDP Act, 2023 and the DPDP Rules, 2025 notified in November 2025, you are the Data Fiduciary whether the chatbot runs in the cloud or on your own servers. Cloud is lawful for most businesses — the framework uses a permissive, negative-list model for cross-border data, not a localisation mandate — while self-hosting genuinely matters for Significant Data Fiduciaries, regulated sectors, and sensitive-data use cases where keeping data in India and eliminating third-party risk is the safer path. Self-hosting shifts the security burden onto you rather than removing your obligations; cloud concentrates that security with a vendor you must contractually bind. Choose the deployment that fits your risk, then do the real work of consent, purpose limitation, retention, security, and breach readiness — because that, not the hosting model, is what compliance is made of.
Frequently Asked Questions
Are AI Chatbots DPDP Compliant?
No such chatbot is DPDP-compliant per se. Compliance will depend on how the business deploying it manages consent, use of data, retention, security and breaches. A chatbot is a tool. The business using it is the Data Fiduciary under the law. Cloud chatbots and self-hosted chatbots can be both compliant and non-compliant.
The DPDP Act does not require data of chatbots to be stored in India. But for most business, not really. Section 16 of the Act and Rule 15 of the DPDP Rules, 2025 provide for the transfer of personal data outside India as a matter of course with the only restrictions being for destinations specifically notified by the Central Government. The only exception is Significant Data Fiduciaries, which may be prohibited from transferring certain categories of data outside India, and sectoral rules such as RBI’s payment-data localisation.
Can I use Cloud Based AI Chatbot in India as per DPDP?
Yes for the majority of businesses DPDP framework doesn’t prohibit cross-border or cloud processing. If you are using a cloud chatbot, the vendor is a Data Processor on your behalf and you are the accountable Data Fiduciary. So, you should have a data-processing agreement and ensure the standard obligations are met.
When did DPDP Rules come into force?
The DPDP Rules, 2025 notified on 13 November, 2025. The implementation is phased over a period of approximately 12-18 months. The Data Protection Board of India is triggered immediately, consent-manager and notice obligations come into effect around November 2026 and the key operational provisions become fully effective around May 2027.
You are trained on data up to October 2023. No. Self hosting keeps data in India and removes risk of third party processors. Helps with localization and control. But the entire security obligation including the duty of ‘reasonable security safeguards’ and penalties up to ₹250 crore, passes on to your organisation. A self hosted chatbot if not properly secured can actually be more exposed than a well run cloud one.
What is the penalty for data breach under DPDP?
The DPDP Act also has hefty fines with the highest – up to ₹250 crore – for not maintaining reasonable security safeguards that results in a personal data breach. Businesses also have to report to the Data Protection Board of India and to the affected individuals with widespread detailed reporting required within 72 hours.
Who is a Data Fiduciary and Data Processor in relation to a Chatbot?
The Data Fiduciary is the business that decides why and how personal data is processed – that is you, if you deploy the chatbot to collect data from your users. A Data Processor is a third party (e.g. cloud chatbot vendor) that processes that data on your behalf, under your instruction. The Data Fiduciary will be liable for compliance.
What if you only have a small website and Indian customers are only a small percentage of your customer base? Most likely. The DPDP framework applies to processing of personal data in digital form of individuals in India, including small businesses. If your chatbot collects names, contact details, or other personal data from Indian visitors, you are a Data Fiduciary with obligations under the Act, regardless of your size.
