ISO 42001 AI Policy Template for Healthcare: Clauses That Can Be Enforced and Evidenced

What the policy has to do

ISO/IEC 42001:2023 is the international standard for AI management systems. It specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, and the requirements include an AI policy and objectives. It applies to organizations of all sizes and sectors, and certification is voluntary. A healthcare policy should therefore claim alignment with the standard, not certification, unless an independent assessment has been completed.

On the HIPAA side, the Security Rule requires regulated entities to implement administrative, physical and technical safeguards for electronic protected health information (ePHI). The technical safeguards sit in 45 CFR 164.312, and paragraph (b) addresses audit controls. The Rule's stated goals are confidentiality, integrity and availability of ePHI, protection against reasonably anticipated impermissible uses or disclosures, and workforce compliance. Those goals are a useful anchor for the rationale in each PHI-related clause. Regulatory status can change, so confirm the current text as of November 2026 before quoting it in the policy.

A policy written only as a document is read and reviewed after the fact. It records intent. It cannot show what an AI system was permitted to do in a specific interaction, or what it actually did. The practical fix is to split each clause into two layers: the statement that humans approve, and the rule that a system evaluates for every interaction and tool call. Some clauses, such as board accountability or training cadence, stay procedural. Others, such as PHI handling or permitted tools, can be enforced directly.

The template, section by section

The sections below follow a common policy structure. For each, the item states what the clause says, the runtime rule it can become, and the evidence it should produce. The mappings to standard clauses and HIPAA provisions are an analytical approach, so carry the exact clause or control reference your auditor will test in a mapping column of your own template.

• 1. Scope and roles: Clause: which AI systems, models, agents and tools are covered, and who owns approval, operation and exceptions. Rule: only registered users, applications and agents may call AI resources, and each call carries an identity. Evidence: the identity, application and policy version attached to every decision. Role assignments and training stay procedural.
• 2. Acceptable use: Clause: permitted and prohibited purposes, such as drafting administrative text versus making clinical or coverage decisions unaided. Rule: block requests routed to prohibited use cases and allow approved ones. Evidence: the matched rule, the action taken and the reason code for each blocked or allowed request.
• 3. Data handling and PHI: Clause: what PHI may enter a prompt, a retrieval step or a tool call, and where processing may occur. Rule: detect PHI in inputs and outputs, then allow, redact or block by destination, user role and purpose. Enforce data residency by restricting permitted endpoints. Evidence: what was detected, what action was applied, and the destination.
• 4. Human oversight: Clause: which actions require a person to approve before they execute, such as writing to a record system or sending a message to a patient or member. Rule: escalate matching tool calls for human approval and hold execution until a decision. Evidence: the request, the approver, the decision, the timestamp and any stated rationale.
• 5. Third-party and tool use: Clause: the approved list of models, tools and servers, with conditions per entry. Rule: allow only listed models and tools, block others, and rate limit high-volume or bulk-retrieval calls. Evidence: the model or tool called, the list version in force, and the outcome.
• 6. Incident handling, evidence and retention: Clause: what counts as an AI incident, who is notified, how long evidence is kept and where. Rule: repeated blocks or policy violations trigger escalation to the incident owner. Evidence: durable, tamper-evident records retained for the period the policy states, in a location that satisfies residency requirements.

Designing evidence for audit controls

HIPAA 164.312(b) is the audit controls provision, so the evidence design should start from it. Review the current regulatory text directly and write the evidence requirements to match it, instead of relying on a summary. The key design decision is granularity. Evidence captured at the level of the individual interaction or tool call lets an auditor pick any clause, find the rule that implements it, and inspect real decisions made under that rule.

A useful evidence record answers five questions: who or what made the request, what was requested, which rule version was evaluated, what action was taken, and what the outcome was. Records for human approvals add the approver and decision. Records for redaction should show that a transformation occurred without reproducing the PHI that was removed. Storing raw PHI in the evidence store would create the exposure the policy is meant to prevent.

Traceability runs in both directions. From a clause, an auditor should reach the rules and the records. From a record, the auditor should reach the clause, the rule version and the policy version in force on that date. This requires versioning policy text and rules together and retiring neither without a record of the change. The same traceability supports the continual improvement expected of an AI management system, because blocked and escalated events show where clauses are too loose or too strict.

Adapting the template for health systems, insurers and banks

Health systems are typically covered entities, so HIPAA is the primary regulatory frame. Their template emphasizes clinical and operational use cases, PHI in prompts and retrieval, human approval before actions touch a patient record, and evidence aligned to audit controls. Acceptable use clauses need to separate administrative assistance from anything that influences care, with stronger oversight for the latter.

Insurers and banks that handle health-related data usually answer to additional regulators beyond, or instead of, HIPAA. Their templates should add use cases such as underwriting, claims, member communication or customer service, and the regulator-specific expectations for each. Regimes such as NAIC model guidance and NYDFS requirements may apply depending on the entity. Write those clauses from the primary regulatory text for your jurisdiction and lines of business, and keep them as separate, labeled clauses so evidence can be filtered by regime.

The structure of the template does not change across these organizations. What changes are the scope definitions, the prohibited and approval-gated use cases, the data categories in the PHI clause, and the regulatory references in the mapping column. Keeping one rule format across all of them lets a group that spans a health plan, a provider and a financial arm maintain a single policy model with sector-specific clauses.

Where runtime enforcement fits, and where it stops

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Its actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and the enforcement produces audit-ready evidence mapped to frameworks including HIPAA and NIST. Trussed runs in production with healthcare organizations and offers self-managed deployment in the customer cloud, with configurable retention and data residency, which maps directly to the retention and residency clauses above.

The limits matter for the policy text. Runtime enforcement and per-interaction evidence do not amount to ISO/IEC 42001 certification. They do not establish model or dataset provenance, and they do not govern business transactions across tasks and agents. A policy should not promise those outcomes on the strength of enforcement alone. Clauses on model lineage, training data, management review and internal audit need their own processes and owners within the AI management system.