Keeping AI Transparency Evidence After the HTI-5 Final Rule
As of November 2026, the ASTP/ONC HTI-5 final rule revises the decision support interventions criterion (§ 170.315(b)(11)) and removes the clinical decision support criterion (§ 170.315(a)(9)). Treat this as a scoping exercise, not a reason to dismantle evidence processes. Inventory the AI transparency evidence you produce, tag each item as certification-driven or independently valuable, map it to obligations that do not depend on ONC certification, and assign retention and ownership. Evidence of what your AI was allowed to do and what it did is the most durable category.
Criteria for keep, simplify or retire
- Keep if the item supports at least one obligation that does not depend on ONC certification.
- Keep if it records what a system actually did, because it cannot be reconstructed later.
- Simplify if the item duplicates another record or was formatted only for a certification template.
- Simplify if a developer still supplies the information and the contract commits them to continue.
- Retire only when no mapped obligation remains, counsel has approved, and no legal hold applies.
What the HTI-5 final rule changed
The ONC deregulatory final rule, referred to by ASTP/ONC as the HTI-5 final rule, was published in the Federal Register on October 28, 2026. Of the 60 certification criteria in effect, 14 were finalized for removal and seven for revision. The December 2025 proposal had been to remove 34 and revise seven. ASTP/ONC lists the decision support interventions criterion, § 170.315(b)(11), as revised and the clinical decision support criterion, § 170.315(a)(9), as removed, both effective on the final rule's effective date. The proposal had suggested fully removing the AI model card requirements from the decision support interventions criterion.
ONC's stated reasoning concerns the certification program. It said it identified no evidence from peer-reviewed publication or trade press that users of certified health IT relied on the (b)(11) transparency requirements to access, record or modify source attributes, or that those requirements improved patient care. Commenters proposed alternatives, including voluntary transparency standards and retaining useful elements of the predictive DSI transparency and risk management requirements. Those are suggestions, not outcomes.
The rationale is about certification burden and evidence of use. It says nothing about your own exposure. Your organization still has to show what its AI systems were permitted to do and what they did, to auditors, payers, counterparties and courts.
Separate intended behavior from actual behavior
The (b)(11) requirements applied to developers of certified health IT. The evidence they produced, such as source attributes and risk management summaries, describes the intended or designed behavior of an AI application. That material is useful context, but it is written by someone else about a system in general.
Deployer-side evidence is different. It records the policy your organization defined, the version in force at a given time, the decision taken on a specific interaction (allow, redact, block), and any human approval. This evidence describes actual behavior in your environment. It was never created to satisfy a certification criterion, so a narrowed ONC scope does not remove the reason to have it.
This distinction drives the keep, simplify or retire decision. Developer-supplied transparency documents may lose their regulatory driver, though they may continue under contract. Policy definitions, runtime decisions and approval records remain relevant to HIPAA, state law, contractual and payer requirements, litigation discovery and your internal risk policy. The specific requirements under each differ, and counsel should confirm how they apply to you.
A five-step sequence for the evidence review
Run the review in order and avoid retiring anything until the mapping is complete. Re-read the final revised text of § 170.315(b)(11) against your inventory before any retirement decision.
- 1. Inventory: Record every AI transparency artifact you produce or collect, who produces it, where it lives and the criterion or policy it was created for.
- 2. Tag: Mark each item as certification-driven (for example, tied to source attributes or developer risk management summaries) or independently valuable (policy, runtime and approval records).
- 3. Map: Link each item to surviving obligations: HIPAA, state law, contracts and payer requirements, litigation hold and discovery, and internal risk policy. Note mappings that need counsel's confirmation.
- 4. Define: Set the retention period, named owner, storage location and a producibility test for each retained item.
- 5. Automate: Identify items that policy enforcement can generate automatically and plan to move them off manual assembly, keeping existing processes until replacements are validated.
Retention, ownership and producibility
Keep three classes of evidence in separate stores: developer or vendor transparency documents received, your own AI policy definitions and versions, and runtime enforcement records. Separation lets each class carry its own retention period and access rules. Vendor documents may be replaceable. Runtime records are not.
For each class, assign one owner and define who may read, export and delete. Decide on integrity protections, such as immutability or tamper-evident storage, and on export formats an auditor can open. These are design decisions rather than settled requirements, so document your reasoning.
Test producibility, not just storage. For a chosen AI interaction, can you retrieve the policy version in force and the allow, redact or block decision taken, and explain both to an auditor? If the answer depends on an engineer assembling logs by hand, the evidence is fragile. Apply legal hold and discovery readiness to runtime records and policy versions, and have counsel approve retention periods.
Also confirm whether your certified health IT developers will keep supplying source-attribute or risk-management documentation after the revision, and whether that commitment is written into the contract.
Generating evidence in the execution path
Evidence assembled after the fact depends on memory, screenshots and reconstructed logs. Evidence generated at the point where policy is enforced records the decision, the policy version, the timestamp and the action taken as the interaction happens. Whether a given tool produces such records should be confirmed with the vendor before you rely on it.
Trussed enforces policy in the execution path, across models, agents, tools and MCP servers, and applies allow, redact, block, rate limit or escalation for human approval to individual interactions and tool calls. That enforcement produces audit-ready evidence mapped to HIPAA, NAIC, NYDFS, EU AI Act and NIST. It deploys self-managed in the customer cloud, with configurable retention and data residency, which bear on where evidence is stored and for how long.
The scope is runtime control of interactions and tool calls. It does not cover model provenance, dataset provenance or end-to-end tracing of agentic workflows, so those items in your inventory need other sources.
From certification-driven to durable evidence
Inventory
List every AI transparency artifact, its producer, its location and the purpose it was created for.
Tag
Separate certification-driven items from those with independent value.
Map
Tie each item to obligations that survive a narrowed ONC scope.
Retain
Set owner, retention, storage and a producibility test for each item.
Review which evidence your AI execution path can produce
Walk through your inventory with us and identify which items can be generated by policy enforcement at runtime rather than assembled manually.
Assess Your AI ReadinessHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.