DPDP Compliance for Ecommerce: Who and Which AI Sees Data

DPDP compliance for ecommerce starts with a simple map: where customer data lives, who can see it, and why. India’s Digital Personal Data Protection Act, 2023 makes your brand the data fiduciary for every customer name, phone number, address and order history you collect, and it holds you responsible for everyone who processes that data for you. That now includes AI tools. If your team asks ChatGPT or Claude questions about orders, the AI tool is reading customer data, and the same rules apply: a lawful basis, limited access, reasonable security, a breach plan and working customer rights.

This post is for founders, CTOs and heads of data at Indian online stores and D2C brands. It covers what to map, where AI fits, and the controls that keep it manageable.

What DPDP asks of an online store

At a high level, the DPDP Act asks a data fiduciary to:

• Give notice and have a lawful basis. Usually consent, given after a clear notice of what you collect and why, with some legitimate uses allowed without it. Customers can withdraw consent, and withdrawing should be as easy as giving it.
• Use data for the purpose it was collected for. Data collected to deliver orders isn’t automatically fair game for every new use.
• Take reasonable security safeguards to prevent personal data breaches, including by processors acting for you.
• Intimate breaches to the Data Protection Board of India and to each affected customer.
• Erase data when the purpose is served or consent is withdrawn, unless a law requires you to keep it. GST invoices, for example, have their own retention rules.
• Honour data principal rights: information about processing, correction, erasure, grievance redressal and nomination.
• Take extra care with children’s data. For anyone under 18, the Act requires verifiable parental consent and bars tracking, behavioural monitoring and targeted advertising directed at children. Baby, toy and school-supply stores should look at this closely.

Larger platforms may be notified as Significant Data Fiduciaries, with extra duties such as a Data Protection Officer and periodic audits. The DPDP Rules, notified in 2025 with phased timelines, add procedural detail, so check the current Rules for what applies to you and when.

Where customer data lives in a typical D2C stack

Most brands are surprised by how many copies exist. A typical list:

Where	What it holds	Who usually reads it
Store database (PostgreSQL, MySQL)	Customers, addresses, orders, returns	Engineering, ops, analysts
Payment gateway	Payment references, sometimes partial card or UPI details	Finance
Logistics / shipping partner	Name, phone, address	Ops, courier staff
CRM, email and WhatsApp tools	Phone, email, purchase history, consent flags	Marketing, agencies
Support desk	Free-text complaints, sometimes photos and IDs	Support team
Spreadsheets and exports	Whatever someone downloaded last month	Anyone with the link
AI chat tools	Whatever someone pasted or queried	Whoever has an account

The last two rows are where most risk sits, because nobody planned them. A CSV exported “just for this one analysis” and pasted into a chat window is a copy with no access control, no log and no erasure date.

Who (and which AI) should see what

A useful rule for an online store: most questions don’t need identities. “Which SKUs sold best in Tier-2 cities last month?” needs orders, products and city. It doesn’t need names, phones or street addresses.

A starting point you can adapt:

Data	Ops	Finance	Marketing	AI analysis
Order lines, SKUs, prices, dates	Yes	Yes	Yes	Yes
City, state, pincode	Yes	Yes	Yes	Usually yes
Customer name	Yes	Limited	Limited	Usually no
Phone, email	Yes (delivery)	No	Only with marketing consent	No
Full address	Yes (delivery)	No	No	No
Payment references	Limited	Yes	No	No
Support ticket text	Support only	No	No	Rarely

The “AI analysis” column is the one many brands haven’t thought about. Once an AI tool is connected to the database, it can read whatever its login can read. Decide that column on purpose.

Connecting AI to the store database without losing control

There are three ways teams give AI access to store data:

1. Copy and paste. Exports go into a chat window. There’s no record and no limit.
2. A direct database connection. A local MCP server or script with a connection string. Faster, but it usually runs with whatever access that login has, and logging is up to you.
3. A governed gateway. The AI tool connects through a layer that enforces read-only access, table and column limits, per-person roles and an audit log.

For DPDP, the third is easiest to defend, because you can show what was allowed and what happened.

Controls that matter for ecommerce data

• Read-only, enforced by the system. An AI agent should never be able to update an order or delete a customer, whatever SQL it generates.
• Selected tables only. Orders, order items, products and returns, yes. Raw customer tables, payment details and support transcripts, no, unless there’s a real need.
• Hidden columns. Keep phone, email, address and similar fields out of AI queries even on tables you expose.
• Use a replica. Point AI access at a read replica so analysis never loads the database that takes orders.
• Named people, with roles. Not one shared key in an agency’s laptop.
• A record of every query. Who asked, the question, the SQL, row counts. Not the rows themselves.
• Revocation in minutes. When an agency contract ends or someone leaves, their access should stop that day.

The AI provider is part of the picture

The AI provider receives the rows its queries return. That’s how it answers. So use a business plan, read its terms on retention and training, and hide the columns you don’t want any AI provider to receive. No connector removes this step, and you should be wary of any that claims to.

Payment data and sector rules

The DPDP Act doesn’t require customer data to stay in India. Section 16 allows transfers abroad except to countries the government restricts by notification. Sector rules can be stricter. The best-known example for ecommerce is the RBI’s directive on storage of payment system data, which requires payment system providers to store that data in India. Most D2C brands never hold card data, because the payment gateway does. Still, check what your own database, logs and exports actually keep. More on this in our post on DPDP and data localisation.

Breach readiness for an online store

Ecommerce breaches often start small: a leaked export, an over-permissioned agency login, a debug log with addresses in it. Plan for:

• Containment: revoke keys and logins, rotate database passwords, disable integrations.
• Evidence: keep logs intact; don’t redeploy over them.
• Reporting: DPDP breach intimation to the Data Protection Board and affected customers, as the Rules require. Separately, CERT-In’s 2022 directions require reporting specified cyber incidents within 6 hours of noticing them, and keeping ICT system logs for 180 days within India.
• Customer communication: plain words about what happened and what customers should do.

An audit log of AI queries helps here. If someone asks “did the AI tool read customer phone numbers?”, you want to answer from a record, not from memory.

How Datablare helps an ecommerce team

Datablare is a governed MCP gateway for databases. It helps you meet DPDP obligations for AI access. It doesn’t take those obligations over: notices, consent and customer requests stay with you.

If your store runs on PostgreSQL (see PostgreSQL MCP server) or MySQL, MariaDB, SQL Server, Oracle, ClickHouse or Snowflake, the setup looks like this:

1. Connect a read-only login, ideally on a replica. Datablare shows the SQL to create one, including column-level grants if you want a field kept out at the database too.
2. Choose tables. Tables you don’t select don’t exist as far as agents are concerned.
3. Hide columns such as phone, email and address in Modeling. A hidden column is left out of what agents are told, and any query that reads it is refused and shows in Audit.
4. Give access by role. Managers, analysts and viewers per project, with analysts limited to some data sources if needed.
5. Connect Claude, ChatGPT, Cursor or another MCP client by signing in, or with a personal key.
6. Review Audit. Every call shows who asked, the question, the SQL, the outcome, rows and time. Query results are never stored. History is kept 7 days on Free, 30 days on Team, and while the organization exists on Business and Enterprise. Team and above can export it as CSV.

Every query also passes an SQL guard and runs in a read-only session, or on SQL Server and Snowflake in a transaction that is always rolled back. Datablare’s servers, database, logs and backups are in India. Read the details on the security page.

A one-week starting plan

• Day 1: Make the data map above for your own stack.
• Day 2: Fill in the “who sees what” table, including the AI column.
• Day 3: Create a read-only login on a replica; list identity columns to hide.
• Day 4: Connect AI access through a governed layer and test real questions.
• Day 5: Write down revocation and breach steps; set an audit review rhythm.

To try it on sample e-commerce data before connecting your own, create a free Datablare account.

This article is general information, not legal advice.