Policy & Compliance (PC)

Software Domain - HAIAMM v3.0

Practice Overview

Objective: Publish the priority policies and compliance map that make the AI/HAI Software Assurance program enforceable, so every AI/HAI artifact the organization builds is governed by a documented set of rules, gated before it reaches production, and defensible to auditors and regulators.

Description: PC-Software codifies three priority policies specific to engineering AI/HAI software, an AI Engineering Standards policy governing what controls are required per archetype, an AI Acceptable Use & Engineering Standards policy governing what engineers may do with LLM SDKs, model registries, and tool-using agents, and an AI Software Intake / Go-Live Gate policy defining what every AI/HAI artifact must produce to enter production. It maps those policies to the compliance regimes that directly apply to the software the organization ships: EU AI Act Art. 26 deployer duties and Annex III high-risk triggers, GDPR Art. 22 automated decisioning and Art. 32/33 security and breach obligations, NIST AI RMF GOVERN, ISO/IEC 42001 AIMS, and SOC 2 CC9.2, plus sector-specific rules where applicable. At L1 the goal is not exhaustive policy coverage, it is the minimum enforceable stack needed to gate AI/HAI software before it ships and trace every relevant regulation to a single named policy.

Context: Most organizations that build AI-enabled software inherit a generic Secure Development Lifecycle and a generic AUP. Neither answers the questions that AI/HAI software raises: Which archetypes need a threat snapshot before shipping? Who may authorize a customer-facing agent? What data classes are permissible as fine-tuning inputs without privacy sign-off? What does a "go-live gate" produce as evidence? And how does EU AI Act Art. 26 deployer-duty compliance flow from the team that ships the feature to the security review that approved it? Without AI-specific policies and an explicit compliance map, shadow AI accumulates inside the engineering organization, deployer duties go unmet, and auditors cannot trace a regulation to a control. PC-Software closes that gap at the engineering surface, it governs what the organization builds, in contrast to PC-Vendors, which governs what it consumes.

Maturity Level 1

Objective: Publish the three priority AI/HAI software engineering policies, map them to the priority compliance requirements, and operate the go-live gate that prevents ungated AI/HAI software from reaching production

At this level, the organization ships the minimum viable policy stack for AI/HAI software governance, maps each policy to the regulations and standards that make it auditable, and implements the go-live gate through which every AI/HAI software artifact must pass before production.

Dependencies

• SM-Software L1 (required): the AI/HAI software inventory, archetype taxonomy, and program charter are the substrate the policies govern, PC-Software L1 cannot be operational without the inventory PC references.
• Alignment (not a hard dependency): enterprise Legal/Privacy function for data-handling obligations; existing SDLC and AppSec program; engineering management authority to enforce intake gate.
• Supports / unblocks: EG-Software L1 (workforce and practitioner training needs published policies as the teaching object); SR-Software L1 (requirements packs inherit policy guardrails); SA-Software L1 (reference patterns operationalize the policy's archetype controls); IM-Software L1 (exception and violation handling flows from policy).

Desired Outcomes

• Three short, AI-specific policies exist, are approved by Legal/Privacy and Security, are accessible to every engineer, and are acknowledged at hire and annually.
• A one-page priority compliance map lets auditors and regulators trace each requirement (EU AI Act Art. 26/50/Annex III, GDPR Art. 22/32/33/44–49, NIST AI RMF GOVERN, ISO/IEC 42001, SOC 2 CC9.2, sector-specific) to the single policy that carries it.
• No AI/HAI software artifact reaches production without passing the go-live gate; the gate produces a required-artifacts checklist for each archetype.
• Every AI/HAI artifact in production with regulatory exposure (customer-facing, decision-affecting, regulated-data-processing) has a named deployer-duty owner and a logged go-live decision.
• Shadow AI in engineering surfaces for retroactive intake through an amnesty path rather than going deeper underground.
• The program demonstrates EU AI Act Art. 26 deployer duties with a documented chain from policy → intake → go-live gate decision → named human oversight.

Activities

A) Publish the three priority AI/HAI software engineering policies

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

1. AI Engineering Standards policy, what every AI/HAI software artifact must have before shipping: - Minimum required controls per archetype (LLM-integrated app, agent, RAG pipeline, fine-tune/training workload, eval harness, model-serving service, classical ML model). Controls include: TA threat snapshot, SR requirements-evidence map (REM), SA reference-pattern adherence or DR-approved deviation, IR readiness attestation, ST evidence, ML logging-baseline confirmation. - Data classes permitted per archetype and per deployment context: regulated data (PHI, PCI, regulated PII, customer source code) at inference requires explicit privacy sign-off; regulated data as fine-tuning input requires privacy-officer approval and a documented no-train-on-production-PII confirmation. - Agentic scope constraints: no agent may act on customer accounts, execute external writes, or call APIs outside its declared tool scope without an SR-approved tool-scope boundary in the REM. - Output-integrity-critical designations: artifacts whose outputs materially affect a decision with legal or significant personal effect must be flagged at intake; these trigger GDPR Art. 22 safeguards. - Model and provider version: LLM / model provider, version, and any fine-tune lineage must be logged in the inventory at go-live; model family swaps trigger re-review.

2. AI Acceptable Use & Engineering Standards policy, what engineers may and may not do: - Permitted: use sanctioned LLM SDKs (listed in SM-Software inventory), sanctioned model providers (OpenAI, Anthropic, Bedrock, Vertex, self-hosted OSS via the model-serving service archetype), sanctioned vector-store clients for RAG. - Requires approval before doing: fine-tune or train a model on customer or regulated data; wire up a tool-using agent that touches internal APIs or makes external writes; ship any customer-facing AI feature; call a foundation-model API not on the sanctioned list. - Prohibited without explicit named sign-off: fine-tuning on customer PII without privacy-officer approval; agents acting on customer accounts without DR approval; shipping AI features that make automated decisions with legal/significant effect without GDPR Art. 22 safeguards logged; piping regulated data through a non-DPA-covered inference endpoint. - Disclosure obligation: engineers must surface AI/HAI software artifacts they build or encounter to the SM-Software inventory, including side-projects, eval harnesses, and features shipped behind feature flags. - Attestation required at hire and annually; violations are routed through the program sponsor and Legal.

3. AI Software Intake / Go-Live Gate policy, what every AI/HAI software artifact must produce to enter production: - Intake required before production deployment for all in-scope archetypes; prototype and staging environments do not require gate passage but must be in the inventory. - Required go-live artifacts by archetype (minimum at L1): - All archetypes: TA threat snapshot (from archetype-level threat library), SR REM with base pack, ML logging-baseline confirmed, named owning team and deployer-duty owner. - Agent: SA reference-pattern adherence confirmation or DR-approved deviation, tool-scope boundary documented and SR-approved, kill-switch / human-override path confirmed. - Fine-tune / training: training-data provenance record, no-regulated-PII confirmation (or privacy sign-off if regulated data used), data-deletion commitment. - Customer-facing or decision-affecting: GDPR Art. 22 safeguards checklist completed, EU AI Act Annex III high-risk use assessment on file, named human oversight assigned. - Amnesty path: artifacts already in production without gate passage may enter through retroactive intake without penalty; the inventory record is created and the gap in artifacts is tracked as an open IM finding. - Go-live gate authority: the program sponsor (or delegated AppSec lead) issues the go-live decision; the decision and the artifact checklist are logged permanently.

B) Map the three policies to the priority compliance requirements

Build a one-page priority compliance map. At L1 the goal is not exhaustive coverage, it is traceability: an auditor asking "how does Art. 26 deployer duty get met for software the org ships?" reaches one row in this table, one policy, and one artifact.

C) Operate the intake gate and track foundational compliance outcomes

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

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

Outcome Metrics (L1)

Process Metrics (leading)

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

Effectiveness Metrics (business value)

• Engineering cycle-time impact, time from intake submission to provisional approval should not increase as the gate matures; the gate is an enabler, not a bottleneck.
• Retroactive catch rate, % of artifacts discovered through amnesty or shadow-AI discovery that would have reached production without the gate; rising catch rate signals the gate is working.
• Auditor evidence turnaround, a compliance or external audit asking "show me deployer-duty evidence for this customer-facing agent" is satisfied within 5 business days from the go-live record.

Success Criteria

• Three priority policies published, approved by Legal/Privacy and Security, and communicated to all engineers.
• One-page priority compliance map published, covering all rows in the table above; linked from each policy.
• Go-live gate operational with a published SLA, a per-archetype artifacts checklist, and an amnesty path for previously ungated artifacts.
• ≥95% of engineering headcount has acknowledged the AI AUP in the current year.
• ≥85% of AI/HAI software artifacts reaching production in the last 12 months passed the gate (100% for Critical/High-tier).
• Every customer-facing and decision-affecting AI/HAI artifact in production has a named deployer-duty owner logged in SM-Software inventory.

Maturity Level 2

Objective: Deepen policy controls and compliance evidence per AI/HAI software risk tier, automate artifact assembly from the SM-Software tier rubric, and produce audit-ready evidence trails continuously

At this level, policy depth is calibrated to the risk tier assigned in SM-Software L2. Critical artifacts carry deeper contractual controls, explicit board / privacy-officer sign-off requirements, and a continuously assembled compliance evidence bundle. Low artifacts stay fast-tracked. Evidence for EU AI Act deployer duties, GDPR Art. 22/32/33 obligations, and ISO/IEC 42001 AIMS controls assembles automatically for every artifact in the Critical/High tier rather than at audit time.

Dependencies

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

Desired Outcomes

• Policy depth visibly differs by tier, Critical artifacts require explicit executive and privacy-officer sign-off; Low artifacts use fast-track with base SR pack only.
• Every Critical and High AI/HAI software artifact has a live compliance evidence bundle (TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record) that a regulator can open today.
• Vendor-style attestations on dependent foundation models (inference provider DPA status, training-on-data posture, subprocessor chain) are pulled into the artifact's evidence bundle, not trusted from a static DPA review alone.
• Policy exceptions have finite lifespans with named owners; no stale exceptions accumulate unnoticed.
• Sector-specific obligations (HIPAA for clinical AI, PCI-DSS 12.8 for payment-flow AI, FINRA/SEC model risk guidance, FDA AI/SaMD where applicable) are operationalized for the artifacts they apply to, not generically acknowledged.

Activities

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

Extend the three L1 policies with tier-specific addenda using the SM-Software L2 tier rubric (Critical / High / Medium / Low):

• Critical: full SR pack with REM required; executive (CISO or CTO) and privacy-officer sign-off required before go-live; EU AI Act Annex III high-risk assessment required and reviewed by Legal; GDPR Art. 22 safeguards reviewed by Privacy; foundation-model inference provider DPA and training-data posture attestation required on file at go-live; kill-switch / human-override path confirmed and tested; re-review mandatory on every material change (model swap, new tool added to agent, new data class, scope expansion) within 14 days.
• High: full SR pack + REM with fast-track exemptions; CISO-delegated AppSec lead sign-off; EU AI Act and GDPR assessments required; provider attestation required; re-review on material change within 30 days.
• Medium: base SR pack + REM; fast-lane DR (or DR waiver for sanctioned reference-pattern implementations); re-review annually or on material change within 60 days.
• Low: base SR pack only; self-attested artifact checklist; re-review at annual review.

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

B) Continuous compliance evidence assembly and foundation-model attestation tracking

For every Critical and High AI/HAI software artifact, maintain a live compliance evidence bundle that auto-assembles: - Current TA snapshot (age vs. last material change threshold) - Current SR REM with gap status and owner for each open gap - SA reference-pattern confirmation or DR-approved deviation record - Latest DR decision and date - Latest IR attestation and date (or finding log if IR found drift) - ST evidence: test battery last run date, prompt-injection regression corpus last run date, data-egress canary last run date - ML logging-baseline confirmation with last-validated date - Deployer-duty record: named human-oversight owner, disclosure mechanism confirmation, Art. 26 obligations checklist - Foundation-model inference provider: current DPA on file, training-on-data posture statement, subprocessor list with last-update date, model-version log

Staleness rules: any element past its tier-specific refresh window triggers a PC-Software finding routed to IM. Critical staleness thresholds, TA snapshot: 90 days; IR attestation: 6 months; ST evidence: 30 days; provider DPA status: 90 days. The evidence bundle is the primary artifact a regulator or auditor receives when asking about any specific AI/HAI software artifact.

C) Exception management and tier-aware enforcement

• Exception register integrated with the intake gate: no exception approved without tier-appropriate compensating control and expiry.
• Monthly exception aging review, exceptions more than 90 days past expiry auto-escalate to the program sponsor.
• Sector-specific evidence bundles (HIPAA PHI-in-clinical-AI bundle, PCI-DSS 12.8 bundle, FDA AI/SaMD bundle, FINRA/SEC model-risk evidence set) generated from the compliance evidence bundle for the artifacts they apply to; completeness tracked.
• Enforcement asymmetry: Critical-tier artifacts with missing go-live artifacts are a blocking finding; no amnesty applies post-L2.

Outcome Metrics (L2)

Process Metrics (leading)

• Evidence-bundle refresh cadence honored by tier (Critical: TA snapshot ≤90d, IR ≤6mo, ST ≤30d; High: TA snapshot ≤180d, IR ≤12mo, ST ≤60d).
• Exception aging reviewed monthly; zero exceptions past expiry un-escalated.
• Foundation-model provider attestation tracker refreshed quarterly from provider trust-center pages and changelog feeds.

Effectiveness Metrics (business value)

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

Success Criteria

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

Maturity Level 3

Objective: Automate compliance attestation from CI/CD, model-registry, and runtime telemetry; drive policy updates from monitoring signals and external regulatory motion; and contribute to AI software standards development

At this level, compliance is a byproduct of the engineering pipeline rather than a separate artifact assembly step. CI/CD events, model-registry promotions, and runtime telemetry feed the compliance evidence bundle continuously. Policy updates are data-driven, IM-Software incident learnings and ML-Software detection trends refresh the policy stack on a known cadence. The program contributes to AI software standards development, regulators, standards bodies, and the engineering community receive evidence-backed artifacts from the organization's experience operating a mature AI/HAI software assurance program.

Dependencies

• PC-Software L2 (required): evidence bundle and exception register must be running.
• SM-Software L3 (required): automation substrate, signal-driven inventory and tier updates feed the continuous attestation pipeline.
• ML-Software L2+ (required): prompt/completion telemetry, tool-call logs, and runtime signals feed the policy-refresh cycle.
• Supports / unblocks: PC-Software L3 evidence posture enables the other 11 Software-domain practices to claim continuous attestation rather than periodic evidence snapshots.

Desired Outcomes

• Compliance attestation for any AI/HAI software artifact is generated on demand in hours, with full provenance from the CI/CD and model-registry events that constitute the evidence.
• Policy refresh is evidence-driven and externally anchored, monitoring trends, incident learnings, EU AI Act implementing acts, US Executive Orders, state laws, and sector guidance feed a versioned, dated policy changelog.
• The program is a recognized voice in AI software regulation, EU AI Act implementation guidance, NIST AI RMF Playbook updates, ISO/IEC 42001 community, sector regulators receive substantive contributions from operators, not only from vendors.
• Contributed contract language, evidence schemas, and policy templates lead the industry, external engineering communities reference and adopt them.

Activities

A) Continuous compliance attestation from CI/CD and model-registry signals

• Evidence bundles auto-update from: CI/CD go-live events (artifact checklist attached to release record), model-registry promotion events (new model version triggers re-check of TA snapshot age, IR attestation currency, ST evidence), dependency-manifest changes (new LLM SDK import auto-opens a PC finding if artifact not yet in inventory), runtime-egress signals (new AI provider domain auto-opens intake), prompt/completion log volume events (sudden new artifact emitting prompts is a discovery signal).
• Attestation-generation pipeline: any regulatory or auditor request produces a provenance-complete evidence pack for any artifact, regulation-keyed (EU AI Act evidence pack, GDPR processor-obligation pack, ISO 42001 AIMS evidence set) or artifact-keyed, within 3 business days.
• SLO: all Critical/High artifacts continuously attested; attestation currency SLO ≤24 hours latency after a triggering event; attestation completeness ≥99% of active Critical/High artifacts.

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

• Quarterly policy-refresh cycle driven by: ML-Software detection trends (what AI-specific violation classes are rising), IM-Software incident learnings (which policy gaps created the incident conditions), tier-movement data (which archetypes are growing fastest and at what risk level), external regulatory and standards updates (EU AI Act implementing acts, EDPB AI guidance, NIST AI RMF Playbook updates, US Executive Orders on AI, state AI laws, sector-specific guidance from FDA/FINRA/OCC/NYDFS/HHS).
• Refresh output: versioned changelog for each of the three policies, approved by Legal/Privacy and Security; EG-Software training content updated within 30 days of any policy change; SM-Software inventory archetypes and tier rubric reviewed for needed updates.
• Regulatory-motion tracker: a maintained log of open regulatory instruments with expected effective dates, mapped to the policy they will affect; the working group reviews it quarterly.

C) Standards contribution and external engagement

• Participate in AI software standards and regulatory forums: EU AI Act deployer-guidance consultations (Art. 26 implementing acts), GDPR EDPB AI guidance rounds, NIST AI RMF Playbook working groups, ISO/IEC 42001 community, sector regulators (FDA AI/SaMD guidance, FINRA/OCC model-risk, NYDFS Part 500, HHS).
• Contribute AI-software-specific artifacts to public standards: go-live gate schemas, compliance evidence bundle templates, archetype-keyed policy addendum patterns, deployer-duty evidence records, through CSA AI Safety Initiative, OpenSSF AI, Shared Assessments, OWASP AI governance track.
• Target: at least 2 substantive public comments or standards contributions per year on AI/HAI software policy and compliance topics.

Outcome Metrics (L3)

Process Metrics (leading)

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

Effectiveness Metrics (business value)

• Regulator / auditor / customer feedback explicitly positive on attestation posture.
• Material audit findings on AI/HAI software controls = 0 in the last 12 months.
• Policy changes measurably close incident classes identified in prior quarters (repeat-class incident rate trends down).
• Contributed artifacts adopted externally, measured by citations, forks, standards-body acknowledgment.

Success Criteria

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

Key Success Indicators

Level 1: - Three priority policies published and approved by Legal/Privacy and Security: AI Engineering Standards, AI Acceptable Use & Engineering Standards, AI Software Intake / Go-Live Gate. - One-page priority compliance map published, covering EU AI Act Art. 26/50/Annex III/Art. 9/Art. 15, GDPR Art. 22/32/33/44–49, NIST AI RMF GOVERN/MAP/MEASURE/MANAGE, ISO/IEC 42001, SOC 2 CC9.2, and applicable sector-specific obligations. - Go-live gate operational with a per-archetype artifacts checklist, published SLA, and amnesty path for previously ungated artifacts. - ≥95% of engineering headcount has acknowledged the AI AUP in the current year. - ≥85% of AI/HAI software artifacts reaching production in the last 12 months passed the gate; 100% for Critical/High-tier.

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

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

Common Pitfalls

Level 1: - ❌ Reusing the generic AUP and SDLC without AI-specific clauses, no rule on fine-tuning data, no archetype-specific controls, no deployer-duty owner requirement; auditors cannot trace a regulation to an artifact. - ❌ Go-live gate applies only to new AI features announced through product management, misses LLM calls embedded in existing services behind feature flags, eval harnesses that reach production traffic, and fine-tunes run from researcher notebooks. - ❌ Compliance map lists frameworks but does not say which policy carries which regulation, auditors must trace coverage themselves and typically conclude it is untraceable. - ❌ No amnesty path, engineers with ungated AI/HAI software in production hide it rather than surface it; shadow AI inventory stays incomplete. - ❌ Gate checklist is archetype-agnostic, an agent and a classical ML model receive the same list; agent-specific controls (kill-switch, tool-scope boundary, human-override path) are never actually required. - ❌ Deployer-duty owner role not assigned, customer-facing AI features ship with no named human oversight; EU AI Act Art. 26 obligation is acknowledged in policy but not operationalized in any artifact. - ❌ Foundation-model provider DPA status never checked at go-live, the engineering team trusts the vendor's marketing page rather than a current contract.

Level 2: - ❌ Tier-specific addenda published but sign-off requirements never enforced, Critical artifacts ship with only the base L1 checklist because no one enforces the executive sign-off rule. - ❌ Compliance evidence bundle is a folder-of-PDFs that only the compliance lead can navigate, a second reviewer cannot assemble the regulator pack without them. - ❌ Evidence staleness thresholds exist on paper but no alert fires when they are exceeded, the TA snapshot ages past 90 days for a Critical artifact and nobody notices until an audit. - ❌ Sector-specific bundles are treated as "covered by the DPA", HIPAA BAA specifics or FDA AI/SaMD documentation are not operationalized. - ❌ Exception register exists but expiry dates are never enforced, stale exceptions from the amnesty window quietly become the permanent state for a significant fraction of the inventory.

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

Practice Maturity Questions

Level 1: 1. Have you published and formally approved the three priority AI/HAI software engineering policies, AI Engineering Standards, AI Acceptable Use & Engineering Standards, and AI Software Intake / Go-Live Gate, with archetype-specific controls, data-class restrictions, and a deployer-duty owner requirement? Is there a one-page compliance map that traces each priority requirement (EU AI Act Art. 26/50/Annex III/Art. 9/Art. 15, GDPR Art. 22/32/33/44–49, NIST AI RMF, ISO/IEC 42001, SOC 2 CC9.2, sector-specific) to the specific policy that carries it? 2. Is the go-live gate operational with a per-archetype artifacts checklist, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and does ≥85% of AI/HAI software reaching production in the last 12 months have a gate record (100% for Critical/High)? 3. Are ≥95% of engineering headcount covered by a current-year AI AUP acknowledgment, and does every customer-facing or decision-affecting AI/HAI artifact in production have a named deployer-duty owner logged in the SM-Software inventory?

Level 2: 1. Have the three priority policies been extended with tier-specific addenda (per the SM-Software L2 rubric), and do Critical artifacts carry explicit executive plus privacy-officer sign-off at go-live with a live compliance evidence bundle that covers TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record, and foundation-model provider attestation? 2. Is a compliance evidence bundle continuously maintained for every Critical/High artifact with staleness inside tier-specific targets, and can a regulatory or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days? 3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing go-live artifacts treated as blocking findings (no amnesty), and sector-specific evidence bundles (HIPAA / PCI-DSS / FDA / FINRA as applicable) complete for in-scope artifacts?

Level 3: 1. Does a continuous attestation pipeline auto-update evidence bundles from CI/CD events, model-registry promotions, and runtime signals, with an attestation currency SLO of ≤24 hours latency and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High artifacts continuously attested? 2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Software detection trends + IM-Software incident learnings + regulatory-motion tracker + tier-movement data) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update? 3. Does the program contribute at least two substantive public comments or standards artifacts per year on AI/HAI software policy topics (EU AI Act implementing guidance, GDPR EDPB AI guidance, NIST AI RMF Playbook, ISO/IEC 42001, sector regulators, or community standards bodies), with documented external recognition?

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