HITRUST AI Compliance Checklist: 9 Tests

A HITRUST AI compliance checklist should trace protected data through one real model request. Select a user, open the clinical or administrative workflow, submit a controlled test prompt, and identify every service that receives it. Then inspect the authorization decision and audit record. That test turns an abstract scope discussion into named systems and identities, tied to the routes and evidence a real request produced. The HITRUST CSF provides an assessable control framework across regulatory and standards requirements, and HITRUST's own AI Assurance Program now folds AI-specific risk management into that same assessment starting with CSF v11.2. The nine checks below focus on the HTTP AI request path while keeping endpoint and provider controls owned separately from whatever the application itself is responsible for.

TL;DR

A HITRUST assessment of an AI workflow has to trace one real request end to end: which identity sent it, what protected data it carried, which model route received it, and what record the decision left behind. The nine tests below build that trace directly, covering scope, inventory, identity, classification, destination rules, response handling, audit evidence, vendor evidence, with recurring testing layered on top, so an assessor can sample real events instead of a written policy.

1. Define the AI assessment scope

List applications, gateways, retrieval services, model endpoints, storage, along with the administrative consoles involved in AI workflows. Mark every point where PHI or other protected data enters and moves through the flow. Track separately where it comes to rest. Assign an owner to every boundary. Validate the diagram with observed traffic because a forgotten pilot can sit outside the drawn scope. The conference-room whiteboard should match the destinations visible in request records. Any excluded component needs a documented rationale and a control preventing scoped data from reaching it.

2. Build an observed model inventory

Record provider, model, region, route, business owner, intended data classes, along with approval state. Reconcile procurement and survey inventories with observed traffic. Model aliases and temporary endpoints deserve separate review because their destination can change beneath a stable application name. Set policy so an unknown route is denied or quarantined according to the organization's risk decision. Store the approval and removal history for assessor sampling.

3. Bind requests to authenticated identity

Carry the human or workload identity to the AI enforcement point. Include role and approved attributes needed for authorization. Provider API keys identify the calling application and often hide the actual principal. Run a sample request and confirm the audit record names the person or workload behind it. Shared accounts should receive compensating controls and an explicit remediation plan where individual attribution is required.

4. Classify protected data before transmission

Inspect prompt content for PHI and other governed categories before it reaches the model. Define actions for each class, including permit, redact, block, along with routing to an approved endpoint. Document how uncertain classification is handled. Test with safe synthetic examples and preserve the classification outcome rather than copying live clinical text into every audit record. The HIPAA AI risk assessment guide provides related workflow questions.

5. Restrict model destinations and actions

Map roles and data classes to approved model routes. Agentic workflows also need action limits for external sharing and record changes, plus any tool calls that cross the HTTP boundary. Test one permitted route and one denied route for each sensitive workflow. My opinion is that the denied test is the part worth keeping; it proves the rule can stop traffic when the input violates policy. Local desktop and file-system actions require their own endpoint controls.

6. Evaluate response handling

Generated responses can reproduce protected data or introduce unsafe instructions into downstream systems. Apply response-side policy where the workflow requires classification, redaction, along with blocking. Document how warnings render, how human approval gets collected, along with what prevents automatic write-back. Keep gateway claims limited to traffic it inspects. A response record should identify the associated request and applied rule, plus the disposition, without creating an unnecessary archive of full clinical content.

7. Produce independent audit evidence

Generate a per-decision record with event ID, time, principal, model, classifications, policy version, result, along with integrity metadata. Send it through a write path independent of the application making the call. Protect access and define retention. Test export separately as part of the same control. The detailed HITRUST AI audit evidence guide explains how these fields support operational sampling.

8. Collect vendor and inherited evidence

Document the model provider's security assurances, data-use terms, retention behavior, incident notification, subprocessors, along with relevant certifications. Identify which controls are inherited and which remain with the deploying organization. Provider evidence cannot prove the enterprise's user authorization decision, so retain request-level records locally. The risk-management vocabulary in NIST's AI Risk Management Framework (govern, map, measure, manage) is a useful cross-check when a provider's own AI documentation uses different terms for the same inherited control. Revisit the review when a provider changes models or regions. Do the same when contractual terms change.

9. Run recurring control tests

Test identity, classification, route enforcement, denied requests, audit generation, along with evidence retrieval on the cadence defined by the risk program. Repeat tests after material changes. Alert on missing records, unexpected destinations, policy failures, along with privileged configuration changes. A dashboard should link to the underlying event and approved policy version. Aggregate counts help operations, while assessment evidence depends on reproducible individual decisions.

DeepInspect

DeepInspect provides identity-aware policy enforcement for HTTP AI traffic. It classifies requests, restricts model routes, applies per-role rules, evaluates configured response policy, and fails closed when required. Each decision creates a tamper-evident record with the fields used in assessment sampling.

The checklist also requires IAM, endpoint, vendor, application, legal, along with HITRUST assessment work outside the gateway. DeepInspect supplies the request-path control and evidence layer for traffic placed behind it. If your assessment workbook still needs that mapping to a request-path control, this is where it happens. Let's talk today.