What an AI Safety Policy Covers
An AI safety policy isn't just a document for compliance folders. It's a shared understanding of what's allowed, what isn't, and who's responsible when AI is involved in work. When it's done well, it removes uncertainty, reduces quiet risk-taking, and gives your team confidence that they're using AI in ways that help the business rather than exposing it.
A good policy covers which AI tools are approved, what data can be used with them, how AI outputs should be checked, how incidents are reported, and how often practices are reviewed. It also sets expectations around training and accountability, so AI use doesn't drift into informal habits that nobody fully owns.
If you've ever heard someone say ‘I wasn't sure if I was allowed to put that into ChatGPT, but I needed an answer quickly', that's exactly the gap a policy closes.
Write Your AI Safety Policy in Nine Steps
The steps below follow a practical order. You'll start by understanding how AI is already being used, then decide what level of risk your business can tolerate, and finally put clear, workable controls in place. You don't need to implement everything at once, but working through these stages will give you a policy that fits your business rather than a generic template that sits untouched.
This process complements other business security measures. If you haven't already created a cybersecurity policy, the steps here will overlap with that work in useful ways.
Step 1. Assess your current AI usage
Before writing any rules, you need to know how AI is already being used. In most organisations, AI arrived quietly. Someone tested a tool. Others followed. Now it's part of daily work, even if no one formally approved it.
Start by asking your team which tools and accounts they use for work, including personal accounts, meeting bots, coding assistants, browser extensions and AI features inside existing software. Record the task, the information supplied, connected systems and who owns the account. Ask what problem each tool solves, so you can offer a workable approved alternative.
The NCSC describes shadow AI as AI use outside approved organisational systems and processes. Its guidance recommends understanding staff needs and encouraging open communication. Discovery should help people disclose use early, rather than encourage them to hide it.
Once you know the tools, look at how they're being used and what data goes into them. Client details, internal documents, contracts, financial data, strategy notes. If information matters to your business, it needs protection. This mapping step becomes the foundation of your policy, and it's often the moment businesses realise how much AI use has grown without oversight.
Step 2. Define your risk tolerance
Not all businesses face the same AI risks, so your policy needs to reflect your reality rather than someone else's. A company handling sensitive personal data will need stricter controls than one working mostly with public information. A business with proprietary methods or valuable client lists has more to lose from accidental exposure. And industries built on trust, like finance, legal services, healthcare, or education, can't afford visible mistakes.
This step is about deciding where you're willing to accept low-level risk and where you aren't. Be realistic. A policy that assumes zero risk and perfect behaviour won't survive contact with daily work, and staff need rules they can follow during ordinary work. It's better to set clear priorities, protect what truly matters, and create controls you can actually maintain.
It also helps to consider your resources. If you're a small team, you'll want simple processes that fit into existing workflows. Overly complex approval chains and monitoring systems usually get bypassed, even when intentions are good. Understanding how small businesses get scammed online can help you identify which risks deserve the most attention.
Step 3. Establish approved AI tools
Your policy needs an approved-use list, not just approved brand names. Record the exact service, account type or plan, permitted tasks, allowed data, owner and review date. Approval for drafting public marketing copy doesn’t automatically allow customer records, confidential contracts or an email integration.
Check the terms and controls for the specific plan you’ll use. Look separately at model training, storage and retention, deletion, access by the provider, subprocessors and any connected systems. A promise not to train on your inputs doesn’t mean the service keeps no copy. A paid or business label isn’t enough evidence that a tool meets your requirements.
It's also important to specify what each tool can be used for. For example, a tool might be approved for drafting internal notes but not for processing client data. Another might be suitable for coding assistance but require code review before deployment. These distinctions remove guesswork and help people make good decisions without needing constant approval, because most people just want to get the work done without having to second-guess every step.
Finally, include a process for requesting new tools. AI evolves quickly, and your policy should allow room to adopt useful tools while keeping oversight in place.
Keep the list short enough to use, and explain how to request a tool or a new use. Name the person who can approve it and give staff a practical route to an answer before they upload information.
Control Integrations and Automated Actions
Approval to use a chatbot doesn’t also approve connecting it to your inbox, shared drive, customer database or payment system. Those connections can expose information beyond an individual prompt and may remain active between tasks.
- Record the systems an integration can read and the actions it can take. Give it only the access needed for the approved task.
- Start trials with read-only access where possible. Require a person to approve external messages, payments, deletions and changes to important records.
- Define who can pause the workflow, revoke its permissions and restore the manual process if it behaves unexpectedly.
- Review connected access when a role changes, someone leaves or the tool is retired. Removing a saved password alone doesn’t remove an integration’s access.
Step 4. Create data classification rules
Data rules need to tell people what they can share before they start a task. Use examples from your own work, and separate public, internal, confidential and restricted information.
Public information may be suitable for an approved tool, but still check copyright and the intended use. Internal information needs approved access and handling. Confidential information needs a specific assessment and safeguards. Restricted information, such as passwords, recovery codes and API keys, should stay out of general AI prompts. Customer, employee and health information needs a separate privacy assessment before use.
The key is clarity. ‘Confidential information' is vague. ‘Customer contact details, employee records, financial statements, contracts, proprietary processes' is clear. The more specific you are, the easier it is for staff to follow the rules without hesitation.
Removing a name doesn’t necessarily make a document anonymous. A role, address, case history or combination of details may still identify someone. Use synthetic examples where possible, and don’t upload a full document when a short, authorised extract will do.
For UK personal information, use the ICO’s current AI and data-protection resources when assessing your obligations. This policy is an operational starting point, not evidence that a use is legally permitted.
Step 5. Set output verification requirements
AI tools make mistakes more often than many people realise. They hallucinate facts, invent sources, and deliver answers with confidence that can feel reassuring. The tricky part is that they often sound right, even when they're wrong.
Your policy needs to define how AI outputs are checked before they're used. Not every output requires the same level of scrutiny. Internal brainstorming notes might only need a quick scan. Client-facing emails, financial analysis, legal clauses, or public-facing content need proper review. Someone still owns the final output. AI doesn't.
It also helps to be explicit about what verification looks like. Sometimes it's fact-checking against source documents. Sometimes it's checking tone and brand alignment. Sometimes it's testing functionality. When you spell this out, people stop guessing what ‘review' means and start applying it consistently, which is usually when quality improves without the process feeling heavier.
With the rise of AI-generated impersonations, verifying the authenticity of communications from clients and suppliers has become increasingly important alongside verifying your own AI outputs.
Name a reviewer with the skills, time and authority to reject the output. For factual writing, open and check the original sources. For figures, recalculate against the source data. For code, test behaviour and review security. For contracts or decisions affecting people, obtain the appropriate specialist review. A quick approval click isn’t meaningful oversight.
Step 6. Address bias and fairness
We already know AI systems can amplify existing bias, and that becomes a business risk when AI influences decisions about people. Recruitment, customer service, credit decisions, performance assessments, and access to services all fall into this category.
Your policy should require human oversight for high-stakes decisions. AI can support, but it shouldn't be the final decision-maker where fairness, legality, or reputational risk is involved. Saying ‘the system decided' won't protect a business if harm occurs.
It's also worth building in periodic checks for patterns that don't feel right. Reviewing samples of decisions, looking for consistent disparities, and giving people a way to question AI-assisted outcomes helps catch problems early.
Step 7. Define incident reporting
Even with good controls, things can go wrong. Someone might enter data they shouldn't. A tool might behave unexpectedly. An AI-generated message might go out with an error that matters.
Your policy should explain what counts as an AI-related incident and how it's reported. Make reporting straightforward. A named contact. A shared inbox. A simple internal channel. When raising a concern feels easy, people speak up sooner, and when people speak up sooner, small problems stay small.
Give staff a first-response checklist. Stop further uploads or automated actions, tell the named owner promptly, and record the service, account, time, data type and connected permissions. Don’t paste the exposed information into another chatbot or an ordinary support ticket. If a credential was exposed, follow your security process to revoke or rotate it and check related access.
The owner should assess what actually happened, preserve necessary evidence securely, contact the provider where appropriate and decide whether contractual or regulatory notifications are required. Not every AI mistake is a reportable data breach. Deleting a chat alone doesn’t establish that all copies or access have been removed.
Step 8. Training and culture
A policy only works if people understand it. Training doesn't need to be complicated, but it should explain what's expected, why it matters, and how to apply the rules in everyday situations.
Use examples that feel familiar. A client email drafted with AI. A spreadsheet summary generated by a tool. A rushed moment when someone is tempted to paste sensitive data for convenience. When people recognise themselves in scenarios, guidance sticks.
Culture matters too. If your environment rewards speed over care, people will take shortcuts. If you make it clear that safe AI use is valued, supported, and expected, behaviour follows, and you'll notice people get more careful and more confident when they know asking ‘is this allowed?' won't be treated like a silly question.
Practical training on how to spot AI-powered phishing and deepfake scams should form part of your broader AI safety training programme, as these threats continue to evolve.
Give staff a safe route to report mistakes and ask about unapproved tools. Explain the rules to contractors as well as employees, and include account access and integrations in onboarding and offboarding.
Step 9. Review and improve
AI changes quickly, and your policy can't be static. Build in regular review points to check whether tools are still appropriate, whether rules still make sense, and whether new risks have appeared.
Set a review interval that fits the risk, and review sooner when the plan, terms, model, integration, task or data changes. Recheck permissions and remove access that’s no longer needed. Legal obligations depend on your location, sector and use, so check current official guidance before introducing a consequential application.
Feedback from your team is valuable here. If people are confused, bypassing steps, or unsure how to apply rules, your policy needs refinement. A policy that looks good on paper but doesn't work in practice won't protect you.
A Short AI Safety Policy You Can Adapt
The clauses below are a starting point for ordinary workplace tools. Replace the placeholders, attach your approved-use list and adapt the rules to your sector and obligations before adopting them.
- Ownership. [Named owner] maintains the policy and approves new services or uses. [Backup contact] handles questions when they’re unavailable.
- Approved use. Staff and contractors may use only the service, account type, task and data listed in the approved-use register. Personal AI accounts aren’t approved for company information unless that use has been assessed and authorised.
- Data. Share only the minimum information allowed for the task. Don’t put passwords, API keys or recovery codes in general AI prompts. Customer and employee information requires the recorded privacy assessment and controls.
- Review. The task owner remains responsible for the final work. [Named reviewer or role] checks relevant facts, figures, sources and risks before an output is sent, published or acted on.
- Connections. Connecting company systems or allowing automated actions needs separate approval of the permissions and a documented way to stop the workflow.
- Reporting. Report suspected exposure, incorrect consequential output or unexpected access promptly to [contact route]. Stop the affected activity and share only the details needed to investigate securely.
- Maintenance. Review the policy and register on [date or interval], and after a material change or incident. Provide staff with an approved alternative and a route to request new tools.
Test the draft with a familiar scenario: a colleague wants to summarise a client contract. Can they identify the approved account, allowed information, reviewer and contact for a mistake without guessing? If not, revise the policy before issuing it.
Make Your Policy Work in Real Life
A policy sets the rules; governance is the ongoing work of applying them. The NIST AI Risk Management Framework organises risk management around Govern, Map, Measure and Manage. It’s a voluntary framework, not a compliance certificate. For a small team, a named owner, an approved-use register, useful review checks and a maintained incident route are a practical place to start.
The most effective AI safety policies are written in plain language, easy to access, and clearly owned. They don't live in forgotten folders. They're referenced, discussed, and updated as part of normal operations.
Support your policy with practical alternatives. If you restrict certain tools, provide approved ones that meet genuine business needs. If you require output verification, make sure people have time to do it properly. Safe behaviour is much easier when the environment supports it.
A useful policy gives someone a clear answer in a rushed moment: which account to use, which information is allowed, who checks the result and where to report a problem. Keep those answers accessible and test them with real examples from your team.
