Picture the Tuesday this policy is really about
It's 11:40 a.m. at a 22-person orthopedics practice. The referral coordinator has eleven incoming faxes from primary-care offices, each with a patient name, DOB, imaging notes, and a diagnosis code. She's drowning, so she opens a free chatbot and pastes the whole packet in with one instruction: "summarize these and tell me which need prior auth." Thirty seconds later she has a tidy table. She also just sent eleven patients' protected health information to a consumer tool with no business associate agreement, no logging, and a data-retention policy nobody read.
That moment—not some sci-fi scenario about AI reading X-rays—is what an acceptable-use policy for a specialty practice exists to prevent. The clinical side is already heavily governed and the providers know it. The exposure lives in the administrative seams: intake, referral routing, payer appeals, scheduling exceptions, and the staff who are trying to move faster, not break rules.
Broader research backs the instinct that small organizations need ownership and guardrails before AI helps rather than hurts. The RSM middle-market AI survey, the San Francisco Fed small-business AI analysis, and the OECD SME AI adoption report all point the same direction: a small staff with no clear rules will improvise, and improvisation around patient data is where the trouble starts. Your policy isn't a research paper. It's the answer the coordinator should have had ready before she hit paste.
Draw the line at "could this identify a patient?"
Most practice policies fail because they're written as a list of approved software. Software changes; the question of what's safe to type doesn't. Sort every task by a single test: does the input or output contain anything that could identify a patient?
On the green side—open to an approved assistant, no special review—sit the things a practice does that have nothing to do with a specific patient. A new-hire onboarding checklist for the front desk. A generic script for explaining your no-show fee. A draft job posting for a second medical assistant. An outline for staff training on the new scheduling system. None of this touches PHI, so let people move fast on it.
On the red side sits everything that names, codes, or describes a patient or their coverage: referral packets, intake summaries, prior-authorization narratives, payer appeal letters, denial responses, anything with a diagnosis or procedure code, provider schedules tied to patient panels, and employee health records. These don't go into a tool without a business associate agreement, configured retention, access logging, and a named reviewer who checks the output before it's used or sent. The hardest cases are the appeal letters—staff love drafting them with AI because medical-necessity language is tedious, and that's exactly why a clinician or billing lead has to read every word before it goes to the payer.
For the structure underneath those rules, the NIST AI Risk Management Framework gives you the risk-management spine, and CISA's AI Data Security Best Practices covers how sensitive data should be handled inside AI systems. When you evaluate a specific assistant, vendor documentation like Microsoft 365 Copilot's privacy and data controls or OpenAI's enterprise privacy commitments tells you what a configured, business-tier tool will and won't do with your data. None of those documents are a substitute for a signed BAA or for your own judgment about what a patient would expect—they tell you whether a tool is eligible to even be considered.
One page, one owner, and a monthly spot-check
A specialty practice does not need a governance committee. It needs a one-page document and a person whose name is on it—usually the practice administrator or office manager. That page lists the approved assistants, the bright-line rule on patient-identifying data, the expectation that PHI-adjacent use is logged, who reviews output before it leaves the building, and the single channel for raising a privacy question ("text me, don't guess"). If it's longer than a page, the front desk won't read it, and a policy nobody reads is decoration.
Then make it real with a recurring spot-check. Once a month, the owner pulls a handful of actual artifacts—a referral-routing note, a prior-auth narrative, a payer appeal draft, a training handout—and asks two questions: was the right tool used, and did the right person review it? You're watching for two specific failure modes. First, PHI slipping into an unapproved tool because someone was slammed. Second, AI output that drifts from administrative summary into something that reads like a clinical opinion—an appeal that asserts medical necessity the chart doesn't support, or an intake note that editorializes about a diagnosis. Both are caught by a human reading the output, which is why the reviewer role is the load-bearing part of the whole policy.
Two quick gut-checks before you roll anything out: can your staff name the one place to ask a privacy question without thinking, and does every PHI-adjacent task have a named reviewer? If either answer is fuzzy, fix that first. To pressure-test your data boundaries and reviewer setup, run the SMB AI readiness assessment, then use the 90-day implementation plan to sequence training, pick your first low-risk pilot, and put real controls behind the page.
