In brief
- Permission depends on the data class, purpose, tool, contract and configuration.
- A company account does not automatically make every input safe or lawful.
- Outputs, embeddings, logs and evaluation data generally inherit the protection of their sources.
- A useful rule also provides a safe alternative when an input is not allowed.
Four questions determine whether an input is appropriate
Approving a product in isolation is not enough. The same tool may be suitable for public marketing copy and unsuitable for personnel files. Data, purpose, recipient and required function must be considered together.
- Data: What information and which people are involved?
- Purpose: What specific task is being supported?
- Tool: Is this exact product version approved under the company account?
- Function: Will the user enable chat history, file upload, web search or connectors?
Five data classes with examples and clear handling rules
A classification becomes useful only when employees recognise typical content and can immediately derive an action. The classes below are an accessible example; labels and approvals must align with the organisation’s established information security and privacy practice.
| Data class | Easy-to-recognise examples | Handling in AI |
|---|---|---|
| Public | Published product pages, press releases, public job adverts, approved brochures and published annual reports. | May be processed in approved tools. Before upload, still remove drafts, comments, change history and hidden metadata. |
| Internal | Internal process descriptions, general meeting agendas, templates, organisation charts without private contact details and non-sensitive project updates. | Use only through managed company accounts and for business purposes. Remove unnecessary names, IDs and internal distribution lists; do not share through public links. |
| Confidential | Customer contracts, unpublished prices, source code, sales pipeline, financial planning, proposals and internal strategy documents. | Use only in an explicitly approved case with reviewed contract, data flow, access controls, logging and retention. Limit data to the required extract. |
| Highly protected | Health information, salaries, performance reviews, disciplinary matters, biometric data, personnel files or cases with high potential harm. | Block by default. Process only in a specially authorised solution with a documented purpose, strict access rights and additional privacy and security review. |
| Secrets and credentials | Passwords, API keys, private keys, recovery codes, production access tokens and complete secret formulas or processes. | Never copy them into a chat, prompt, upload or test dataset. Keep credentials in a secrets manager and use clearly non-functional placeholders in examples. |
Data class, privacy category and the AI use case's risk assessment are not the same
These three classifications answer different questions and can apply at the same time. A published job advert may be public, while an internal application-ranking system processes personal data and needs a deeper AI risk assessment because of its impact. This operational assessment does not replace the separate analysis of whether the EU AI Act or other regulatory categories apply.
| Classification | Main question | Example |
|---|---|---|
| Internal data class | How much protection does the information need, and how may it be stored, shared and processed? | An unpublished price list is confidential even if it contains no personal data. |
| Privacy category | Does the information relate to a person, and is it sensitive personal data? | A business email address is personal data; a medical diagnosis is sensitive personal data. |
| AI use-case risk assessment | What effect can the specific AI use case have on people, the organisation or safety? | A system that prioritises applications needs a different review from an assistant for public marketing copy. |
Classification applies to the complete data flow
The text in a prompt is only one part of the picture. An AI system can create copies, derived content and technical logs. The handling rule must therefore cover every processing step.
| Step | What is created or transferred | Practical rule |
|---|---|---|
| Input and chat | Prompts, pasted text and conversation history. | Enter only necessary content, account for history and sharing links, and check the highest data class permitted for the tool. |
| File upload | Documents including comments, metadata, worksheets or embedded attachments. | Clean the file first, select only required pages, and define retention and deletion for uploads. |
| Connector and RAG | Content retrieved from a DMS, CRM, wiki, email system or database. | Enforce existing access rights, limit sources, and prevent the search index or answer from exposing another user’s content. |
| Embeddings and index | Numerical representations, text chunks and metadata used for retrieval. | Protect them like the source, separate tenants, keep them current, and remove them when access is revoked or the source is deleted. |
| Logs and traces | Error logs, prompt and answer excerpts, user IDs and technical metadata. | Minimise or mask content by default, restrict access and apply short, justified retention periods. |
| Outputs and evaluation data | Summaries, translations, generated files, feedback and test cases with expected answers. | Review before sharing, treat at least like the source, and prefer synthetic or approved cases for evaluation. |
| Retention and deletion | Chats, files, indexes, caches, logs, backups and exported results. | Set periods by data type, include downstream and backup systems, and keep auditable evidence that deletion occurred. |
Derived data inherits the protection of its source
A summary, translation or embedding is not automatically less sensitive than its source document. Until an accountable owner has demonstrably decided otherwise, at least the source classification applies. Where sources are mixed, use the highest class present.
- A summary of a confidential contract remains confidential.
- A search index built from personnel files remains highly protected even if individual passages are not stored in directly readable form.
- An AI output containing new assessments about people may require even greater protection.
- Anonymisation lowers the class only where re-identification is no longer reasonably possible; merely replacing a name is often insufficient.
A lean process clarifies ownership and change
Classification must not rest solely with individual employees. Data assets and AI applications need named owners, a fast route for resolving uncertainty and triggers for reassessment.
- Step 1
Assign the initial class
The accountable business function classifies information when it is created or received; the data owner is responsible for existing datasets.
- Step 2
Implement the handling rule
System and AI owners translate the class into permitted tools, access rights, connectors, logs, retention periods and deletion paths.
- Step 3
Review specialist cases
Privacy and information security are involved selectively for personal data, high protection classes, new data flows or exceptions.
- Step 4
Reassess change
New sources, user groups, purposes, models, providers or output channels trigger a renewed classification and approval review.
Safe alternatives make rules workable
A prohibition without an alternative encourages shadow use. Employees should know how to complete the task safely, for example with anonymised examples, approved knowledge sources or an internal assistant with suitable access controls.
- Step 1
Reduce
Use only the passages or fields the task genuinely requires.
- Step 2
Mask
Remove or replace names, customer numbers and identifiers where the purpose permits.
- Step 3
Use an approved source
Provide documents through a controlled knowledge connection instead of manual copying.
- Step 4
Ask
Offer a fast approval route for unclear or novel cases.
Example: Drafting a response to a customer complaint
A customer complaint contains names, contact details, a contract number and an unpublished price. The company classifies the document as confidential. An employee uses the approved company tool for this purpose, removes unnecessary identifiers and submits only the relevant facts. The internal application retrieves required contract information through existing access rights. The generated draft remains confidential, is reviewed before sending and is deleted according to the defined retention period.
What to remember
Connect every data class to understandable examples, approved tools, permitted purposes and rules for the entire data flow. A classification is effective only if employees can apply it within seconds and accountable owners can verify its technical implementation.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed
Reviewed 17 July 2026. General information, not legal advice. The specific legal position and applicable scope must be assessed for each use case.