Biometric Data in India: Aadhaar Act, DPDP, and AI Use Cases

Biometric Data Under Indian Law

Biometric data in India sits at the intersection of multiple laws: the Aadhaar Act 2016 strictly governs Aadhaar biometrics (fingerprint and iris) — their use is limited to Aadhaar authentication and explicitly prohibited for other purposes. The IT Act's SPDI Rules listed biometrics as sensitive personal data. DPDP extends these protections to all biometric data, not just Aadhaar.

Types of biometric data in use in India: fingerprints (Aadhaar EKYC, attendance systems), iris scans (Aadhaar), face recognition (entry systems, DigiYatra, video KYC), voice prints (voice authentication for banking), and increasingly gait patterns for security systems.

Facial Recognition: High Risk Under DPDP

Facial recognition is in widespread use in India — DigiYatra for airports, smart city surveillance, hotel check-in, and attendance systems. Under DPDP, facial recognition processes biometric personal data. The consent requirement applies: users must explicitly consent to biometric processing.

AI governance for facial recognition systems: (1) Consent and notice before biometric capture, (2) Storage of facial vectors must be encrypted and access-controlled, (3) Facial vectors must not be sent to third-party AI APIs without explicit consent for that transfer, (4) Right to deletion: a data principal can request deletion of their facial vector.

Aadhaar Biometric Restrictions

The Aadhaar Act Section 29(1) prohibits the use of Aadhaar biometrics for any purpose other than Aadhaar authentication. This means: you cannot store Aadhaar fingerprints in your database (even if collected during EKYC), you cannot use Aadhaar iris images for non-Aadhaar purposes, and you cannot replicate Aadhaar biometrics to your own biometric matching system.

Practical implication for AI: if your video KYC flow uses Aadhaar EKYC, you may use the authentication result but you must not log or process the biometric data itself beyond what's required for the authentication step.

Data Types operational checklist

Biometric Data in India: Aadhaar Act, DPDP, and AI Use Cases 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.