How to Write an AI Policy for Your Company

Why a working policy beats a comprehensive one

If you have not yet worked through the AI Readiness Checklist, start there. Item 07 on that list is "write the one-page policy before the wider rollout," and this guide is that step, done properly. The two are meant to be used together: the checklist tells you what to sort out, this guide is where you actually write it down.

Research on AI governance consistently finds the same failure mode: only a minority of organisations review AI-generated content before it goes out the door, and long, legally worded AI policies sit unread in a shared drive while staff carry on using whatever tool is fastest. A policy that fits on one page, that leads with what people are allowed to do rather than a wall of prohibitions, gets followed. A twelve-page document written to cover every hypothetical does not.

Classify your data before you write a word

Every workable AI policy rests on one decision made first: which data can go into which kind of tool. Skip this and every other section of the policy becomes a judgement call for whoever is using the tool that day.

This is the single most useful sentence in most AI policies: free, consumer-grade AI tools are not confidential by default. If a tool is free and nobody signed a contract for it, assume anything typed into it can end up used to train someone else's model. That one line, understood by every member of staff, prevents more incidents than any amount of legal drafting.

What the policy actually needs to say

Strip out the parts written mainly to cover the legal department, and a working AI policy comes down to six sections.

Where PDPA fits

Singapore's PDPC finalised advisory guidelines on generative AI and personal data on 20 July 2026, and the four obligations they set out map directly onto the sections above: a documented legal basis for personal data used with AI, accountability that survives outsourcing to a vendor, mitigation for hallucination and bias, and clear disclosure to individuals when AI is involved in processing their data. The AI Readiness Checklist guide covers these four points in full with the PDPC's own framing. The short version for the policy document itself: the sensitive data tier above is where PDPA obligations concentrate, and the approved tools list for that tier should not include a vendor until its contract addresses all four points.

The approval workflow for new tools

A policy without a process for adding new tools becomes outdated the week someone finds a better one. The workflow does not need to be elaborate for a business without a dedicated security team.

• Someone requests a new tool. A short form or even an email to the named policy owner: what the tool does, what data it would touch, why the current approved list does not cover it.
• The owner checks three things. Does the vendor train on customer data by default. Where is data processed and stored. Does the contract include a data processing agreement if it will touch internal or sensitive-tier data.
• The tool gets a tier rating, not a blanket yes or no. Most tools are fine for public-tier work immediately and need more scrutiny before they touch anything higher.
• The approved tools table gets updated and the change gets communicated. An update nobody hears about does not change what people actually do, so a table edit alone is not the finish line.

Get it signed off, not just published

The Singapore Institute of Directors' AI Guide for Boards, published in July 2026, argues that AI oversight is now a director-level responsibility rather than something delegated wholesale to IT. That does not mean a small business needs a board meeting to approve a one-page policy. It means the policy should have a named senior owner, and for businesses with any kind of board or advisory group, the policy is worth a five-minute agenda item: here is what we have written, here is who owns it, here is when it gets reviewed. That single step is what turns a document into a governed decision.

The one-page template

Fill in the fields below and the policy on the right updates as you type. Leave anything blank and it stays as a bracketed placeholder, so you can fill in the gaps later. When it looks right, copy the text or download it as a plain text file to paste into your own document.

How to launch it so people actually read it

The policy itself is the easy part. Getting it read and followed is where most of these documents quietly fail. Three things make the difference.

Lead with what is allowed, not what is banned. A briefing that opens with a list of prohibitions gets tuned out. One that opens with "here is what you can now use, and here is how" gets attention.

Keep the briefing to thirty minutes, cover two or three realistic grey-area examples specific to your business, and leave time for questions. A policy staff have never had explained to them out loud is a policy they will not follow under pressure.

Launch the policy and the tool access at the same time. If the approved tools are not actually available to staff the day the policy goes out, the gap gets filled with whatever unapproved tool is fastest, and the policy loses credibility from day one.

Once the policy is written, signed off, and launched, the loop back to the AI Readiness Checklist closes: item 01 was the inventory of what is already running, and this document is what governs everything that gets added to it from here. If your organisation is somewhere in the middle of this process and wants a second opinion before it goes to leadership, ScaleASEAN's fractional CTO and technology advisory work covers exactly this kind of review.