[EAAPL-SEC009] AI Data Classification

Category: Security / Data Governance Sub-category: Classification Enforcement Version: 1.1 Maturity: Proven Tags: data-classification sensitivity-labels rag-security cross-boundary-controls data-governance output-labelling Regulatory Relevance: Australian Privacy Act APP 11, GDPR Art. 25, EU AI Act Art. 10, APRA CPS234, ISO 27001 A.8.2, NIST AI RMF MAP 1.5

1. Executive Summary

AI Data Classification defines the automated detection, labelling, and enforcement architecture that ensures data entering and exiting AI systems carries appropriate sensitivity labels — and that those labels are enforced at every processing stage. Unlike traditional data classification for document management, AI systems introduce unique challenges: data from multiple classification levels may be mixed in a single prompt (e.g., a RAG system injecting both public and confidential documents), model outputs may inherit the classification of their inputs, and classification must be enforced at machine speed with sub-100ms latency.

For business leaders, the risk without classification enforcement is concrete: a RAG system that retrieves documents across sensitivity boundaries can expose CONFIDENTIAL information to users with only PUBLIC clearance. An AI model processing RESTRICTED data may route that data to an external model provider in violation of data sovereignty requirements. Output labelling tells downstream systems how to handle AI-generated content appropriately.

This pattern covers: automated classification of data entering AI systems, classification enforcement in RAG retrieval pipelines, cross-boundary controls that prevent data from flowing to inappropriate model providers, output labelling of AI-generated content, and the integration of classification decisions with the AI Gateway's routing and policy engine. It is the data governance foundation that makes all other AI security controls classification-aware.

2. Problem Statement

Business Problem

Organisations have invested significant effort in classifying their data — documents labelled CONFIDENTIAL, RESTRICTED, or PUBLIC; databases with column-level sensitivity tags; data catalogs with lineage and classification metadata. However, when AI systems enter the picture, these classifications are often ignored: documents of all classification levels are embedded into a vector database without sensitivity labels, RAG systems retrieve and inject them into prompts without checking the requester's clearance level, and model outputs inherit no classification from the sensitive documents they summarise.

Technical Problem

AI-specific classification challenges:

• Prompt classification: A prompt assembled from a PUBLIC system message, a CONFIDENTIAL user query, and a RESTRICTED document chunk should be classified at the highest level of any component (RESTRICTED). Without automated classification, this labelling does not occur.
• RAG cross-boundary retrieval: Semantic search by its nature retrieves documents based on relevance, not classification. A query from a PUBLIC-clearance user can retrieve RESTRICTED documents if the retrieval layer does not enforce classification boundaries.
• Output classification inheritance: A model output that summarises a CONFIDENTIAL document is at least CONFIDENTIAL. Without output classification labelling, this content may be logged, shared, or processed without appropriate protections.
• Model routing: Data at certain classification levels must not be sent to external cloud model providers (data sovereignty or contractual restriction). Without classification on the prompt, the AI Gateway cannot enforce routing decisions.

Symptoms

• RAG systems retrieving documents without classification filtering on the query.
• Prompts containing CONFIDENTIAL data being routed to external model APIs.
• Model outputs with no sensitivity label, processed as PUBLIC by downstream systems.
• No mechanism to enforce "RESTRICTED data → on-premises model only" routing policy.
• Multiple classification levels mixed in a single vector index with no per-document labelling.

Cost of Inaction

3. Context

When to Apply

• Any AI system with a RAG component that retrieves from a mixed-classification document corpus.
• Organisations with data classification policies that must be enforced in AI pipelines.
• AI systems whose prompts include data from external sources (uploaded documents, database records, email content).
• Regulated data environments where data sovereignty (geography/provider) restrictions apply.
• AI systems that generate content that feeds downstream systems with classification-sensitive handling requirements.

When NOT to Apply

• AI systems operating exclusively on a single classification level of data (all PUBLIC, or all CONFIDENTIAL in an environment where all processing is CONFIDENTIAL-cleared).
• Proof-of-concept systems not processing real enterprise data.

Prerequisites

Industry Applicability

4. Architecture Overview

The classification architecture operates at four distinct points in the AI pipeline: (1) at data ingestion into AI stores, (2) at retrieval from RAG systems, (3) at prompt assembly, and (4) at output generation. Together these four controls create a classification-aware AI pipeline where no data flows without its sensitivity label.

Classification at Ingestion

When documents or records are ingested into AI data stores (vector databases, RAG corpora, fine-tuning datasets), they carry classification metadata from the source system. The ingestion pipeline:

• Reads classification metadata from the document management system or data catalogue.
• If no metadata is present, applies the automated classifier to assign a classification level.
• Stores classification labels alongside the document embedding in the vector database's metadata fields.
• Enforces immutable classification labels — once set, classification can only be elevated (increased), never reduced, without human approval and audit.

Classification Enforcement in RAG Retrieval

When a query is made against the vector database, the retrieval layer applies classification-based filtering:

• The query context carries the requesting user's clearance level.
• Vector search is filtered to return only documents at or below the user's clearance level (using the vector database's metadata filter capability).
• Documents above the clearance level are excluded from retrieval results regardless of semantic relevance.
• If no documents within the clearance level are relevant, the response acknowledges the limitation rather than elevating the user's access.

Prompt Assembly Classification

When the AI Gateway assembles the final prompt (combining system message, user input, and RAG context), it:

• Computes the composite classification of the assembled prompt: maximum of all component classifications.
• Attaches the classification label to the prompt as gateway metadata.
• The routing policy engine uses this classification to select the appropriate model: PUBLIC/INTERNAL → external cloud model allowed; CONFIDENTIAL/RESTRICTED → on-premises or private cloud model only.

Output Classification Labelling

Model outputs are labelled with the maximum classification of the inputs used to generate them. This label is:

• Attached as a response header by the AI Gateway.
• Written to the audit log alongside the response.
• Used by output storage systems to apply appropriate retention and access controls.
• Presented to downstream automated systems so they handle the content with appropriate protections.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Flow

Error Flow

8. Security Considerations

Authentication & Authorisation

• User clearance level must be attested by the Identity Provider (not self-declared by the application). Clearance is a claim in the JWT, signed by the IdP.
• Classification label updates require authenticated, authorised data steward identity — not application-level writes.

Data Classification

• The pattern itself defines and enforces data classification — it is both the policy and the enforcement mechanism.

OWASP LLM Top 10 Coverage

9. Governance Considerations

Governance Artefacts

10. Operational Considerations

SLOs

Incident Management

• Cross-boundary violation (RESTRICTED data routed to external provider) → P1 privacy/security incident.
• RAG corpus with unlabelled documents → P2: block new queries until audit complete.
• Classification metadata corruption → P2: reindex affected documents.

11. Cost Considerations

Cost Drivers

Indicative Cost Range

12. Trade-Off Analysis

Option Comparison

13. Failure Modes

14. Regulatory Considerations

15. Reference Implementations

AWS

Azure

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven

18. Revision History