HITRUST AI Security Certification: Training Data Requirements for AI Providers

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

How the HITRUST AI Security assessment is structured

The HITRUST AI Security assessment is an add-on, not a standalone certificate: it is performed alongside a HITRUST e1, i1 or r2 assessment and adds AI-specific requirements scoped to the system type, deployment model and risk. HITRUST states that no more than 44 AI security-specific requirements are added to an assessment, delivered as an ai1 assessment (paired with e1 or i1) or an ai2 assessment (paired with r2) [6]; confirm the current version and pathway rules in MyCSF before scoping.

The requirement statements discussed below come from the published draft specification on Manula [1]. Requirement IDs such as 19.06cAISecOrganizational.1 follow the HITRUST CSF control-reference pattern, which ties each AI requirement back to an existing CSF domain. Because draft numbering and wording can change between versions, map your evidence to the requirement intent and re-check IDs against your assessment object.

For a healthcare AI vendor, the practical consequence is that training data stops being an ML-team concern and becomes in-scope assessment evidence. The assessor will sample datasets, not just read policies.

The legal-obligations requirement for AI data

The core training-data requirement asks you to identify and evaluate every constraint on data used to train, validate, tune or augment prompts via RAG, covering laws, regulations, contracts, internal governance and copyright, before first use and at least annually [1]. It reaches beyond pretraining: a retrieval index over customer documents and a fine-tuning set built from support tickets are both in scope.

In practice the assessor looks for three things. First, a complete list of datasets in scope, with no "shadow" corpora added by an engineer. Second, a documented evaluation per dataset that names the applicable obligations. Third, evidence that the evaluation happened before use and was repeated on schedule.

Typical obligations to map for a US healthcare AI provider include:

• HIPAA Privacy Rule. Whether the data is PHI, de-identified under 45 CFR 164.514(b) by Safe Harbor or Expert Determination [3][4], or a limited data set usable only under a data use agreement per 164.514(e) [4]. See HIPAA-compliant AI training data.
• Contracts. Business associate agreements, data use agreements, and data license terms covering permitted uses, term, derivative models and deletion.
• State law. Biometric statutes such as BIPA (biometric data rules), CCPA deidentified-data commitments (buyer obligations), and AI disclosure duties (US state AI laws).
• Copyright and license terms. Non-commercial licenses (see CC BY-NC datasets) and how the data was acquired.
• Non-US regimes. If the model is offered in the EU, Article 10 data governance for high-risk systems and Article 53 GPAI duties.

Trusted data sources and dataset lineage

The trusted-source requirement expects a maintained catalog of approved data sources whenever the system uses data-driven models, including classical machine learning and generative AI; this and the requirements below appear in the same draft specification as [1], so confirm wording in MyCSF. A catalog entry should identify the source, the basis for trusting it, and who approved it.

The inventory topics in the draft also cover linkage between dataset, model and pipeline configuration. That means an assessor may pick a production model version and ask which dataset versions trained it, which config produced it, and whether each dataset was in the trusted catalog at training time. Teams that store data in an object store without immutable version IDs (for example, an S3 prefix overwritten each week) usually fail this trace.

Practical controls that make lineage provable:

• Content hashes (SHA-256) per delivered file, recorded at intake and again at training time.
• Dataset version IDs written into the model card and experiment tracker run metadata (for example, MLflow or Weights & Biases run parameters).
• A frozen manifest per dataset release: file list, record counts, schema version and the license ID it was delivered under.

Poisoning, robustness and third-party datasets

The training-data measures requirement asks you to evaluate whether extra defenses such as adversarial training are needed against evasion and poisoning, document that evaluation, repeat it at least semiannually, and revisit it after AI security incidents, per the draft specification. Draft threat topics also include poisoning through compromised third-party training data.

For externally sourced data, the weak points are predictable. A supplier pipeline that accepts unauthenticated uploads, a delivery over email or an unsigned public link, or a refresh that silently replaces records all break the chain between what you reviewed and what you trained on. Ask suppliers how deliveries are authenticated, how files are integrity-checked, and how corrections are versioned rather than overwritten; the supplier security review guide covers the questions.

Statistical checks belong in the same evidence: label-distribution drift between releases, duplicate and near-duplicate rates, and outlier records concentrated in one source. Record the result even when nothing is found, because the requirement tests that the evaluation happened.

The evidence pack for licensed training data

A defensible evidence pack ties every in-scope dataset to an obligation review, a license and a lineage record that an assessor can sample end to end. Build it once per dataset and update it on the annual review cycle [1].

Illustrative example: invented to show structure; it does not describe an available dataset.

The audit readiness evidence pack guide extends this structure to regulators and enterprise customers, and the due diligence questionnaire shows which fields to request from suppliers up front.

Where HITRUST AI fits next to ISO 42001 and NIST AI RMF

HITRUST AI Security is a control-level, assessor-tested certification of an AI system's security, while ISO/IEC 42001 certifies an AI management system and NIST AI RMF is a voluntary risk framework [2][5]. Many healthcare AI vendors face all three because hospital customers ask for HITRUST, enterprise buyers ask for ISO certifications, and federal-facing teams map to NIST.

The training-data evidence overlaps heavily. ISO/IEC 42001 Annex A includes data controls (acquisition, quality, provenance) and supplier controls; check exact wording against the standard. NIST AI RMF 1.0 and the Generative AI Profile, NIST AI 600-1, address data provenance and third-party risk in the Map and Govern functions [5]. One dataset record, maintained well, can answer all three.

How licensed sourcing changes the obligation review

Buying data under a written license makes the 19.06c evaluation tractable because the constraints are named in one document rather than inferred from scraped content. Ask any supplier for: the rights basis (ownership and consents), the license terms on uses and term, the de-identification method and QA result, and a delivery path that preserves integrity.

SourceX sources operational datasets from US companies on request, such as support histories, engineering records, documents, and finance and legal workflows, and manages licensing and ongoing purchases. Every dataset is rights-reviewed and delivered under a license that defines records, uses, term and delivery; diligence materials on source, rights, preparation and allowed use are prepared per dataset, which maps directly onto the evidence pack above. Health records require HIPAA de-identification by Safe Harbor or Expert Determination, and no de-identification method is perfect, so keep your own residual-risk review. Healthcare teams can start from healthcare buyers or describe the data you need.

For the broader map of rules, start at the compliance hub or the AI data hub.

Get licensed training data with records your assessor can sample

SourceX sources operational data from US companies on request, rights-reviews each dataset and delivers it under a license that defines records, uses, term and delivery, through private access-controlled workflows after an agreement and supplier approval. A request does not guarantee a match, and nothing is contracted until a supplier agrees. Tell SourceX what data your model needs.