Home › Blog › Internal AI usage policy

Writing an internal AI usage policy — a section-by-section guide

Internal AI policies usually fail not because there is no policy but because the policy never says what may be entered. Once that judgement falls to individuals, the policy exists only as a document.

4 required sections Data class table Shadow AI

The short answer

The section most often missing is the data classification. "Do not enter sensitive information" is not a rule, it is a hope. Unless what counts as sensitive is written out as classes, nobody on the floor can apply it.

The second most often missing is what happens after a violation — meaning the reporting route, not the punishment. Whether an employee who pasted customer data by mistake quietly moves on or reports it immediately depends entirely on whether the policy says what happens when they do.

Section 1 — Data classes (write this first)

Class	Examples	Entering into AI tools
Public	Press releases, published product information, company registration number	Any approved tool
Internal	Process documents, meeting notes, non-public schedules	Approved work accounts only
Confidential	Contract terms, pricing policy, unannounced strategy	Only tools with training use disabled, plus manager approval
Personal data	Names, contact details, national ID, health information	Prohibited as a rule. If required, de-identify first and confirm the processing agreement
Regulated	Financial, medical and other separately regulated data	Prohibited. No exceptions without legal and compliance review

Section 2 — The approved tool list

Keep it as a list — "Use safe tools" is not a policy. Maintain a table: tool name, permitted data classes, who pays, owning team.

Address personal accounts explicitly — This is the most common incident route. The same tool has different data terms on a personal account. Write down "approved tools, company accounts only".

Create a request route — If there is nowhere to ask for a new tool, people will not ask — they will just use it. A policy without a request route is what manufactures shadow AI.

Re-review on a schedule — Vendor data policies change. Put a six- or twelve-month cycle for re-confirming training use and retention into the policy itself.

Section 3 — Prohibited actions (short, specific)

Processing company data in an unapproved tool — Prohibited regardless of class. The criterion is approval, not the tool.

Sending AI output externally without verification — Customer replies, contracts, official documents. Name who verifies.

Using unsourced figures or quotations — Applies to external documents and internal reporting alike. A number AI produced is not a number until it is checked.

Concealing that AI was used — Where a colleague or customer needs that context. For customer-facing services, a separate disclosure review applies.

Entering other people’s personal data — Entry beyond the scope of consent. CVs, customer enquiries and staff evaluations are the common cases.

Section 4 — After a violation (reporting route before punishment)

The purpose of a policy is not to eliminate incidents but to hear about them quickly. So write the reporting route first: to whom, in what form, within how long.

Then the immediate steps: whether a deletion request is possible, whether the session must be preserved for root-cause work, and who assesses the blast radius. Without those three, a report arrives and nothing can be done with it.

Sanctions come last, and it is worth distinguishing intent from mistake. A policy that treats a mistake like intent lowers the reporting rate — and the unreported incident is the expensive one.

Two things that make a policy actually work

First, establish what is already being used before publishing anything. Expense records and SSO logs will show most of it. A policy that contradicts reality is ignored from day one.

Second, fill the class table with examples from your actual work. "Our internal rate card" drives a decision in a way that the word "confidential" does not. Collect one or two examples per team and the policy starts getting read.

Frequently asked questions

How long should the policy be?

Structure matters more than length. What people consult in the moment is two pages: the class table and the approved tool list. Keep everything else as reference and those two always current.

How do we stop personal account use?

You largely cannot. Providing company accounts first is the realistic move. If the approved tool is awkward and the personal account is convenient, convenience wins. Offering an alternative beats prohibiting.

We have already had an incident. Where do we start?

Confirm with the vendor whether the entered data can be deleted and how long it is retained, and document the blast radius. If personal data was involved, notification obligations need review. Policy revision comes after that.

How do we detect violations at all?

Only in tools that have audit logs. Which is why putting audit-log support into the approval criteria is what decides whether the policy has any teeth.

Organisational readiness

Current state before policy

The AX readiness assessment scores named ownership, policy and budget together on the organisation axis, showing whether the missing policy is the problem or a symptom.

Check readiness