Corporate AI Use Policy: What Employees Need to Know
Employees are already using AI: some through a work account, some through a personal app on a phone, and some by pasting contract excerpts into a free chat because it is faster. A manager knows rules are needed but may not know where to start or how to avoid a document nobody reads.
A useful baseline AI policy answers five practical questions. Which services and accounts may employees use? What information may they share, and what must stay out? Who checks and owns the result? Which actions require a person’s approval? Who should be told when something goes wrong? The document should help someone assess a real task quickly and know whom to ask when unsure.
The template in this article needs your actual company details: approved services, access methods, contacts and internal rules. It is not a finished legal instrument. Use it to draft a working first version, assign an owner and identify questions for counsel.
Purpose and scope
Start by stating who and what the policy covers. Without this, employees cannot tell whether a rule applies to their task.
Specify:
- People: employees, contractors with access to work systems and interns; explain any differences.
- Information: company, customer and partner information used for work, regardless of device.
- Products: chat assistants, AI features in office software, image generators, coding assistants and AI features in CRM or support tools.
- Workflows: drafting, data analysis, customer responses, coding and translation.
- Owner: a named role responsible for the policy, questions and updates.
- Review cycle: for example, quarterly and after material product changes or an incident.
It helps to assign four functions: setting rules, understanding a use case and its risks, evaluating outputs, and responding to identified risks. These are functions, not mandatory departments; one person may cover several in a small company. This framework helps organize a working document but does not establish legal sufficiency.
Approved tools register
Employees need a concise register of services approved for work. A broad statement such as “ChatGPT is allowed” or “Copilot is allowed” can be misleading because products under one brand may have different terms.
Personal and business accounts from the same provider can differ. A provider may, for example, exclude business data from model training by default while still processing and retaining it for a period to operate the service. Check training use, retention, administrator settings and processing location for the specific product and plan. “Not used for training” does not mean zero retention or processing on your own servers.
For each service, record:
| Register field | What to record |
|---|---|
| Product and plan | Exact product and plan, not just the brand |
| Access method | Business account, work email or SSO |
| Administrator | Who grants access and manages settings |
| Approved uses | Tasks for which the service is approved |
| Allowed data categories | Link to the data matrix below |
| Terms review date | When the provider terms were last checked |
Also explain how to request a new service: whom to contact, what information to provide and who decides. Without a clear route, employees may quietly use unreviewed tools.
Data matrix
A data matrix turns “protect confidential information” into a usable rule: it shows where each category may be processed.
Example matrix for adaptation
This is an educational example. Adapt the categories, services and conditions to your contracts, internal rules and applicable legal requirements.
| Data category | Examples | Approved business AI service | Personal account | Additional condition |
|---|---|---|---|---|
| Public | Website copy, published price lists | Yes | Yes, if policy allows | Author checks the result |
| Internal | Procedures, reports without personal data | Yes | No | Approved use cases only |
| Confidential | Contract terms, financial metrics, proposals | Only specifically approved services | No | Data owner approval |
| Personal data | Names, phone numbers, customer correspondence | Only where company data rules expressly allow it | No | Minimize fields to what is needed |
| Access secrets | Passwords, API keys, tokens, verification codes | No | No | Never put them in prompts |
Explain the reasoning, not only the prohibition. A personal account is outside company administration: the company may lack access to its settings and usage data and does not control its retention terms. Even translating a customer email can be a problem if it contains personal data.
Generative AI brings risks from data disclosure and from instructions embedded in material the system reads (prompt injection). The matrix sets which data may be sent to a service, but it does not protect against embedded instructions. Automated actions need separate input checks, access limits and human confirmation.
Output review rules
Risk concerns both what went into an AI service and what came out. One generative AI risk is confabulation: information presented confidently but incorrectly. A model may invent a figure, link, contract clause or product capability and make it sound convincing.
The policy should say what to check before using an output:
- Facts and figures: compare them with company source data or a primary record.
- Calculations: repeat key calculations in a spreadsheet or another way.
- Code: use the ordinary review and testing process.
- Links and quotations: open each link and check that it exists and supports the statement.
- External commitments: approve customer-facing timelines, prices, discounts and guarantees as usual.
The person using the output and the process owner remain responsible for it. AI is not a participant to whom a decision can be handed off. Legal responsibility in a specific dispute depends on the circumstances and applicable law; that is a question for counsel, not something an internal policy alone can settle.
Actions and incidents
Separate rules are needed when AI takes an action, such as sending an email, changing a CRM record, publishing a post or creating an invoice. An error can immediately affect someone outside the company.
Specify:
- which actions require human confirmation, such as customer emails, deal-status changes, discounts or refunds;
- who may enable automated actions, such as the process owner together with the system administrator;
- who can stop the process and how to do it quickly.
Keep the incident procedure simple:
- Stop the action: do not send, publish or continue the service interaction.
- Notify the designated person through the stated channel.
- Record what happened: service, data, time and who may have had access.
- Do not try to hide the mistake by deleting evidence.
An incident may include data sent by mistake, an incorrect output already sent to a customer, or suspicious service behavior. The easier it is to report a problem, the sooner the company can respond.
Example policy wording for adaptation
Replace the brackets with your company’s real details. This is not a finished legal instrument.
> Work data may be processed only in approved services using business access: [services and plans]. Passwords, access keys and other secrets must never be included in AI prompts. The process owner [role] checks outputs that affect a customer or company records. AI-assisted customer emails and CRM changes require human confirmation. If data is sent by mistake, the employee stops the action and contacts [responsible person and channel].
Training and policy review
A document that is signed and forgotten will not guide daily work. Pair it with short training and a clear update process.
- Examples instead of a lecture: prepare three to five “allowed / ask first / not allowed” examples for each team based on real tasks.
- Acknowledgement: record that employees have read it; a short exercise classifying data in three examples may be more useful than a signature.
- Questions channel: tell employees whom to contact and ensure they can get a timely answer.
- Tool register updates: providers change plans and terms. Review the register on a schedule and after product, contract or data-category changes or an incident.
- Feedback: if people repeatedly work around a rule, it may be too restrictive for the actual task or there may be no approved tool for a common need. Route that feedback to the policy owner.
What to do in your workflow
- Assign a policy owner and set the first review date.
- Find out which AI services employees already use, without punishing honest answers.
- Build a register of approved services with plan, access method, administrator and terms review date.
- Adapt the data matrix to your categories and review it with the people responsible for personal data and contracts.
- Set which AI-enabled actions require human confirmation and who receives incident reports.
- Prepare three to five real-task examples for each team and hold a short briefing.
- Send jurisdiction, contract and disciplinary questions to counsel.
Frequently asked questions
That depends on the data category and service terms. A personal account may be acceptable for public information if the policy allows it. For internal, confidential and personal data, approved business services are safer because the company does not manage personal-account settings. State which account types are allowed for which data instead of leaving the decision to each employee.
Assign a person to check the output before use and an owner for the review rules. A decision cannot be handed off to AI. Legal responsibility depends on the facts, contracts and applicable law, so consult counsel.
Set a schedule, such as quarterly, and review sooner after a material change: a new plan or terms, a new contract, a new data category or an incident. Keep the last review date for each service so it is clear what may be out of date. If you want to test a policy against a real workflow, BotLabs specialists can examine one scenario: its data, human approvals and output checks. We can discuss the process and participants and identify a realistic first step.
AI workflow rules consultation
In 15 minutes with a BotLabs specialist, examine one work scenario: required data, service access and result checks. Identify where human approval is needed and which questions to take to the policy owner before approving an initial pilot.
Data and actions
Human approval
15 minutes with a specialist to discuss data, checks and human approval in one scenario.
