Hospital AI Governance Policy Template (Joint Commission + CHAI Aligned)

Disclosure: Surgy Health builds AI software for hospitals. This template is vendor-neutral and should govern any AI you use, including ours. It is a starting point, not legal advice; adapt it with your legal, compliance and clinical leaders.

Download the template

Get the policy as an editable Word document or a PDF, with the register, intake checklist, disclosure scripts and incident form as appendices.

Download in Word (.docx) · Download as PDF

What's new in 2026

The template is built on the Guidance on the Responsible Use of AI in Healthcare released by the Joint Commission and the Coalition for Health AI (CHAI) on 17 September 2025, which set out seven elements: governance, privacy and transparency, data security, quality monitoring, safety-event reporting, risk and bias assessment, and training. Two things followed in 2026:

• CHAI governance playbooks (late May 2026) set baseline controls covering organisational AI policy and structure, resources, AI lifecycle management, risk and impact assessment, data management and use, third-party management, and education, training and feedback.
• Joint Commission Responsible Use of AI in Healthcare (RUAIH) Certification (launched the week of 1 June 2026) is a voluntary certification for US hospitals and health systems. It certifies the organisation's governance, not individual AI products, across five areas: governance; data management; risk and bias reduction; monitoring and validation of safety and performance; and transparency, education and training.

The certification currently targets US organisations, but its five areas are a useful benchmark for any hospital. The mapping table later on this page shows which policy section covers each.

Risk tiers: match the scrutiny to the risk

The policy template

Copy the text below into your policy system. Replace everything in [square brackets].

Policy control

1. Purpose

This policy makes sure [Hospital name] uses artificial intelligence safely, fairly, lawfully and transparently, so that AI improves care and operations without putting patients, staff or data at risk.

2. Scope

This policy applies to every AI tool used at [Hospital name], whether bought, built in-house, included in other software, or used by staff on personal devices or free websites for hospital work. It applies to all employees, consultants, students, contractors and vendors.

3. Definitions

• AI tool: software that produces predictions, classifications, recommendations, summaries, text, speech or images from data using machine learning or similar methods.
• Clinical-purpose AI: an AI tool intended to diagnose, treat, monitor, or drive or inform clinical decisions. Such tools may be medical devices under CDSCO, SFDA or MOHAP rules.
• Generative AI: AI that produces new text, speech, images or code.
• AI owner: the named manager accountable for an AI tool's safe use.
• Qualified reviewer: a staff member authorised to check and accept an AI output in their area (for clinical outputs, a licensed clinician).
• AI incident: any event where an AI output caused, or could have caused, harm, a privacy breach, a wrong decision or unfair treatment.

4. AI committee

4.1 [Hospital name] has an AI committee reporting to [the Board / Hospital Management Committee].

4.2 Members: a chair ([Medical Director]); IT and information security lead; data protection lead; quality and patient safety lead (NABH/JCI coordinator); nursing lead; legal or compliance; finance; and the AI owner for each item under discussion. A patient representative is invited when patient-facing tools are reviewed.

4.3 Meetings: at least every [month]. Quorum is [five] members including the chair or deputy and the data protection lead.

4.4 Decisions: the committee approves, conditionally approves, pauses or retires AI tools, sets monitoring thresholds, and reviews incidents. Decisions and reasons are minuted.

5. AI register

5.1 The committee keeps one register of every AI tool in use or pilot (fields in Appendix A).

5.2 No AI tool may be used for hospital work unless it is on the register with status "Approved" or "Pilot".

5.3 Department heads confirm their department's entries every [6 months].

6. Risk tiering

6.1 Each tool is assigned a risk tier (1–4) using the definitions in this policy's risk tier table.

6.2 The tier sets the approval route and review frequency. When in doubt, the higher tier applies.

7. Approval before use

7.1 The AI owner submits the intake checklist (Appendix B) before purchase, pilot or build.

7.2 Approval requires: a named measurable purpose and baseline; the vendor's intended-use statement; regulatory status for clinical-purpose AI (CDSCO in India, SFDA in Saudi Arabia, MOHAP in the UAE); a data protection impact assessment for tools that process patient data; security review; results on [Hospital name]'s own anonymised or pilot data; a patient-disclosure decision (section 9); a training plan; and a monitoring plan with thresholds (section 12).

7.3 Tier 3 and 4 tools run in shadow mode — outputs reviewed but not acted on without checking — for at least [2 weeks] before live use.

7.4 Contracts follow section 16 before any patient data is shared.

8. Prohibited uses

Staff must not:

• enter patient-identifiable information into any AI tool that is not on the register, including free public chatbots;
• allow an AI tool to send clinical advice, results or diagnoses to patients without review by a qualified reviewer;
• use AI to make final decisions about admission, discharge, treatment, triage priority or employment without human review;
• allow a vendor to use [Hospital name] data to train or improve models without written approval from the committee and the data protection lead;
• use AI-generated images or voices that impersonate real staff or patients.

9. Patient transparency and consent

9.1 Patients are told in plain language, in a language they understand, when AI is used in a way that affects their care or communications (for example, ambient documentation or AI voice calls). Scripts are in Appendix C.

9.2 Where AI materially influences a treatment decision, the clinician explains its role as part of informed consent.

9.3 Patients may ask for a human alternative where one is reasonably available; asking will not affect their care.

9.4 Notices and consent follow applicable data protection law, including India's Digital Personal Data Protection Act, 2023 and Rules, 2025, the UAE's health-data and personal-data laws, and Saudi Arabia's Personal Data Protection Law.

10. Data protection and security

10.1 [Hospital name] remains responsible for patient data processed by AI vendors on its behalf.

10.2 Patient data is processed only in locations approved by the data protection lead and permitted by law (for example, in-country hosting where UAE or Saudi rules require it).

10.3 Minimum controls: encryption in transit and at rest; role- and site-based access; single sign-on or multi-factor authentication; audit logs kept for at least [one year]; tested backups; and removal of identifiers wherever the purpose allows.

10.4 Vendors must notify [Hospital name] of security incidents within [6 hours] of discovery, so the hospital can meet its own reporting deadlines.

11. Human review and accountability

11.1 Outputs from Tier 3 and 4 tools are checked and accepted by a qualified reviewer before they are acted on or entered into the record.

11.2 The person who accepts an AI output is accountable for the decision, as with any other information they rely on.

11.3 Staff can override any AI output; overrides are not penalised.

12. Performance and quality monitoring

12.1 For each tool, the committee sets measures, a baseline and a threshold that triggers review. Examples:

12.2 The AI owner reports results to the committee at the frequency set by the tool's tier.

13. AI incident and safety reporting

13.1 Any staff member can report an AI incident through [the incident reporting system], and may do so anonymously. Reports are treated as learning, not blame.

13.2 The quality team triages each report within [2] working days, informs the AI owner, and decides whether to pause the tool.

13.3 The committee reviews every AI incident within [5] working days of triage and records the cause, fix and follow-up.

13.4 Where a clinical-purpose AI may have caused harm, the hospital informs the vendor and, where required, the relevant regulator, using its existing adverse-event process. De-identified learning may be shared with professional or industry safety networks.

14. Bias and fairness

14.1 Before approval and at each review, the AI owner checks performance across relevant groups in [Hospital name]'s patient mix — for example language (including mixed-language speech), age band, sex and, where relevant, nationality.

14.2 Material differences are reported to the committee with a plan to fix, limit or retire the tool.

15. Changes to AI tools

15.1 Vendors must give [30] days' notice of material changes to models, sub-processors or hosting, except urgent safety fixes.

15.2 Any change to the model, vendor, intended use or hosting location triggers re-review at the tool's tier.

16. Vendor management

AI contracts include: purpose limitation and no training on hospital data without written approval; named sub-processors and hosting locations; incident notification within [6 hours]; performance reporting; notice of model changes; audit and information rights; regulatory-status warranties for clinical-purpose AI; data return and deletion at exit; and liability terms reviewed by legal.

17. Education and training

17.1 All staff complete AI awareness training at induction and every [12 months], covering this policy, prohibited uses and how to report incidents.

17.2 Users of each Tier 2–4 tool complete role-specific training before access is granted.

17.3 Training completion is recorded per employee and available as accreditation evidence.

18. Retiring AI tools

When a tool is retired, the AI owner removes access, recovers or deletes data under the contract, records the reason on the register, and confirms that dependent workflows have a replacement.

19. Exceptions

Exceptions to this policy require written approval from the committee chair and the data protection lead, are time-limited, and are recorded on the register.

20. Non-compliance

Breaches of this policy are handled under [Hospital name]'s disciplinary and vendor-management procedures. Serious breaches involving patient data are also handled under the data-breach procedure.

21. Review

The committee reviews this policy at least every [12 months], and sooner when laws, standards or the hospital's use of AI change.

Appendix A — AI register fields

Appendix B — Intake checklist

• Problem, metric and baseline stated
• Intended-use statement from vendor
• Risk tier proposed
• Regulatory status confirmed for clinical-purpose AI
• Data protection impact assessment (if patient data)
• Security review completed
• Results on our anonymised or pilot data
• Bias check across relevant patient groups
• Patient disclosure decided; script ready
• Training plan and user list
• Monitoring measures and thresholds set
• Contract clauses (section 16) agreed

Appendix C — Patient disclosure scripts (AI documentation example)

English: "During this consultation, your doctor may use an AI tool to help write your medical notes. Your doctor checks every note. If you'd prefer we didn't use it, just tell us — it won't affect your care."

Hindi: "इस परामर्श के दौरान आपके डॉक्टर आपके मेडिकल नोट्स लिखने में मदद के लिए एक AI टूल का उपयोग कर सकते हैं। डॉक्टर हर नोट की जाँच करते हैं। अगर आप नहीं चाहते कि इसका उपयोग हो, तो हमें बता दें — इससे आपके इलाज पर कोई असर नहीं पड़ेगा।"

Arabic: "قد يستخدم طبيبك خلال هذه الاستشارة أداة ذكاء اصطناعي للمساعدة في كتابة ملاحظاتك الطبية. يراجع الطبيب كل ملاحظة بنفسه. إذا كنت تفضّل عدم استخدامها، يُرجى إخبارنا، ولن يؤثر ذلك على رعايتك."

Appendix D — AI incident report fields

Date and time; tool and version; department; what the AI output was; what happened or nearly happened; patient impact (none / potential / actual); immediate action taken; reporter (optional); triage outcome; committee decision.

End of template.

The seven elements mapped to evidence

India and GCC rules this policy supports

For country detail, see AI in healthcare in the UAE and Saudi Arabia.

Training evidence for NABH

NABH's human resource standards expect training to be documented, tracked per employee and linked to competence. Section 17 produces exactly that record for AI. A learning platform that syncs with your HR system and exports per-employee completion reports, such as SurgyLearn, makes the evidence easy to produce at assessment.

Next step

Use this policy with our healthcare AI RFP template and scorecard: the RFP's security gate and regulatory questions feed straight into the approval in section 7.

Related reading

• Hospital AI buyer's guide — governance step
• Healthcare AI RFP template and scorecard
• CDSCO software as a medical device: hospital guide
• DPDP Act for hospitals
• NABH 6th edition roadmap

Sources

• Polsinelli, The Joint Commission and CHAI release guidance on responsible AI use in healthcare (guidance released 17 September 2025)
• Healthcare Innovation, CHAI releases AI governance playbooks; Joint Commission launches certification (June 2026)
• Indian Council of Medical Research, Ethical Guidelines for Application of AI in Biomedical Research and Healthcare (2023)
• AZB & Partners via Mondaq, MeitY releases India AI Governance Guidelines (November 2025)
• CDSCO, Guidance Document on Medical Device Software (July 2026)
• International Bar Association, How is AI in healthcare being regulated in the UAE? (May 2026)
• Al Tamimi & Company, AI in healthcare – Kingdom of Saudi Arabia

This template is a practical starting point, not legal advice. Adapt it with your legal, compliance and clinical leaders before adoption.