What goes in a team AI policy

You will be able to outline a team policy that answers the questions colleagues actually ask.

Daniel, the clinic's operations lead from module 2, has been asked by the owners to "write something about AI for the staff". He searches online and finds templates running to twelve pages, full of words like governance and framework. He knows nobody at the front desk will read that. What they need is answers to the questions they actually ask him.

A team AI policy is a set of shared rules about how a team or organisation uses AI. This lesson covers what goes in one that works, built around four sections. Each answers questions colleagues really ask, and each draws on a module of this course.

Approved tools and how to get a new one

The first section answers the question Daniel hears most: can I use this?

List the AI tools the team may use, and the account or plan for each. Be specific: name the tool and say which login. Then say what isn't allowed. For most teams that includes personal accounts for any work involving client or customer data, for the reasons in lesson 1.2, Personal, business and enterprise accounts are not the same.

Then say how someone requests a new tool. New AI tools appear constantly, and staff will find ones they like. If there's no route to ask, people will use them quietly instead. A simple route works: tell a named person what the tool is, what you'd use it for, and what data would go in, and wait for a yes before using it with work data.

Data rules

The second section says what may go into which tool. Base it on the three groups from lesson 1.1, What happens to the words you type into an assistant, and map it to the PDPA and to client confidentiality.

Use real examples from your team's work, not abstract categories. Daniel's section says that patient names, NRIC numbers, contact details and treatment notes never go into any AI tool except the clinic's approved system, and only for tasks the data protection officer has signed off. It says feedback forms can go into the approved assistant once names and phone numbers are removed, as in lesson 2.2. And it says general health information from public sources can go anywhere.

If your team handles client material under contracts, add a line on that. A client's confidential documents may be off limits even in an approved tool, depending on what the contract says.

Review and disclosure

The third section answers two questions: who checks AI output before it leaves the team, and when do we tell clients or the public that AI was used?

For review, use the delegate, assist and keep groups from lesson 7.3, Decide what to hand over, what to assist, what to keep. Name which kinds of output need a person to check them before they go out, and who that person is. A role is fine where a name would go out of date, such as "the senior physio on duty" or "the account manager".

For disclosure, there's no universal rule, as lesson 4.4, Write a content use note for your team, discussed. Decide what your team will do and write it down. Some clients' contracts require disclosure. Some professions have their own rules. And some uses, such as an AI-made image that looks like a real photo, need disclosure to avoid misleading anyone. If you wrote a content use note in module 4, it can fold into this section.

If your work affects decisions about people, add a line from module 3: AI output used in decisions about hiring, performance or customers needs a bias check or a human decision.

Incidents: what to do when something goes wrong

The fourth section is the one most templates leave out, and it's the one people need under pressure. It covers two situations.

The first is personal data going into the wrong tool. Someone pastes a customer list into a personal account, or uploads a patient file to an unapproved app. The policy should say: stop, delete what you can, and tell a named person straight away, without fear of being blamed for reporting it. Lesson 2.1, PDPA basics every employee should know, explained why the organisation needs to know quickly, since some breaches must be reported to the PDPC. Make it clear that hiding a mistake is the only thing that will get someone in trouble.

The second is a deepfake or impersonation request. Someone receives a call, voice note or video call from a "manager" asking for an urgent transfer or a change to payment details. The policy should restate the rule from lesson 5.3, Safe words, callbacks and questions only they can answer: a second person and a second channel, every time, with no exceptions for seniority or urgency.

Under each heading, an example

Daniel's draft is four short headings, each with two or three rules and one example drawn from the clinic. Under data rules, for instance: "Example: you want help summarising this month's feedback. Remove names and phone numbers first, then use the clinic assistant."

Those examples are what make a policy usable. People skim the rules and remember the examples. When you sketch your team's version, start with the four headings and the single example under each that would answer the question you hear most often.

Write the section headings of your team policy with one example rule under each.

Course

Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).