Start with a policy people can follow
A useful AI policy answers a question that comes up during ordinary work: “Can I put this into that tool?” If the answer requires someone to interpret a long document, they may guess or avoid using AI altogether. Keep the main policy short, name a person who can answer questions, and maintain a separate list of approved tools that can change as the team’s needs change.
Set the policy’s scope explicitly. For example: “This policy applies to anyone using AI tools for team work, including employees and contractors. It covers text, images, audio, code, files, and information pasted into a chat or connected through an integration.” Make clear that using a personal account for work does not put it outside the policy.
Define what an approved tool means
An approved tool is one the team has reviewed for a specific use, not a blanket promise that every feature is safe. Your tool list can record the product, approved account or workspace, permitted tasks, allowed data category, required settings, tool owner, and date of the next review. A team might approve one workspace for drafting public-facing copy while limiting another tool to experiments with made-up data.
Before adding a tool, check the controls that matter to your team. These may include who can access the workspace, whether conversations or uploaded files can be retained or shared, available settings for use of submitted content, and whether connected apps can read more information than intended. Record what you verified rather than assuming a familiar product name guarantees the same protections across every plan, account, or feature.
A simple policy sentence is: “Use only tools and accounts on the approved list for team work. Do not enable new integrations, upload files, or switch to a personal account to bypass a restriction. Ask the tool owner to review a new use case before trying it with real team data.”
Draw a firm line around prohibited data
List data that must not be entered into AI tools unless a named owner has explicitly approved a specific tool and workflow for it. A practical default prohibition includes passwords, access tokens and recovery codes; private customer or employee information; unpublished financial or business plans; confidential client materials; internal security details; and material received under a confidentiality obligation. Include screenshots, attachments, code repositories, meeting recordings, and connected data sources: sensitive information can enter a tool without being pasted into a prompt.
Clarify what people can use instead. Public information, original non-sensitive drafts, and fictional or thoroughly de-identified examples may be suitable for an approved tool. Removing a name alone may not make a record safe if its remaining details identify a person or reveal a confidential project. When in doubt, replace specifics with placeholders, describe the task at a higher level, or ask for approval before submitting anything.
You can express the default as: “Do not submit prohibited data to an AI tool, even to summarize, translate, troubleshoot, or redact it. If a task requires sensitive information, stop and request an approved workflow.” This is easier to apply than a vague instruction to “use good judgment.”
Specify acceptable uses and required review
Name a few permitted activities so the policy supports useful work. Examples might include brainstorming with non-sensitive context, outlining a document, rewriting a public draft for clarity, or generating sample code that contains no secrets or private data. Approval to use a tool does not mean its output is approved for publication, deployment, or a decision affecting someone else.
Require a person to review outputs before use. The reviewer should check factual statements, calculations, links or citations, tone, and whether the output includes information the team should not disclose. Code needs testing and review under the team’s normal process. For consequential decisions, AI can help organize questions or draft options, but an accountable person should make the decision using appropriate evidence.
Give the policy an exception and incident path
People need a way to request exceptions without making them informally. Ask them to state the task, proposed tool, data involved, intended audience, and why an approved alternative will not work. The designated owner can approve a limited workflow, reject it, or request changes. Document approvals so they do not become an unclear precedent for every future task.
Also explain what to do after a mistake: stop using the affected conversation or integration, avoid sharing the output further, and promptly tell the designated owner what tool and data were involved. The owner can assess next steps under the team’s existing privacy and security procedures. Encourage prompt reporting rather than asking people to decide on their own whether an exposure matters.
Review the tool list when accounts, features, integrations, or team workflows change. The policy itself can remain stable: approved tools for defined tasks, prohibited data by default, human review of outputs, and a clear route for questions. Those few rules give a small team a usable starting point without pretending that every AI use has the same risk.
