twimco.Let’s talk ↗︎
Menu
Field notes / AI & judgment

Your team already uses AI. Write the policy for that team.

If the policy says no AI and people are pasting customer emails into a chatbot on their phones, the policy isn't working. These are the questions worth answering before you write one more rule.

Editorial engraving of a bright office kitchen where four colleagues of different ages stand at a counter sorting blank cards into green, ochre and terracotta folders and a small locked tin, with a phone and laptop among them.

A useful AI policy for a small or mid-sized team starts from what people already do. Find out which tools are in use and for what, without punishing anyone. Sort your data into what can go into an approved tool, what needs a business account whose terms you have checked, and what never goes in. Then give people a sanctioned tool that's easier than the workaround, name who approves new uses, and say what a person must check before it reaches a customer.

We're a small company. Do we really need an AI policy?

Probably, and probably a shorter one than you think.

The reason isn't that AI is scary. It's that your team is almost certainly using it already. Someone drafts replies with a chatbot. Someone summarizes long PDFs. Someone in finance tidies a spreadsheet formula. Most of it is sensible and some of it is genuinely clever. A little of it involves pasting things that shouldn't leave the building into tools nobody has looked at.

A policy is how you keep the first part and stop the last part. It should fit on a page or two, in plain language, and answer the questions people actually have. Here are the ones worth answering.

What should we find out before we write anything?

What people are doing now. Ask, and make it safe to answer honestly. A short anonymous form or a team conversation works: which tools, for which tasks, with what kind of information, and what they wish they could do.

You're not running an investigation. If the first thing a policy does is punish the people who told you the truth, you'll never hear the truth again.

What you'll usually learn is useful in two ways. You'll see the risky uses, which often cluster around a few tasks, such as customer emails, contracts, or anything with personal details. Often a few people have quietly built genuinely good habits, like keeping a checked prompt for a recurring task, and they're worth learning from. And you'll see the valuable uses, which tell you what a sanctioned tool needs to do so people actually prefer it.

Don't forget the AI that arrived without anyone choosing it. Many tools you already pay for, such as email, documents, CRM and video calls, now include AI features that are switched on by default or one click away. They count too. Note which ones are on, and what they can see.

A ban people work around is worse than no policy, because now the risky use is also the hidden one.

Which information can go into these tools?

This is the heart of the policy. Sort your information into a few kinds, with a plain example of each, and say where each kind may go.

Public or already published. Your website copy, published prices, public documentation. Fine for any approved tool.

Internal work. Draft proposals, internal notes, non-sensitive spreadsheets. Fine in a tool your company has an account with and whose terms someone has read. Check whether your inputs are used to train models, how long they're kept, and who in your company can see them, and choose settings to match.

Personal or regulated information. Customer and employee personal details, health information, payment card data, anything a contract says you'll protect. Only in systems built and contracted for that purpose, not in a general chat tool, unless your agreements and your legal advice say otherwise.

Never. Passwords, keys, and access tokens. Other people's confidential documents you don't have permission to share.

If you're in a regulated field, such as healthcare, finance, or education, get legal advice on the third kind. This note isn't that advice. But the sorting itself is something you can do this week.

How the work moves

Sort the information before you pick the tool

  1. Public or published

    Any approved tool.

  2. Internal work

    A company account whose training, retention and access terms you have checked.

  3. Personal or regulated

    Only systems built and contracted for it.

  4. Never

    Passwords, keys, tokens, and confidential material you may not share.

Illustrative decision framework; adapt it to your contracts and get legal advice for regulated data.

Is banning it ever the right answer?

For specific uses, yes. For everything, rarely.

Some uses deserve a clear no: letting a tool make final decisions about people, such as hiring, firing or credit, without a person deciding; giving customers legal, medical or financial advice generated by a tool; putting anything from the "never" pile anywhere.

Meeting note-takers deserve their own line. A tool that records and summarizes calls is useful, and it also captures other people's words, sometimes customers'. Decide when it may be used, make sure everyone on the call knows it's there, and check the consent rules where you and your callers are, because some places require everyone on a call to agree to a recording.

A blanket ban tends to backfire. The work doesn't stop. It moves to personal phones and personal accounts, where you can't see it, can't set the terms, and can't help. A ban people work around is worse than no policy, because now the risky use is also the hidden one.

Decision guide

A blanket ban vs. a policy people follow

ConsiderationBlanket banWorking policy
Where use happensPersonal phones and accounts.Approved tools with company settings.
What you knowVery little.Which tools, which tasks, which data.
Risky dataStill moves, unseen.Has a clear never list and a safer path.
Who decides new usesNobody; people guess.A named owner who answers within days.
What goes to customersUnclear who checked it.A named person reads and owns it.
Decision framework: assess these against what your own team actually does.

What should a person always check?

Say it plainly, by output, not by tool:

  • Anything that goes to a customer gets read by the person sending it. They own it, whichever tool drafted it.
  • Numbers, dates and names get checked against the source before they're used.
  • Contract and legal wording gets the same review it always did.
  • Code goes through your normal review before it reaches production.
  • Anything that changes a record in a system of record is done or confirmed by a person, unless you've deliberately built and tested an automated step for it.

The principle is simple: AI can draft, sort and summarize. A named person stays responsible for what goes out the door. "The tool wrote it" is never an answer you want to give a customer, a regulator or a colleague.

That also means the people sending AI-assisted work need time to check it. If a team is expected to answer twice as many emails because a tool drafts them, the checking is what quietly gets cut. Set expectations that leave room for it.

Who keeps it current, and where do we start?

Give it an owner, not a committee. That person keeps the approved tool list, answers "can I use it for this?" within a few days, and revisits the page every few months, because tools and terms change. Pair the page with a short, practical session, ideally showing real examples from your own work of a good use, a risky one and a fixed one. People remember examples far better than rules.

Then do the thing that makes the policy stick: give people a better option than the workaround. If the most common risky use is answering customer questions from internal documents, a sanctioned assistant that searches your own approved sources, shows where each answer came from, and keeps the data where it belongs will win on convenience. We wrote about how to start one in collect the questions before you index the documents.

That's the kind of thing we build in our AI applications work: tools that bring the right context into the moment, with sources, permissions and review visible. If your team's real AI use is a mystery, tell us what you've found, and we'll help you turn it into something safe enough to encourage.

Related work: PatientIQ.

twimco.

We build alongside the people doing the work.
Bring us the problem you’re thinking about.

Related work

PatientIQ ↗︎