Policy & Compliance (PC)

Infrastructure Domain - HAIAMM v3.5

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

---

Practice Overview

Business Function: Governance

Objective: Publish the priority compliance map and the minimum policy stack governing the infrastructure AI/HAI systems run on, so every obligation reaches a named policy and a named owner.

Description: A program at this level has written down which rules apply to the infrastructure AI/HAI systems run on and who answers for each. A one-page priority compliance map traces every in-scope obligation to a policy clause and an evidence artifact, so a regulator asking how a given article is addressed reaches one row, one policy and one piece of evidence rather than a research project. The AI Infrastructure Standard is published, acknowledged by the in-scope population, and specific enough to be violated, which is the test that separates a policy from a statement of values.

---

Maturity Level 1, Foundational

Objective: Publish the priority compliance map and the minimum policy stack governing the infrastructure AI/HAI systems run on, so every obligation reaches a named policy and a named owner.

A program at this level has written down which rules apply to the infrastructure AI/HAI systems run on and who answers for each. A one-page priority compliance map traces every in-scope obligation to a policy clause and an evidence artifact, so a regulator asking how a given article is addressed reaches one row, one policy and one piece of evidence rather than a research project. The AI Infrastructure Standard is published, acknowledged by the in-scope population, and specific enough to be violated, which is the test that separates a policy from a statement of values.

Dependencies

• Required: SM-Infrastructure-L1
• Alignment (not blocking): Enterprise policy management and the existing security policy stack, so AI policy is an extension rather than a parallel library
• Supports / unblocks: TA-Infrastructure-L1; SR-Infrastructure-L1; DR-Infrastructure-L1; IR-Infrastructure-L1; IM-Infrastructure-L1; ML-Infrastructure-L1 (retention requirements); Required by: EG-Infrastructure-L1, EH-Infrastructure-L1, PC-Infrastructure-L2, SM-Infrastructure-L2

Desired Outcomes

• Every in-scope obligation governing the infrastructure AI/HAI systems run on traces to a policy clause, an owner and an evidence artifact on one page.
• The AI Infrastructure Standard is published, acknowledged, and written so that a violation is identifiable rather than arguable.
• Policy exceptions are recorded with a rationale, an owner and an expiry date rather than granted informally.
• The in-scope population knows which rules apply to them without reading the full policy stack.
• A regulator or auditor question reaches a single map row rather than an internal investigation.

Activities

A) Publish the priority compliance map

Produce a one-page priority compliance map covering the obligations that actually apply to the infrastructure AI/HAI systems run on: EU AI Act Art. 15 accuracy robustness and cybersecurity; ISO/IEC 27001 A.8; ISO/IEC 42001 8.1; NIST AI RMF MANAGE 2.2; GDPR Art. 32 security, plus any sector-specific rules in scope. Each row names the obligation, the specific clause of the internal policy that implements it, the accountable owner, the evidence artifact that demonstrates conformance, and the practice that produces that evidence. The map is one page by design. A compliance register of two hundred rows is a document nobody reads and nobody maintains, whereas a one-page map that traces the obligations a regulator is actually likely to ask about is a document that survives contact with an audit. Review it quarterly and whenever a new obligation enters scope, and treat an obligation with no named evidence artifact as an open finding rather than as a row to be filled in later.

B) Publish the AI Infrastructure Standard and the supporting policy stack

Publish an AI Infrastructure Standard covering permitted hosting regions and residency, accelerator provisioning authority, model registration and promotion requirements, inference endpoint exposure rules, and the hardening baseline each archetype must meet. Write each requirement so that conformance is observable: a rule stating that AI must be used responsibly cannot be assessed, whereas a rule naming the seven infrastructure archetypes, being inference endpoint, model registry, accelerator fleet, orchestrator and control plane, vector-store infrastructure, AI-specific CI/CD and feature store and stating what is permitted for each can be. Route the policy through the same approval and review cycle as the enterprise security policy stack rather than creating a parallel governance path, and set an explicit review interval of at most 12 months. Publish a short summary aimed at the population that must follow it, because a policy that requires reading twenty pages to answer a five-second question will be guessed at instead. Establish an exception process with a named approver, a required rationale, a mandatory expiry date and a register, since undocumented exceptions are how policy stacks quietly become fiction.

C) Attest the population and baseline conformance

Run an attestation campaign across the in-scope population, delivered through the existing human resources or learning system so that completion is recorded where compliance evidence already lives. Track coverage as a percentage of the in-scope population rather than as a count of completions, because the denominator is what an auditor asks for. Baseline three conformance measures in the first quarter: the share of obligations on the map carrying a named evidence artifact, the share of the population with a current acknowledgement, and the count of active exceptions with their age distribution. Reconcile the map against infrastructure-as-code definitions and cloud configuration state to confirm that what the policy requires is what the environment actually does, and record every divergence as a finding with an owner rather than as a note. Report all three to the executive sponsor quarterly.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
Priority compliance map obligations carrying a named policy clause, owner and evidence artifact	first map publication	100% of mapped obligations within 6 months	Priority compliance map reviewed against the policy stack
In-scope population with a current acknowledgement of the AI Infrastructure Standard	first attestation run	≥95% of the in-scope population	HR / LMS attestation records
Active policy exceptions carrying a rationale, named approver and expiry date	first exception register review	100%, with zero exceptions past expiry	Exception register
Policy requirements reconciled against the operating environment	first reconciliation pass	≥90% of requirements verified against infrastructure-as-code definitions and cloud configuration state, with divergences raised as findings	Reconciliation report joined to the issue tracker
Obligations on the map with no evidence-producing practice identified	first map publication	0	Priority compliance map coverage review

Process Metrics (leading)

• Compliance map reviewed quarterly and whenever a new obligation enters scope.
• Policy review interval of at most 12 months honoured, with the review date published.
• Exception register reviewed monthly and expired exceptions closed or renewed within 10 business days.
• Attestation campaign re-run at least annually and on material policy change.

Effectiveness Metrics (business value)

• Time to answer a regulator or auditor question about a specific obligation falls, measured from request to evidence delivered.
• Exception volume falls as the policy is refined to match what teams actually need, rather than exceptions becoming the normal path.
• Documented cases where the map surfaced an obligation with no owner before an audit did.

Level of Effort (incremental over the level below)

• Stand-up: 120 hours · Ongoing: 60 hours/quarter
• Program Manager / Practice Lead — primary, 22 days/year
• Legal / Privacy Counsel — regular, 14 days/year
• Compliance / Audit — regular, 12 days/year
• Executive Sponsor — low, 3 days/year

Success Criteria

• A one-page priority compliance map is published, tracing every in-scope obligation to a policy clause, an owner and an evidence artifact.
• The AI Infrastructure Standard is published with an explicit review interval of at most 12 months and written so that violations are identifiable.
• At least 95% of the in-scope population holds a current acknowledgement.
• An exception process operates with named approvers, mandatory expiry dates and a reviewed register carrying no expired entries.
• Policy requirements are reconciled against infrastructure-as-code definitions and cloud configuration state, with every divergence raised as a finding with an owner.

---

Maturity Level 2, Comprehensive

Objective: Calibrate policy depth and evidence requirements to the risk tier of each infrastructure asset, and assemble tier-specific evidence packs that can be produced on demand.

At this level policy stops applying uniformly. Requirements and evidence obligations scale with the tier assigned by SM L2, so a Critical-tier asset carries deeper controls, tighter review cycles and a fuller evidence pack than a Low-tier one, and the difference is published rather than negotiated per case. Evidence packs are assembled continuously rather than at audit time, which is the difference between a programme that can answer a regulator in days and one that treats every enquiry as a project. Control mappings run both ways, so a control failure names the obligations it puts at risk.

Dependencies

• Required: PC-Infrastructure-L1, SM-Infrastructure-L2
• Alignment (not blocking): Internal audit planning, so evidence packs serve both regulatory and audit demand
• Supports / unblocks: TA-Infrastructure-L2; SR-Infrastructure-L2; DR-Infrastructure-L2; IR-Infrastructure-L2; ST-Infrastructure-L2; IM-Infrastructure-L2; ML-Infrastructure-L2; Required by: PC-Infrastructure-L3

Desired Outcomes

• Policy requirements and evidence obligations differ by tier, and the difference is published rather than decided case by case.
• Every Critical- and High-tier asset has an evidence pack that can be produced within a stated service level.
• Control mappings run in both directions, so a failing control names the obligations it jeopardises.
• Exceptions at Critical tier require a higher approval authority than at Low tier, and are reviewed more often.
• Regulatory change reaches the affected assets through a defined path rather than through whoever happened to read the update.

Activities

A) Calibrate policy requirements per tier

Extend the L1 policy stack with tier-differentiated requirements keyed to the SM L2 rubric. For each requirement, state what Critical, High, Medium and Low each owe: which controls are mandatory versus recommended, what review cadence applies, what approval authority an exception requires, and what evidence must exist. A Critical-tier the infrastructure AI/HAI systems run on might owe a documented conformance assessment, an annual independent review and a named accountable executive, where a Low-tier one owes an intake record and an annual self-attestation. Publishing the difference is what prevents the two failure modes that follow from uniform policy: either every asset carries Critical-tier burden, which makes the policy unenforceable and drives teams around it, or every asset carries Low-tier burden, which leaves the Critical ones under-governed. Route tier-calibrated requirements through the same approval cycle as the base policy. In this domain tier calibration turns mainly on exposure and residency: an internet-reachable inference endpoint in a third country carries obligations that an internal batch-scoring host does not, and the difference is a property of the deployment rather than the model.

B) Build bidirectional control mappings and tier-specific evidence packs

Map each obligation on the priority compliance map to the specific controls that satisfy it, and map each control back to the obligations that depend on it. The reverse direction is the one usually missing and the one that matters operationally: when a control fails or is deferred, the programme needs to state immediately which obligations are now unevidenced, rather than discovering it during the next audit. Assemble an evidence pack per tier specifying exactly which artifacts constitute conformance, drawn from infrastructure-as-code definitions and cloud configuration state and from the outputs of TA, SR, DR, IR, ST and ML. Automate collection where the artifact already exists in a system of record, and set a service level for producing a complete pack on request, targeting 10 business days at Critical tier. An evidence pack assembled only when asked for is a pack that will be incomplete the one time it matters. The evidence pack for infrastructure draws on infrastructure-as-code definitions, cloud configuration state and change records, all of which are machine-readable and therefore the cheapest evidence in the model to automate.

C) Operate regulatory change management and tiered exceptions

Establish a defined path from a regulatory change to the assets it affects. Assign a named owner to monitor the in-scope obligation sources, assess each change for applicability within 30 days of publication, identify the affected assets by tier, and open remediation work items with owners and dates. Without this, regulatory change arrives through whoever happens to read an update, which is neither reliable nor auditable. Calibrate the exception process by tier: a Critical-tier exception requires executive approval, a shorter maximum duration and quarterly review, where a Low-tier exception can be approved by the practice lead with an annual review. Report exception volume and age by tier to the sponsor, and treat a rising Critical-tier exception count as a signal that the policy is mis-calibrated rather than that teams are non-compliant. Regulatory change in this domain most often arrives as accuracy, robustness and cybersecurity guidance under Art. 15, which lands on the serving and hardening configuration rather than on the application.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Policy requirements carrying a published tier calibration	L1 policy stack	100% of requirements where tier differentiation is meaningful	Policy stack tier-calibration review
Critical- and High-tier assets with a current, complete evidence pack	first evidence-pack assembly	≥95% of Critical, ≥85% of High	Evidence pack register joined to the asset inventory
Time to produce a complete evidence pack on request at Critical tier	first request exercise	≤10 business days	Evidence request log with timestamps
Obligations with a bidirectional control mapping	first mapping pass	100% of mapped obligations	Control mapping register
Regulatory changes assessed for applicability within 30 days of publication	first quarter of change tracking	100%	Regulatory change log with assessment dates
Critical-tier exceptions carrying executive approval and a review within the quarter	first tiered exception review	100%	Exception register joined to asset tier

Process Metrics (leading)

• Regulatory change sources monitored continuously by a named owner, with assessment completed within 30 days.
• Evidence packs refreshed on the tier's cadence rather than on request.
• Exception register reviewed by tier, quarterly at Critical and annually at Low.
• Control mapping updated whenever a control is added, changed or retired.

Effectiveness Metrics (business value)

• Time from regulatory enquiry to complete evidence delivery falls, reported per tier.
• Audit findings relating to missing evidence fall as packs are assembled continuously rather than on demand.
• Critical-tier exception volume and age fall as tier calibration is refined.
• Effort concentrates on Critical and High tiers relative to L1.

Level of Effort (incremental over the level below)

• Stand-up: 140 hours · Ongoing: 90 hours/quarter
• Compliance / Audit — primary, 24 days/year
• Legal / Privacy Counsel — regular, 16 days/year
• Program Manager / Practice Lead — regular, 14 days/year
• Security Architect — low, 6 days/year
• Material new tooling: Evidence collection automation against existing systems of record

Success Criteria

• Tier-calibrated policy requirements are published, stating what each tier owes in controls, cadence, approval authority and evidence.
• Evidence packs exist per tier and are refreshed on cadence, with a Critical-tier production service level of 10 business days met.
• Bidirectional control mappings are complete, so a failing control names the obligations it jeopardises.
• A named owner assesses every regulatory change for applicability within 30 days and opens remediation work items by tier.
• Exceptions are tier-calibrated in approval authority, maximum duration and review cadence, with Critical-tier volume and age reported to the sponsor.

---

Maturity Level 3, Industry-Leading

Objective: Generate compliance evidence continuously from the operating environment, prove conformance by assertion rather than assembly, and engage in the regulatory process for the infrastructure AI/HAI systems run on.

At this level compliance evidence is a by-product of running the environment rather than a separate assembly exercise. Conformance assertions are computed from infrastructure-as-code definitions and cloud configuration state continuously, so the question of whether the programme is compliant today has an answer today. The organisation participates in the regulatory process rather than only receiving its output, contributing implementation experience to consultations and standards bodies. Compliance drift is detected in days, and the evidence that would be produced for a regulator is the same evidence the programme uses to run itself.

Dependencies

• Required: PC-Infrastructure-L2, ML-Infrastructure-L2
• Alignment (not blocking): Internal audit and assurance planning, so continuous evidence serves both
• Supports / unblocks: Every other Infrastructure practice at L3, which inherits continuous conformance evidence

Desired Outcomes

• Conformance assertions are computed continuously from the operating environment rather than assembled at audit time.
• Compliance drift is detected within days of the environment diverging from the policy.
• The evidence a regulator would receive is the same evidence the programme uses to run itself.
• The organisation contributes implementation experience to the regulatory and standards process.
• Audit preparation time falls toward zero because there is nothing left to prepare.

Activities

A) Generate conformance evidence continuously

Instrument the environment so that each policy requirement has a continuously evaluated conformance assertion rather than a periodically collected artifact. Draw the signals from infrastructure-as-code definitions and cloud configuration state and from the telemetry the other practices already emit, and express each requirement as a check that returns conformant, non-conformant or not-evaluable. The third state matters and is usually omitted: a requirement that cannot be evaluated is a gap in the evidence chain, not a pass, and collapsing it into conformant is how continuous compliance dashboards become reassuring and wrong. Publish a service level covering detection of a conformance drift within 5 business days. Reserve manual attestation for requirements that are genuinely not machine-evaluable, list them explicitly, and review that list quarterly with the aim of shrinking it, since the list is the honest measure of how far the automation actually reaches.

B) Prove conformance on demand and shrink audit preparation

Convert the evidence pack from an assembled document into a generated view over the continuous assertions, so that producing it is a query rather than a project. Target production within one business day at every tier, and run unannounced internal exercises at least twice a year to verify the claim, because an evidence pipeline that has never been exercised under time pressure is an assumption. Track audit preparation effort explicitly in hours and drive it toward zero: the measure of this level is not that audits pass, which they did before, but that they cost almost nothing to prepare for. Where an external audit or regulatory enquiry does raise a finding, trace it back to the assertion that should have caught it and either fix the assertion or record why the requirement is not machine-evaluable.

C) Engage in the regulatory and standards process

Participate in the process that produces the obligations rather than only consuming its output. Submit implementation experience to consultations on EU AI Act implementing acts and successor guidance, contribute to the standards bodies developing conformance methods including ISO/IEC 42001 and the relevant national standards organisations, and share anonymised implementation patterns through sector bodies and practitioner communities. Implementation experience is the input regulators most consistently lack and most consistently ask for, which makes it the contribution with the highest leverage and the lowest cost to produce, since the programme generates it as a by-product of operating. Target at least four substantive submissions per year, count only those accepted or published, and have legal review every submission before it leaves the organisation.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Policy requirements with a continuously evaluated conformance assertion	L2 evidence pack coverage	≥85%, with the non-evaluable remainder listed explicitly	Conformance assertion registry
Time to detect a conformance drift	L2 review cadence	≤5 business days at the 90th percentile	Conformance assertion evaluation log
Time to produce a complete evidence pack at any tier	L2 achieved 10 business days	≤1 business day, verified by unannounced exercise twice a year	Evidence generation timestamps
Audit and enquiry preparation effort	L2 preparation hours per audit	falling year over year toward under 20 hours per audit	Time recorded against audit preparation work items
Accepted regulatory and standards contributions per year	0	≥4 accepted or published, with legal review completed	Contribution log with acceptance references

Process Metrics (leading)

• Conformance assertions evaluated continuously, with evaluation freshness monitored and alerted on staleness.
• Non-evaluable requirement list reviewed quarterly with the explicit aim of shrinking it.
• Unannounced evidence production exercises run at least twice a year.
• Contribution pipeline carries at least two submissions in draft or under review.

Effectiveness Metrics (business value)

• Audit preparation effort falls year over year, which is the level's defining business outcome.
• External findings attributable to a missing assertion fall as the assertion set matures.
• Regulatory relationships improve, evidenced by invitations to consult rather than only to respond.
• Peer adoption of published implementation patterns.

Level of Effort (incremental over the level below)

• Stand-up: 200 hours · Ongoing: 70 hours/quarter
• Compliance / Audit — primary, 20 days/year
• DevOps / Platform Engineer — regular, 16 days/year
• Legal / Privacy Counsel — regular, 10 days/year
• Program Manager / Practice Lead — low, 8 days/year
• Material new tooling: Continuous conformance assertion evaluation against existing telemetry

Success Criteria

• At least 85% of policy requirements carry a continuously evaluated conformance assertion, with the non-evaluable remainder listed explicitly rather than counted as conformant.
• Conformance drift is detected within 5 business days at the 90th percentile.
• A complete evidence pack is produced within one business day at any tier, verified by unannounced exercise twice a year.
• Audit preparation effort is tracked in hours and falling year over year.
• At least four accepted regulatory or standards contributions per year, each legally reviewed before submission.

---

Key Success Indicators

Level 1:

• A one-page priority compliance map is published, tracing every in-scope obligation to a policy clause, an owner and an evidence artifact.
• The AI Infrastructure Standard is published with an explicit review interval of at most 12 months and written so that violations are identifiable.
• At least 95% of the in-scope population holds a current acknowledgement.
• An exception process operates with named approvers, mandatory expiry dates and a reviewed register carrying no expired entries.
• Policy requirements are reconciled against infrastructure-as-code definitions and cloud configuration state, with every divergence raised as a finding with an owner.

Level 2:

• Tier-calibrated policy requirements are published, stating what each tier owes in controls, cadence, approval authority and evidence.
• Evidence packs exist per tier and are refreshed on cadence, with a Critical-tier production service level of 10 business days met.
• Bidirectional control mappings are complete, so a failing control names the obligations it jeopardises.
• A named owner assesses every regulatory change for applicability within 30 days and opens remediation work items by tier.
• Exceptions are tier-calibrated in approval authority, maximum duration and review cadence, with Critical-tier volume and age reported to the sponsor.

Level 3:

• At least 85% of policy requirements carry a continuously evaluated conformance assertion, with the non-evaluable remainder listed explicitly rather than counted as conformant.
• Conformance drift is detected within 5 business days at the 90th percentile.
• A complete evidence pack is produced within one business day at any tier, verified by unannounced exercise twice a year.
• Audit preparation effort is tracked in hours and falling year over year.
• At least four accepted regulatory or standards contributions per year, each legally reviewed before submission.

---

Common Pitfalls

Level 1:

• ❌ Building a compliance register of hundreds of rows instead of a one-page map, which nobody reads, nobody maintains and no auditor is helped by.
• ❌ Writing policy requirements that cannot be violated, such as requiring AI to be used responsibly, which makes conformance unassessable.
• ❌ Creating a parallel AI policy governance path separate from the enterprise stack, which doubles the review burden and halves the authority.
• ❌ Granting exceptions without expiry dates, after which the exception register becomes the real policy.
• ❌ Publishing the policy without reconciling it against what the environment actually does, so policy and practice diverge from day one.

Level 2:

• ❌ Applying one policy depth to every asset, which either over-burdens Low-tier work until teams route around the policy, or under-governs the Critical-tier assets that justify the programme.
• ❌ Mapping obligations to controls in one direction only, so a deferred control's regulatory consequence is discovered at audit rather than at the deferral decision.
• ❌ Assembling evidence packs only when requested, which guarantees the pack is incomplete on the one occasion it is needed urgently.
• ❌ Leaving regulatory monitoring to whoever happens to read an update, which is neither reliable nor demonstrable to an auditor.
• ❌ Treating a rising Critical-tier exception count as non-compliance by teams rather than as evidence that the policy is mis-calibrated.

Level 3:

• ❌ Collapsing the not-evaluable state into conformant, which produces a compliance dashboard that is reassuring and wrong.
• ❌ Claiming one-day evidence production without ever exercising it unannounced, which makes the claim an assumption rather than a capability.
• ❌ Automating the assertions that were easy and leaving the non-evaluable list unpublished, so the automation's real reach is unknown.
• ❌ Measuring audit success rather than audit preparation cost, when the latter is what this level actually changes.
• ❌ Submitting to consultations without legal review, which can commit the organisation to positions it has not agreed internally.

---

Practice Maturity Questions

Level 1:

1. Is there a published one-page priority compliance map tracing every in-scope obligation governing the infrastructure AI/HAI systems run on to a specific policy clause, an accountable owner, an evidence artifact and the practice that produces it?
2. Is the AI Infrastructure Standard published with requirements written so conformance is observable, routed through the enterprise policy review cycle, carrying a review interval of at most 12 months, and acknowledged by at least 95% of the in-scope population?
3. Does an exception process operate with named approvers, mandatory rationale and expiry dates and a register carrying no expired entries, and are policy requirements reconciled against infrastructure-as-code definitions and cloud configuration state with divergences raised as findings?

Level 2:

1. Are policy requirements calibrated by the SM L2 risk tier, stating for each tier what controls are mandatory, what review cadence applies, what approval authority an exception requires and what evidence must exist? Evidence this in the Infrastructure domain against the AI Infrastructure Standard and the residency position for one production endpoint.
2. Do bidirectional control mappings exist so that a failing or deferred control immediately names the obligations it leaves unevidenced, and do tier-specific evidence packs get refreshed on cadence rather than assembled on request? For Infrastructure, the assessor should be shown the AI Infrastructure Standard and the residency position for one production endpoint.
3. Does a named owner assess every regulatory change for applicability within 30 days of publication and open tier-prioritised remediation work items, and are exceptions tier-calibrated in approval authority, duration and review cadence? In Infrastructure, ask to see the AI Infrastructure Standard and the residency position for one production endpoint.

Level 3:

1. Do at least 85% of policy requirements carry a continuously evaluated conformance assertion returning conformant, non-conformant or not-evaluable, with the non-evaluable set listed explicitly and reviewed quarterly for reduction rather than collapsed into conformant? Evidence this in the Infrastructure domain against the AI Infrastructure Standard and the residency position for one production endpoint.
2. Is a complete evidence pack produced within one business day at any tier, verified by unannounced exercises at least twice a year, and is audit preparation effort tracked in hours and falling year over year? For Infrastructure, the assessor should be shown the AI Infrastructure Standard and the residency position for one production endpoint.
3. Does the organisation make at least four accepted regulatory or standards contributions per year drawn from its own implementation experience, each reviewed by legal counsel before submission? In Infrastructure, ask to see the AI Infrastructure Standard and the residency position for one production endpoint.

---

Lightweight Questions (E0 rung)

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

Level 1:

• Is there a written policy covering the infrastructure AI/HAI systems run on?
• Could you show which internal policy implements a specific regulatory obligation?
• Do your policy exceptions have expiry dates?

Level 2:

• Do your highest-risk AI assets carry stricter policy requirements than the rest?
• Could you produce a complete evidence pack for a regulator within two weeks?
• Does someone own watching for regulatory changes that affect your AI?

Level 3:

• Do you know whether you are compliant today, or only as of the last audit?
• Could you produce your evidence pack by tomorrow morning?
• Have you contributed implementation experience to a regulator or standards body?

---

Tracking

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

• Done when: Every obligation on the priority compliance map carries a policy clause, owner and evidence artifact, attestation coverage is at or above 95%, and the exception register holds no expired entries, for two consecutive quarters.
• Git artifacts: governance/compliance-map.json, governance/policy/ai-infrastructure-standard.md, governance/exception-register.json
• Git signal: compliance-map.json is reviewed quarterly with a commit each interval, and exception-register.json is checked by CI for entries past their expiry date.
• CI check: policy-exception-expiry

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

• Done when: Critical-tier evidence pack coverage at or above 95% with production within 10 business days on request and every regulatory change assessed within 30 days, sustained two consecutive quarters.
• Git artifacts: governance/tier-calibrated-policy.md, governance/control-mapping.json, governance/evidence-packs.json, governance/regulatory-change-log.json
• Git signal: evidence-packs.json is regenerated by the collection job on the tier cadence rather than assembled on request, and control-mapping.json is updated in the same change as any control addition or retirement.
• CI check: evidence-pack-freshness

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

• Done when: Continuous conformance assertion coverage at or above 85% with drift detection within 5 business days at the 90th percentile and evidence production within one business day, sustained two quarters.
• Git artifacts: governance/conformance-assertions.json, governance/non-evaluable-requirements.json, governance/contribution-log.json
• Git signal: non-evaluable-requirements.json is maintained as an explicit list reviewed quarterly, and conformance-assertions.json is evaluated by a scheduled job rather than edited by hand.
• CI check: conformance-assertion-freshness

---

Mappings

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

---

Document Version: HAIAMM v3.5 (generated) / Practice: Policy & Compliance (PC) / Domain: Infrastructure