How to write an AI policy for your company

Why does a company need an AI policy?

An AI policy is a short document that tells staff how AI may be used at work. It covers which tools are allowed, what information can be put into them, when a person must check the output and who decides about new uses. Without one, each person decides alone, and the risks pile up unseen: confidential material pasted into the wrong tool, unchecked answers sent to customers, and spending nobody tracks. A good policy is brief, written in plain words and easy to find. A policy nobody reads protects nobody.

Below are the sections worth including, who should approve each one, and the mistakes that make a policy fail in practice.

Why write the policy before the tools?

Start by finding out how people already use AI in their daily work : ask each team which tools they use, for what, and with which information. Expect surprises, such as personal accounts. Ask without blame, because you want honest answers, and write down what you hear.

A policy written from guesses misses the real risks. One written from what people actually do gets followed.

What should the policy say about data?

Five sections cover most companies: purpose and scope, the approved tools list, data rules, human review and approval. Purpose and scope say who and what the policy applies to. The tools list names what is allowed. Data rules set limits on what goes in. Review says when a person must check the output, and approval says who decides about anything new.

Keep the policy short enough to read in ten minutes. Use plain words, add examples from your own teams, and link to the approved tools list. Ask a few staff to read a draft and say where they would get stuck, then fix those places.

Which tools are approved?

The section most often skipped is the one that names who approves what. Without a named approver, requests for new tools sit unanswered and people go around the rules. Choose a person or a small group, and give them a target time to reply.

Then write the data rules. Split information into three simple groups: never enter, enter only with approval, and fine to enter. Customer records, contracts, credentials and personal data usually sit in the first two. Give examples from your own work, because examples are easier to follow than definitions.

Who reviews and approves AI use?

Keep a short approved tools list with what each tool is for, who may use it and what data it may touch. Update it whenever a tool is added or removed, and publish it where everyone can find it.

Plan the review. Set a date, perhaps every quarter at first, and ask the owner to check three things: whether the tools list is current, whether any incident or near miss shows a gap, and whether the rules still fit how people work. Where people break a rule, find out why. The rule may be impractical, the approved tool may be poor, or the training may have been missed. A policy that changes after real use is a policy that works.

How often should you review it?

Training matters as much as the text. A one-hour walk-through with examples from each team beats a long document. Teams in finance and other controlled functions know the value of a written rule well, which is why our guide for finance teams shows how the same care applies to controls, review and reporting in daily work.

A second mistake is writing a ban. If you forbid everything, people use AI in secret and you lose sight of it. Offer approved tools that do the job, say clearly what is off limits, and make it easy to ask for something new.

Who for?

This is why the Embedded Week suits policy work. We sit with your team for a week, watch the real work and see where AI is already used or could help. Afterwards we build a custom solution for your company and train your team to run it. To talk it through, book a meeting.

Checks

Note 1: this is not legal advice. An AI policy is an internal operating guide. Laws and sector rules differ by country, so ask a qualified adviser what applies to you, and have them read the policy before you publish it.

Note 2: keep a record of approvals. Store who approved each tool or use, and when, so you can answer questions later.

Note 3: test the policy on one team first, then adjust the wording before you roll it out widely.