The page you write for yourself
Why a written rule beats good judgement
Everything in this course is useless at 6pm on a Thursday if it has to be recalled and applied under pressure. Risk assessment made in the moment tracks convenience — at the end of a hard day, everything looks low-stakes and everything looks urgent.
A rule written on a calm afternoon survives the day it is inconvenient, which is the only day it does any work. This lesson is the artefact: one page, thirty minutes, reviewed twice a year.
The six sections
1. What I use it for. List the actual tasks, specifically. "Drafting first versions of internal documents. Explaining unfamiliar technical material. Rewriting my own text for length. Generating practice questions. Debugging code I wrote." Specificity here is what makes the rest of the page apply to something.
2. What I never use it for. Short, absolute, memorable. Five items maximum. Typically: anything I am professionally licensed to judge personally; crisis conversations; final decisions about a named person; anything I would be unable to explain if challenged; and one that is specific to your work.
3. What never goes in. The data list. Credentials and keys. Identifiable information about clients, patients or children. Material under an NDA. Unreleased financial information. Third parties' private messages. Add the rule that follows: if I cannot remove the identifiers, I use a local model or I do not use one.
4. Verification by tier. The triage from the first module, written as a schedule. Low: skim. Medium: check every specific claim, name and number, and form my own view before reading the output. High: verify against a primary source I open myself, have a second person read it, and record what was checked. Add the trigger that moves something up a tier: irreversibility, another person bearing the cost, repetition at scale, or no route to appeal.
5. Disclosure. When I say I used it, in what form, and to whom. Cover the contexts you are actually in: work deliverables, published writing, academic submissions, client work.
6. Stop conditions. The part almost nobody writes and the most valuable. Finish these sentences honestly:
- I would stop using this tool for this task if…
- I would know my skills were degrading if…
- I would report an incident if…
A stop condition written in advance is a commitment you can be held to by yourself later, when the honest answer has become inconvenient. Without one, you will not stop, because there will be no moment at which stopping is obviously required.
A worked example, compressed
Use: first drafts of internal reports; explaining unfamiliar statistics; rewriting my own text; generating practice questions; reviewing code I wrote.
Never: clinical judgement; anything going to a regulator without a colleague's review; final wording of a performance assessment.
Never in: patient identifiers; credentials; the contents of the HR shared drive.
Verification: internal notes, skim. Anything sent outside the team, every figure checked against source. Anything about a named individual, second reader and a record.
Disclosure: stated in the document footer where a section was AI-drafted.
Stop if: I find myself unable to produce a section unaided; a checked output is wrong twice in a month; or a colleague tells me the writing no longer sounds like me.
Review: March and September.
That is one page. It took twenty minutes and it will make several hundred decisions on your behalf.
The organisational version
The same six sections, plus three: which tools are approved for which data categories, who to tell when something goes wrong and what will happen when you do, and who owns the page and when it is next reviewed.
Most organisational AI policies say "use AI responsibly", which delegates the entire question back to the person least equipped to answer it in the moment. A page that names tools, data categories and verification requirements is worth more than twenty pages of principles.
Review, and expect to be wrong
Set a date. Twice a year is enough. At each review, ask three things: what did I use it for that is not on the list, what went wrong since the last review, and what has changed about the tools. The list will have grown by itself — that is normal, and the review is where you decide whether the growth was a good idea.
The page is not a constraint on using these tools. It is what makes using them heavily defensible.
The one thing to keep
Write one page — uses, absolute exclusions, what never goes in, verification by tier, disclosure, and stop conditions — because a rule written on a calm afternoon is the only kind that survives the day it becomes inconvenient.
Before you move on
Which section of a personal AI policy is most often omitted and does the most work when a tool starts causing problems?
Pick the one you would defend. Nobody sees your answer.