What Actually Belongs in Your Company AI Policy

Most corporate AI policies are either a ban nobody obeys or a values statement nobody can apply. Meanwhile employees paste customer data into whatever tool answered fastest. A working policy is short, specific and enforceable. Six sections cover it.

1. The approved-tools list, with a fast lane

Name the tools, the accounts (business tier, not personal), and who approves additions — with a 48-hour SLA on requests. Shadow AI use is a function of how slow the official path is; make approval faster than sneaking and the shadow economy dries up. Review quarterly: the tool landscape turns over fast enough that January's list is stale by June.

2. Data rules by classification, not vibes

Tie AI use to the data classes you already have. Public data: any approved tool. Internal: approved tools with training-opt-out confirmed. Customer PII: only tools under DPA, and list them by name. Regulated data: named tools, named use cases, named owners — or nothing. One table, printable, no ambiguity about the difference between "our marketing copy" and "our customer list".

3. Disclosure lines

Where AI output reaches customers, decide once: support replies (disclosed or reviewed), marketing content (reviewed, no disclosure needed in most markets), contracts and legal text (human-owned, always). Under the EU AI Act, chatbots must be identifiable as AI — write that down so nobody relitigates it per project.

4. Human sign-off for consequential decisions

Hiring screens, credit terms, account terminations, anything with legal effect: name the checkpoint and the accountable role. Not because models are bad at these — because you are accountable for them, and "the system decided" is not a defence you want to test, legally or reputationally.

5. Procurement hooks

New AI tools go through a lightweight review: training-data terms, data residency, deletion handling, EU AI Act role (provider vs deployer). One page, filled by the vendor, filed. This is where policy meets the real world of credit-card SaaS — see our vendor questions list for the long form.

6. Incident path

Wrong AI output reached a customer; someone pasted the wrong data somewhere; a tool leaked. Who is told, within what time, and what gets logged. Treat it like security incidents: blameless reporting, fast containment, written learning. A policy without an incident path is a document that ends careers instead of preventing repeats.

Keep it to three pages

Everything else — ethics principles, future ambitions, model cards — lives elsewhere. The policy is the part people must follow, and people follow what they can remember. Publish it, train against it once, and enforce the approved-tools list; the rest mostly enforces itself.

We draft these alongside AI readiness work — usually in a week, usually replacing something four times longer that nobody had read.