An employee acting against instructions does not discharge the company's security obligation. Below you can download, free of charge, a blank corporate AI use policy and a data-leakage incident protocol.
When an employee pastes a customer list into a publicly available AI tool to have it summarised, the result behaves differently from a classic data breach. Nothing is stolen; the data is transferred voluntarily, by the company, into a provider's system in a third country.
Legally this transfer is assessed under three separate headings:
In most companies the answer to all three is the same: unknown. And that is precisely what proves decisive in an audit. The first question in an enforcement assessment is not whether a breach occurred, but whether the company has a record of the measures it took beforehand.
Shadow AI describes tools used without the knowledge of the IT function. In companies that impose blanket bans this category does not shrink — it grows, as use migrates from corporate accounts to personal devices. The result is that the company loses both visibility and any ability to intervene.
For that reason the template below is built on classification rather than prohibition: tools are placed in three classes by data-processing risk, and prohibited input categories are defined separately.
| Provision | Subject | What it means in practice |
|---|---|---|
| GDPR Art. 5 | Principles | Purpose limitation and data minimisation apply to AI inputs too |
| GDPR Art. 6 | Lawfulness | A legal basis is needed for the transfer to the provider |
| GDPR Art. 9 | Special categories | Additional protection regime for health, biometric and similar data |
| GDPR Art. 28 | Processors | Standard terms usually do not substitute for a processor agreement |
| GDPR Art. 32 | Security | Measures appropriate to the risk — policy, training, access control |
| GDPR Art. 33/34 | Breach notification | Time-bound; time runs from becoming aware |
| GDPR Art. 35 | DPIA | May be required for high-risk processing |
| GDPR Art. 44 et seq. | Transfers | Mechanism required where servers sit outside the EEA |
| AI Act Art. 4 | AI literacy | Staff using AI must be sufficiently informed |
| AI Act Art. 50 | Transparency | Disclosure of AI interaction and synthetic content |
Provisions cited reflect the text as at the date this page was prepared. Confirm against the version in force before relying on them.
Copy the text below or download it as markdown. No sign-up.
# CORPORATE AI USE POLICY AND DATA-LEAKAGE PREVENTION PROTOCOL
Document code: AIA-POL-01 · Version 1.0 · Classification: Internal
Effective date: ……/……/20…… Review cycle: 12 months
ARTICLE 1 — PURPOSE AND SCOPE
1.1 The purpose of this Policy is to set out the rules governing the use of
generative artificial intelligence and machine-learning tools ("AI Tools")
within [COMPANY NAME] (the "Company"), with respect to the protection of
personal data, trade secrets and client information.
1.2 This Policy binds Company employees, interns, contractor personnel,
freelance service providers and all third parties with access to Company systems.
1.3 It covers AI use on all Company-owned or Company-accessed devices, as well
as on employees' personal devices (BYOD).
ARTICLE 2 — DEFINITIONS
2.1 AI Tool: any software service producing text, images, audio, code or
decision recommendations from input data.
2.2 Publicly Available AI Tool: a tool accessed under the provider's standard
terms without a corporate agreement.
2.3 Enterprise AI Tool: a tool governed by an agreement executed in the
Company's name containing data-processing terms.
2.4 Shadow AI: any AI Tool used without the knowledge and approval of the
information technology function.
2.5 Sensitive Input:
(a) Personal data and special categories of personal data,
(b) Commercial information of a client, supplier or partner,
(c) Source code, architecture documents, security configurations,
(d) Financial statements, pricing models, non-public information,
(e) Any information covered by a non-disclosure agreement.
ARTICLE 3 — APPROVED TOOL LIST AND ACCESS REGIME
3.1 AI Tools are placed in three classes by data-processing risk:
Class A — Enterprise agreement, excluded from model training. Permitted.
Class B — Enterprise agreement, restricted configuration. Partly permitted.
Class C — Publicly available. Sensitive Input PROHIBITED.
3.2 The Approved Tool List (ANNEX 1) is maintained by IT, reviewed quarterly.
3.3 Use of a tool absent from the List constitutes Shadow AI (Art. 9).
3.4 Class is determined by retention period, whether inputs are used for model
training, server location and the sub-processor list.
ARTICLE 4 — PROHIBITED INPUT CATEGORIES
4.1 Entering any Sensitive Input into a Class C tool is prohibited.
4.2 Even in Class A and B tools, the following require prior approval:
4.2.A Special categories of personal data (GDPR Art. 9).
4.2.B Third-party personal data sets entrusted to the Company under a
processor agreement (GDPR Art. 28).
4.2.C Any data of a client whose contract prohibits or conditions the use
of sub-processors.
4.2.D Production credentials, API keys, access tokens, encryption keys.
4.2.E Correspondence and evidence in an ongoing legal dispute.
4.3 Where in doubt, the input is withheld and [LEGAL] is consulted.
ARTICLE 5 — OUTPUT VERIFICATION AND EDITORIAL APPROVAL
5.1 Unverified output may not be sent to a client, deployed to production,
published publicly, or relied on for a legal or financial decision.
5.2 Verification is performed by an informed employee other than the author and
recorded in the ANNEX 2 Output Verification Log.
5.3 Copyright check: before commercial use, output is checked for reproduction
of protected works; code output is scanned for licence compatibility.
5.4 For public AI content, AI Act Art. 50 obligations are reserved.
ARTICLE 6 — TRANSPARENCY AND DISCLOSURE
6.1 Where an AI system interacts directly with natural persons, disclosure is
made at the time of the first interaction.
6.2 Synthetic audio, image, video or text is marked machine-readably.
6.3 Scope depends on whether the Company is provider or deployer (ANNEX 3).
ARTICLE 7 — INCIDENT RESPONSE PROTOCOL
7.1 Where Sensitive Input has been entered, the employee notifies [INCIDENT
RESPONSE] without delay and within one hour at the latest.
7.2 No disciplinary action is taken on the grounds of the report itself.
Concealment does not benefit from this protection.
7.3 Response sequence:
1) Terminate sessions on the affected account,
2) Submit a written deletion request to the provider,
3) Identify affected data categories and number of data subjects,
4) Assess the notification obligation (GDPR Art. 33/34),
5) Assess contractual notification to the client or partner,
6) Enter the incident in the ANNEX 4 Breach Register.
7.4 Time runs from the moment the breach becomes known.
ARTICLE 8 — RECORDS AND AUDITABILITY
8.1 Retained for at least [PERIOD]: tool-list version history, risk
assessments, output verification records, incident records, training records.
8.2 These are the first documents requested in an audit or supplier assessment.
ARTICLE 9 — NON-COMPLIANCE AND SANCTIONS
9.1 Breach is subject to proportionate disciplinary action.
9.2 Where trade secrets or personal data are intentionally transferred, rights
of termination for cause, damages and criminal liability are reserved.
ARTICLE 10 — TRAINING AND ENTRY INTO FORCE
10.1 A sufficient level of AI literacy is ensured among personnel (Art. 4).
10.2 This Policy enters into force on [DATE] and is notified in writing.
SIGNATURE BLOCK: Prepared by / Reviewed by (Legal) / Approved by (Management)
ANNEXES: 1 Approved Tool List · 2 Output Verification Log ·
3 Role Determination Form · 4 Breach Register
This template is general in nature and does not constitute legal advice.
The template gives you the framework, not the part specific to your company. The most common mistakes:
Where personal data is involved, liability arises as a rule with the company acting as controller. An employee acting contrary to instructions does not remove the company's obligation under GDPR Art. 32. With no written policy, no training record and no access restriction, the argument that the breach was unforeseeable rarely succeeds.
The difference is contractual. Enterprise versions allow retention periods, sub-processor lists and an undertaking that inputs are not used for training to be secured by agreement. Individual use is governed by standard terms, which in most cases do not substitute for a processor agreement under Art. 28.
Usually not. A blanket ban does not eliminate use, it makes it invisible — use shifts to personal devices and accounts, leaving the company with neither record nor remedy. What works is a classified approved-tool list plus clearly defined prohibited input categories.
A deletion request can be submitted, but complete removal from the provider's systems and any training sets usually cannot be verified. The protocol's purpose is not retrieval but timely detection, assessment of the notification obligation, and creating a record.
As a framework yes, as a final document no. Without the bracketed fields and the Article 3 classification completed, the document does no work. It also needs checking against your existing client and supplier agreements.
In a twenty-minute preliminary call we look at your tool inventory and work out the class assignment and role determination together. If you're out of scope, we tell you that clearly too.
Reserve your spot for an online call The call is online · the template is yours either way