HITRUST AI Compliance Checklist for Protected Data Flows

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, identities, routes, and evidence. The HITRUST CSF provides an assessable control framework across regulatory and standards requirements. The nine checks below focus on the HTTP AI request path while preserving clear ownership for endpoint, provider, and application controls.

1. Define the AI assessment scope

List applications, gateways, retrieval services, model endpoints, storage, and administrative consoles involved in AI workflows. Mark where PHI or other protected data enters, moves, and persists. 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, and 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, or route 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, record changes, and 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, or blocking. Document which application renders warnings, collects human approval, or prevents automatic write-back. Keep gateway claims limited to traffic it inspects. A response record should identify the associated request, applied rule, and 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, and integrity metadata. Send it through a write path independent of the application making the call. Protect access, define retention, and test export. 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, and 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. Revisit the review when a provider changes models, regions, or contractual terms.

9. Run recurring control tests

Test identity, classification, route enforcement, denied requests, audit generation, and evidence retrieval on the cadence defined by the risk program. Repeat tests after material changes. Alert on missing records, unexpected destinations, policy failures, and 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, and HITRUST assessment work outside the gateway. DeepInspect supplies the request-path control and evidence layer for traffic placed behind it. If your assessment workbook needs that mapping, let's talk today.