DPDP AI Governance: Check This Before Connecting Claude

DPDP AI governance comes down to one question: when Claude, ChatGPT or another AI tool reads your customer data, can you show that the access was lawful, limited, secured and recorded? India’s Digital Personal Data Protection Act, 2023 does not ban AI tools. It puts duties on the business that decides how personal data is used. Before you connect an AI tool to a database with customer data, check your role, your purpose, what the tool can read, what gets logged, where the data goes and how you would handle a breach. The checklist below walks through each one.

Why connecting an AI tool is a DPDP question

Most teams start by pasting exports into a chat window. The next step is connecting the AI tool straight to the database, usually through the Model Context Protocol (MCP), so it can write and run SQL itself. That is far more useful, and it changes what you are answerable for.

Under the DPDP Act, the business that decides why and how personal data is processed is the data fiduciary. A company that processes data on its behalf is a data processor. When your sales head asks Claude “which customers in Pune haven’t ordered since June?”, your company is the fiduciary for those customer records. Every system in the path, including the connector and the AI provider, is handling personal data for you. The Act keeps the fiduciary responsible for that processing, including what its processors do.

So “can we use AI on this data?” is really several smaller questions. They are answerable, and most of the answers are about access control rather than law.

The pre-connection checklist

Run through this before anyone connects an AI tool to a database that holds personal data.

1. Roles and purpose

• You have written down which database, which tables and which business purpose the AI tool is for (for example “sales reporting on orders and products”).
• Your privacy notice and the consent or other lawful basis you rely on cover that purpose. Using data collected to ship orders for internal analysis is usually easier to justify than using it for a new purpose customers were never told about.
• You know who in the company owns this decision, so there is a name to go back to.

2. What the AI tool can read

• The connection is read-only. An AI agent writing SQL against a live database should not be able to insert, update or delete anything, and that should be enforced by the system, not by a prompt.
• Only the tables the purpose needs are exposed. An orders table may be needed; a support-ticket table with free-text complaints probably is not.
• Columns that identify people are hidden unless the purpose needs them: phone, email, address, Aadhaar or PAN, date of birth, health details.
• Access is per person and per project. A finance analyst and a marketing intern should not get the same reach.

This is the part that matters most. Data the AI tool cannot read is data you never have to explain, secure or report on.

3. The AI provider

• You use a business plan from the AI provider, not a personal account.
• You have read its terms on data retention, training on your inputs, and where it processes data.
• You accept that the provider receives the rows its queries return. Results from your database become part of the conversation with the model. Hiding columns is how you keep specific fields away from any AI provider.

4. Records and oversight

• Every AI query is logged: who asked, the question, the SQL that ran, whether it was allowed, how many rows came back.
• The log does not store the result rows themselves. A log full of customer data is a second copy to protect.
• Someone reviews the log, for example a weekly look at refused queries and unusual volumes.
• You have chosen how long the log is kept, and that choice fits your security and audit needs.

5. Breach readiness

• You can cut off an AI tool’s access in minutes: revoke the key, remove the person, or disable the connection.
• Your incident plan covers AI access. Under the DPDP Act, a personal data breach must be intimated to the Data Protection Board of India and to each affected data principal, in the form and timing the Rules set.
• You know your CERT-In duties. Its 2022 directions require reporting specified cyber incidents within 6 hours of noticing them and keeping ICT system logs for 180 days within India.

6. Data principals’ rights

• You can still answer access, correction and erasure requests. The DPDP Act gives data principals rights to information about processing, correction and erasure, grievance redressal and nomination.
• Connecting an AI tool has not created copies you cannot find. Reading through a governed connection is easier to account for than spreadsheets pasted into chat histories.

7. Where data goes

• You know where the connector runs and where the AI provider processes data.
• You have checked sector rules. Section 16 of the DPDP Act allows transfers outside India except to countries the central government restricts by notification, but sector regulators can set stricter rules for some data.

What the DPDP Act asks for, in plain terms

A short summary of the parts that touch AI access. It is a high-level reading, not a full one.

DPDP idea	What it means for an AI connection
Data fiduciary and data processor	Your company is answerable; the connector and AI provider process data for you
Notice and consent (or another lawful basis)	The purpose of AI analysis should fit what customers were told
Reasonable security safeguards	Read-only access, least privilege, encryption, logging
Breach intimation	Tell the Data Protection Board and affected people if data is exposed
Data principal rights	Access, correction, erasure, grievance redressal, nomination still work
Erasure when the purpose is served	Don’t create AI-side copies that outlive their purpose
Cross-border transfer (Section 16)	Allowed except to notified countries; sector rules may be stricter

The DPDP Rules were notified in 2025, with obligations coming into force in phases. Dates and details matter here, so check the current Rules and your counsel rather than relying on a blog post’s summary.

Common mistakes when connecting AI to customer data

Using the application’s own database login. It can usually write, and it can read everything. Create a separate read-only login for AI access, ideally pointed at a read replica.

Trusting the prompt for safety. “Only run SELECT queries” in a system prompt is a request, not a control. The system between the AI and the database has to refuse writes whatever the model generates.

Exposing the whole schema “for context”. Agents work better with fewer, well-described tables. Exposing everything is worse for answers and worse for governance.

Logging results. Debug logging that captures query output turns your log store into an unprotected copy of the customer table.

Forgetting the questions themselves. People type names and phone numbers into questions (“orders for 98xxxxxx21”). Those questions are personal data too, so the audit log needs access control and a retention period.

How Datablare fits

Datablare is a governed MCP gateway: it sits between AI tools and your database. It helps you meet DPDP obligations. It does not take them over. Here is what it covers, as built:

• Read-only, enforced twice. Every query is checked by an SQL guard that allows only a single plain read. It then runs in a read-only database session, or on SQL Server and Snowflake in a transaction that is always rolled back.
• Tables and columns you choose. A project manager selects which tables agents may read and can hide individual columns. A hidden column is left out of what the agent is told and refused if the agent names it in SQL.
• Roles per project. Managers, analysts and viewers, and analysts can be limited to some data sources. Viewers can oversee activity without querying.
• An audit trail. Each call records who asked and with which key or app, the question, the SQL, whether a rule stopped it, row count and timing. Query results are never stored. Audit history is kept 7 days on Free, 30 days on Team, and for as long as the organization exists on Business and Enterprise. Managers on Team and above can export it as CSV.
• Fast revocation. Keys can be revoked at once. Removing someone, or lowering them to Viewer, switches off their keys and connected apps.
• Hosted in India. Datablare’s servers, database, logs and backups are in India.

What Datablare does not do: write your privacy notice, collect consent, answer data principal requests about your customers, or vouch for the AI provider. The provider you connect still receives the results it asks for, under its own terms.

See how the controls work on the security page.

A practical order of work

1. Pick one purpose and one database, ideally a read replica.
2. Create a read-only login and expose only the tables that purpose needs.
3. Hide identifying columns the purpose does not need.
4. Give access to named people, with roles, not a shared key.
5. Connect the AI tool, ask the questions you expect, and read the audit log.
6. Set a review rhythm and a retention period, and add AI access to your incident plan.

You can try this with Datablare’s sample e-commerce dataset before connecting anything of your own: create a free account.

This article is general information, not legal advice.