AI Governance in Healthcare: Building an Ethical Framework for Your Practice

AI is already part of routine practice operations. It can appear in visit documentation, chart summaries, scheduling, prior authorization, patient messages, triage, and clinical decision support, sometimes through an electronic health record (EHR) update or an individual staff member before the practice has discussed how the tool should be used.

In the American Medical Association's (AMA) 2026 survey of 1,692 physicians, 81% reported using AI in a professional context, roughly double the share reported in 2023. Common uses included summaries of medical research, draft discharge instructions and care plans, documentation, chart summaries, draft responses to patient portal messages, translation, and assistive diagnosis. (2) That level of adoption makes governance a current operational issue.

For a practice, AI governance means inventorying the tools in use, deciding how much risk each use creates, assigning responsibility, reviewing vendors and data flows, setting human-review requirements, and monitoring the tool after launch. It sits alongside Health Insurance Portability and Accountability Act (HIPAA) compliance and information technology (IT) security. Those programs address privacy and security obligations. AI governance also asks whether the tool is appropriate for its intended use, how its output is reviewed, how problems are reported, and whether its performance changes over time.

This article gives practice owners, clinic directors, physicians, operations managers, and compliance leads a practice-level framework for clinical and administrative operations. It is not a legal opinion, a state-by-state AI-scribe consent guide, a Food and Drug Administration (FDA) submission guide, a cybersecurity architecture manual, developer-level algorithm guidance, or a vendor ranking.

Key takeaways:

• AI governance is the set of policies, owners, review steps, and monitoring processes a practice uses to select, approve, use, disclose, and reassess AI tools.
• Start with a complete inventory, including informal or unsanctioned use. Then classify each use case by risk so the review matches what the tool can affect.
• Administrative drafting, documentation support, patient-facing tools, predictive decision support, and AI-enabled device functions need different levels of oversight.
• HIPAA compliance, a business associate agreement, or FDA authorization addresses only part of the review. The practice still has to assess intended use, workflow fit, human oversight, and performance after launch.
• Small practices do not need hospital-scale infrastructure. They do need a named owner, defined permitted and prohibited uses, vendor review, privacy review, human oversight, an incident path, and periodic reassessment.
• NIST, WHO, ONC, the Joint Commission, the AMA, FDA, and the EU AI Act use different scopes and authorities. Their governance themes overlap enough that a practice can map one internal process to several external frameworks.

Why AI governance has become an operational priority

AI use is spreading across documentation, administration, patient communication, clinical support, research, and medical devices. In many practices, those uses have not arrived through one coordinated approval process.

The gap between adoption speed and oversight

A useful first step is to look beyond tools purchased specifically as "AI." AI may already be present in:

• Ambient scribes and visit documentation.
• Chart summaries and draft portal messages.
• Prior authorization and revenue-cycle workflows.
• Scheduling and call routing.
• Patient chatbots and lab-interpretation support.
• Predictive risk scores.
• Imaging, diagnostic-support, or device-linked software.

The World Health Organization (WHO) describes similar uses across diagnosis and clinical care, patient-guided applications, clerical and administrative work, medical and nursing education, and research and drug development. (16)

The inventory also has to account for shadow AI: staff using general-purpose tools for drafting, summarizing, rewriting, or problem-solving without a formal approval process. Without practice rules, that use continues by default, and the longer a practice postpones a governance decision, the more unmanaged AI it accumulates. Practices are more likely to learn about it when staff can report it without assuming the first response will be disciplinary.

The risks governance is meant to contain

The main risks are familiar to clinicians and practice leaders:

• Privacy: Protected health information (PHI) may be sent to a third party, retained, or used in ways the practice did not intend.
• Documentation: AI-generated notes, summaries, or messages may enter the record without adequate review or clear attribution.
• Bias: performance may differ across patient populations that were poorly represented in development or validation data.
• Automation bias: a fluent or confident output may receive more deference than its evidence warrants.
• Accountability: responsibility may be unclear when AI contributes to an incorrect action.
• Trust: patients and staff may react differently when AI use is hidden or poorly explained.
• Drift and updates: performance can change as models, vendors, workflows, or patient populations change.

WHO guidance specifically warns about false, inaccurate, biased, or incomplete outputs and over-reliance on AI. (16) Joint Commission and Coalition for Health AI (CHAI) guidance includes ongoing monitoring, risk and bias assessment, privacy, transparency, and training across the AI lifecycle. (6)

The clinician and practice stake

A practice needs answers to six questions: What AI tools are in use? What can each one affect? Who is responsible for it? What evidence supports the intended use? What safeguards are required? How will the practice detect a problem after deployment?

A practice that can answer them controls the selection, approval, use, disclosure, and audit of every AI tool it runs. Those questions apply to clinical and administrative tools alike. Documentation and liability also belong in the practice-level review. The level of review changes with the potential consequence of an error.

What AI governance is and the principles that anchor it

AI governance is the set of policies, roles, review steps, and monitoring processes that determine how AI tools are selected, approved, used, disclosed, audited, paused, and reassessed.

A working definition for a practice

The scope is wider than a list of purchased AI products. It includes:

• AI embedded in the EHR or other clinical software.
• AI scribes and patient-communication tools.
• Revenue-cycle and administrative automation.
• General-purpose AI used by staff.
• Internally developed AI.
• AI-enabled device software functions.

Governance connects to privacy, cybersecurity, compliance, procurement, clinical quality, and vendor management. It does not replace those functions. It adds a common process for deciding how a specific AI use is introduced and supervised. It is not a one-time approval, a purely legal sign-off, or a barrier to adopting useful tools.

Governance is broader than compliance

A HIPAA review is necessary when PHI is involved. It does not establish clinical validity, fairness, usability, workflow safety, or documentation accountability. The Privacy Rule governs uses and disclosures of PHI. (11)

FDA status is relevant when a software function falls within medical-device regulation. Authorization addresses the device and its intended use. The practice still has to train users, fit the tool into its workflow, and monitor its use locally. (14, 15)

ONC's HTI-1 requirements address transparency for predictive decision-support interventions in certified health IT. They give users information about how a covered intervention was developed and evaluated. The practice still decides whether the tool fits its own use and patient population. (8)

The core principles of ethical healthcare AI

A practice-level framework can be built around eight principles:

1. Patient safety: review intended use, foreseeable failure modes, clinical proximity, autonomy, and potential harm.
2. Privacy and data security: apply HIPAA requirements, access controls, retention rules, and vendor review whenever PHI is involved. (11, 12, 13)
3. Transparency: tell clinicians and, where appropriate, patients when AI is being used and what role it plays.
4. Human oversight: define where a qualified person reviews the output before action. AMA principles emphasize physician oversight for AI-influenced clinical decisions. (1)
5. Fairness: examine validation populations and subgroup performance where relevant.
6. Clinical validity: confirm that evidence supports the intended use and the population in which the tool will be used.
7. Accountability: assign a named owner.
8. Lifecycle monitoring: continue review after deployment, including model and vendor updates.

These themes also appear across NIST, WHO, ONC, and Joint Commission guidance. (6, 7, 8, 16)

Step 1: Create an AI use-case inventory

The inventory should capture every AI use the practice knows about, including tools that never went through formal procurement.

Capture formal and informal AI use

Start with sanctioned tools: EHR features, scribes, scheduling and billing automation, prior-authorization tools, patient-messaging systems, predictive decision support, imaging, and device-linked AI.

Then ask about informal use. Staff may use public AI tools for drafts, clinicians may use them to summarize or rewrite content, operations teams may generate policy or training material, and existing vendors may add AI features through product updates.

Shadow AI is easier to surface when staff understand that the purpose of the inventory is to establish safe use, training, and reporting. Once a use is known, the practice can decide whether it should be approved, restricted, or stopped.

Minimum inventory fields per tool

Each entry should include enough information to support risk classification and later review:

• Tool name, vendor, and version.
• Intended or approved use.
• Clinical, documentation, administrative, or patient-facing category.
• Data inputs, outputs, and output type.
• PHI involvement and handling.
• Users: clinicians, staff, patients, or a combination.
• EHR or other system integration.
• Vendor data use, retention, and deletion terms.
• BAA status where applicable.
• FDA status where applicable.
• ONC or certified-health-IT relationship where applicable.
• Accountable owner and current review process.
• Approval date, last review date, and incident or correction history.

Define approved and prohibited uses

Approved use should be specific to a workflow. Examples include internal drafting without PHI, an approved AI-scribe workflow with clinician review, portal-message drafting with human review before sending, or analytics use after privacy and security review.

Prohibited uses should be equally specific. Common examples include:

• PHI entered into an unapproved public AI tool.
• Clinical advice sent without required clinician review.
• AI-generated documentation signed without meaningful review.
• A vendor tool used outside its approved purpose.
• AI output copied into the record without required review, attribution, or correction.

The AMA states that AI-generated records or communications on a physician's behalf require physician consent and final review. (1)

Step 2: Classify AI tools by risk

Risk classification determines how much review a tool receives. Uses with greater potential harm need more review and monitoring.

Risk-tier criteria

Consider these factors together:

• PHI exposure.
• Patient-facing status.
• Clinical proximity.
• Degree of autonomy.
• Effect on diagnosis, triage, treatment, access, billing, or documentation.
• Whether a qualified human reviews the output before action.
• Certified-health-IT status.
• Possible medical-device status.
• Severity of a plausible error.

For patient-facing and predictive tools, monitoring should watch for false reassurance, over-triage, under-triage, inequitable performance across patient groups, and unsafe output. This tracks ONC's framing for predictive decision-support interventions. (8)

Reclassify a tool when its use changes. PHI, patient-facing output, billing claims, medical advice, or record documentation can move an administrative use into a higher tier.

Handling ambiguous or multi-function tools

For a multi-function product, review the highest-consequence function the practice plans to use. A scribe that also generates unreviewed triage advice creates a different risk than documentation support alone.

If medical-device status is unclear, confirm the intended use and seek appropriate regulatory or compliance review. FDA states that its public list of AI-enabled medical devices is not comprehensive. (15)

Step 3: Assign accountability and right-size governance

Every tool needs a named owner. A small practice can combine roles. The decisions still need to be assigned.

Name an owner for every tool

Depending on practice size and tool risk, the governance functions may include:

• Executive sponsor: organizational risk and resources.
• Clinical owner: clinical fit, review expectations, and escalation.
• Privacy and security lead: PHI, access, retention, safeguards, and incidents.
• Compliance lead: regulatory, consent, disclosure, payer, and policy issues.
• IT/data owner: integration, logs, downtime, and disablement.
• Quality or patient-safety representative: complaints, errors, and safety trends.
• End-user representative: workflow fit and user feedback.
• Vendor owner: contract, BAA, vendor evidence, and update notices.

One person may hold several of these functions in a small practice.

Separate decision rights

Document who can:

• Approve a pilot.
• Approve full deployment.
• Restrict a use.
• Pause or disable the tool.
• Require retraining.
• Request additional vendor evidence.
• Escalate an incident.
• Retire the tool.

Where staffing allows, the person monitoring safety or performance should not be the only person who approved and operates the tool.

Scale the structure to practice size

A health system may use a standing committee, registry, formal approval gates, and support from legal, risk, privacy, data science, and IT.

A solo or small group practice can use a simpler structure. At minimum, it still needs:

• A named owner.
• Approved and prohibited uses.
• Risk classification.
• Vendor and PHI review.
• Clinician sign-off rules.
• Staff training.
• Incident reporting.
• Periodic reassessment.

The Joint Commission and CHAI framework identifies governance structures as a core element without prescribing one committee model for every organization. (6)

Approval documentation

For each approved use, retain a short record of:

• The use case and risk tier.
• Evidence reviewed and reviewers.
• Approved users and prohibited uses.
• PHI and data-flow decision.
• Human-review requirement.
• Training requirement.
• Monitoring plan.
• Reassessment triggers and next review date.

This record can stay at framework level. A full standard operating procedure can be developed separately when needed.

Step 4: Vet vendors before deployment

Vendor review should cover data, clinical performance, bias, auditability, and the practice's ability to stop or change the tool.

Data and privacy questions

Ask:

• What data does the tool collect?
• Does it receive, store, transmit, or generate PHI?
• Is PHI used for training, fine-tuning, analytics, quality improvement, or product development?
• Where is data stored and processed?
• Who can access it?
• What retention and deletion terms apply?
• What happens to practice data after termination?
• Is a BAA required and available?
• Which subprocessors or third parties receive data?

Under HIPAA, a vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity may be a business associate and require a written agreement. (12)

Clinical and performance questions

For clinical or patient-facing uses, ask:

• What is the intended use?
• What output does the tool generate?
• What populations were used for training and validation?
• Were populations similar to the practice's patients included?
• What limitations and failure modes are known?
• Can clinicians understand enough about the output to review it appropriately?
• How does the vendor monitor drift or degradation?
• How are user corrections handled?

A favorable accuracy figure is not enough by itself. Performance has to be relevant to the intended use, population, and workflow.

Bias, fairness, and accessibility questions

Ask what subgroup performance data are available and which patient characteristics were assessed where relevant, including language, disability, age, race, ethnicity, sex, gender, and socioeconomic factors.

Also ask how bias concerns are reported and corrected, whether accessibility and language access are supported, and what target the model is actually predicting. A model can perform well on an overall metric while performing differently across subgroups.

Contracting, auditability, and control questions

Before signing, establish:

• What audit logs are available and how long they are retained.
• How errors are reported and escalated.
• Incident-response and breach-notification commitments.
• Whether the practice can disable, override, or roll back the tool.
• Ownership of generated outputs.
• Uptime, downtime, and support terms.
• Notice requirements for model or product updates.
• What evidence the vendor will provide after a material update.

The HIPAA Security Rule includes access-control and audit-control requirements for systems containing electronic PHI. (13)

Why vendor assurances are a starting point, not proof

Three common assurances answer narrower questions than a full governance review:

• "HIPAA-compliant": relevant to privacy and security obligations, not evidence of clinical validity or workflow safety.
• Vendor accuracy claims: useful evidence that still needs to be interpreted for the practice's patients, intended use, and workflow.
• FDA authorization: relevant to a regulated device function and its intended use. Local training, workflow review, monitoring, and incident planning still apply. (14, 15)

Step 5: Protect PHI and control data use

AI data flows should fit the privacy and security duties the practice already has.

Tie governance to existing privacy duties

Map each AI tool to the patient information it handles: identifiers, visit audio, notes, images, laboratory data, claims data, portal messages, or device data.

The HIPAA Privacy Rule limits uses and disclosures of PHI. Apply the minimum-necessary standard where it applies, while recognizing its exceptions, including certain treatment-related uses and disclosures. (10, 11)

A BAA is one required control when applicable. The practice still decides whether the proposed data flow is appropriate and whether access, retention, and vendor use are acceptable.

Public AI tools and unapproved PHI use

Staff should not enter PHI into public or otherwise unapproved AI tools unless the practice has completed the necessary privacy and security review and established appropriate contractual and technical safeguards.

If unapproved PHI use occurs, route it through the practice's existing process for containment, privacy/security review, compliance review, patient-safety review when clinical output was affected, and staff retraining or workflow correction.

Access control and auditability

For AI systems handling PHI, the practice should be able to determine:

• Who used the tool.
• Which patient or record was involved.
• What input was provided and what output was generated.
• Whether the output was changed.
• Who reviewed or signed the final action.
• Whether the model or tool version changed.

Retention and deletion requirements should be written into the contract. AI-related privacy incidents should connect to the practice's existing breach-response process. (9, 13)

Step 6: Require human oversight

Human review should match the kind of output and what can happen if it is wrong.

Match review level to output type

• Administrative drafts: staff review for accuracy and appropriateness.
• Documentation drafts: clinician review before signing.
• Portal-message drafts: human review appropriate to the clinical content and delegation policy.
• Clinical recommendations: licensed-clinician review before action.
• Predictive alerts: clinician interpretation in context, with override and escalation available.
• Device outputs: use according to intended use, labeling, local training, and clinical workflow.

The clinician remains responsible for the final signed documentation and clinical decision. AMA principles place AI-influenced clinical decisions under qualified human oversight. (1)

Anchor oversight to recognized expectations

For predictive decision support covered by ONC requirements, source attributes address issues such as validity, reliability, robustness, fairness, intelligibility, safety, security, privacy, risk mitigation, and governance. (8)

At the point of use, those attributes become practical questions: Is the output understandable enough to review? Does it fit the patient and setting? Is there a known failure mode that matters here? Can the clinician override it? Is escalation available?

High-volume workflows need explicit guardrails against automation bias, because review compresses under time pressure and a fluent output can draw more deference than its evidence supports.

Train staff to detect plausible errors

Training should use examples staff may actually encounter:

• An incorrect summary.
• A missing red flag.
• Incorrect attribution.
• An overconfident statement.
• A hallucinated guideline or medication detail.
• Missing patient context.
• Biased or inequitable output.

WHO guidance identifies false, inaccurate, biased, and incomplete outputs and automation bias among the risks practices need to address. (16)

Preserve professional accountability

AI-generated notes, summaries, and recommendations do not transfer responsibility for the final clinical record or decision to the tool.

Questions about liability allocation, consent, documentation duties, or contractual responsibility may vary by jurisdiction and should be routed to compliance or legal review.

Step 7: Monitor AI after go-live and manage the lifecycle

Approval is not the end of the review. Monitoring checks whether the tool still performs as expected and whether the conditions around it have changed.

What to monitor

Depending on the tool, monitor:

• Accuracy and correction patterns.
• Documentation amendments and clinician overrides.
• Bias or unequal-performance signals.
• User feedback and patient complaints.
• Workflow burden.
• Safety events or documentation errors associated with AI.
• Security incidents, downtime, and integration failures.
• Out-of-scope use.
• Vendor updates and model/version changes.

The monitoring plan should be defined before launch and assigned to a named owner. That approach is consistent with the lifecycle monitoring described in Joint Commission and CHAI guidance. (6)

Reassessment triggers

Re-review the tool when there is:

• A new vendor release.
• A change in intended use.
• A new patient-facing function.
• A new use of PHI.
• Expansion to another specialty, location, or patient population.
• A complaint cluster or safety event.
• A regulatory or contract change.
• A change in vendor data use.
• A performance-degradation or drift signal.

The routine review cadence can vary with the tool and practice. Document the next review date at approval.

Incident response for AI failures

A framework-level incident path can follow this sequence:

1. Contain the immediate problem and complete clinical review where needed.
2. Complete privacy/security and compliance review.
3. Notify the vendor and communicate with patients when required.
4. Correct affected documentation and complete root-cause review.
5. Retrain, restrict, disable, or retire the tool as appropriate.

Someone should have documented authority to pause or roll back the tool. Where PHI is involved, use the practice's existing breach-response process and applicable notification requirements. (9)

Step 8: Build transparency into patient and staff communication

Transparency includes both required disclosures and the information patients and staff need to understand how AI is being used.

Patient-facing transparency

AMA principles call for appropriate disclosure and documentation when AI directly affects patient care, access, medical decision-making, communications, or the medical record. (1)

A patient-facing explanation may need to cover:

• When AI is used.
• What the tool does and does not do.
• Who reviews its output.
• How patient data is protected.
• How patients can ask questions or opt out when appropriate.

Legal requirements for disclosure or consent vary. A practice should separate what is required in its jurisdiction from additional disclosure it chooses to provide for clarity and trust.

The AI scribe disclosure boundary

AI scribes deserve separate attention because consent and disclosure requirements can depend on state law, recording rules, organizational policy, payer requirements, and the vendor's workflow.

A practice-level framework can still assign responsibility for disclosure, review the vendor's recording and data flow, and identify who owns the consent language. State-specific language belongs in a policy developed with appropriate legal or compliance review.

Internal transparency for staff

Staff should know:

• Which tools are approved.
• Which uses are prohibited.
• When PHI may be used.
• Who reviews different outputs.
• How errors or incidents are reported.
• How patient questions are handled.
• How updates and workflow changes are communicated.

Training is part of ongoing governance, and it should be repeated when staff onboard, when a new tool launches, and when a material product or workflow change occurs.

Aligning your framework with external standards

A practice does not need to adopt every AI framework separately. It can map its own governance steps to the external standards that apply to its setting and use cases.

Using the frameworks without duplicating effort

The recurring controls are similar: define the use, assess risk, assign responsibility, protect data, keep humans involved, monitor performance, and communicate appropriately.

Choose a primary reference that fits the practice's size, setting, and jurisdiction. Then use the others when a specific tool brings in certified-health-IT, device, privacy, or cross-border requirements.

Pre-launch screen and practice-level governance checklist

Before launch, review recurring process failures and assumptions that can leave a tool under-governed.

Process failures to screen for

• Staff select tools independently without review.
• PHI enters public or unapproved AI.
• Vendor claims are accepted without workflow review.
• Bias or fairness review is skipped where relevant.
• Permitted and prohibited uses are undefined.
• AI-generated documentation is signed without meaningful review.
• Patient-facing output is sent without appropriate review or escalation rules.
• Human review is not documented.
• Monitoring stops after approval.
• Vendor or model updates do not trigger reassessment.
• Use continues despite unresolved safety, privacy, or equity concerns.

Misconceptions that create risk

Five common assumptions need narrower interpretation:

1. "HIPAA-compliant" means clinically safe. HIPAA addresses privacy and security obligations. It does not establish clinical performance or workflow fit.
2. FDA authorization completes the practice's review. Local intended-use, training, workflow, and monitoring decisions remain.
3. AI-generated notes can be signed like ordinary drafts. Clinical documentation still requires meaningful clinician review.
4. Vendor accuracy claims are enough. The practice still needs evidence relevant to its intended use and patient population.
5. Governance is only for large health systems. Small practices need fewer layers of administration. They still need the core decisions and documentation.

The practice-level AI governance checklist

• Inventory formal and informal AI use, including shadow AI.
• Assign a named accountable owner to each tool.
• Classify each use as low, moderate, high, or regulated/special review.
• Review PHI handling and execute a BAA where applicable.
• Review evidence, validation, limitations, and subgroup performance.
• Check FDA and ONC/certified-health-IT implications where applicable.
• Define permitted and prohibited uses.
• Require clinician review for clinical or diagnostic outputs.
• Train staff on data-entry boundaries, tool limitations, and plausible AI errors.
• Establish an incident-reporting and escalation pathway.
• Define patient-facing and staff-facing transparency processes where applicable.
• Set monitoring measures and a reassessment cadence.
• Reassess after material vendor, model, workflow, or regulatory changes.
• Document governance decisions and reviews.

Knowledge check: applying the framework to two simultaneous requests

A mid-sized multispecialty practice receives two requests at the same time. Nursing staff want to pilot an ambient AI scribe that records visits, generates draft notes, and temporarily stores audio on a vendor platform. The vendor cannot yet sign a BAA but says it expects to do so within 30 days. The marketing coordinator also wants to add a patient-facing chatbot to the public portal to answer basic clinical questions after hours.

Using the framework, identify the risk tier, accountable owners, vendor questions, PHI and disclosure issues, clinician-review requirements, and first-90-day monitoring plan for each tool.

For the scribe, documentation support places it in the moderate-risk tier. The clinical owner, privacy/security lead, and vendor owner should be identified before the pilot. Review should cover audio and PHI data flow, retention, deletion, vendor access, BAA status, documentation accuracy, clinician sign-off, and applicable disclosure or consent requirements. If the vendor is acting as a business associate, the required agreement and safeguards have to be in place before PHI is disclosed. (12) Early monitoring should include correction patterns, complaints, workflow burden, and vendor changes.

For the chatbot, patient-facing clinical output places it in the high-risk tier. Clinical, compliance/privacy, IT, and vendor responsibilities should be assigned. Review should cover clinical validation, the questions the chatbot may answer, escalation and fallback behavior, subgroup performance, auditability, disclosure, and handling of urgent symptoms. Clinical output should not bypass the practice's defined human-review and escalation rules. Early monitoring should include unsafe or out-of-scope answers, escalation failures, complaints, subgroup signals, and any over-triage or under-triage pattern.

The vendor review differs because the scribe's main risks are PHI handling and documentation accuracy, while the chatbot's main risks are patient-facing clinical output, escalation, and safety. Both need a defined owner and post-launch monitoring.

Frequently asked questions about AI governance in healthcare

What is AI governance in healthcare, and how is it different from the HIPAA and IT-security program a practice already runs?

AI governance is the set of policies, owners, review steps, and monitoring processes used to select, approve, use, disclose, and reassess AI tools. HIPAA and IT-security programs address privacy and security. AI governance also covers intended use, clinical validity, human oversight, workflow fit, and monitoring.

Why do medical practices need an AI policy before adopting AI tools?

A policy defines approved tools, prohibited uses, review requirements, and responsibility before individual staff make those decisions independently. It also gives the practice a basis for training and incident reporting.

How should a practice inventory its current AI use, including shadow AI, and tell administrative AI apart from clinical AI?

Review contracts, EHR release notes, vendor products, and staff use of general-purpose AI. Classify the use by what it handles and affects. Administrative drafting without PHI or clinical decision-making creates a different risk from a tool that touches the record, patient communication, diagnosis, triage, treatment, or another clinical action.

Is an AI tool that claims to be "HIPAA-compliant" automatically safe for clinical use?

No. The claim is relevant to privacy and security. It does not establish clinical validity, fairness, documentation accuracy, or workflow safety.

What questions should healthcare practices ask AI vendors before deployment?

Ask about data flow, PHI use, BAAs, retention and deletion, model training, intended use, validation populations, subgroup performance, known limitations, audit logs, updates, incident handling, and the ability to disable or roll back the tool.

Can AI replace clinical judgment under current standards?

The frameworks in this article retain qualified human oversight for clinical decisions. AMA principles state that AI-influenced clinical decisions require specified qualified human intervention points. (1)

When does an AI vendor need a business associate agreement?

A BAA may be required when a vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity. The practice should make that determination as part of vendor and privacy review before PHI is disclosed. (12)

Do patients need disclosure or consent when AI is used in their care?

Requirements vary by jurisdiction and use case. AI-scribe recording rules, for example, may depend on state law, organizational policy, and vendor workflow. AMA principles also support disclosure when AI affects patient care, access, or medical decision-making. (1)

When does an AI function cross from administrative software into a regulated medical device?

That depends on the function's intended use and applicable FDA rules. If a tool is intended for a medical purpose such as diagnosis or treatment, confirm its regulatory status rather than relying only on a vendor label or the FDA's public device list. (14, 15)

How do NIST, WHO, ONC, FDA, AMA, the Joint Commission, HIPAA, and the EU AI Act fit into practice-level governance?

They address different scopes and have different legal force. A practice can use one primary governance framework and map its internal process to the other standards that apply to a particular tool, setting, or jurisdiction.

Who should approve AI tools in a small or mid-sized practice with no formal committee?

One or two named people can cover several governance roles, provided the required decisions are made and documented. At minimum, the practice needs ownership, risk classification, vendor and PHI review, human-review rules, training, monitoring, and authority to pause a tool.

How often should a deployed AI tool be re-reviewed, and what triggers an off-cycle review?

Set the cadence when the tool is approved and document the next review date. Reassess sooner after material vendor or model updates, changes in intended use or PHI handling, new patient-facing functions, expansion to a new population or site, complaint clusters, safety events, regulatory changes, or performance-drift signals.

The bottom line

AI governance gives a practice a repeatable way to decide how an AI tool may be used and who is responsible for reviewing it. The process begins with an inventory and risk classification, then adds ownership, vendor and data review, human oversight, monitoring, transparency, and incident response.

The same decisions apply in a solo practice and a large health system, although the people and committees carrying them will differ. Start with an inventory of the AI already in use, assign an owner to each tool, and review the highest-risk use against the controls in this framework before adding another one. Unresolved clinical, privacy/security, compliance, IT, or operational questions should go to the appropriate reviewer.