How to Write an AI Use Policy for a Singapore SME With Fewer Than 20 Staff

An AI use policy for a Singapore SME with fewer than 20 staff should be one page, and it needs seven things: a named list of approved tools, a red list of data that may never be pasted into them, a human-review rule for anything that leaves the company, a single approver for new tools, a disclosure rule for client work, the consequence for breaking it, and a review date. That is the whole document. You do not need a governance committee, an external counsel review, or a 30-page framework borrowed from a bank. You need something short enough that every staff member actually reads it, and specific enough that it answers the real question your team is asking right now, which is simply: am I allowed to put this in the chatbot?

Why does a 15-person company need a written AI policy at all?

Because the unwritten policy is already in force, and you did not choose it. Your sales person is drafting proposals in a consumer chatbot on a personal account. Your ops coordinator is summarising a customer complaint thread that contains a full name, a mobile number and an address. Your bookkeeper is asking an AI tool to explain a CPF calculation and has pasted the payroll table in to make the question clearer. None of these people are being reckless. They are being efficient, in the absence of instruction.

The exposure is not theoretical. Under the PDPA, your organisation remains responsible for personal data it controls, including the obligation to make reasonable security arrangements and, where data moves out of Singapore, to ensure a comparable standard of protection. A staff member pasting a customer list into a free consumer tool on a personal login is a disclosure you cannot describe, cannot log, and cannot undo. If the PDPC ever asks what controls you had in place, the answer cannot be that you assumed everyone knew better.

There is a second, duller reason. A written policy converts an argument into a lookup. Without one, every new tool becomes a debate, every incident becomes a judgement call about intent, and you — the owner — become the bottleneck for a question that arises four times a week. The policy exists so the decision happens without you.

What should the policy actually say?

Seven clauses. Write them in plain English, not legal English.

1. Approved tools. Name them. Not categories — specific products, on specific plans, accessed through the company Google Workspace or Microsoft 365 login. Personal accounts are not approved, even for an approved product. This distinction matters more than the product choice: business and enterprise tiers generally carry different data-handling terms from consumer tiers, and your admin can see and revoke a company account.
2. Red-list data. Never into any AI tool, approved or not: NRIC and FIN numbers, payroll and CPF figures tied to a named person, bank and payment details, medical or MC information, anything under a client NDA, unreleased pricing, and credentials of any kind.
3. Amber data. Permitted once de-identified. A customer complaint becomes usable when the name, number and account reference come out. Teach the redaction habit, because it is the clause staff will use daily.
4. Human review. No AI output reaches a customer, a regulator, a statutory filing or your accounts without a named person reading it first. Name the person per output type, not in general.
5. Client disclosure. State when you tell a client AI was used in their deliverable. Some clients — particularly government-linked and MNC buyers — now ask contractually. Decide your answer before the tender asks.
6. New tool approval. One approver, 48-hour turnaround. The time limit is the point: a slow approval process guarantees people route around it.
7. Consequence and review date. Say what happens on a breach, and set a date to revisit the tool list. Six months is realistic; the market moves faster than your policy will.

Which tasks are safe to hand over, and which are not?

Safe, with redaction and review: internal first drafts, reformatting and tidying, summarising documents that are already public, translating marketing copy, explaining a regulation in plain language, generating test data, writing code comments, and turning your own meeting notes into actions.

Not safe, regardless of how good the tool is: anything that makes or shapes a determination about a specific person. Hiring shortlists sit squarely here. From 1 January 2027, the Workplace Fairness Act regime expects hiring decisions that can be explained and defended; a shortlist produced by a tool whose reasoning you cannot reconstruct is a liability wearing the costume of a productivity gain. The same logic applies to credit terms, disciplinary matters, final quotations, and PDPA access-request responses. Use AI to prepare the material a human decides on. Do not use it to make the decision.

How do you enforce this without an IT department?

Four controls, all available inside Google Workspace or Microsoft 365, and all configurable in an afternoon.

• Single sign-on only. If a tool cannot be accessed through the company identity, it is not an approved tool. This gives you one place to revoke access when someone leaves.
• Audit your connected apps. In your admin console, review which third-party applications hold OAuth access to company Drive and mail. Most SMEs find grants nobody remembers approving, some from staff who left in 2024.
• Managed browser profiles. You can log or block consumer AI domains on company devices. Logging alone is usually enough — the visibility changes behaviour faster than the block does.
• A ten-minute quarterly check. Put it in the calendar now. Review connected apps, confirm the approved list is still accurate, and confirm departed staff are actually gone.

Enforcement also depends on something no console provides: an amnesty. When you roll this out, state explicitly that nobody will be penalised for telling you what they have already been using. You want the inventory more than you want the accountability. You will not get both.

What does a realistic five-day rollout look like?

Day 1 — Ask, do not audit. One question to every staff member: which AI tools have you used for work in the last month, and for what? Expect three to six tools you did not know about.

Day 2 — Choose. Pick one general assistant on a business plan, plus any role-specific tools that earn their keep. Fewer tools means a shorter policy and a smaller attack surface.

Day 3 — Write the page. Seven clauses. If it runs past one page, you are writing for a lawyer instead of your team.

Day 4 — Brief and sign. Fifteen minutes, everyone in the room, two worked examples of a red-list mistake and its redacted version. Acknowledgement in writing, filed with HR records.

Day 5 — Configure and diarise. SSO, connected-app audit, browser logging, review date in the calendar.

Done properly, this costs you under six hours and removes a category of risk that scales with every new hire. It also does something less obvious: it makes AI adoption defensible. The company with a written policy can say yes to new tools quickly, because it knows where the line is. The company without one eventually says no to everything, after the first incident.

Frequently asked questions

Does a company with 12 staff legally need an AI use policy?

No Singapore law names an AI use policy as a required document. However, the PDPA requires reasonable security arrangements for personal data in your control, and the PDPC and IMDA governance frameworks treat documented internal controls as evidence of that reasonableness. A written policy is not the obligation — it is how you demonstrate you met one.

Can we just ban AI tools instead?

You can declare a ban, but you cannot enforce one. Staff have AI on their phones, in their browsers, and increasingly inside software you already pay for. A ban converts visible usage into invisible usage on personal accounts, which is strictly worse for PDPA exposure than approved usage inside your tenant.

Is the paid business tier of an AI tool actually safer than the free one?

Usually, but verify rather than assume. Check the specific plan's terms on whether inputs are used for model training, where data is processed, what retention applies, and whether an administrator can audit and revoke access. The audit and revocation capability is often the bigger practical gain, because it is what lets you answer questions after an incident.