The Question
Your organization has a data classification framework. It has been through several revisions, it is documented in policy, and it governs how data assets are labeled, stored, transmitted, and retained. The framework has categories — Confidential, Internal, Public, or equivalent — and each category has a defined set of controls that data in that category must receive. This is the foundation of your data governance program, and it has worked reasonably well for the data assets it was designed to cover: databases, file shares, cloud storage buckets, email, and SaaS applications.
Then your organization started building AI systems, and the question the data governance team is now facing is: where do AI training datasets, trained model weights, and vector embedding indexes fit in our classification framework? The answer, in most organizations, is that they do not appear in the framework at all. They are not recognized as data asset types. They do not have inheritance rules that propagate sensitivity from source data to derived data. They do not appear in the data catalog. They are governed, if at all, by ML engineering practices that were not designed with the classification framework in mind.
A data classification framework that doesn't cover training datasets, model weights, and vector embeddings has a gap at the exact point where most enterprise AI data risk concentrates.
Why This Matters Now
The practical consequences of this gap became visible in a series of incidents throughout 2024 and 2025. A healthcare technology company completed a regulatory audit in mid-2024 that included a review of AI development practices. Auditors requested the data classification records for training datasets used to fine-tune the organization's clinical documentation model. The organization could not produce them — the training datasets had never been classified as data assets under the governance framework. They existed in a cloud storage environment managed by the ML engineering team, with access controls inherited from the team's IAM configuration rather than from any data governance policy.
The audit finding was not that the data had been mishandled in any operational sense. It was that the data governance framework — which existed, was documented, and governed the source EHR records that seeded the training data — had a systematic blind spot for derived AI data assets. The training dataset was assembled from Confidential source records, but the training dataset itself had never been classified, catalogued, or governed as a Confidential asset. Its access controls, retention schedule, and authorized uses were not documented. The auditors classified this as a significant data governance gap.
The regulatory pressure behind this finding is increasing. The EU AI Act's technical documentation requirements for high-risk AI systems require evidence of training data governance including data sources, preprocessing applied, and relevance to the system's intended purpose. The NIST AI Risk Management Framework's Govern function includes data governance as a core organizational practice. The FTC's 2025 guidance on AI governance cited training data classification as a due diligence requirement for enterprises using AI in consumer-facing contexts. Organizations that cannot demonstrate training data governance are increasingly exposed to regulatory and enforcement risk, not just audit findings.
What the CURVE™ Data Shows
The 2026 Stackcurve Data Security for AI CURVE™ Report assessed the data classification and governance capabilities of platforms across the full AI data asset spectrum. The evaluation found that no current data governance platform provides comprehensive native coverage for all three AI-specific asset types — training datasets, model weights, and vector embeddings — but that several platforms provide meaningful coverage for one or two.
BigID leads in sensitive data discovery for AI training datasets, with the ability to scan structured and unstructured data stores at scale and apply classification tags that propagate to governance workflows. Their ML dataset module extends the BigID classification engine specifically to data assembled for model training, with lineage tracking from source records to derived datasets. Securiti.ai's AI Data Command Center provides the most complete governance framework for AI datasets, with support for consent tracking, data lineage, and cross-border transfer governance for training data. Collibra and Alation, the leading enterprise data catalog platforms, have added support for AI/ML dataset registration, allowing organizations to extend their existing catalog governance to training datasets — though coverage of model weights and vector indexes requires custom configuration. Neither platform has native support for vector embedding classification.
The significant gap across all platforms is model weight file governance and vector embedding classification. These are new data types for which the incumbent governance platforms were not designed, and the market has not yet produced a dedicated platform with strong coverage for both.
The full vendor rankings are in the 2026 Stackcurve Data Security for AI CURVE™ Report — free to download.
The Gap Most Buyers Miss
Most data governance teams approaching the AI data classification problem focus on training datasets — the most visible and intuitive new data class — while overlooking model weights and vector embeddings. All three asset types require explicit framework treatment, and the latter two represent the more commonly neglected gaps.
Training datasets: the most visible gap, but not yet well-governed. An AI training dataset is a distinct data asset assembled from one or more source data assets. It may aggregate records from multiple source classifications: a training dataset built from a mix of public web content, Internal product documentation, and Confidential customer records should carry the highest classification of any component. Most classification frameworks apply this logic automatically to documents and databases through data tagging — but training datasets are typically assembled as flat files or cloud storage collections that are not registered in the data catalog and do not receive classification tags at creation.
The correct governance treatment is to require that any training dataset be registered as a named asset in the data catalog at the point of creation, with metadata capturing: source datasets and their classifications, the highest classification level present in any source, the ML use case and intended model, consent status (for personal data), and data minimization attestation (confirming that only the minimum necessary personal data has been included). This is not technically complex — it is a process change in how ML engineering teams provision training data. The technical enablement is catalog integration in the tooling where training data is assembled.
Model weights: the overlooked derived data class. A trained model is a data asset. A fine-tuned model that was trained on Confidential customer records has, by the logic of derived data governance, a Confidential classification — because querying the model can surface information about the training data. Most classification frameworks do not address model files as a data class, and most ML engineering practices treat model weight files as technical artifacts rather than data assets.
The governance requirements for model weights should mirror those of high-classification data assets: storage in access-controlled repositories with audit logging, transfer approval workflows for sharing or deploying model artifacts, retention schedules (fine-tuned models trained on personal data should be subject to the same retention limits as the source data), and deletion procedures that address the "right to erasure" problem (a fine-tuned model that encodes personal data may need to be retrained or deleted when data subjects exercise erasure rights). None of these governance requirements are standard in current ML platform practice.
Vector embeddings: the newest and least-governed class. A vector embedding of a document is a mathematical representation of that document's content. It is not the document — it is not human-readable — but it is derived from the document's content and can be used to retrieve or reconstruct content semantically. A vector store populated with embeddings of Confidential documents is a Confidential data asset, regardless of whether the embeddings themselves contain legible text.
The classification inheritance rule for vector embeddings should be explicit in the framework: an embedding inherits the classification of the source document. A vector index populated from documents of mixed classification should carry the highest classification level present in the source corpus. This inheritance rule should be enforced at the data pipeline level, not at the application level — the embedding generation pipeline should capture source document classification metadata and propagate it to the vector index registration.
Practical framework extension steps. Add three asset types to the classification framework definition: AI training datasets, model artifacts, and vector indexes. Define inheritance rules for each: training datasets inherit the highest source classification, model artifacts inherit the training dataset classification, vector indexes inherit the highest source document classification. Require data catalog registration at the point of creation for all three asset types. Extend DLP and access control policies to the new asset types using the tooling your organization has in place for source data.
Questions Your Buying Team Should Be Asking
1. Can your platform register AI training datasets, model artifacts, and vector indexes as distinct asset types in the data catalog — and does it support automated classification inheritance from source data?
This question tests whether the platform has been genuinely extended for AI data assets or whether AI support is a marketing layer on top of a traditional catalog. Automated inheritance — where a training dataset assembled from Confidential source records is automatically tagged as Confidential without requiring manual classification input from the ML engineer — is the feature that makes classification sustainable at the pace of AI development. Manual classification of every training dataset is not operationally viable.
2. How does your platform handle data lineage for AI training datasets — specifically, the chain from source records through preprocessing transformations to the assembled training dataset?
Lineage documentation for training datasets is a regulatory requirement for high-risk AI systems under the EU AI Act and an emerging expectation in healthcare, financial services, and other regulated industries. Ask vendors to show you what a training dataset lineage record looks like in their platform: which fields are captured, how preprocessing steps are tracked, and what the export format is for regulatory documentation. The ability to generate a human-readable data lineage report for a specific training dataset is the practical test.
3. Does your platform provide classification and access control for model weight files stored in cloud object storage — including detection of unregistered model artifacts in storage environments?
Most data governance platforms do not have native support for model weight file detection and classification. Ask vendors to describe their approach: do they use file format detection (safetensors, GGUF, PyTorch .pt files), storage path conventions, or metadata tagging to identify model artifacts? Can they flag model weight files in cloud storage that have not been registered in the catalog? This capability gap is significant and worth surfacing early in the evaluation.
4. How does your platform extend data governance to vector databases — specifically, can it enforce classification-based access controls on vector index queries?
Vector database governance is an emerging area where most platforms have limited coverage. Ask vendors to describe their integration with vector database platforms (Pinecone, Weaviate, Chroma, pgvector) and whether they can enforce access controls based on the classification of the source documents at query time. The technically correct answer requires integration at the retrieval layer, not just at the ingestion layer.
5. How does your platform support data subject rights requests — specifically, the ability to identify which training datasets and model artifacts contain data about a specific individual, and what remediation options exist?
Data subject rights under GDPR and CCPA — access, correction, erasure — apply to personal data in AI training datasets and, by extension, to models trained on that data. Ask vendors how their platform supports identifying which training datasets contain records about a specific individual, and what the remediation workflow is for erasure requests. "Retrain the model without the individual's data" is a valid but expensive remediation. "Delete the training dataset" may conflict with model governance requirements. Vendors who have thought through this workflow have materially better coverage for regulated industries.
The Stackcurve Take
Extending a data classification framework to cover AI data assets is primarily a process and policy change, enabled by platform tooling. The technical requirements — data catalog registration, classification inheritance, access control extension — are achievable with current platforms. The organizational challenge is getting ML engineering practices to incorporate data governance requirements at the point where AI data assets are created: when training datasets are assembled, when models are trained, and when vector indexes are populated.
The organizations that have closed this gap have done so by making data governance a gate in the ML pipeline, not an audit retrospective. Training dataset creation generates a catalog registration event. Model training completion generates a model artifact registration event. Both events are automated, not manual. The governance documentation is produced as a byproduct of the engineering process, not as a separate compliance activity.
BigID and Securiti.ai provide the strongest current platform support for AI data asset classification, with Collibra and Alation offering viable paths for organizations that have existing catalog investments and want to extend rather than replace. The model weight and vector embedding coverage gaps are real across all platforms and will require custom configuration or process controls to address in the near term.
The 2026 Stackcurve Data Security for AI CURVE™ Report covers AI data classification tooling, framework extension approaches, and vendor capability assessments for all three AI-specific asset types. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.