A surveyor sits across from your chief medical officer and asks a single question: "Show me your policy for artificial intelligence." Someone slides a binder across the table. It contains a radiology AI validation memo from two years ago, a one-page ambient-scribe consent script from the ambulatory clinics, an IT security standard that mentions machine learning in passing, and an email thread in which the sepsis-model committee agreed to keep monitoring drift. The surveyor turns the pages slowly and asks the question that decides the survey: "This is four documents from four departments. Where is the policy that governs all of it, the one that tells me who approved this sepsis model, who can turn it off, and what happens when it is wrong?" There is a silence in the room, and in that silence is the entire subject of this lesson. A health system does not become safe with AI by accumulating a patchwork of local practices. It becomes safe with one coherent enterprise policy that holds across documentation, decision support, imaging, and operations, and that a surveyor, a plaintiff, or a board can read as a single, governing whole.

Why a Patchwork Fails and a Policy Holds

The most common state of AI governance in a health system in 2026 is not the absence of rules. It is the presence of too many, none of them connected. The ambulatory group adopted an ambient scribe and wrote a consent script. Radiology validated an imaging triage tool and kept a spreadsheet. A data-science team stood up a readmission model with its own review. Revenue-cycle bought a prior-authorization assistant and never told anyone clinical. Each of these is defensible in isolation, and together they are a failure, because there is no single place that answers the questions that matter across all of them: who decides an AI tool may be used on our patients, what uses are forbidden regardless of who wants them, what happens to protected health information, when a patient must be told, how a deployed tool is watched, and who is accountable when it harms someone. A patchwork answers none of these consistently. It answers each of them differently, in different departments, with different rigor, and the gaps between the pieces are exactly where a patient falls.

An enterprise AI policy is the opposite structural choice. It is one governing document, owned at the executive and board level, that applies to every AI tool touching a patient or the record regardless of which department bought it, what it is called, or whether the vendor insists it is "not really AI." It does not replace the local operating procedures that a radiology team or an ambulatory clinic needs; it sits above them and sets the non-negotiable floor they must all clear. The test of such a policy is simple and demanding: a new AI tool arrives at any door of the organization, and the same intake, the same approval, the same PHI rules, the same validation and monitoring expectations, and the same accountability apply to it, whether it is a scribe, a risk score, an imaging algorithm, or an operational bot. One policy, one floor, one accountable owner. Everything else in this lesson is the anatomy of that document.

A patchwork of local AI practices is not a policy. It is a map of the places a patient can fall between departments. The enterprise policy is the floor that runs under all of them.

Building on the Seven Foundational Elements

You do not have to invent the skeleton of this policy from nothing, and you should not, because a board and a surveyor will both ask what recognized framework you built on. The first accrediting-body guidance in the United States, the Responsible Use of AI in Healthcare (RUAIH) guidance issued jointly by the Joint Commission and the Coalition for Health AI (CHAI) on September 17, 2025, gives you the spine. It sets out seven foundational elements, and a strong enterprise policy is organized so that each element has an owner, a process, and evidence. The seven are: an AI policy and governance structure; patient safety and quality as the governing priority; a designated governance body with real authority; risk and bias evaluation both before and after deployment; vendor disclosure of known risks and limitations; validation on data representative of your own population; and workforce training. The guidance is voluntary today, but treat it as the shape of your next survey, because accrediting bodies rarely publish an element they never intend to inspect.

Because a surveyor and a board will both ask how your policy maps to the recognized frameworks, it helps to keep the crosswalk explicit. The table below maps the sections of a strong enterprise policy to the RUAIH element they satisfy and to the HTI-1 mechanism they lean on, so the mapping is a document you can hand over rather than a claim you have to reconstruct under pressure.

The value of anchoring on these seven is not that they are novel. It is that they are external and recognized, which changes the conversation in the boardroom. When a service line pushes to skip validation because the vendor's national numbers look excellent, the answer is no longer one leader's caution against another leader's enthusiasm. It is "our policy requires representative validation, consistent with the Joint Commission and CHAI framework we adopted, and that requirement does not bend for a good demo." An enterprise policy built on a named framework converts individual judgment into institutional standard, which is precisely what survives a leadership change, a vendor's charm, and a plaintiff's cross-examination. Name the framework in the policy, map each of your sections to its elements, and keep the mapping current as HTI-2 and future CHAI playbooks evolve.

Intake, Approval, and the Permitted-and-Prohibited List

The load-bearing operational section of the policy is the intake and approval process, because it is the gate that everything else depends on. The policy must state, in plain terms, that no AI tool may be used on a patient or the record until it has passed a defined intake and been approved by the designated governance body. Intake is not a formality; it is a structured submission that forces the requesting service line to answer the questions the organization needs answered before, not after, deployment: what the tool does, what population it was trained and validated on, what its intended use and known limitations are, what data it touches and where that data goes, what the vendor discloses about risk and bias, what state disclosure obligations it triggers, and who will own it operationally once it is live. A tool that cannot supply these answers does not get approved; it gets sent back, and that friction is the point.

Equally important, and often missing, is an explicit list of permitted and prohibited uses. The permitted list describes the categories of AI use the organization has decided it can govern safely: ambient documentation with attestation, imaging triage with radiologist sign-off, decision-support scores presented as one input among many, operational drafting with human review. The prohibited list is where a mature policy shows its spine. It names, in advance, the uses the organization will not allow no matter who asks: autonomous clinical decisions with no human sign-off, AI-generated patient clinical communications sent without a licensed reviewer, feeding protected health information into any consumer tool that lacks a business associate agreement, and any deployment whose intended use the vendor cannot state. Writing the prohibited list before a specific request arrives is what keeps the answer from bending under pressure in the moment. The list is not a statement of distrust in AI; it is the boundary that makes the permitted uses defensible. The table makes the contrast concrete: each permitted use carries the human control that makes it governable, and each prohibited use names the specific control it removes.

PHI Rules and the Shadow-IT Problem

Two rules in this section do more to prevent breaches than any other. The first is an absolute PHI rule: protected health information may enter an AI tool only when a business associate agreement (BAA) is in place and the tool has passed intake, and never otherwise. This is the rule that stops a clinician from pasting a patient's history into a consumer chatbot to draft a letter, and it must be stated so plainly that no one can claim confusion. The minimum-necessary principle applies here as everywhere: even an approved tool receives only the data it needs. The second rule addresses shadow IT, the single most common way an enterprise policy is defeated in practice. Shadow IT is any AI tool adopted by an individual or a team without going through intake, and it is dangerous precisely because it is invisible: no BAA, no validation, no monitoring, no one accountable, and no one who even knows it is running until something goes wrong. The policy must make clear that using an unapproved AI tool on patients or the record is a policy violation regardless of how helpful it is, and it must pair that prohibition with an intake path fast enough that people are not tempted to route around it. A prohibition without a reasonable approved alternative simply drives the behavior underground, which is worse than not having the rule at all.

Disclosure, Validation, and Monitoring

The policy must set consistent standards for three things that individual departments tend to handle unevenly. Disclosure and consent come first. The policy establishes when patients must be told AI is involved and how consent is handled, reconciling the organization's practice with the live patchwork of state law: California's AB 3030 requiring a disclaimer and human-contact instructions on generative-AI patient clinical communications not reviewed by a licensed provider, Texas TRAIGA (HB 149) requiring clear disclosure of AI use in diagnosis or treatment as of January 1, 2026, and the evolving Colorado regime. Rather than let each service line interpret these separately, the policy sets one enterprise standard that meets the strictest obligation the organization is subject to, so that disclosure does not depend on which clinic a patient happens to visit. The table summarizes the live patchwork the policy has to reconcile; treat every date and penalty as a fact to verify against current law, since this area is evolving and a policy built on a stale citation is a liability of its own.

The policy's job is not to reproduce these statutes but to translate them into one operational rule a clinician can follow without reading the law: when an AI tool generates a communication a patient will read, a licensed reviewer signs off or the required disclaimer and human-contact path appears, and AI use in diagnosis or treatment is disclosed clearly. Setting the enterprise floor to the strictest obligation means a multistate system does not have to run a different disclosure workflow in every jurisdiction, and a clinician who follows the enterprise rule is compliant everywhere the system operates.

Validation and monitoring are the second and third standards, and they are where a policy either has teeth or does not. The validation requirement states that before any tool goes live, it is validated on data representative of the organization's own patient population, not accepted on the vendor's national performance alone, because a model that performs well in aggregate can underperform badly for the specific patients a given hospital serves. Disparate performance across demographic groups must be tested before deployment, not discovered after. The monitoring requirement states that validation is not a one-time gate but an ongoing obligation: every deployed tool has defined performance metrics, a monitoring cadence, an owner who watches for model drift and disparate impact, and a threshold at which the tool is paused or pulled. A model can pass validation on the day it goes live and degrade silently as the patient population, the documentation habits, or the upstream data change. The policy that only validates at launch is governing the tool it had, not the tool it has. To have teeth, the monitoring requirement should name, for each deployed tool, the specific metrics watched, the cadence of review, the accountable owner, and the threshold at which the tool is automatically paused or pulled pending review. A threshold stated in advance is what converts monitoring from a dashboard nobody acts on into a trigger that fires: if the audited note-error rate crosses the line, or subgroup performance diverges past a defined gap, the tool pauses and the governance body reviews, rather than the organization debating in the moment whether the drift is bad enough to act on. Every one of these numbers is a value to set and verify against your own population rather than to import from a vendor's benchmark, because the threshold that matters is the one that protects your patients, not the one that flatters the tool.

Incident Response and Who Owns What

The final two sections turn the policy from a set of expectations into an operational system. Incident response defines what happens when an AI tool is implicated in a patient-safety event, a near miss, a privacy breach, or a performance failure. The policy names the reporting path, the analysis process, the authority to pause or disable a tool immediately, and the loop back into the governance body so that the same failure does not recur across other tools. An AI incident is not only a clinical event; it may also be a device malfunction reportable to the FDA, a privacy incident, and a signal that a whole class of tools needs re-examination. Treating an AI safety event as a one-off clinical footnote, rather than a governed incident with an owner and a paper trail, is how a single failure becomes a pattern no one caught. The practical test of an incident section is whether it answers four questions before an event occurs: who is notified, who has the authority to pause or disable the tool immediately, what parallel reporting obligations the event may trigger, and how the finding loops back to prevent recurrence across the class of tools. A confabulated exam finding in one ambient note, for instance, is not only a clinical documentation problem; it may be a device malfunction that is reportable to the FDA, a signal that every deployment of that tool needs a note audit, and evidence the governance body uses to tighten the attestation workflow. A policy that names the pause authority in advance is worth more than one that discovers, mid-incident, that no one is sure who can turn the tool off, because the minutes spent locating that authority are the minutes the tool keeps producing the same error into live charts.

Roles and accountability close the loop, because a policy with no named owners is a wish. The policy assigns, by role, who chairs the governance body, who owns intake, who signs off on validation, who monitors deployed tools, who handles incidents, and, crucially, where clinical accountability sits. That last point is the cardinal rule of the whole program written into governance language: AI assists, the clinician decides, and no policy structure, no governance committee, and no vendor relationship transfers accountability for a clinical decision away from the licensed human who made it. "The model recommended it" is not a defense to a board, a plaintiff, a family, or a surveyor, and the policy should say so in as many words. Governance exists to keep the human meaningfully in the loop and to prove, through the record, that the human was there.

A Worked Example: One Tool Through the Policy

Watch a single tool move through a real policy, because the anatomy only makes sense in motion. A hospitalist group wants an ambient documentation tool that also drafts discharge instructions for patients. Under a patchwork, the group would pilot it, like it, and roll it out, with consent handled by whichever nurse remembered and PHI flowing wherever the app sent it. Under the enterprise policy, the request enters intake. The submission must state the training population, the vendor's disclosed limitations, the data flows, and the state-disclosure implications of AI-drafted patient instructions. Intake surfaces two problems the group had not considered: the discharge-instruction feature generates patient clinical communications, which triggers AB 3030 disclosure obligations in California and clear-disclosure obligations under TRAIGA in Texas, and the vendor's default configuration routed transcripts through a subprocessor not covered by the existing BAA.

The governance body does not reject the tool; it conditions approval. The ambient-note function is permitted with attestation. The patient-instruction drafting is permitted only with a licensed-reviewer step and the required disclaimer, satisfying the disclosure standard. The BAA is amended to cover the subprocessor before any PHI flows, satisfying the PHI rule. Validation is required on the system's own patient population before go-live, and a monitoring plan with a named owner and a drift threshold is attached. An incident path is specified: if the tool confabulates an exam finding or drops a critical instruction, here is who is told and who can pause it. The tool goes live in a controlled way, and every one of those conditions is documented. Now return to the surveyor from the opening scene and ask the question again: who approved this tool, who can turn it off, and what happens when it is wrong? Under the patchwork, there was a silence. Under the policy, there is a single document that answers all three, plus an intake record, an approval with conditions, a validation report, a monitoring log, and a named accountable owner. That difference is not paperwork. It is the difference between an organization that can govern AI and one that is merely using it and hoping.

Notice too what the policy did not do. It did not slow the group down out of caution for its own sake, and it did not reject a genuinely useful tool. It caught two real problems the enthusiastic buyers had missed, a live legal exposure and an active privacy gap, and it converted them into conditions the group could actually meet. This is the quiet argument for enterprise governance that no demo ever makes: the same structure that a service line experiences as friction is the structure that keeps that service line out of a survey finding, a breach notification, and a courtroom. A good policy is not the enemy of adoption. It is what lets an organization adopt aggressively without discovering, one incident at a time, the questions it should have asked before go-live. The service lines that resist governance most loudly are usually the ones with the most to lose from its absence, because they are moving fastest, and speed without a floor is exactly how a health system turns its best AI enthusiasm into its worst AI headline.

Key Takeaways

• Safety at enterprise scale does not come from many local AI practices but from one coherent policy that holds across documentation, decision support, imaging, and operations, with a single floor every department must clear.
• A patchwork of department-level rules answers the questions that matter (who approved this, who can turn it off, what happens when it is wrong) differently everywhere, and the gaps between the pieces are where patients fall.
• Build the policy on a named external framework: the Joint Commission and CHAI RUAIH guidance (September 17, 2025) and its seven foundational elements, so requirements survive leadership changes, vendor charm, and cross-examination.
• The intake-and-approval gate is load-bearing: no AI tool touches a patient or the record until it has passed a structured intake and been approved by the designated governance body, and a tool that cannot state its intended use, population, and limits does not get approved.
• Write the permitted and prohibited lists before a specific request arrives, so the prohibited uses (autonomous clinical decisions, unreviewed AI patient communications, PHI into tools without a BAA) do not bend under pressure in the moment.
• Set one enterprise standard for PHI (BAA required, minimum necessary), for shadow IT (unapproved tools are a violation, paired with an intake path fast enough that no one routes around it), and for disclosure (meet the strictest state obligation you are subject to).
• Validation must be on your own representative population and test for disparate performance before go-live, and monitoring must be ongoing, with defined metrics, an owner, a drift threshold, and the authority to pause or pull a tool.
• Assign roles and accountability explicitly, and write the cardinal rule into governance language: AI assists, the clinician decides, and no committee, policy, or vendor relationship transfers clinical accountability away from the licensed human.