Sensible AI Rules for a Company That Is Not a Bank

Before writing anything, find out what is happening. People in your company are already using these tools, in personal accounts, on their own phones, for work you would probably approve of. A policy written without knowing that is a policy written about an imaginary company.

Ask, and ask in a way that does not punish honesty. Say plainly that nobody is in trouble and that you want to know what is genuinely useful. You will get a more accurate picture in an afternoon than a survey gives you in a month, and you will usually find one or two things worth spreading to everybody else.

Then write the policy around that reality. Rules that outlaw what people find useful get ignored, and once one rule is ignored the rest of the page loses its authority too.

Do it before you buy anything, too. What people already reach for tells you what a good approved option would have to do, and it is a better guide than a requirements workshop, because it is a record of behaviour rather than a list of opinions gathered in a room.

The whole thing should fit on a page a new starter can read in a few minutes. A long document feels more careful and protects you less, because nobody reads it and nobody can recall any of it at the moment they need to.

Four things belong on that page. What may go in. What has to be checked by a person before it leaves the company. Who to ask when it is not obvious. And what gets written down. Everything else is commentary and can live somewhere else for whoever wants it.

Write it in your own nouns. Customer addresses rather than personal data. The client repository rather than intellectual property. Salary letters rather than confidential records. Abstract categories force every reader to make a judgement call, and they will each make a different one.

Three buckets is enough. Freely, in the approved tool only, and never. Put your real examples under each, and expect the list to be argued about in the first meeting, because that argument is the useful part of writing it.

Freely usually covers anything already public. Your marketing copy. Your published help pages. General questions about how to do something. Code from open source projects. Nobody should have to think twice about those, and the page should say so, because a policy that makes everything feel risky gets ignored wholesale.

The approved tool bucket holds most of the real work. Internal documents. Draft emails to customers. Your own source code. Meeting notes. Those are fine under business terms with retention configured, and not fine in a personal account. That distinction is the single most important line in the document.

Never should be short and specific. Card numbers. Anything covered by a confidentiality agreement with a named counterparty. Health records. Login credentials, which people paste more often than you would believe. Financial results before they are announced. Keep it to a handful of items somebody can actually memorise.

The rule that does the most work in a small company is short: anything leaving the building gets read by a person first. Emails to customers. Anything published. Contract wording. Answers in a tender response. Code that reaches production.

Be specific about what checking means, because approving something you did not read is the failure mode here. Checking a customer email means confirming every fact in it is true, that the promises are ones you can keep, and that it sounds like your company. Checking generated code means reviewing it the way you would review a colleague's work, tests included.

Add one rule about attribution. Nobody puts their name to something they have not read. That sentence prevents most of what goes wrong, because it puts responsibility back where it belongs and people behave differently when their own name is attached to the output.

Then name the categories needing a second pair of eyes rather than one. Anything with a legal consequence. Anything going to a regulator. Anything quoting a figure the business will be held to. Keep that list short enough that nobody starts looking for a way around it.

Every policy meets a case it did not anticipate, usually within a fortnight. Name one person, name a deputy, and put both names on the page rather than a shared mailbox that belongs to nobody.

Set an expectation for how quickly they answer, and make it quick. A day is workable. A week means people decide for themselves and stop asking, which costs you the visibility as well as the time.

Have that person keep a short log of the questions and what they answered. After a few months the recurring questions tell you exactly which part of the page is unclear, and you can fix the wording instead of answering the same thing over and over.

Give them somewhere to escalate as well. A question touching a customer contract, a regulator or somebody's personal data belongs with whoever normally handles those things. Say so on the page, rather than leaving one person to invent a legal answer on a Friday afternoon because nobody told them where the edge was.

Logging everything is a project you will abandon by spring. Log the things you would want during an argument or an investigation, and leave the rest alone.

Worth logging: which tools are approved and who approved them, the exceptions somebody asked for and was granted, and any case where generated material went out publicly under the company name. That last one matters because if something published turns out to be wrong later, you will need to know how it was produced and who signed it off.

Not worth logging in most companies: individual prompts, keystroke level monitoring, a record of every conversation a member of staff has with a tool. It creates a surveillance relationship with your own people, it produces a store of data that is itself a liability, and it tells you very little in return.

Where a system makes a decision that affects a customer, log that one properly. The input, the output, the version of whatever produced it, and who approved it. That is a different kind of record from monitoring your staff, and it is the record an auditor or a court will ask for.

The most effective sentence in the whole document is the one naming which accounts people should use. Rules restrict behaviour and depend on memory. An approved account that is easy to reach and works well changes what people do without them having to think about it at all.

So put the effort there. Get a business tier, turn the retention down, connect it to your normal sign in, and give it to everybody on their first day. Then make sure it is genuinely good. If the approved option is slower or weaker than the free one people already use, the policy loses quietly and nobody tells you.

Keep the list current. New tools appear constantly, staff will ask about them, and a request that sits unanswered for a month teaches people to stop asking. Have a light way to add something: what it does, what data it touches, who read the terms, approved or not, and the date.

Say what was actually checked on each entry. The terms, the retention settings, where the processing happens, and whether the company behind it is one you would be comfortable naming to a customer. That is a short piece of work per tool, and it is what separates a list from a decision somebody made.

Put a review date on the page and keep it. Twice a year is plenty for most companies. What changes is the tool list, the examples, and occasionally the never bucket as the business takes on new obligations.

Resist the urge to grow it. Every incident creates pressure to add a paragraph, and a document that grows after every incident becomes the document nobody reads. When something goes wrong, ask first whether the page was unclear or whether it was ignored. Only the first of those is fixed by writing more.

Tell people when it changes, in a sentence, in whatever channel they genuinely read. A policy updated quietly exists only for the person who updated it, and you will discover that during the argument you wrote it to prevent.

Keep it proportionate to what you actually are. A company handling other people's medical records or their money needs more than this. Most companies do not, and a page people follow will protect you considerably better than a framework sitting in a folder nobody opens.