Writing an AI Policy for a Rural Hospital: What It Needs, What the Rules Actually Say, and a Template to Start From

Rural hospital IT runs on borrowed work, and that is a strength. When an IT manager at a small hospital needs a new policy, a Group Policy baseline, or a downtime procedure, the first move is usually to ask the neighbors. Regional hospital networks, state association workgroups, and shared IT email lists exist for exactly this reason, and the answer is usually a colleague attaching whatever their hospital adopted. For most things, that system works remarkably well.

One of the most common asks right now is some version of "does anyone have an AI policy, or a risk assessment for the AI agent our EHR vendor is rolling out?" It is a reasonable question. It also deserves a better answer than a forwarded attachment.

Here is why this one is different. A borrowed password policy works because password requirements do not change much from one hospital to the next. An AI policy and risk assessment describe your tools, your contracts, your EHR configuration, and which features your vendor has switched on. The neighbor's document was approved against a different business associate agreement and a different feature set, possibly even a different release of the same product. What does carry over from one hospital to the next is the underlying problem. The AI arrived before the policy did. It came in through the EHR vendor, not through a procurement process. And the person being asked to govern it is an IT manager who also runs the help desk, the network, the phones, and probably the badge printer.

This article covers what an AI policy for a small hospital actually needs to contain, which federal rules genuinely apply (and which obligations get understated), how to run a risk assessment on a specific AI tool, and where IT fits in enforcing any of it. Alongside it, we have published a free sample AI use policy with a risk assessment worksheet written for Critical Access Hospitals, small community hospitals, and rural clinics. Adapt it, strip it down, or use it as a checklist against whatever you already have.

The AI Is Already in the Building

Ask a rural hospital how much AI it uses and the answer is usually "not much yet." That is rarely accurate. Picture a 14-bed Critical Access Hospital with an attached rural health clinic, two IT staff, and a hosted EHR. A quick look around commonly turns up providers piloting the EHR vendor's ambient documentation feature, a revenue cycle vendor running AI-assisted claim edits, a department head using a free AI note taker to record meetings, and front-line staff drafting patient letters in a personal chatbot account on their phones. Each of those is a different risk, and in many small hospitals none of them is covered by a written policy. Some of them may not be covered by a business associate agreement either.

The Kansas Health Institute team that presented a two-part AI policy webinar series for hospitals in June made the same point during Q&A. When an attendee asked whether a hospital with little AI use should write a policy anyway, the presenters recommended doing it now, and suggested an anonymous staff survey to surface what they called shadow use, because staff are often reluctant to admit what they are already doing. They also noted that AI increasingly shows up embedded inside platforms that never used to have it, so you may be running AI features you do not know about.

Your EHR's AI Agent Is Not One Tool

The EHR-embedded agent is where most rural hospitals will meet clinical AI first, and it deserves special attention because it changes shape on the vendor's schedule, not yours.

Oracle Health Clinical AI Agent is a useful example, since it is offered to community hospitals on Oracle Health platforms. It started as ambient note generation. In February 2026, Oracle added the ability to draft clinical orders from the conversation, including labs, imaging, prescriptions, and follow-up appointments. In March, note generation became available for inpatient and emergency department settings. In August, Oracle announced automated professional fee coding suggestions, dictation, and AI-assisted chart review. This is not a knock on Oracle. Other EHR vendors, including MEDITECH, are publicly moving in the same agentic direction. Whatever EHR you run, assume its AI features will keep expanding and plan your governance accordingly.

Here is the governance problem. A draft note waiting for physician review, a draft medication order waiting for a signature, and a suggested charge code heading toward a claim are three different risk profiles. A bad note puts wrong information in the chart. A bad order can hurt a patient. A bad code is a billing compliance problem. If your risk assessment was signed off when the tool only drafted notes, it does not describe the tool your providers are using today.

Two practical conclusions follow. First, assess and approve AI by capability and use case, not by product name. "Clinical AI Agent, ambient note drafting, outpatient clinic" is an approvable thing. "Clinical AI Agent" is not specific enough to mean anything. Second, your policy needs a trigger that forces re-review when a vendor ships a new AI capability, even if it arrives in a routine release package. Ask your EHR vendor, in writing, how new AI capabilities are turned on: per organization, per provider, or on by default. The answer determines whether your change control process will even see them coming.

What the Rules Actually Require

HIPAA does not mention artificial intelligence anywhere. It does not need to. An AI tool that touches electronic protected health information is part of your environment, and the existing Security Rule and Privacy Rule requirements apply to it like any other system.

Risk analysis and risk management. The risk analysis at 45 CFR 164.308(a)(1)(ii)(A) and risk management at 164.308(a)(1)(ii)(B) are both Required implementation specifications. An AI tool that processes ePHI belongs in your risk analysis the same way a new interface engine or cloud fax service would. The evaluation standard at 164.308(a)(8) also calls for re-evaluation in response to environmental or operational changes, and a new AI capability going live in your EHR is exactly that kind of change.

Business associate agreements. An AI vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate. Documenting that relationship in a written contract is a Required implementation specification under 164.308(b)(3), with contract content requirements at 164.314(a) and 164.504(e). It is sometimes described in AI governance discussions as a best practice. It is not optional. The contract must prohibit the vendor from using or disclosing PHI other than as the contract permits or as required by law (164.504(e)(2)(ii)(A)), which is where you pin down whether your patients' encounters can be used to train or improve the vendor's models. At termination, it must require the vendor to return or destroy PHI if feasible, and where that is not feasible, to extend the contract's protections to the retained information and limit its further use (164.504(e)(2)(ii)(J)). It must also require the vendor to report security incidents (164.314(a)(2)(i)(C)). A business associate must notify you of a breach without unreasonable delay and in no case later than 60 calendar days after discovery (164.410(b)). Sixty days is an outer limit, not a safe harbor, and you can negotiate something shorter.

For EHR-embedded AI, there is a wrinkle worth chasing down. Your existing EHR business associate agreement may well cover the AI feature, or the AI feature may run under separate terms or involve additional subcontractors that host the underlying model. Do not assume either way. Ask the vendor to identify which agreement governs the AI capability, where audio and transcripts are processed and stored, how long they are retained, and which subcontractors touch them.

Minimum necessary, sanctions, and training. The minimum necessary standard at 164.502(b) generally applies when staff put PHI into an AI tool for billing, operations, or administrative work, though it has exceptions, including disclosures to a provider for treatment. In practice, a staff member pasting a whole chart into a chatbot to draft a letter has a minimum necessary problem. A treating provider using an EHR-embedded tool covered by a BAA is a different analysis. The Security Rule sanction policy at 164.308(a)(1)(ii)(C) is Required, and the Privacy Rule requires sanctions (164.530(e)) and workforce training on privacy policies (164.530(b)). An AI policy that staff have never been trained on and that carries no consequences for violations will not survive contact with a real incident.

Audit logs. Information system activity review at 164.308(a)(1)(ii)(D) is Required, and audit controls at 164.312(b) is a standard with no separate implementation specifications, so the standard itself applies. Before you approve an AI tool, find out what activity logs it produces, whether you can get to them, and how long they are kept. If you cannot answer "who used this tool on which patient, and when," you will have a hard time investigating anything.

Documentation. To the extent your AI policy, risk assessments, and approval decisions document Security Rule compliance, they are Security Rule documentation, and 164.316(b)(2)(i) requires keeping them for six years from creation or the date last in effect, whichever is later.

A word on the Addressable designation, since it comes up in any policy discussion that touches training. The security awareness and training standard at 164.308(a)(5) is mandatory, while its implementation specifications, such as security reminders and log-in monitoring, are Addressable. Addressable does not mean optional. It means you implement the specification or document why an equivalent alternative is reasonable and appropriate, and implement that alternative. HHS proposed in January 2025 to eliminate the Addressable designation and make nearly all specifications Required. That rule is still proposed, not final, and the federal Unified Agenda now lists it as a long-term action with a July 2027 target for final action.

Nondiscrimination in clinical decision tools

Outside HIPAA, the rule most small hospitals miss is 45 CFR 92.210, part of the Section 1557 nondiscrimination regulations. It prohibits covered entities from discriminating on the basis of race, color, national origin, sex, age, or disability through the use of patient care decision support tools. It also creates an ongoing duty to make reasonable efforts to identify tools that use any of those characteristics as input variables, and to make reasonable efforts to mitigate the risk of discrimination from those tools. Hospitals that participate in Medicare or Medicaid receive federal financial assistance and are covered entities, and the identification and mitigation duties took effect May 1, 2025. The rule is focused on clinical decision-making, and legal analysis of the final rule's preamble reads it as not reaching purely administrative, billing, or scheduling tools. In practice, that means your AI inventory needs a column for whether each clinical tool uses those input variables and what you did about it.

State law is moving faster than any template

State AI laws vary widely, and they are changing quickly enough that anything we list here has a shelf life. A few examples show the range. In Texas, SB 1188 (effective September 1, 2025) requires practitioners using AI for diagnostic purposes to review AI-generated records and disclose AI use to patients, and TRAIGA (effective January 1, 2026) requires providers to disclose AI use in treatment no later than the date of service. California has required disclaimers on certain generative AI patient communications since January 2025. Colorado shows how fast the ground moves: its 2024 AI Act was delayed once, then repealed and replaced in May 2026 by a narrower disclosure-focused law that takes effect January 1, 2027. At least one freely circulating AI policy template still lists the original Colorado law with a 2026 effective date.

At the federal level, Executive Order 14365, signed in December 2025, directs a Justice Department task force to challenge state AI laws the administration considers burdensome. An executive order does not by itself preempt state law, and Congress has not passed a federal AI statute that does. Until a statute or court decision says otherwise, state laws in effect are the laws you follow.

The takeaway for policy design is simple. Do not hard-code state requirements into the body of your policy. Put regulatory references in an appendix that the policy owner can update without sending the whole document back through board approval, and check with your state hospital association or counsel on what applies where you operate.

Voluntary frameworks worth knowing

The Joint Commission and the Coalition for Health AI (CHAI) released joint guidance on responsible AI use in September 2025, and in June 2026 the Joint Commission launched a voluntary Responsible Use of AI in Healthcare certification that does not require Joint Commission accreditation to apply. You do not need to pursue certification to borrow its structure. One more federal development affects what you can expect from vendors: the federal health IT certification program's "model card" transparency requirements for predictive decision support, which require certified EHR developers to disclose information about how those tools were built and validated, are proposed for removal under the HTI-5 proposed rule. If you want that information from a vendor, put the requirement in your contract rather than counting on certification rules to deliver it.

What Goes in the Policy

A small hospital does not need 40 pages to get started. The Kansas Health Institute's AI Use Policy Template for Hospitals, developed with support from Healthworks, the nonprofit arm of the Kansas Hospital Association, is thorough, free, and includes rural-specific considerations throughout. It has 19 core sections, five add-on modules for specific AI types, six appendices, and a separate section-by-section companion guide. If you have the governance capacity to work through it, it is an excellent resource, and nothing in it is Kansas-specific beyond one line in a regulatory checklist you would replace with your own state.

If your governance capacity is you, a CEO, a DON, and a compliance officer who also runs HR, start leaner and grow it. At minimum, a working AI policy needs to answer these questions:

1. What counts as AI here? Include AI features embedded in the EHR, Microsoft 365, and other existing platforms, not just standalone products.
2. Who owns it? Name roles for policy ownership, clinical oversight, technical and security review, and privacy. In a small hospital one person may hold three of those roles. That is fine if it is written down and each role has a backup.
3. What is approved? Keep an AI use register as an appendix listing each approved tool and use case, its risk tier, its BAA status, and its owner. If it is not on the register, it is not approved.
4. Where is the PHI line? No PHI goes into any AI tool unless it has an executed BAA and appears on the register. A personal paid subscription is still a personal account, and it is not covered by the hospital's agreements.
5. How is risk tiered? KHI's three-tier model works well for small hospitals: high risk for anything touching clinical decisions, PHI, or patient safety; moderate risk for operational uses that shape decisions without directly affecting care; and low risk for work with no sensitive data. A tool's controls must match or exceed the tier of the task, and a use case moves up a tier when its data, scope, or level of automation increases.
6. Who reviews AI output? AI output is a draft. The person who signs, sends, or acts on it owns it.
7. What do patients hear? Set expectations for disclosure of ambient documentation and other patient-facing AI, how a patient declines, and how that choice is documented. Then check your state's specific requirements.
8. What must vendors agree to? A BAA before any PHI flows, no use of your data for model training without written permission, disclosure of subcontractors, a defined incident notification timeline, access to audit logs, and return or destruction of data at the end of the relationship.
9. What forces a re-review? A new tool, a new capability in an existing tool, a new data type, a significant incident, or a change in law.
10. How do people report problems, and how are they trained? Staff need a no-blame way to report pasting PHI into the wrong tool, and a documented acknowledgment that they have read the policy.

Our sample policy is built around those ten questions, with the risk tiers, a register template, a vendor questionnaire, a patient disclosure script, and a staff acknowledgment form included as appendices.

Running the Risk Assessment on a Specific Tool

That brings us back to the request making the rounds: a risk assessment for a specific EHR AI agent. The good news is that you already know how to do most of this. An AI risk assessment is not a new category of paperwork. It is an addendum to your HIPAA risk analysis, plus a clinical and operational review that your risk analysis was never designed to cover.

Work through each capability separately. For an EHR ambient agent at a small hospital, that assessment should document the following.

What each capability does and what tier it falls in. Note drafting, order drafting, and coding suggestions each get their own line, and each gets its own approval or non-approval. You can approve ambient notes in the clinic while holding order drafting until the medical staff has reviewed it.

Where the data goes. Where is audio captured: a provider's phone app, a workstation microphone, a room device? Where is it processed and stored, and by whom? How long are audio and transcripts retained? Is any of it used to improve the vendor's models? Which agreement covers it?

Who can turn it on. Is it enabled per provider or organization-wide? Does access go through your identity provider with multifactor authentication? Can IT see who has it enabled?

What gets logged. Can you produce a record of who used the tool, for which patient, and when? Can you get that record without opening a vendor ticket?

Where the human review happens. Does the workflow require a signature before a draft note enters the legal record or a draft order goes anywhere? What happens to unsigned drafts?

What happens when it fails. Rural broadband goes down. Vendor clouds have outages. What is the documentation fallback, and does your downtime procedure mention it?

How patients are told, and how they decline. Who says what, when, and where in the chart the declination goes.

Nondiscrimination. For clinical decision support capabilities, does the tool use any of the input variables covered by 92.210, and what did the vendor provide about testing?

Then rate the likelihood and impact of each identified risk, document the mitigations, name an owner and a review date, and get sign-off from clinical leadership, IT, and compliance. Our template includes a worksheet laid out this way. One honest note: a vendor's own security documentation, however polished, is an input to your risk assessment. It is not your risk assessment.

IT's Part: A Policy Nobody Enforces Is Just a Document

The policy is a leadership document, but most of what makes it real lands on IT.

Find what is already in use. Your DNS or web filter logs will show traffic to AI services. Many next-generation firewalls now categorize generative AI applications. If you license Microsoft Defender for Cloud Apps alongside Defender for Endpoint, its cloud app catalog has a Generative AI category you can use to discover, sanction, and block apps. Configuration Manager or Intune software inventory will show desktop AI apps and, depending on how you have inventory configured, browser extensions. Pair the technical inventory with the anonymous staff survey, because phones on guest Wi-Fi or cellular never show up in your logs.

Offer an approved option before you block. If staff have a legitimate need and no sanctioned tool, blocking consumer AI on workstations just moves the activity to personal phones, where you see nothing. Stand up at least one approved tool for low-risk drafting work, then block unapproved AI services on managed devices, ideally with a warn-and-redirect message first.

Manage the devices ambient tools run on. If providers run an ambient documentation app on a phone, that phone needs to be managed, or the app needs app-level protection policies, and your lost-device procedure needs to cover it.

Keep the logs. Confirm where AI tool audit logs live, how long they are retained, and that someone actually reviews them on a schedule, consistent with your information system activity review procedures.

Where to Start This Month

If you do nothing else in the next 30 days, do five things. Send an anonymous survey asking staff which AI tools they use for work. Pull a week of DNS or firewall logs for AI services. Send your EHR vendor written questions about its AI features, including which agreement covers them, where the data goes, and how new capabilities are enabled. Adopt an interim one-page rule that no PHI goes into any AI tool without a BAA and IT approval. Put AI governance on the agenda of whichever existing committee is closest to the job, whether that is compliance, medical staff, or leadership, instead of creating a new committee your hospital does not have the people to staff.

So when the next request for an AI policy comes across your regional list, share what you have, and share it with a caveat. A neighbor's policy is a starting point, not a finished document, and a vendor's documentation is not a substitute for your own assessment. Nobody has to start from a blank page, though. Between KHI's comprehensive template and the lean starting point we have published, there are two good places to begin.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources

1. eCFR, 45 CFR 164.308, Administrative safeguards. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
2. eCFR, 45 CFR 164.312, Technical safeguards. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
3. eCFR, 45 CFR 164.314, Organizational requirements. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.314
4. eCFR, 45 CFR 164.316, Policies and procedures and documentation requirements. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.316
5. eCFR, 45 CFR 164.410, Notification by a business associate. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D/section-164.410
6. eCFR, 45 CFR 164.502, Uses and disclosures of protected health information: General rules. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502
7. eCFR, 45 CFR 164.504, Uses and disclosures: Organizational requirements. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504
8. eCFR, 45 CFR 164.530, Administrative requirements. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.530
9. eCFR, 45 CFR 92.210, Nondiscrimination in the use of patient care decision support tools. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-A/part-92/subpart-C/section-92.210
10. Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule), January 6, 2025. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information
11. Reginfo.gov, Unified Agenda entry for RIN 0945-AA22, HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information. https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=0945-AA22
12. Health Affairs Forefront, "Section 1557 Rule Mandates Identification And Mitigation Of Discriminatory Clinical Algorithms." https://www.healthaffairs.org/content/forefront/section-1557-rule-mandates-identification-and-mitigation-discriminatory-clinical
13. Crowell & Moring, "HHS Applies Discrimination Prohibitions to Use of Automated and Non-Automated Patient Care Decision Support Tools," May 2024. https://www.crowell.com/en/insights/client-alerts/hhs-applies-discrimination-prohibitions-to-use-of-automated-and-non-automated-patient-care-decision-support-tools
14. Oracle, "Oracle Health Adds Order Creation Capabilities to Oracle Health Clinical AI Agent," February 2, 2026. https://www.oracle.com/news/announcement/oracle-health-adds-order-creation-capabilities-to-clinical-ai-agent-2026-02-02/
15. Oracle, "Oracle Health Clinical AI Agent Helps Emergency and Inpatient Doctors Spend More Time on Patient Care," March 11, 2026. https://www.oracle.com/news/announcement/health-clinical-ai-agent-helps-emergency-and-inpatient-doctors-2026-03-11/
16. PR Newswire, "Oracle Health Expands Clinical AI Agent with Automated Coding, Dictation, and Chart Review," August 19, 2026. https://www.prnewswire.com/news-releases/oracle-health-expands-clinical-ai-agent-with-automated-coding-dictation-and-chart-review-302854383.html
17. Business Wire, "MEDITECH Advances Toward Agentic User Experience and Previews New AI Initiatives," September 2025. https://www.businesswire.com/news/home/20250916738781/en/MEDITECH-Advances-Toward-Agentic-User-Experience-and-Previews-New-AI-Initiatives
18. Texas Medical Liability Trust, "New AI disclosure requirements for physicians passed into Texas law." https://www.tmlt.org/resource/new-ai-disclosure-requirements-for-physicians-passed-into-texas-law
19. Health Law Rx, "New Year, New AI Rules: Healthcare AI Laws Now in Effect," January 2026. https://www.healthlawrx.com/2026/01/new-year-new-ai-rules-healthcare-ai-laws-now-in-effect/
20. Hunton Andrews Kurth, "Colorado AI Act Amended and Effective Date Delayed," May 2026. https://www.hunton.com/privacy-and-cybersecurity-law-blog/colorado-ai-act-amended-and-effective-date-delayed
21. White & Case, "State AI laws under federal scrutiny: Key takeaways from the executive order establishing federal AI policy framework." https://www.whitecase.com/insight-alert/state-ai-laws-under-federal-scrutiny-key-takeaways-executive-order-establishing
22. Joint Commission, "Joint Commission and Coalition for Health AI (CHAI) Release Initial Guidance," September 17, 2025. https://www.jointcommission.org/en-us/knowledge-library/news/2025-09-jc-and-chai-release-initial-guidance-to-support-responsible-ai-adoption
23. Joint Commission, Responsible Use of AI in Healthcare certification announcement, June 1, 2026. https://www.jointcommission.org/en-us/knowledge-library/news/2026-05-responsible-use-of-ai-in-healthcare-certification
24. ASTP/ONC, HTI-5 Proposed Rule Fact Sheet. https://www.healthit.gov/topic/laws-regulation-and-policy/hti-5-proposed-rule-fact-sheet
25. Kansas Health Institute, AI Use Policy Template for Hospitals and Companion Guide, August 2026. https://www.khi.org/articles/ai-use-policy-template-for-hospitals-and-companion-guide/
26. Kansas Health Institute and Healthworks, "Where AI Fits in Healthcare" (June 12, 2026) and "Building Your AI Policy Step by Step" (June 30, 2026) webinar series for hospitals.
27. Microsoft Learn, "Discover, monitor, and manage generative AI apps." https://learn.microsoft.com/en-us/microsoft-365/copilot/manage-generative-ai-apps