Your staff are already using AI tools. Some use the ones you pay for. Some use personal accounts on consumer services. Some use AI features that appeared inside software you bought years ago. An acceptable use policy has to cover all three, and it has to be short enough that people read it.
Most first drafts fail in one of two ways. Either they ban everything, which pushes use out of sight, or they say "use AI responsibly," which tells nobody what to do on a Tuesday afternoon with a customer contract open.
This article sets out what the policy needs to decide, how to tie it to data classification, and what to leave out. It is about the staff-facing rules. Your top-level AI policy, the one ISO/IEC 42001 clause 5 asks for, is a separate document, covered in building an AI management system.
Decide the scope first
Before writing a single rule, settle three scope questions. Each changes what the rest of the policy says.
Who it applies to. Employees, contractors, and anyone else with access to your systems or data. Contractors are the group most often left out.
What counts as an AI tool. Standalone assistants, coding assistants, browser extensions, meeting transcription, and AI features inside existing software. Name the categories so nobody assumes their tool is exempt.
Which accounts. Company-provisioned accounts only, or personal accounts too. Most organizations allow work use only through company accounts, because that is the only way contract terms and admin controls apply.
Approved tools and how a tool gets approved
The policy should not list every approved tool by name. Tools change faster than policies get reapproved. Instead, point to a maintained list, and say who owns it.
The policy then needs a short, real process for adding a tool:
The requester names the tool, the use, and the data it will touch.
Security or procurement reviews it, with depth proportional to the data involved. The approach in vendor tiering by data access works for AI tools too.
The decision, and any conditions, go on the approved list.
Approved tools are reviewed on a cycle, because their terms and features change.
If the process takes weeks, people route around it. A quick path for low-risk tools that touch only public data keeps the slow path credible for the tools that need it.
Tie data rules to your classification scheme
This is the section that does the most work. Do not invent new data categories for AI. Use the classification scheme you already have, and say what each level may go into.
| Classification | Approved company AI tool | Unapproved or personal AI tool |
|---|---|---|
| Public | Allowed | Allowed |
| Internal | Allowed | Not allowed |
| Confidential, including customer data | Allowed only in tools approved for that level | Not allowed |
| Restricted, such as credentials, keys, or regulated data | Not allowed unless a specific exception is approved | Not allowed |
Adjust the levels to match yours. The important pattern is that approval is per tool and per data level, not a single yes or no. A tool approved for internal notes is not automatically approved for customer records.
Add two specific rules, because they come up constantly:
Secrets never go into a prompt. Credentials, API keys, and private keys should be stated explicitly, even though your classification already covers them.
Customer data follows customer contracts. Some contracts restrict subprocessors or processing locations. An AI tool can be a new subprocessor. Check before use, not after.
Rules for outputs
Data going in is half the risk. What comes out is the other half.
The person who uses the output owns it. AI-drafted text, code, or analysis is the user's work product once they use it. They are accountable for its accuracy.
Review before it leaves the building. Anything customer-facing, published, or sent to a regulator gets human review. Say what review means: read in full, facts checked, not skimmed.
Code goes through normal review. AI-generated code follows the same code review, testing, and dependency rules as any other code. No separate, lighter path.
Disclosure where it matters. Decide whether and when staff must disclose AI involvement, for example in customer deliverables. Some customer contracts address this directly.
Prohibited and restricted uses
Keep this list short and concrete. A long list of hypotheticals reads as legal filler and gets ignored.
Common entries:
Using AI tools to make or materially inform decisions about individuals, such as hiring, performance, or credit, without a specific approved process
Uploading content you do not have the right to share, including third-party confidential material
Using AI tools to get around a security control, monitoring, or access restriction
Presenting AI output as verified fact, legal advice, or professional opinion without review by someone qualified
Decisions about people deserve care. Automated decision-making can engage legal rules, such as GDPR Article 22 for decisions based solely on automated processing with legal or similarly significant effects. Confirm the position with counsel for your jurisdictions before writing this section.
Making the policy stick
A policy with no acknowledgment, no training, and no exception path is a document, not a control.
Acceptance. Every person in scope acknowledges the policy at onboarding and after each material revision. Keep the records.
Training. A short session with worked examples beats a long policy. Show the classification table and three realistic situations.
Exceptions. Say who can approve one, how it is recorded, and when it expires. Unrecorded exceptions are how policies quietly stop meaning anything.
Reporting. Tell people where to report a mistake, such as pasting confidential data into the wrong tool. Make it clear that reporting quickly is expected and not punished. A late report is far harder to contain.
Review. Review the policy at least annually and when a significant new category of tool appears.
What to leave out
Several things make AI policies longer without making them more useful.
Tool names and version numbers. They belong on the approved list, which can change without a policy revision.
Predictions about AI. A paragraph on how AI will transform the business ages badly and tells nobody what to do.
Rules you will not enforce. If the policy says every prompt is reviewed and nobody reviews prompts, an auditor who reads the policy and then samples practice will find a gap. Write what you actually do.
Duplicated rules. If your information security policy already covers credential handling or data classification, refer to it. Two versions of the same rule drift apart, and then staff have to guess which one applies.
A useful test: hand the draft to someone in sales or support and ask what they may and may not paste into a chat assistant. If they cannot answer in a minute, the policy needs another pass.
How it maps to ISO/IEC 42001
If you are building toward ISO/IEC 42001, an acceptable use policy supports several Annex A controls, mainly in A.2 on AI policies and A.9 on responsible use. It does not meet them alone. The Annex A explainer covers what else each area needs, and the ISO 42001 framework page summarizes the standard.
Outside ISO/IEC 42001, the same policy is evidence for the acceptable use and awareness expectations in ISO/IEC 27001 and SOC 2. Write it once, and map it to each.
How TrustLynce helps
TrustLynce's policy management provides policy templates, version history, and acceptance tracking, so you can show who acknowledged which version and when. Security training delivers the awareness session and records completion alongside it.