The AI Acceptable Use Policy a Medical Practice Can Actually Enforce

Two failure modes, and they are opposites. The first is the blanket ban: no AI tools, no exceptions. Staff use them anyway, on personal accounts and personal devices, and the practice now has the same exposure with none of the visibility. The second is the aspirational policy, four thousand words of principles about fairness and transparency, which nobody reads and which answers none of the questions a medical assistant has on a Tuesday afternoon.

A policy people follow is short, specific and concrete about the tools they actually have. It names products. It gives examples of prohibited inputs in the practice's own vocabulary. It tells someone what to do in the first ten minutes after a mistake. And it is enforceable, which means the rules are ones a manager could actually observe being broken.

The context matters here. The American Medical Association reported that 66 percent of physicians surveyed in 2024 said they were using AI in practice, up from 38 percent in 2023. Whatever your policy says, the tools are already in the building. A policy written on the assumption that adoption has not started yet is describing a practice that does not exist.

This article is operational guidance, not legal advice. The structure and the questions are ours; the final wording should be reviewed by counsel who knows your state and your payer contracts.

Open with three short paragraphs that leave no room for a reasonable person to think they are exempt.

Who it covers. All employees, contractors, locum and per diem clinicians, students, volunteers and vendor personnel working on practice premises or with practice data. The contractor and locum clause is the one most often missing, and locums are frequently the heaviest users of general purpose tools because they are working across several systems.

What it covers. Any software that generates, summarises, classifies, transcribes or drafts content using artificial intelligence, whether the practice bought it, whether it is free, whether it is a feature inside a system you already use, and whether it is accessed on a practice device or a personal one. Naming the personal device case explicitly closes the most common loophole.

What it does not cover. Say so. Spell checkers, calculators and rules based clinical alerts inside your EHR are not in scope, and listing the exclusions stops the policy from being read as absurd. If your practice uses ambient documentation or an AI phone agent under a signed agreement, name those systems as approved rather than leaving staff to infer it.

The approved tool list is the working heart of the policy, and it should live in an appendix so it can be updated without reissuing the whole document. Every row needs four facts: the tool, whether a business associate agreement is in place, what it may be used for, and who owns it internally.

Two rules make the table work. First, a tool that is not on the list is not approved, and the default is no rather than ask forgiveness. Second, the list has a named owner and a review date, because an appendix that has not changed in a year is one staff have stopped believing. Comparing candidates for that list is what our HIPAA compliant AI tools review is for, and pricing questions on the documentation side are covered in the AI scribe pricing comparison.

This is the section people will actually read, so make it concrete and put it early. The governing rule is simple to state: protected health information may be entered only into tools on the approved list, only for the approved purpose, and only where a business associate agreement is in place. The HIPAA obligation does not change because the recipient is a model rather than a person.

Then give examples in your own language, because abstractions do not transfer. Prohibited inputs into an unapproved tool include:

• Names, dates of birth, addresses, phone numbers, email addresses or medical record numbers of patients
• Any part of a clinical note, letter, referral, imaging report or pathology report, even with the name removed
• Photographs of documents, screens, whiteboards or wristbands
• Appointment lists, schedules, surgery lists or panel reports
• Audio of a consultation, including a voice memo made for your own convenience
• Claim files, remittance advice, denial letters or payer correspondence
• Staff personnel information, which is not PHI but is confidential for other reasons

Address the de-identification shortcut directly, because it is the most common rationalisation. Removing a name is not de-identification. A note describing a rare condition, an unusual occupation and a specific date of surgery can identify a patient in a small community without a single formal identifier in it. Unless someone has applied a recognised de-identification method and documented it, treat clinical text as identifiable.

Say something about what staff may do. A policy that only prohibits reads as hostile. Drafting a patient education handout on a general topic, rewriting a practice letter template, summarising a public guideline or generating interview questions are all reasonable uses of an approved tool with no patient information involved, and saying so buys you compliance on the parts that matter.

One sentence, and it should be the sentence people remember: the person who uses the output owns it.

Spell out what review means for each category, because it differs:

• Clinical notes. The signing clinician reads the full note before signing. Signing without reading is a policy violation regardless of how good the drafts have been. State that clinicians remain responsible for accuracy, and that a documentation tool is a drafting aid rather than a record of what happened.
• Patient communications. A named staff member reads and approves any AI drafted message before it is sent, unless the message type is on a specifically approved automated list such as appointment reminders. Draft replies in the clinical inbox are drafts.
• Coding and claims. A qualified coder or biller reviews suggestions. Submitting a code because a tool suggested it is not a defence, and coding automation should be configured to require that review.
• Clinical decisions. No AI tool in the practice makes or replaces a clinical decision. If a tool starts offering clinical recommendations, it goes back through review before continued use, and may fall under FDA device oversight.

Add a line about vigilance that acknowledges reality: models produce fluent text that is sometimes wrong, and the errors that get through review are the plausible ones. Reviewers should specifically check names, dosages, laterality, dates, numbers and anything the model could not have known from the encounter.

Assume the mistake will happen and design for the first ten minutes after it. The reportable events are narrow enough to list:

1. Patient information was entered into an unapproved tool, in any amount
2. AI generated content containing an error reached a patient, a payer or the record
3. A tool produced output that was clearly wrong in a way that could have caused harm
4. A tool behaved differently after a vendor update, in a way that affects safety or accuracy
5. An account, device or credential giving access to an approved tool was lost or compromised

Give one route and one deadline: report to the privacy officer or practice manager the same working day, by any means, in plain language. Then state the response commitment in the policy itself, because that is what determines whether anyone reports. Good faith reports of accidental disclosure do not result in disciplinary action; concealing one does. Practices that get this wrong learn about incidents from patients.

The privacy officer then runs the ordinary process: assess whether the disclosure is a breach under the HIPAA breach notification rule, document the analysis whatever the conclusion, and record the event in the practice's incident log. An AI incident is not a new category of event, and treating it as one usually means it bypasses the process you already have.

Work through it in this order, and expect the whole exercise to take a few hours of real work rather than a week.

1. Inventory first. Ask every staff member what tools they use, with an explicit amnesty. Write the policy against that list rather than against an imagined one.
2. Fill the appendix. Populate the approved tool table. If you have no enterprise tool at all, that is your first gap, because staff will otherwise use consumer ones.
3. Localise the prohibited inputs. Rewrite the examples in your own workflow vocabulary. A dermatology practice should name clinical photographs; a behavioural health practice should name session notes and address 42 CFR Part 2 where it applies.
4. Set the review cadence. Appendix reviewed quarterly, policy reviewed annually, with a named owner for each.
5. Have counsel read it. Particularly if you operate in a state with its own AI or health data statutes. California, Colorado, Texas and Utah have each moved, and the disclosure obligations differ.
6. Train on it once, properly. Thirty minutes, with the examples, not an attestation click. Then attest.

Enforcement fails when the policy prohibits things staff need to do and offers no substitute. Someone drafting a difficult patient letter at nine in the evening will use the tool that is available. If the only available tool is a consumer chatbot, that is the practice's procurement problem before it is the employee's discipline problem.

So pair every prohibition with a permitted route. Prohibit consumer chatbots and license an enterprise tier. Prohibit voice memos of consultations and provide a documentation product. Prohibit pasting denial letters into unapproved tools and put denial management on the roadmap. The prohibitions that hold are the ones with an alternative attached.

Then keep the enforcement proportionate and visible. A first accidental disclosure reported promptly is a coaching conversation and a note in the log. A repeated or concealed one is a disciplinary matter. Publishing that gradation in the policy does more for compliance than any amount of severity, because it makes reporting the rational choice.

Review the whole thing when the tools change, which currently means at least annually. If you would rather not write it from a blank page, the policy set, the approved tool appendix and the staff training are what our staff training and AI governance engagements produce, usually starting from the same tool inventory described above. Practices at the smaller end will find the segment specific version in our notes for private practice.