AI Data
Classification Guide

At minimum, the following data categories should never be entered into any AI tool unless the tool has been specifically approved for that data type with appropriate controls in place: personally identifiable information (PII) about customers, employees, or other individuals; financial account data, payment card data, or banking details; healthcare or medical records; credentials, passwords, API keys, or authentication tokens; legally privileged communications (attorney-client, doctor-patient); trade secrets, unreleased product plans, M&A information; and source code for systems handling sensitive data. The key question is: if this data appeared in the AI provider's training set and was reflected in responses to other users, what would the consequence be? If the answer is a regulatory violation, legal liability, or material business harm, the data should not enter an external AI tool.

Practical implementation requires three layers working together. First, the policy layer: a clear, documented classification scheme with explicit AI tool rules for each level, written in plain language employees can apply without ambiguity. Second, the training layer: regular employee training using realistic examples of data employees actually encounter, with decision scenarios that build classification intuition. Third, the technical layer: DLP rules that detect classification-relevant data patterns (credit card numbers, NHS numbers, company financial metrics) being submitted to AI services, and an AI security platform that monitors all AI tool usage and flags policy violations. The technical layer is what makes classification enforceable, without it, classification is a guideline rather than a control.

Yes, and this is where most organisations go wrong. The appropriate data classification level for a given AI tool depends on: whether the tool has a data processing agreement and no-training guarantee (critical for any tool used with Internal or above data); where the data is processed and stored (EU-only for GDPR-sensitive data); what security certifications the tool holds (SOC 2 Type II, ISO 27001); and whether the tool is an enterprise tier product or a consumer product with different data handling defaults. The same data type may be permitted in one AI tool and prohibited in another based on these factors. Your AI acceptable use policy should specify approved tools for each classification level explicitly, not leave employees to make this determination themselves.

Using personal data with AI tools creates several GDPR obligations. As controller, you are responsible for ensuring lawful basis for the processing activity, which for AI-assisted work typically means legitimate interests or performance of contract, both requiring a necessity assessment. If the AI vendor is a data processor, you need a GDPR-compliant DPA under Article 28 before any personal data is processed. If the vendor's terms mean they are a data controller (common in consumer AI products), you need to assess whether the transfer to that controller has a lawful basis. The data minimisation principle (Article 5(1)(c)) requires that only the minimum necessary personal data is used, submitting a full customer database to an AI tool for a task that could be accomplished with anonymised data would likely violate this principle. Finally, any AI system making automated decisions about individuals may trigger Article 22 rights, requiring human review processes.