If you have not written an ai usage policy yet, your staff has already written one for you. It just lives in their heads, not on paper, and it is probably some version of "paste it into ChatGPT and see what happens." I have seen this at a multifinance company where a junior analyst pasted a customer list into a public AI tool to "clean up the formatting." Nobody told her not to. Nobody had told her anything.
This is not a story about bad employees. It is a story about a gap. AI tools are useful enough that people reach for them the moment they hit friction, and most owners have not decided, in writing, what is allowed. An ai usage policy closes that gap without needing to ban the tools that are actually helping your team move faster.
Why banning AI does not work
I get the instinct. Data risk feels scarier than the productivity gain feels valuable, so the easy move is to say "no AI tools, full stop." In practice this fails in about two weeks, because:
- Staff use it anyway, on personal devices, outside any logging or control you have.
- You lose visibility into exactly the risk you were trying to avoid.
- You give up real productivity gains (drafting, summarizing, translating) for a rule nobody follows.
A policy that enables with guardrails beats a ban that gets ignored. The goal is not zero AI use. The goal is AI use you can see and defend if a client or regulator ever asks.
The one-page structure
Keep it to one page. Nobody reads a twelve-page AI governance document, and you do not need one at SME scale. Structure it in five sections.
1. Approved tools
Name the specific tools staff may use for work, and note whether each is a business or personal account:
| Tool | Approved use | Account type |
|---|---|---|
| ChatGPT (business plan) | Drafting, summarizing, brainstorming | Company account |
| Claude (business plan) | Document analysis, code review | Company account |
| Personal AI accounts | Not for work data | N/A |
If you have not upgraded to a business or team plan for your main AI tool, do that before writing the rest of the policy. Free consumer accounts often use your input to train models by default, and that is the opposite of what you want for client data.
2. Forbidden data categories
This is the section that actually protects you. Spell out, in plain language, what must never go into an AI tool, sanctioned or not:
- Customer personal data: names, ID numbers, account numbers, contact details
- Financial figures not yet public: unreleased pricing, unaudited financials, payroll
- Credentials: passwords, API keys, tokens
- Anything under an NDA with a named restriction
Give one or two concrete examples relevant to your business, because "personal data" is abstract and "don't paste the customer's KTP number to summarize a complaint" is not.
3. Review requirement
AI output is a draft, not a deliverable. State plainly that no AI-generated content goes to a customer, a regulator, or into a financial record without human review and sign-off. This single line is what protects you if AI ever produces something wrong: your process shows a human was supposed to check it.
4. Escalation contact
Give one name and one channel for "I'm not sure if this is allowed." Ambiguity kills policies faster than bad rules do. If staff do not know who to ask, they either freeze or guess, and guessing is how the data leak happens.
5. Consequences
State plainly what happens if forbidden data is pasted into an unapproved tool. This does not need to be harsh. It needs to exist, so the policy has teeth and HR has something to point to.
Rolling it out without a training session nobody attends
You do not need a workshop. A one-page PDF, a five-minute walkthrough in your next team meeting, and a signature (even a WhatsApp thumbs-up works for a small team) gets you 90% of the compliance value. Revisit it every six months as tools change, not on a rigid quarterly cycle nobody has time for.
If your team already handles regulated data (multifinance, healthcare, anything under OJK oversight), pair this policy with your existing data handling SOP rather than writing a competing document. The AI policy should reference the data policy, not duplicate it.
What this connects to
An ai usage policy is really a subset of a broader question: do you actually own your customer data, or is it scattered across tools and now AI chat histories you cannot audit? If you have not thought this through, read Own Your Customer Data or Someone Else Will. And if AI is becoming a real part of how your team works day to day, it deserves the same strategic thought as any other system, not just ad hoc tool adoption, which is the argument I make in Why Your Business Needs a Technology Strategy, Not Just a Website.
The takeaway
Write the one-page policy this week, not next quarter. Name the approved tools, name the forbidden data, name the reviewer, name the person to ask. That is the entire document. It will not stop every mistake, but it turns an invisible risk into a managed one, and it means the next time someone reaches for AI under deadline pressure, they reach for it inside the guardrails you built instead of outside them.