Quick recap for anyone joining mid-series: In Part 1 of this audit (The AI Data Readiness Audit: Part 1, Discovering What AI Can Actually Access), we mapped every data store your AI systems can actually reach, including the shadow databases and forgotten SharePoint sites nobody remembers creating. If you haven't done that step yet, go back and do it first. Everything below assumes you already have that inventory in hand, because classification without an inventory is just guessing with extra steps.
I've started thinking of this whole audit like binge-watching a good mystery show. Part 1 was "who are all the characters in this story," the full cast list. Part 2, the one you're reading now, is "which of these characters actually did something interesting." Not everyone in your data estate is a suspect. But you don't know which ones matter until you've actually looked, and that's the part most organizations skip, because classification is time consuming and skipping feels efficient right up until it very much isn't.
Sensitive isn't just PII anymore
Here's where I want to push back on the instinct most security teams have when they hear "classify sensitive data." The reflex is to think PII: names, social security numbers, credit card digits, the usual suspects. That reflex made total sense five years ago. It is dangerously incomplete now.
In an AI context, sensitive data includes at least three categories most classification programs still under-cover. First, proprietary intellectual property: source code, pricing models, unreleased product designs, the stuff that doesn't have a regulatory framework demanding you protect it but absolutely has a board demanding you protect it. Second, model-training data itself, because if an AI model was trained or fine-tuned on a dataset containing sensitive information, that sensitivity doesn't stay contained to the original file. It can echo out through the model's behavior in ways that are genuinely hard to audit after the fact. Third, and this one gets missed constantly: access tokens and credentials sitting in config files, notebooks, and chat logs, which are sensitive not because of what they say but because of what they unlock.
Miss any of these three, and your classification program has a blind spot exactly where AI agents are most likely to go looking, because agents don't respect the informal boundary between "the data we usually worry about" and "the data that's actually valuable to someone."
Why rule-based classifiers reach their limits
If you've worked with an older DSPM or DLP tool, you've probably met the regex-and-keyword approach to classification: look for patterns that resemble a social security number, flag anything near the word "confidential," build out a growing list of exceptions as false positives pile up. It works, sort of, for narrow, well-structured data. It falls apart fast against the messier stuff AI systems actually touch: a PDF contract with sensitive terms buried in paragraph fourteen, a scanned image of a form, an audio transcript of a customer call, a spreadsheet where the sensitive column has a header that says nothing informative at all.
Rule-based classification is looking for a pattern. What you actually need is something closer to comprehension, understanding what a piece of content is and what it means in context, not just whether it matches a template. That's the difference between a classifier that catches "123-45-6789" and one that understands a paragraph describing a merger negotiation is sensitive even though it contains no numbers that trip a regex at all.
What SLM-powered classification actually gets you
This is where small language model powered classification earns its keep. Instead of pattern matching alone, it layers schema analysis, semantic classification, vector embeddings, named entity recognition, optical character recognition, and speech-to-text processing to understand both the content and the context of what it's looking at. In practical terms: structured data, unstructured documents, images, and audio all get evaluated by something that understands meaning, not just shape.
The classification approach we covered in Day 8 of this series scans across 250-plus classifiers and 130-plus file formats, with better than 98 percent accuracy independently validated by customers operating at petabyte scale, and a false positive rate under 1 percent. Those numbers matter more than they might sound, because a classification system that produces too many false positives constantly gets ignored within a quarter, and a classification system that misses real sensitive content gets you the exact headline you were trying to avoid. Accuracy at that level is the actual foundation everything downstream depends on: if classification is wrong, every enforcement action built on top of it is wrong too, just with more confidence.
Your Part 2 classification checklist
Building directly on the Part 1 inventory, here's the practical rundown:
- Extend your sensitivity taxonomy beyond PII. Explicitly include proprietary IP, model-training datasets, and credentials or access tokens as first-class categories, not afterthoughts bolted onto a PII-first framework.
- Classify by content, not by location. A file's sensitivity doesn't change because it moved from a data warehouse to a collaboration tool. Classification needs to travel with the data, not reset every time the data moves.
- Cover every data type your AI systems touch. Structured tables, unstructured documents, images, and audio all need coverage, because agents don't limit themselves to the format your classifier is best at.
- Validate accuracy against a real sample, not a vendor's demo dataset. Ask for false positive and false negative rates against your own data, not a curated showcase.
- Connect classification output back to the Part 1 inventory. A classification result that isn't tied to a specific, discoverable asset is a spreadsheet, not a governance program.
What's coming in Part 3
Once you know what data exists and how sensitive it is, the next question is who, and what, can actually reach it, which is exactly where we're headed in Part 3 of this audit: enforcing least-privilege access for AI systems specifically. Discovery tells you what exists. Classification tells you what matters. But neither answers the most important question: Can your AI agents actually reach it? That's where Part 3 will begin. The gap between those two steps is where a surprising number of otherwise well-run security programs quietly stall out.
Conclusion
Discovery tells you what data exists. Classification tells you what it means. Together, they're the foundation everything else in your AI data readiness program depends on, and getting them wrong upstream means every access decision and enforcement action downstream inherits that mistake.
If you're working through this audit for your own environment and want a second set of eyes on your classification approach, we're happy to walk through it. Book a demo to see how Sentra classifies structured, unstructured, image, and audio data at petabyte scale, or catch Part 3 when we cover least-privilege access enforcement for AI systems.
