Sensitive Data Discovery Tools 2026: How to Test AI Data Classification

Published on August 13, 2026 by Steven Jones

Sensitive data discovery tools now sit at the intersection of privacy, security, data governance, and AI access control. The useful buying question is not how many predefined PII types a platform claims to recognise. It is whether the software can find regulated and proprietary data across messy real sources, classify it with enough context to keep false positives manageable, connect each finding to ownership and access, and give the security team a credible path to remediation.

This comparison covers seven serious options for sensitive data discovery, AI data classification and PII detection: BigID, Varonis, Cyera, Sentra, Microsoft Purview, Nightfall and Google Cloud Sensitive Data Protection. They solve different versions of the problem, from enterprise-wide DSPM to developer-facing detection APIs.

DIY AI has not assigned benchmark scores to these products because we do not currently maintain a dataset of sensitive data. Instead, the shortlist is based on current documented capabilities and a practical evaluation framework designed to expose the weaknesses that product demos usually hide: ambiguous data, scanned files, custom intellectual property, access context, sampling, confidence calibration and false-positive workload.

Sensitive data discovery tools: the 2026 shortlist

The order below reflects our editorial view of which products deserve an early proof of concept for this specific search intent. It is not a claim that DIY AI has run all seven platforms against the same enterprise data estate.

Tool	Best fit	What makes it interesting	Main POC question	Pricing shape
1. BigID	Broad enterprise discovery and governance	Connects discovery and classification with ownership, lineage, privacy, DSPM and AI data governance	How much operational overhead does its breadth add to your actual use case?	Custom enterprise pricing
2. Varonis	Access-aware sensitive data security	Strong connection between classification, permissions, exposure, activity and remediation	Does it materially reduce risky access rather than simply producing more findings?	Custom enterprise pricing
3. Cyera	Cloud and SaaS-heavy DSPM	AI-assisted contextual classification combined with data posture and exposure analysis	Does coverage remain deep across your less convenient repositories and file formats?	Custom enterprise pricing
4. Sentra	Cloud data and AI governance	Cloud-focused classification with signals designed to feed existing DLP, IAM, SIEM and security workflows	How well does it handle legacy or on-premises sources if your estate is genuinely hybrid?	Customised pricing
5. Microsoft Purview	Microsoft-heavy and hybrid estates	Data Map, classifications, lineage, sensitivity controls, exact matching and broader Microsoft security integration	What is actually inspected rather than merely connected, catalogued or sampled?	Microsoft licensing plus usage-based elements
6. Nightfall	SaaS, AI applications and DLP overlap	Combines historical discovery with contextual detection and controls around active data exposure	Is its repository coverage wide enough for your complete data estate?	Platform plans plus discovery options
7. Google Cloud Sensitive Data Protection	Developers and Google Cloud workloads	API-driven inspection, custom detectors, OCR, redaction and de-identification	Who will supply the ownership, access, lineage and remediation layers around the detector?	Usage-based

DIY AI buying rule: do not choose sensitive data discovery software by detector count. Choose the system that produces the lowest operational cost per genuine sensitive-data risk found, understood and remediated.

---

---

PII detection, data classification, DSPM and DLP are not the same purchase

A lot of poor vendor shortlists begin by grouping four different jobs into a single category.

PII detection identifies items such as names, addresses, account numbers, health information, or credentials within content. A library or API can do this without knowing anything about the employee who owns the file, its permissions or where the information came from.

Data classification adds meaning. It might decide that a document is confidential, contains customer financial information, belongs to a particular regulatory class or matches an organisation-specific category such as acquisition material.

Data security posture management, or DSPM, adds the surrounding security context. It attempts to answer where the sensitive information is stored, who can access it, whether it is overexposed, how it relates to other assets, and what should be fixed first.

Data loss prevention, or DLP, is concerned with enforcement. It can monitor or restrict what happens when sensitive information is copied, uploaded, emailed, pasted into an AI application or otherwise moved.

This creates a useful buying shortcut. If you need to detect PII inside an application you are building, an enterprise DSPM suite may be excessive. If you need to locate forgotten customer databases across multiple clouds and determine who can access them, a standalone PII API is nowhere near enough.

How to build a sensitive-data test corpus that vendors cannot optimise for

Product demos normally favour recognisable data. Credit card numbers, email addresses and national identifiers are useful tests, but they are the easy part. The harder question is whether AI data classification adds meaningful context when a simple pattern is insufficient.

For a serious proof of concept, build a private 100-item corpus before vendors see your expected results. Ten groups of ten items is enough to make the comparison manageable while forcing each classifier into several different failure modes.

Test group	What to include	What it exposes
Obvious PII	Email addresses, phone numbers, postal addresses, account identifiers and other conventional patterns	Basic detection coverage and confidence
Health narratives	Free-text medical or wellbeing notes, including examples where sensitivity comes from context rather than one identifier	Contextual PHI and semantic classification
Customer notes	CRM-style text combining names, commercial information, support history and internal comments	Mixed structured and unstructured context
Source code and secrets	Realistic credentials, environment variables, tokens, configuration files and harmless documentation examples	Whether the system can separate a plausible live secret from instructional text
Contracts	Legal documents containing parties, payment terms, confidentiality clauses and commercially sensitive obligations	Document-level meaning beyond individual PII matches
Spreadsheets	Customer tables, formulas, comments, multiple sheets and misleading column names	Parsing depth and structured-data classification
Scanned documents	Image-only PDFs, skewed scans, screenshots and lower-quality documents	OCR coverage and what the scanner silently skips
False-positive bait	Internal reference numbers, fictional identifiers, documentation examples and long numeric strings	Precision and analyst noise
Ambiguous entities	Names such as May, Rose or Jordan alongside internal project names and product names	Whether entity detection understands surrounding language
Proprietary text	Strategy documents, product plans, research or other confidential material with no standard PII pattern	The real value of contextual AI classification

Keep the expected labels separate from the system being configured. Otherwise, the proof of concept becomes a supervised exercise in teaching each vendor exactly what it needs to find.

Then run three rounds. The first is a cold-start test with normal product configuration. The second follows reasonable tuning by the vendor or your security team. The third introduces new documents that were not part of the tuning set. That final round is important because a classifier that looks excellent only after being tuned to 100 known examples may perform very differently on next month’s data.

Measure the whole chain: discovery to remediation

Classification accuracy is only one stage of the useful workflow. A better evaluation follows the finding all the way through:

Discovery -> classification -> confidence -> lineage -> owner -> access -> remediation

Stage	What to test	Failure to watch for
Discovery	Did the platform actually inspect every source and supported object you expected?	A connected repository appearing in inventory even though large files, images or rows were never inspected
Classification	Was the correct sensitivity or data type assigned?	Everything vaguely personal being classified as the same generic PII category
Confidence	Do high-confidence findings actually deserve greater trust?	Confidence scores that do not correlate with real accuracy
Lineage	Can you see where important data originated or where useful derived copies exist?	A finding with no explanation of how the data reached its current location
Owner	Can the system identify someone capable of making a remediation decision?	Thousands of findings assigned to the security team because ownership is unknown
Access	Can it distinguish sensitive-but-protected data from sensitive-and-overexposed data?	Treating every sensitive file as equally urgent
Remediation	Can the problem be fixed, routed or governed without rebuilding the workflow elsewhere?	A dashboard that generates work but cannot help close it

The difference between these stages becomes particularly important at enterprise scale. Ten thousand correctly classified files are not automatically ten thousand useful security findings. If only 50 are exposed to the wrong users, those 50 should dominate the queue.

Use precision and recall, but add analyst cost

At minimum, calculate precision = true positives / all positive findings and recall = true positives / all sensitive items. Neither metric should be considered alone. A system can produce impressive recall simply by flagging almost everything.

Add three operational measures competitors rarely put in comparison charts:

• False positives per 1,000 benign objects: this translates model noise into a workload the security team can understand.
• Median review time per finding: two products with similar precision can have very different investigation costs if one provides ownership, access and content context immediately.
• Cost per validated risk remediated: include licence costs, scanning charges, engineering work and analyst time rather than comparing subscription prices in isolation.

A recurring operational complaint around classification and DLP projects is that excessive false positives gradually teach people to ignore the system. A procurement test should therefore measure alert-review burden from day one, not treat tuning as a problem to solve after purchase.

Which sensitive data discovery tool fits which environment?

1. BigID: strongest shortlist for broad enterprise data discovery

BigID deserves an early look when the project stretches beyond PII detection into governance, privacy, security and AI data access. Its current platform positions discovery and classification as the common data layer beneath DSPM, ownership, lineage, privacy workflows and governance. It also specifically addresses sensitive data used by AI models, agents, copilots and RAG pipelines.

That breadth is also the first thing to test. A large data intelligence platform can be the correct answer for a regulated organisation with hundreds of sources and several governance teams. It is harder to justify if the real problem is simply finding secrets in a handful of SaaS repositories.

Best fit: large organisations that want sensitive-data discovery to feed several governance and security programmes rather than remain a standalone scanner.

POC focus: proprietary classifications, ownership accuracy, lineage, connector depth, incremental rescanning and the amount of platform administration required after implementation.

2. Varonis: strongest when access is as important as classification

Varonis is particularly interesting when the security question is not merely “where is sensitive data?” but “who can reach it and what should we fix?” Its platform combines discovery and classification with permissions, activity, exposure analysis and automated security actions across cloud, SaaS and data-centre environments.

This makes the comparison with a pure PII detector slightly unfair. The extra value sits in the security context surrounding each classification. If a customer database is supposed to contain personal data and only the correct service accounts can access it, discovery alone has not uncovered an emergency. If the same records have inherited broad access through an old group, the finding becomes much more actionable.

Best fit: security teams that want to reduce excessive access and data exposure, not simply maintain a sensitive-data inventory.

POC focus: permission analysis, stale access, ownership, automated remediation and whether the security context genuinely reduces the number of findings humans must investigate.

3. Cyera: a strong cloud-first DSPM candidate

Cyera is built around automated data discovery, classification and DSPM with an increasingly explicit focus on AI-era data security. Its classification approach combines conventional detection with contextual AI methods, while the wider platform connects sensitive data to posture and exposure information.

Cloud-heavy organisations should pay particular attention to how quickly a platform maps a real estate rather than a pristine demonstration account. Put duplicate datasets, abandoned storage, semi-structured records and awkward file formats into the test. A fast inventory is useful only if the difficult material is being inspected rather than bypassed.

Best fit: organisations with significant cloud and SaaS data that want modern DSPM rather than a traditional file-classification project.

POC focus: contextual proprietary classification, source coverage, scan depth, recurring scan behaviour and the difference between data that is discovered and data that is fully inspected.

4. Sentra: worth testing for cloud data feeding AI

Sentra is another cloud-oriented DSPM platform, with current positioning increasingly centred on classifying and governing data that AI systems can reach. Classification signals can feed existing DLP, IAM, ITSM, SIEM, SOAR and cloud tooling rather than requiring every downstream action to live inside the same security console.

That architecture is attractive when you already have mature enforcement systems and mainly lack reliable data context. The trade-off appears when an organisation has a substantial legacy estate. Do not accept “hybrid support” as a binary checkbox. List the exact databases, file servers, SaaS systems, warehouses, document stores and AI data pipelines you expect to govern and test each one.

Best fit: cloud-first security teams that want classification intelligence to enrich an existing security stack.

POC focus: AI-related data copies, cloud-scale scan behaviour, custom business classifications and the quality of downstream integrations.

5. Microsoft Purview: powerful for Microsoft-heavy estates, but inspect the scan model

Microsoft Purview spans data governance, information protection, classification, DLP and AI-related data security. Its Data Map can capture metadata across analytics, SaaS, and operational systems in hybrid, on-premises, and multicloud environments, while Microsoft 365 security workloads add sensitive information types, exact data matching, and trainable classifiers.

The hidden procurement issue is scan depth. Current Microsoft Purview Data Map documentation describes sampling rules for classification. Structured sources can be sampled rather than read exhaustively, while document scans have size limits. That does not make Purview unsuitable. It means “this source is supported” and “every sensitive value inside this source will be inspected” are different claims.

This is exactly why the discovery stage should be measured separately from classification accuracy. A perfect classifier cannot identify content it never receives.

Best fit: organisations already invested heavily in Microsoft 365, Azure, Fabric or Purview governance.

POC focus: sampling behaviour, unsupported edge cases, Microsoft versus non-Microsoft coverage, custom classifications and how easily findings move into protection or remediation workflows.

6. Nightfall: strongest where SaaS discovery and active DLP meet

Nightfall sits closer to the operational DLP side of the market. Its current platform combines data discovery and classification with protection around SaaS applications, AI use and data exposure. Its detection approach is particularly relevant to one of our recommended corpus tests: distinguishing genuinely sensitive credentials or identifiers from similar strings appearing in harmless documentation.

That is useful because a security team rarely suffers from a shortage of things that look like secrets. The real problem is identifying which findings deserve action.

Nightfall should still be tested against your complete source inventory. A product can be excellent at SaaS and AI leakage while being the wrong primary discovery platform for a sprawling estate of legacy databases and file infrastructure.

Best fit: organisations whose sensitive-data risk is concentrated in SaaS collaboration, employee workflows and AI applications.

POC focus: false positives, real versus example credentials, historical SaaS data, inline controls and remediation.

7. Google Cloud Sensitive Data Protection: best treated as a building block

Google Cloud Sensitive Data Protection takes a different approach from the broad DSPM platforms. It provides built-in and custom information detectors, inspection APIs, classification, image OCR, redaction and de-identification capabilities. Pricing is usage-based, enabling the integration of detection directly into engineering pipelines rather than procuring an entire security platform.

This can be exactly what a technical team needs. It can also create a lot of work around the detector. Knowing that an object contains personal information does not automatically tell you the business owner, inappropriate permissions, source lineage, remediation priority or whether another copy has already reached an AI knowledge base.

Best fit: developers building privacy controls and Google Cloud teams seeking programmable detection, transformation, and de-identification.

POC focus: OCR quality, custom infoTypes, API throughput, scan cost, regional requirements and the engineering effort required to turn findings into governance actions.

Your search, your sources

Make DIY AI a preferred source

See more of our reporting in Google Top Stories, AI Overviews and AI Mode.

Add DIY AI on Google

Use an open-source PII detector as the baseline, not the finish line

Microsoft Presidio is useful in a procurement exercise because it provides an open-source baseline for automated PII detection and anonymisation. It combines recognisers, patterns, named entity recognition and contextual logic, and can be extended with custom detectors.

Run the obvious PII portion of your test corpus through Presidio or a comparable open-source detector before an expensive enterprise proof-of-concept. You are not expecting the library to replace BigID, Varonis or Cyera. You are establishing how much of the detection problem can already be solved without an enterprise platform.

If a commercial product’s only visible advantage is that it finds the same email addresses and phone numbers, the procurement case is weak. Its value should appear elsewhere: harder contextual classifications, connector coverage, ownership, lineage, permissions, AI governance, lower false-positive workload or remediation.

AI classification should supplement deterministic detection, not replace it

There is a temptation to treat contextual AI as a universal replacement for regex, exact matching and rules. That would be a mistake.

Deterministic methods remain excellent for well-defined identifiers. If an organisation maintains a database of actual customer account numbers, exact matching can be more precise than asking a probabilistic model whether a number appears sensitive. Checksums, dictionaries and structured rules are also cheap and predictable.

Contextual models earn their keep on difficult material: free-text health information, legal documents, intellectual property, internal project materials, unusual customer notes, and other information whose sensitivity depends on meaning rather than syntax.

The strongest architecture is therefore usually hybrid:

• Exact matching for known organisational records.
• Patterns and checksums for well-defined identifiers.
• Secret-specific detection for credentials and keys.
• NER and machine learning for entities in free text.
• Contextual or generative models for document-level meaning and proprietary categories.
• Human review where the consequence of a wrong classification is high.

Ask another question before enabling any AI classifier: Where does classification inference happen? If raw content is sent elsewhere for model inference, the classifier’s security architecture becomes part of the sensitive-data review. Find out what content leaves the source environment, what is retained, which regions are involved and whether training or telemetry uses customer material.

The ugly file test is more valuable than the polished demo

Support for “PDF”, “Excel” or “source code” tells you surprisingly little. File handling has layers.

An image-only PDF needs OCR before a text classifier can do much with it. A spreadsheet can contain sensitive data on an ignored sheet rather than the visible one. Source code can contain genuine secrets, fake examples, generated files and commented documentation. Contracts can bury commercially sensitive information in appendices while the first few pages contain little of interest.

Oversized files create another trap. Some discovery systems use sampling to keep scanning economically practical. That may be entirely reasonable, but you need to know the sampling boundary before interpreting the result.

During the POC, deliberately place sensitive content:

• near the end of a large document;
• on a secondary spreadsheet sheet;
• inside an image-only PDF;
• next to a similar but benign identifier;
• inside source-code documentation and inside an actual configuration secret;
• inside a duplicate or archived copy of another file.

Record not only whether the platform detects the item, but whether its interface makes a skipped or partially scanned object visible. Silent non-coverage is more dangerous than an explicit “unsupported” result because the dashboard can still look complete.

Test what happens before enterprise data enters AI

Sensitive data discovery becomes much more valuable when labels determine what AI systems can access before ingestion or retrieval.

Map the complete AI data path. A source document can be copied into an ingestion queue, split into chunks, written into another document store, associated with vector metadata, cached, inserted into an evaluation dataset and eventually surfaced to an agent. A discovery platform that understands only the original SharePoint folder may not describe the copy the AI application is actually reading.

For agentic systems, classification also needs to sit beside access control. Our guide to AI agent security explains why a capable agent should not automatically inherit every permission available to its user or connector. Discovery tells you what is sensitive. Authorisation still decides whether the agent should receive it.

Classification also does not solve hostile instructions embedded inside trusted-looking content. That is a separate control problem covered in our guide to prompt injection. Treating every AI security problem as DLP creates the opposite mistake of ignoring classification entirely.

The cheapest tool can create the most expensive review queue

Sticker price is a poor way to compare this category because vendors charge against different units and shift work to different parts of your team.

A more realistic monthly cost model is:

licensing + data-source charges + scan compute + implementation + analyst review + classifier tuning + remediation work + rescanning

BigID and the larger DSPM platforms generally require commercial scoping. Sentra uses customised pricing. Microsoft mixes existing licensing entitlements with additional capabilities and usage-based services. Google Cloud Sensitive Data Protection is consumption-oriented. Nightfall exposes more plan information publicly, but discovery still sits within a wider security product.

None of those models is inherently cheaper. A usage-based API can become expensive when an organisation repeatedly scans enormous datasets, while an enterprise licence can be wasteful when only three repositories need protection.

Normalise the POC around your own workload. Ask each vendor to price the same sources, approximate data volume, scan frequency, retention period and remediation requirements. Then add the estimated staff time needed to operate it.

The useful number is not the cost per terabyte. It is closer to the cost per validated sensitive-data risk that the organisation can actually close.

A practical scoring model for AI data classification

If we were running a formal procurement comparison, we would not give equal weight to every feature. For a sensitive-data discovery programme designed to support AI adoption, this weighting is more useful:

Evaluation area	Weight	What earns a high result
Classification quality	30%	Strong precision and recall across obvious, contextual and proprietary data
Discovery coverage	15%	The expected objects are genuinely inspected rather than merely inventoried
Confidence and context	10%	Confidence is calibrated, and findings explain why the classification was applied
Ownership and lineage	10%	Findings lead to responsible owners and useful origin or movement context
Access risk	15%	The system identifies which sensitive assets are genuinely overexposed
Remediation	10%	Findings can trigger useful controls or workflows without manual reconstruction
Operating cost	10%	Licensing, scanning, review and tuning remain sustainable at expected scale

Change the weights if your objective is different. A development team embedding PII detection into an API should place far greater weight on latency, programmatic control, and cost per inspection. A regulated enterprise rolling out copilots may care much more about access, provenance, custom intellectual-property categories and governance.

Questions to ask every sensitive data discovery vendor

• Do you perform complete content scans, sampling or a mixture of both?
• Which file formats are parsed deeply, and which are metadata-only?
• What happens to image-only PDFs and other OCR-dependent material?
• Can we export finding-level results so we can calculate our own precision and recall?
• Can we create organisation-specific classifications for information that lacks a standard identifier?
• Where does AI classification inference run, and does source content leave our environment?
• How is confidence calculated, and can thresholds control automated actions?
• Can the platform identify the owner of a sensitive asset?
• Does it understand permissions and actual access, or only content?
• How are duplicate and derived copies handled?
• Can classifications feed existing IAM, DLP, SIEM, SOAR and AI-governance systems?
• What changes after tuning, and how much ongoing analyst work is expected?
• What is the pricing unit: users, connectors, repositories, data volume, compute or another measure?
• What happens to costs when we rescan the same estate frequently?
• Can remediation be automated safely, or does every finding become another ticket?

Which sensitive data discovery tool should you choose?

Start with BigID if the project is really an enterprise data intelligence and governance programme. Put Varonis high on the list when risky permissions and exposure are the main problems. Cyera and Sentra deserve strong consideration for cloud-first DSPM and AI-data projects. Microsoft Purview becomes much more compelling when Microsoft already owns a large part of your data, identity and compliance stack.

Nightfall is particularly interesting where historical discovery needs to connect with SaaS, employee and AI-related DLP. Google Cloud Sensitive Data Protection is the more natural choice when developers need programmable inspection and de-identification rather than an enterprise governance console.

Then ignore the marketing hierarchy and make them process the same ugly corpus.

The winning product should not simply find the most things. It should discover the data you expected, catch contextual information and deterministic patterns missed, avoid burying analysts in false positives, explain why a finding is risky, connect it to an owner and access path, and make remediation cheaper than continuing to ignore the problem.

Frequently asked questions

What are sensitive data discovery tools?

Sensitive data discovery tools inspect data stores, files, SaaS applications, databases and other repositories to identify information that requires additional protection. This can include PII, PHI, payment information, credentials, intellectual property, confidential documents and organisation-specific sensitive data.

What is AI data classification?

AI data classification uses machine learning, natural language processing or other contextual models to categorise data based partly on meaning rather than relying exclusively on fixed patterns. It is particularly useful for materials such as customer notes, contracts, and proprietary documents, where sensitivity cannot be captured by a single regular expression.

What is the difference between PII detection software and DSPM?

PII detection software identifies personal information within content. DSPM adds the wider security context, including where sensitive data is stored, who can access it, how exposed it is and what should be remediated. A detection API can be part of a DSPM platform, but the two categories are not interchangeable.

How should I test false positives in a data classification tool?

Create benign documents that deliberately resemble sensitive data. Include long internal reference numbers, fictional identities, example API keys, ambiguous names and documentation containing sample credentials. Measure false positives per 1,000 benign objects and the time required to investigate each one.

Do AI classifiers make regex-based PII detection obsolete?

No. Exact matching, checksums, dictionaries and patterns remain efficient for predictable identifiers. AI is most useful where context changes the meaning of the information. A hybrid detection stack usually makes more sense than forcing one technique to solve every classification problem.

Can sensitive data discovery stop employees from sending information to AI tools?

Discovery alone cannot. It can identify and classify information that should receive stronger controls, but enforcement normally requires DLP, browser or endpoint controls, application permissions, AI gateways or other access policies. For AI agents, the classification also needs to influence what connected tools and data sources the agent is authorised to use.