A generative AI policy for healthcare staff should answer practical questions before anyone opens a chatbot: Which tools are approved? What information can staff enter? What should they do if a tool is not approved for patient data?
A blanket ban can leave staff without clear options, while a general instruction to “use AI responsibly” is difficult to follow consistently. A useful policy sets boundaries by tool and use case, offers safe alternatives, and gives staff a straightforward way to request approval or report a mistake.
This guide offers general operational ideas, not legal advice. Clinics should have their privacy, security, and compliance leads review policies for their own environment. CMS’s AI guidance is an example of agency guidance, not a universal rule for every healthcare organization. The NIST Generative AI Profile offers a voluntary framework for thinking about generative AI risks.
Start with a clear tool and use-case register
Do not treat all AI tools, or every task performed in one tool, as equivalent. A tool might be acceptable for drafting general educational material but not approved to receive patient information. Record approval at the level staff need to make a decision: the specific tool, its permitted uses, and the type of information allowed.
A simple register can sort tools into three categories:
- Approved for specified patient-information workflows: Name the approved use cases and the data staff may handle. Approval should apply to the documented setup and workflow, not merely to the vendor’s brand.
- Approved for non-PHI work only: Staff may use the tool for permitted general tasks, but must not enter patient information or other confidential material.
- Not approved: Staff should not use the tool for clinic work unless it is reviewed and approved.
For each listing, identify a responsible owner, permitted data and uses, any conditions staff must follow, and when the listing should be reviewed. Revisit it when the tool, its settings, the vendor’s terms, or the intended workflow changes.
Set practical rules for patient information
Define patient information broadly enough that staff do not assume only a name or medical record number needs protection. Text can include identifying details in a combination of facts, such as a distinctive event, location, date, or clinical narrative. Removing a name alone does not automatically make a prompt safe.
For tools that are not approved to process PHI, instruct staff not to enter identifiable patient details, clinical notes, images, records, or other information that could reveal who a patient is. Make clear that changing a name or swapping in initials is not a substitute for an organization-approved de-identification process.
If a workflow needs patient information, staff should use only a tool and configuration approved for that specific purpose. The review should establish what data moves through the service, how the vendor handles it, and what safeguards and terms apply. A vendor’s statement that a product is “HIPAA-compliant” is not, by itself, approval for the clinic’s use.
Where applicable, the clinic should determine whether a business associate agreement is needed and whether the agreement covers the particular service and workflow. A BAA is not a standalone green light: the organization still needs to review the tool, data handling, safeguards, and intended use with appropriate privacy and security advisors.
Give staff safe alternatives, not just prohibitions
When a tool is not approved for PHI, staff still need a way to complete routine work. The policy should name alternatives, such as:
- Using clinic-approved templates for routine messages, summaries, or administrative tasks.
- Working with synthetic examples that do not describe a real patient or reproduce details from a real record.
- Using an organization-approved AI system for an approved workflow, following its specific instructions.
- Submitting a tool or use-case request to the designated reviewer before using it with sensitive information.
Give examples of acceptable and unacceptable prompts without copying real patient material into the policy or training. For instance, a staff member could request a general explanation of how to structure a patient education handout, without including a patient’s diagnosis or personal circumstances. For individualized work, staff should follow the approved clinical workflow rather than asking an unapproved tool to interpret patient details.
For more on the wider safeguards around patient information, see Zevonix’s guide to enhancing patient data security.
Use a consistent approval process
Before a new tool or use case is approved, have the appropriate people assess the purpose, data flow, access, vendor terms, security and privacy considerations, and human review requirements. Depending on the clinic, that may involve privacy or compliance leadership, security and IT, operational owners, and clinical leadership.
Ask the requester to explain the task, who will use the tool, what information it will receive, and how the output will be used. Review whether the tool’s settings and vendor terms fit that use. Confirm any applicable agreement requirements, and define what staff must check before relying on or sharing output.
Document the decision and communicate it in plain language. CMS’s responsible-use guidance can help organizations consider governance and risk, while the NIST profile provides a voluntary way to organize generative AI risk management. Neither should replace the clinic’s own review of its obligations and circumstances.
Clear technology oversight also supports the broader work of monitoring connected systems and protecting care workflows. See Zevonix’s article on healthcare cybersecurity monitoring for related considerations.
Require human review of AI-generated content
AI output should be treated as a draft, not as verified clinical or operational information. Staff should check it against reliable source material, correct errors, and follow the clinic’s existing review and approval procedures before using or sharing it.
For patient-facing or clinical content, define who is responsible for checking accuracy, context, tone, and appropriateness for the intended use. Staff should not rely on a generated answer simply because it sounds confident. The policy should also state where AI-generated material may be used, and when it must not be entered into a record, sent to a patient, or used to guide care without the required review.
For help aligning technology decisions with operational needs, the clinic can also review Zevonix’s guidance on healthcare IT strategy planning.
Make accidental disclosure easy to report
Staff may make mistakes, especially when tools and rules are unclear. Tell them what to do if patient information is accidentally entered into an unapproved tool:
- Stop using the tool for that information and do not add more patient details.
- Report the event promptly through the clinic’s designated privacy or security channel.
- Share what tool was used, what information may have been entered, and when it happened, following internal reporting instructions.
- Let the responsible team assess the event and direct any further steps. Staff should not try to investigate or resolve it alone.
Make clear that prompt reporting is more important than deciding on one’s own whether the information was exposed. The clinic’s response team can determine what review and follow-up are appropriate.
Frequently asked questions
Can staff enter PHI if a vendor says its AI tool is HIPAA-compliant?
Not on that claim alone. The clinic should review the specific tool, settings, data handling, terms, and intended workflow, and confirm the required approvals before staff use it with PHI.
When does an AI vendor need a business associate agreement?
That depends on the service, the information involved, and the vendor’s role. The clinic’s privacy or compliance advisor should determine whether an agreement is needed and whether it applies to the specific workflow.
Is removing a patient’s name enough to make a prompt safe?
No. Other details, including unusual dates, locations, or narrative information, may still identify someone. Use only an organization-approved method for de-identification, and do not treat casual editing as sufficient.
What should staff do if they accidentally share patient information?
Stop entering information and report the event promptly through the clinic’s designated privacy or security channel. Follow the response team’s instructions rather than attempting to manage the incident independently.
Who should approve AI tools that may process patient information?
The clinic should assign a review process that brings in the appropriate privacy or compliance, security and IT, operational, and clinical perspectives for the intended use.
Conclusion
A practical generative AI policy makes safe choices easier: it identifies approved tools and uses, explains patient-data boundaries, offers alternatives, and gives staff a clear path for review and incident reporting. Start by mapping the tools your team uses and assigning owners to review them. If your clinic needs help considering its IT environment and workflows, contact Zevonix at (904) 658-0777.