A salesperson is preparing an offer that was due yesterday. He pastes a client’s framework agreement into a free chatbot, asks for a summary of the terms and gets an excellent result a moment later. The company security policy says only that “employees use AI tools responsibly”. The salesperson was convinced that this is exactly what he did — and it is hard to blame him, since nobody told him which tool is allowed or what must not be entered into it.
An AI use policy makes sense only when it settles specific situations. Below we describe the elements it must include, link them to the GDPR, trade secrets, NIS2 and the AI Act, and provide a table of sample clauses with owners and evidence of application.
Why does a company need an AI use policy and whom does it cover?
An AI use policy tells employees which AI tools they may use, with what data and on what terms, and names who approves exceptions and enforces the rules. Its purpose is not to discourage AI but to move decisions from the individual employee to the organisation. Without a policy, everyone assesses the risk on their own — and everyone does it differently.
The personal scope is worth defining broadly: employees, contractors on civil-law and B2B contracts, and subcontractors working on company data; for suppliers, the rules are carried over into contracts. The material scope covers chatbots, assistants in office suites, tools for code, transcription and translation, and AI features built into other applications.
The document starts with definitions: “AI tool”, “approved tool”, “company account”, “confidential data”, “AI output”. They settle disputes before they arise, for example whether summarisation in a video conferencing app is an AI tool. The policy takes data classes, account rules and incident reporting from existing documents instead of duplicating them.
Which AI tools are allowed and how should they be approved?
The policy should contain a list of approved AI tools with the required settings and a simple path for requesting a new tool, and treat anything outside the list as not allowed for work on company data. The list changes more often than the rest of the document, so it is convenient to keep it as an annex with its own owner and review date.
Each entry states what the tool is for, which account to use, which data classes are permitted and which settings must be enabled, for example disabling model training on the data, if the supplier offers that option.
The approval path must be fast, or employees will bypass it. A form describing the use case, the type of data and the supplier’s name, a security and data protection assessment, and a decision within a set time are enough. The structure of roles, the AI system register and the approval committee are described in our article on the AI governance framework; the policy only says where to submit a request and who decides.
The assessment checks at least where the supplier processes data, whether it trains a model on it, how long it keeps it, whether it will sign a data processing agreement and which logs it provides. The result goes into the register.
What data may be entered into AI tools?
The policy should assign each data class from the company’s classification one of three rules: allowed in approved tools, allowed only in selected tools with additional safeguards, or prohibited in all AI tools. A general ban on “confidential data” is not enough, because employees do not know whether meeting notes or a code fragment are confidential.
Examples work best. The text of a published offer can be processed in any approved tool, a draft presentation without client data in tools with a company account. Contracts, clients’ personal data and product source code go only into tools assessed for that data class. Health data, passwords, API keys and payment card data do not go into AI tools at all.
Simple techniques help: instead of the whole contract, the clause the question concerns; instead of the client’s name, “Client A”; instead of a CRM export, a description of the data structure. This is what the data minimisation principle in Article 5(1)(c) of the GDPR looks like in practice.
Rules alone will not stop every mistake, so the policy mentions the technical controls that support it, such as DLP rules covering traffic to AI services. Their selection and gaps are described in our article on data leaks to ChatGPT and DLP controls.
Key takeaways:
- Each data class gets one rule: allowed, conditionally allowed or prohibited.
- The rules must include examples, because employees do not classify data in the abstract.
- A fragment instead of the whole and a pseudonym instead of a name are practical data minimisation under Article 5 of the GDPR.
- Technical controls support the policy but do not replace it.
How does an AI policy govern company accounts, personal accounts and AI features in SaaS applications?
The policy should require work on company data only from company accounts in approved tools, prohibit personal accounts for business purposes and set rules for browser extensions and AI features switched on in SaaS applications. These are the three most common routes by which data leaves the company’s control.
A personal account and a company account for the same tool may be subject to different terms. Business plans may differ from free ones in their rules on training on data, the retention period and the availability of data processing agreements — this has to be checked in the specific supplier’s terms. A company account also gives the administrator visibility of users and the ability to revoke access when an employee leaves.
Browser extensions with AI features may have broad permissions to read pages, including applications holding company data, so only extensions from the list are allowed, and IT enforces this through browser management. Suppliers may switch on AI features in SaaS applications as part of an update — the application owner submits them for assessment before use.
Together this makes up shadow AI, that is the use of AI tools without the knowledge of IT and security; methods for finding it are described in our article on how to detect and reduce shadow AI.
Who is accountable for AI-assisted output and copyright?
The person who uses AI-assisted output, and their manager, are accountable for it — the policy should say so explicitly and require the output to be verified before it is used in documents, code, client communication and decisions. A model can invent a regulation, a source or a number, and it is the company, not the tool supplier, that answers to the client.
Verification should be proportionate to risk. A draft internal note only needs reading. A reply to a client, an opinion, a contract or production code requires checking facts, sources and behaviour, just as with human work. The policy can also specify when to disclose the use of AI to the recipient — always for material covered by Article 50(4) of the AI Act.
The Polish Act on copyright and related rights (Journal of Laws 2025, item 24) protects a work as a manifestation of creative activity of an individual character (Article 1(1)). Protection of content generated solely by a model, without a creative human contribution, is therefore uncertain. The policy should remind staff that such content may not give the company exclusivity and that material key to the brand needs a substantial contribution from an author.
The other side is third-party rights: the policy prohibits entering material the company has no rights to and requires a licence check of generated code before it goes into a product.
How should AI incidents be reported and AI use monitored while respecting employee privacy?
AI-related incidents are reported through the same path as other security incidents, and the policy should give examples of such events and clearly tell employees which use of AI tools the company monitors, for what purpose and to what extent. Incidents include, among others, pasting data of a prohibited class, using a personal account to work on company data, or an incorrect AI output that reached a client.
Reporting must be safe: if admitting a mistake ends only in a sanction, the next mistake will not be reported. The policy can distinguish an unintentional breach reported immediately from one that was hidden or repeated. Speed matters, because a personal data leak may require notifying the supervisory authority within the deadlines set by the GDPR.
Monitoring the use of AI tools, for example through proxy logs or an admin console, is subject to Polish labour law. Article 22³ of the Labour Code (Journal of Laws 2026, item 1245) allows monitoring of business email and other forms of monitoring where necessary to organise work and ensure proper use of work tools, without infringing the secrecy of correspondence and personal rights. The purposes, scope and method of monitoring are set out in a collective agreement, the work regulations or a notice, and employees are informed no later than two weeks before it starts (Article 22² §§ 6 and 7).
The AI policy therefore refers to the work regulations and states which data on tool use is collected, who has access to it and how long it is kept. Transparent monitoring supports the policy; hidden monitoring undermines trust and may break the law, including the duty to inform employees in advance under Article 22² § 7 of the Labour Code.
How does an AI policy connect with the GDPR, trade secrets, NIS2 and the AI Act?
An AI use policy is one of the organisational measures required by the GDPR, the Polish Act on combating unfair competition, NIS2 and the AI Act, so it is worth writing it to document compliance with all of these acts at once.
The GDPR requires a legal basis for processing (Article 6), purpose limitation and data minimisation (Article 5(1)(b) and (c)) and appropriate technical and organisational measures (Article 32). An AI tool supplier that processes personal data on the company’s behalf is a processor and must provide sufficient guarantees, on the basis of a contract under Article 28. Processing using new technologies that is likely to result in a high risk requires a data protection impact assessment under Article 35.
The Act on combating unfair competition (Journal of Laws 2026, item 85), in Article 11(2), treats information as a trade secret only if the entitled person has taken steps, with due diligence, to keep it confidential. A ban on entering trade secrets into unapproved AI tools is exactly such a step, and its absence weakens the company’s position in a possible dispute.
The NIS2 Directive, in Article 21(2), requires essential and important entities to have, among others, policies on risk analysis and information system security and on supply chain security. In Poland it is transposed by the Act of 23 January 2026 amending the Act on the national cybersecurity system (Journal of Laws 2026, item 252), in force since 3 April 2026. AI tool suppliers are further ICT service suppliers, so their assessment and the list of approved tools fit these requirements.
The AI Act, in Article 4, requires providers and deployers to take measures supporting the development of their staff’s AI literacy, without an obligation to guarantee a specific level (as of 10 November 2026). A policy with clear rules is one of those measures. The other deadlines are described in our article on the EU AI Act timeline, the concepts in the AI Act glossary entry, and a broader management system framework in the ISO/IEC 42001 standard.
How do you enforce and review an AI policy?
An AI policy is enforced in three layers: acknowledgement by staff, technical controls supporting the key rules, and a periodic review that compares the document with the actual use of tools. A document with none of these layers is a declaration, not a policy.
Acknowledgement is worth linking to access: an account in an approved AI tool goes to a person who has accepted the rules. Technical controls include single sign-on to approved tools, blocking or warning on unapproved services and data protection rules for traffic to AI services. Sanctions are better linked to the existing work regulations than set out in a separate catalogue.
The review takes place at least once a year and after every significant change. Its result is a new version with a date, a list of changes and the owner’s sign-off. Versioning matters as evidence: during an inspection or a dispute, the company shows which rules applied on a given day.
Public frameworks help check completeness: NIST published the AI Risk Management Framework (AI RMF 1.0) on 26 January 2023 and the generative AI profile (NIST AI 600-1) on 26 July 2024. OWASP provides the “LLM Applications Cybersecurity and Governance Checklist” (version 1.1 of May 2024), addressed, among others, to executives and to security, privacy, compliance and legal teams.
What clauses should an AI policy contain?
An AI policy should contain at least ten elements, and each needs a specific clause, an owner and evidence of application. An element without an owner or evidence points to a gap.
| Policy element | Sample clause | Owner | Evidence of application |
|---|---|---|---|
| Scope and definitions | ”The policy covers people and subcontractors working on company data and tools that process content using AI models.” | information security | version with date and change list |
| Approved tools | ”Company data is processed only in the tools listed in Annex A, from a company account.” | IT | Annex A with review date |
| Approval of new tools | ”A new tool is requested via a form; the decision follows a security and data protection assessment.” | process owner | register of requests and decisions |
| Data in prompts | ”Specially protected data does not go into AI tools; confidential data only into tools assessed for that class.” | information security, DPO | data class table, data protection rule reports |
| Accounts and extensions | ”Personal accounts are not used for business purposes; extensions with AI features only from the list.” | IT | browser configuration, list of accounts |
| AI features in SaaS | ”A new AI feature is submitted for assessment before use on company data.” | application owners | register of AI features |
| Verification and accountability | ”The person using the output is accountable for it; client content and production code require verification.” | team managers | checklist in the review process |
| Copyright | ”No third-party material is entered without rights; generated code is checked for licences.” | legal | clause in the code review procedure |
| Incidents and monitoring | ”AI incidents are reported like other incidents; the scope of monitoring is set out in the work regulations.” | information security, HR | incident register, monitoring notice |
| Enforcement and review | ”Each tool user acknowledges the policy; review at least once a year.” | policy owner | acknowledgements, review minutes |
A policy an employee can read in a few minutes is more likely to be followed than a lengthy rulebook; details are better kept in annexes.
How can nFlo help you prepare an AI use policy?
nFlo prepares the AI use policy as part of the shadow AI assessment and AI use policy service, which starts by establishing which AI tools employees actually use and what data goes into them. As a result, the document addresses real situations in the company rather than a generic template.
When the policy is part of preparing for the AI Act, we combine it with the AI Act readiness and AI governance service. The broader context is described on the AI security page, and related articles are collected in the AI security knowledge base. If you want to check whether your policy settles the situations described here, contact us.
What else is worth knowing about an AI policy in a company?
The most common questions when writing the first version of a policy.
Is an AI policy mandatory for a company?
No provision explicitly requires a document with that name. The AI Act (Article 4), however, requires measures supporting staff AI literacy, the GDPR requires organisational measures, and the protection of trade secrets depends on steps taken to keep information confidential. An AI policy is the simplest way to document these steps.
Can we simply ban employees from using ChatGPT?
You can, but a ban on its own rarely works: employees turn to personal accounts and devices, and the company loses visibility of what data leaves. A policy that names an approved tool with a company account and sets boundaries for data is more effective.
How often should an AI policy be updated?
At least once a year and after every significant change: a new tool, a change in a supplier’s terms, a new regulation or an incident. The list of approved tools is worth reviewing more often than the rest of the document.
Who should own the AI policy?
Usually the information security or compliance function, working with IT, the data protection officer, legal and HR. One person is responsible for reviews and versioning, and decisions on approving tools have a named owner.
Does an AI policy have to cover contractors and suppliers?
Yes, if they have access to company data. For suppliers, the policy rules are carried over into contracts, including data processing agreements under Article 28 of the GDPR.
