Every data privacy vendor in India now markets "AI-powered classification." The phrase shows up on product pages, in sales decks, in comparison guides. Almost none of them explain what happens under the hood, and the difference is not cosmetic. It decides accuracy, data sovereignty, performance at scale, and whether your classification output survives a question from the Data Protection Board.
So here is a technical look at how classification engines actually work: why the AI-versus-deterministic framing is a false choice, what a sound hybrid architecture looks like for DPDPA, and where most tools break on India-specific data before a single file gets scanned.
The Problem With "AI-Powered" as a Marketing Claim
Start with what AI classification does well. A large language model reads meaning. Feed it a free-text support ticket that mentions a customer's kidney condition, and a well-trained model flags it as health data even though nothing in it matches an identifiable format. That is real capability, and it works.
The trouble starts when a vendor positions AI as a replacement for deterministic methods rather than a complement to them. The implied claim is that regex and rule-based detection are legacy, and LLMs are the modern successor. That gets the architecture backwards.
Deterministic methods are near-certain for the data types they target. Regex with checksum verification, dictionary matching, proximity rules, exact fingerprinting. A PAN that matches the alphanumeric format and passes the issuer encoding check is a PAN. A card number that passes the Luhn algorithm is a card number. No probability is involved. LLMs are probabilistic by nature. Even well-optimised LLM classification lands at roughly 90 to 95 percent accuracy in controlled conditions. Now weigh that against the stakes: a single missed file of Aadhaar numbers can carry a ₹200 crore penalty. A 5 to 10 percent miss rate on structured identifiers is not a tolerable error band. It is a gap a regulator will eventually find.
How a Multi-Layer Classification Engine Actually Works
A production-grade engine does not pick one method. It runs several in sequence, each doing the job it is best at. This layered approach is the same principle behind why classification is broken when it relies on ML alone, and getting the order right is what separates a defensible inventory from a noisy one.
Pattern matching goes first. It scans for known formats. Aadhaar is a 12-digit number with specific checksum properties. PAN is five letters, four digits, one letter, with issuer position encoding. Indian phone numbers follow MSISDN and DND formats. These patterns are exact.
Proximity rules add structural context. The string "9847XXXXX" sitting next to a column header called "mobile_no" means something different from the same string buried in a free-text notes field. Proximity rules kill the false positives that pattern matching alone would raise.
Algorithmic verification applies mathematical validation after the pattern match. Aadhaar uses the Verhoeff checksum. A string that looks like an Aadhaar but fails the checksum is not one. This step pushes precision toward certainty for well-formatted structured data. Exact data matching fingerprints known sensitive records. If a hash of a known Aadhaar number turns up in an unrelated table, that match is certain, not a guess.
LLM classification runs last, only on what the deterministic layers could not confidently resolve: free text, scanned documents, call transcripts, CRM notes. Here the model reads meaning and flags probable sensitive content for review.
Sequence is the whole point. Run the LLM on data that deterministic methods already nail with certainty, and you waste compute and inject probability where precision was available. Run only deterministic methods on unstructured text, and you miss the layer where a large share of real sensitive data actually lives.
The India-Specific Problem Most Classification Engines Miss
An engine built for global markets and adapted for India is a different animal from one built for India. The gap shows up in the taxonomy. India's identity infrastructure carries formats that appear in no global PII taxonomy. Aadhaar, with its Verhoeff checksum. PAN, with issuer encoding. Voter ID, with its state and serial format. NACH mandate codes, UPI IDs, IFSC codes. An engine without India-specific regex patterns and checksum validators will not reliably catch these in structured data. It falls back on the LLM layer to catch them semantically, which drops you from near-certainty to that 90 to 95 percent band for identifiers you could have caught deterministically.
The DPDP Act's sensitive-data categories add another wrinkle. Caste is a sensitive personal data category under Indian law, and it appears in neither GDPR nor CCPA taxonomies. Religious belief, sexual orientation, health data, and financial data all exist in global frameworks, but the specific Indian regulatory treatment that triggers the higher security-safeguard obligation needs an India-native taxonomy, not a transplanted one.
Then the LLM problem compounds it. A model trained mostly on English text from Western sources reads Indian identity documents, Indian financial identifiers, and India-specific sensitive categories less reliably than a model trained on Indian data. An enterprise running a global DSPM tool across its BFSI dataset and treating the results as comprehensive is making an assumption the vendor's own documentation probably will not back. The gap between Indian PII and generic classification tools is worth reading in full on this point.
The Inference-Only Requirement for AI Models
When an AI model classifies data, it reads content and returns a label. That is inference mode. Some platforms go further and use customer data to improve their models over time, which embeds that data into the model weights. Vendors tend to call this adaptive learning or auto-improvement. For an Indian enterprise under DPDPA, that is not a feature. It is a compliance question.
If a classification tool ships your customer data to an external model that trains on it, that model is a data processor under the Act. The data fiduciary stays accountable for what the processor does. A vendor's reassurance that the data is "embedded irreversibly" or "segregated to prevent exposure" does not dissolve the processor relationship. It only describes the method. Ask the vendor plainly: does my data leave my environment during classification, and does it feed your model training? If the answer needs a paragraph to explain, the answer is yes.
A model in inference-only mode reads content, returns a label, and learns nothing. There is no retained data to leak even if the model itself is later compromised. For enterprises handling health data, financial records, or Aadhaar-linked identifiers, inference-only stops being an architectural preference and becomes the standard the obligation demands.
The Sampling Problem: What You Don't Scan, You Don't Know
Some tools sample. They cluster similar files with ML and classify a small representative slice from each cluster. For structured data, where schema consistency makes a sample representative, this holds up reasonably well. If a thousand rows share the same columns, classifying 10 percent gives you a defensible read. Unstructured data does not behave that way.
Picture a repository of 10 million files with sensitive data in 0.1 percent of them, scattered at random, in odd formats, created by people who left years ago. Sample 1 percent and you miss 99 percent of the sensitive content in that sparse category. That is not a rounding error. Under DPDPA, it is a live compliance gap. A data principal asks for erasure, the scan missed their file, and the request cannot be fulfilled in full.
The files that matter most to a CISO or DPO are precisely the ones sampling skips. The spreadsheet holding a full customer database that someone exported three years ago. The KYC PDF sitting in a forgotten SharePoint folder. The text file of credentials a developer left as a temporary fix. Low-frequency, high-severity files. Sampling underweights the unusual by design.
For DPDPA, the sound approach is a full scan with incremental updates. Classify everything once, then only classify what changes afterward. That is exactly how static and dynamic data mapping differ in practice: a point-in-time full scan sets the baseline, and activity-based monitoring keeps it current without endlessly rescanning the whole estate.
Keeping the Inventory Current: Why Classification Is Not a Project
A scan starts going stale the second it finishes. New files get created. Existing files change. Data moves between systems. Someone copies a database to a local drive. A vendor integration pulls customer records into a fresh SaaS environment.
Two ways exist to keep the inventory current. Periodic rescans, which cost a lot and always describe a slightly past state. Or activity-based monitoring, which watches for new and modified files, classifies only those, and builds a continuously updated picture instead of a snapshot.
Activity-based classification is what turns data lineage into something useful for compliance rather than decorative. A new file of Aadhaar numbers lands in a system, the engine detects it, classifies it, traces where it came from, and flags whether a consent record even covers that data being there. A periodic rescan cannot do that. By the time the next scheduled run fires, the file may have moved three times.
What a DPDPA-Ready Classification Platform Requires
For an enterprise evaluating tools against DPDPA, the technical requirements fall straight out of the compliance obligations. An India-native taxonomy that covers Aadhaar, PAN, Voter ID, NACH codes, UPI IDs, IFSC codes, and the DPDP Act's sensitive categories natively, not through configuration. Deterministic methods with checksum validation for structured identifiers, rather than LLM-only classification where determinism already gives certainty.
LLM classification in inference-only mode, with no customer data used for training or improvement. Full-scan capability across structured databases, cloud storage, SaaS environments, on-premises file shares, and unstructured document repositories. Activity-based incremental updates instead of periodic full rescans, so the inventory stays current without the cost of rescanning everything.
Classification output wired into consent records, data principal rights workflows, and breach response, rather than sitting as a standalone report. That last one is the requirement most tools would rather not discuss. A result that cannot answer an erasure request or scope a breach satisfies the letter of "we ran a scan" while missing the point of DPDPA readiness entirely. It fails where a platform built for full data security posture management would hold.
How Data Compass Approaches Classification for DPDPA
Privy by IDfy built Data Compass as India's first DPDPA-native data discovery and classification module, connecting across 150+ system types and 250+ native connectors. Classification runs the deterministic layer (India-specific patterns for Aadhaar, PAN, Voter ID, financial identifiers, and the DPDP Act's sensitive categories) alongside contextual AI for unstructured data, using in-house models trained for Indian regulatory context and running inference-only.
The output does not sit in a report nobody acts on. It feeds consent governance, data principal rights management, and incident response directly, so a finding that something is sensitive personal data immediately tells you which consent obligation applies, which rights requests could touch it, and how a breach involving it would be scoped.
Continuous monitoring across digital journeys picks up new sensitive data flows and triggers reclassification when data moves or changes, so the inventory Data Compass builds keeps pace instead of freezing into a point-in-time artefact. To see how this fits the rest of the obligation stack, the Privy platform overview shows how discovery connects to consent, rights, and breach workflows.
Conclusion
AI-powered classification is a real advance. The mistake is leaning on AI alone, especially for structured Indian PII where deterministic methods deliver near-certainty. Enterprises with defensible, DPDPA-ready inventories by May 2027 will be the ones running engines that pair deterministic precision on known formats with semantic LLM analysis on unstructured content, built on an India-specific taxonomy, running inference-only, and wired into the compliance workflows that make the output usable.
A scan that cannot tell you which consent record covers each piece of data, cannot scope a breach, and cannot complete an erasure request does not amount to compliance. It amounts to a record that you tried. To see how Data Compass classifies personal data across your systems and connects that output to your DPDPA compliance programme, write to shivani@idfy.com.
FAQ's
What is the difference between deterministic and LLM-based data classification?
Deterministic methods use explicit rules, regex patterns, proximity matching, and algorithmic verification to identify known data formats with near-certain accuracy. LLM classification reads semantic meaning and finds sensitive data in unstructured text where no consistent format exists. Both are needed: deterministic for structured identifiers, LLM for unstructured content.
Why does India-specific PII classification require a different taxonomy?
Indian identity documents such as Aadhaar, PAN, Voter ID, NACH codes, UPI IDs, and IFSC codes carry formats and checksum properties absent from global taxonomies built for GDPR or CCPA. An engine without these patterns either misses structured Indian identifiers or leans on probabilistic LLM classification where near-certain deterministic detection was achievable.
What is inference-only AI classification?
A model in inference-only mode reads content and returns a classification label without learning from what it processes. Customer data is not embedded in model weights or used for training. Under DPDPA, a tool that trains on customer data is a data processor, and the data fiduciary stays accountable for that processing.
Why is sampling insufficient for DPDPA compliance?
DPDPA obligations, including erasure rights and breach scoping, attach to actual records, not statistical estimates. A sparse, high-severity file such as an exported customer database in a forgotten folder is exactly what sampling misses and what a data principal request or breach would expose.
How does classification connect to DPDPA compliance workflows?
A result that sits as a standalone report cannot answer an erasure request, scope a 72-hour breach report, or confirm that consent records cover a given processing purpose. Classification has to connect to consent governance, rights management, and incident response to satisfy DPDPA, not merely document that data was found.
What Indian PII formats require checksum validation for accurate classification?
Aadhaar uses the Verhoeff checksum algorithm. PAN uses alphanumeric issuer position encoding. IFSC codes follow bank and branch identifier patterns. Each needs native pattern matching plus validation logic, not just length and character-type checks.
-1.png)
