Ayush Rawat
Field note / AI governance / India

Your AI policy is probably theatre.

If nobody can explain what data enters the system, which vendor sees it, who approves the output and what evidence survives an incident, the policy is decoration. Here is the operating model Indian startups should build around the Digital Personal Data Protection Act, 2023.

By Ayush Rawat17 August 20268 minute read

The legal context is moving. Your controls still need to work today.

India’s Digital Personal Data Protection Act, 2023 creates a framework for processing digital personal data. The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025 and use a phased commencement timeline. That timeline matters. It does not give a startup permission to ignore basic controls until a future date.

The Act and Rules are the legal source of truth. This article is an operational interpretation for product and business teams. It is not legal advice. Your organisation should confirm its obligations, role, notices, contracts and timelines with qualified counsel.

The blunt version. If your team cannot draw the data flow on one page, you do not have an AI governance problem yet. You have an ownership problem.

Seven questions that expose a weak AI control system.

Do not start with the name of the model. Start with the decision the system makes and the people affected by it.

  1. What personal data enters the workflow? Include prompts, uploaded files, support tickets, voice transcripts, embeddings, logs and output that is saved for later.
  2. Why is each category being processed? A vague goal such as “improve the product” is not an operating purpose. Tie each data flow to a real business purpose and document the decision.
  3. Which vendors and subprocessors can see it? Record whether a provider retains prompts, uses them for training, transfers them, or returns and deletes them.
  4. Who is accountable for the output? A model can generate a recommendation. It cannot own a customer decision, an employee decision or a complaint response.
  5. Where can a person challenge the result? Define a review path for inaccurate, unsafe or unfair output. Put a human in the loop where the harm can compound.
  6. What evidence will remain after the incident? Keep dated approvals, tests, changes, access records, incidents and corrective actions. A clean dashboard is not evidence by itself.
  7. What happens when the model or vendor changes? A new model, prompt, data source or retention setting is a new risk decision. Recheck the workflow instead of treating the change as a routine release.

Build the minimum operating model.

1. Map the actual data path.

Create a simple register with the workflow name, purpose, owner, model, data categories, vendor, storage location, retention rule, human reviewer and shutdown path. The register should be understandable by a founder, an engineer and a lawyer without translation.

2. Make the notice match the product.

A notice should describe the data and purpose in language people can understand. Review it when the product adds a new model, changes a vendor, starts storing prompts or introduces a new decision. The notice cannot be a static page that quietly drifts away from the actual system.

3. Give humans a real veto.

Human oversight is not a person clicking approve on every output. Reviewers need context, a confidence or risk signal where appropriate, a reason to disagree and a way to escalate. Define which cases must stop automatically.

4. Test failure modes before launch.

Test the failures that matter to your workflow. That may include prompt injection, data leakage, unsafe output, biased recommendations, hallucinated facts, unauthorised access and a vendor outage. Save the test set, results, limitations and launch decision.

5. Make vendors part of your control system.

Your risk does not disappear because another company hosts the model. Ask what the provider receives, retains, uses for training, returns, deletes and discloses to subprocessors. Keep a fallback route if the provider changes its policy or becomes unavailable.

6. Create evidence while the system is small.

Evidence is cheapest before the first complaint. Keep a versioned model or workflow register, approval notes, evaluation results, change logs, access reviews, incidents and corrective actions. Rehearse a bad output, a data request, a vendor breach and a shutdown.

A practical 30 day start.

Days 1 to 7. Inventory.

List every AI feature, internal tool and vendor workflow that touches personal data. Assign one accountable owner to each.

Days 8 to 14. Map.

Draw the data path from collection to deletion. Mark the purpose, access, retention, transfer and human decision point.

Days 15 to 21. Test.

Run the failure cases that could cause real harm. Record the result and set a launch or remediation decision.

Days 22 to 30. Rehearse.

Run a short tabletop exercise and make sure the team can pause the workflow, answer a person’s request and explain what happened.

Use the companion checklist. I turned this operating model into a practical worksheet for Indian startups. Open the AI compliance readiness checklist ↗

Common questions.

Does using an overseas AI API automatically make a startup non compliant?

No. The answer depends on the data, purpose, roles, contract, safeguards, transfers and the requirements that apply to the organisation. The mistake is sending data first and asking those questions later.

Is a privacy policy enough for an AI product?

No. A policy explains intent. A control system shows who owns the workflow, what data moves, how decisions are reviewed and what evidence exists when something goes wrong.

Can AI make a compliance decision on its own?

AI can support analysis and workflow. Accountability still belongs to the organisation and the people responsible for the decision. Put a review and escalation path where the consequences justify it.

Official sources.

This article is an operational starting point for discussion. It is not legal advice, a compliance certification or a substitute for professional review. Last reviewed 17 August 2026.