What you can explore
1. What problem would this solve?
Staff need workable rules for tools, confidential information and review. An abstract rule like “be responsible” does not tell someone what to do with a confidential attachment or an unverified draft.
2. What could become easier?
- Know what is okay to share.
- Have a simple approval route.
- Respond clearly when something goes wrong.
The aim is to make a clearer decision, with practical checks before relying on AI output.
3. What practical support could include
A possible starting point: A plain-language internal AI-use guidance workshop. A scoped engagement might produce:
- Approved-use and prohibited-use table
- Data-classification examples
- Human-sign-off and escalation chart
- Draft staff FAQ and usage checklist
- Policy review and ownership schedule
Any practical support would be scoped to the task, available information and agreed responsibilities.
4. Why this approach?
We translate actual employer rules into approved-use examples, a practical escalation route and scenario-based questions. Legal and security owners retain approval authority.
5. What evidence supports these recommendations?
The sample clauses are only drafting examples; NIST, OWASP, Microsoft and EU materials support different parts of the risk discussion, not universal compliance.
6. How might we work together?
Identify approved tools and data classes; draft plain rules; test staff scenarios; route the text to responsible reviewers.
Practical guide: how to make this decision
Sample staff-facing AI rule card (not an approved company policy)
Before using AI: Check that the task is authorized and the account is approved for the category of information. Do not paste a real client contract, password, personal health record, employee file or other restricted data into an unapproved service. If in doubt, ask the designated security or governance contact.
While using AI: Give the tool only the permitted facts. Ask for a source for any consequential statement. Keep a named human responsible for decisions about people, money, safety and regulated work.
Before sharing an output: Compare factual claims to the approved original material, remove invented references, check personal information, and record who approved it. A policy, employee handbook or legal obligation must be reviewed by authorized organizational specialists before being described as binding.
Escalation example: A staff member asks whether a supplier may be approved despite a missing verification document. The assistant may help identify the relevant policy section; it must not invent a waiver or grant approval. Under the European Commission's explanation of amended Article 4, AI-literacy obligations are context-dependent; this illustrative card is not proof of compliance [EUAI].
Evidence and important limits
- The European Commission says Article 4 AI-literacy obligations apply, while mid-July 2026 amendments changed their wording. [S01]
- NIST AI 600-1 is a voluntary generative-AI risk-management profile published 26 July 2024. [S02]
- Article 4 requires providers/deployers to support context-appropriate staff AI literacy; the law does not mandate a defined individual competence level. [S03]
- OWASP describes prompt-injection threats and practical mitigations; it does not establish that the user’s system has a vulnerability. [S04]
Evidence references
What is a staff-friendly AI-use policy?
A staff-friendly policy tells an employee what they are allowed to do with AI during ordinary work, what information must be protected and what to do if they are uncertain. It should be short enough to use in the moment but linked to the organization's actual security, privacy and records rules. A document that says only “use AI responsibly” is not a workable guide. For example, a receptionist should know whether an approved assistant may help draft a generic public reply, whether customer details may be entered, and who signs off before the message is sent. NIST's generative AI profile supports the importance of risk governance, documentation and practical context [NIST]. It is a voluntary framework, not a policy template that automatically creates legal compliance.
Identify the policy owner and actual tool environment
Before writing rules, record who can authorize AI tools, which work accounts are configured, which departments are covered and which existing policies already govern records and confidential information. A staff guide cannot contradict an information-security policy or promise access protections that have not been verified. An AI product's privacy terms may vary according to account type and configuration; for example, Microsoft describes particular enterprise-data-protection arrangements for signed-in work or school users of Copilot Chat [MS_PRIV]. That information should not be generalized to every product. A policy must reference the actual approved system, not an imaginary “company AI” environment. If tools have not been approved, the guide should explain how staff request evaluation before use.
Create a decision table for everyday information
Classify sample content using the organization's own data rules rather than a universal label chosen by the content writer. A simple teaching table might distinguish public information, internal but permitted templates, confidential client records and regulated or specially protected material. The following examples are illustrative; real authorization requires an internal decision.
| Employee wants to use |
Example action |
Draft rule to consider |
Who decides |
| Public webpage |
Generate a summary for private reading |
May be allowed in approved tool, with source check |
Policy owner |
| Approved internal template |
Reword instructions for an internal draft |
Allowed only if tool and data class are approved |
Team lead + security policy |
| Client file |
Ask a public chatbot to analyze details |
Do not upload without explicit approval |
Authorized data owner |
| Passwords or access secrets |
Paste into any AI chat |
Prohibit in ordinary prompts |
Security authority |
| Employment or other consequential decision |
Let AI make final decision |
Require qualified human decision and specialist review |
Responsible decision owner |
The table is not jurisdiction-specific legal advice. The employer must adopt rules based on actual data categories, law and operational needs.
Draft clauses in language employees can act on
An acceptable-use clause might read: “Use only the AI tools approved for your team. Do not enter confidential, personal or restricted information unless that specific use is authorized.” A review clause might say: “Check facts, names, quotations, calculations and commitments before using an AI-generated draft. The employee using the draft remains responsible for the final work.” An escalation clause might say: “If the tool reveals information you did not expect to see, stop and report the issue through the security contact.” These are illustrative clauses for discussion. They must be adapted and reviewed by the appropriate authority before being adopted. Good policies name a real team, contact channel or existing internal procedure instead of sending employees to an unspecified “administrator.”
Explain tool limits without frightening users
Employees should learn that a fluent AI answer may be inaccurate and that text generated from a document does not automatically establish the current version, legal validity or full context. A policy can list the types of outputs requiring source checking—external claims, personnel matters, financial reports and statements that create organizational obligations—without treating every brainstorming idea as equally consequential. Encourage staff to ask for missing information rather than encourage the model to guess. Where the task is already handled by an approved template, the policy can recommend that template. The goal is to make safer choices easy to recognize, not to issue an abstract warning that AI is dangerous.
Include the path for exceptions and incidents
A useful policy answers three questions: What if the employee accidentally shares restricted information? What if an AI-generated claim is discovered after it was used? What if a colleague asks them to automate a decision they are not authorized to make? The guide should direct staff to the existing security or incident process, preserve necessary records under applicable retention rules and avoid making unauthorized corrections that worsen the issue. OWASP's 2025 LLM risks include sensitive information disclosure and improper output handling [OWASP]. These categories support the need for clear escalation, but they do not prove that a particular workplace has suffered an incident. The organization should define its own response roles and reporting channel.
Test the policy with realistic staff questions
Give employees scenarios and ask them to choose an action. Example A: “Can I paste a published product description into the approved tool to shorten it?” Example B: “Can I upload an unredacted customer contract into my personal assistant?” Example C: “The assistant invented a date in a public message—what should I do?” Example D: “A manager wants the assistant to send replies automatically, without review.” Record where participants misunderstand the rules. If they cannot answer a common case, the policy needs clearer examples or an easier approval process. A concise FAQ derived from genuine confusion is more useful than repeating the same warning in different words.
Consider jurisdiction and sector without universal claims
Requirements differ by location, sector, tool and type of AI use. In the European Union, Article 4 of the AI Act concerns measures supporting AI literacy for people operating or using AI systems on an organization's behalf. The European Commission's updated guidance notes changes entering into force during 2026 and clarifies that the law does not mandate an identical individual proficiency level for everyone [EU]. That point should be considered only where EU requirements apply and verified with qualified legal counsel as needed. Data protection, employment and professional rules may require separate analysis. This page offers a method for drafting clear internal guidance, not an assertion that one generic policy meets every country's obligations.
Make the policy a maintained workplace tool
Record a named owner, effective version, review triggers and where staff will find the current document. Review when a new AI tool is approved, an account configuration changes, a workflow starts taking actions or an incident reveals a gap. Keep a short record of staff questions and approved answers, and update examples when workflows change. For accessibility, provide short headings, an approved/prohibited-use table and a clear route for questions. A training session can then use actual policy scenarios instead of asking participants to memorize generic principles. The deliverable is a proposed, comprehensible internal guide ready for employer review—not a promise of certification, a legal opinion or a finished security implementation.
