What should a company’s first AI policy cover?

Your staff are already using these tools, so the policy should start by saying what is safe. A flat ban mostly pushes the use out of sight, onto personal phones and personal accounts, where you can see nothing.

Say what data can go into which tool

Start with data, because that is where the real exposure sits. Some free consumer tools may keep what people type, and some may use it to improve their models, depending on the plan and the settings. Read the terms of every tool you allow, then write the rules in a few plain groups.

• Customer personal data and customer contracts go only into tools the company has approved for that purpose.
• Source code, pricing and unreleased financial results stay inside approved company accounts.
• Public information and general drafting can go into most approved tools.
• Staff do not use personal accounts for work, because the company usually cannot see or delete what is stored there.

A sales team tidying customer proposals in a free chatbot, names and prices included, is the usual first case. Nobody told them not to. A short data rule and a company account for the tool give the team a safer way to do the same work.

Name the approved tools and who checks the output

Give staff a short list of approved tools and a simple way to ask for a new one, and name the person who answers those requests. If asking is slow or unclear, people go around it.

The policy should also say who is responsible for what AI produces. The answer is the person who uses or sends it. AI can write a wrong answer in a confident voice, so anything that reaches a customer or a regulator needs a person who has read it and stands behind it.

Add a separate line for decisions about people. Hiring, firing, pay and credit decisions carry legal duties that differ by country, and they should not be handed to a tool without review by someone senior. Say too whether staff must tell customers when AI helped produce the work, since some contracts and some regulators expect it.

Keep it short and set a review date

A policy that runs to many pages is less likely to be read. Two pages is a good limit for a first version. Use everyday words, give a few examples of what is allowed and what is not, and name one accountable person, often the COO, the CIO or a risk lead.

Test it before you publish it. Ask a few people in different teams to explain the rules back to you in their own words. If they cannot, the policy is too long or too vague.

Tools and laws change quickly, so put a review date in the document and say whom staff should tell when something goes wrong. Make it easy for staff to report mistakes early, before a small leak becomes a larger one. Setting rules like these is part of our AI strategy and governance work.