Implementation Review (IR)

Infrastructure Domain - HAIAMM v3.0

Practice Overview

Objective: Verify, at go-live and on a recurring cadence, that the actual configuration of AI/HAI infrastructure the organization operates matches the design approved at DR, and that it stays there as components evolve.

Description: IR-Infrastructure is the configuration check for AI/HAI infrastructure components, the moment a reviewer opens the IaC state, the cloud-provider API, the Kubernetes manifest, and the model registry and confirms that what is running matches the DR decision record. At L1 the review runs at go-live, at least annually, and on material change (model version swap, new tenant added, GPU scheduling policy changed, isolation policy updated). At L2, IR-Infrastructure consumes IaC drift-detection tooling, cloud-provider Config Rules and asset-inventory APIs, admission-controller policy checks, model-registry webhooks, and vendor admin API probes to detect configuration drift continuously for High and Critical-tier components. Findings are severity-tagged and SLA-bound per the SM-Infrastructure L2 tier-treatment matrix; they feed IM-Infrastructure for tracking and resolution.

Context: The gap between the approved infrastructure design and the running state is the primary source of silent security exposure in AI/HAI infrastructure. A GPU fleet's residual-state-clearing policy is correct in the DR record but the scheduler was reconfigured to allow cross-workload sharing on a Critical-tier node. A model registry's signed-artifacts-only policy appears in the SR REM but a platform update reset the enforcement flag. An inference endpoint's per-tenant rate-limit is documented in the SA pattern but the rate-limit layer was removed during a cost-optimization change. IR-Infrastructure closes these gaps by making the implementation check systematic, evidence-based, and recurring, not a one-time pre-launch checkbox or a scramble when an incident reveals a configuration regression.

Maturity Level 1

Objective: Run per-archetype implementation reviews at go-live, annually, and on material change, verifying deployed configuration matches the SA-Infrastructure pattern, the DR decision, and that the SR-Infrastructure REM evidence is current

At this level, the gap between approved design and running infrastructure is systematically checked at the moments it matters most. Every review produces findings with severity tags, named owners, and SLA-bound resolution dates.

Dependencies

• DR-Infrastructure L1 (required): the approved DR decision record is the specification IR checks against; without it there is no authoritative baseline.
• SR-Infrastructure L1 (required): the REM defines which requirements must be evidenced; IR verifies the evidence is current and accurate.
• SA-Infrastructure L1 (required): the SA reference pattern defines the intended configuration shape; IR checks adherence to the pattern's controls.
• EG-Infrastructure L1 (required): reviewers must understand AI/HAI infrastructure archetypes and know where to look for pattern controls in IaC state, cloud-provider APIs, and admin consoles.
• Supports / unblocks: ST-Infrastructure L1 (tests run against the verified configuration), EH-Infrastructure L1 (hardening acts on IR findings), IM-Infrastructure L1 (IR findings become issues in the backlog), ML-Infrastructure L1 (logging configuration verified here feeds monitoring).

Desired Outcomes

• The gap between the DR-approved design and the live infrastructure configuration stays small and short-lived.
• Material configuration drift is found by the program, not by an external auditor or an incident.
• Every finding has a named owner, a severity tag, and a SLA-bound resolution date; aging findings are visible to the program sponsor.
• Material changes to a production AI/HAI infrastructure component always trigger a review before the change is in production.
• The SR-Infrastructure REM is kept current, evidence cited in the REM is verified to still be accurate, not just present.

Activities

A) Publish the per-archetype implementation review checklist

One checklist per SM-Infrastructure archetype, focused on the configuration points where production reality most commonly drifts from the approved design. Each item is a yes/no with a required evidence artifact (IaC plan output, cloud-provider API response, screenshot, test result).

Common spine across all archetypes: - IaC state matches SA pattern, Terraform / Pulumi plan-vs-apply confirms the deployed configuration is within tolerance of the DR-approved IaC module; deviations flagged. - Config matches DR decision, workload identity, encryption key placement, isolation policies, rate-limit configs, and image pins match the DR decision record; deviations flagged. - SR REM evidence is current, a stratified sample of REM rows verified against current observable reality: workload identity confirmed via IAM API (not assumed), encryption keys confirmed in KMS (not inline), rate-limit confirmed active via probe, image pins confirmed in deployment manifest. - Logging is actually producing the events the design promised, pull a sample of required event types (model-serve events, admin-audit events, identity events) from the logging pipeline; confirm they are present, match the format, and meet the retention policy specified in the SR REM. - Per-tenant isolation actually enforced, run a cross-tenant probe to confirm one tenant cannot access another tenant's data, compute, or model artifacts through the component.

Archetype-specific additions:

• Inference endpoint / model-serving cluster: mTLS confirmed active (not bypassed by a network policy change); per-tenant rate-limit confirmed active (not reverted to global-only); model artifact signature verification confirmed active at serving time (test by attempting to serve an unsigned artifact, verify rejection); canary deployment configuration matches the DR-approved rollout plan; PII redaction at logging confirmed active (test with a synthetic PII-containing prompt and verify the PII is absent from the log output).

• Model registry: signed-artifacts-only policy confirmed active (attempt to push an unsigned artifact, verify rejection); lineage required policy confirmed active (attempt to promote an artifact without lineage, verify rejection); rollback tested within the last 90 days (test record on file); promotion-rights access control confirmed against current IAM assignments.

• GPU / accelerator fleet: residual-state-clearing confirmed operational (run job A on a GPU node, then run job B on the same node and verify job A's GPU memory is inaccessible to job B, test record on file); classification-aware scheduling confirmed (attempt to schedule a Critical-tier workload on a shared node, verify the scheduler rejects or redirects); per-job credential scoping confirmed (confirm job credentials expire after job completion and cannot be reused by subsequent jobs on the same node).

• Orchestrator / control plane: workflow-signing enforcement confirmed (attempt to submit an unsigned workflow, verify rejection); per-step principal assignment confirmed (confirm each step runs under its own identity, not the orchestrator's identity, via IAM audit log sample); control-plane API authentication confirmed (confirm unauthenticated API calls are rejected, run a probe without credentials and verify 401/403 response); agent-state-isolation confirmed (confirm a workflow step cannot read another step's in-flight state).

• Vector-store infrastructure: cross-tenant retrieval isolation confirmed (query from tenant A with a term matching tenant B's index, verify zero results or a namespacing error); classification-label propagation confirmed (query returns classification labels from the index in result metadata); query observability confirmed (pull a query log sample and verify tenant context, query, and result-count are captured).

• AI-specific CI/CD: pipeline-signing enforcement confirmed (attempt to run an unsigned pipeline, verify rejection); SLSA provenance generation confirmed active (pull a recent model artifact and verify provenance attestation is attached); eval-gate enforcement confirmed (attempt to promote a model without a passing eval attestation, verify the promotion gate blocks it); secrets-leak-prevention scan confirmed active in the pipeline (confirm a recent scan result is on file with zero findings or documented exceptions).

• Feature store / online serving cache: offline/online feature skew alert confirmed active (inject a synthetic skew and verify the alert fires); feature lineage confirmed in the store (verify a recent feature version carries a traceable source dataset and transformation record); rollback playbook tested within the last 90 days (test record on file); access control confirmed (read and write attempts by unauthorized principals rejected, verify via probe).

B) Perform reviews at the right moments

Three triggers at L1:

• Go-live review: before the component enters production (or before a new version or configuration goes live), verify the as-deployed state against the DR-approved design. No production cutover with a blocker finding open.
• Annual review: every active AI/HAI infrastructure component reviewed at least annually; scheduled from the SM-Infrastructure inventory (last-IR-date field linked to a review-due alert).
• Material-change review: any of the following triggers an ad-hoc review before the change ships to production: GPU scheduling policy change; new tenant added to a shared component; rate-limit policy change; workload identity change (new service account, new key); encryption key rotation to a new key management mechanism; model version or signing policy change on the model registry; pipeline signing policy change on AI-CI/CD; feature schema change on the feature store.

Reviews are evidence-based, IaC plan outputs, cloud-provider API responses, or probe results stored with the IR record.

C) Track findings to closure

Every review produces zero or more findings. Each finding carries: - Severity: Critical (e.g., GPU node sharing Critical-tier and non-Critical workloads without residual-state-clearing) / High / Medium / Low. Severity is calibrated to the SM-Infrastructure tier-treatment matrix; at L1 use a consistent judgment rubric pending SM L2 formalization. - Owner: named engineer or team owner; not "the platform team." - SLA from SM-Infrastructure tier-treatment matrix: Critical blocker resolved before production cutover or rollback required; High ≤7 days; Medium ≤30 days; Low ≤90 days or accepted residual. - Evidence: after-fix evidence artifact (IaC plan output, probe result, screenshot) linked to the finding before closure.

Findings feed IM-Infrastructure as issues and loop back to SR-Infrastructure where a finding reveals that an REM row's cited evidence was inaccurate.

Drift sources verified at L1 (without continuous tooling): - IaC repository: Terraform / Pulumi plan-vs-apply state for the component's infrastructure module. - Cloud-provider APIs: resource configuration changes vs. the DR-approved baseline (AWS Config, GCP Asset Inventory, Azure Policy state). - Kubernetes / orchestrator API: deployment manifest drift vs. the DR-approved manifests. - Model-registry events: model version changes, signing policy changes since the last IR. - CI/CD job parameters: build-job parameters affecting model versions, pipeline signing, eval-gate settings.

Outcome Metrics (L1)

Process Metrics (leading)

• Annual review calendar populated from the SM-Infrastructure inventory; components nearing review-due date visible in advance.
• Material-change trigger wired to SM-Infrastructure inventory material-change events; reviews queued within 5 business days of a confirmed material change.
• Reviewer backlog aging, no single reviewer more than 3 components overdue.
• SR REM update loop active, % of IR findings that trigger an REM row update for the affected requirement.

Effectiveness Metrics (business value)

• Drift-caught-early rate, findings closed before they reach an incident or an external audit.
• REM accuracy improvement, stale-evidence rate trends down as the IR / SR feedback loop operates.
• Avoided-incident stories, documented cases where IR caught a configuration regression before it was exploited or caused a data event.

Success Criteria

• Per-archetype IR checklists published, owned, and linked from the SM-Infrastructure inventory record and the DR decision record.
• Go-live, annual, and material-change review triggers wired to the SM-Infrastructure inventory; 100% of new AI/HAI infrastructure components in the last 90 days have a go-live IR record.
• ≥90% of active AI/HAI infrastructure components carry a current-year IR record.
• All Critical / blocker findings resolved before production cutover; High findings closed within 7 days with evidence linked.
• Findings-aging dashboard reviewed at least monthly by the program sponsor.

Maturity Level 2

Objective: Detect configuration drift continuously for Critical and High-tier components via IaC drift-detection tooling, cloud-provider Config Rules, admission-controller checks, model-registry webhooks, and vendor admin API probes; calibrate IR cadence per SM-Infrastructure tier

At this level, implementation review stops being a point-in-time check and becomes a continuous signal for Critical and High-tier components. Drift sources are wired to automated detection. Rate-limit configurations, signing policies, workload identity, and per-tenant isolation are validated recurrently via cloud-provider APIs and admission-controller checks, not trusted from one-time screenshots. IR cadence is explicitly differentiated by SM-Infrastructure L2 risk tier.

Dependencies

• IR-Infrastructure L1 (required): per-archetype checklists and findings workflow must be established.
• SM-Infrastructure L2 (required): the risk-tier rubric (Critical / High / Medium / Low) drives IR cadence and depth per the tier-treatment matrix (Critical: go-live + semi-annual + continuous drift; High: go-live + annual + material change; Medium: go-live + annual; Low: go-live).
• SA-Infrastructure L2 (required): IaC-encoded patterns establish the "correct" baseline that continuous drift detection measures against.
• Supports / unblocks: ST-Infrastructure L2 (tests run against the continuously verified configuration), EH-Infrastructure L2, ML-Infrastructure L2 (monitoring configuration verified here feeds detections).

Desired Outcomes

• Configuration drift on Critical-tier components is detected within days, not months.
• Workload identity, encryption key placement, per-tenant isolation, rate-limit configuration, and signing policies are verified via cloud-provider API state, not trusted from one-time configuration exports.
• IR cadence visibly differentiates by tier: Critical gets semi-annual reviews plus continuous drift detection; Low gets go-live only.
• All Critical-tier IR findings carry severity tags and SLAs matching the SM-Infrastructure L2 tier-treatment matrix.

Activities

A) Continuous drift detection from IaC, cloud-provider APIs, and admission-controller checks

Wire the following signal sources to an automated drift-detection pipeline for Critical and High-tier components:

• IaC drift-detection tooling: Terraform Cloud / Atlantis / Pulumi state diff runs on a defined cadence for Critical and High components; configuration deviations from the approved IaC module open IR findings automatically.
• Cloud-provider Config Rules / asset-inventory APIs: AWS Config Rules, GCP Asset Inventory, or Azure Policy continuously checks resource configurations against the DR-approved baseline; violations open IR findings with severity tags.
• Admission-controller policy checks: Kyverno / Gatekeeper policies enforce SA-Infrastructure reference pattern controls at the Kubernetes API level (workload identity annotations required, image signing required, resource quota policies enforced); policy violations open IR findings.
• Model-registry webhooks: model version promotions, signing policy changes, and lineage-exemption events trigger an IR re-review gate for the affected component; a model promotion without a corresponding DR material-change review is a Critical finding.
• Vendor admin API recurrent probes: for managed AI infrastructure components (Amazon Bedrock fleet configuration, Vertex AI model deployment settings, Azure OpenAI deployment configurations), recurrent probes via vendor admin APIs verify rate-limit settings, signing policies, and logging configurations match the DR-approved baseline; delta from the previous probe opens an IR finding.

Detection latency targets: Critical-tier drift detection ≤7 days from change event to finding opened; High-tier ≤30 days.

B) Tier-calibrated IR cadence

Publish and enforce per the SM-Infrastructure L2 tier-treatment matrix: - Critical: go-live + semi-annual + material-change-triggered + continuous drift detection. - High: go-live + annual + material-change-triggered. - Medium: go-live + annual. - Low: go-live + re-review on material change.

Every component in the SM-Infrastructure inventory has a last-IR-date and next-IR-due field; Critical-tier components with no IR in the last 180 days are escalated to the program sponsor.

C) Per-archetype boundary probing

For Critical and High-tier components, boundary probes are executed at each IR cycle to verify isolation and enforcement claims, not assumed from configuration declarations:

• Inference endpoint: run a cross-tenant probe (send a request with tenant A credentials that attempts to access tenant B's model endpoint or model artifact); verify rejection. Run an unsigned-model-artifact serving probe; verify rejection.
• GPU fleet: execute the residual-state-clearing test (run job A, then run job B on the same node, verify job A's GPU memory is inaccessible); record the test date and result. Attempt to schedule a Critical-tier workload on a shared node; verify the scheduler rejects or redirects.
• Orchestrator: submit an unsigned workflow definition; verify rejection. Run a step-privilege-boundary test (attempt to invoke a resource from within one step that belongs to another step's principal scope); verify rejection.
• Vector-store: run a cross-tenant retrieval probe; verify zero results or namespacing error. Verify classification labels are present and correct in query results.
• AI-CI/CD: attempt to run an unsigned pipeline; verify rejection. Attempt to promote a model artifact without a passing eval attestation; verify the gate blocks it.

Boundary probe evidence stored with the IR record; failures are Critical findings for Critical-tier components and High findings for High-tier components.

Outcome Metrics (L2)

Process Metrics (leading)

• Drift-detection pipeline health monitored, % Critical components producing a fresh signal in the last 7 days; on-call alert if feed silent for >48 hours.
• Vendor admin API probing calendar maintained; missed probes tracked as process-metric failures.
• Boundary probe coverage tracked per archetype per IR cycle.
• IR backlog tier-aware; Critical-tier findings never wait behind Low-tier queue items.

Effectiveness Metrics (business value)

• Drift caught before ST / ML detections or incidents, trend measured over quarters.
• Reduced audit findings on configuration claims, external auditors (SOC 2, ISO 42001) find IR evidence sufficient without supplemental screenshots or interviews.
• Vendor admin API probing reveals vendor-side changes (rate-limit policy reset by product update, signing enforcement changed by a platform release) before they become security incidents.

Success Criteria

• ≥90% of Critical-tier components under continuous drift detection; median detection latency ≤7 days.
• Vendor admin API probes current for ≥80% of Critical/High-tier managed components on a monthly (Critical) and quarterly (High) probing cadence.
• 100% of Critical/High-tier components with boundary probes on record in the current IR cycle.
• Tier-cadence adherence ≥95%; Critical-tier findings aged per the SM-Infrastructure L2 tier-treatment matrix SLAs.

Maturity Level 3

Objective: Continuous configuration attestation for Critical-tier components, daily attestation signal confirming IaC-pattern compliance and evidence freshness, automatic IM ticket on drift, and contribution to OpenSSF AI reference attestation schemas, CNCF AI working group, and OWASP LLM / Agentic Top 10 infrastructure patterns

At this level, configuration for Critical-tier AI/HAI infrastructure components is not periodically reviewed, it is attested continuously. Every Critical component produces a daily attestation signal confirming that IaC-pattern compliance, REM evidence freshness, and deployed configuration are within tolerance. Drift opens an IM-Infrastructure ticket automatically. Per-archetype configuration baseline schemas are contributed to OpenSSF AI, CNCF AI Working Group, and OWASP LLM / Agentic Top 10 infrastructure patterns.

Dependencies

• IR-Infrastructure L2 (required): automated drift detection, vendor admin API probing, boundary probing, and tier-calibrated cadence must be in place.
• SA-Infrastructure L3 (required): externalized IaC patterns supply the attestation frame for automated compliance scans.
• ML-Infrastructure L2+ (required): runtime signals (logging completeness, anomaly detections) are evidence sources the attestation pipeline reads.
• SR-Infrastructure L3 (alignment): machine-readable REM schema provides the evidence-freshness signals the attestation pipeline validates against.

Desired Outcomes

• Every Critical-tier AI/HAI infrastructure component produces a daily attestation signal, IaC-pattern compliance, evidence freshness, and deployed configuration are continuously within tolerance.
• Drift automatically opens an IM-Infrastructure ticket; the program does not wait for the next scheduled review to act.
• Per-archetype configuration baseline schemas are published to OpenSSF AI, CNCF AI, and OWASP, the program is a net contributor to the AI-assurance infrastructure implementation-review ecosystem.
• IR reviewer-hours per component trend down as attestation absorbs routine checks; reviewers focus on novel configurations and exception escalations.

Activities

A) Daily attestation signal for Critical-tier components

Each Critical-tier AI/HAI infrastructure component produces a daily composite attestation signal covering three dimensions:

1. IaC-pattern compliance: automated IaC-compliance scan confirms key controls are present and active in the deployed state (workload identity correctly assigned, encryption keys in KMS, rate-limit configuration active, per-tenant isolation policy intact, image pins enforced, signing policies active). Uses the IaC drift-detection tooling and admission-controller checks from IR L2, now running on a daily schedule with machine-readable output.

2. Evidence freshness: the SR-Infrastructure REM's evidence citations are checked for staleness, are the cited evidence artifacts (IaC plan output, boundary probe result, vendor admin API probe result, GPU residual-state-clearing test record) within their defined freshness window? Stale evidence opens a finding automatically. Evidence freshness windows (per SM-Infrastructure tier-treatment matrix): IaC plan ≤1 day; boundary probe ≤90 days; vendor admin API probe ≤30 days (Critical) / ≤90 days (High); GPU residual-state-clearing test ≤90 days.

3. Configuration within tolerance: deployed configuration checked against the DR-approved baseline. Tolerances defined per-control (patch versions within the same major image tag are tolerated; image family changes are not tolerated without a DR re-review; workload identity principal changes are not tolerated without a material-change review).

Attestation artifacts are machine-readable, signed, and stored in the SM-Infrastructure inventory record. They are regulator-consumable for EU AI Act Art. 9 risk-management evidence and ISO/IEC 42001 AIMS operational records.

Drift opens an IM-Infrastructure ticket automatically; the ticket carries the drift dimension (IaC-pattern compliance / evidence freshness / configuration), the specific control that failed tolerance, and a link to the DR decision record.

B) Contribute per-archetype configuration baseline schemas

Publish per-archetype IR configuration baseline schemas, defining what "correct" implementation looks like for each AI/HAI infrastructure archetype at each SM-Infrastructure tier, to: - OpenSSF AI working group, reference attestation schema for AI infrastructure implementations; machine-readable format compatible with supply-chain attestation frameworks (SLSA, in-toto). - CNCF AI Working Group, per-archetype configuration controls for AI/ML infrastructure on Kubernetes; checklist items and evidence-type definitions aligned to CNCF AI security best practices. - OWASP LLM / Agentic Top 10 infrastructure patterns, Verification function, Implementation Review stream; practitioner-level checklist items for inference endpoint, model registry, GPU fleet, orchestrator, and vector-store archetypes.

Internal practice remains aligned to the published external versions; internal-only deviations are proposed as upstream changes. Adoption tracked: citations, forks, direct acknowledgment from peer organizations, inclusion in external tooling or assessment frameworks.

C) Automated drift-to-IM escalation and post-incident attestation refinement

All IR findings (whether from daily attestation or from periodic reviews) flow into IM-Infrastructure automatically with severity and SLA pre-populated from the SM-Infrastructure L2 tier-treatment matrix. IM-Infrastructure SLA clock starts when the finding is opened; overdue Critical findings escalate to the program sponsor automatically at 50% and 100% of the SLA window.

Post-incident reviews in IM-Infrastructure that touch a configuration control automatically re-examine the IR record for the affected component, was the drift detectable earlier? What attestation rule would have caught it? The answer updates the attestation rule and the IR checklist.

Outcome Metrics (L3)

Process Metrics (leading)

• Attestation-pipeline health monitored, % Critical components producing a fresh attestation signal in the last 24 hours; on-call paged if any Critical component silent for >24 hours.
• Schema publication pipeline, at least one schema in-draft, in-review, or published at any time.
• IM escalation automation tested quarterly, confirm Critical-finding auto-escalation fires correctly for a synthetic finding.
• Post-incident IR feedback loop active, % of IM post-incident reviews that produce an attestation rule update.

Effectiveness Metrics (business value)

• IR reviewer-hours per component trending down as attestation absorbs routine checks.
• Zero Critical-tier go-live events where the DR-approved design and the deployed configuration are materially different, attestation enforces what was once a periodic audit.
• Auditor configuration-claim findings approaching zero as daily attestation corroborates internal records; regulator inquiries answered via machine-readable attestation artifacts without manual assembly.
• Configuration baseline schemas cited by peer organizations, security tooling vendors, or regulatory guidance documents.

Success Criteria

• Daily attestation operating for ≥90% of Critical-tier components across all three dimensions (IaC-pattern compliance, evidence freshness, configuration tolerance); deviations auto-opening IM tickets within 1 hour.
• Zero stale-evidence violations for Critical-tier REMs; High-tier stale-evidence rate trending down.
• Per-archetype configuration baseline schemas published to OpenSSF AI / CNCF AI / OWASP with documented external adoption.
• IR reviewer-hours per Critical component per year trending down over two consecutive quarters.

Key Success Indicators

Level 1: - Per-archetype IR checklists published, one per SM-Infrastructure archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store), covering IaC-state-matches-pattern, config-matches-DR, SR REM evidence currency, logging-event production, and per-tenant isolation confirmation; GPU fleet checklist verifies residual-state-clearing test and classification-aware scheduling probe; inference endpoint checklist verifies mTLS, per-tenant rate-limit, signed-artifact enforcement, and PII-redaction-at-logging. - Go-live, annual, and material-change review triggers wired to the SM-Infrastructure inventory; 100% of new AI/HAI infrastructure components in the last 90 days have a go-live IR record; ≥90% of active components carry a current-year IR record. - All Critical / blocker findings resolved before production cutover; High findings closed within 7 days with evidence linked; findings-aging dashboard reviewed monthly by the program sponsor. - SR REM update loop active, IR findings that reveal stale or inaccurate REM evidence trigger REM row updates before the finding is closed.

Level 2: - ≥90% of Critical-tier components under continuous drift detection (IaC drift-detection tooling, cloud-provider Config Rules / asset-inventory APIs, admission-controller policy checks, model-registry webhooks, CI/CD parameter monitoring); median detection latency ≤7 days. - Vendor admin API probes current for ≥80% of Critical/High-tier managed components on a monthly (Critical) and quarterly (High) cadence, not from one-time screenshots alone. - 100% of Critical/High-tier components with boundary probes on record in the current IR cycle, covering cross-tenant isolation, signing enforcement, rate-limit enforcement, GPU residual-state-clearing, and pipeline-gate enforcement. - Tier-cadence adherence ≥95%: Critical on semi-annual + continuous, High on annual, Medium on annual, Low on go-live + material-change.

Level 3: - ≥90% of Critical-tier components producing a daily attestation signal across all three dimensions (IaC-pattern compliance, evidence freshness, configuration tolerance); deviations auto-opening IM tickets within 1 hour. - Zero stale-evidence violations for Critical-tier REMs; evidence freshness windows enforced per the attestation pipeline. - Per-archetype configuration baseline schemas published to OpenSSF AI, CNCF AI, or OWASP with documented adoption. - IR reviewer-hours per Critical component per year trending down over two consecutive quarters as attestation absorbs routine checks.

Common Pitfalls

Level 1: - ❌ IR treated as a one-time go-live formality, no annual re-review and no material-change trigger; configuration drift accumulates silently for quarters until an audit or an incident surfaces it. - ❌ Reviewers take the DR decision record at face value without querying the IaC state or cloud-provider API, the workload identity is declared correctly in the DR record but the deployed service account was swapped to a shared long-lived key during a deploy emergency. - ❌ Per-tenant isolation "verified" by reviewing the IaC module description without running a cross-tenant probe, the isolation is declared in config but never confirmed to actually block cross-tenant access at the API layer. - ❌ GPU residual-state-clearing documented in the DR record but never tested, the IR checklist has a "residual-state-clearing: yes" box that is checked without an actual test execution and a recorded result. - ❌ Finding severity is flat, all findings treated as Medium regardless of impact, so a Critical-level GPU scheduling policy change that exposes regulated workloads sits in the same queue as a logging-format discrepancy. - ❌ Material-change trigger is not wired to SM-Infrastructure inventory events, GPU scheduling policy changes, new tenants on shared components, and rate-limit removals ship to production without triggering an IR.

Level 2: - ❌ Drift-detection pipeline ingests IaC state events but generates no findings on deltas, the pipeline exists but automated finding creation was never configured; drift detection is manual in practice. - ❌ Vendor admin API probing is configured once at onboarding and never re-run, a rate-limit policy reset by a vendor platform update is undetected for months. - ❌ Boundary probing is documented as "verified at go-live" but never repeated, GPU residual-state-clearing and cross-tenant isolation may have regressed at a subsequent configuration change; the go-live test is the only record. - ❌ Tier-calibrated cadence exists on paper but Critical and Low-tier components sit in the same review queue with no prioritization, Critical-tier components wait behind Low-tier backlogs. - ❌ Drift findings from automated detection dead-end in an alert dashboard rather than auto-opening IM tickets, findings age without owners.

Level 3: - ❌ Daily attestation signals show green across all Critical components but the underlying checks cover only logging volume, workload identity state, per-tenant isolation policy, and signing enforcement are not checked; attestation is cosmetic. - ❌ Configuration baseline schemas published externally diverge from internal practice, what is published reflects the L1 checklist; internal practice has advanced to L2 tooling and boundary probing; external adopters build on a stale baseline. - ❌ Attestation-exception queue overwhelms the team because configuration tolerance thresholds are too tight, every image patch triggers a deviation; reviewers suppress the signal source rather than tune the tolerance rules. - ❌ Post-incident IR feedback loop exists in policy but never fires in practice, IM post-incident reviews do not include the IR-record re-examination step; attestation rules never update from incident learning.

Practice Maturity Questions

Level 1: 1. Is there a published, per-archetype IR checklist, one per SM-Infrastructure archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store), covering IaC-state-matches-pattern, config-matches-DR, SR REM evidence currency, logging-event production, and per-tenant isolation confirmation, with the GPU fleet checklist requiring a residual-state-clearing test record and a classification-aware scheduling probe, and the inference endpoint checklist requiring mTLS, per-tenant rate-limit, signed-artifact enforcement, and PII-redaction-at-logging verification? 2. Do 100% of new AI/HAI infrastructure components going to production in the last 90 days carry a go-live IR record, and do ≥90% of all active components carry a current-year IR record, with material-change triggers wired to SM-Infrastructure inventory events, Critical / blocker findings resolved before production, and High findings closed within 7 days with evidence linked? 3. Are findings severity-tagged and tracked in IM-Infrastructure with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR-Infrastructure REM row update before the finding is closed?

Level 2: 1. Are ≥90% of Critical-tier AI/HAI infrastructure components under continuous drift detection, via IaC drift-detection tooling, cloud-provider Config Rules / asset-inventory APIs, admission-controller policy checks, model-registry webhooks, and CI/CD parameter monitoring, with median detection latency ≤7 days and automated finding creation on material deviations? 2. Are vendor admin API probes current for ≥80% of Critical/High-tier managed components on a monthly (Critical) and quarterly (High) cadence, and are 100% of Critical/High-tier components covered by boundary probes (cross-tenant isolation, signing enforcement, rate-limit enforcement, GPU residual-state-clearing, pipeline-gate enforcement) in the current IR cycle? 3. Is tier-cadence adherence ≥95% with Critical-tier findings aged per the SM-Infrastructure L2 tier-treatment matrix SLAs, and is the drift-detection pipeline wired to auto-open IR findings (not just alert dashboards) for all Critical-tier components?

Level 3: 1. Are ≥90% of Critical-tier AI/HAI infrastructure components producing a daily attestation signal across all three dimensions (IaC-pattern compliance, evidence freshness, configuration tolerance), with deviations auto-opening IM-Infrastructure tickets within 1 hour and zero stale-evidence violations for Critical-tier REMs? 2. Has the program published per-archetype configuration baseline schemas to OpenSSF AI, CNCF AI Working Group, or OWASP LLM / Agentic Top 10 infrastructure patterns, with documented adoption and internal practice aligned to the published versions, and is IR reviewer-hours per Critical component per year trending down over two consecutive quarters? 3. Is the post-incident IR feedback loop operational, IM-Infrastructure post-incident reviews include a mandatory IR-record re-examination step, and at least one attestation rule update is produced per material incident, ensuring incident learning continuously improves attestation coverage?

Document Version: HAIAMM v3.0 Practice: Implementation Review (IR) Domain: Infrastructure Last Updated: 2026-05-14 Author: Verifhai