Do You Need an AI Use Policy for ChatGPT & Copilot at Work?
Yes — if your team uses ChatGPT, Copilot, or Gemini, you need an acceptable-use AI policy, because the alternative is "shadow AI" running with no rules at all. Here is what that policy should cover, and why writing it is only half the job.
The short answer: yes — and it is mostly about the tools you did not approve
If people in your organization use generative AI for work — and unless you have actively blocked it, they almost certainly do — you need a written policy that says what is and is not allowed. This is true even if you have never bought an AI product in your life. The moment an employee opens ChatGPT, Copilot, or Gemini in a browser tab and pastes in part of their day job, your company is using AI, whether or not anyone decided to.
The real driver behind an AI use policy is not the tools you formally adopted; it is the ones nobody told you about. This is what people mean by "shadow AI": staff quietly using free or personal AI accounts to draft emails, summarize documents, write code, or analyze data, outside any approval, contract, or oversight. It is the same dynamic as shadow IT a decade ago, except the data leaves faster and the output is harder to verify. A policy is how you bring that activity into the light — not by pretending it isn't happening, but by setting clear rules for the people who are already doing it.
None of this is about banning AI. Used well, these tools are genuinely useful, and a blanket prohibition usually just pushes usage further underground. The goal of a workplace AI policy is to let people get the benefit while protecting your confidential data, your customers, and your obligations. This is general information, not legal advice, and the right policy for your business depends on facts a qualified advisor should review.
The real risks of unmanaged employee AI use
When AI use happens with no rules, a handful of specific risks tend to show up. They are worth naming concretely, because a good policy is essentially a response to each one.
Confidential and customer data leaving your control. This is the headline risk. An employee pastes a customer list, source code, an unreleased contract, or personal data into a public AI tool to get help with it. What happens next depends on the tool and the account: free and consumer tiers may, depending on their terms and your settings, use submitted inputs to help improve the provider's models, whereas business and enterprise tiers typically commit by contract not to train on your data. Either way, you have sent sensitive information to a third party — which can itself trigger privacy and contractual obligations — and most employees have no idea which tier they are on or what the setting says.
Intellectual property, licensing, and ownership questions. Two distinct issues live here. First, what you put in: feeding someone else's copyrighted or licensed material into a tool may breach the terms you agreed to. Second, what you get out: the ownership and copyrightability of purely AI-generated content is genuinely unsettled, and output can also resemble existing protected work. Treat these as risks to manage in your policy, not as settled questions with a clean legal answer.
Over-reliance on inaccurate output. Generative AI is fluent, confident, and sometimes simply wrong — it can fabricate facts, citations, figures, and code that looks right and isn't. The danger is not that AI makes mistakes; it is that polished, plausible output invites people to skip the checking. Unverified AI output dropped into a client deliverable, a financial model, or production code is a real liability.
Privacy and regulatory exposure. If your business handles personal data, health information, or financial records, pushing that data through an unapproved AI tool can collide with privacy rules and the data-protection commitments you have made to customers and regulators.
Shadow AI itself. The meta-risk is simply not knowing. If you cannot say which tools are in use, on what data, by whom, you cannot manage any of the risks above — which is exactly why the first job of a policy is to replace the unknown with a known, agreed set of rules.
What an acceptable-use AI policy should cover
An acceptable-use AI policy translates those risks into plain rules people can actually follow. It does not need to be long, but it should be specific. Aim to cover the following.
Approved tools. Name the AI tools your organization permits and, ideally, the account type or tier people must use (for example, the company's licensed business account rather than a personal free login). Make it clear that anything not on the list needs approval before it touches company work. Vagueness here is what produces shadow AI.
What data may and may not be entered. This is the heart of the policy. Spell out, in concrete terms, the categories of information that must never be pasted into AI tools — customer data, personal data, health or financial records, credentials, source code, trade secrets, anything under NDA — and what is fine to use (public information, general questions, non-sensitive drafts). Tie the rules to your existing data-classification scheme if you have one.
Mandatory human review. Require that a competent person reviews and verifies AI output before it is used, especially anything that goes to a customer, into a public-facing channel, into code, or into a decision that affects people. The person who used the tool owns the result; "the AI wrote it" is not an excuse for an error.
Disclosure. State when and how the use of AI must be disclosed — to managers, to customers, or in a deliverable — and label AI-generated or AI-assisted content where your contracts, your customers, or applicable rules expect it.
Prohibited uses. Be explicit about what AI must not be used for. Common examples: making consequential decisions about people (hiring, firing, credit, discipline) without human judgment; generating anything deceptive or impersonating a real person; bypassing security controls; or any use that would violate law, contracts, or your other policies.
Ownership and IP handling. Set expectations on inputs and outputs: do not feed in material you are not licensed to use, treat AI output as a draft requiring human authorship and review, and follow your normal IP and confidentiality rules. Given the unsettled legal landscape, the policy should steer people toward caution rather than promise certainty.
Roles and reporting. Name who owns the policy, how someone requests a new tool, and how to report a mistake — such as confidential data accidentally pasted into a public tool — without fear, so problems surface early instead of staying hidden.
How this fits into broader AI governance — and where it stops
An acceptable-use policy is the entry point to AI governance, not the whole of it. It is the ground-level rulebook for everyday users; broader governance frameworks address how an organization manages AI risk across its full lifecycle. It helps to know the names your customers and auditors will raise — without confusing any of them with certification.
NIST's AI Risk Management Framework (AI RMF) is a voluntary US framework organized around four functions — Govern, Map, Measure, and Manage — for building trustworthy AI practices. It is guidance you adopt, not a certificate you earn. The EU AI Act is the EU's binding law on AI, and the part most relevant to a workplace policy is its AI-literacy duty (Article 4): organizations are expected to make sure staff who deal with AI on their behalf have a sufficient level of understanding — which is precisely what a clear policy plus training delivers. The Act's risk tiers and obligations phase in on a staggered timeline, and the details continue to be shaped by guidance, so confirm the current specifics and dates that apply to you in the official EU text rather than relying on any one summary. ISO/IEC 42001:2023 is the international standard for an AI management system — a structured way to govern AI across its lifecycle, analogous to what ISO/IEC 27001 does for information security.
Here is the line that matters: none of these makes you "certified" or "compliant" because you wrote a policy or bought a template. A policy and a toolkit give you the documentation and the rules these frameworks assume you have. ISO/IEC 42001 certification comes only from an accredited certification body after it audits a working management system; conformity with a law like the EU AI Act comes from actually operating the required controls, not from owning a document. What good governance documentation does is give you the backbone — and an acceptable-use policy is usually the first, most useful piece of it. If you are building that backbone, an editable AI Governance Policy Pack covers the acceptable-use, human-oversight, and disclosure documents described above, and an ISO 42001 AI Management System Toolkit gives you the wider management-system structure — both as starting points you tailor to how your organization actually works.
A policy sets the rules — you still have to enforce them
The honest part: writing the policy is the easy half. A document in a shared drive that nobody reads, and that nothing backs up, changes very little. Employees defaulted to convenient AI tools before you had a policy, and they will keep doing so unless the approved path is at least as easy and the rules are real.
Enforcement is a mix of people and technology, and you need both. On the people side, train staff so they understand not just what the rules are but why — what can go wrong, and what to do when they slip. Make the sanctioned tools genuinely available, because the single best way to reduce shadow AI is to give people a good, approved option instead of only a list of prohibitions. Have a clear, blame-aware way to report mistakes so an accidental paste of confidential data gets reported in minutes, not buried.
On the technical side, do what your environment allows: provision approved AI tools through managed company accounts with the right privacy settings, and consider controls such as data-loss-prevention rules or restricting unsanctioned tools on managed devices, sized to your risk and resources. And treat the policy as living — review it on a defined cadence, because the tools, their features, and the rules around them change quickly, and a policy written a year ago may already name the wrong tools or miss new capabilities.
The realistic picture is straightforward. A policy is necessary, and it is not sufficient. It tells people what good looks like; training, sensible technical controls, an easy approved path, and regular review are what turn the words into actual behavior. Build the document, then do the unglamorous work of making it true.
Frequently asked questions
- Do we really need an AI policy if we only use free tools like ChatGPT?
- Yes — arguably more so. Free and consumer AI accounts are exactly where the data and oversight risks concentrate, because depending on the terms and settings, submitted inputs may be used to help improve the provider's models, and you have no business contract governing the data. If staff are using personal or free AI accounts for work ("shadow AI"), a policy that defines approved tools, what data may be entered, and required human review is how you bring that activity under control rather than leaving it ungoverned.
- What is the most important thing an AI use policy should cover?
- The rules on what data may and may not be entered into AI tools. That single section addresses the biggest risk — confidential, customer, personal, or regulated information leaving your control through a third-party tool. Close behind it are naming the approved tools (and account tier), requiring human review and verification of AI output before it is used, and listing prohibited uses. Tie the data rules to your existing data-classification scheme if you have one.
- Is an AI use policy the same as following NIST AI RMF, the EU AI Act, or ISO 42001?
- No. An acceptable-use policy is the ground-level rulebook for everyday users; those frameworks are broader. The NIST AI Risk Management Framework is voluntary US guidance built around four functions (Govern, Map, Measure, Manage); the EU AI Act is binding EU law (its AI-literacy duty for staff, Article 4, is the part a workplace policy most directly supports, and its obligations phase in on a staggered timeline you should confirm in the official EU text); and ISO/IEC 42001 is the standard for an AI management system. A policy is usually the first piece of the documentation these assume you have, but it is not the same as adopting any of them in full.
- Does buying an AI policy template or toolkit make us compliant or certified?
- No. A template sets the rules and gives you the documentation, but no document set by itself makes an organization compliant or certified. ISO/IEC 42001 certification comes only from an accredited certification body after it audits a working AI management system, and conformity with a law such as the EU AI Act comes from actually operating the required controls. A good toolkit removes the slowest part — the drafting — so you can focus on the parts only your organization can do: implementing the rules, training staff, and enforcing the policy.
- How do we actually enforce an AI policy once it is written?
- Through a combination of people and technology, because the document alone changes little. Train staff on the rules and the reasons behind them; make approved AI tools genuinely available through managed company accounts so people have an easy sanctioned path; use technical controls such as data-loss-prevention rules or restrictions on unsanctioned tools where your environment allows; and provide a blame-aware way to report mistakes quickly. Then review the policy on a regular cadence, since the tools and the rules around them change fast.
Related guides: AI Governance (EU AI Act & NIST AI RMF)
Toolkits that help
AI Governance Policy Pack
10 editable AI policies aligned to the EU AI Act and NIST AI RMF, plus an AI risk register — govern workplace AI before regulators and clients ask.
