AI and HITRUST: Adding AI Systems to a Certified Scope

HITRUST certification is a common requirement for organisations handling health data, and adding an AI system to a certified scope raises questions the framework was not originally written around. This guide covers them, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

What determines whether the AI system is in scope?

The same test as anything else: what data it touches and what it can affect.

Factor	Effect on scope
Processes protected information	In scope
Connected to in-scope systems	Generally in scope
Can affect in-scope security	In scope
Fully isolated, synthetic data only	Potentially out of scope
Sends data to external provider	In scope, plus third-party questions
Stores outputs containing health data	In scope

What controls can be inherited?

Typically platform-level controls covering infrastructure, network segmentation, physical security, and parts of access management, depending on the environment and what the platform provider offers.

Inheritance has to be documented rather than assumed. Assessors ask which controls are inherited, from whom, and on what evidence, and an inheritance claim without a supporting attestation is a finding rather than a saving.

What do assessors probe hardest?

Third-party model provider relationships and prompt handling.

The questions are practical: what data leaves the environment in a prompt, whether the provider retains it, who can see model outputs, and whether logs would let you reconstruct who saw what health information and when. Teams that can answer those quickly have designed for it; teams that cannot spend weeks assembling answers. See AI and SOC 2 Type 2.

How does AI change risk analysis?

It adds failure modes that are not confidentiality, integrity, or availability breaches in the usual sense.

Output quality degradation, behaviour changing when a provider updates a model, and a system producing incorrect clinical or administrative information confidently are all risks worth analysing explicitly. A risk register that covers only breach scenarios misses what is most likely to go wrong. See what is an slo for ai systems.

What evidence do you need?

Scope documentation, inheritance mapping with supporting attestations, third-party assessments for model providers, evidence of prompt handling and redaction, access and audit logs covering model outputs, and risk analysis covering AI-specific failure modes.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes data minimisation and logging design earlier. Sending only what the model needs, rather than the whole record, reduces both the risk and the assessment surface.

Logging is the other half: audit evidence has to cover who accessed model outputs containing health information, which means treating outputs as protected data in their own right rather than as ephemeral responses.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Claiming inherited controls without attestations. Sending whole records in prompts when a subset would do. Treating model outputs as ephemeral rather than as stored health information. And omitting AI-specific failure modes from risk analysis.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How does this interact with other health obligations?

It overlaps substantially with the underlying regulatory requirements for health data, and certification is generally a way of demonstrating them to partners rather than a separate regime.

Organisations that build once — minimised data, documented third parties, complete audit logging, AI-aware risk analysis — satisfy both, and the evidence transfers between them with little rework.

What should you do first?

Map exactly what leaves your environment in a prompt for one AI system. That single diagram answers most of the scope and third-party questions an assessor will ask.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: prompts minimised to what the model needs rather than whole records, model outputs treated as protected data with full audit logging, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and SOC 2 Type 2.