AI use policy template for staff: one page for Singapore SMEs

An AI use policy template for staff can fit on one page if it settles eight things: which AI tools staff may use, what data they may enter, how prompts and outputs are treated, who checks the result, what customers are told, how long anything is kept, who hears about a mistake, and when the page is next reviewed. The eight clauses below are written to be copied, filled in and handed to the team.

The template leans on PDPC’s Advisory Guidelines on Use of Personal Data in Generative AI, issued on 20 July 2026. For organisations that deploy generative AI, they say to track prompts and outputs as new data sources and educate end users on which personal data they may enter (paragraph 9.3), and they encourage clear written policies (paragraph 9.4). In our reading, a business whose staff use an AI assistant at work is such a deployer. The guidelines are advisory and the PDPA prevails over them (paragraph 1.5), so this page is a starting point, not proof of compliance.

This page is the document you hand to staff. For what the guidelines require and when, see our explainer on PDPC’s generative AI guidelines.

What should an AI use policy for staff say?

Head the page with one line: [Business name] AI use policy. Owner: [name and role]. Version [number], effective [date], next review [date]. Then the eight clauses. Square brackets are yours to fill in.

1. Approved tools. Use only the AI tools on the approved list: [tool, plan and account type]. Sign in with your work account, never a personal one. Ask [owner] before adding any other AI app or browser extension.
2. What you may enter. Check the Green, Amber and Red table before you paste or upload anything. Green may be entered. Amber only in [approved tool], with names and identifiers removed or with [owner]’s agreement. Red never goes into any AI tool. If unsure, treat it as Red and ask.
3. Prompts and outputs. What you type and what the tool returns is business data, and [owner] is responsible for it. Save any output you rely on in [folder], and do not share chat links.
4. Human review. AI output is a first draft. You remain responsible for anything you send, file or act on, so check every name, number, date and claim about a person against the source. [Role] approves anything that commits the business or goes to a customer for the first time.
5. Customers. Customers are told when they are dealing directly with an AI tool, and our privacy notice covers how we use their data with AI tools. No customer-facing AI tool without [owner]’s approval.
6. Keeping and deleting. Clear AI chat history every [30 days], or switch it off where the tool allows. Keep outputs containing personal data only in the customer or client file they belong to, under that file’s retention period.
7. Mistakes and incidents. If you enter something Red, send an output to the wrong person, or rely on an answer that was wrong in a way that matters, tell [owner] the same day by [phone number or channel]. Do not wait to see whether it matters.
8. Review. [Owner] reviews this policy and the approved list every [quarter] and whenever a tool, its terms or the law changes. You confirm you have read each new version.

Where does each clause come from?

Each clause is mapped to the official text it draws on. The wording, the Green, Amber and Red labels and intervals such as 30 days are our suggestions, not PDPC or IMDA text.

• 1. Approved tools: paragraph 9.1 makes deployers primarily responsible for choosing systems that can meet their PDPA obligations, so they need information on the provider’s safeguards (paragraphs 7.5 and 8.3 give access controls, data residency, retention and incident procedures as examples). Our suggestion: also ask whether prompts are used for training (paragraph 7.1 covers providers that use end-user prompts for model development).
• 2. What you may enter: paragraph 9.2 (be disciplined about the purpose of processing and the amount of personal data needed), plus two examples: guidelines on the types of personal data that can go in prompts (9.4) and a data classification system that tags more sensitive data for stricter handling (9.5).
• 3. Prompts and outputs: paragraph 9.3 names end-user prompts, inputs and generated outputs as new data sources, and says deployers must designate responsibility for them and put safeguards in place.
• 4. Human review: a PwC Singapore case study in IMDA’s Model AI Governance Framework for Agentic AI describes AI-generated content as a first draft that human reviewers refine and approve before reliance. PDPC’s page on the Data Protection Obligations states the Accuracy Obligation as making reasonable effort to ensure that the personal data collected is accurate and complete, especially if it is likely to be used to make a decision that affects the individual or to be disclosed to another organisation. For checks, see our AI hallucination guide.
• 5. Customers: IMDA’s framework (section 2.4.2) says to declare upfront, at the point of interaction, that users are interacting with agents; applying that to any customer-facing tool is our reading. PDPC’s chart (May 2021) lists the Notification and Consent obligations. For wording, see the IMDA chatbot information card.
• 6. Keeping and deleting: the Retention Limitation obligation (PDPC’s chart) means disposing of personal data once it is no longer needed for any business or legal purpose. Paragraph 7.3 says model providers should regularly review the personal data they hold, and that this applies similarly to deployers who retain personal data to develop and deploy generative AI systems. The 30 days is our example.
• 7. Incidents: PDPC’s data breach guide expects containment and assessment to begin immediately and PDPC to be notified within three calendar days of determining that a breach is notifiable. IMDA lists “timely reporting of bugs or issues with agents” among users’ responsibilities; the same-day rule is our suggestion.
• 8. Review: paragraph 9.5 says deployers should regularly review the sufficiency of their safeguards. It sets no interval, so quarterly is our suggestion.

What can staff paste into AI tools?

Staff may enter Green material, Amber material only in the approved tool with identifiers removed, and never Red. The table has to fit your work, so here is one for a fictional 12-person accounting practice in Tanjong Pagar: two partners, seven accountants and associates, two administrators and a practice manager, who owns the policy and is also the Data Protection Officer. PDPC’s getting-started guide says every organisation in Singapore that handles personal data must appoint at least one, and that the DPO can be an employee or an external service provider.

• Green, may be entered: published material such as legislation and the firm’s website text; generic templates; a request to tighten a reminder email that contains no client facts.
• Amber, only in the approved tool, identifiers removed: a client’s figures with name, UEN, addresses and staff names stripped; internal procedures; a dummy spreadsheet with the same columns as a real one and invented rows.
• Red, never in any AI tool: NRIC and FIN numbers; bank account and card numbers; payroll, wage and bonus details of named people; client accounts and tax computations that name the client; passwords and keys; health information; anything about children; personal email and home addresses; anything a client has said is confidential.

The Red list draws on IMDA’s Starter Kit, a guide for testing LLM-based applications, so using it for staff rules is our reading. It gives personal identifiers (such as NRIC numbers, personal emails and physical addresses), financial information, medical information, confidential business data (such as contracts and employee information) and credentials such as API keys as commonly considered sensitive. PDPC’s guidelines (paragraph 4.5) give children’s data and health or credit records as examples of more sensitive personal data. What counts as sensitive depends on context, so this table is an illustration, not an official classification.

What happens when someone pastes the wrong thing?

Take clause 7 through an illustrative case. On a Friday afternoon an associate pastes a client’s payroll spreadsheet, with 40 named employees, NRIC numbers and monthly wages, into a free chatbot on a personal account to fix its layout, and tells the practice manager within the hour. The tool was not approved and the data was Red. The steps follow PDPC’s C.A.R.E. sequence (contain, assess, report, evaluate); steps 2 and 3 together cover assess and report:

1. Contain. PDPC’s containment measures include stopping the unauthorised practice, so the associate stops using the tool for work and the practice notes the tool, account, time and exactly what was entered. Our suggestion: ask the provider what it can delete rather than assuming the chat can be recalled.
2. Whose data is it? PDPC asks organisations to identify whether they are a data controller (decides the purpose and means of processing) or a data intermediary (processes data on the controller’s behalf). If the practice runs the client’s payroll, it may be an intermediary: PDPC says to notify the controller immediately on discovering the breach, and the controller assesses whether PDPC must be told. Otherwise the practice is the controller, assesses notifiability itself (PDPC offers a self-assessment tool) and documents the basis for its determination.
3. Assess, then count calendar days. Whether the paste is a data breach at all (PDPC’s definition covers personal data used or disclosed without authorisation) is for the practice to assess. A breach is notifiable if it is likely to cause significant harm or affects 500 or more individuals. Forty is under 500, but PDPC gives financial information such as wages as an example of data that may cause significant harm, so the headcount alone settles nothing. The three-calendar-day deadline runs from the time the organisation determines that the breach is notifiable; if that were Friday evening, then on our reading (weekends count) it would fall on Monday evening.
4. Evaluate. PDPC lists incident review, a prevention plan, a review of policies and procedures and employee training among evaluation steps. Here the associate only wanted a layout, so the prevention step is the dummy-data rule in the Amber list, added to the policy and explained to staff.

This is general information, not legal advice; whether an incident is notifiable is for the organisation to judge.

How do you keep the policy current?

Clause 8 needs a log. This one is fictional, with invented dates and counts:

• Review 1, 29 January 2027. Tool requests: 3; approved: 1, after the practice manager read the provider’s information on data location, retention and training use of prompts; declined: 2. Confirmations of version 1.0: 12 of 12. Incidents: 2 (the payroll paste and a wrong figure caught in review). Changes: version 1.1 adds the dummy-data rule and moves personal email addresses from Amber to Red (the table above shows the list after this change). Next review: 30 April 2027.
• Review 2, 30 April 2027. Tool requests: 0. Confirmations of version 1.1: 11 of 12; the twelfth was on leave and is chased. Incidents: 0. Changes: none. Next review: 30 July 2027.

At each review, check for newer versions of the PDPC guidelines (20 July 2026), IMDA’s framework (version 1.5) and the Starter Kit (version 1.0). Unfamiliar terms are in our AI and automation glossary.

What to check before you roll it out

• The policy fits on one page and names one owner and a deputy.
• The approved list names each tool, plan and account type, and someone has read each provider’s information on data location, retention and training use of prompts.
• Each Green, Amber and Red column has at least five examples from your own work.
• Customers who deal directly with a tool are told, your privacy notice mentions AI tools, a Data Protection Officer is appointed, and the incident contact is reachable at a weekend.
• Everyone has confirmed they have read the policy, and the review date is in the owner’s calendar.

Start with clause 1: ask staff this week which tools they already use. If any act on your systems rather than answer questions, read what agentic AI means, our guide to hiring an AI intern and how to choose your first AI workflow. If staff use AI to screen job applicants, see our fair-hiring decision log. More guides are in the AI and automation topic.

Common questions