An enterprise AI acceptable use policy should start by naming which AI tools are approved for company use and which are explicitly prohibited, since a vague policy that says employees must use AI responsibly gives no one a clear line to follow. The policy needs data classification rules stating what can never be entered into an AI tool, such as customer personal data, source code, or unreleased financial results, alongside guidance for what is acceptable with masking or an approved enterprise-tier tool. It should also cover copyright considerations for AI-generated content, a requirement for human review before AI output is published or acted on for anything consequential, and a clear channel for reporting incidents such as a suspected data leak or a hallucinated fact that reached a customer-facing document. Under the EU AI Act, employers also need an AI literacy element, pairing the policy with role-based training so staff understand the rules rather than treating it as a document to sign once. The policy should be reviewed at least annually, since one written for last year's tools will not cover this year's agents. Nanobase AI drafts and helps implement these AI usage policies alongside the technical controls that enforce them.
Start with a data tier, not a tool list
A policy that lists approved and banned tools by name goes stale within months, since new AI products launch faster than any list can track. The more durable approach is to classify data into tiers and state what is allowed at each tier, regardless of which specific tool an employee is using, because the rule then survives the next product launch. A tiered structure also gives employees a decision they can make quickly in the moment, rather than requiring them to check an approved-tools list every time they consider pasting something into an AI assistant.
A working data classification structure
| Tier | Example data | Rule |
|---|---|---|
| Red | Customer PII, unreleased financials, source code, patient or health data | Never enter into any AI tool without an enterprise data agreement and explicit legal sign-off |
| Amber | Internal drafts, non-sensitive project details, anonymized data | Permitted only in tools with an enterprise-tier contract and no training on inputs |
| Green | Public information, published content, general knowledge questions | Permitted in any sanctioned tool, including free tiers where approved |
This structure only works if employees can tell which tier a given piece of data falls into without asking, which means the policy needs concrete examples specific to the business, not abstract category names alone.
Who signs off on the policy
| Role | Responsibility |
|---|---|
| Chief Information Security Officer or IT security lead | Owns the technical controls that enforce the policy |
| Legal or Data Protection Officer | Confirms tier definitions align with GDPR, KVKK, or sector rules |
| Business unit leaders | Validate the tiers against how their teams actually use data day to day |
| HR or People team | Distributes training and tracks acknowledgment |
Skipping business unit input is the most common reason a policy fails in practice, since a tier structure written by security and legal alone often misclassifies data types unique to sales, engineering, or clinical operations.
Making the policy enforceable, not aspirational
A policy has no effect if it depends entirely on employees remembering it, so the tiers need to be backed by technical enforcement wherever possible: single sign-on restricting access to sanctioned tools, data loss prevention rules flagging Red-tier content pasted into a browser, and a logged exception process for the rare case where a business need genuinely requires an exception. The exception process matters as much as the rules themselves, since a policy with no legitimate path around a rule invites employees to simply ignore it when they hit an edge case. Under the EU AI Act, the policy should also connect to the organization's AI literacy training, since Article 4 expects staff to understand the reasoning behind the rules, not just follow them by rote.
Rollout and review cadence
A policy that is never revisited after launch drifts out of date as fast as the AI tool landscape itself changes, so the rollout plan needs a review date built in from day one, not added once the policy is already stale.
- Draft the tiers with input from legal, security, and at least one representative from each major business unit.
- Pilot the policy with one department for two to four weeks and collect the edge cases that come up.
- Roll out organization-wide with role-based training, not a single generic session.
- Review the policy at least annually, or immediately after adopting a new AI tool category such as agents or coding assistants.
Frequently asked questions
Should the policy name specific approved tools or stay tool-agnostic?
A hybrid works best in practice: keep the data tiers tool-agnostic so they remain valid as products change, but maintain a separate, more frequently updated list of currently sanctioned tools that maps onto those tiers. Embedding tool names directly into the tier rules makes the core policy obsolete every time the tool catalog changes.
How does this policy relate to shadow AI?
The policy is the rule set, and shadow AI is what happens when the rule set is either unclear or the sanctioned catalog fails to meet real employee needs; addressing shadow AI requires both the policy and active discovery of unsanctioned tool use.
Does every employee need the same level of AI training under the policy?
No. Training depth should match role and risk exposure, since an employee building an AI-powered feature needs materially different training than one using an AI assistant for email drafts, a distinction the EU AI Act's AI literacy provision explicitly recognizes.
How Nanobase AI helps
Nanobase AI drafts tiered AI usage policies with clients, working directly with legal and security stakeholders to define data tiers that match how the business actually operates, then helps implement the technical controls, from SSO restrictions to DLP rules, that make the policy enforceable rather than aspirational.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.