Two clinicians finish this level of training on the same afternoon, and by the next morning they are already different practitioners. The first goes back to the floor and improvises. Some shifts she edits the ambient note carefully; other shifts, tired and behind, she signs it half-read. Some days she tells patients a draft was AI-assisted; other days it does not occur to her. She pastes a chart summary into whatever tool is open without checking whether there is a business associate agreement behind it, and she could not tell you, if asked, exactly what she verifies before she commits an output. She is not careless. She is simply deciding all of this over and over, live, forty times a day, under load, which means she is deciding it inconsistently, which means eventually she will decide it wrong. The second clinician does something almost trivially small. Before she leaves, she sits down for twenty minutes and writes one page. It says which tools she uses for which tasks, what she always checks before she signs, how she tells patients, what she will never do, and how she documents that a human decided. That one page is the difference between practicing with AI and being practiced upon by it. This lesson is about writing that page.

The One Page Is the Graduation Artifact of This Level

Everything in Level 2 has been a rehearsal for this. You learned how ambient scribes actually work and how to edit and verify the note before you sign it. You learned to summarize a longitudinal record without losing the signal, and to catch the fabricated or dropped fact hiding in a smooth summary. You learned when to trust an AI answer to a clinical question and when to look it up, how to ground a citation, how to verify a drug interaction. You learned to draft patient-friendly messages and answer the portal inbox without softening bad news, and to disclose AI use under AB 3030 and TRAIGA. You learned to use AI for prior authorization, coding support, scheduling, referral and order drafting, without walking into the upcoding trap or letting a tool decide clinical urgency. And in the previous lesson you learned the verification habit itself: the reusable, risk-tiered routine you run before you commit anything.

All of that lives, right now, in your head as a set of separate skills. The problem with skills that live only in your head is that they are subject to the same load, fatigue, and automation bias that Level 1 taught you to fear. On a good day you apply them all. On a bad day you apply the ones you happen to remember. A personal AI operating procedure is the fix: it moves the rules out of your working memory and onto a page, so that on your worst shift you are still governed by the standard you set on your best one. This is what mature professions do with high-stakes judgment. Surgeons use checklists. Pilots use them. The page you are about to write is your checklist for practicing with AI, and it is the artifact that turns this level from things you learned into a way you work.

A rule you keep only in your head is a rule you keep only when you have the attention to spare. The whole point of writing it down is that your worst shift gets governed by your best judgment.

Keep it to one page on purpose. A ten-page policy is something you read once and never open again. A one-page procedure is something you can actually carry, actually revisit, and actually follow when the basket is full. It should be short, it should be real (yours, not a generic template), and it should be revisited as your tools change, because they will. What follows is the anatomy of that page: five components, each of which synthesizes a strand of everything you have learned.

Component One: Which Tools for Which Tasks, and Which You Refuse

The first section of your page is a plain inventory: for each task you do, which AI tool (if any) you use, and, just as importantly, which tasks you deliberately keep AI out of. This is not a technology list. It is a map of where you have decided the tool earns its place and where you have decided it does not. The act of writing it forces a decision you have probably been making implicitly and inconsistently, and it exposes the tools you are using out of habit rather than judgment.

Be specific about the task, because the same tool is safe on one task and dangerous on another. An ambient scribe is well-suited to drafting the visit note and poorly suited to deciding the plan. A summarizer is useful for orienting you to a long chart and unfit to be the only thing you read before a high-stakes decision. A drafting tool is excellent at turning a verified finding into plain-language patient wording and untrustworthy as a source of clinical facts. The point of listing tasks, not just tools, is that your procedure captures the task-by-task risk you learned across this level, rather than flattening everything into "I use tool X."

The refusals matter as much as the uses. There will be tasks where you decide, for now, that no available tool clears your bar: perhaps you will not let AI draft the assessment and plan, or you will not use a consumer chatbot for anything touching a patient, or you will not let a tool auto-route urgent messages without a human reading them first. Writing your refusals down is what keeps them from eroding quietly the next time a vendor demo is impressive or a colleague is enthusiastic. A refusal you have written and reasoned is a decision. A refusal you merely feel is a mood, and moods do not survive a busy Tuesday.

Component Two: What You Always Verify Before You Commit

This is the heart of the page, and it is the verification habit from the previous lesson, made concrete for the specific things you touch. The principle you carry forward is that verification is risk-tiered: you do not check every token with equal suspicion, you spend your attention where a wrong output does the most harm. Your job here is to write the short, explicit list of items that you never let out of your hands without confirming them against the source, no matter how fluent and confident the output looks.

The list below is the spine of that section. These are the items where AI-assisted work has been shown, across this level, to fail quietly, and where the cost of the failure lands on a patient. Treat every number as something to verify against the source, not repeat blindly, because a plausible wrong number is the most dangerous kind.

Your version of this list should be yours: shaped by the tasks you actually do and the tools you actually use. But it should not be shorter than the risk warrants, and it should not soften into "review the output." "Review" is a wish. "Confirm the dose, the laterality, the abnormal values, and that the note supports the code, against the source, before I sign" is a procedure. The difference is whether, six months from now, a colleague could hand your page to a new hire and have them practice as safely as you do.

Notice what risk-tiering actually buys you on a real shift. You do not have the attention to treat every token of every AI output with equal suspicion, and if you tried you would either burn out or, more likely, quietly abandon the whole practice by the second bad Tuesday. The point of the tier is to spend your finite scrutiny where a wrong output does the most damage. A misspelled word in a patient message is a nuisance; a transposed digit in a heparin dose is a code. A slightly clunky sentence in a referral is forgivable; a dropped potassium of 6.2 in a discharge summary can kill someone. When you write the tier, you are pre-deciding, in calm, where the half-second of extra reading has to go, so that under load your attention lands on the heparin and the potassium by reflex rather than by luck. That is the difference between a habit that survives a hard shift and a good intention that does not.

Component Three: How You Disclose AI Use to Patients

The third section commits you to a consistent disclosure practice, because disclosure that happens only when you remember is disclosure that fails the patients you forget. This is where your page honors the state law you studied: California's AB 3030, which requires that generative-AI communications to patients about clinical matters carry a disclaimer that AI was used and a way to reach a human, and Texas's TRAIGA, which requires disclosure when AI is used in a patient's diagnosis or treatment. Even where no statute reaches you, the ethical baseline is the same: patients are entitled to know when a machine helped shape what they are told, and to reach a person.

Write down, in plain terms, the three things your disclosure practice guarantees. First, when you disclose: which communications and which uses trigger it, so you are not deciding case by case. Second, what the disclosure says, in plain language a patient can understand, not legalese: that AI helped prepare this, and that a member of the care team reviewed it. Third, the human-contact path: the concrete way a patient reaches a person with a question, which is both an AB 3030 requirement and a matter of basic decency. If your organization has standardized disclosure language, your page points to it. If it has not, your page contains yours, so you are never improvising a disclaimer under time pressure.

Disclosure is not an admission of weakness in the tool; it is the practice that keeps trust intact. A patient who learns after the fact that AI was involved and was not told feels deceived. A patient who is told plainly, and given a way to reach a human, sees a care team using a tool responsibly. Your procedure makes the honest version the default.

Component Four: What You Never Do With AI

Every operating procedure needs a set of bright lines: things you will not do regardless of the pressure, the deadline, or how well the tool seems to be performing. Bright lines are valuable precisely because they do not require judgment in the moment. You decided them once, in calm, so that you do not have to relitigate them at 4:50 on a Friday. Four belong on nearly every clinician's page.

• Never paste PHI into a tool with no BAA. A business associate agreement is what makes it lawful for a vendor to handle protected health information under HIPAA. No BAA means the tool is not covered, and pasting identifiable patient data into it is a breach, not a shortcut. This includes consumer chatbots. It also invokes minimum necessary: even in a covered tool, you share only what the task requires.
• Never let AI assert a fact the record does not support. Whether it is a diagnosis code, a sentence in a prior-auth letter, or a claim in a note, if the chart does not support it, it does not go out over your name. This is the single discipline that prevents most AI-related documentation harm.
• Never sign an output you did not verify. Your signature, your attestation, is a statement that you reviewed and agree. Signing an unverified draft is not efficiency; it is attesting to something you have not checked, and the accountability lands on you regardless of which tool produced it.
• Never let AI decide clinical urgency unchecked. A triage score, an inbox priority, a routing decision: these are inputs to your judgment, not substitutes for it. The one message the tool mis-ranked is the one that will hurt a patient, and a human owns the decision that it can wait.

Each of these has a failure story behind it that is worth keeping in mind as you write your own. The no-BAA line exists because a well-meaning clinician pasting a full note into a consumer chatbot to get a cleaner summary has just disclosed protected health information to a vendor with no legal obligation to protect it, and that is a reportable breach, not a productivity hack. The assert-nothing-unsupported line exists because the fastest route to a fraud or a malpractice finding is a prior-auth letter or a note that states a fact the chart cannot back up. The never-sign-unverified line exists because your attestation is the one thing in the record that a court reads as your personal word. And the urgency line exists because triage tools optimize for the average message, and the one they mis-rank is, by definition, the one that did not look urgent to a pattern-matcher and did to a human who knew the patient. These are not paranoia. They are the operational form of the accountability principle from Level 1: the cardinal rule that accountability stays human. AI can assist every task on your page. It cannot inherit your license, your attestation, or your duty to the patient, and the never-do list is where you refuse to let it try.

Component Five: How You Document That a Human Decided

The final section commits you to a documentation practice, because in a dispute the record is the only version of events that counts, and the record must show that a human decided. This closes the loop that runs through the entire level: AI assists, the clinician decides, and the record proves it. If the record cannot prove the third clause, the first two do not protect you.

Your documentation practice should make three things reconstructable after the fact. First, that AI assisted: an honest, non-defensive acknowledgment that a tool contributed to the work, consistent with your organization's convention and with any attribution the record supports. Second, what you verified: not a novel, but enough that someone reading later can see you checked the things that mattered, especially on higher-risk outputs. Third, why you agreed or overrode: when you accepted the AI's output, that your judgment concurred; when you overrode it, what you changed and why. An override that is documented is a clinician exercising judgment. An override that is invisible looks, later, like it never happened.

This is the practice that makes your decision defensible and, more importantly, correct, because the discipline of documenting that a human decided is also the discipline of actually deciding. You cannot honestly write "verified against source, agree with plan" about an output you rubber-stamped. The documentation requirement, done sincerely, is a forcing function for the verification it records. That is the quiet reason it belongs on the page: it is not paperwork about the decision, it is part of how the decision gets made well.

One Clinician's Page, and Where It Leads

A worked example

Abstractions do not fit in a pocket, so here is a sample one-page personal AI operating procedure, written the way an actual clinician might write it. It is not a template to copy verbatim; it is a shape to adapt. Notice that it is short, specific, and organized around the five components. Yours will name different tools and different tasks, but it should feel like this: a page you could hand to a colleague and have them understand exactly how you practice.

My AI Operating Procedure (rev. this quarter)

1. Tools and tasks. Ambient scribe: visit-note draft only, never the assessment and plan (I write those). Summarizer: to orient to a long chart, never as my only read before a high-stakes call. Drafting tool: patient-message and letter wording from facts I have verified. Coding assistant: suggestions only, I confirm support. I do not use any consumer chatbot for anything touching a patient. I do not let any tool auto-route messages without a human reading them.

2. Always verify before I commit. Every dose, route, frequency. Laterality and site. Abnormal and critical values plus trend. That the note supports every code. Message urgency and routing. The clinical question on every referral. Every clinical assertion in a prior-auth letter. Numbers get checked against the source, not repeated.

3. Disclose. Any AI-assisted patient communication carries our standard plain-language line that AI helped prepare it and the team reviewed it, plus how to reach a person (AB 3030). If AI touched diagnosis or treatment, I disclose it (TRAIGA). I do not improvise disclaimers.

4. Never. Never paste PHI into a no-BAA tool (minimum necessary even in covered ones). Never let AI assert what the record does not support. Never sign what I did not verify. Never let AI decide urgency unchecked.

5. Document. That AI assisted, what I verified on higher-risk work, and why I agreed or overrode. The record must show a human decided.

Read it back and notice what it does. It is opinionated. It refuses some things outright. It names the risk-tiered verification list rather than gesturing at "review." It commits to disclosure and documentation as defaults, not as things done when remembered. And it fits on one page, which is the only length that survives contact with a real clinical day. That is the artifact. The twenty minutes it takes to write your own version is the best-spent twenty minutes of this level.

From personal practice to designed workflow

Your page is a personal discipline, and it is exactly the right thing to build first, because you cannot design a safe system around a practice you have not yet mastered yourself. But a personal procedure has a ceiling. It protects the patients you touch, when you remember, on the shifts you work. It does not protect the patient touched by the colleague who never wrote a page, or the patient processed by an automated workflow at 2 a.m. when no clinician is watching a particular step. Scaling safety past yourself is the work of Level 3, and everything you just wrote becomes the seed of it.

Level 3 moves from personal practice to designing end-to-end clinical AI workflows, and each component of your page becomes a design pattern for a whole team. Your "always verify" list becomes verification gates set by risk level, engineered into the workflow so the check happens whether or not any one person remembers. Your never-do line about urgency becomes the human-in-the-loop design pattern, the deliberate placement of a required human decision at the point where it matters, which is the very next lesson. Your documentation practice becomes documenting AI involvement in the record at the system level, so an audit can reconstruct who decided what. Your instinct that a tool's answer must be grounded becomes the discipline of prompting and grounding AI on your local protocols and real sources. The personal habit and the designed system are the same principles at two scales.

So carry the page forward as more than a checklist. It is a specification. When Level 3 asks you to help design a clinician-AI handoff, or set a verification gate, or decide where a human must stay in the loop, you will already know the answers, because you will have lived them one patient at a time. The clinician who has never written her own procedure has nothing to design from. The clinician who has, is ready to build. Keep the page short, keep it real, and revise it as your tools change, and it will keep being true long after the specific tools on it are gone.

Key Takeaways

• A personal AI operating procedure is a one-page rulebook that moves your judgment out of working memory and onto paper, so your worst shift is governed by the standard you set on your best one.
• It has five components: which tools for which tasks (and which you refuse), what you always verify, how you disclose, what you never do, and how you document that a human decided.
• The always-verify list is risk-tiered: doses, laterality, abnormal values, coded-diagnosis support, urgent-message routing, the referral's clinical question, and every clinical assertion in a prior-auth letter, all checked against the source, not repeated blindly.
• Disclosure is a default, not an afterthought: honor AB 3030 (generative patient communications carry a plain-language disclaimer and a human-contact path) and TRAIGA (disclose when AI touches diagnosis or treatment).
• The never-do bright lines are the operational form of accountability: no PHI in a no-BAA tool, no asserting what the record does not support, no signing what you did not verify, no letting AI decide clinical urgency unchecked.
• Documentation must make it reconstructable that AI assisted, what you verified, and why you agreed or overrode, because in a dispute the record is the only version of events that counts.
• The iron rule of the whole level: AI assists, the clinician decides, and the record proves it.
• Keep the page short, real, and revisited, and it becomes the specification you carry into Level 3, where these personal habits become designed end-to-end workflows with verification gates, human-in-the-loop patterns, and grounded prompting.