Industry
E-Commerce DPDP Compliance: Customer Data, AI Recommendations, and Delivery
DPDP compliance guide for Indian e-commerce platforms — customer data, AI recommendation engines, delivery address handling, and payment data governance.
E-Commerce Data: High Volume, High Risk
Indian e-commerce platforms are among the highest-volume personal data processors in the country. A typical platform collects: name, mobile, email, delivery addresses (multiple), payment methods (UPI, cards, wallets, bank accounts), purchase history, browsing behaviour, search queries, review content, and return/complaint history. All of this is personal data under DPDP.
The volume creates disproportionate risk: millions of customers' data, if breached, triggers millions of data principal notifications and potentially massive Data Protection Board penalties under DPDP Section 26 (up to ₹250 crore per violation category).
AI Recommendation Engines and DPDP
Recommendation engines process purchase history, browsing data, wish lists, and demographic data to personalise product suggestions. This processing requires: a legal basis (consent or legitimate use under DPDP Section 7), a privacy notice that describes this processing, and an opt-out mechanism for customers who don't want personalised recommendations.
For LLM-powered product discovery: if your AI uses customer profile data to generate natural language product recommendations, the LLM call must not include customer PII in the prompt. Instead: profile the customer's preferences as abstract vectors (category affinity scores), pass those to the LLM, not the raw purchase history with order IDs and customer name.
Delivery Address and Third-Party Logistics
Delivery address is highly sensitive location data — it's the customer's home in most cases. Third-party logistics partners (Delhivery, Blue Dart, Shiprocket) receive delivery addresses as part of shipment processing. DPDP requires: DPA with each logistics partner, purpose limitation (address used only for delivery, not for logistics partner marketing), and deletion on contract termination.
For AI customer support that discusses delivery issues: the LLM must not receive the full delivery address. Redact to '[DELIVERY_ADDRESS]' and substitute back for the human agent or customer-facing response. The LLM can discuss delivery issues without knowing the actual address.
Industry operational checklist
E-Commerce DPDP Compliance: Customer Data, AI Recommendations, and Delivery should be reviewed as an operating control, not only as a reference article. The minimum checklist is a data inventory, a stated processing purpose, owner approval, PII detection at the AI boundary, redaction or tokenisation where possible, retention limits, vendor transfer records, and a tested user-rights workflow. This checklist gives engineering and compliance teams a shared language for deciding what must be blocked, what can be allowed in shadow mode, and what needs human review before production release.
For AI systems, the review should include prompts, retrieved context, tool call arguments, model responses, logs, traces, analytics events, exports, and support attachments. Many incidents happen because teams scan only the visible form field while sensitive data moves through background context or observability tooling. CrewCheck's recommended pattern is to place the scanner at the request boundary, record the policy version, and keep audit evidence that shows which identifiers were detected and what action was taken.
A practical rollout starts with representative samples from production-like traffic. Run a DPDP scan, sort findings by identifier sensitivity and blast radius, fix Aadhaar, PAN, financial, health, children's, and precise-location exposure first, then move to consent wording, retention, deletion, and vendor review. Use shadow mode when false positives could disrupt users, and promote to enforcement only after the exceptions have owners and expiry dates.
This page is educational and should be paired with legal review for final policy interpretation. The operational proof should still come from repeatable evidence: scanner results, audit exports, pull-request checks, policy configuration, and a documented owner for the workflow. That combination is what makes the content useful during buyer diligence, board review, regulatory questions, or an incident investigation.
Related pages
Check your own workflow
Run a free DPDP scan before this risk reaches production.
Scan prompts, logs, documents, and API payloads for Indian PII exposure, missing redaction, and audit gaps. Backlinks: learn hub, developer docs, pricing, and the DPDP scanner.