AI Data Classification: The Categories the Audit Record Has to Carry at the LLM Request Boundary
AI data classification is the layer that labels prompt content before policy evaluates and before the audit record commits. Deterministic categories for PII, PHI, source code, customer data, and free-form sensitive labels supply the field the EU AI Act Article 19 record expects on every decision. This piece walks through the categories, the placement where the classifier runs, the regulatory framing, and how the labels feed identity-bound policy at the request boundary.
The Cloud Radix research found that 78% of employees use unauthorized AI tools at work, and 77% of those admit to pasting sensitive business data into the prompts. The volume of sensitive data flowing through prompt bodies makes data classification at the LLM request boundary the field the audit record sits on. Without a label on the content, the policy cannot evaluate. Without an evaluation, the record carries no decision context.
I want to walk through the categories AI data classification has to label, the placement where the classifier sits, how the labels feed policy, and the regulatory framing that decides which categories carry weight on the audit record.
Categories the classifier has to recognize
A working AI data classification layer ships deterministic categories tuned for prompt content rather than for files or for email. The categories the audit record references include:
Each category carries a confidence score from the classifier output. The policy evaluates against the categories and the score together. The record captures the label, the score, and the snippet location inside the prompt.
Where the classifier sits
The classifier runs at the HTTP request boundary between authenticated users or agents and the LLM endpoint. The inspection layer terminates the TLS connection from the caller, authenticates the caller against the corporate identity provider, runs the classifier against the prompt content before the model receives the request, and commits the result to the per-decision record.
The placement matters because the prompt content sits inside a TLS-encrypted POST body to a SaaS endpoint. A classifier running at the network edge cannot read the body without an MITM appliance. A classifier running inside the application sees the body but does not see the verified natural-person identity unless the application carries it through. The placement at the HTTP proxy boundary holds both the prompt and the identity at the same moment.
How labels feed policy
The policy surface evaluates against identity context (role, group membership, data tenant) and the classification labels. A typical policy rule reads:
The policy returns a deterministic decision: permit, redact, or block. The decision is the field auditors sample. The record carries the policy version, which lets the program reconstruct what the policy said at the moment of the decision even if the policy changed afterward.
The redact decision substitutes a placeholder for the labeled span before forwarding the request to the model. The model receives a prompt where the PII or PHI has been replaced with a typed placeholder. The original prompt content is retained in the audit record on a separate encrypted store with access controls.
Regulatory framing
EU AI Act Article 12 requires automatic recording of events over the lifetime of the system sufficient to ensure traceability. Article 19 specifies the record fields, including identification of natural persons involved, input data references, and the classification labels relevant to the decision. The August 2, 2026 deadline applies to high-risk AI systems including credit scoring, employment screening, education access, and biometric identification.
HIPAA Security Rule 45 CFR 164.312(b) expects audit controls on systems that process PHI. The PHI label on the classifier output is the field that maps directly to the HIPAA record requirement. A classifier that fails to identify PHI in clinical narratives or SOAP note fragments produces records that fail the HIPAA audit sample.
PCI DSS v4.0 requirements 3 and 10 expect protection of cardholder data and audit logging. The payment-card pattern in the PII category is the field that maps to PCI requirement 10 on the AI request path. The classifier output feeds the same audit pipeline the PCI program already operates.
What the classifier does not do
The classifier does not decide whether the data should have been in the prompt. The policy decides that. The classifier does not bind identity to the request. The IdP integration at the inspection point does. The classifier does not produce the audit record by itself. The enforcement layer that commits the record on every decision does.
These boundaries matter because programs that buy a classifier alone often discover the gap when the auditor asks who made the request. Identity binding is the field that turns the classifier output into an audit record.
Where most programs start
A program building toward the August 2, 2026 deadline typically starts with the classifier in detection mode for the first thirty days. The team observes which categories fire on real traffic, tunes the confidence thresholds, and confirms the false-positive rate is low enough that production teams accept the enforcement. After calibration, the policy moves from permit-and-log to redact-or-block on the categories the program decided carry the most risk.
The calibration window is the operational cost of standing up AI data classification at the boundary. Programs that skip it discover false-positive volume that production teams cannot accept. Programs that invest in it land on policy thresholds that hold up at the enforcement step.
DeepInspect
DeepInspect ships AI data classification at the HTTP request boundary as part of the identity-aware enforcement gateway. The proxy authenticates the caller against the corporate IdP, runs deterministic classification against the prompt content (PII, PHI, source code, customer data, organization-defined categories), evaluates policy against identity and classification, and commits a per-decision audit record before the response returns. The records carry the classification label, the confidence score, the policy version, the decision, and an integrity signature on a tamper-evident series.
For programs preparing for the August 2, 2026 deadline, the classifier output is the field the audit record references. The placement at the request boundary is what makes the field consistent across multiple application teams and multiple LLM providers.
Book a demo today.
Frequently asked questions
- How does the classifier handle false positives?
The classifier outputs a confidence score per label. The policy evaluates against a threshold (typically 0.7 for high-precision categories, 0.85 for free-form categories with higher variance). Programs calibrate the thresholds during the first thirty days against real traffic and tune by category. The audit record captures the score, which lets the program review whether false positives drove block decisions inappropriately.
- Can the classifier handle multi-language prompts?
The classifier supports the major languages enterprise prompt traffic uses (English, Spanish, French, German, Portuguese, Japanese, Mandarin, Korean). The PII patterns include locale-specific identifier formats. PHI coverage tracks ICD-10 codes across English clinical traffic; programs with significant non-English clinical workflows tune the classifier with additional pattern sets.
- How does AI data classification work for agentic flows?
Agentic flows generate prompt content programmatically. The classifier runs on the assembled prompt the agent sends to the LLM, not on the intermediate state inside the agent's reasoning step. The identity binding for agentic flows carries the service identity the agent inherits plus the originating user identity if the agent is operating on behalf of a person. The audit record carries both fields on the same series.
- Can we plug an existing classifier in instead of the proxy's built-in?
The enforcement layer can call an external classifier through an integration if the program already operates a canonical classifier (Nightfall, Protect AI, or an internal model). The audit record carries the external classifier's output alongside the policy decision. Programs that already standardize on one classifier across SaaS and email can extend that taxonomy to the LLM request boundary through this pattern.
- What is the classifier's overhead on the request path?
The classifier runs in under 30 ms on typical prompt sizes (under 4,000 tokens). End-to-end inspection overhead, including TLS termination and policy evaluation, measures under 50 ms in DeepInspect's internal testing. LLM inference itself takes 500 ms to 5 seconds, which keeps the classification overhead inside the variance of the round-trip.