Employee AI Use Policy: Rules and Controls

Why you need an AI policy and what problems it solves

Without rules, employees will use AI however they want: someone pastes parts of contracts into a chat, someone asks to "rewrite an email to a client" with real figures, and someone treats the model's answer as fact. Risks arise in several places at once: data leaks, mistakes in documents and reports, and reputational incidents when something that shouldn't have been released goes public.

An employee AI use policy is not meant to "ban everything", but to give a single clear answer to three questions: what can be sent to AI, what cannot, and what to do with the result. This reduces chaos and eases unnecessary tension: people know the boundaries and are not afraid to make mistakes.

A typical situation: a manager prepares a commercial offer and asks AI to "improve the text", inserting discount data, deadlines and the client's name. Without rules, they might disclose confidential terms or personal data. The policy sets the boundaries in advance: which data we redact, what we replace it with, where templates are acceptable, and where an approved process is required.

A unified set of rules is needed for everyone working with texts, numbers and files: office teams (sales, procurement, finance, marketing), IT and information security, HR and learning, legal and compliance, managers.

A good policy does not turn AI into a "forbidden zone." It preserves useful scenarios (drafts, editing, brainstorming, summarizing general texts) but clearly restricts what can harm the company.

Data classification: what must never be sent to AI under any circumstances

For the policy to work, start with a simple rule: first identify the data class, then decide whether it can be used in a prompt. This reduces the risk of leaks and helps everyone act uniformly without guessing.

A convenient basic scale:

• Public: already published information (press releases, open vacancies, general product descriptions).
• Internal: working materials without sensitive details (meeting plans, email templates, draft instructions).
• Confidential: data that gives a competitive advantage or concerns clients and employees.
• Strictly confidential: information that could cause serious harm if leaked or is regulated by law.

There are categories that should almost never be entered into generative AI, even if it seems to speed up work:

• Personal data (IIN, document numbers, addresses, phone numbers, employee and client data).
• Passwords, codes, tokens, API keys, credentials for VPN and mail.
• Financial details and payment data (account and card numbers, statements, bank-client access).
• Trade secrets: prices and discounts, contract terms, procurement plans, internal estimates, source code and system architecture.
• Medical and government data: requirements are usually stricter; use only approved corporate solutions and procedures.

A simple example: a manager prepares a letter to a supplier and wants AI to "improve the text." You can send a general draft without amounts, counterparty names, contract numbers and delivery dates. But a full contract, a price table and a procurement schedule — cannot be sent.

If an employee is unsure about the category, the rule is simple: don't send it. Then quickly clarify with the data owner (process owner) or InfoSec, or replace details with anonymized markers like "CLIENT_A", "AMOUNT_X", "CONTRACT_2026". This preserves AI's usefulness without revealing too much.

How to anonymize prompts and documents before using AI

If the text allows identifying who or which deal it is about, the data are still sensitive. Anonymization is not for a checkbox; it's to ensure the prompt cannot be linked to a specific person, client, patient, employee or project.

Start by removing direct identifiers: full names, IIN, contract and invoice numbers, phones, emails, addresses, license plates, device serial numbers, logins, and any details that uniquely point to a record in your systems.

It's more convenient to replace elements with placeholders rather than just redacting them. The text stays understandable and AI gives useful output. For example: "Иванов И.И." -> "Employee_A", "Contract No. 18-02/24" -> "Contract_X", "г. Астана, ул…" -> "City_N".

Before sending, do a quick context check for recognizability. Sometimes the danger is not the fields themselves but unique details: a rare job title, a sole supplier, an exact amount combined with a date, or a description of an incident discussed in a meeting. If a colleague could guess the case from the description, the anonymization is weak.

A practical routine:

• Copy the text into a separate draft and work only with it.
• Replace identifiers with placeholders of a consistent format.
• Round amounts and dates when precision is not needed (for example, "in March", "about 12M").
• Remove attachments with scans, stamps, signatures and metadata.
• Reread the prompt as an outsider: can the organization or person be identified?

Store source materials separately in corporate storage with role-based access. The anonymized draft can be stored there too, but do not mix it with the original or forward it in public chats.

There are cases when it is better not to anonymize but to avoid AI entirely: customer complaints with details, medical data, internal investigations, classified documents, and any data that by law cannot be transmitted to third parties even in a modified form.

What can be safely automated with AI and bring real value

A good employee AI use policy usually starts not with bans but with clear scenarios where AI truly saves time without increasing leak risk. Give AI the form and "wrapper" of the task, but not the raw material the company must protect.

Common safe tasks where only general context is needed and internal numbers, names or contract details are not required:

• Draft emails to clients and partners (tone, structure, alternative phrasings).
• Short meeting summaries based on your notes without names and exact amounts.
• Document templates: spec structure, project plan, list of items for agreement.
• Text work: simplify, shorten, check style, translate (if the source was pre-cleaned of secrets).
• Ideas for analytics without real data: what metrics exist, how to structure a report, what questions to ask of the data.

IT and support can also benefit at a safe level. For example, an employee may ask for a diagnostic checklist "PC won't boot" or "printer won't print" describing symptoms in words but not sending logs, serial numbers, screenshots from internal systems, passwords or tokens.

There are tasks where AI should assist but the human retains responsibility: final decisions (procurement, dismissal, refusal to a client, vendor selection), legal wording and signed documents, risk and compliance assessments, and public statements on behalf of the company.

A practical approach: AI prepares options and structure; the employee verifies facts, inserts allowed data, and is accountable for the final result.

Which tools and accounts to allow and which to forbid

For work tasks use only approved tools and corporate accounts. This gives the company unified responsibility, security settings and the ability to quickly disable access on termination or during an incident.

Personal accounts for work should be forbidden. The reason is not distrust but risk: request history and uploaded files can remain in a personal profile, are harder to delete, and IT cannot control access. This is especially critical for departments handling contracts, procurement and citizen inquiries.

Fix rules about histories and logs: where and how chats are stored, who has access, when to clear history, and whether saving can be disabled. If a service saves history by default, set configurations for minimal retention where possible, and forbid exporting to third-party notes and chats.

Specify plugins, extensions and bots separately. They often request access to page contents, email or documents and must not be installed without InfoSec and IT approval. Allow only reviewed items and maintain a fixed list.

Minimum device requirements matter too. A good service won't help if a work laptop is unpatched.

In short:

• Allowed: corporate accounts, approved IT services, work devices with up-to-date updates.
• Forbidden: personal accounts for work, unauthorized plugins and extensions, moving work data to personal notes and messengers.
• By default: OS and browser updates enabled, endpoint protection active, disk encryption enabled (where available).

Example: when an employee drafts a supplier email, they do it in an approved corporate AI tool, not in a personal account, and do not enable an extension that promises to "write for you" without IT review.

Prompt and result rules: avoid surprises

Even a strong policy fails on small things: someone types "make it pretty", someone pastes an entire document, someone accepts the answer as truth. A simple standard helps: how to craft a prompt and what to do with the result.

A good prompt answers three questions: why, for whom, and in what format the result is needed. Give just enough context for the model to understand the task, but exclude secrets and unnecessary details.

A short template:

• Purpose: what exactly is needed (draft email, risk list, wording options).
• Context: only general facts (role, industry, constraints), no personal data or internal info.
• Format: length, tone, structure (e.g., "5 bullets", "table", "2 variants").
• Constraints: what not to mention, which words to avoid or use.
• Quality criteria: what will be considered "done".

Another rule: do not "paste the whole file and let it do the rest." Break large documents into parts and set narrow tasks: first extract key points, then propose a structure, then rewrite 1–2 paragraphs. It's easier to control input and output that way.

AI results must always be verified. Especially numbers, names of laws and standards, technical specs, dates, names, quotes and any confident assertions without sources. Before sending to a client or manager:

• Verify facts against the primary source (document, contract, registry, spec).
• Check logic: no contradictions or invented details.
• Ensure the text does not disclose internal information (processes, prices, terms).

Label outputs as "draft", "needs verification", "for internal use". Final versions should be stored in corporate storage and work systems, not in personal chats and notes, so it is clear who approved the text and which version is current.

Step-by-step: how to roll out an AI policy without stopping work

A policy sticks when implemented as a process change, not as a ban. Start small and make it clear to people: what they can do, what they cannot, and where to ask questions.

A five-step foundation:

• Appoint a policy owner and a small working group: IT, InfoSec, legal, HR. One person has the final word and updates.
• Describe real scenarios by department (support, procurement, finance, sales) and assess risks: which data can leak, where text errors may occur, where licenses matter.
• Record rules: which data are strictly forbidden, what is allowed only after anonymization, which tools and account types are permitted.
• Run a 2–4 week pilot with one or two teams. Collect questions and examples of "bad" prompts, refine wording, add short templates.
• Establish an exception and review process: how to request permission for nonstandard cases, who approves, how often rules are updated (for example, quarterly).

A helpful trick: publish a one-page "what to do right now" sheet alongside the rules. For example: "if a document contains full names, IIN, contract numbers or internal prices, first redact identifiers or do not use AI." This reduces mistakes more than a long regulation.

How to train employees: short practical materials, not lectures

Rules fail if people don't know how to apply them in everyday emails and documents. Training should be short, regular and example-based.

A basic session for everyone fits into 30–45 minutes. Focus on clear boundaries: which data must never be entered, which can be used after anonymization, and how to verify results before use.

Practical materials:

• a short session with "do/don't" examples and 3–4 typical tasks analyzed
• a one-page cheat sheet: bans, safe practices, where to ask questions
• a mini-quiz of 5–7 questions to reinforce understanding
• one hands-on exercise: fix bad prompts

Different roles need tailored modules because risks differ. For example: HR (resumes and candidate personal data), finance (payment details, tax docs, budgets), legal (contracts, claims, commercial terms), support (customer requests, incident details, internal instructions), procurement (specs, prices, tender conditions).

The "bad prompt vs fixed prompt" format works well:

Плохо: Суммируй договор с ТОО \"Х\" и выдели риски. (вставлен полный текст с реквизитами и ценами)

Лучше: Суммируй типовые риски в договоре поставки. Вот обезличенный фрагмент без названий, адресов, ИИН/БИН и цен. Отдельно перечисли пункты, которые нужно проверить юристу.

Provide a clear channel for questions: one email or chat where employees can quickly send a screenshot or text if they are unsure. Answers must be fast; otherwise people will "figure it out themselves."

Monitoring and responding to violations without overreach

Monitoring is not about total surveillance but ensuring the AI policy works in practice. If people fear punishment for every experiment, they will hide mistakes and risks will increase.

What to monitor

Focus on things that create real risk, not every request:

• use of unauthorized AI services and "rogue" accounts
• signs of leaks: sending contract fragments, personal data, commercial terms
• bulk exports: uploading large files and lists without clear purpose
• copying AI outputs into documents without verification when decisions depend on them

To record incidents, collect the minimum: who, when, which service, type of violation and a short description. Store prompts and responses only if necessary for investigation and with restricted access. Rule of thumb: collect exactly what is useful and nothing more.

Proportional response

A newbie mistake and a deliberate attempt to bypass rules are different. Possible measures:

• a warning and brief review
• targeted retraining using company examples
• temporary restriction of access to tools
• disciplinary measures for intent or repeated violations

Example: an employee uploaded a vendor price table to an external service. First time — log the incident, help anonymize the data and show the approved tool. Repeats justify restricting access and involving the manager.

Useful metrics are simple: how many consultation requests were made, which errors occur most often, how many repeat violations for the same reasons. This helps improve rules and training rather than "tighten the screws." In practice IT often needs process support and 24/7 backing, and such a loop can be built together with GSE.kz.

Common policy mistakes and how to avoid them

The most frequent reason for failure is simple: a document exists, but there is no clear everyday practice. A good employee AI use policy should help people work more safely, not become a formality.

Frequent mistakes

• Total ban without alternatives. People then use personal accounts and random services, increasing risk.
• Vague phrases like "don't send important data." Tomorrow someone won't know whether to paste a contract, a client email or a code snippet.
• No exception process. A project urgently needs a translation or review, but approving tool use is impossible — work stalls.
• Blind trust in AI answers. Mistakes occur in numbers, dates, links and even in "quotes" from documents.
• No policy owner and no review date. Tools change fast; rules become outdated in months.

How to avoid these traps

Instead of bans, provide safe alternatives: approved tools, corporate accounts and typical tasks (drafts, meeting summaries, templates). Add a simple verification rule: anything affecting money, deadlines, safety or legal decisions must be confirmed by a source or a person. This is especially critical in integration and procurement: one wrong SKU or clause can be costly.

Appoint a responsible party (e.g., InfoSec or Compliance) with a review calendar and a fast channel for exception requests.

Quick checklist before sending a prompt to AI

This checklist helps follow the policy without extra bureaucracy. Go through the items in 20–30 seconds.

Before sending, make sure you can honestly answer "yes" to all:

• The text contains no personal data, passwords, tokens, access keys, scanned documents, ID numbers, invoices or contracts.
• You are not pasting internal financial figures, contract terms, "insider" prices, sales plans, margins, client lists or other trade secrets.
• The task can be formulated in general terms: no unique details about a client, deal or incident. If details are necessary, anonymize first.
• You know in advance how you will verify the answer: which source you'll check, which calculations you'll recheck manually, who will approve the final version.
• You have planned where to put the result: corporate storage with a clear name, and will mark it as "draft" or "needs verification" if needed.

Rule of thumb: if you wouldn't paste this text into a company-wide chat, don't paste it into AI.

Mini-example: to "improve a supplier email", use placeholders instead of real company names, amounts and contract numbers: "supplier X", "amount Y", "date Z", and ask to improve tone and structure. AI helps with phrasing without getting sensitive data.

Practical example: procurement uses AI safely

Scenario: a procurement specialist drafts an email to a supplier (asking about delivery dates, payment terms, warranty) and a short summary for the manager. This is a good case for AI: you can speed up drafts and structure without revealing sensitive information.

To comply with the policy, the request is made "impersonal." Instead of prices, full names, contract numbers and company names, use neutral placeholders: "Supplier A", "Contract N", "Amount X", "Term Y". Even combinations of details (city, unique product, date and amount) may identify a deal, so remove anything that makes the case recognizable.

Example of a safe prompt:

Compose a polite email to a supplier.
Context: we plan to procure equipment. Need to clarify delivery date, payment terms, warranty, certificate availability and the possibility of phased deliveries.
Tone: businesslike, concise, non-pressuring.
Do not use names, contract numbers or amounts.

Then the employee reviews the result and "cleans" the text before sending externally. In practice it's useful to:

• remove any accidentally generated specific figures, company names, addresses or credentials;
• check wording for promises (penalties, deadlines, "we guarantee") — AI often sounds overly confident;
• verify facts: document requirements, payment terms, delivery terms;
• ensure the email does not reveal internal reasons for the purchase or budget limits.

If the company requires recording AI use, a short note in the email template or task card is enough: "Draft prepared with AI; final edit by employee." This helps when reviewing disputed cases.

If real data are unavoidable (e.g., analyzing specific SKUs, prices and contract terms), use a "safe perimeter": request approval from the manager and InfoSec, use an approved corporate tool or an isolated environment, and predefine which fields can be transmitted and which must be handled manually.

Next steps: how to start and where GSE.kz can help

To make the policy work, start with a simple 2–4 week plan rather than a long document. Collect real cases: ask teams to name 10–15 tasks where AI already saves time or could help (draft emails, meeting summaries, phrasing alternatives, table analysis without sensitive data). These tasks are the easiest places to test rules.

Then fix boundaries. Create a short list of data that must never be entered into AI and agree it with InfoSec and legal. Typically this includes personal data, contract commercial terms, procurement details before publication, internal passwords and keys, medical and financial information, and any details that could expose vulnerabilities.

Next decide which tools are acceptable and how: which accounts are allowed, whether personal accounts are permitted, how to store request history, who administers access. Simpler rules mean fewer workarounds.

To cement changes, the minimum is:

• appoint a policy owner (often InfoSec or IT with legal)
• select 1–2 pilot departments and run short hands-on exercises with their cases
• launch a question channel (email or chat) and promise fast responses
• agree on a clear reaction to violations: start with help and review, escalate on repeats

If your organization needs a secure AI perimeter (for local deployment and internal document handling), discuss infrastructure and support. GSE.kz as a vendor and system integrator in Kazakhstan supplies S200 servers and workstations, helps integrate AI solutions and data centers, and provides 24/7 technical support.