How to implement an internal AI policy for a team of up to 20 people: template + checkpoints

A small team usually does not need a thirty-page directive. It needs a short, understandable document from which people can identify three things: what they are allowed to enter into AI tools, what they are allowed to use them for, and who bears responsibility for the output. The problem is often most visible precisely in teams of up to 20 people: one person uses ChatGPT for emails, another uses Copilot in Office, a third records meetings into an AI transcription tool, and no one knows exactly whether personal data, trade secrets, or non-public contracts are being sent to the service.

A well-set internal AI policy is not a ban on using AI. It is an operational rule that shortens decision-making and reduces damage. In practice, it should be 2 to 5 pages long, with clearly defined roles, a list of approved tools, and several situations where AI must not be used at all. If the team works with client data, HR agendas, or non-public financial materials, it is advisable to introduce the policy before AI becomes an unmanaged standard.

For basic orientation in the differences between services, an overview at aivyber.cz/ai-tools is also useful, where you can compare what types of tools are commonly used for company operations. For text assistants, it is also useful to follow specific limits and deployment modes, for example in the overview ChatGPT on AIVýběr.

1. First determine why the policy is being created and what risk it is meant to address

Illustrative context on the topic continues below.

The most common mistake is to start with a list of prohibitions. A better approach is to start with scope. For a small team, it is usually enough to answer four questions:

What types of data are processed in the team?
Which activities are people already doing in AI without rules?
Where is the greatest damage likely if a mistake occurs?
Who approves exceptions?

What to do: Within 30 minutes, write down a list of the 10 most common work tasks for which people actually use AI or soon will. Typically: email drafts, meeting notes, document summaries, translations, outline creation, spreadsheet analysis, editing marketing texts, image generation, and working with source code.

Who it is for: Founders, team leads, the office manager, the operations manager, or the person responsible for IT and processes, even if they are not a full-fledged compliance specialist.

When not to use this: If the company already falls under a strictly regulated regime with its own corporate directive or has binding requirements from a parent company. In that case, the local team should only supplement operational rules, not create a parallel document.

The output of this phase should not be legal text, but a simple definition of the goal. For example: “We are introducing the policy to protect client data, unify approved tools, and establish human oversight over AI outputs.” That is enough as the opening sentence of the document and as an internal explanation of why the rules are being created.

2. Divide data into three classes and allow or prohibit inputs accordingly

The most practical part of the policy is data classification. Without it, people do not know what they are allowed to paste into a chat. For a team of up to 20 people, three classes are usually enough:

A. Public data

Content that is published or intended for publication: press releases, public product descriptions, published articles, general outlines, internally approved marketing texts.

Rule: Can be used in standard AI tools if this does not violate licensing or contractual terms.

B. Internal non-public data

Internal procedures, non-public presentations, business plans, roadmaps, budgets, meeting notes, non-public offers.

Rule: Can only be used in pre-approved tools and after data minimization. This means removing names, amounts, client names, project identifiers, and anything not necessary to complete the task.

C. Sensitive and prohibited data

Personal data, special categories of personal data, client contracts without anonymization, payroll agenda, health information, access credentials, API keys, non-public source code without approval, security incidents, documents under NDA if the contract does not cover AI processing.

Rule: Must not be entered into publicly available AI services. Without exception.

What to do: Insert this classification directly into the policy as a table: “data type / example / allowed / condition / prohibited.”

Who it is for: All team members regardless of seniority. Even a new person on their first day at work must understand the rule.

When not to use this: If the team works exclusively with anonymized public data and sends no sensitive inputs to AI. Even then, however, a brief version of at least one page still makes sense.

This is exactly where the greatest practical benefit arises. The employee does not have to deal with the abstract question of whether the tool is “safe.” They assess the specific input. That is faster and more enforceable.

3. Create a list of approved tools and describe the usage mode for each

A policy without a list of approved services is often non-functional in practice. People then choose a tool themselves based on price or the first search result. A small team usually manages with 3 to 6 approved services.

OpenAI

The list should include at least:

service name,
purpose of use,
who may use it,
what type of data may be entered into it,
who pays for the license and who manages access.

A typical company baseline may look like this:

ChatGPT Team / Business – texts, summaries, outlines, translations, internal brainstorming. Official website: https://openai.com/. Indicative price: previously around USD 25–30 per user per month depending on the plan and terms; always verify the current pricing.
Microsoft Copilot for Microsoft 365 – work in Word, Excel, Outlook, Teams, and across the company tenant. Official website: https://www.microsoft.com/microsoft-365/copilot. Indicative price: around USD 30 per user per month, excluding VAT and depending on the license.
Claude Team – work with longer documents, summaries, text analysis. Official website: https://www.anthropic.com/claude. Indicative price: around USD 25–30 per user per month depending on the plan.
Otter.ai or Fireflies.ai – meeting transcription and meeting summaries. Official websites: https://otter.ai/, https://fireflies.ai/. Indicative price: approximately USD 10–20 per user per month depending on the plan.
GitHub Copilot – code completion, test suggestions, function explanations. Official website: https://github.com/features/copilot. Indicative price: from single digits to lower tens of USD per user per month depending on the edition.

What to do: For each tool, write one sentence stating “approved only for…” and “prohibited for…”. For example: “Otter.ai is approved for internal operational meetings, but not for client calls without the prior consent of participants.”

Who it is for: Team leaders, marketing, sales, customer support, HR, and development. Each department may have a different set of approved tools.

When not to use this: If the company can centrally enforce only one approved platform and technically blocks everything else. In that case, it is enough to list one platform and prohibit circumvention.

It is important not to use personal accounts for company work. The policy should clearly state that company outputs are created only in work accounts managed by the organization. This is essential because of employee departures, access management, and audit trail.

4. Set roles and responsibility: who enters, who checks, who approves

An AI policy fails the moment it is unclear who is responsible for an incorrect output. In a small team, there is no need to introduce a complex role matrix, but it must be clear that responsibility lies not with the tool, but with the person.

In practice, three roles work well:

AI user – enters the prompt, prepares the output, marks the use of AI if the process requires it.
Reviewer – verifies factual accuracy, sources, tone of communication, and legal or procedural compliance.
Policy owner – usually the founder, COO, team lead, or IT administrator; manages the list of tools, decides on exceptions and updates.

What to do: Insert into the policy the rule: “Without human review, an AI output must not be sent to a client, published in the company’s name, or used as the sole basis for a decision about a person.”

Who it is for: Marketing and sales teams, where AI often generates texts and drafts faster than someone can review them. It is equally important for HR and support.

When not to use this: Not in the sense of removing review, but do not formulate the rule too generally. A sentence like “always use common sense” is not enforceable and has little value in a policy.

It is also good to add a simple task risk label:

Low risk: internal outline, summary of a public article, language editing of a text.
Medium risk: proposal draft, response to a client, meeting notes.
High risk: legal text, price calculation, HR evaluation, financial analysis, security recommendation.

For high risk, the policy should require a second pair of eyes or explicit approval by the responsible person.

5. Introduce minimum operational rules: access, logging, retention, and deletion

Even a small team needs several technical and operational principles. This is not about enterprise architecture, but about basic order. In most cases, five points are enough:

Company AI tools are used only through a work account.
Access is disabled no later than on the day the person leaves the company.
Passwords, tokens, private keys, and full database exports must not be entered into AI.
If the tool allows history, shared conversations, or training on data, the settings must be verified in advance according to company terms and the provider’s documentation.
Outputs intended for the client or the public are stored in the company system, not only in the tool’s chat.

What to do: Add a short onboarding and offboarding checklist to the policy. On joining: create an account, add the person to approved workspaces, send the usage rules. On leaving: revoke access, transfer ownership of shared conversations or projects, check integrations with other services.

Who it is for: Office management, HR, and IT administration, even if handled externally by a vendor.

When not to use this: If the team does not use separate AI accounts at all and everything runs only within an already managed platform, for example in a Microsoft 365 tenant. Even there, however, access permissions and employee departures still need to be addressed.

For meeting and call transcriptions, one more condition must be added: participants must know that the meeting is being recorded or transcribed by an AI tool. This is important operationally and legally. The policy should specify who announces this information and whether explicit consent is required for certain types of meetings.

6. Add a decision tree: when to use AI, when only with anonymization, and when not at all

One of the most practical parts of the policy is a short decision tree. People will use it faster than the whole document. It can look like this:

Does the input contain personal data, payroll data, a contract, secret code, or security information? Yes: do not enter it into a standard AI chat.
Is the task only supportive and will the output be reviewed by a person? Yes: an approved tool may be used.
Is it possible to shorten, generalize, or anonymize the data before entering it? Yes: use the anonymized version.
Will the output be sent to a client or used as the basis for an important decision? Yes: human review is required, and for high-risk cases, a second approval as well.

What to do: Print the decision tree on one page and attach it to the policy as an appendix. For a small team, it works better than lengthy explanations.

Who it is for: New employees, junior roles, and contractors who do not have full context of company processes.

When not to use this: If the text is too general and does not correspond to specific situations in the company. The decision tree must be based on the team’s real tasks, not abstract maxims.

The advantage is that this format also makes training easier. In 20 minutes, you can go through model situations with the team and immediately show how decisions are made in practice.

7. Practical scenarios: what is allowed, conditionally allowed, and prohibited

Below are the scenarios that appear most often in a team of up to 20 people. The policy should be built on these, because people remember rules by situations, not by definitions.

Scenario 1: Marketing wants to shorten a finished article for LinkedIn

Allowed: Yes, if it is your own or approved text without non-public information.

Condition: A person edits the output and checks facts, dates, product names, and brand tone of voice.

Do not use: If the article contains an embargo, non-public campaign data, or third-party text without clarified licensing terms.

Scenario 2: Sales wants to paste an entire email thread with a client and have AI suggest a reply

Conditionally allowed: Only after removing names, contacts, pricing details, non-public contractual terms, and other identifiers, and only in an approved tool.

Review: The sent reply must be approved by the responsible salesperson.

Do not use: If it concerns a dispute, complaint, contractual interpretation, or sensitive negotiation.

Scenario 3: HR wants to create a summary of candidates from CVs

Usually not allowed in standard public AI services: CVs contain personal data and often sensitive information.

Possible path: Only if the company has assessed a specific tool, the legal basis for processing, and a process that covers personal data protection.

Do not use: For automated hiring decisions, ranking candidates without human assessment, or generating evaluative judgments without verifiable criteria.

Scenario 4: A developer wants to paste part of internal code into an AI assistant

Conditionally allowed: Only if it is in line with company rules and client contracts, ideally in a tool approved for the development team.

Review: The output must go through code review and security assessment.

Do not use: For proprietary client code, security modules, secret algorithms, or where prohibited by contract.

Scenario 5: The team wants to record internal meetings using AI transcription

Allowed: Yes, if participants are informed and the record is stored according to internal rules.

Condition: Do not transcribe meetings where salaries, disciplinary matters, health information, or non-public legal strategy are discussed.

Do not use: If any participant does not agree and there is no other legal or contractual basis.

What to do: Add at least 5 to 8 scenarios directly from the company environment to the policy. This is more effective than long definitions.

Who it is for: The whole team, especially roles that work daily with text, clients, or meeting records.

When not to use this: If the scenarios do not correspond to the company’s reality. Copied examples from the internet without connection to your own processes lose value.

8. Set limits: where AI must not replace expert judgment

A good policy does not only say what is allowed, but also what AI should not do. For a small team, four limits are essential:

AI is not a lawyer. It must not independently create a final legal opinion, contractual interpretation, or binding terms without review by a qualified person.
AI is not an accountant or tax advisor. It must not be the sole basis for bookkeeping, tax assessment, or reporting.
AI is not an HR decision-maker. It must not independently select, reject, or evaluate people without clear criteria and human review.
AI is not a source of truth. Facts, quotations, numbers, and current terms must be verified in the primary source.

What to do: Add a separate section “Prohibited uses” to the policy. For a small team, 6 to 10 points are enough.

Who it is for: Company management and all roles that may mistakenly understand AI output as a finished expert opinion.

When not to use this: Do not write limits in the style of “AI may be inaccurate.” That is too vague. You need specific prohibitions and mandatory checks.

Prohibited uses can also commonly include generating deepfake materials in the company’s name, bypassing internal approval processes, and entering data into unapproved services just because they are free.

9. Deployment within 14 days: a short schedule for a team of up to 20 people

A policy is useful only if it is actually implemented. For a small team, it is realistic to manage the first version within two weeks.

Day 1 to 2: mapping

List the tools being used.
Name the types of data and risky processes.
Appoint the policy owner.

Day 3 to 5: first version of the document

Write the purpose of the policy.
Add data classification.
Create a list of approved tools.
Add roles, reviews, and prohibited uses.

Day 6 to 7: review with managers

Go through scenarios by department.
Correct unclear areas.
Confirm the owner of updates.

Day 8 to 10: technical steps

Unify company accounts.
Disable unapproved workflows, if possible.
Prepare the onboarding checklist.

Day 11 to 14: training and launch

30-minute training based on real scenarios.
Send out a one-page decision tree.
Confirm acknowledgment of the rules.

What to do: Announce the policy as version 1.0 with a review date in 90 days. This is more practical than waiting for a “perfect” document.

Who it is for: Founders and small management teams that do not have a separate legal or compliance department.

When not to use this: If the company is simultaneously implementing a major infrastructure change or moving to a different office ecosystem. In that case, it is better to align the policy with the new environment so it does not have to be rewritten in a month.

10. Internal AI policy template for a small team

The following structure is sufficient for the first internal version:

Purpose of the document – why the policy exists.
Scope – who it applies to: employees, contractors, temporary workers.
Data classification – public / internal / sensitive and prohibited.
Approved tools – list of services, purpose, limitations.
Approved uses – text drafts, summaries, translations, transcriptions, brainstorming.
Prohibited uses – personal data, contracts without anonymization, passwords, decisions about people without review.
Human review – what a person must check before sending or publishing.
Roles and responsibility – user, reviewer, policy owner.
Operational rules – company accounts, access, deletion, onboarding/offboarding.
Rule violations and exceptions – who to report a problem to, who approves an exception.
Document review – who updates the policy and how often.

What to do: Write the policy with the goal of fitting into 2 to 5 pages plus an appendix with scenarios. If it is longer, people usually do not read it.

Who it is for: Small companies, agencies, startups, e-shops, and internal teams that want to quickly establish an operational minimum.

When not to use this: If you need to address industry-specific requirements, for example in healthcare, financial services, or public administration. In that case, the policy must be expanded with sector-specific and legal obligations.

FAQ

Does a small company need an internal AI policy even if it only uses ChatGPT for texts?

Yes, if more than one person on the team uses the tool or if non-public information is processed in it. Even one-page rules are better than none.

Is it enough to tell employees not to enter sensitive data into AI?

No. They need to see specific examples of what is sensitive, how to anonymize data, and which tools are approved.

Is it better to ban everything until a detailed directive is finished?

In most small teams, no. It is more reasonable to quickly introduce minimum rules, a list of approved tools, and human review of outputs.

Should the policy also address copyright and sources?

Yes. At a minimum, state that AI output must not be presented without verification as factually correct, original, or free of licensing issues. For images, texts, and code, terms of use must be checked.

How often should the policy be updated?

The first review makes sense 60 to 90 days after implementation. After that, whenever tools, processes, or data flows change, but at least once a year.

What if someone uses a private AI account for company work?

The policy should explicitly prohibit it. Company outputs should be created in accounts that can be managed, audited, and removed when an employee leaves.

Conclusion

An internal AI policy for a team of up to 20 people does not have to be complicated, but it must be unambiguous. It brings the greatest benefit in four points: it distinguishes what data must not be entered into AI, defines approved tools, introduces human review, and clarifies responsibility. If the document reflects the team’s real tasks, it can be prepared within two weeks and quickly put into operation.

The first version does not have to solve everything. But it must solve what matters most: so that people know when to use AI, when to anonymize data, and when not to turn it on at all. In a small team, that is the difference between a useful tool and an unnecessary operational risk.

Recommended AI stack for implementation

Choose tools according to your budget and level of automation. Below is a direct overview of services for implementing the project.

Service	Service description	Offer
NordVPN	VPN service for privacy protection and secure connections.	Open offer
Semrush	SEO and marketing platform for analysis and traffic growth.	Open offer
Make	Advanced visual automation for workflows and integrations.	Open offer
Hostinger	Web hosting and domains for fast website launch.	Open offer
Fiverr	Marketplace for freelancers and external specialists.	Open offer
Adobe	Creative tools for graphics, video, and digital content.	Open offer
Canva	Online design tool for graphics, presentations, and social media.	Open offer
Jasper	AI tool for marketing copy and content campaigns.	Open offer