A practical AI privacy checklist for Indian product teams

Start with the data flow, not the model

When a team adds an AI feature, privacy decisions often get made too late. A developer connects an API, a product manager writes a prompt, and only after the prototype works does someone ask which customer details leave the product. Start instead by drawing the data flow from collection to deletion. Include the user interface, application server, model provider, retrieval store, analytics tools, support logs, backups and any human review queue. A simple map exposes copies and transfers that a model diagram may hide. It also gives engineering, legal, security and product teams a shared artefact to review before real personal data enters testing.

Classify inputs by purpose and sensitivity

List the exact fields the feature needs, why each field is needed and whether a less sensitive substitute would work. A support assistant may need an order status but not a customer's full identity document. A document summariser may need the relevant contract clauses but not unrelated employee records embedded in the same folder. Classify data into practical tiers such as public, internal, confidential and highly sensitive, then define which tiers each workflow may send to an external service. Classification labels alone are not controls: enforce them through access rules, upload restrictions, redaction and clear user-facing warnings. If a field is unnecessary for the task, remove it before it reaches the model.

Treat Indian privacy law as a product requirement

India's Digital Personal Data Protection framework makes it important for teams to understand their role, purposes for processing, notices, consent where applicable, security safeguards, retention and individuals' rights. The exact obligations and commencement dates can depend on the applicable law, rules and notifications, so teams should verify the current official position with qualified counsel rather than assume a generic checklist settles compliance. Map each AI use case to a documented purpose and identify who determines that purpose, who processes the data, and which vendors or subprocessors are involved. Avoid broad language such as 'we may use data to improve services' when the real use is narrower or materially different.

Review vendors beyond the sales page

Ask the provider whether prompts and uploaded files are retained, whether they are used to train or improve models, where processing occurs, who can access logs, how deletion works, and which subprocessors are involved. Ask what happens when the provider changes a model or retires an endpoint. Obtain the relevant contractual terms and security documentation instead of relying on a salesperson's verbal assurance. For an enterprise workflow, confirm how the vendor handles incidents, support access, encryption, access logging and data export. A vendor's statement that it is 'secure' is not a complete answer; the buyer needs to understand the controls, their scope and any exceptions.

Minimise data before prompt construction

Prompt templates can accidentally include more context than a task requires. Before sending a request, select only the fields needed for that particular action. Replace names with case identifiers where identity is not required, redact unrelated text from documents, and keep secrets, credentials and access tokens out of prompts. Retrieval systems need the same discipline: a search result should be filtered by the current user's permissions before it is inserted into the model context. Do not rely on instructions such as 'ignore private information' as the only protection. The model should never receive information the user is not authorised to access in the first place.

Separate testing data from live customer data

Early prototypes often use copied production records because they are convenient. That convenience can create long-lived exposure in notebooks, logs, shared drives and vendor dashboards. Prefer synthetic or carefully de-identified examples for development, but remember that synthetic data can still reproduce sensitive patterns and de-identification can fail when rare details make a person recognisable. Keep a controlled, approved test set for evaluation and document its origin. If live data is genuinely necessary, limit access, remove unnecessary fields, set a short retention period and make the approval explicit. Do not let temporary test files become an unmanaged second database.

Set retention and deletion rules that can be tested

Privacy promises are weak if nobody can explain how to delete an input, output or conversation history. Define retention separately for source documents, prompts, model responses, audit logs, embeddings, cached results and backups. Some records may need to be kept for security or legal reasons, but those exceptions should be documented rather than treated as a reason to retain everything indefinitely. Test deletion end to end, including vector stores and downstream processors. If a provider cannot delete data immediately from a backup, record the actual schedule and explain it accurately. Retention should be a configured system behaviour, not a paragraph that only appears in a policy.

Give users meaningful notice and control

People should understand when they are interacting with AI, what information the feature uses and when a human may review the result, especially when the output affects an important decision. Notices should be concise and placed where they influence a choice, not buried in a long legal page. Provide a route to correct inaccurate source information, request assistance or reach a human where the use case requires it. Avoid presenting generated text as a verified record. If a feature uses personal data for a new purpose, pause and assess whether the original notice, legal basis and user expectations still fit.

Test for leakage, access mistakes and prompt attacks

Privacy testing should include more than checking whether the model gives a good answer. Try asking the system to reveal other users' records, reproduce hidden prompts, quote sensitive source passages or use a retrieval result outside the caller's permissions. Check whether logs expose personal data to staff who do not need it. Test file uploads containing instructions that attempt to redirect the model. Security controls should operate around the model: authentication, authorisation, input validation, output handling, rate limits and audit trails. Record each failure, its severity and the control that prevents recurrence. Red-team exercises are most useful when findings turn into test cases that run again before release.

Assign owners and review changes

A privacy checklist needs named owners. Product should own purpose and user experience; engineering should own data paths and enforcement; security should review threats and vendor controls; legal or privacy specialists should assess applicable obligations; operations should own incident handling and deletion verification. Revisit the assessment when the model provider changes, new data sources are connected, outputs become automated actions or the product expands into a higher-impact use. A quarterly review can be useful, but material changes should trigger an earlier review. Keep a short decision record that explains what was approved, what remains uncertain and which controls are required before launch.

A practical launch gate

Before launch, a reviewer should be able to answer six questions without searching through chat threads: What data enters the system? Why is each field necessary? Which vendors process it? Who can see inputs and outputs? How long are records retained? How can a user obtain help or challenge an outcome? If answers are missing, limit the rollout to a controlled test with non-sensitive data rather than assuming the gaps can be fixed later. Privacy is not achieved by avoiding AI; it is achieved by making data handling visible, proportionate and testable. The strongest team is not the one with the longest checklist, but the one that can show evidence that its safeguards work.