Your AI usage policy

T13-L03 · Adoption & enablement · Level 3 Builder

1. Your project works. Can someone else use it on Tuesday?

The useful result is already within reach: perhaps your project turns public sources into a weekly briefing, helps prepare accessible teaching material, or drafts a response that a colleague checks before sending. You know which account to open, which inputs belong there, and which parts of the answer need checking. Then you take a day off.

Your colleague reaches the same screen and hesitates. Is this internal note allowed? Does the assistant send the result or only draft it? Who answers if the usual reviewer is away? They can copy what you did in a demonstration, but they cannot recover the decisions you kept in your head.

This book turns those decisions into a small, usable part of the thing you built: an AI working rule at the point where colleagues start the work. Continue your chosen project. You do not need to replace it with a tracker, invent a company, or build another application. Your result here is the rule that lets someone else use that project within agreed boundaries, get an answer when the boundary is unclear, and keep useful work moving through a safe fallback.

The tools are ordinary: your existing text or document editor, the team's approved shared handbook or project page, and its existing question and incident channels. No AI account is needed to write or test the rule. If you already have equivalent current guidance, improve the project-specific entry rather than create a competing policy.

2. The rule is whatever people guess

Imagine a team where one person uses a personal AI account for public material, another uploads routine internal notes, and a third avoids every assistant because they think everything is forbidden. Nobody can name the approved route, the person who decides an edge case, or the first action after a mistaken paste.

A blanket ban may be necessary for some uses, but it does not by itself provide a workable route for permitted tasks. A twelve-page corporate policy may be authoritative, but a colleague still needs to decide whether today's agenda may enter today's tool. When that answer is hidden, people improvise, delay, or move work out of sight.

You need a concise page they can find during the task. It names the approved route, explains green, yellow and red inputs in the language of the project, shows who checks the recurring result, and gives a prompt reporting path. Then colleagues use it on fictional cases without you supplying the answers. The aim is not to make everyone enthusiastic about AI. It is to make permitted work understandable and mistakes easier to contain.

Show a colleague gets someone to an informed first task. This book makes that task dependable for a team. Rules for things that run without you handles the operating controls of an unattended build; this book makes its boundaries findable and usable by people. Rolling it out comes later, when you decide about seats, budgets, support burden and expansion. A narrow working rule does not need to become an organisation-wide rollout plan.

3. After this you can

• Build a concise working-rule page around a recurring result from your chosen project.
• Specify the exact approved tool, account, purpose, input classes, output check and fallback.
• Route uncertainty to a named owner and substitute instead of treating silence as permission.
• Address shadow AI with practical permitted work and prompt good-faith reporting, without weakening necessary prohibitions.
• Test whether colleagues can find the current rule, classify representative inputs, reach the decider and respond to a mistake without you.

4. Prerequisites

• What you may and may not paste into AI at work, for the input boundary and approved route.
• Rules for things that run without you, especially if your project can send, publish, approve or change something.
• Your chosen project and a sentence naming its useful recurring result, its user and its handoff point.
• The higher-order security, privacy, research, records, employment, procurement and incident rules that actually apply.
• An accountable team owner who can adopt the working rule and identify specialists for decisions outside their authority.
• An existing editor, an approved team publication location that colleagues can access, and time for a walkthrough.

If you are working alone, you can prepare the page and rehearse it with fictional cases. Label it draft - not yet in force; do not claim team adoption. If your team has no approved AI route, the page can explicitly direct the task to the non-AI method while the appropriate owner decides the request.

Do not collect colleagues' prompt histories, customer records, participant data, unpublished text, credentials or screenshots from personal accounts. Ask about task 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 reduces guessing when someone is about to paste, upload, connect, share or act on generated output.

Keep one concise working page because retrieval and comprehension matter. Detailed vendor assessments, contracts, data-protection analysis, ethics decisions and system operating rules belong in their owned records; link or route to them. Do not squeeze those decisions into tiny prose or pretend the page replaces them. A readable scrolling page is better than an unreadable single printed sheet. Use headings, descriptive links and written decisions, not colour alone.

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. Publicly readable does not automatically mean unrestricted reuse, and a managed account does not make every input permissible.

Treat shadow AI as a sign 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. A link and a meeting invitation prove neither permission nor understanding.

Start with the result, not the prohibition

Write this sentence before filling the policy:

Each [cadence or trigger], [colleague] uses [project/tool] to turn [permitted input] into [result] for [recipient]. Before the handoff, [reviewer] checks [specific quality]. If the route or reviewer is unavailable, [fallback] keeps the work safe.

For an optional public-source briefing project, it might read:

Each Monday, the briefing editor uses our approved assistant workspace to draft a short digest from selected public source passages and URLs. The duty reviewer opens each source, checks every summary claim and link, and releases the reviewed document to the team handbook. If the assistant is unavailable, the editor writes the digest manually from those sources. If no authorised reviewer is available, the digest stays a draft and the team receives the source links through its normal approved route instead.

That sentence exposes the real dependency: colleagues rely on a reviewed digest, not on the existence of an AI account. It also separates two failures. A tool outage may have a manual workaround; an absent approval cannot be bypassed just because the deadline is close. Replace the example with your own project. Keep its actual quality check, recipient and fallback rather than borrowing a briefing you do not need.

6. Build the rule around your project

The build has six moves: discover the gaps, confirm authority, fill the page, review it, walk it through and test adoption. Use the project you already chose. The Lab and Company cases later in this section are optional fictional illustrations of the same method, not assignments or evidence of observed teams.

Open the editor and create the working draft

In your existing text editor, create a new file named ai-working-rule.md inside your chosen project's documentation folder. Paste the template below and save it. Do not replace the organisation's policy or an adopted project rule. If an equivalent rule already exists, use its normal draft/review process instead of making a second current copy.

If your team authors directly in an approved document or wiki editor, create a new draft page titled [Project name] - AI working rule in that team's existing space. You do not need both a local Markdown file and a separate maintained document. Choose one authoring route, then designate one current reader-facing location.

At the top, enter draft - not yet in force, the project name, the recurring-result sentence and the owner. The expected result is a clearly non-operative draft, not permission to start using a new tool. Save and reopen it once to confirm you edited the intended file or page. The remaining steps fill that same artifact; they do not require a new tracker or application.

Discover the actual gaps

Use an existing approved survey route, or ask the following questions in a short conversation. Use an anonymous pulse only if the survey settings actually support that claim; a form that records names or sign-ins is not anonymous merely because the questions omit a name field. Tell colleagues who can see responses. Collect 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 point to missing policy content: an approved summarisation route, concrete examples and a visible mistake path. Do not use a small pulse to identify or discipline individuals; even apparently anonymous categories can identify someone in a tiny team.

For your project, a brief conversation may be enough. Ask the colleague who will use the result, not only the person enthusiastic about the tool. Where do they start? What do they receive? Which uncertainty would stop them tomorrow? Put those answers into the working rule rather than collecting a large survey for its own sake.

Confirm who can decide

Before drafting permissions, the team owner identifies the 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. Put the everyday owner and substitute on the page, with routes to specialist decisions. The full authority record can remain where the organisation already maintains it.

An acknowledgement target is not a promise of approval within that time. We will acknowledge within one working day means someone receives and routes the question. It does not mean a new provider or research use can be cleared in a day. For a time-sensitive task, state what the colleague does while waiting.

Fill the working-rule page

Replace every bracketed field with a local answer. If an answer is missing, say not approved - use [fallback] or leave the page visibly draft while the owner resolves it. Do not let a plausible assistant invent the approved account, legal basis, contact person or retention requirement.

[PROJECT / TEAM] AI WORKING RULE - version [VERSION]
Status: [DRAFT - NOT YET IN FORCE / ADOPTED]
Owner: [NAME/ROLE + CONTACT] | Substitute: [NAME/ROLE + CONTACT]
Effective: [DATE OR NOT YET EFFECTIVE] | Review: [DATE] | Questions: [CHANNEL]
Applies to: [PEOPLE, WORK, AND LOCATIONS COVERED]
Recurring result: [INPUT -> RESULT -> RECIPIENT, WITH CADENCE OR TRIGGER]
Current rule: [CANONICAL TEAM LOCATION] | Higher-order rules: [LINKS]

APPROVED ROUTE
Open [APPROVED ENTRY LINK] and use [EXACT TOOL + ORGANISATION-MANAGED ACCOUNT]
for [ALLOWED PURPOSES] with [ALLOWED DATA CLASSES]. Confirm [WORKSPACE/ACCOUNT
IDENTIFIER] before entering content. If absent or different, stop and ask.
[NO APPROVED ROUTE / NON-AI METHOD] is the fallback; find it at [LOCATION].
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 + SUBSTITUTE] checks [SPECIFIC CLAIMS/QUALITY] against [APPROVED
SOURCES], checks missing information and affected-person impact, applies
[DISCLOSURE/LABELLING RULE], and owns the final decision.
Store the checked result at [DESTINATION] with [DRAFT/REVIEWED STATE + SOURCE LINKS].
If checking fails or no authorised reviewer is available, [HOLD/FALLBACK + CONTACT].
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/use [RESULT]; classify [RESULT]; escalate [RESULT]; incident [RESULT]
Next review trigger: review date, changed tool/data/use, incident, or higher-order rule.

The reporting clause needs the responsible employment, legal or incident owner's approval where required. If the team cannot authorise its wording, link to the existing reporting protection and process rather than promising immunity. Keep the practical instruction to stop and report promptly.

This is one artifact, including its adoption record. Meeting notes, test scratch paper and approval messages may support it under local retention rules, but the course exit is the adopted working page itself. Use necessary work contact details through the approved team route; do not publish personal phone numbers, sensitive incident content or individual performance histories.

Make the tool action and handoff concrete

Use approved AI responsibly gives the colleague no next move. The approved-route field should let them open the right entry point and distinguish it from a personal account before submitting content. Record the real workspace label they should see, never a password or token. If you cannot establish that route, keep the no-tool fallback in force. A tools directory or a familiar vendor name does not confer approval.

For the optional briefing project, the local instructions could say:

1. From the project's normal team page, open the AI working rule link. Check its adopted status and version. Follow its approved assistant entry link and confirm the named organisation workspace before entering content.
2. In that assistant's message composer, enter only the selected permitted source passages and their public URLs. Ask for a draft digest that separates source-supported claims from unanswered questions. Do not upload a whole internal folder or enable a connector to save a few clicks.
3. In the existing document editor, create this week's digest in the approved draft location. Copy the generated text as a draft, retaining the source URLs. Do not send it to the recipient yet.
4. The authorised reviewer opens the cited sources in a browser, compares the claims, corrects omissions and checks the digest's local quality requirements. If a source cannot be checked, remove the unsupported claim or hold the draft rather than turning uncertainty into fact.
5. Only after the required review, place the result in the rule's agreed destination and mark its review state using the team's existing convention. The colleague opens that document, not the author's private assistant conversation. If the tool fails, use the manual method; if approval is missing, follow the hold rule.

These are proposed actions for the fictional example, not a claim that a particular assistant or workspace has been installed or approved. For your project, replace the source passages, editor, quality check and destination with its actual flow. A generated lesson resource may need an accessibility check; a draft customer response may need a factual and commitment check; a code change may need the existing review and test route. The working page names that check and its owner. It does not attempt to reteach every specialist practice.

Put the rule where work starts

In the team's existing handbook or project editor, place the reviewed candidate in its approved location, still labelled draft - not yet in force. If you authored locally, transfer the Markdown content through that platform's existing editing route and inspect the rendered result. Keep headings readable, links descriptive and green/yellow/red decisions written out. Avoid wide tables in the working page if they make a phone or enlarged text difficult to use.

Use the platform's existing access controls to give intended colleagues reading access and restrict editing to the responsible maintainers. Do not choose public or organisation-wide access merely because a link is easier to distribute. Ask a colleague using their own authorised account to open the candidate and its required linked instructions. An owner opening their own page does not test reader permissions. Never request a colleague's login or simulate access by borrowing their credentials.

Add a clearly labelled link from the place they normally begin the task: the project home, task instructions or existing runbook. Do not require them to search your private chat history. During testing, keep the current approved rule clearly distinguished from the candidate. Once approval and the tests are complete, mark the new version adopted with its effective date, update the normal entry link if needed, and visibly mark the previous version superseded through the existing records process. Do not leave two apparently current instructions.

Use four measurable adoption tests

Test at least three team members who did not draft the wording. For a smaller team, test every available non-author and record the smaller sample as a limitation; do not invent participants to meet a number. Use only synthetic cards or equivalent fictional cases drawn from your project's input boundaries. Do not test comprehension by asking people to disclose real AI use.

The time and score thresholds are practical checks for this walkthrough, not a certification of safety. Accommodate colleagues' access needs, agree an appropriate findability target where necessary, and record the condition rather than treating assistive technology or reading speed as a failure. The essential question is whether the rule works for the people expected to depend on it.

Use this six-card set if it fits, or replace its subjects with fictional equivalents from your chosen project while retaining the boundary decisions:

Card 6 describes a credential; it must not contain a working one. No actual disclosure is needed to test the decision.

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. Removing a name does not establish permission.

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. Arrange any channel rehearsal with its owner and mark it TEST - synthetic; do not trigger a real emergency response without agreement.

Record actual aggregate results on the page. Keep it draft - not yet in force while an acknowledgement, correction or approval is pending. After wording changes, rerun the complete set so a fix to one example does not silently confuse another. When the accountable owner accepts the tested version, complete the adoption line and effective date.

Optional Lab case: a research group's working rule

Everything in this case, including people, services, dates and scores, is fictional. 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.

Their recurring project is a public-literature briefing for the group meeting. The approved route in this fictional setting 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 remain red until the specific purpose and route are cleared in writing. The non-AI fallback is manual source review; a wholly synthetic structural prompt is an alternative AI task only if that route is already permitted.

Mira uses 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. The sample tracker is only a classification card, not a replacement for the briefing project. The researcher responsible for the briefing checks generated claims against the named sources before colleagues use it. Publication, authorship, ethics, consent and disclosure decisions stay with their existing owners.

The principal investigator authorises testing of candidate RG-AI-1.0. Mira puts the labelled draft in the group's normal handbook without making it look like it has superseded the current guidance. The candidate names the briefing's source list, draft location, duty reviewer, reviewed-result destination and manual method, so another group member can take the next turn.

During a fictional 25-minute 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 candidate 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. They can also find the reviewed-briefing destination and explain the manual fallback.

The data steward later 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. Once the test results and approval are complete, the policy becomes effective on the example date of 8 September 2026, with review on 6 October 2026. Mira updates the normal handbook entry and marks the old FAQ superseded, retaining it as required by the records process.

The adoption line now records authority, access, walkthrough and test results. 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; the review date and event triggers create the next correction point.

Optional Company case: the same method, different work

This case is also fictional. Jonas works with a twelve-person customer-operations team. Their chosen project drafts reusable answers from public product information, not from real customer messages. 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, 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 adapts the common template to create candidate CO-AI-1.0; he does not copy a research group's permissions and assume they apply. 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 responsible person checks generated claims and sources before any resulting 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 handoff is explicit: the drafter saves a proposed answer in the existing review location; the reviewer checks it against current product information and the team's commitment rules; colleagues use only the reviewed version. If the source is unclear or approval is unavailable, they use the existing approved answer or route the question to the manager. They do not turn a plausible new draft into a promise to a customer.

The operations director approves the candidate for testing. Jonas places it in the operations handbook as a draft and runs the same walkthrough. Three non-authors complete the four tests with the Company cards. The edge-case discussion 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 identifies the incident route, output handoff and fallback. After these results and final approval, the example page takes effect on 8 September 2026 with a 6 October review date. Jonas marks the previous local guidance superseded rather than deleting its history.

Neither fictional team has "solved governance." Each has adopted a narrow current rule, demonstrated a legitimate route, exposed a misunderstanding, repaired the page and scheduled review. The useful difference is that a colleague can now take the next turn without treating the author's memory as an essential service.

7. What goes wrong

You copy a corporate policy nobody can use during the task

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 the working page. Ask non-authors to classify cases from the actual project.

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, a non-AI fallback, quick questions and prompt good-faith reporting. Ask about unmet needs 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. Show the entry point and expected workspace identifier. 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, acknowledgement target and specialist route. The owner acknowledges uncertainty and identifies the accountable decider rather than improvising permission. The colleague waits or uses the named fallback.

The no-blame clause promises too much or too little

Symptom: 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, or the rule changes under the reader

Symptom: a tool, account configuration, higher-order rule or team changes while the page still looks current. Alternatively, someone edits a permission in place and colleagues cannot tell which version they followed.

Fix: print owner, status, version, effective date, review date and event triggers. Draft the change through the existing review route. After approval and relevant usability checks, replace the current version and visibly mark the old copy superseded. Preserve required history rather than deleting evidence of what applied.

If a newly adopted rule is wrong, stop the affected use and contact the owner. Use the approved non-AI fallback while the owner prepares a correction. Do not blindly restore an older permission: it may conflict with the very incident, contract or organisational change that caused the update. Restore only a version the accountable owner confirms is still valid, through the existing revision process. Keep incident facts in the incident system, not in a widely readable version note.

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: keep the candidate labelled as a draft until approval and tests are complete. Run the fictional cards with non-authors, repair systematic misunderstandings and rerun the complete set before 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. Include the project's output handoff and author-absence question. Put actual results, not training delivered, in the adoption record.

The page works only from your account

Symptom: your colleague can read the rule but cannot open the approved input location, review destination or fallback instructions. They ask you to forward a private chat or grant broad access to make progress.

Fix: check the necessary links with an intended reader using their own authorised account. Ask the appropriate access owner for the minimum required permission. Until then, use the named fallback; do not widen sharing or move the material to a personal account. A rule that depends on private author-only resources is not ready for colleagues.

8. Do it yourself: prepare, test, then adopt

Continue your chosen project with public, synthetic or explicitly approved practice material. The sequence below is an optional 90-minute working session, not a reading estimate or a promise that approval will fit into a meeting. A one-working-day acknowledgement target cannot honestly be completed on a 90-minute stopwatch. If the accountable owner cannot approve or a test response is pending, finish the draft and record the pending state.

Minutes 0-10: in the project documentation location, create or open the working draft. Write the recurring-result sentence, scope and authority. Name owner, substitute, new-use deciders, output reviewer and incident route. State what the rule cannot approve.

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

Minutes 20-35: adapt the template in the same file or page. Fill in the actual approved entry point and account, purposes, data classes, fallback location, output check and destination, disclosure route, question target and incident action. Leave unsupported permissions explicitly unavailable.

Minutes 35-45: add two green, two yellow and at least four red examples in the language of your project. Include the credential prohibition and the rule that uncertainty means wait or use the fallback. Check the rendered page at a comfortable reading size; shorten repetition, not the necessary decisions.

Minutes 45-55: review authority and safety with the accountable owner and relevant specialist. Remove claims the team cannot make. Obtain permission to test the candidate or leave it a private draft. Do not mark it adopted yet.

Minutes 55-62: place the candidate in the controlled team location, labelled draft - not yet in force. Confirm intended reader access and the entry link from the normal project home. Do not supersede the current rule before the candidate is ready.

Minutes 62-77: run find/use and classify tests with non-authors. Use six fictional cases suited to your project, including the red boundaries. Record actual results and agreed accessibility conditions. If any red card proceeds or the wording systematically confuses people, repair it and arrange a complete rerun; the timer is not a reason to skip it.

Minutes 77-84: send the clearly labelled synthetic edge case through the agreed question route and rehearse the fictional incident aloud. Confirm the substitute and safe fallback when you are absent. Never stage an actual disclosure.

Minutes 84-90: record completed tests and pending items on the draft. Arrange any rerun or awaited acknowledgement. Only after the tests and final accountable approval are complete, enter the effective date, mark the page adopted and supersede old local guidance through the existing process. Add the review date and event triggers.

At the next normal use of the project, invite the colleague to start from the rule rather than from your explanation. If they need a missing link or an unstated decision, that is a concrete correction to the artifact, not a reason to add a second handbook.

9. Exit check

Deliver one artifact: a concise AI working-rule page for your chosen project, adopted by its accountable team owner, with its adoption record on the page.

It passes when the page names the recurring result and recipient; scope; exact approved tool and managed account or explicit no-tool fallback; allowed purposes and data classes; green, yellow and red examples; the specific output review and destination; edge-case owner, substitute, route and acknowledgement target; mistake route and appropriately authorised reporting clause; accountable approver; effective date; and review date.

Non-author colleagues must find the intended version, access the necessary links, explain the output handoff and fallback without your prompting, 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. Use three testers where the team has them; record a smaller team's actual sample and the resulting limitation. Record agreed accessibility conditions and actual results, not invented scores. If wording changes after a failed test, rerun the complete set before adoption.

The page must contain no real prompt histories, sensitive incident content, customer or participant records, unpublished research material, credentials or personal-account screenshots. Necessary owner roles and approved work contact details belong on it; unrelated personal data does not. Supporting evidence stays in the appropriate controlled records.

A draft without accountable approval, a link without usable access, a page without the walkthrough or a rule with no substitute and review date is not adopted. Report it honestly as prepared or pending. The colleague dependency is the final question: can someone take the next turn, recognise when to stop, and find the safe next action when you are unavailable?

10. Rule to remember

One working page, one accountable owner, one review date. Put it where the next colleague starts.

11. Further reading & tools

• What you may and may not paste into AI at work supplies the green/yellow/red input rule, approved-route boundary and everyday privacy precautions.
• Rules for things that run without you adds approvals, limits, accountability and a stop path when a build can act without its author. Keep those system controls distinct from the working rule for colleagues.
• Show a colleague: the 30-minute demo helps a colleague make an informed choice about a useful first task; a demonstration is not continuing permission for every use.
• Rolling it out takes the next step into wider adoption, cost, support and objections after the working boundary is usable.
• NIST AI Risk Management Framework (opens in a new tab) is a voluntary risk-management framework. It does not approve a tool, policy or data use. Its official overview was checked for this revision.
• NIST AI RMF Playbook (opens in a new tab) offers optional risk-management actions. This route is linked from the checked NIST overview; the Playbook was not separately reviewed for this revision. Select actions that fit local authority and context, not a checklist for its own sake.
• NIST Privacy Framework (opens in a new tab) is an inherited reference for voluntary privacy-risk guidance, not a fresh legal assessment. Local legal, contractual, research and organisational decisions still apply.
• Tools index helps compare capabilities only after you define purpose, account, data, owner and approval requirements. This book needs your existing editor and controlled team publication route, not another product purchase.