Policy & Compliance (PC)

Infrastructure Domain - HAIAMM v3.0

Practice Overview

Objective: Publish the priority policies and compliance map that make the AI/HAI Infrastructure Assurance program enforceable, so every inference endpoint, model registry, GPU fleet, orchestrator control plane, vector store, AI-specific CI/CD pipeline, and feature store the organization hosts and operates is governed by a documented set of rules, gated before it serves production AI workloads, and defensible to auditors and regulators.

Description: PC-Infrastructure codifies three priority policies specific to AI/HAI infrastructure governance, an AI Infrastructure Standards Policy establishing per-archetype security baselines (encryption, isolation, region/residency, observability minimums), a GPU / Accelerator Acceptable Use Policy governing who can run what workloads on what fleet with what data classification, and an AI Infra Intake / Provisioning Gate Policy defining what every new inference endpoint, registry, vector store, orchestrator, or CI/CD pipeline must produce before it hosts production AI workloads. It maps those policies to the compliance regimes that directly apply to infrastructure hosting AI/HAI systems: EU AI Act Art. 15 (accuracy/robustness/cybersecurity of high-risk systems), Art. 12 (log-keeping), GDPR Art. 32 (security of processing) and Art. 44–49 (international transfers / region pinning), ISO/IEC 42001 AIMS, ISO/IEC 27001 A.5/A.8, SOC 2 CC6/CC7/CC8, and sector-specific obligations (HIPAA security rule, PCI-DSS for in-scope infrastructure, FedRAMP / sector cloud). At L1 the goal is not exhaustive policy coverage, it is the minimum enforceable stack needed to gate AI/HAI infrastructure before it hosts production workloads and to trace every relevant regulation to a single named policy.

Context: Most organizations operating AI infrastructure inherit generic cloud-hardening standards and generic change-management policies. Neither answers the questions that AI/HAI infrastructure raises: What isolation controls are required before a multi-tenant inference cluster serves customer data? Who may authorize a training run on a GPU fleet that touches regulated PII? What residency obligations apply to a cross-border vector store serving a GDPR-regulated retrieval pipeline? And how does EU AI Act Art. 15 cybersecurity evidence flow from the team that provisions the inference endpoint to the security review that approved it? Without AI-specific policies and an explicit compliance map, shadow AI infrastructure accumulates, Art. 15 and Art. 32 obligations go unmet, and auditors cannot trace a regulation to a control. PC-Infrastructure closes that gap at the hosting and serving layer, it governs what the organization operates, in contrast to PC-Software, which governs what it builds, and PC-Vendors, which governs what it consumes.

Maturity Level 1

Objective: Publish the three priority AI/HAI infrastructure policies, map them to the priority compliance requirements, and operate the provisioning gate that prevents ungated infrastructure from hosting production AI workloads

At this level, the organization ships the minimum viable policy stack for AI/HAI infrastructure governance, maps each policy to the regulations and standards that make it auditable, and implements the provisioning gate through which every AI/HAI infrastructure instance must pass before hosting production workloads.

Dependencies

• SM-Infrastructure L1 (required): the AI/HAI infrastructure inventory, archetype taxonomy, and program charter are the substrate the policies govern, PC-Infrastructure L1 cannot operate without the inventory it references.
• Alignment (not a hard dependency): enterprise Legal/Privacy function for data-residency obligations; existing cloud-hardening and change-management programs; platform and SRE management authority to enforce the provisioning gate.
• Supports / unblocks: EG-Infrastructure L1 (workforce and practitioner training needs published policies as the teaching object); SR-Infrastructure L1 (requirements packs inherit policy controls); SA-Infrastructure L1 (reference architectures operationalize the policy's archetype controls); IM-Infrastructure L1 (exception and violation handling flows from policy).

Desired Outcomes

• Three short, AI-specific infrastructure policies exist, are approved by Legal/Privacy and Security, are accessible to every platform engineer and SRE, and are acknowledged at hire and annually.
• A one-page priority compliance map lets auditors and regulators trace each requirement (EU AI Act Art. 15/12, GDPR Art. 32/44–49, ISO/IEC 42001, ISO/IEC 27001 A.5/A.8, SOC 2 CC6/CC7/CC8, sector-specific) to the single policy that carries it.
• No AI/HAI infrastructure instance reaches production hosting without passing the provisioning gate; the gate produces a required-artifacts checklist keyed to each archetype.
• Every AI/HAI infrastructure instance in production with regulatory exposure (customer-facing inference endpoints, infrastructure processing regulated data, cross-border data flows) has a named infrastructure-owner and a logged provisioning decision.
• Shadow AI infrastructure surfaces for retroactive intake through an amnesty path rather than going deeper underground.
• The program demonstrates EU AI Act Art. 15 cybersecurity obligations with a documented chain from policy → intake → provisioning gate decision → named accountable owner.

Activities

A) Publish the three priority AI/HAI infrastructure policies

Ship these three policies in their smallest useful form, short, readable, and specific enough to be enforceable against platform provisioning decisions. Each is a distinct lever; all three must exist at L1.

1. AI Infrastructure Standards Policy, per-archetype security baselines every AI/HAI infrastructure instance must meet before hosting production workloads: - Inference endpoint / model-serving cluster: TLS 1.2+ on all serving interfaces; no public endpoint without DR approval; model artifacts encrypted at rest (managed KMS minimum); authentication required for all API calls; structured inference access logs retained per the ML-Infrastructure logging baseline. - Model registry: artifact signing or checksum verification on promotion; access control on model-version promotion gate (minimum two-party approval for production promotion); registry credentials stored in secrets vault; promotion audit log retained. - GPU / accelerator fleet: fleet credentials in secrets vault; no standing human IAM access on production training or inference nodes; GPU workload isolation (dedicated namespace or VM-level isolation per workload); training-data access scoped to the declared training corpus; GPU-spend tagging by owning team and workload. - Orchestrator / control plane: tool-call scope bounded to declared tool list; no orchestrator agent may call APIs outside its declared scope without explicit SR-approved tool-scope boundary; control-plane authentication enforced; orchestrator state and tool-call logs retained. - Vector-store infrastructure: access control on collection / namespace level; no collection with public read access without DR approval; TLS on all client connections; collection contents classified per SM-Infrastructure and SM-Data inventories. - AI-specific CI/CD: model artifacts signed or checksummed on build; promotion gates require passing eval scores (minimum configurable thresholds); pipeline credentials in vault; pipeline runs audited with artifact lineage record. - Feature store / online serving cache: access control on feature-group level; TLS on serving interface; feature-serving logs retained.

2. GPU / Accelerator Acceptable Use Policy, who can run what workloads on what fleet with what data classification: - Permitted without pre-approval: training or inference workloads on sanctioned GPU fleets using only public or internal-classified data; workloads declared in the SM-Infrastructure inventory with a provisional or sanctioned status. - Requires approval before running: training or fine-tuning on confidential or regulated data (PII / PHI / PCI / source code); workloads that span multiple classification boundaries on a shared fleet; large-scale batch training runs consuming the majority of a shared fleet; any training workload not yet in the SM-Infrastructure inventory. - Prohibited without explicit named sign-off: training on customer PII without privacy-officer approval; running regulated-data workloads on a multi-tenant fleet without per-workload isolation confirmation; exporting GPU fleet credentials to personal workstations or external repositories; spinning up GPU resources in personal or untagged cloud accounts to avoid the provisioning gate. - Disclosure obligation: platform and ML engineers must add all GPU-hosted AI workloads to the SM-Infrastructure inventory, including side-projects, exploratory runs, and workloads behind feature flags. - Attestation required at hire and annually; violations routed through the program sponsor and Legal.

3. AI Infra Intake / Provisioning Gate Policy, what every new AI/HAI infrastructure instance must produce before hosting production AI workloads: - Intake required before production provisioning for all seven archetypes; development and staging environments do not require gate passage but must be in the SM-Infrastructure inventory. - Required provisioning artifacts by archetype (minimum at L1): - All archetypes: named owning team and infrastructure owner; archetype-keyed AI Infrastructure Standards baseline met (as declared above); TA threat snapshot from the archetype-level threat library; SM-Infrastructure inventory record created. - Inference endpoint / model-serving cluster: no-public-endpoint confirmation or DR approval for public endpoint; model encryption at rest confirmed; inference access log retention confirmed; data classification of serving traffic declared. - GPU / accelerator fleet: fleet credential vault storage confirmed; GPU workload isolation posture declared; training-data access scope documented; GPU-spend tag applied. - Orchestrator / control plane: tool-call scope documented and SR-approved; control-plane auth confirmed; orchestrator state log retention confirmed. - Vector-store infrastructure: collection access control confirmed; data classification of indexed content declared; TLS confirmed. - AI-specific CI/CD: artifact signing or checksum verified; eval-gate thresholds configured; pipeline credential vault storage confirmed. - Cross-border or regulated-data instances: data residency documented; GDPR Art. 44–49 transfer basis confirmed if personal data crosses regions; data classification of data passing through declared. - Amnesty path: instances already in production without gate passage may enter through retroactive intake without penalty; the inventory record is created and the control gaps are tracked as open IM findings. - Provisioning gate authority: the program sponsor (or delegated platform security lead) issues the provisioning decision; the decision and the artifact checklist are logged permanently.

B) Map the three policies to the priority compliance requirements

Build a one-page priority compliance map. At L1 the goal is traceability: an auditor asking "how does Art. 32 security-of-processing apply to inference infrastructure?" reaches one row in this table, one policy, and one artifact.

C) Operate the provisioning gate and track foundational compliance outcomes

Policies without an enforced gate do not reduce shadow AI infrastructure. L1 closes the loop by putting the three policies behind a single provisioning checkpoint and measuring whether the gate catches production deployments.

Gate mechanics at L1: - Single intake ticket queue; single SLA (triage within 5 business days; fast-track provisional approval within 10 BD for Low-tier archetypes with no regulated data, no customer exposure, and no cross-border flows). - Artifacts checklist is archetype-keyed, the platform engineer submitting intake receives the checklist for their archetype; missing artifacts block production provisioning. - Integration with the SM-Infrastructure inventory: gate approval creates or updates the inventory record with artifact links. - Amnesty path is visible: linked from the intake form, the AUP, and the platform engineering Slack/Teams channel pins. - Exceptions logged with owner, rationale, and review date; no exception may remain open longer than 90 days without re-review.

Outcome Metrics (L1)

Process Metrics (leading)

• Intake SLA adherence, ≥90% of intakes triaged within 5 BD; ≥90% of Low-tier intakes provisionally approved within 10 BD.
• Policy exception aging, exceptions open >90 days reviewed by program sponsor; target: 0 exceptions past expiry.
• Compliance map refresh, reviewed and updated when a new regulation comes into force or a new archetype is added to the inventory; at minimum annually.
• Gate checklist accuracy, archetype-keyed required-artifacts checklists reviewed quarterly; platform engineers' reported blocking rate tracked.

Effectiveness Metrics (business value)

• Platform provisioning cycle-time impact, time from intake submission to provisional approval should not increase as the gate matures; the gate is an enabler, not a bottleneck.
• Retroactive catch rate, % of instances discovered through amnesty or shadow-infra discovery that would have reached production without the gate; rising catch rate signals the gate is working.
• Auditor evidence turnaround, a compliance or external audit asking "show me Art. 15 cybersecurity evidence for this inference endpoint" is satisfied within 5 business days from the provisioning gate record.

Success Criteria

• Three priority policies published, approved by Legal/Privacy and Security, and communicated to all platform engineers and SREs.
• One-page priority compliance map published, covering all rows in the table above; linked from each policy.
• Provisioning gate operational with a published SLA, a per-archetype artifacts checklist, and an amnesty path for previously ungated infrastructure.
• ≥95% of platform/SRE headcount has acknowledged the AI Infrastructure Standards AUP in the current year.
• ≥85% of AI/HAI infrastructure instances reaching production in the last 12 months passed the gate (100% for Critical/High-tier).
• Every customer-facing and regulated-data-processing AI/HAI infrastructure instance in production has a named infrastructure owner logged in the SM-Infrastructure inventory.

Maturity Level 2

Objective: Deepen policy controls and compliance evidence per AI/HAI infrastructure risk tier, assemble continuous compliance evidence bundles for Critical/High instances, and operationalize FedRAMP and regional compliance gating for applicable instances

At this level, policy depth is calibrated to the risk tier assigned in SM-Infrastructure L2. Critical-tier instances, customer-facing inference endpoints, GPU fleets processing regulated data, orchestrators hosting Annex III workloads, carry deeper contractual controls, explicit sign-off requirements, per-tenant isolation enforcement, and continuously assembled compliance evidence. Low-tier instances stay fast-tracked. FedRAMP / regional compliance gating is operationalized for Critical-tier infrastructure in applicable sectors rather than acknowledged-in-policy-only.

Dependencies

• PC-Infrastructure L1 (required): three priority policies, compliance map, and provisioning gate must be live.
• SM-Infrastructure L2 (required): the risk-tier rubric and tier-treatment matrix drive the differential policy depth. PC-Infrastructure L2 inherits tier definitions from SM-Infrastructure L2.
• Supports / unblocks: EG-Infrastructure L2 (tier-calibrated reviewer training needs tier-aware policies); TA-Infrastructure L2 (per-instance deep threat models for Critical/High need archetype controls to bound scope); IR-Infrastructure L2 (drift detection confirms policy adherence post-provisioning); IM-Infrastructure L2 (tier-aware incident playbook enforces policy SLAs).

Desired Outcomes

• Policy depth visibly differs by tier, Critical-tier instances require explicit executive and security sign-off, per-tenant isolation confirmation, and FedRAMP/regional compliance evidence where applicable; Low-tier instances use fast-track with base SR pack only.
• Every Critical and High AI/HAI infrastructure instance has a live compliance evidence bundle (TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, infrastructure-owner record) that a regulator can open today.
• FedRAMP / regional compliance gating is enforced before Critical-tier infrastructure in applicable contexts goes live, not retrospectively assembled at audit time.
• Policy exceptions have finite lifespans with named owners; no stale exceptions accumulate unnoticed.
• Sector-specific obligations (HIPAA security rule for PHI-processing infrastructure, PCI-DSS for in-scope infrastructure, FedRAMP for government-context infrastructure) are operationalized for the instances they apply to, not generically acknowledged.

Activities

A) Tier-calibrated policy depth and sign-off requirements

Extend the three L1 policies with tier-specific addenda using the SM-Infrastructure L2 tier rubric:

• Critical: full SR pack with REM required; CISO and VP Infrastructure sign-off required before go-live; per-tenant isolation confirmation required; FedRAMP or sector-equivalent compliance evidence required for US federal/public-sector context before go-live; EU AI Act Art. 15 cybersecurity evidence assembled; GDPR Art. 32/44–49 residency and transfer basis confirmed; GPU fleet credentials zero-standing-access confirmed; re-review mandatory on every material change (new AI workload hosted, new tenant, new region, new data class) within 14 days.
• High: full SR pack + REM with fast-track exemptions; CISO-delegated platform security lead sign-off; EU AI Act and GDPR assessments required; isolation posture confirmed; re-review on material change within 30 days.
• Medium: base SR pack + REM; fast-lane DR (or DR waiver for sanctioned reference-architecture implementations); re-review annually or on material change within 60 days.
• Low: base SR pack only; self-attested artifact checklist; re-review at annual review.

Policy-exception framework: deviations from any tier's required controls require a named owner, a compensating control description, a Legal/platform-security reviewer acknowledgment, and an expiry date (max 12 months). Critical-tier instances have no amnesty path for missing provisioning artifacts after L2 is established, missing artifacts are blocking findings routed through IM.

B) Continuous compliance evidence assembly and FedRAMP / regional compliance gating

For every Critical and High AI/HAI infrastructure instance, maintain a live compliance evidence bundle that auto-assembles: - Current TA snapshot (age vs. last material change threshold). - Current SR REM with gap status and owner for each open gap. - SA reference-architecture confirmation or DR-approved deviation record. - Latest DR decision and date. - Latest IR attestation and date (or finding log if IR found drift). - ST evidence: full battery last run date, model-extraction resistance test, vector-store inversion test, orchestrator-scope test, GPU-fleet IAM test last run date. - ML logging-baseline confirmation with last-validated date. - Infrastructure-owner record: named accountable owner, data-residency declaration, Art. 32 / Art. 15 obligations checklist. - FedRAMP / sector-equivalent compliance evidence for applicable instances.

Staleness rules: any element past its tier-specific refresh window triggers a PC-Infrastructure finding routed to IM. Critical staleness thresholds, TA snapshot: 90 days; IR attestation: 6 months; ST evidence: 30 days. The evidence bundle is the primary artifact a regulator receives for any specific AI/HAI infrastructure instance.

C) Exception management, sector-specific bundles, and tier-aware enforcement

• Exception register integrated with the provisioning gate: no exception approved without tier-appropriate compensating control and expiry.
• Monthly exception aging review, exceptions more than 90 days past expiry auto-escalate to the program sponsor.
• Sector-specific evidence bundles generated from the compliance evidence bundle for applicable instances: HIPAA security-rule bundle (PHI-processing infra), PCI-DSS 12.8 bundle (cardholder-data-adjacent inference infra), FedRAMP bundle (US federal/public-sector infra), ISO/IEC 27001 Annex A bundle. Completeness tracked per instance.
• Enforcement asymmetry: Critical-tier instances with missing provisioning artifacts are blocking findings; no amnesty applies post-L2.

Outcome Metrics (L2)

Process Metrics (leading)

• Evidence-bundle refresh cadence honored by tier (Critical: TA snapshot ≤90d, IR ≤6mo, ST ≤30d; High: TA snapshot ≤180d, IR ≤12mo, ST ≤60d).
• Exception aging reviewed monthly; zero exceptions past expiry un-escalated.
• FedRAMP / regional compliance tracker reviewed quarterly; no in-scope instance missing evidence un-escalated.

Effectiveness Metrics (business value)

• Regulatory inquiry turnaround, evidence bundle open time for a regulator or auditor request ≤5 business days.
• Audit findings on AI/HAI infrastructure control set trending down; repeat findings = 0.
• Policy-exception volume trending down as tier-calibrated controls become the default provisioning path.

Success Criteria

• Three priority policies extended with tier-specific addenda; tier-appropriate sign-off in place for 100% of Critical instances in the last 12 months.
• Compliance evidence bundle live for every Critical/High instance; staleness inside target.
• Exception register comprehensive; reviewed monthly; zero exceptions past expiry un-escalated.
• Sector-specific evidence bundles (HIPAA / PCI-DSS / FedRAMP as applicable) complete for all in-scope instances.
• Regulatory / auditor inquiry SLA (≤5 BD) met in the last 12 months.

Maturity Level 3

Objective: Automate compliance attestation from IaC, cloud-provider, and runtime telemetry; drive policy updates from monitoring signals and regulatory motion; and contribute to AI infrastructure standards development through CNCF, OpenSSF AI, and sector regulators

At this level, compliance for AI/HAI infrastructure is a byproduct of the provisioning and operating pipeline rather than a separate evidence-assembly step. IaC state events, cloud-provider API events, Kubernetes admission webhook records, and runtime telemetry feed the compliance evidence bundle continuously. Policy updates are data-driven. The program contributes to AI infrastructure standards development, CNCF, OpenSSF AI, FinOps Foundation, and sector regulatory bodies receive evidence-backed artifacts from operating a mature AI/HAI infrastructure assurance program.

Dependencies

• PC-Infrastructure L2 (required): evidence bundle and exception register must be running.
• SM-Infrastructure L3 (required): automation substrate, signal-driven inventory and tier updates feed the continuous attestation pipeline.
• ML-Infrastructure L2+ (required): runtime signals (access logs, configuration drift events, GPU-fleet IAM events) feed the policy-refresh cycle.
• Supports / unblocks: PC-Infrastructure L3 evidence posture enables the other 11 Infrastructure-domain practices to claim continuous attestation rather than periodic snapshots.

Desired Outcomes

• Compliance attestation for any AI/HAI infrastructure instance is generated on demand in hours, with full provenance from IaC and cloud-provider events.
• Policy refresh is evidence-driven and externally anchored, monitoring trends, incident learnings, EU AI Act implementing acts, GDPR EDPB AI guidance, NIST AI RMF Playbook updates, FedRAMP rev changes, and sector guidance feed a versioned, dated policy changelog.
• The program is a recognized contributor to AI infrastructure standards, CNCF, OpenSSF AI, FinOps Foundation, and sector regulators receive substantive technical artifacts.
• Contributed IaC policy-as-code templates, provisioning gate schemas, and compliance evidence structures lead the industry.

Activities

A) Continuous compliance attestation from IaC and cloud-provider signals

• Evidence bundles auto-update from: IaC state events (Terraform plan/apply records carry artifact checklist status), cloud-provider provisioning events (new endpoint created auto-opens intake check), Kubernetes admission webhook records (policy-as-code assertions on GPU workloads and serving deployments verified at admission), runtime configuration events (drift from declared baseline opens PC finding), ML logging-baseline validation events (log retention confirmed or failed), model-registry promotion events (CI/CD pipeline integrity evidence refreshed).
• Attestation-generation pipeline: any regulatory or auditor request produces a provenance-complete evidence pack for any instance, regulation-keyed (EU AI Act Art. 15 evidence pack, GDPR Art. 32 processing-security pack, SOC 2 CC6/CC7/CC8 evidence set, FedRAMP evidence set) or instance-keyed, within 3 business days.
• SLO: all Critical/High instances continuously attested; attestation currency SLO ≤24 hours latency after a triggering event; attestation completeness ≥99% of active Critical/High instances.

B) Telemetry-driven policy refresh and regulatory-motion tracking

• Quarterly policy-refresh cycle driven by: ML-Infrastructure detection trends (what infrastructure misconfigurations are rising), IM-Infrastructure incident learnings (which policy gaps created incident conditions), tier-movement data (which archetype classes are growing fastest and at what risk level), external regulatory and standards updates (EU AI Act implementing acts, GDPR EDPB AI guidance, NIST AI RMF Playbook updates, FedRAMP revision cycles, sector-specific guidance from HHS / PCI SSC / FedRAMP PMO / sector cloud regulators).
• Refresh output: versioned changelog for each of the three policies, approved by Legal/Security; EG-Infrastructure training content updated within 30 days of any policy change.
• Regulatory-motion tracker: a maintained log of open regulatory instruments with expected effective dates, mapped to the policy they will affect; the working group reviews it quarterly.

C) Standards contribution and external engagement

• Participate in AI infrastructure standards and regulatory forums: CNCF AI/ML Working Group, CNCF TAG Security, OpenSSF AI supply-chain security, FinOps Foundation AI Infrastructure SIG, EU AI Act Art. 15 implementing-acts consultations, NIST AI RMF Playbook infrastructure chapter working groups, FedRAMP Emerging Technology Advisory Group, sector regulators (HHS AI infrastructure guidance, PCI SSC AI guidance, sector cloud regulators).
• Contribute AI-infrastructure-specific artifacts: provisioning gate schemas, compliance evidence bundle templates, archetype-keyed policy-as-code assertions, IaC module templates with embedded compliance guardrails, through CNCF, OpenSSF AI, CSA AI Safety Initiative, Shared Assessments.
• Target: at least 2 substantive public contributions or standards comments per year on AI/HAI infrastructure policy and compliance topics.

Outcome Metrics (L3)

Process Metrics (leading)

• Evidence-pipeline change-detection health monitored; on-call paged when a feed staleness threshold is exceeded.
• Policy-refresh cycle on calendar; zero missed cycles in last 12 months.
• Regulatory-motion tracker reviewed quarterly; no open instrument missed.
• Contribution pipeline ≥2 items in-flight at any time.

Effectiveness Metrics (business value)

• Regulator / auditor / customer feedback explicitly positive on infrastructure attestation posture.
• Material audit findings on AI/HAI infrastructure controls = 0 in the last 12 months.
• Policy changes measurably close infrastructure misconfig classes identified in prior quarters.
• Contributed IaC templates and policy-as-code assets adopted externally.

Success Criteria

• On-demand attestation pack generation inside 3 business days for any active AI/HAI infrastructure instance; SLA met in last 12 months.
• Continuous attestation pipeline operational with ≤24h currency SLO; completeness ≥99% of Critical/High instances.
• Quarterly telemetry-driven policy-refresh cycle operating with a versioned, externally-auditable changelog.
• ≥2 substantive public regulatory or standards contributions per year on AI/HAI infrastructure policy.
• External recognition documented (citations, invitations, adopted artifacts).
• Zero material audit findings on AI/HAI infrastructure controls in the last 12 months.

Key Success Indicators

Level 1: - Three priority policies published and approved by Legal/Security: AI Infrastructure Standards Policy, GPU / Accelerator Acceptable Use Policy, AI Infra Intake / Provisioning Gate Policy. - One-page priority compliance map published, covering EU AI Act Art. 15/12/Annex III, GDPR Art. 32/44–49/33, ISO/IEC 42001, ISO/IEC 27001 A.5/A.8, SOC 2 CC6/CC7/CC8, HIPAA security rule, PCI-DSS 12.8, FedRAMP (as applicable). - Provisioning gate operational with a per-archetype artifacts checklist, published SLA, and amnesty path for previously ungated infrastructure. - ≥95% of platform/SRE headcount has acknowledged the AI Infrastructure Standards AUP in the current year. - ≥85% of AI/HAI infrastructure reaching production in the last 12 months passed the gate; 100% for Critical/High-tier.

Level 2: - Tier-specific policy addenda in place; Critical instances carry explicit CISO + VP Infrastructure sign-off; evidence bundles live for all Critical/High instances with staleness inside tier-specific targets. - Exception register comprehensive with named owners, compensating controls, and expiry dates; monthly aging review active; Critical-tier missing artifacts treated as blocking findings with no amnesty. - Sector-specific evidence bundles (HIPAA / PCI-DSS / FedRAMP as applicable) complete for in-scope instances. - Regulatory / auditor inquiry evidence SLA (≤5 BD) met in the last 12 months.

Level 3: - Continuous attestation pipeline operational; ≤3 BD on-demand evidence pack generation and ≤24h currency SLO met. - Quarterly telemetry-driven policy refresh operating with versioned changelog; 100% of changes traceable to ML/IM telemetry or named regulatory update. - ≥2 substantive public regulatory or standards contributions per year on AI/HAI infrastructure policy; external recognition documented. - Zero material audit findings on AI/HAI infrastructure controls in the last 12 months.

Common Pitfalls

Level 1: - ❌ Reusing the generic cloud-hardening standard and change-management policy without AI-specific archetype clauses, no rule on GPU fleet IAM, no per-archetype inference-endpoint controls, no provisioning gate for vector stores; auditors cannot trace Art. 32 obligations to a control. - ❌ Provisioning gate applies only to new cloud deployments announced through a formal project, misses GPU workloads provisioned by researchers, vector stores stood up as database extensions, and orchestrators repurposed for AI without re-review. - ❌ Compliance map lists framework names but does not say which policy carries which regulation, an auditor asking "how does Art. 15 cybersecurity apply to this inference endpoint?" must trace it themselves and typically concludes coverage is untraceable. - ❌ No amnesty path, platform engineers with ungated inference endpoints or GPU workloads in production hide them rather than surface them; shadow AI infrastructure inventory stays incomplete. - ❌ Gate checklist is archetype-agnostic, an inference cluster and a vector store receive the same checklist; cluster-specific controls (no-public-endpoint, model encryption) and vector-store controls (collection access control, inversion-resistance) are never actually required. - ❌ Infrastructure owner not assigned, customer-facing inference endpoints operate with no named accountable owner; EU AI Act Art. 15 and GDPR Art. 32 obligations are acknowledged in policy but not operationalized. - ❌ FedRAMP / regional compliance treated as out-of-scope for L1, inference infrastructure in US federal/public-sector contexts ships without any compliance assessment.

Level 2: - ❌ Tier-specific addenda published but sign-off requirements never enforced, Critical-tier inference clusters ship with only the base L1 checklist because no one enforces the executive sign-off rule. - ❌ Compliance evidence bundle is a folder of PDFs that only the compliance lead can navigate, a second reviewer cannot assemble a regulator pack without them. - ❌ Staleness thresholds exist on paper but no alert fires when exceeded, the TA snapshot ages past 90 days for a Critical inference endpoint and nobody notices until an audit. - ❌ FedRAMP gating acknowledged in policy but the evidence assembly process never built, the gate reads "FedRAMP required" but no checklist or evidence template exists; the requirement is bypassed silently. - ❌ Exception register exists but expiry dates never enforced, stale exceptions from the amnesty window become the permanent state for a significant fraction of the inventory.

Level 3: - ❌ Attestation pipeline generates evidence that is technically complete but narratively thin, a regulator still needs a human to explain what the IaC state records mean; the 3 BD SLO is met but a follow-up is needed. - ❌ Policy refresh is cadence-only, quarterly ritual without real telemetry input; the changelog reads like formatting updates and Legal cannot explain what incident prompted which change. - ❌ External contributions are deadline-only comment letters rather than technical artifacts (IaC templates, policy-as-code examples, evidence schemas) that standards bodies actually use. - ❌ Policy-as-code templates published once and then go stale, external practitioners stop trusting the program because they find outdated IaC modules that miss current cloud-provider API changes. - ❌ ROI narrative omits compliance-cost-reduction evidence, the biggest L3 business case (lower audit preparation overhead, lower regulatory exposure, faster FedRAMP assessment) is never measured or reported.

Practice Maturity Questions

Level 1: 1. Have you published and formally approved the three priority AI/HAI infrastructure policies, AI Infrastructure Standards Policy (per-archetype baselines: encryption, isolation, region/residency, observability minimums), GPU / Accelerator Acceptable Use Policy (who can run what, on what fleet, with what data classification), and AI Infra Intake / Provisioning Gate Policy (what every new endpoint/registry/vector-store must produce before hosting production workloads), with a one-page compliance map tracing each priority requirement (EU AI Act Art. 15/12, GDPR Art. 32/44–49/33, ISO/IEC 42001, ISO/IEC 27001 A.5/A.8, SOC 2 CC6/CC7/CC8, sector-specific) to the specific policy that carries it? 2. Is the provisioning gate operational with a per-archetype artifacts checklist, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and does ≥85% of AI/HAI infrastructure reaching production in the last 12 months have a gate record (100% for Critical/High)? 3. Are ≥95% of platform/SRE headcount covered by a current-year AI Infrastructure Standards AUP acknowledgment, and does every customer-facing and regulated-data-processing AI/HAI infrastructure instance in production have a named infrastructure owner logged in the SM-Infrastructure inventory?

Level 2: 1. Have the three priority policies been extended with tier-specific addenda (per the SM-Infrastructure L2 rubric), and do Critical instances carry explicit CISO + VP Infrastructure sign-off at provisioning with a live compliance evidence bundle covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, infrastructure-owner record, and FedRAMP / regional compliance evidence where applicable? 2. Is a compliance evidence bundle continuously maintained for every Critical/High instance with staleness inside tier-specific targets, and can a regulatory or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days? 3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing provisioning artifacts treated as blocking findings (no amnesty), and sector-specific evidence bundles (HIPAA / PCI-DSS / FedRAMP as applicable) complete for in-scope instances?

Level 3: 1. Does a continuous attestation pipeline auto-update evidence bundles from IaC state events, cloud-provider provisioning events, Kubernetes admission webhook records, and runtime configuration signals, with an attestation currency SLO of ≤24 hours latency and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High instances continuously attested? 2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Infrastructure detection trends + IM-Infrastructure incident learnings + regulatory-motion tracker + tier-movement data) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update? 3. Does the program contribute at least two substantive public comments or standards artifacts per year on AI/HAI infrastructure policy topics (CNCF, OpenSSF AI, FinOps Foundation, EU AI Act Art. 15 implementing guidance, NIST AI RMF Playbook, FedRAMP Emerging Technology, sector regulators), with documented external recognition?

Document Version: HAIAMM v3.0 Practice: Policy & Compliance (PC) Domain: Infrastructure Last Updated: 2026-05-14 Author: Verifhai