GovTech AI in India: DPDP Compliance for Public Sector Digitalisation

Government Data Under DPDP

DPDP Section 17 exempts certain government data processing from some provisions (national security, public order, prevention of offences). However, this exemption is narrow — routine citizen service delivery does not qualify for the exemption. GovTech vendors that build digital services for citizens are fully subject to DPDP.

The Digital India ecosystem — DigiLocker, DigiYatra, ONDC, Aarogya Setu, ABDM, Aadhaar — each creates personal data flows that DPDP governs. Private vendors that integrate with these platforms inherit DPDP obligations for the citizen data they process.

DigiYatra and Facial Recognition Compliance

DigiYatra uses facial recognition to match passengers to their boarding pass, eliminating physical document checks. As a biometric processing system, it's subject to DPDP's strictest protections. The current DigiYatra consent mechanism (opt-in, image deleted after 24 hours per the stated policy) must be maintained and auditable.

For GovTech vendors building on top of DigiYatra or similar biometric systems: you cannot store facial vectors beyond the stated retention period, you cannot use biometric data for purposes beyond the consented use (security/boarding), and you must be able to demonstrate deletion to auditors.

ONDC and E-Commerce Data Governance

ONDC (Open Network for Digital Commerce) separates buyer apps, seller apps, and logistics providers. Each has DPDP obligations. Buyer apps process consumer personal data (address, payment, purchase history). Seller apps process buyer data passed through the network. Logistics providers process delivery addresses.

DPDP challenge for ONDC: the network protocol shares personal data across multiple operators. DPA requirements between operator pairs must be implemented, and each operator must be able to process DSR requests for data they hold — including deletion of data they received from other network participants.

Industry operational checklist

GovTech AI in India: DPDP Compliance for Public Sector Digitalisation 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.