How to write a one-page internal AI use policy your team will follow

An internal AI use policy tells your staff which AI tools they may use, what data they may put into them, and what they must disclose when AI helped produce their work. For most mid-sized organisations, a single page is enough, and a single page is far more likely to be read, remembered and followed than a twenty-page compliance document. This guide walks through what to allow, what to ban, what to log, and how to keep the whole thing short enough to pin to a wall.

Why does a mid-sized organisation need an AI policy at all?

Because your staff are already using AI, whether you have a policy or not. Assistants are built into browsers, office suites, design tools and phones. The question is not whether AI touches your work; it is whether it does so under rules you chose or rules you drifted into.

Without a policy, three predictable problems appear. First, sensitive data leaks quietly: a well-meaning employee pastes a client contract or a patient note into a free chatbot to summarise it, and that content has now left your control. Second, quality drifts: AI-drafted text goes out unreviewed, with errors nobody owns. Third, an uneven culture forms, where some teams use AI openly, others hide it, and nobody can say what the organisation's actual position is.

A written policy fixes the accountability gap. It does not need to be perfect; it needs to exist, name an owner, and be short enough that everyone has genuinely read it.

What should the policy allow, ban and log?

Structure the core of the page as three lists: allowed, banned, logged.

Allow a short list of approved tools, named explicitly, each on an organisational account rather than personal sign-ups. Organisational plans typically offer admin controls, audit visibility and contractual terms about how your data is handled, none of which you get when staff sign up with personal emails. State what these tools may be used for in plain terms: drafting, summarising internal documents, writing and reviewing code, brainstorming, translation and similar assistive work.

Ban a small number of things clearly and absolutely. Typical entries: entering confidential or personal data into unapproved tools; using AI to make final decisions about people, such as hiring, discipline or credit, without human review; presenting AI output as the work of a named expert without that expert's review; and using AI tools through personal accounts for company work. A short ban list with no exceptions is easier to follow than a long one with footnotes.

Log the things you will want to reconstruct later. Keep a living register of which tools are approved and who approved them, record when AI is used in high-stakes deliverables such as legal, financial or client-facing documents, and keep vendor review notes. You are not building surveillance; you are building the ability to answer "which tools were we using, and under what terms?" when a client, regulator or insurer asks.

How should you classify data for AI tools?

AI risk is, in practice, mostly data risk. The strongest move in the whole policy is to tie AI rules to data classes rather than to individual products, because tools change constantly and your data categories do not.

Three or four tiers are plenty for a mid-sized organisation. Label them in words your staff already use, define each with examples from your own business, and give each tier one clear rule about AI.

Canadian organisations should keep PIPEDA, and provincial laws such as BC's PIPA, in view here: personal information carries obligations that do not disappear because a tool is convenient. If you handle health, financial or public-sector data, the restricted tier is where your legal advisors should spend their time.

How do you review an AI vendor before approving it?

You do not need a procurement department to do useful vendor review. A one-hour check against a fixed list of questions, recorded in a shared document, covers the questions that actually matter.

Ask five things of every tool. Where does the data go, and in which country is it stored? Is your input used to train the vendor's models, and can that be switched off contractually? Can you get an organisational agreement with admin controls, rather than a consumer licence? What happens to your data when you leave? And does the vendor publish security practices you can point to, such as recognised certifications or independent audits?

Give each reviewed tool a simple verdict: approved, approved with conditions, or declined, with one sentence of reasoning. Date the entry. When the vendor ships a major change, review again. This register is also your answer to the shadow-IT problem: when someone asks for a new tool, they submit it for the same one-hour review instead of just using it. A fast yes-or-no process is what stops people quietly working around you.

A policy nobody can recite is a policy nobody is following. If it does not fit on one page, it is not done yet.

What should your disclosure norms look like?

Disclosure is where many policies get the tone wrong. If admitting AI use feels like confessing to a shortcut, staff will stop admitting it, and you will lose visibility precisely where you need it most.

Set two plain norms instead. Internally, people say when AI drafted or heavily shaped a piece of work, in the same casual way they would say a template was used. Externally, a human is accountable for everything that leaves the organisation: AI can draft, but a named person reviews, corrects and signs off. For client deliverables, decide in advance whether and how you tell clients that AI is part of your process, and put that position in writing so nobody improvises it under pressure.

Pair disclosure with a verification habit: AI systems state falsehoods fluently, so anything factual, legal, numerical or medical gets checked against a source before it ships. The rule is easy to remember: AI can write the first draft, but it never gets the last word.

How do you train staff and keep the policy alive?

A policy launch is thirty minutes, not a course. Walk through the one page, show the data tiers with real examples from your own organisation, demonstrate one approved tool doing genuinely useful work, and show the request path for new tools. People follow rules faster when the same session shows them something they want to use.

Then keep it alive with three habits. Name a single policy owner with authority to approve tools and answer questions within a day or two, because unanswered questions become workarounds. Revisit the policy on a fixed schedule, quarterly is reasonable at the current pace of change, and treat each revision as a normal update rather than an event. And invite staff to report near-misses without blame: the person who says "I almost pasted a client file into the wrong tool" has just improved your policy for free.

Resist the urge to let the page grow. Every incident will tempt you to add a paragraph. Prefer editing an existing line over adding a new one, and move genuinely rare cases into the owner's judgement rather than the document.

How OlDevs can help

OlDevs is a full-stack technology studio in Vancouver, working with organisations across Canada since 2014. We build AI systems for a living, from LLM-powered assistants to automation and agents through our AI development practice, so we have strong opinions about where AI genuinely helps and where guardrails matter. That perspective shapes how we help clients draft usable AI policies, select and configure tools on proper organisational terms, and build internal systems with security and compliance designed in from the start rather than bolted on.

We work as one accountable team, show a working demo every week, and our clients own all code, designs, accounts and IP. If your organisation is ready to put AI on a sound footing, from a one-page policy to the systems behind it, read about how we work and then request a quote. We reply to every enquiry within one business day.