Preparing a Company AI Usage Policy

Companies flailing between two extremes: in one, "AI is forbidden" (the employees use it in secret); in the other, "everyone as they see fit" (where the customer data goes, nobody knows). Neither is a policy; the first is denial, the second chaos. A policy is the gate in the middle: to what, how, on which condition.

An AI policy is not an intimidation document; it is a working document: it gives the team speed (usage rises when what is permitted is known) and protects the company (privacy, quality, legal). This article gives the document's structure section by section; at a level a small company can write in one day.

Before the policy: three decisions

• The stance: what is your relationship to AI? (The "we use it actively, with rules" stance is the competitive standard in 2026; the document should open with that sentence.)
• The permitted tools: which tools, which account types (the data difference of personal vs business plans is decisive here).
• Ownership: who owns the document (the updates, questions, exceptions)? An ownerless policy is stale paper within six months.

The document's structure: 8 sections

Filling the key sections

The data rules (section 3) are the document's heart, and the lists from the security article get formalised here: red (never: passwords, personal data combinations, commercial secrets), grey (only on permitted business accounts: internal documents, code) and green (freely: public information, anonymised structures). The review rule (section 5), meanwhile, is the quality gate; the principle is risk-proportionate: an internal draft → own responsibility; text going to a customer → an editor; a legal/financial document → a specialist; code → review+tests. Transparency (section 6) is the little-written, much-disputed section; the simple rule: an honest answer when the customer asks + a declaration on fully automated decisions (if any exist).

Rollout: from document to habit

The graveyard of policies is the "written, sent, forgotten" folder. A working rollout is four steps: a half-hour introduction conversation (talking, not making people read the document; the questions come out of it), an examples booklet (5–6 real scenarios: "may I have a customer email edited? yes, like this"; it teaches more strongly than the rule), the new-hire pack (in the first-day document set) and a quarterly 15-minute review (what changed, which new tool, which questions accumulated). There is one cultural key too: the reaction to the first violation. Stage a punishment theatre, and you will never hear of the second violation; a fix + a rule clarification, meanwhile, teaches the system.

The shortcut for a small company

A five-person team does not need a 12-page corporate document; the one-page version (the stance sentence + the tool list + the three-colour data rule + the review table + the incident sentence) works fully. The sections expand as you grow. What matters is not the paper's size but two questions having answers: does an employee find the answer to "may I do this?" in 10 seconds, and is the road known in the "something went wrong" case. If those two exist, you have a policy.

Sources and further reading

Where to verify the source

The primary sources for the frameworks and standards:

• The NIST AI Risk Management Framework: the governance language
• OECD.AI: the principles and policy examples

Continuing the topic

The policy's practical neighbours:

• AI security: the individual layer
• The business AI roadmap
• Protecting personal data
• The AI text-checking reality
• Other articles on this topic

This week's one hour: write the one-page version and walk it through with the team over tea. The perfect policy is next quarter's work; the working policy, this week's.