"Use AI Responsibly" Is Not a Policy. It's a Sentence.
It cannot be enforced against an employee, it does not answer a customer's security questionnaire, and it demonstrates nothing to a regulator. The clauses that do all three are specific, short, and organised around data rather than around tools.
The Policy Serves Three Different Audiences
Most drafts fail because they are written for one reader and then asked to satisfy three. The three want different things from the same document, and knowing which clause serves which reader is what keeps the policy short.
Structure It Around Data Tiers
A tool-based policy answers the question "may I use X?" — which is the wrong question, because the answer depends entirely on what goes into X. A data-tier policy answers "may this information go into an AI tool, and which kind?", which is the question people actually face and which does not change when a new vendor appears.
- Credentials, API keys, private keys and access tokens
- Regulated personal data: health records, financial account numbers, government identifiers, biometric identifiers, data about minors
- Information under a third-party confidentiality obligation that you have not confirmed permits AI processing
- Anything under legal hold, in active litigation, or subject to a regulatory inquiry
- Customer personal data and customer content, where the tool appears on your published subprocessor list
- Proprietary source code and system architecture detail
- Unreleased financial figures, pricing strategy and roadmap material
- Personnel records and anything relating to an identified employee
- Requirement: company tenant, company account, never a personal login
- Published material, marketing copy and public documentation
- General research, drafting and summarisation with no company-specific detail
- Anonymised or synthetic examples that cannot be re-identified
- Code from public repositories under permissive licences
- The person who ships the output owns it; 'the model wrote it' is not an explanation
- Output used in customer-facing, legal, financial or safety contexts requires human verification of facts and citations
- Enabling an AI feature inside existing software counts as adopting a tool and requires the same check
- Anything that looks like an AI incident gets reported through the incident channel, not fixed quietly
The Request Path Is the Load-Bearing Part
Every policy has a section nobody reads and one that determines whether the whole thing works. Here it is the request path, and it fails in a predictable way: no named owner, no stated turnaround, and a review process heavy enough that asking costs more than proceeding quietly.
What makes it work is proportionality. A tool that will only ever see Tier 3 material does not need the review a customer-data processor needs, and treating them identically guarantees the queue backs up. Publish a stated turnaround, keep a lightweight lane for low-tier tools, and reserve full vendor assessment for anything that will touch Tier 2. A programme that says yes reasonably often is the only kind that produces an accurate picture of what is actually in use.
Where Policies Overreach
Enthusiastic first drafts routinely include provisions that create their own exposure. Four to watch for:
- Sweeping confidentiality language. A clause barring discussion of "any company information" with external systems can be read as restricting employees' protected right to discuss pay and working conditions. Carve that out explicitly.
- Monitoring that outruns notice. If you inspect prompts, extensions or endpoint activity, say so plainly, and check the notice and consent requirements in every jurisdiction where staff sit. Retroactive discovery of monitoring is its own incident.
- Personal-device and personal-time reach. A rule about what someone may do with your data is defensible. A rule about what they may do with their own tools on their own time generally is not, and blurring the two weakens the enforceable part.
- Assuming output ownership. Whether generated material is protectable, and on what terms the provider grants rights in it, is governed by copyright doctrine and the vendor's terms — not by a sentence in your handbook asserting the company owns everything.
Making It Provably Real
The difference between a policy and a document is a small set of records, each of which gets requested during enterprise security review:
- Dated acknowledgements from every employee, with re-acknowledgement on material change and on hire.
- Training with completion records — short and example-driven beats comprehensive and unwatched.
- A maintained approved list with dates, an owner and the data tier each tool is cleared for.
- A request log showing decisions and turnaround times, which is the fastest way to demonstrate the process is not theatre.
- A review cadence with a named owner, because a policy last touched two model generations ago reads as abandoned.
Frequently Asked Questions
Why do most AI acceptable use policies fail?
Two structural mistakes. First, they enumerate tools, which means the policy is stale within a quarter and silent about the tool someone actually used. Second, they prohibit without providing an approved alternative, which relocates the behaviour rather than stopping it — people still have the work to do. A policy organised around data categories with a functioning request path addresses both, because data categories are stable and an approved route removes the incentive to route around the rule.
Should the policy list approved tools or prohibited data?
Both, but they belong in different documents with different change cadences. The policy states the data rules and the accountability rules and changes rarely, so it can go through proper review and acknowledgement. The approved tool list is an operational artefact maintained by a named owner and updated continuously. Merging them means either the policy is perpetually out of date or you are re-running an approval process every time a vendor is added.
Can we require employees to disclose when they used AI?
You can, but a blanket disclosure requirement on all work product is widely ignored and therefore worse than useless as evidence of a control. Scope it to where disclosure has a purpose: material that goes to a customer or the public, anything entering a legal or financial process, code merged into production, and content where a regulator or contract requires provenance. Narrow requirements get followed; universal ones train people to treat the policy as decorative.
Can an AI policy be too broad to enforce?
Yes, and the risk is underappreciated. Workplace rules that a reasonable employee would read as restricting discussion of pay, working conditions or terms of employment can be challenged as overbroad regardless of intent — and AI policies stray into this when they prohibit discussing company matters with any external system, or when monitoring provisions sweep in protected concerted activity. Carve out protected discussion explicitly and have employment counsel read the monitoring section.
How does an AI policy interact with customer contracts?
It is increasingly the artefact that proves a contractual commitment. Enterprise agreements and security questionnaires now ask whether you have an internal AI use policy, whether employees are trained on it, and whether customer data may be processed by AI tools. Your answer has to match both the policy text and your actual approved tool list, because a reviewer who finds a tool in your subprocessor list that the policy would have prohibited has found a real inconsistency.
Do we need employees to formally acknowledge the policy?
Yes, with a dated record and a re-acknowledgement whenever it materially changes. Enforcement against an employee generally requires showing they were told, and a policy sitting in a wiki nobody was pointed to is weak evidence. The acknowledgement record is also what a customer security reviewer or a regulator asks for when they want to know whether the policy is real, which makes it one of the highest-value low-effort items in the whole programme.
How long should the policy be?
Short enough that the data tiers fit on one screen. The failure mode of a long policy is not that it is wrong but that nobody consults it at the moment of decision, which is the only moment that matters. Put the tier table and the request link at the top, move the rationale and the definitions to the end or to a linked page, and resist the urge to restate your general confidentiality policy inside it.
Does a contractor or agency need to be covered too?
Yes, and this is a common gap. Contractors, agencies and outsourced development teams frequently sit outside your device management and your acknowledgement system while handling exactly the data your policy is designed to protect. The mechanism differs — a contractual flow-down rather than an employment policy — but the substance should match, and the flow-down should reach subcontractors rather than stopping at the firm you signed with.
Write the Tier Table First
If you only produce one artefact this quarter, make it the three-tier data table with a named owner and a request link at the top. It is the part employees will actually read at the moment they need it, the part a security reviewer will ask to see, and the part that stays correct when the tool landscape shifts again next quarter.
The rationale, the monitoring section and the enforcement ladder can follow. None of them work without the tier table, and the tier table does a surprising amount of work on its own.