Write an internal policy in the language of the people it governs

Turn compliance requirements into policies your team will actually follow, written in the words they already use.

For anyone who has to write the rules for a small team · 9 steps · 7 min

How it works today.

You start with a template from a law firm or a competitor's handbook you found online. You search-and-replace the company name, skim the thirty-page document for anything obviously wrong, and publish it to a shared drive. Three months later someone violates a rule they never knew existed because the policy reads like it was written for a Fortune 500 with dedicated compliance staff.

When someone asks a question, you realize the policy doesn't cover their actual situation. You either make a judgment call on the spot or spend an hour re-reading legalese to figure out what you meant to require. The document becomes a liability instead of a guide, because it describes a company you don't have and work you don't do.

Before you start.

All of it has to be true, or step one fails in a way that is annoying to debug.

A list of the actual rules you need to enforce, whether from a legal requirement, an insurance policy, a client contract, or a decision you have made as a team.
Access to a generalist agent with a context window large enough for your existing policy draft or template, if you have one.
Examples of how your team currently talks about this area of work: chat transcripts, meeting notes, or onboarding docs.
Sign-off authority from whoever is accountable for legal or regulatory compliance before the policy is published.

The steps.

List the rules you actually need to enforce
Write down what must happen or must not happen, and why. If the requirement comes from outside your company, note the source: a regulation, a contract term, an insurance condition. If it is your own decision, write the reason in one sentence. Do not pad this list with aspirations or things you wish were true. This becomes your scope.
Gather examples of how your team describes this work today
Pull real sentences from Slack, email, standups, or onboarding checklists where people talk about the area this policy governs. You need at least ten examples. If your team uses specific jargon, abbreviations, or role names, include those. If they never talk about this topic, that is a signal the policy may be solving a problem you do not have yet.

Draft the policy in your team's language

Give the agent your list of rules, the source material, and the examples of how your team talks. Ask it to write the policy as if it were instructions for someone joining tomorrow. The output should name real roles, real tools, and real situations your team encounters.

Paste this

You are writing an internal policy for a team of [number] people. The policy must cover these requirements:

[paste your list of rules and sources]

Here is how the team currently talks about this work:

[paste your examples]

Write a policy that:
- Uses the same role names, tool names, and vocabulary as the examples
- Explains why each rule exists in one sentence
- Gives a concrete example for any rule that could be misunderstood
- Fits on two pages or less
- Sounds like it was written by someone on this team, not by a lawyer

Start with the most common situation someone will face, not with definitions.

Test the draft against three real scenarios
Pick three things that have actually happened or that you expect to happen in the next quarter. Read the draft and see if someone could follow it without asking you a question. If the answer is unclear or if the policy does not cover the scenario, note where it breaks. Do not skip this step. Policies fail because they are written for hypothetical work.
05
Revise for the gaps and the jargon you missed
Feed the agent your three scenarios and the places where the draft did not work. Ask it to revise only those sections. If you found jargon or acronyms in the draft that your team does not use, replace them now. If a rule needs an exception for a specific role or situation, add it explicitly.
Paste this
```
Here is the policy draft:

[paste the draft]

It does not clearly cover these scenarios:

[paste your three scenarios and notes]

Revise only the sections that failed to address these situations. Keep the same tone and vocabulary. If a rule needs an exception, state it plainly rather than adding a clause.
```
Add a single-sentence summary at the top of each section
People skim. For every section or rule, write one sentence that tells someone whether they need to read it. The agent can draft these, but you should edit them yourself. If you cannot summarize a section in one clear sentence, the section is probably too complicated.
Check that every rule names who is responsible
Go through the draft and confirm that every requirement says who does it or who approves it. If a rule says 'must be reviewed', it should say reviewed by whom. If it says 'before publishing', it should say who publishes. Vague accountability is how policies get ignored.
08
Send the draft to your compliance reviewer
Give the draft to whoever is responsible for legal, regulatory, or contractual compliance. This is not optional. Tell them what requirements you were trying to meet and ask if the policy satisfies them. If they request changes, make them. If they add language your team will not understand, ask them to explain it in plain terms and revise the draft to include both.
Paste this
```
I need to confirm this policy meets [regulation/contract/requirement]. Here is the draft:

[paste draft]

Does this satisfy the requirement? If not, what is missing or wrong? If you need to add language, please also provide a plain-language explanation I can include for the team.
```
Publish with a changelog and a review date
Put the policy somewhere your team already looks: the wiki, the handbook, the shared drive they actually use. Include the date it takes effect and a sentence on what changed if this replaces an older version. Set a calendar reminder for six months out to review whether the policy still matches how you work. Policies rot when the work changes and the document does not.

What you keep.

Automating the typing does not move the accountability. These stay with a person.

Deciding which rules are actually required and which are borrowed from a template that does not fit your company.
Confirming with a qualified reviewer that the policy satisfies any legal, regulatory, or contractual obligation before you publish it.
Testing the draft against real scenarios your team has faced, and revising where it fails to give clear guidance.
Reviewing the policy every six months to confirm it still describes the work as it is actually done.

Once it works.

The first run is the demo. These are where the time actually comes back.

Fire it from an event

When a new regulation or contract term arrives, feed it to the agent with your existing policy and ask for a diff showing what needs to change.

Run it on a loop

Every quarter, pull recent questions from your team chat about the policy area and check if the policy answers them; if not, revise that section.

Hand off to another agent

When onboarding someone new, ask them to read the policy and flag any sentence they had to read twice; use their feedback to simplify the next version.

Scale it wider

Once you have one policy written this way, use it as an example when drafting the next one so the agent matches the tone and structure your team already recognizes.