Your AI usage policy

T13-L03 · Adoption & enablement · Level 3 Builder · 35 minutes

At Level 3 Builder, colleagues depend on a rule you create. If it is vague, hidden, or impossible to follow, each person invents a different boundary and the team cannot see mistakes early.

2. The rule is whatever people guess

You discover that half your team already uses AI through personal accounts. One colleague pastes public material, another uploads routine internal notes, and a third will not use any assistant because they think everything is forbidden. There is no written rule. Nobody can name an approved tool, who decides an edge case, or what to do after a mistaken paste.

You could respond with a blanket ban or copy a twelve-page corporate policy. Neither fixes today's behaviour. The ban drives useful work out of sight; the long document remains unread while people continue to guess.

You need one page that a colleague can find during a task. It must name the approved route, classify common inputs as green, yellow, or red, show what needs approval, and give a no-blame reporting path. Then you must walk a real team through synthetic cases and test whether they can use it without you prompting every answer.

3. After this you can

• Draft a one-page AI usage policy with approved tools, data boundaries, decisions, and mistake handling.
• Route green, yellow, red, and uncertain cases to a named owner instead of relying on personal judgement.
• Address shadow AI with a legitimate route and a no-blame reporting clause rather than an unenforceable ban alone.
• Run one Lab or Company walkthrough using synthetic scenarios and measurable pass criteria.
• Prove adoption with findability, classification, escalation, and incident-response tests plus a review date.

4. Prerequisites

• T12-L01 · What you may and may not paste into AI at work.
• T12-L03 · Rules for things that run without you.
• The current higher-order security, privacy, research, records, employment, procurement, and incident rules that apply to your team.
• A real team owner who can adopt a working rule and named specialists who can decide questions outside that owner's authority.
• A team publication location that everyone can access, plus a meeting slot for one walkthrough.
• A text editor and the synthetic test cards in Section 6. No AI account is needed to write or test the policy.

Do not collect colleagues' prompt histories, customer records, participant data, unpublished text, credentials, or screenshots from personal accounts for this exercise. Ask about categories and unmet needs, not the protected content itself. A team policy cannot override law, contracts, ethics approvals, works-council or employment requirements, information-security controls, or organisation-wide policy. Route those decisions to the responsible people.

5. The idea in one page

A usable AI policy is a decision surface: the shortest current document that tells a colleague what they may do now, when they must stop, and who answers the next question. Its job is not to describe AI or predict every use. It should reduce guessing at the moment someone is about to paste, upload, connect, share, or act on generated output.

Keep the working rule to one page because retrieval and comprehension are controls. Put detailed vendor assessments, contracts, data-protection analysis, ethics decisions, and system operating rules in their owned records, then link or route to them. Do not squeeze those decisions into tiny policy prose or pretend the one-page rule replaces them.

The page needs seven decisions:

Use the prerequisite book's meaning: green is intentionally public or wholly synthetic material used for an allowed task; yellow is routine internal, non-sensitive material used only through the approved tool, account, purpose, and data class; red is restricted or sensitive material that stops unless the exact use has written clearance. Active credentials are never prompt material. Pair every colour with local examples so the rule does not depend on colour perception or an abstract phrase such as sensitive information.

Treat shadow AI as evidence that a legitimate route or answer may be missing, not as permission for unlisted use. Make permitted work practical, prohibited work explicit, and questions quick to route. Encourage prompt reporting without promising immunity the team cannot grant; the incident owner decides containment and notification.

Publication is not adoption. Adoption requires accountable approval, findability, correct use on representative cases, working question and incident routes, and a dated review. Section 6 turns each condition into a measurable test.

6. The worked example: one policy, tested with a real team

The build has six moves: discover the actual gaps, confirm authority, fill the page, review it, walk it through, and test adoption. The Lab and Company versions use the same template and scorecard. Only their examples, owners, and higher-order obligations differ.

Start with a bounded discovery

Send a three-question anonymous pulse that collects no prompts or files:

1. Which task categories have you used or wanted to use AI for?
   Drafting / summarising / extracting / coding / media / other
2. What stops you using the approved route?
   Unknown tool / unknown data rule / access / speed / quality / no route / other
3. Which decision is currently hardest to find?
   Approved tools / allowed data / output review / disclosure / mistake reporting / owner

Do not include names, records, source text, customer or participant details, credentials,
unpublished findings, or confidential project descriptions.

Suppose eight of twelve invited people respond. Five report using or considering personal accounts for summarisation, six cannot name the incident route, and seven want examples of allowed data. These are synthetic baseline numbers, not claims about a real team. They identify policy content: the page needs an approved summarisation route, concrete data examples, and a visible mistake path. Do not use a small anonymous pulse to identify or discipline individuals.

Before drafting, the team owner writes an authority map:

One person may fill several roles in a small organisation, but each decision still needs an explicit hat. The team owner must not silently grant themselves legal, ethics, security, or employment authority they do not hold.

Fill this one-page policy

Adapt the bracketed fields. Keep the final rendered policy to one page; links may point to controlled records outside it.

[TEAM] AI WORKING RULE - version [VERSION]
Owner: [NAME/ROLE] | Substitute: [NAME/ROLE]
Effective: [DATE] | Review: [DATE] | Questions: [CHANNEL]
Applies to: [PEOPLE, WORK, AND LOCATIONS COVERED]

APPROVED ROUTE
Use [EXACT TOOL + ORGANISATION-MANAGED ACCOUNT] for [ALLOWED PURPOSES] with
[ALLOWED DATA CLASSES]. [NO APPROVED ROUTE / OFFLINE OPTION] is the fallback.
Personal accounts, unlisted tools, connectors, plug-ins, and public share links are not
approved for internal work unless [DECIDER] clears the exact use in writing.

BEFORE YOU SUBMIT
GREEN - public or synthetic: [TWO LOCAL EXAMPLES]. Proceed for an allowed task;
minimise the input and check rights and accuracy.
YELLOW - internal, non-sensitive: [TWO LOCAL EXAMPLES]. Use only the approved route.
If tool + account + purpose + data are not all covered, stop and ask [OWNER/CHANNEL].
RED - restricted or sensitive: [FOUR LOCAL EXAMPLES]. Do not submit unless [DECIDER]
has cleared the exact tool, purpose, and data in writing. Never submit active credentials.

BEFORE ANYONE RELIES ON THE OUTPUT
[REVIEWER ROLE] compares claims with approved sources, checks missing information and
affected-person impact, applies [DISCLOSURE/LABELLING RULE], and owns the final decision.
AI does not send, publish, approve, rank people, or change systems unless a separate
operating rule explicitly allows that action and its human approval, limit, and stop control.

WHEN UNSURE OR REQUESTING A NEW USE
Send a generic description of task, tool/account, data class, destination, and impact to
[OWNER/CHANNEL]. Do not attach the real restricted material. Expect [ACKNOWLEDGEMENT
TARGET]. No response means wait or use the non-AI fallback, not self-approval.

AFTER A POSSIBLE MISTAKE
Stop the activity. Report promptly through [INCIDENT ROUTE]: when, tool/account, generic
data class, recipients/actions, and current state. Do not repeat or widely copy the content.
Follow the incident owner's containment steps; deleting a chat is not enough.
We prioritise containment and learning. Good-faith self-reporting is not itself treated as
misconduct; deliberate concealment or repeated bypassing follows existing rules.

ADOPTION RECORD
Approved by: [ACCOUNTABLE OWNER + DATE] | Walkthrough: [DATE + TEAM]
Tests: find [RESULT]; classify [RESULT]; escalate [RESULT]; incident [RESULT]
Next review trigger: review date, changed tool/data/use, incident, or higher-order rule.

This is one artifact, including its adoption record. Meeting notes, test scratch paper, and approval messages may support the work under local retention rules, but the course exit artifact is the adopted page itself.

Use four measurable adoption tests

Test at least three team members who did not draft the wording. Use only these synthetic cards or equivalent fictional cards. Do not test policy comprehension by asking people to expose their real AI use.

Use this common six-card set with parallel skins:

The edge-case card is: The identifiers have been removed from an unpublished participant extract / customer complaint, but the contract, consent, or original data permission does not clearly cover this AI use. The passing action is not to debate whether anonymisation solved it. Send a generic description to the named route and wait for the accountable decision.

The incident card is: A colleague says they may have pasted a restricted unpublished draft / customer file into a personal AI account ten minutes ago. A passing tester does not ask them to paste the content into the team channel. They stop further use, invoke the named incident route, provide time, service/account type, generic data class, recipients or actions, and current state, then follow containment instructions. The policy does not prescribe deletion, notification, or discipline because those decisions belong to the incident process.

Lab framing: adopt the rule in a research group

Mira coordinates a ten-person research group. The principal investigator is the accountable policy owner; the research data steward is substitute. The institution's security route handles suspected disclosures, while the principal investigator and data or ethics owners decide whether a new use involving participant or collaborator material is permitted.

The approved route in this fictional example is Northstar Research AI, an invented organisation-managed workspace, for public literature and routine non-sensitive internal administration. The policy does not infer that unpublished manuscripts, peer-review material, participant data, instrument exports, or collaborator files are allowed merely because the workspace is managed. Those are red until the specific purpose and route are cleared in writing. The offline fallback is manual review or a synthetic structural prompt.

Mira fills the local examples with published abstract and synthetic sample tracker for green; generic group agenda and approved style guide for yellow; and participant record, unpublished result, collaborator manuscript, and credential for red. Generated literature or administration drafts must be checked against named sources by the researcher responsible for the work. Publication, authorship, ethics, consent, and disclosure decisions stay with their existing owners.

The principal investigator approves version RG-AI-1.0, effective 8 September 2026, with a review on 6 October 2026. Mira publishes one canonical page in the group's normal handbook and marks an old FAQ as superseded rather than leaving two active rules.

During a 25-minute group walkthrough, Mira explains the purpose in two minutes, demonstrates one green/yellow/red decision in five, and gives three non-drafting members the six cards. All three locate the page in under two minutes. They score 6/6, 6/6, and 5/6; the mismatch is Card 4, which one person calls green. Mira changes the yellow wording from ordinary guidance to internal non-sensitive style guide: approved workspace only, then all three rerun all cards and score 6/6. The data steward acknowledges the synthetic edge case within the stated one-working-day target and routes it to the principal investigator plus data owner. All three pass the fictional incident response.

The policy is adopted because authority, publication, walkthrough, and tests are evidenced on its adoption line. The scores do not prove every future case will be classified correctly. They show that representative members can use this version on these declared boundaries, and the scheduled review creates the next correction point.

Company framing: adopt the same rule in a small company

Jonas uses the identical process with a twelve-person customer-operations team. The operations director owns the working rule; the security lead is substitute and incident contact. Procurement and privacy owners approve new providers or data classes. The customer-operations manager remains responsible for communications and decisions affecting accounts, refunds, access, or service commitments.

The fictional approved service is Northstar Business AI, again an invented managed workspace, for public marketing text and routine non-sensitive internal drafting. Personal accounts and unlisted browser extensions are not approved for internal work. Customer messages, contracts, invoices, employee or applicant records, production logs, confidential pricing, and credentials remain red unless the accountable process explicitly clears the exact use; credentials are never entered.

Jonas changes only the examples and accountable roles in RG-AI-1.0 to create CO-AI-1.0. He uses public product page and synthetic request tickets for green; generic weekly update and internal response style guide for yellow; and customer email, contract, employee record, and credential for red. A person checks every generated claim and source before a draft reaches a customer. The page forbids the assistant from sending, approving refunds, restricting accounts, ranking applicants, or changing systems without a separately approved operating rule.

The operations director approves the page, effective 8 September 2026, with the same 6 October review date. Jonas publishes it in the operations handbook and runs the same 25-minute walkthrough. Three members who did not draft it complete the same four tests with the Company cards. The first classification run reveals that two people think removing a customer's name automatically makes a complaint yellow. Jonas adds removing a name does not establish permission; if original rights or terms are unclear, stop and ask to the red examples. The full rerun passes: all red cards stop, every tester scores at least 5/6, the security lead acknowledges the edge case within one working day, and every tester follows the incident route.

The Lab and Company teams have not "solved governance." Each has adopted a narrow current working rule, demonstrated a legitimate route, exposed one misunderstanding, repaired the page, and scheduled review. That is a safer rollout than announcing a permanent policy nobody has tested.

7. What goes wrong

You copy a corporate policy nobody will read

Symptom: the page is filled with legal definitions and references, but a colleague cannot decide whether today's agenda may enter today's tool.

Fix: keep the higher-order policy intact and link to it. Put the everyday tool, data, output, question, mistake, owner, and review decisions on one working page. Ask non-authors to classify cases.

You ban everything and shadow use becomes harder to see

Symptom: the written rule says no AI, while task pressure and easy personal accounts move use into private browsers and unreported workflows.

Fix: preserve every necessary prohibition, but provide a legitimate route for safe permitted tasks, an offline fallback, quick questions, and no-blame reporting. Use an anonymous needs pulse without collecting real prompts or identifying users.

"Approved tool" means a brand instead of a boundary

Symptom: colleagues assume any account, plug-in, connector, model, or data type is permitted because the service name appears on the page.

Fix: specify tool, organisation-managed account, allowed purposes, and data classes. Treat a new connector, account type, action, or use as a new approval question.

No named decision-maker owns edge cases

Symptom: the question channel exists, but users receive opinions, silence, or referrals in a loop.

Fix: name owner, substitute, response target, and specialist route. The owner must acknowledge uncertainty and identify the accountable decider rather than improvising permission.

The no-blame clause promises too much or too little

Symptom: either mistakes stay hidden because the page only threatens sanctions, or the team promises immunity it has no authority to grant.

Fix: prioritise prompt good-faith reporting, containment, and learning while leaving deliberate concealment and repeated bypasses to existing organisational rules. Have the responsible employment, legal, or incident owner approve the wording where required.

There is no review date

Symptom: a tool, account configuration, higher-order rule, or team changes while the page still looks current.

Fix: print owner, version, effective date, review date, and event triggers on the page. Replace the canonical version and visibly mark old copies superseded.

You publish without a walkthrough

Symptom: the owner announces a link and counts page views as adoption; testers later classify the same customer or collaborator file differently.

Fix: run the synthetic cards with people who did not draft the page. Repair systematic misunderstandings and rerun the complete set before marking adoption.

Attendance is mistaken for adoption

Symptom: everyone joined the meeting, but they cannot find the rule, reach the owner, or state what happens after a mistake.

Fix: measure findability, classification, escalation, and incident response. Put actual results, not training delivered, in the adoption record.

8. Do it yourself: adopt the rule in 90 minutes

Use one real team, but public, synthetic, or explicitly approved data only. If the accountable owner cannot attend or approve, complete the draft and tests but do not mark the policy adopted.

Minutes 0-10: confirm scope and authority. Name the policy owner, substitute, new-use deciders, output owners, incident route, and any higher-order rules. Write what this team rule cannot approve.

Minutes 10-20: run the three-question pulse or a short verbal equivalent. Record only task categories, blockers, and missing decisions. Do not ask for prompts, files, provider histories, names, or admissions about restricted content.

Minutes 20-35: adapt the fill-in template. Name the exact approved tool and managed account, purposes, data classes, offline fallback, output checks, disclosure route, question target, acknowledgement target, incident action, effective date, and review date.

Minutes 35-45: add two green, two yellow, and at least four red examples in the team's language. Confirm that credentials are never prompt material and uncertainty means wait or use the fallback. Keep the rendered working rule to one page.

Minutes 45-55: review authority and safety with the accountable owner and relevant specialist. Remove claims the team cannot make. Obtain explicit adoption approval or mark the page draft - not yet in force.

Minutes 55-62: publish one canonical current page where the team normally looks. Mark old local guidance superseded. Ask three non-authors to start from the normal team home rather than giving them the final URL.

Minutes 62-77: run the find and classify tests. Use all six synthetic cards. Record time and score per tester without collecting unrelated personal data. If any red card proceeds or the same wording confuses multiple people, revise the page and rerun the whole set.

Minutes 77-84: send the synthetic edge case through the question route and run the fictional incident card aloud. Confirm the owner or substitute can receive the question and identify the real decider. Never stage an actual disclosure.

Minutes 84-90: complete the adoption record on the same page: approver and date, walkthrough date and team, actual four test results, effective date, owner, substitute, review date, and event triggers. Store it through the approved team route.

9. Exit check

Deliver exactly one artifact: a one-page AI usage policy adopted by a real team, with its adoption record on the page.

It passes when the page names scope; exact approved tool and managed account or explicit no-tool fallback; allowed purposes and data classes; green, yellow, and red examples; output review; edge-case owner, substitute, route, and acknowledgement target; mistake route and no-blame clause; accountable approver; effective date; and review date. At least three non-author team members must find it within two minutes, stop every red test card, score at least five of six classifications, route the synthetic edge case without restricted content, and state the complete fictional incident response. Record actual results on the page. If wording changes after a failed test, rerun the complete set before adoption.

The artifact fails if it contains real prompts, incident content, personal data, customer or participant records, unpublished material, credentials, or screenshots from personal accounts. A draft without accountable approval, a published page without the walkthrough, or a policy with no named owner and review date is not adopted.

10. Rule to remember

One page, one owner, one review date.

11. Further reading & tools

• Taught: T12-L01 · What you may and may not paste into AI at work - supplies the green/yellow/red input rule and the meaning of an approved route.
• Taught: T12-L03 · Rules for things that run without you - adds approvals, limits, accountability, and a stop path when an AI-enabled build can act without its author.
• Taught: Privacy & safe AI use - applies approved-tool, minimisation, source-checking, and human-escalation controls to everyday work.
• Taught: Private AI for your org: buy, build & govern - separates accountable, content, technical, and incident decisions and links risks to tests and pause criteria.
• Catalogued: NIST AI Risk Management Framework (opens in a new tab) - voluntary risk-management structure; it does not approve a tool, policy, or data use.
• Catalogued: NIST AI RMF Playbook (opens in a new tab) - optional actions for governing, mapping, measuring, and managing risk; select actions that fit local authority and context.
• Catalogued: NIST Privacy Framework (opens in a new tab) - voluntary privacy-risk guidance; local legal, contractual, research, and organisational decisions still apply.
• Catalogued: Tools index - compare product capabilities only after the team has defined purpose, account, data, owner, and approval requirements.