In brief
- The policy must be short enough for daily use and precise enough for real decisions.
- Approved tools and data classes need a maintained, easy-to-find list.
- Obligations depend on impact: a draft, recommendation and automated action are not equivalent.
- Training, support contacts and technical controls are part of implementation.
Define scope and purpose first
The policy should cover external and internal AI tools, embedded AI features and custom applications. It should also state the organisation’s goals and the principles that always apply.
- Which employees, entities and external partners are covered?
- Does it include chatbots, copilots, agents, APIs and AI embedded in business software?
- Which existing privacy, security, copyright and communication rules still apply?
- Who owns the policy, its updates and exception decisions?
Describe permitted use concretely
A generic instruction to use AI responsibly offers little help. Employees need examples of permitted, restricted and prohibited activity and a current catalogue of approved tools.
| Rule level | Typical examples | Required employee action | Control behind the policy |
|---|---|---|---|
| Permitted | Summarise public material, improve wording or create an internal draft in an approved company account. | Check the result before use and follow normal confidentiality and copyright rules. | Approved-tool catalogue, company login and basic logging without unnecessary content. |
| Only after approval | Use confidential contracts, customer records, employee data or connect an AI feature to a business system. | Submit the use case, data classes, recipients and planned review to the responsible function. | Risk-based review, restricted roles, retention settings, test cases and documented release conditions. |
| Prohibited | Enter passwords or secrets, upload unapproved sensitive data, bypass access controls or let AI make consequential decisions without a reviewed basis. | Stop, use the named safe alternative and report accidental disclosure or suspicious behaviour immediately. | Technical blocking where feasible, incident route, sanctions proportionate to intent and a usable approved alternative. |
Human accountability must be explicit
The policy should state that AI output requires review and that a person remains responsible for its use. Review depth follows the potential harm and reversibility of an error.
- Verify facts and sources before external or business-critical use.
- Do not rely on AI alone for decisions with significant effects without a reviewed legal and process basis.
- Require explicit confirmation or approval before consequential actions.
- Report errors, suspicious output and prohibited use through a known channel.
A policy needs an operating process
Products and features change faster than normal policy cycles. A stable core document should therefore link to dynamic schedules for tools, data classes and contacts.
- Step 1
Publish
Make the policy, quick rules and current tool list available in one familiar place.
- Step 2
Enable
Deliver role-based training using realistic examples and exercises.
- Step 3
Support
Provide a fast route for questions, new tools and exception requests.
- Step 4
Review
Use adoption, incidents and provider changes to update the policy regularly.
Example: A policy with two layers
A one-page quick guide tells employees which company tools are approved for public, internal and confidential data. A detailed schedule covers approvals, roles, documentation and exceptions. The tool list is updated monthly without reopening the entire core policy.
What to remember
Write the policy around common work situations. Every rule should lead to a clear action, a support contact or a safe alternative.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed
Reviewed 17 July 2026. General information, not legal advice. The specific legal position and applicable scope must be assessed for each use case.