Writing a company AI usage policy
Your team already uses AI. Here is how to write a policy that enables safe use — data classes, approved tools and human sign-off — instead of a ban list.
Someone in marketing had a proposal due Friday evening, so they pasted the client's product list, contact details and last year's discount notes into a free chat assistant. The copy was good, the proposal went out on time, nobody noticed. Two weeks later, on the renewal call, that client asked which systems their data was processed in — and nobody could answer.
This piece is about the document that closes that gap. The goal is not to stop people using AI; it is to write down, plainly enough that anyone remembers it, which data goes into which tool with whose approval. Below: scope, data classes, approved tools, sign-off thresholds, verification, copyright, disclosure, shadow AI and what happens after a mistake — plus a one-page skeleton.
What a policy fixes, and what it doesn't
A good AI usage policy does not say "don't use AI." Your team already does — the app on their phone, a browser extension, the assistant that tidies their email drafts. The policy's job is to make that use visible, draw a line where the risk sits, and put people at ease everywhere else. Ban lists go unread, and even when read they go unenforced; they only push usage out of sight.
Scope answers three questions. Who it binds: staff, interns, contractors, agencies and vendors with system access. Which tools: chat assistants, the AI features inside your CRM, coding assistants, image and voice generators, meeting-note bots. Which work: customer-facing copy, internal documents, analysis, code, design, hiring. Skip one and every clause below becomes arguable.
The policy is also a promise the company makes: proper accounts, real training, a stated answer for when something goes wrong. A one-sided list of obligations builds no trust.
Data classification is the backbone
Spend most of your drafting time here, because the question in an employee's head is never abstract — it is "can I put this into the tool?" Four buckets answer that better than three paragraphs of prose. Name them however you like; each just needs a single-sentence rule.
| Data class | Examples | Rule inside an AI tool |
|---|---|---|
| Public | Website copy, published brochures, press releases | Free to use, no approval needed |
| Internal | Process docs, internal decks, meeting summaries | Allowed in approved corporate accounts only |
| Confidential | Contracts, pricing strategy, source code, financials | Manager sign-off; requires a configuration that excludes your data from training |
| Personal data | Names, phone numbers, emails, addresses, sensitive categories | Never raw; mask or anonymize first |
Classification moves the debate down a level. "Is AI dangerous?" is a question nobody settles. "Which bucket is this document in?" is one an employee settles in ten seconds.
An approved tool list and a route for new ones
Keep a living one-page list beside the policy: tool name, what it is approved for, the highest data class allowed, who owns the corporate account, when the contract renews. Do not bury it inside the policy — tools change faster than policies, and kept separate you can update it without re-approving the whole text.
The second piece matters more: a request route for new tools. Someone who finds a tool that helps and has nowhere to take it will use it quietly. Keep the form short — what job, what data class, any alternative, where the provider processes data — and commit to a response time. A process that doesn't answer within a few working days is not a process.
Include the AI features already sitting inside your CRM. If the data lives there anyway, doing the work in place — asking your CRM questions in plain language, or capturing documents and business cards instead of typing them in — beats moving records outside.
Working with customer and personal data
The logic here is genuinely simple: use the least data that does the job, don't repurpose it, and strip identity when identity isn't needed. Summarizing a complaint does not require a name, a phone number and an invoice reference in the prompt. "An enterprise account is writing for the third time about a delayed delivery" does the same work and identifies nobody.
Put three concrete rules in writing: customer contact data is never pasted into general-purpose tools; sensitive categories such as health, biometric, belief or criminal-record data never go into an AI tool at all; recordings and transcripts are processed only with the customer's knowledge. We cover the wider frame in AI and customer data, and lawful collection and deletion in the data-protection-compliant CRM guide.
One caution: data protection and AI rules differ by country and are moving quickly. This is a general frame, not legal advice — have your own counsel read the final draft and confirm where your obligations stand.
Owning the output: what needs a human
The most useful sentence in the policy is this: the person who uses the output owns it. The model drafts; a human signs. Don't leave that as a principle — list the work that cannot move without review.
- Anything a customer reads: proposals, contract annexes, apology notes and bulk email get read end to end by their owner before they go out.
- Prices, discounts and terms: AI may do the arithmetic, but an authorized person approves the number; no unapproved figure reaches a customer.
- Legal and financial content: contract clauses, formal notices and tax interpretations are never used as generated; they pass through the relevant expert.
- Code and automation: generated code is reviewed and tested rather than shipped straight to production, and suggested libraries get a license check.
- People decisions: screening, reviews and disciplinary steps cannot rest on model output; at most it summarizes.
Verification is a rule, not a hope
Language models can be confidently wrong, and an invented regulation reads with the same assurance as a real one. So write an executable reflex into the policy, not a wish like "make sure it's accurate."
The two-minute check
Make it this: no name, date, figure, legal reference or quotation leaves the building until it is confirmed at the source. Open the link the model gave you; one that doesn't open counts as nonexistent. For answers grounded in your own material, attach that material and say "use only the document I gave you" — one sentence that noticeably cuts invention. We walk through the failure modes in recognizing hallucinations and verifying AI output.
Intellectual property, copyright and disclosure
The IP section looks both ways. Inward: nobody uploads someone else's copyrighted text, image or code to generate derivatives, and images imitating a recognizable brand style or character stay out of commercial work. Outward: the legal status of generated material varies by jurisdiction, so don't rest a logo or wordmark on fully generated output.
Set a quality threshold for anything published: raw output does not ship, a person enriches and checks it. We covered how search engines read this in AI-generated content and where Google stands.
When you have to say AI was involved
Disclosure needs a workable line between "declare it everywhere" and "never mention it." A usable test: would the other person behave differently if they knew? For an email drafted with an assistant, no. For a recorded call, a bot speaking on your behalf, or a model taking part in an evaluation decision, yes — and there it is required.
A policy is measured not by how many things it forbids, but by how many people think to check it before they act.
Internal transparency counts as much. People should know where AI sits in processes that affect them — hiring, performance, work allocation.
Bring shadow AI into a channel instead of banning it
Unapproved tool use is rarely a discipline problem; it is usually a design problem. People find the faster way to do their job, and without an official one they use their own. A ban doesn't remove the usage — it makes it invisible and moves your most sensitive data into your least governed tool. We take that apart in shadow AI at work.
The security side
Three items close most of the exposure. Corporate accounts: anything opened with a personal email walks out the door with the employee. Access management: single sign-on, roles, and revoking a leaver's access the same day. Records: a periodic check of which team uses which tool, and whether sharing settings are switched off.
Training, incidents and keeping the policy alive
Emailing the document and collecting an "I have read it" checkbox is not training. An hour of hands-on work beats it, using three examples from the team's real week: a proposal draft, a complaint summary, a comment on a report. Cover prompt basics in the same session; if people don't know how to ask, quality drops and trust goes with it. Prompt writing for salespeople gives you a ready structure.
Write the incident clause to correct, not to punish. When someone realizes they pasted a confidential document into the wrong tool, every hour of frightened silence makes it worse. Say it plainly: report the same day and there is no sanction, we contain the damage together. Deliberate and repeated breaches are a separate heading under the normal disciplinary route.
Set a review rhythm: the tool list quarterly, the policy text twice a year. Name an owner; a document nobody owns goes stale. For how the regulatory frame is maturing, AI governance and the EU AI Act is a good starting point.
A one-page policy skeleton
These headings are enough for a document that never runs past one page. Give each three sentences at most; keep annexes in separate files.
- Purpose and scope: why the policy exists, who it binds, which tools it covers.
- Core principle: AI assists; the person using the output is accountable for it.
- Data classes and rules: four buckets, one sentence of permission each.
- Approved tools and requests: a link to the list, the request form, the response time.
- Work that needs sign-off: customer copy, commercial terms, legal and financial content, code, hiring.
- Verification: names, dates, figures and sources confirmed before anything ships.
- Copyright and disclosure: third-party material, use of generated work, the disclosure threshold.
- Security: corporate accounts, access control, the leaver rule.
- Incidents and support: where and how fast to report; the corrective stance.
- Owner and review: responsible person, version number, next review date.
Common mistakes
The most frequent is drafting the policy like a legal instrument: twelve pages, a definitions section, nobody reading it. Second, burying the tool list in the body so it can never be updated. Third, saying "be careful" without naming the work that needs sign-off — that changes no behavior. Fourth, framing incidents as offenses, which kills reporting. Fifth, writing it once and never opening it again while tools, terms and regulations move on.
A policy is not a wall of prohibitions; it is the handrail your team holds while moving fast. For it to hold, the place where AI touches customer data has to be orderly too — when conversations, proposals, tasks and reports live in one system, tracing which data went where is straightforward. If you want a foundation to build your rules on, create a free Rocketly account and bring your team's AI use inside a structure you can see.