Strategy & Metrics (SM)

Infrastructure Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/SM-Infrastructure-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Governance

Objective: Stand up AI infrastructure assurance, inventory every place models are served, stored and trained, and baseline the metrics that prove shadow AI infrastructure is shrinking.

Description: A program at this level knows where its models actually run. One inventory covers all seven infrastructure archetypes, from inference endpoints and model registries through GPU fleets, orchestrators, vector-store infrastructure, AI-specific CI/CD and feature stores. The domain's shadow-AI signal is unusually strong here because compute is expensive: an unexplained GPU spend spike or an untagged accelerator reservation is a reliable indicator of a workload nobody chartered. FinOps sits on the working group by necessity rather than courtesy, because the cost-allocation tags that make infrastructure attributable are the same tags that make the shadow-AI signal readable.

---

Maturity Level 1, Foundational

Objective: Stand up AI infrastructure assurance, inventory every place models are served, stored and trained, and baseline the metrics that prove shadow AI infrastructure is shrinking.

A program at this level knows where its models actually run. One inventory covers all seven infrastructure archetypes, from inference endpoints and model registries through GPU fleets, orchestrators, vector-store infrastructure, AI-specific CI/CD and feature stores. The domain's shadow-AI signal is unusually strong here because compute is expensive: an unexplained GPU spend spike or an untagged accelerator reservation is a reliable indicator of a workload nobody chartered. FinOps sits on the working group by necessity rather than courtesy, because the cost-allocation tags that make infrastructure attributable are the same tags that make the shadow-AI signal readable.

Dependencies

• Required: None.
• Alignment (not blocking): Existing cloud governance and landing-zone standards, so AI infrastructure inherits rather than duplicates account and network controls; FinOps cost allocation for the AI scope, which the GPU-spend shadow signal depends on
• Supports / unblocks: PC-Infrastructure-L1; TA-Infrastructure-L1; SA-Infrastructure-L1; EH-Infrastructure-L1; ML-Infrastructure-L1; IM-Infrastructure-L1; Required by: DR-Infrastructure-L1, EG-Infrastructure-L1, IR-Infrastructure-L1, SM-Infrastructure-L2, SR-Infrastructure-L1, ST-Infrastructure-L1

Desired Outcomes

• Every inference endpoint, model registry, accelerator fleet, orchestrator, vector store and AI pipeline is inventoried and attributed to an owning team.
• Unsanctioned model hosting and shadow GPU workloads are detectable from cost-allocation and scheduler telemetry rather than discovered by accident.
• Accelerator capacity is attributable, so the question of who is consuming the fleet has an answer without an investigation.
• Every serving endpoint carries a known model provenance, so what is running is traceable to what was registered.
• The organization knows its concentration exposure across providers, regions and accelerator classes.

Activities

A) Charter AI infrastructure assurance with FinOps at the table

Publish a charter within the first 30 days, sponsored by the CISO jointly with the VP Infrastructure or Head of Platform Engineering. Name the seven in-scope archetypes, being inference endpoint, model registry, GPU or accelerator fleet, orchestrator and control plane, vector-store infrastructure, AI-specific CI/CD, and feature store. Seat FinOps on the working group as a standing member alongside Platform and SRE, Cloud Architecture, ML Platform, AI/ML engineering and Privacy counsel, because in this domain cost allocation is not a reporting convenience but the primary discovery instrument; an untagged accelerator reservation is both a FinOps problem and a security finding, and separating those conversations means neither side sees the whole signal. Define decision rights over who may provision accelerator capacity, who may register and promote a model, who may expose an inference endpoint beyond the cluster boundary, and who can revoke any of the three. Commit to a numeric year-one target per outcome metric.

B) Inventory the estate and read the cost signal for shadow infrastructure

Build one AI infrastructure inventory recording per asset the archetype, owning team, environment, region and residency, accelerator class and quantity, the models served or stored, network exposure, identity and access model, and links to the SA reference pattern and EH hardening baseline it claims to follow. Seed from cloud asset inventories, Kubernetes and orchestrator APIs, model registries and infrastructure-as-code state. Then run the domain's shadow-AI mechanism monthly across four signals: cloud cost-allocation data filtered to accelerator instance types, managed inference services and AI platform products, where unexplained spend or an untagged cost centre is a shadow-infrastructure candidate; scheduler and cluster telemetry showing accelerator workloads whose namespace maps to no chartered team; network egress revealing self-hosted inference endpoints reachable from outside their intended boundary; and registry reconciliation revealing models served from artifacts that were never registered. Cost is the highest-yield of the four and the cheapest to read, because it requires no new agent anywhere.

C) Baseline the infrastructure scoreboard and open the capacity ledger

Instrument and report quarterly to the sponsor: inventory coverage against discovery reconciliation, the shadow-infrastructure ratio, the share of serving endpoints whose model provenance traces to a registry entry, the share of assets carrying an owning team and a cost-allocation tag, and provider and region concentration. Open the capacity ledger recording accelerator-hours and inference cost attributed to owning team and workload, with the denominator declared per archetype, being cost per thousand inference requests for serving and cost per served model-hour for fleet capacity. Report utilisation alongside cost, because an idle reserved fleet and a saturated one cost similarly and mean opposite things. Where accelerator spend is not allocated to an owning team, record the ledger as blocked on allocation and raise the tagging standard with FinOps rather than estimating, since in this domain an unallocated bill is precisely the shadow-infrastructure signal being lost.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
AI infrastructure inventory coverage against discovery reconciliation	first reconciliation sweep	≥90% within 12 months	Inventory reconciled against cloud asset APIs, orchestrator APIs and registries
Shadow-infrastructure ratio (unsanctioned AI assets ÷ total AI assets)	first sweep result	≤10% and falling for two consecutive quarters	Inventory status field reconciled with cost and scheduler telemetry
Serving endpoints whose model provenance traces to a registry entry	first registry reconciliation	≥95%	Model registry reconciled against serving configuration; where no registry exists, the deployment manifest of each serving host, recorded at E1
AI infrastructure assets carrying an owning team and a cost-allocation tag	first tagging audit	100% of production assets	Cloud tagging compliance report joined to inventory
Provider and accelerator-class concentration for production inference	first concentration assessment	documented with a named single-point-of-failure list and a stated risk acceptance	Inventory provider and accelerator-class fields

Process Metrics (leading)

• Four-signal shadow-infrastructure sweep runs monthly with its last-run timestamp published.
• Tagging compliance checked continuously in CI against the infrastructure-as-code definitions.
• Registry-to-serving reconciliation runs weekly for production endpoints.
• Working group including FinOps meets monthly with minutes published.

Effectiveness Metrics (business value)

• Accelerator utilisation rises as capacity is attributed and idle reservations are reclaimed.
• Time to provision sanctioned AI infrastructure falls, so teams stop self-provisioning around the program.
• Documented cases where the cost signal surfaced an unsanctioned workload before any other control did.

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Inference cost per thousand requests, by serving endpoint	per 1k inference requests	denial-of-wallet at the serving layer, where request volume drains budget without degrading availability, and inefficient serving configurations that only show up when normalised by request count	Cloud cost-allocation tags joined to inference gateway request counts
Accelerator cost per served model-hour, with utilisation reported alongside	per served model-hour	idle reserved capacity and shadow GPU workloads, which are indistinguishable from legitimate demand on an absolute spend line but obvious once divided by delivered model-hours	Scheduler telemetry joined to accelerator cost-allocation tags
Unallocated AI infrastructure spend as a share of the ledger	per dollar of AI infrastructure consumption	shadow infrastructure hiding in untagged cost centres, which is simultaneously an allocation gap and the domain's single most reliable discovery signal	Cloud cost-allocation report reconciled against inventory

Level of Effort (incremental over the level below)

• Stand-up: 170 hours · Ongoing: 85 hours/quarter
• Program Manager / Practice Lead — primary, 26 days/year
• DevOps / Platform Engineer — regular, 20 days/year
• Security Architect — regular, 12 days/year
• AI/ML Engineer — low, 6 days/year
• Executive Sponsor — low, 3 days/year
• Material new tooling: Cloud tagging policy enforced in infrastructure-as-code CI, Scheduler and accelerator utilisation telemetry joined to cost data

Success Criteria

• A charter is published and jointly sponsored by the CISO and the infrastructure leader, with FinOps a standing working-group member and four provisioning decision rights named.
• One AI infrastructure inventory covers all seven archetypes at 90% coverage or better within 12 months.
• The four-signal shadow-infrastructure sweep runs monthly and the shadow ratio has fallen for two consecutive quarters.
• All production AI infrastructure assets carry an owning team and a cost-allocation tag, and provenance traces to the registry for at least 95% of serving endpoints.
• A capacity ledger is open with denominators declared per archetype and utilisation reported beside cost, or explicitly recorded as blocked on allocation.

---

Maturity Level 2, Comprehensive

Objective: Tier the AI infrastructure estate by exposure and criticality, calibrate hardening and monitoring intensity per tier, and bound accelerator and inference consumption.

At this level the estate is no longer governed uniformly. A published rubric derives a tier from network exposure, data sensitivity in flight, the criticality of what the asset serves, accelerator concentration and blast radius, and a treatment matrix states what each tier receives in isolation, identity model, egress control, monitoring and testing. Critical-tier inference endpoints carry request and spend limits with declared behaviour at the cap, because denial-of-wallet at the serving layer degrades no availability metric and therefore evades every traditional saturation alarm. Capacity concentration becomes an explicit, accepted or mitigated risk rather than an unexamined default.

Dependencies

• Required: SM-Infrastructure-L1, PC-Infrastructure-L1, TA-Infrastructure-L1
• Alignment (not blocking): Enterprise cloud tiering and landing-zone conventions
• Supports / unblocks: PC-Infrastructure-L2; TA-Infrastructure-L2; SR-Infrastructure-L2; SA-Infrastructure-L2; DR-Infrastructure-L2; IR-Infrastructure-L2; ST-Infrastructure-L2; EH-Infrastructure-L2; IM-Infrastructure-L2; ML-Infrastructure-L2; Required by: EG-Infrastructure-L2, SM-Infrastructure-L3

Desired Outcomes

• Every AI infrastructure asset carries a tier derived from exposure, data sensitivity, criticality, concentration and blast radius.
• Hardening, identity, egress and monitoring intensity are differentiated per tier and enforced rather than recommended.
• Critical-tier inference endpoints operate under request and spend limits with a defined and tested behaviour at the limit.
• Provider, region and accelerator-class concentration is an explicitly accepted or mitigated position rather than a default.
• The scoreboard reports per tier, so a Critical-tier gap is not absorbed by healthy aggregate coverage.

Activities

A) Publish the infrastructure risk-tier rubric

Derive four tiers from five auditable dimensions. Network exposure is the strongest: an inference endpoint reachable from the public internet is Critical or High regardless of what it serves, because reachability is what converts every other weakness into an incident. Data sensitivity in flight elevates where regulated or customer-confidential content passes through the asset at inference or training. Criticality of the served workload elevates where the asset is on a revenue path, a customer-onboarding flow or an authentication decision. Concentration elevates where the asset is the single point of failure for a production AI capability, or where a provider, region or accelerator class carries a disproportionate share of production inference. Blast radius elevates where a compromise reaches beyond the asset, which applies particularly to orchestrators and control planes whose credentials command the fleet. Publish the rubric with its derivation rule and re-derive automatically when exposure or served-workload fields change, since infrastructure exposure changes faster than infrastructure inventory does.

B) Calibrate hardening intensity and consumption limits per tier

Publish a tier-treatment matrix covering, per tier: tenancy and isolation model from shared to dedicated; identity model, moving toward no standing human access on Critical-tier fleets with time-bound elevation; egress control from monitored to explicit allowlist; secrets management and rotation cadence; hardening baseline and its drift-detection cadence; monitoring detections and log completeness; testing obligations; and re-review triggers on material change. Add the consumption row that this domain needs more than any other: Critical- and High-tier inference endpoints carry per-tenant request rate limits and spend limits with a declared behaviour at the limit, being shed, queue or refuse, and never silently continue. Denial-of-wallet at the serving layer is invisible to availability monitoring by construction, so the limit is the control and its at-cap behaviour must be tested like any other boundary. Treat a capacity change, a model swap, a region change or a retention reduction on a Critical-tier asset as a material change triggering re-review, including when the motivation was cost.

C) Report per tier and manage concentration explicitly

Report the scoreboard per tier and archetype quarterly. Cover inventory and tier state, shadow-infrastructure ratio per tier, tagging and provenance conformance, hardening-baseline drift, per-tier service-level adherence, and the Assured Spend Ratio for accelerator and inference consumption per tier with full attribution targeted at Critical. Produce a standing concentration statement naming, for production inference, the share carried by each provider, each region and each accelerator class, together with the single points of failure that follow and an explicit decision to accept, mitigate or migrate each one, signed by the sponsor. Concentration in this domain is usually the result of accumulated convenience rather than a decision anyone made, and writing it down is what converts it into a governed position. Maintain a tier-movement log recording the triggering dimension for each change, and review it quarterly.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
AI infrastructure assets carrying a current tier assignment	L1 inventory coverage	100% of production assets, with tier age under 6 months	Inventory tier field
Critical-tier assets conforming to the tier hardening baseline	first baseline conformance scan	≥95%, with drift remediated inside the tier window	Configuration drift detection against the hardening baseline
Critical- and High-tier inference endpoints with request and spend limits and tested at-cap behaviour	first limit audit	100% of Critical, ≥90% of High	Gateway limit configuration reconciled against inventory tier; where no AI gateway is deployed, provider-side usage and limit configuration read per provider account, recorded at E1
Standing human access to Critical-tier accelerator fleets and control planes	first access review	0 standing human identities, with time-bound elevation only	Cloud IAM and cluster RBAC review
Per-tier service-level adherence across hardening, monitoring, testing and issue management	first quarter of per-tier telemetry	≥90% per tier	Program telemetry from each practice's log
Assured Spend Ratio for accelerator and inference consumption at Critical tier	L1 ledger baseline	100% of Critical-tier consumption attributed	Capacity ledger joined to inventory tier

Process Metrics (leading)

• Tier re-derivation triggers automatically on exposure or served-workload change, and each run is logged.
• Hardening-baseline drift detection runs continuously for Critical tier and at least weekly for High.
• Concentration statement refreshed quarterly and signed by the sponsor.
• Cost-driven configuration changes on Critical-tier assets routed to re-review within the tier window.

Effectiveness Metrics (business value)

• Reviewer and engineering effort concentrates on Critical and High tiers relative to L1.
• Accelerator utilisation rises at Low and Medium tiers as capacity is pooled rather than reserved per team.
• Documented cases where a per-tenant spend limit contained a denial-of-wallet attempt that availability monitoring did not register.

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Inference cost per thousand requests at Critical tier against the endpoint's rolling median	per 1k inference requests	denial-of-wallet at the serving layer, which drains budget while uptime, latency and error rate all stay green and therefore trips no conventional alarm	Gateway request telemetry joined to cost-allocation tags
Spend-limit breach rate and at-cap behaviour conformance per tier	per endpoint-quarter	limits that are configured but silently continue past the cap, which is functionally equivalent to having no limit at all	Gateway limit enforcement log
Accelerator cost per served model-hour by tier, with utilisation	per served model-hour	capacity concentration and idle reservation at high tiers, where the cost of resilience is paid without the resilience being verified	Scheduler telemetry joined to capacity ledger and inventory tier

Level of Effort (incremental over the level below)

• Stand-up: 150 hours · Ongoing: 120 hours/quarter
• Program Manager / Practice Lead — primary, 22 days/year
• DevOps / Platform Engineer — regular, 25 days/year
• Security Architect — regular, 15 days/year
• AppSec / SecEng — low, 6 days/year
• Executive Sponsor — low, 3 days/year
• Material new tooling: Per-tenant request and spend limiting at the inference gateway, Continuous configuration-drift detection against tier hardening baselines

Success Criteria

• A tier rubric is published and applied to 100% of production assets, re-derived automatically on exposure change.
• A tier-treatment matrix is published covering tenancy, identity, egress, secrets, hardening, monitoring and testing, and downstream Infrastructure L2 practices are calibrated to it.
• Every Critical-tier inference endpoint carries request and spend limits with a tested at-cap behaviour.
• Standing human access to Critical-tier fleets and control planes stands at zero, with time-bound elevation only.
• A sponsor-signed concentration statement names provider, region and accelerator-class exposure with an explicit accept, mitigate or migrate decision per single point of failure.

---

Maturity Level 3, Industry-Leading

Objective: Drive infrastructure inventory and tiering from live cloud and orchestrator signals, benchmark serving unit economics externally, and contribute infrastructure assurance patterns back.

At this level the estate describes itself. Inventory, tier and provenance derive from cloud asset events, orchestrator admission telemetry, registry events and billing feeds, with a published latency objective and exception-based human review. Serving unit economics are benchmarked against peers, which is the only reliable way to tell an efficient configuration from a familiar one, and the program contributes hardened infrastructure-as-code patterns back to the communities it draws from. The domain return is computed from the capacity ledger rather than narrated, covering contained denial-of-wallet, reclaimed idle reservation and avoided commitment overage.

Dependencies

• Required: SM-Infrastructure-L2, ML-Infrastructure-L2, EG-Infrastructure-L2
• Alignment (not blocking): FinOps at Run maturity for accelerator and inference cost attribution
• Supports / unblocks: Every other Infrastructure-domain practice at L3, which inherits automated inventory and tier data

Desired Outcomes

• Inventory, tier and model provenance are derived from cloud, orchestrator and registry events rather than curated.
• The freshness of the infrastructure picture is a published latency objective rather than a function of the audit calendar.
• Serving and accelerator unit economics are benchmarked against named peers rather than only against the program's own history.
• Hardened infrastructure-as-code patterns are published and adopted outside the organization.
• Domain return is computed from the capacity ledger and reconciled with Finance.

Activities

A) Automate inventory, tier and provenance from live signals

Derive the estate picture from the control planes that already emit it: cloud asset and configuration events for creation, modification and deletion of AI infrastructure; orchestrator admission telemetry for workloads requesting accelerators; model-registry events for registration, promotion and deprecation; infrastructure-as-code state changes; network exposure changes from security-group and ingress events; and provider billing feeds for cost attribution and new-tag appearance. Implement tier derivation as a versioned, replayable rule set over the L2 dimensions, and wire tier changes to open downstream obligations automatically so that an endpoint newly exposed to the internet triggers its hardening, monitoring and testing obligations without waiting on a human to notice the security-group change. Publish a data-quality service-level objective covering tier correctness within 24 hours of an exposure change, which is tighter than the other domains warrant because infrastructure exposure changes in seconds and its consequences are immediate. Reserve human curation for novel archetypes, ambiguous ownership and conflicting dimensional inputs.

B) Benchmark serving unit economics and hardening posture externally

Publish a semi-annual brief comparing the program against named peers on at least five metrics: inventory coverage and freshness, shadow-infrastructure ratio, hardening-baseline conformance, inference cost per thousand requests by serving archetype, and accelerator cost per served model-hour with utilisation. Unit economics carry particular weight in this domain because serving configurations are optimised continuously and rarely re-reviewed; a cost per thousand requests well below the peer median may indicate efficient batching, or it may indicate that per-request authorization, logging and content filtering were removed to hit a savings target. Report cost and control coverage together so that the comparison cannot be read as a pure efficiency ranking. Draw from CNCF AI and ML working groups, OpenSSF AI supply-chain work, the FinOps Foundation AI scope, sector information-sharing bodies and ML-platform community forums. Name the peer cohort and record where the program trails.

C) Publish hardened patterns and compute the domain return

Contribute at least four substantive artifacts per year, weighted toward executable rather than descriptive ones: hardened infrastructure-as-code modules for inference serving, registry and vector-store deployment published through OpenSSF AI or CNCF; accelerator-fleet identity and isolation patterns; provenance-verification tooling for registry-to-serving reconciliation; observed infrastructure-layer techniques submitted to MITRE ATLAS; and FinOps Foundation AI-scope contributions on capacity governance and concentration risk. Count only what external bodies accept. Compute the domain return from the capacity ledger: contained denial-of-wallet events valued at burn rate multiplied by time to detect; reclaimed idle reservation, which is usually the largest single component and the easiest to verify; avoided commitment overage under governed capacity planning; and capacity reclaimed by retiring endpoints serving no traffic. Reconcile with Finance annually and publish alongside the Assurance Cost Ratio for the domain.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Inventory and tier auto-update latency after an exposure change	L2 review cycle time	≤24 hours at the 99th percentile	Cloud and orchestrator event pipeline telemetry
Inventory entries auto-curated rather than human-curated	first quarter of automation telemetry	≥85% auto-curated	Curation telemetry from the inventory pipeline
Model provenance verified automatically from registry to running serving configuration	L2 weekly reconciliation result	≥99% of production endpoints, verified continuously	Continuous registry-to-serving reconciliation job
Peer-comparable metrics in the semi-annual brief, reported with control coverage alongside cost	0	≥5 metrics with a named and defended peer cohort	Published benchmarking brief
Externally accepted infrastructure assurance contributions per year	0	≥4 accepted, weighted toward executable artifacts	Contribution log with external acceptance references

Process Metrics (leading)

• Event-feed freshness and error rate monitored, with on-call paged on staleness breach.
• Tier-rule changes versioned, replayable and reviewed quarterly.
• Continuous provenance reconciliation runs on every serving-configuration change.
• Contribution pipeline carries at least two artifacts in draft or external review.

Effectiveness Metrics (business value)

• Sponsor capacity and budget decisions cite benchmark deltas and per-tier utilisation rather than narrative.
• Serving unit cost converges toward or beats the peer median without a fall in control coverage.
• Computed domain return reconciles with Finance annually without restatement.
• External adoption of published infrastructure-as-code modules by peer organizations.

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Inference cost per thousand requests benchmarked against the peer cohort, reported with control coverage	per 1k inference requests	a cost advantage that reflects removed authorization, logging or filtering rather than efficient serving, which a cost-only comparison actively rewards	Capacity ledger compared against the semi-annual benchmarking brief
Reclaimed idle accelerator reservation	per served model-hour	reserved capacity paid for and never delivered against, which is the largest and most verifiable component of this domain's return and is invisible on an absolute spend line	Scheduler utilisation telemetry joined to reservation cost records
Contained denial-of-wallet value: burn rate multiplied by time to detect	per contained event	serving-layer budget drain running long because no availability signal degrades, making detection time the whole of the loss	Gateway limit enforcement log joined to the capacity ledger

Level of Effort (incremental over the level below)

• Stand-up: 230 hours · Ongoing: 75 hours/quarter
• Program Manager / Practice Lead — primary, 16 days/year
• DevOps / Platform Engineer — regular, 28 days/year
• Security Architect — regular, 12 days/year
• Compliance / Audit — low, 4 days/year
• Executive Sponsor — low, 2 days/year
• Material new tooling: Event pipeline joining cloud asset, orchestrator, registry and billing feeds, Continuous registry-to-serving provenance verification

Success Criteria

• Inventory, tier and provenance are event-derived with at least 85% auto-curation and a published latency objective of 24 hours on exposure change, met at the 99th percentile.
• Model provenance is verified continuously from registry to serving configuration for at least 99% of production endpoints.
• A semi-annual benchmarking brief covers at least five peer-comparable metrics reporting cost and control coverage together, with the peer cohort named and defended.
• At least four externally accepted contributions per year, weighted toward executable infrastructure-as-code artifacts.
• Domain return is computed from capacity-ledger arithmetic, reconciled with Finance, and published with the domain Assurance Cost Ratio.

---

Key Success Indicators

Level 1:

• A charter is published and jointly sponsored by the CISO and the infrastructure leader, with FinOps a standing working-group member and four provisioning decision rights named.
• One AI infrastructure inventory covers all seven archetypes at 90% coverage or better within 12 months.
• The four-signal shadow-infrastructure sweep runs monthly and the shadow ratio has fallen for two consecutive quarters.
• All production AI infrastructure assets carry an owning team and a cost-allocation tag, and provenance traces to the registry for at least 95% of serving endpoints.
• A capacity ledger is open with denominators declared per archetype and utilisation reported beside cost, or explicitly recorded as blocked on allocation.

Level 2:

• A tier rubric is published and applied to 100% of production assets, re-derived automatically on exposure change.
• A tier-treatment matrix is published covering tenancy, identity, egress, secrets, hardening, monitoring and testing, and downstream Infrastructure L2 practices are calibrated to it.
• Every Critical-tier inference endpoint carries request and spend limits with a tested at-cap behaviour.
• Standing human access to Critical-tier fleets and control planes stands at zero, with time-bound elevation only.
• A sponsor-signed concentration statement names provider, region and accelerator-class exposure with an explicit accept, mitigate or migrate decision per single point of failure.

Level 3:

• Inventory, tier and provenance are event-derived with at least 85% auto-curation and a published latency objective of 24 hours on exposure change, met at the 99th percentile.
• Model provenance is verified continuously from registry to serving configuration for at least 99% of production endpoints.
• A semi-annual benchmarking brief covers at least five peer-comparable metrics reporting cost and control coverage together, with the peer cohort named and defended.
• At least four externally accepted contributions per year, weighted toward executable infrastructure-as-code artifacts.
• Domain return is computed from capacity-ledger arithmetic, reconciled with Finance, and published with the domain Assurance Cost Ratio.

---

Common Pitfalls

Level 1:

• ❌ Treating cost allocation as a finance concern, which discards the domain's cheapest and highest-yield shadow-infrastructure signal.
• ❌ Inventorying managed inference services while missing self-hosted models running on general-purpose compute, which carry no accelerator signature.
• ❌ Reconciling the registry against serving configuration annually, so a model swapped in production drifts from what was registered and tested for months.
• ❌ Reporting accelerator spend without utilisation, so an idle reserved fleet and a saturated one look identical in the scoreboard.
• ❌ Accepting untagged AI spend as a permanent condition rather than raising it as a blocking allocation gap with the FinOps practice.

Level 2:

• ❌ Tiering by data sensitivity alone while ignoring network exposure, which is the dimension that converts every other weakness into a reachable one.
• ❌ Configuring rate limits without spend limits, which stops request floods but not the expensive-generation variant of denial-of-wallet.
• ❌ Declaring a limit without testing its at-cap behaviour, so the first time anyone learns what happens at the cap is during the incident.
• ❌ Leaving concentration as an accumulated default rather than a signed position, so nobody ever decided to depend this heavily on one provider.
• ❌ Exempting cost-driven capacity and model changes from change governance because they arrived through a savings initiative rather than a feature request.

Level 3:

• ❌ Automating inventory from cloud events while leaving network exposure changes on a slower path, which misses the dimension that matters most and moves fastest.
• ❌ Benchmarking serving cost without reporting control coverage, which rewards the peer who removed the most controls.
• ❌ Publishing infrastructure patterns as documentation rather than as executable modules, which peers cannot adopt and therefore do not.
• ❌ Computing return from reclaimed reservation without verifying that the reclaimed capacity was not simply re-reserved elsewhere under a different tag.
• ❌ Setting a 48-hour tier latency objective borrowed from another domain, when infrastructure exposure changes in seconds and its consequences are immediate.

---

Practice Maturity Questions

Level 1:

1. Is there a published AI infrastructure assurance charter jointly sponsored by the CISO and the infrastructure leader, with FinOps as a standing working-group member and explicit decision rights over provisioning accelerator capacity, registering models and exposing inference endpoints?
2. Does one inventory cover all seven infrastructure archetypes, reconciled monthly against cloud cost-allocation data, scheduler telemetry, network egress and registry records, reaching 90% coverage or better of discovered assets within 12 months?
3. Do all production AI infrastructure assets carry an owning team and cost-allocation tag, does model provenance trace to a registry entry for at least 95% of serving endpoints, and is a capacity ledger open reporting utilisation alongside denominated cost?

Level 2:

1. Is every production AI infrastructure asset assigned a tier from a published rubric covering network exposure, data sensitivity in flight, served-workload criticality, concentration and blast radius, re-derived automatically when exposure changes?
2. Is there a published tier-treatment matrix covering tenancy and isolation, identity model, egress control, secrets, hardening baseline, monitoring and testing, with at least 95% of Critical-tier assets conforming to their hardening baseline and drift remediated inside the tier window?
3. Do all Critical-tier inference endpoints carry per-tenant request and spend limits with tested at-cap behaviour, and is there a sponsor-signed concentration statement recording an explicit accept, mitigate or migrate decision for each single point of failure?

Level 3:

1. Do inventory, tier and provenance auto-update from cloud asset, orchestrator admission, registry, infrastructure-as-code and billing events against a published objective of tier correctness within 24 hours of an exposure change, with at least 85% of curation automated?
2. Does the semi-annual benchmarking brief compare at least five peer-comparable metrics including inference cost per thousand requests and accelerator cost per served model-hour, reporting control coverage alongside cost so efficiency cannot be confused with removed controls?
3. Does the program contribute at least four externally accepted infrastructure assurance artifacts per year weighted toward executable modules, and is the domain return computed from capacity-ledger arithmetic covering contained denial-of-wallet, reclaimed idle reservation and avoided overage?

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Do you know every place a model is being served in your environment?
• Would an unexplained GPU spend spike reach a security person?
• Can every production inference endpoint be traced to a registered model?

Level 2:

• Does every AI infrastructure asset carry a risk tier?
• Is there a spend limit on your most exposed inference endpoint?
• Does anyone hold standing admin access to your GPU fleet?

Level 3:

• Does your AI infrastructure inventory update itself from cloud events?
• Do you know how your inference cost per thousand requests compares with peers?
• Have you published a hardened AI infrastructure pattern externally this year?

---

Tracking

Level 1 — Jira Epic, labels haiamm-sm-infrastructure-l1, haiamm-governance

• Done when: Inventory coverage at or above 90% with zero untagged production AI infrastructure assets and endpoint provenance at or above 95%, sustained across two consecutive quarters.
• Git artifacts: infra/ai-inventory.json, infra/tagging-policy.yaml, governance/ai-infrastructure-charter.md, finops/capacity-ledger.json
• Git signal: ai-inventory.json is regenerated by the monthly discovery job from cloud and orchestrator APIs, and tagging-policy.yaml is enforced by a blocking infrastructure-as-code CI check.
• CI check: ai-infra-tagging-compliance

Level 2 — Jira Epic, labels haiamm-sm-infrastructure-l2, haiamm-governance

• Done when: Tier coverage at 100% of production assets with zero standing human access to Critical-tier fleets and every Critical endpoint carrying a tested spend limit, held across two consecutive quarters.
• Git artifacts: infra/tier-rubric.md, infra/tier-treatment-matrix.md, infra/hardening-baselines/, gateway/limit-config.yaml, governance/concentration-statement.md
• Git signal: limit-config.yaml changes are gated by a CI check asserting that every Critical-tier endpoint has both a request and a spend limit with a declared at-cap behaviour.
• CI check: endpoint-limit-audit

Level 3 — Jira Epic, labels haiamm-sm-infrastructure-l3, haiamm-governance

• Done when: Tier latency within 24 hours at the 99th percentile on exposure change, auto-curation at or above 85% and provenance verification at or above 99%, sustained two quarters.
• Git artifacts: infra/pipeline/, infra/tier-rules.versioned.json, governance/benchmarking-brief.md, governance/contribution-log.json, finops/return-computation.json
• Git signal: tier-rules.versioned.json carries a monotonic version with a replay test in CI, and provenance reconciliation runs on every serving-configuration change rather than on a schedule.
• CI check: infra-provenance-continuous

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	EA	AML.T0010, AML.T0029, AML.T0035, AML.T0044, AML.T0049, AML.T0055	LLM03, LLM10	EU AI Act Art. 15; ISO/IEC 27001 A.5.9; ISO/IEC 42001 8.1; NIST AI RMF MANAGE 2.2; NIST AI RMF MAP 1.1
L2	EA, TM	AML.T0024, AML.T0029, AML.T0035, AML.T0044, AML.T0049, AML.T0055	LLM03, LLM10	EU AI Act Art. 15; ISO/IEC 27001 A.5.9; ISO/IEC 42001 8.1; NIST AI RMF MANAGE 2.2; NIST AI RMF MEASURE 2.6
L3	EA, TM	AML.T0010, AML.T0024, AML.T0029, AML.T0035, AML.T0044, AML.T0049, AML.T0055	LLM03, LLM10	EU AI Act Art. 15; EU AI Act Art. 72; ISO/IEC 27001 A.5.9; ISO/IEC 42001 9.1; NIST AI RMF MEASURE 2.6

---

Document Version: HAIAMM v3.5 (generated) / Practice: Strategy & Metrics (SM) / Domain: Infrastructure