A company of 5 to 20 people rarely has a risk committee or a compliance team. It still has people pasting customer details into chat tools, coding agents working in the repository, and maybe an AI feature on its way to customers.
At that size you don't need a framework document. You need one page that says what the team has agreed, who decides, and when you will look at it again.
Here is the structure I would use. Copy it, fill it in, and keep it short enough that people actually read it.
1. Approved tools, and what each is for
List the AI tools the company has approved and the job each one is approved for. One line each is enough: the chat assistant for drafting and research, the coding agents for work in the repository, the meeting notes tool for internal calls.
Name the plan or account, not just the product, because data terms can differ between plans from the same vendor. Anthropic, for example, says it does not use inputs or outputs from its commercial products for training by default, while on its consumer plans the user chooses whether their chats can be used to improve the models. Check the terms for every tool on your list.
Then add one line for everything else: ask before using any other AI tool with company data, and say who to ask.
My own coding list is four tools: Google Antigravity, Claude Code, Cursor and Devin. All four work under the same written rules for coding agents.
2. What data can and cannot go in
This is the section that matters most day to day. Write it by type of data, not by principle.
- Allowed: public information, the team's own drafts and internal notes, code with no secrets in it.
- Allowed with care: customer information, only in tools approved for it, and only what the task needs.
- Never: passwords, keys and tokens; payment details; health records or government ID numbers; anything a customer contract says cannot leave your systems.
Give production data its own line. My coding agents never touch it. They work against seed data and demo workspaces.
Where a contract, your industry or privacy law sets stricter rules, those win. The page does not replace them, so check the rules where you operate.
3. Who approves AI features before customers see them
Using AI inside the team is one thing. A feature customers see, or one that acts on their data, needs a named person to sign off before launch. In a small company that is usually the founder or the product lead. Write down the name, not the role.
Before saying yes, they check:
- what the feature can do on its own, and what needs a person to approve;
- what data it sees and which provider it goes to;
- how it was tested, on realistic inputs;
- what customers are told about it;
- how to switch it off quickly.
I have written about where an AI agent should ask for human approval and why humans keep launch authority on my own releases. The rule is the same at company level: AI can draft and summarize, and a named person decides what ships.
4. What gets logged
Decide what you keep, so that when something goes wrong you can see what happened.
For AI features in your product, that usually means what was asked, what the AI proposed, what a person approved or changed, what ran and whether it worked, and which model and prompt version were used. For internal use, a list of which tools can reach which systems is often enough.
Logs can hold sensitive data too. Decide who can read them and how long you keep them.
5. What to do when it gets something wrong
It will. Write the steps down before you need them:
- Pause or switch off the feature if it is still causing harm.
- Tell the named owner.
- Work out who was affected, and tell them plainly.
- Fix the records, then the cause.
- Write a few sentences on what happened and what changed, and update the page if needed.
Add one more line: anyone can report an AI mistake without blame. A team that hides its mistakes learns nothing from them. If personal data was exposed, you may also have legal duties to report it, so check your local rules.
6. Who reviews the page, and when
Name the person who owns the page. Set a review every quarter, and also whenever you add a tool, launch an AI feature, sign a customer with new data requirements or have an incident. AI tools change their features and terms often, and a page nobody revisits goes out of date quietly.
Where NIST fits
If you want an official reference behind the page, NIST's AI Risk Management Framework is a good one. It is intended for voluntary use. Its core has four functions: Govern, Map, Measure and Manage. NIST describes Govern as cross-cutting, infused throughout the others, and says framework users may apply the functions as best suits their needs.
Two of the Govern categories line up with this page: accountability structures, so the right people are empowered to act, and policies for AI risks that come from third parties. A one-page policy is a modest start on that side of the framework.
It is not compliance with anything. If you sell into regulated industries, or customers ask you to meet a specific standard, you will need more than a page, and probably legal advice.
A one-page policy everyone has read beats a long one nobody has.
The page, ready to copy
- Approved tools: each tool, the plan or account, and what it is approved for. Anything else, ask the named owner first.
- Data: what is allowed, what is allowed with care and what never goes in.
- AI features: one named person approves before customers see them, after checking actions, data, testing, disclosure and the off switch.
- Logging: what you keep, who can read it and for how long.
- Mistakes: pause, tell the owner, tell the people affected, fix it, write it down.
- Review: who owns the page, reviewed every quarter and after any new tool, feature or incident.
If your team uses AI every day and none of this is written down yet, email me. I am happy to help you write the first version.