Writing an AI policy

Find out where the tools are already being used

Ask staff which tasks they use AI for, which accounts they use, what information goes in, and who checks the result. Make it easy to answer honestly. The purpose is to understand the work and provide a clear route for suitable uses.

List each task beside its tool, data type, output, and owner. If a use is unapproved or sensitive, pause that use while the responsible person reviews it. You can still give staff an approved way to practice with public or fictional material.

This guide is a working approach to an internal policy. The people responsible for your organization's obligations should review the draft before adoption, especially where the work involves sensitive records or consequential decisions.

Write rules that answer a real question

• Who is covered? Name the staff, contractors, volunteers, or board members the policy applies to, and the owner who answers questions.
• Which accounts and uses are approved? List the product, plan, managed workspace, permitted tasks, and prohibited actions. Say how someone requests a new use.
• What information may enter? Set the data boundary for each approved use. Include attachments and connected data sources, not just pasted text.
• Who reviews the result? Name a reviewer and backup for each recurring job. For an initial rollout, use this rule: nothing an AI system writes reaches a customer, an employee, a payment, or a public statement before a person has approved it.
• When is disclosure needed? Decide from the audience, nature of the output, organizational commitments, and applicable requirements. Separately address recordings, generated media, and direct interactions with AI. Do not assume one sentence covers every situation.
• What happens when something goes wrong? Give people a contact, a way to hold the output, and a process for handling possible exposure or incorrect actions.
• When does approval get revisited? Record a review date and triggers such as a new connection, changed vendor terms, a significant error, or a new kind of data.

Before approving a vendor, get clear answers about retention, training use, administrative access, connected services, export, and deletion. Record where the answers came from and which plan they cover.

Try the draft on a situation someone will face

Also test a public announcement, a customer reply, a proposed new tool, and an accidental upload. If two readers reach different decisions, clarify the rule or the escalation route.

Make adoption part of the work

Have the people who will use the policy review a draft. Route approval through the authority your organization actually uses; a small business and a public board will have different processes. Record the effective date, policy owner, and approved version.

Put the short decision rules where people work, with a link to the current approved-tool list. Walk through an example together. Use a Reviewer Card for recurring tasks so the policy connects to a real approval step.

Schedule an early check after rollout, then choose a review interval that fits the consequences and pace of change. The goal is a policy people can apply, with a dependable way to get an answer when it does not cover the situation.