Almost every enterprise has a data-classification scheme. It usually has three or four tiers (public, internal, confidential, restricted), it was written between 2017 and 2020, and it was designed for a world where data flowed primarily between systems the enterprise controlled directly. The scheme works fine for that world. It does not work for AI deployments, which move data across model boundaries, embedding caches, retrieval pipelines, and editorial surfaces in ways the original classification did not anticipate. The mismatch is producing risk that has not yet surfaced as incidents — but is well-positioned to.
The audit that catches this risk is bounded — typically two to three weeks of work — and is best run before the next major AI deployment expansion. The audit produces a remediation list, a refreshed classification scheme aligned to the way data actually moves under AI deployment, and a set of policy controls that bring the deployment into alignment with what the classification was supposed to mean.
What the audit actually examines.
Three primary data flows that the original classification scheme almost never accounts for.
Corpus ingest. When a document is indexed into the AI deployment's corpus, it acquires a new lifecycle. The original document had a retention policy, an access policy, and a deletion path. The indexed representation — the chunks, the embeddings, the metadata graph — may have none of these. A document classified "internal" may have an indexed representation that is effectively persistent, broadly accessible to model queries, and not subject to the original deletion path. The classification scheme assumes the asset is the document; the AI deployment treats the asset as the indexed representation.
Output generation. When the model produces an output that draws on multiple corpus documents, the output's classification is implicitly the maximum of its sources' classifications — but this is rarely enforced. An output that synthesizes a public document and an internal document may itself be internal in classification, but downstream systems that consume the output may treat it as public because the AI surface they consumed it from did not propagate the classification. This is a category of leak that does not look like a leak in any single system.
Editorial caching. Editor-in-the-loop surfaces frequently cache draft outputs, model responses, and operator queries to support undo, history, and review. These caches inherit the classification of the highest-tier source they touch, but the caches themselves are often outside the scope of the original classification scheme. A draft output that was never shipped because the editor rejected it may still live in the cache, with effective access broader than the original document's classification permitted.
What the audit produces.
The audit produces three artifacts.
A data-flow map of the AI deployment. Every system, every cache, every retrieval pipeline, every editorial surface that data passes through, with the classification of the data at each point. The map is what the security and compliance teams use to identify gaps; it is also what an external auditor will ask for if the deployment ever attracts regulatory attention.
A remediation list. The specific changes — usually small, often configuration-only — that bring each data flow into alignment with the classification it should have. Most remediation items in the audits we have run are bounded: tighten an access policy on an embedding cache, add a classification-propagation step to an editorial surface, change a retention policy on a draft store. The aggregate is meaningful; each individual item is small.
A refreshed classification scheme. The original scheme expanded to include the data primitives the AI deployment introduced — corpus chunks, embeddings, model inputs, model outputs, editorial caches, training data. The refresh is what makes the scheme load-bearing for the next round of deployment expansion.
What this looks like in regulated environments.
In healthcare, financial services, and public-sector deployments, the audit has additional teeth. Regulatory frameworks — HIPAA, GDPR, sector-specific data-handling rules — predate AI deployment in ways the original classification scheme reflects. The audit surfaces every place where the deployment is operating in a gap between the regulatory framework and the classification scheme's coverage. The gaps are not legal violations on their own. They are the conditions under which a future incident becomes a regulatory event.
We wrote about this in the tenant-owned weights decision tree. The audit is the practical version of that decision: not just "should we have tenant-owned weights" but "does our actual data-flow map honor the tenancy boundary the architecture promises." In our experience, the architecture promises and the actual data-flow map agree about seventy percent of the time. The thirty percent of disagreements is what the audit is for.
When to run it.
The audit produces the most value at three specific moments. Before a major expansion of the deployment — adding a new workflow category, ingesting a new corpus, onboarding a new user cohort. Before an external audit cycle — SOC 2, ISO 27001, sector-specific certifications. After any internal incident that surfaced an unexpected data flow — a privacy event, a misrouted output, an editorial leak. The audit costs the same in all three cases and pays back differently. The first two are preventive; the third is forensic.
If your AI deployment is past the pilot phase and you have not run this audit, you are in the most common posture in the enterprise market right now. You are not alone. The deployments that are running this audit are the ones that will be defensible when the regulatory landscape catches up to the deployment landscape, which the consensus expects to happen within the next eighteen months. Doing the audit now is the cheap version. Doing it under regulatory pressure is the expensive version.