Writing an AI use policy

What a use policy is for

Every earlier lesson produced something a team does: an inventory, a prompt guard, tests, review design, vendor checks. A use policy is what everyone else does: the engineer debugging at midnight, the recruiter with a stack of résumés, the manager writing reviews. Most people will never read the NIST AI RMF. They need to know, in a minute, whether what they're about to do is fine.

The frameworks ask for one:

• ISO/IEC 42001, clause 5.2: top management sets an AI policy. Annex A.2 adds that it's aligned with other policies (security, privacy) and reviewed at planned intervals.
• NIST AI RMF, GOVERN 1: policies and practices for mapping, measuring and managing AI risk are in place, transparent and implemented.
• EU AI Act, Article 4: AI literacy for people using AI systems. The Digital Omnibus softened this from an obligation on companies to support from the Commission and member states (Lesson 4), but a policy plus training is still how most organizations show their staff know what they're doing.

Fernhill's policy

Here it is in full. Every rule is numbered so a decision can cite it, and every rule traces back to a lesson.

What makes it work:

• It says yes as clearly as no. Section 2 tells people what they can use. A policy that's all prohibitions drives people to free tools where nobody can see them.
• Data rules are by data type, not by tool. People know whether something is a customer record or a public article; they shouldn't need to know a vendor's retention terms. Lesson 10's vendor work is what makes the Assistant safe for personal data.
• Hard limits are few and absolute. Secrets (Lesson 7), emotion recognition and decisions without review (Lessons 4 and 9).
• Section 9 promises no blame. People report what they're not afraid to report.

Testing the policy: policy as code

A policy reads well until it meets real requests. To test Fernhill's, its rules become data:

"tools": {
  "assistant":  {"name": "Fernhill Assistant (company account; no training, 0-day retention)", "data": ["public", "internal", "confidential", "personal"]},
  "brightlane": {"name": "Brightlane Hire (approved for screening only)", "data": ["personal"], "purposes": ["screening"]},
  "consumer":   {"name": "Personal or free AI accounts", "data": ["public"]}
},
"never": {
  "secret": "3.1 Never put passwords, keys or tokens into any AI tool"
},

Each tool lists the data it may hold, and optionally the purposes it's approved for. Each rule carries its policy number, so every decision can cite the rule that made it. A checker applies the rules in order:

def decide(p, r):
    # 1. hard limits: no tool, no exception
    for d in r["data"]:
        if d in p["never"]:
            return "DENY", [p["never"][d]]
    for u in r.get("flags", []):
        if u in p["prohibited"]:
            return "DENY", [p["prohibited"][u]]
    # 2. is the tool approved, and for this purpose?
    tool = p["tools"].get(r["tool"])
    if tool is None:
        return "REVIEW", ["2.2 Tool not approved: request it through the AI review"]
    if "purposes" in tool and r.get("purpose") not in tool["purposes"]:
        return "DENY", [f"2.1 {tool['name']}: not approved for '{r.get('purpose')}'"]
    # 3. is the data allowed in this tool?
    for d in r["data"]:
        if d in p["review_data"]:
            return "REVIEW", [p["review_data"][d]]
        if d not in tool["data"]:
            return "DENY", [f"3.0 '{d}' data isn't allowed in {tool['name']}"]
    # 4. allowed: collect the conditions that apply
    conds = [p["conditions"][k] for k in r["data"] + r.get("flags", []) + [r.get("purpose", "")]
             if k in p["conditions"]]
    if conds:
        return "ALLOW WITH CONDITIONS", sorted(set(conds))
    if r.get("purpose") is None:
        return p["default"].upper(), ["6.1 Not covered: the policy's default applies"]
    return "ALLOW", []

How it works:

• Each request names a tool, the kinds of data involved, a purpose, and optional flags such as customer_facing or auto_decision.
• Hard limits come first, so no tool approval or business purpose can override them: an API key is denied in every tool.
• Then the tool: unknown tools go to review; an approved tool used for a purpose it isn't approved for is denied.
• Then the data: sensitive data goes to review; data a tool isn't approved for is denied.
• Then conditions: everything that passes collects the conditions that apply to its data, flags and purpose.
• The default (review) handles a request the policy can't place.

Fourteen requests

The requests are the kind Fernhill actually gets: from support, engineering, HR, finance and managers.

(Your machine)

python3 -I check_use.py policy.json requests.json

Policy version 1.0 (2026-11); default for uncovered uses: review

 R1  ALLOW                 Summarize a public news article in a free chatbot
 R2  DENY                  Paste support tickets into a free chatbot to find themes
                           - 3.0 'personal' data isn't allowed in Personal or free AI accounts
 R3  ALLOW WITH CONDITIONS Draft a reply to a customer's ticket in Fernhill Assistant
                           - 3.3 Use only the fields the task needs (Lesson 7)
                           - 5.1 A person checks it before it's sent, and AI chat says it's AI
 R4  DENY                  Paste an API key and error log into the Assistant to debug
                           - 3.1 Never put passwords, keys or tokens into any AI tool
 R5  ALLOW                 Classify supplier invoices with a local model
 R6  DENY                  Let Brightlane reject the bottom half of applicants automatically
                           - 4.2 No decision about a person without human review
 R7  ALLOW WITH CONDITIONS Use Brightlane to summarize applicants for HR review
                           - 3.3 Use only the fields the task needs (Lesson 7)
                           - 5.2 HR reviews every finding; the hiring manager decides; tests on file
 R8  DENY                  Use Brightlane to check employees' performance reviews
                           - 2.1 Brightlane Hire (approved for screening only): not approved for 'performance'
 R9  REVIEW                Try a new meeting-notes AI that records calls
                           - 2.2 Tool not approved: request it through the AI review
R10  DENY                  Measure staff engagement from webcam expressions
                           - 4.1 No emotion recognition of staff or applicants
R11  REVIEW                Summarize an employee's medical leave notes in the Assistant
                           - 3.2 Health, biometric and similar data need an AI review first
R12  ALLOW WITH CONDITIONS Generate code with the Assistant and ship it
                           - 5.3 Normal code review; no secrets in prompts
R13  REVIEW                Rewrite a public blog post in the Assistant
                           - 6.1 Not covered: the policy's default applies
R14  ALLOW WITH CONDITIONS Draft performance ratings for my team in the Assistant
                           - 3.3 Use only the fields the task needs (Lesson 7)

ALLOW: 2, ALLOW WITH CONDITIONS: 4, DENY: 5, REVIEW: 3

Most decisions are what the policy meant:

• R2 and R4 are the two most common real-world AI incidents: customer data in a free tool, and a secret pasted to debug something. Both denied, each with the rule that says why.
• R6 and R10 hit hard limits. No approved tool makes them acceptable.
• R8 is a good tool for the wrong purpose. Brightlane was assessed for screening applicants (Lesson 10), not for employees' performance.
• R9 is a new tool, so it goes to review, not a flat no. Saying no to every new tool is how shadow AI starts.

Two results need a closer look.

R14: the request that slipped through

A manager drafting performance ratings in the Assistant was allowed, with nothing more than "use only the fields the task needs". But performance ratings judge a person, the kind of use Lessons 4, 5 and 9 spent the most time on. R6 was caught because the request carried an auto_decision flag. R14 carried none: the policy relied on the person asking to describe their own use as risky. People rarely do. To the manager, it's drafting.

Version 1.1 adds rule 4.3, and the checker decides it from the purpose, not from flags:

    # 2b. uses that judge people: the purpose decides, not the requester's flags
    pp = p.get("people_purposes", {})
    if r.get("purpose") in pp.get("purposes", []) and r.get("purpose") not in tool.get("purposes", []):
        return "REVIEW", [pp["rule"]]

people_purposes lists hiring, performance, promotion, discipline, pay and screening. A request with one of those purposes goes to review, unless the tool was approved for exactly that purpose, as Brightlane is for screening. Running all fourteen again:

R14  REVIEW                Draft performance ratings for my team in the Assistant
                           - 4.3 Uses that judge people need an AI review first, unless the tool is approved for that purpose

ALLOW: 2, ALLOW WITH CONDITIONS: 3, DENY: 5, REVIEW: 4

Only R14 changed; the other thirteen decisions were identical. That's the value of testing a policy like code: a rule change comes with proof of what it changed, and what it didn't.

Enlarge (opens the diagram full size)

Close

R13: what the default costs

R13, rewriting a public blog post in the approved Assistant, is about as safe as AI use gets. It went to review because the request named no purpose, and the policy's default for anything it can't place is review.

That's the right default for Fernhill: when in doubt, ask. But it has a cost. Every harmless request that waits two days for a review teaches someone that asking is slow, and the next time they'll use a free tool and not ask. Two ways to keep the default rare:

• Make the common safe cases explicit. Public data in an approved tool needs no purpose at all. A rule saying so would have allowed R13.
• Watch what goes to review. If most reviews end in "yes, that's fine", the policy is missing rules, not the people.

Keeping it alive

A policy is a version, not a monument. Fernhill's has three habits:

• Every review decision becomes a test case. When the AI review group approves the meeting-notes tool (R9) with conditions, that becomes a rule and a request in requests.json, so the next policy change is checked against it.
• Every incident is checked against the policy. If something went wrong that the policy allowed, the policy changes, as it did for R14.
• The policy points at the inventory. Section 7 makes the review group keep Lesson 6's inventory, so every approved use is also a listed system, with an owner and a review date.

Spot the problem

Work out what's wrong before you read the explanation.

"We banned it." After hearing about a data leak at another company, a firm's leadership issues a one-line AI policy: "Use of generative AI tools is prohibited until further notice." Six months later, a security review finds forty employees using free AI chatbots with work data, including customer contracts, on personal phones and home laptops. Nobody reported it, because it wasn't allowed. What's wrong? A ban with no approved alternative doesn't stop use; it hides it. The work people wanted AI for didn't go away; it moved to tools the company can't see, with no data terms, no logs and no training. And because using AI breaks the policy, no one reports problems. Three fixes: provide an approved tool with acceptable data terms, so there's a safe yes; write data rules, not just tool rules, so people know what can go where; and make reporting safe, so the next mistake surfaces in a day, not in an audit.

Where you are now

That's the track. You can explain what AI governance is in engineering terms (Lesson 1); work with the NIST AI RMF (Lesson 2), ISO/IEC 42001 (Lesson 3), the EU AI Act (Lesson 4) and US rules (Lesson 5); build an inventory (Lesson 6); control what goes into prompts and comes out (Lesson 7); test and red-team a model (Lesson 8); measure whether human oversight is real (Lesson 9); assess a vendor (Lesson 10); and write, and test, the policy that ties it together. Every one of those is something an engineer can do this week, without waiting for a governance team to exist.

Check yourself

Key terms

• AI use policy: the rules staff follow when using AI: tools, data, prohibited and reviewed uses, and who decides the rest.
• Hard limit: a rule no approval can override, such as never putting secrets into an AI tool.
• Policy as code: writing a policy's rules as data and code, so they can be tested against example requests.
• Default: what happens to a request no rule covers.
• AI review group: the people who decide requests the policy sends to review, and keep the inventory.
• AI literacy: enough understanding of AI for people to use it sensibly; EU AI Act Article 4.
• Shadow AI: AI use the organization doesn't know about, often because the policy gave no safe alternative.

Go deeper

• NIST AI RMF, GOVERN 1 (opens in a new tab), on policies and practices.
• ISO/IEC 42001 clause 5.2 and Annex A.2, on the AI policy (Lesson 3).
• Try: write R15 to R20, six requests from your own work, and decide each by hand before running the checker. Where do you disagree with it?
• Try: add a rule for R13's case, public data in an approved tool, and rerun. Does anything else change?