A One-Page AI Use Policy for Small Teams: Allowed, Ask First, Forbidden
A small team does not need a thick rulebook. This post gives one page with three columns (allowed, ask first, forbidden), four data levels in plain words, who is accountable and what to do in an incident, with a paste-ready template, an example for a six-person team and a checklist.
For team leads, freelancers, small business owners and anyone in a team of a few people who uses AI at work, including beginners. No legal or security background is needed. Every term comes with an everyday picture, and the calculation is marked so you can skip it.
This is not legal advice. Figures come from public sources listed at the end, and in some places I only read a news report. Examples labeled "illustration" are made up and do not refer to real people or companies. Nobody fully understands the inside of AI, so the pictures here are memory aids. The template is my practical suggestion, not a mandatory standard.
Quick summary#
- Small teams often have no rules for AI. A news report on the Stack Overflow 2026 survey says about 29.7% of respondents left AI use to the individual and about 24% said their workplace had approved tools or an official policy. These are numbers read through a news report.
- The biggest risk is often not that AI is wrong, but that someone pastes data they should not. In 2023, according to Bloomberg's report and outlets repeating it, Samsung employees were reported to have put internal source code into ChatGPT, and the company then restricted generative AI tools.
- One page is enough to start: three columns (allowed, ask first, forbidden), four data levels in plain words, a list of approved tools, one accountable person for each AI-written change, incident steps and a review date.
- A way to test the policy: take 20 real tasks from last week and sort them into the three columns. If too many land in "ask first", the policy is too strict or too vague.
- A policy that is too strict makes people work around it, a vague one leaves everyone guessing, and one nobody reads is the same as none. The post shows how to spot each.
- A policy is not a safety guarantee. It only makes what to do clear and gives someone responsibility.
Hard words, plain meaning#
| Term | Plain meaning |
|---|---|
| AI use policy | A short rule sheet saying what the team may do, must ask about and must never do with AI. Like the house rules in a shared kitchen. |
| Data classification | Labeling information by how sensitive it is: public, internal, customer, secret. Like telling apart what sits on the shelf and what goes in the safe. |
| Approved tool | An AI tool the team has read the terms of and agreed to use. Like a supplier checked before you buy from them. |
| Accountability | The person who signs off on a result and answers when something goes wrong. AI cannot put its name on it. |
| Shadow AI | Team members quietly using tools nobody approved because they are handy, like cooking on a private stove outside the shared kitchen. |
| Incident | Something that exposed, or may have exposed, data, or let a mistake reach a client. |
| Disclosure | Telling a client that the team uses AI on their work, when and how much. |
| Review date | The date you agreed to reread the policy and fix it. |
1. A picture first: house rules for a shared kitchen#
Picture a shared kitchen for six people. Nobody wants to read a thick rulebook. But with nothing at all, one person uses the same board for raw and cooked food and another leaves expired food in the fridge. One sheet of paper on the fridge door is enough: this you can just use, this you ask about first (say, the landlord's pressure cooker), this never (leaving the gas on when you go out). A short sheet gets read. A review date keeps it from going stale. A named person means someone to ask.
An AI use policy for a small team works the same way. The goal is not to cover every situation, but to give everyone the same answer to the questions that come up most: can I paste this here, who reads what the AI wrote, what do I do if I slip.
Takeaway: a good policy for a small team is a sheet on the fridge door, not a binder in a drawer.
2. Why it matters: two things with data#
2.1 Most teams have no rules yet (Stack Overflow 2026 survey, via a news report)#
A news report on the Stack Overflow Developer Survey 2026 (IT Brief) says about 29.7% of respondents said AI use at work was optional and left to the individual, and only about 24% said their employer had approved tools or an official policy or guidance. I only read these numbers through the news report and did not check them against the survey pages, and the sample is people who chose to answer, not every small team. Read it as "quite a few places do not have one", not as an exact figure.
Takeaway: if your team has no policy you are not unusual, and the gap is common, not specific to you.
2.2 A reported case: source code into a chatbot (Samsung, 2023)#
According to Bloomberg's first report in early May 2023 and outlets repeating it (Forbes, TechRadar), Samsung engineers used ChatGPT to deal with problems in source code and were reported to have put internal source code into it around April 2023. The company then sent a notice restricting generative AI tools on company computers, phones and networks, allowing them on personal devices as long as company intellectual property was not at risk, and saying violations could lead to discipline. According to these reports the notice did not say what the leaked code contained. Sources also disagree on whether the restriction was temporary or lasting, and I could not open Bloomberg's original, so keep this at the level of "according to reports".
What matters is not the name of a big company. It happened where the engineers were skilled: one very ordinary task (asking a chatbot to look at a bug) plus one very ordinary habit (pasting the code in) is enough.
Takeaway: the risk is in the act of pasting data, and it needs a rule that says which data must not be pasted.
3. The one sheet: three columns and seven items#
Picture the sheet on the fridge door, split into green, yellow and red columns, a few lines each.
3.1 Three columns#
- Allowed (no need to ask): use approved tools with public and internal data for things like explaining, drafting, writing tests, renaming and writing docs.
- Ask first: using a tool not on the list, putting client data into any tool, letting an agent run install, delete or deploy commands, using AI on work the client said not to use it on.
- Forbidden: pasting keys, passwords, tokens and real personal data, using a personal free account for client data, merging AI-written code that no second person has read and no check has run on.
3.2 Four data levels in plain words#
Picture a house with four places to keep things.
| Level | What it is | Examples | Suggested rule |
|---|---|---|---|
| Public | Anyone has already seen it or may see it | Open-source docs, published blog posts | Use approved tools freely |
| Internal | The team's own, awkward if leaked but not harmful | Meeting notes, code with no secrets | Approved tools only |
| Customer | The client's, promised to be kept private | The client's data, documents, code | Ask first, and only if the terms allow it |
| Secret | Leaking it does real damage | Access keys, passwords, tokens, real personal data | Never into an AI tool |
3.3 The other seven items#
- Approved tools: name, account type, who approved, date, and whether the data terms were read.
- Who reviews the result: every AI-written change is read by a second person. The ways of asking for proof in Make AI Output Prove Itself help the reader go faster.
- Who is accountable: the person who merges or sends it to the client answers for it. See also Who is accountable when AI is wrong.
- Telling the client: when to tell, what to say, as agreed in the contract.
- Logging: for new AI use, one line: tool, purpose, data level.
- When something goes wrong: the short steps in section 6.
- Review date: usually about 90 days out, with a named keeper.
3.4 A template to paste and edit#
AI USE POLICY OF TEAM [team name]
Keeper: [name] In effect: [date] Review on: [date + 90 days]
ALLOWED (no need to ask)
- Use the tools on the list below with Public and Internal data.
- Ask AI to explain, draft, write tests, rename, write docs.
ASK FIRST
- Use a tool not on the list.
- Put Customer data into any AI tool.
- Let an agent run install, delete or deploy commands.
- Use AI on work where the client asked us not to.
FORBIDDEN
- Pasting keys, passwords, tokens, real personal data.
- Using a personal free AI account for client data.
- Merging AI-written code before a second person has read it and a check has run.
DATA: Public / Internal / Customer / Secret (examples in section 3.2)
APPROVED TOOLS: [name, account type, approver, date]
ACCOUNTABLE: the person who merges or sends it to the client
TELLING THE CLIENT: [when, how]
LOGGING: new AI use, one line (tool, purpose, data level)
INCIDENT: stop, report within 1 hour, write down what was done, rotate keys if exposed, tell the client if needed
4. An illustrated example for a six-person team#
This example is made up and does not refer to any real company. Picture a team of six building software under contract for a few clients. They fill in the template:
- Approved tools: one paid service on a team account created by the lead, with the approver having read the terms on whether the team's data is used for training (you need to read the real terms of whatever service you pick). Personal free accounts are not on the list.
- Ask first: anything touching client data, and every time an agent is allowed to run an install or a deploy.
- Telling the client: the quote states that the team uses AI to help write code, every change is read by a person, and the client's data is not put into the tool without agreement.
- Review: every 90 days, kept by the lead.
4.1 The test: sort 20 real tasks into the three columns (illustration, can be skipped)#
A way to test the policy: each person lists real tasks where they used AI last week, and the team sorts them into the three columns. The numbers below are made up to be easy to compute, not measurements.
tasks, people, minutes_per_ask = 20, 6, 3
allowed, ask, banned = 12, 6, 2
print(allowed / tasks, ask / tasks, banned / tasks)
# 0.6 0.3 0.1
weekly = tasks * people # 120 tasks a week for the team
asks = weekly * ask / tasks # 36 ask-first questions
minutes = asks * minutes_per_ask # 108 minutes
print(weekly, asks, minutes, minutes / 60)
# 120 36.0 108.0 1.8
Reading the result: of 20 tasks, 12 (60%) go ahead at once, 6 (30%) need a question and 2 (10%) are forbidden. With 6 people at 20 tasks each a week, that is about 36 questions, roughly 108 minutes, or about 1.8 hours a week for the whole team. If 12 of the 20 tasks (60%) landed in "ask first", the same calculation gives 72 questions and 3.6 hours a week, and people would stop asking.
Be clear about this: three minutes per question and the 12, 6, 2 split are assumptions. The rule of thumb that "ask first should not exceed about a third of tasks" is mine, not a measurement from any study. Try it with your team's real tasks and adjust.
5. Where a policy fails#
Picture the house rules: too long and nobody reads them, too strict and people cook in secret, too vague and everyone reads them their own way.
| Situation | Mechanism | How to catch it |
|---|---|---|
| Nobody reads it | A long policy in a folder nobody opens | Keep it to one page, post it where people see it, repeat it when someone joins |
| Too strict, so people work around it | Everyday tasks are forbidden and there is no approved alternative | Count tasks in "ask first" and "forbidden", provide an approved alternative |
| Too vague | Words like "sensitive data" with no examples | Write concrete examples for each data level |
| No one accountable | If "the team" answers, nobody does | Name the person who merges and the person who keeps the policy |
| A tool changes its terms | The approved list is months old | Review date, and reread the terms when you change plan |
| Only bans, no teaching | New people do not know why | A short explanation under each ban |
5.1 Illustration: one morning with and without a policy#
This is an illustrative scenario that names no real person or product.
- 10:00. A dev needs to find a bug in a report exported for a client. The error log contains emails and names of the client's end users.
- 10:05. The dev pastes the whole log into a public chatbot on a personal free account, because nobody ever said not to.
- 10:30. The dev notices real emails in what was pasted. There is no procedure, so the dev stays quiet.
- Next week. The client asks where their data went. Nobody has an answer.
The version with a policy: at 10:05, the line "customer data means ask first" makes the dev message the lead. Together they strip the emails from the log, use an approved tool and write one line. If the paste had still happened, the "report within an hour" step lets the team deal with it early: note what was pasted, rotate keys if any, tell the client if needed.
What to do: write the incident section before there is an incident, because people rarely think of the steps in a panic.
This illustration is not evidence. The Samsung case reported above is a real example of the same kind of behavior, and the Stack Overflow 2026 survey (via a news report) suggests the policy gap is common. See also OWASP Top 10 for AI Apps for technical risks.
6. When something goes wrong: five short steps#
- Stop: stop what you are doing with that tool.
- Report within an hour: to the accountable person, even if you are not sure it is an incident.
- Write it down: what was put in, into which tool, when.
- Deal with it: rotate keys if they were exposed, delete the conversation if the tool allows, ask the provider about data retention.
- Tell the client if the contract or the law requires it, and put the lesson back into the policy.
Allow reports of near misses as well. If reporting is punished, people will stay silent.
7. Numbers, standards and law: how to read them#
| Source | Says | How to read it | Caveat |
|---|---|---|---|
| Stack Overflow 2026 survey, via an IT Brief report | About 29.7% leave it to the individual, about 24% have approved tools or an official policy | The policy gap is common | Read through a news report, not checked against the original tables, sample is people who chose to answer |
| Samsung reports, 2023 (Bloomberg, Forbes, TechRadar) | Source code reportedly went into ChatGPT, the company restricted generative AI tools | Pasting data is a real risk | I did not open the original, sources disagree on how long the restriction lasted |
| NIST AI RMF 1.0 (1/2023) | A voluntary framework with four functions: Govern, Map, Measure, Manage | A pointer to how to think about governance | Aimed at larger organizations, I only read secondary summaries |
| ISO/IEC 42001:2023 | A standard for an AI management system, can be certified | Only a pointer, small teams usually do not need it yet | I have not read the standard itself |
| Law on Artificial Intelligence, No. 134/2025/QH15 (Vietnam) | In effect from 1 March 2026, distinguishes developers, providers, deployers and users | Read it to learn which role your team falls under | Not legal advice. I have not read every article on obligations |
On the legal side: according to the sources I found, the law was passed by the National Assembly on 10 December 2025 and takes effect on 1 March 2026. It defines a deployer as an organization or individual using an AI system in professional, commercial or service activity, and use for personal, non-commercial purposes falls outside that scope. I have not verified the specific obligations of each party, the implementing rules or the transition periods. If your team supplies products or services that use AI to clients, read the full law and ask a legal professional. This post only helps you know what to ask.
Read it fairly: the sources above support having clear rules and a named person accountable. I found no study measuring how many incidents a one-page policy prevents. The template here is a synthesis of practice.
8. Habits to apply from tomorrow#
8.1 Eight questions before posting the policy#
- Does the policy fit on one page?
- Do the three columns have concrete examples, not only concepts?
- Do the four data levels have examples familiar to your team?
- Is there a list of approved tools with dates and approvers?
- Does every AI-written change get read by a second person?
- Is there a named accountable person and a named keeper of the policy?
- Are the incident steps written down, and is reporting a near miss allowed?
- Is there a review date?
8.2 Three things to do now#
- Spend 30 minutes filling in the template in 3.4 and cut what your team does not need.
- Run the 20-task test in 4.1 with last week's real tasks.
- Set a review date about 90 days out and write the keeper's name.
9. A balanced view: what a policy does and does not do#
It does: give everyone the same answer to recurring questions, tell newcomers what to do, create a place to report when someone slips and leave a trail when a client asks.
It does not:
- A policy is not a safety guarantee. People can still paste by mistake, and tools can change their terms.
- I have not seen a study measuring how well a one-page policy works. Track your own count of questions and near misses.
- One sheet of paper does not replace training, checking tools and a culture where people dare to report mistakes.
- For teams that supply services to clients or handle personal data, one page is a starting point, not the full set of legal obligations.
Do not oversell it: no template fits every team. Do not wave it off: the policy gap tends to show up when a client asks, and by then it is too late to write one.
10. Conclusion#
A small team does not need a thick rulebook. It needs a sheet on the fridge door: allowed, ask first, forbidden, four data levels, one accountable person, five steps when something goes wrong and a review date. Draft it in 30 minutes, test it on 20 real tasks and revise it after 90 days.
References#
Figures come from public sources as of October 2026. Some sources I read only through news reports or secondary summaries, so open the originals before quoting. This is not legal advice.
- Stack Overflow, 2026 Developer Survey and the IT Brief report on the survey (the source of the 29.7% and 24% figures)
- Reports on Samsung's restriction of generative AI (May 2023): Forbes Australia and TechRadar (repeating Bloomberg's report)
- NIST, AI Risk Management Framework (AI RMF 1.0, January 2023)
- ISO, ISO/IEC 42001:2023
- Law on Artificial Intelligence, No. 134/2025/QH15 on Thu Vien Phap Luat and the Baker McKenzie overview (read the full text before relying on it)
Frequently asked questions
- Does a small team need an AI use policy?
- It helps, because without rules everyone decides alone and data can end up in tools nobody approved. A news report on the Stack Overflow 2026 survey says about 29.7% of respondents said AI use at work was left to the individual and about 24% said their employer had approved tools or an official policy. Those numbers come from the news report, not from the original tables. One page is enough to start.
- What goes into a one-page policy?
- Three columns (allowed, ask first, forbidden), four data levels (public, internal, customer, secret), a list of approved tools, who reviews AI output and who is accountable, when to tell the client, what to log, incident steps and a review date, usually about 90 days out.
- Should we ban public AI tools outright?
- It depends on the risk. In 2023 Samsung restricted generative AI tools on company devices and networks after employees were reported to have put source code into ChatGPT, according to Bloomberg and outlets repeating its report. This post does not say bans are wrong. It notes that a ban without an approved alternative can push people to find workarounds. For a small team, a common approach is to allow approved tools with public and internal data and forbid secret data.
- Is this a substitute for legal advice?
- No. This is an explanation for developers, not legal advice. Vietnam's Law on Artificial Intelligence, No. 134/2025/QH15, takes effect on 1 March 2026 according to the sources I found, but I have not read every article on obligations. Read the original text or ask a legal professional before relying on it.
- How often should the policy be reviewed?
- About every 90 days is reasonable for a small team, because tools and their terms change quickly. That is my practical suggestion, not a mandatory standard. Write the review date at the top of the page and give it to one person.