# Policy & Compliance (PC)
## Processes Domain - HAIAMM v3.0

---

### Practice Overview

**Objective:** Publish the **priority policies and compliance map** that make the AI/HAI Process Assurance program enforceable, so every AI-embedded business workflow the organization operates is governed by a documented set of rules, gated before it goes live, and defensible to auditors, regulators, and affected individuals.

**Description:** PC-Processes codifies three priority policies specific to AI-embedded business workflows, an AI-in-Business-Process Policy governing which workflows may include AI and what human-oversight model is required per archetype, a HITL Standards Policy defining what "human-in-the-loop" actually means (substantive review with a documented SLA and named override authority, not rubber-stamp approval), and an AI-Process Intake / Sanction Gate policy defining what every new AI-embedded workflow must produce before going live. It maps those policies to the compliance regimes that directly apply to AI-embedded business workflows: EU AI Act Arts. 26 (deployer duties) / 50 (transparency obligations) / Annex III (high-risk system triggers) / Art. 9 (risk management) / Art. 14 (human oversight); GDPR Art. 22 (automated decision-making); ISO/IEC 42001 AIMS; and sector-specific obligations (HIPAA clinical workflow, FCRA credit, FINRA model risk, EEOC AI-employment, NYC Local Law 144 AI hiring, CO SB-21-169 insurance, FRT facial recognition). At L1 the goal is not exhaustive policy coverage, it is the minimum enforceable stack that gates AI-embedded workflows before they go live and traces every relevant regulation to a single named policy.

**Context:** Most organizations that operate AI-embedded workflows inherit a generic Acceptable Use Policy and a generic data-handling policy. Neither answers the questions that AI-in-process raises: Which workflow archetypes require a HITL standards assessment before going live? Who may authorize a decision pipeline that affects thousands of customers? What does "human oversight" actually mean for a loan-decision workflow where the human approves 200 cases per day? And how does EU AI Act Art. 26 deployer-duty compliance, GDPR Art. 22 automated-decisioning safeguard, and sector-specific rule flow from the business function that runs the workflow to the compliance team that must demonstrate accountability? Without AI-process-specific policies and an explicit compliance map, shadow workflows accumulate inside business functions, deployer duties go unmet, FRIA obligations are unrecognized until a regulator inquires, and HITL standards are rubber-stamps that fail Art. 14 oversight requirements. PC-Processes closes that gap at the workflow surface, it governs what the organization *operates*, in contrast to PC-Software (what it builds) and PC-Vendors (what it consumes).

---

## Maturity Level 1
### Objective: Publish the three priority AI/HAI process policies, map them to the priority compliance requirements, and operate the AI-Process Intake / Sanction Gate that prevents ungated AI-embedded workflows from going live

At this level, the organization ships the minimum viable policy stack for AI-embedded workflow governance, maps each policy to the regulations and standards that make it auditable, and implements the intake gate through which every AI-embedded workflow must pass before going live.

#### Dependencies

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

#### Desired Outcomes

- Three short, AI-process-specific policies exist, are approved by Legal/Privacy and Security, are accessible to every function head and process owner, and are acknowledged annually.
- A one-page priority compliance map lets auditors and regulators trace each requirement (EU AI Act Art. 26/50/Annex III/Art. 9/Art. 14, GDPR Art. 22, ISO/IEC 42001, sector-specific) to the single policy that carries it.
- No AI-embedded workflow goes live without passing the intake gate; the gate produces a required-artifacts checklist for each archetype.
- Every AI-embedded workflow 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-processes surfaces for retroactive intake through an amnesty path rather than going deeper underground.
- HITL standards are documented for every customer-facing and decision-affecting workflow, distinguishing substantive review from rubber-stamp approval.

#### Activities

**A) Publish the three priority AI/HAI process policies**

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

**1. AI-in-Business-Process Policy**, what workflows may include AI and what oversight is required:
- Permitted workflow archetypes and permitted AI-tool archetypes per archetype (decision pipeline, customer-facing flow, HITL collaboration chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow).
- Required human-oversight model per archetype: autonomous steps require explicit approval at intake with HITL design documented; customer-facing flows require disclosure mechanism; decision pipelines with legal or significant effect require GDPR Art. 22 safeguards; Annex III high-risk uses require FRIA.
- Required disclosure to affected persons: customers and employees affected by AI-embedded decisions must receive disclosure in line with EU AI Act Art. 50 and Art. 26 deployer duties; disclosure mechanism must be confirmed at intake.
- Prohibited without explicit named sign-off: operating a decision pipeline affecting persons without a named human-oversight owner; operating a customer-facing AI flow without an Art. 50 disclosure mechanism; embedding AI in a workflow that touches Annex III use cases without a commissioned FRIA; using AI in employment screening without EEOC / Art. 22 safeguards documented.
- Attestation required annually by all function heads, process owners, and operations managers.

**2. HITL Standards Policy**, what "human-in-the-loop" actually means:
- Definition of substantive review vs. rubber-stamp review: substantive review means the human has enough time and information to meaningfully evaluate the AI output, can exercise judgment independently of the AI recommendation, and has a clear override path with no disincentive to override; rubber-stamp review (SLA so short no human can realistically review, no override training, no override rate tracked) does not satisfy Art. 14 human oversight.
- Minimum review SLA per archetype: decision pipelines, the human reviewer must have at least X minutes per item (set per workflow based on item complexity; not less than 2 minutes for any legally significant decision); the queue size per reviewer per shift must not exceed the rate that makes substantive review impossible.
- Override authority: for every AI-embedded workflow, a named individual or role has explicit authority to override the AI recommendation; the override path is trained, practiced, and logged; overrides are tracked and reported to the program sponsor quarterly.
- AI output integrity: the human reviewer must have access to the AI output and any confidence score, key inputs, and the basis for the AI recommendation, not just the final recommendation; AI output must not be presented in a way that anchors the human toward one outcome before substantive review occurs.
- Escalation path: criteria for escalating to a senior reviewer, legal, compliance, or the program sponsor when the AI output is uncertain, the case is novel, or a customer challenge is received.
- HITL standards must be documented and confirmed at intake for all customer-facing and decision-affecting workflows; HITL standards are reviewed annually or on any material change to the workflow.

**3. AI-Process Intake / Sanction Gate Policy**, what every AI-embedded workflow must produce before going live:
- Intake required before production deployment for all in-scope workflow archetypes; test and pilot 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 function and deployer-duty owner.
  - Decision pipeline: GDPR Art. 22 safeguards checklist completed; EU AI Act Annex III high-risk use assessment on file; FRIA commissioned or confirmed not-required with documented rationale; HITL standards documented and confirmed substantive.
  - Customer-facing flow: Art. 50 disclosure mechanism confirmed; human-oversight model documented; HITL SLA confirmed.
  - Human-AI collaboration chain: HITL standards reviewed; override authority named; override-rate tracking confirmed active.
  - Approval/review workflow: AI pre-classification accuracy baseline established; override rate tracked; escalation path documented.
  - Content-generation workflow: human review and publication accountability documented; output attribution policy confirmed.
  - Knowledge-management workflow: retrieval-source governance confirmed; output-integrity-in-decisions risk assessed.
- Amnesty path: workflows 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 Compliance / 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 traceability: an auditor asking "how does Art. 26 deployer duty get met for AI-embedded workflows the org operates?" reaches one row in this table, one policy, and one artifact.

| Priority requirement | What it demands for AI-embedded workflows | Which L1 policy carries it |
|---|---|---|
| **EU AI Act, Art. 26 (deployer duties)** | Use AI systems per provider instructions; assign human oversight; monitor operation; inform affected persons; keep logs for high-risk systems; conduct FRIA where Annex III applies | AI-in-Business-Process Policy (oversight model, disclosure requirement, deployer-duty owner) + Intake Gate (go-live artifact checklist, logged decision, deployer-duty owner) |
| **EU AI Act, Art. 50 (transparency)** | Disclose AI interaction and AI-generated content to persons affected by AI-embedded workflows | AI-in-Business-Process Policy (disclosure requirement for customer-facing and decision-affecting flows) + HITL Standards (disclosure mechanism confirmed at intake) |
| **EU AI Act, Annex III (high-risk systems)** | Triggers for high-risk classification: employment, credit, education, biometric, critical infrastructure, law enforcement, immigration, justice, essential services | Intake Gate (Annex III high-risk use assessment required at go-live; FRIA gate for decision pipelines) |
| **EU AI Act, Art. 9 (risk management)** | Documented risk management system for high-risk AI systems, iterative testing, residual-risk controls | AI-in-Business-Process Policy (TA + SR + SA required artifacts) + Intake Gate (gate checklist constitutes the risk-management record) |
| **EU AI Act, Art. 14 (human oversight)** | Effective human oversight of high-risk AI systems; oversight persons understand capability and limitations; can override; identify and address risks | HITL Standards Policy (substantive review definition, override authority, escalation path, SLA, anchoring-prevention requirements) |
| **GDPR, Art. 22 (automated decision-making)** | Safeguards when AI output materially drives a decision with legal or significant effect on a person: right to human review, right to explanation, right to contest | AI-in-Business-Process Policy (Art. 22 safeguards required for decision pipelines) + HITL Standards (substantive review satisfies right to human review) + Intake Gate (safeguards checklist at go-live) |
| **ISO/IEC 42001 (AIMS)** | AI management system scope, controls, AI risk management, roles and responsibilities, continuous improvement | Full three-policy stack; Intake Gate enforces the AIMS outputs for every workflow |
| **NIST AI RMF 1.0, GOVERN / MAP / MEASURE / MANAGE** | Policies, accountability, risk identification, impact assessment, testing, ongoing monitoring | Three-policy stack + Intake Gate + HITL Standards constitute the GOVERN / MAP / MEASURE / MANAGE record for AI-embedded workflows |
| **HIPAA (clinical AI workflows)** | PHI in clinical AI workflows requires BAA with AI providers; human oversight in clinical decision-support; documentation of AI-assisted clinical decisions | AI-in-Business-Process Policy (sector clause for clinical) + HITL Standards (clinical review SLA and override authority) |
| **FCRA (credit AI decisions)** | Adverse action notices citing AI-driven credit decisions; explanation requirements; accuracy obligations | AI-in-Business-Process Policy (credit decision-pipeline requirements) + HITL Standards (override SLA for credit review) + Intake Gate (FCRA checklist for credit pipelines) |
| **EEOC AI employment guidance / NYC Local Law 144** | Bias audit requirements for AI hiring tools; annual bias audits for automated employment decisions; notice to candidates | Intake Gate (bias-audit requirement for employment screening pipelines; NYC LL144 compliance checklist) + AI-in-Business-Process Policy (employment-screening AI requirements) |
| **CO SB-21-169 (insurance AI)** | Insurer requirements for AI in underwriting; anti-discrimination; explainability | AI-in-Business-Process Policy (insurance underwriting workflow clause) + Intake Gate (CO SB-21-169 checklist) |
| **FINRA model risk guidance (automated advice)** | Model documentation, validation, and ongoing monitoring for automated financial advice; human review requirements | AI-in-Business-Process Policy (financial advice automation requirements) + HITL Standards (financial advice override SLA) |

**C) Operate the intake gate and track foundational compliance outcomes**

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

Gate mechanics at L1:
- Single intake ticket queue; single SLA (triage within 5 business days; fast-track provisional approval within 10 BD for Low-tier archetypes with no regulated data, no customer exposure, and full human review).
- Artifacts checklist is archetype-keyed, the function team submitting intake receives the checklist for their archetype; missing artifacts block go-live.
- Integration with the SM-Processes inventory: gate approval creates or updates the inventory record with artifact links.
- Amnesty path is visible: linked from the intake form, the AI-in-Business-Process Policy, and the function-head 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)

| Metric | Baseline | L1 Target | Source |
|---|---|---|---|
| % of AI-embedded workflows going live that passed the intake gate | measure | ≥80% within 12 months; 100% for Critical/High archetypes | Intake queue vs. SM-Processes inventory |
| % of AI-embedded workflows in production with a named deployer-duty owner | measure | 100% for customer-facing and decision-affecting workflows | SM-Processes inventory |
| % function heads and process owners with acknowledged AI-in-Business-Process Policy (current-year) | measure | ≥90% | HR / LMS attestation |
| Priority compliance map published and reviewed in last 12 months | n/a | Yes | Document registry |
| Retroactive intake amnesty records opened and tracked as IM findings | measure | trending down QoQ (coverage increasing) | Intake queue tagged "amnesty" |

#### 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; at minimum annually.
- Gate checklist accuracy, archetype-keyed required-artifacts checklists reviewed quarterly; function teams' reported blocking rate tracked.

#### Effectiveness Metrics (business value)

- Function-team 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 workflows discovered through amnesty or shadow-AI-in-processes discovery that would have gone live without the gate; rising catch rate signals the gate is working.
- Regulatory-evidence turnaround, a compliance or external audit asking "show me Art. 22 safeguards for this credit decision pipeline" 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 function heads and process owners.
- One-page priority compliance map published, covering all rows in the table above; linked from each policy.
- Intake gate operational with a published SLA, a per-archetype artifacts checklist, and an amnesty path for previously ungated workflows.
- ≥90% of function heads and process owners have acknowledged the AI-in-Business-Process Policy in the current year.
- ≥80% of AI-embedded workflows going live in the last 12 months passed the gate (100% for Critical/High-tier).
- Every customer-facing and decision-affecting AI-embedded workflow in production has a named deployer-duty owner logged in SM-Processes inventory.

---

## Maturity Level 2
### Objective: Deepen policy controls and compliance evidence per AI-embedded workflow risk tier, automate artifact assembly from the SM-Processes tier rubric, and operate the FRIA gate for EU AI Act Annex III workflows continuously

At this level, policy depth is calibrated to the risk tier assigned in SM-Processes L2. Critical decision pipelines carry deeper compliance evidence requirements, explicit board / privacy-officer sign-off, FRIA completion, and HITL standards validation. Low back-office augmentation workflows stay fast-tracked. Evidence for EU AI Act Art. 26 deployer duties, GDPR Art. 22 safeguards, ISO/IEC 42001 AIMS controls, and sector-specific obligations assembles continuously for every workflow in the Critical/High tier rather than at audit time.

#### Dependencies

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

#### Desired Outcomes

- Policy depth visibly differs by tier, Critical decision pipelines require FRIA completion, executive and DPO/CPO sign-off, HITL validation, and a live compliance evidence bundle; Low back-office augmentation uses fast-track with base SR pack only.
- Every Critical and High AI-embedded workflow 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, HITL validation, Art. 22/26 safeguards checklist) that a regulator can open today.
- HITL substantive-review validation is evidenced, not self-reported, override rates, review-time data, and escalation logs prove the HITL model meets the HITL Standards Policy.
- Sector-specific obligations (HIPAA clinical, FCRA credit, FINRA/OCC model risk, NYC LL144 AI hiring, CO SB-21-169 insurance, EEOC employment AI) are operationalized for the workflows they apply to, not generically acknowledged.
- Policy exceptions have finite lifespans with named owners; no stale exceptions accumulate unnoticed.

#### Activities

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

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

- **Critical:** full SR pack with REM required; executive (CISO or COO) and DPO/CPO sign-off required before go-live; EU AI Act Annex III high-risk assessment required and reviewed by Legal; FRIA commissioned, completed, and signed off before production; GDPR Art. 22 safeguards reviewed by Privacy; HITL standards validated with override-rate data and review-time confirmation; Art. 26 disclosure mechanism confirmed and tested; sector-specific compliance checklist completed (FCRA, NYC LL144, CO SB-21-169, HIPAA, FINRA, EEOC as applicable); re-review mandatory on every material change (new AI tool, new decision population, new data class, scope expansion) within 14 days.
- **High:** full SR pack + REM with fast-track exemptions; CISO-delegated AppSec / Compliance lead sign-off; EU AI Act and GDPR assessments required; FRIA required if Art. 22 applies and scale exceeds threshold; HITL model documented and confirmed; re-review on material change within 30 days.
- **Medium:** base SR pack + REM; fast-lane DR (or DR waiver for sanctioned reference-pattern implementations); HITL documented; re-review annually or on material change within 60 days.
- **Low:** base SR pack only; self-attested artifact checklist; HITL confirmed; 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 / Compliance reviewer acknowledgment, and an expiry date (max 12 months without re-review). Critical-tier workflows 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 HITL validation tracking**

For every Critical and High AI-embedded workflow, 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: output-integrity test battery last run date, HITL bypass test last run date, input-injection probe last run date
- ML logging-baseline confirmation with last-validated date
- Deployer-duty record: named human-oversight owner, Art. 26 disclosure mechanism confirmation, Art. 26 obligations checklist
- HITL validation evidence: override rate (last 90 days), average review time per item, escalation rate, most recent HITL standards review date
- FRIA status: not applicable / commissioned / completed / last reviewed date (for Annex III workflows)
- Sector-specific compliance checklist status (FCRA, NYC LL144, CO SB-21-169, HIPAA, FINRA, EEOC as applicable)

Staleness rules: any element past its tier-specific refresh window triggers a PC-Processes finding routed to IM. Critical staleness thresholds, TA snapshot: 90 days; IR attestation: 6 months; ST evidence: 30 days; HITL validation data: 30 days; FRIA review: 12 months or on material change. The evidence bundle is the primary artifact a regulator or auditor receives when asking about any specific AI-embedded workflow.

**C) FRIA gate operation and sector-specific compliance bundle management**

- FRIA gate: for all EU AI Act Annex III workflows, FRIA is commissioned at intake and must be completed before production go-live. FRIA completion is tracked in the compliance evidence bundle and in SM-Processes inventory. FRIA scope includes: the workflow archetype and AI system; the population affected; decision effects and reversibility; fundamental rights assessment (non-discrimination, data protection, transparency, right to explanation); human oversight design and HITL validation; regulatory scope; residual risks and mitigations; named FRIA author and reviewer.
- FRIA review schedule: Critical-tier Annex III workflows, FRIA reviewed annually and on every material change. High-tier Art. 22 workflows, FRIA reviewed on material change.
- Sector-specific evidence bundles generated from the compliance evidence bundle for the workflows they apply to:
  - FCRA bundle: adverse-action notice process, AI-model documentation, accuracy-rate tracking, dispute-handling path.
  - NYC Local Law 144 bundle: annual bias audit on file, candidate notice mechanism confirmed, audit publication confirmed.
  - CO SB-21-169 bundle: anti-discrimination evidence, explainability documentation, state reporting compliance.
  - HIPAA clinical bundle: BAA with AI provider confirmed, PHI-in-clinical-workflow documentation, human-oversight of AI-assisted clinical decisions.
  - FINRA model risk bundle: model documentation, validation evidence, ongoing monitoring plan.
  - EEOC employment AI bundle: adverse-impact analysis, explanation mechanism, override-rate tracking.
- Enforcement asymmetry: Critical-tier workflows with missing go-live artifacts are blocking findings; no amnesty applies post-L2.

#### Outcome Metrics (L2)

| Metric | Baseline | L2 Target | Source |
|---|---|---|---|
| % Critical/High AI-embedded workflows with complete compliance evidence bundle | measure | ≥95% | Evidence registry × SM inventory |
| Median staleness of evidence-bundle elements for Critical workflows | measure | ≤30 days past refresh window | Evidence registry |
| FRIA completion rate for all Annex III workflows | measure | 100% before production | FRIA register |
| % Critical workflows with explicit executive + DPO/CPO sign-off at go-live | measure | 100% | Gate records |
| HITL validation evidence present and current for all Critical/High workflows | measure | 100% | HITL validation tracker |
| Sector-specific evidence bundle completeness for in-scope workflows | measure | 100% | Sector evidence artifact |

#### Process Metrics (leading)

- Evidence-bundle refresh cadence honored by tier (Critical: TA snapshot ≤90d, IR ≤6mo, ST ≤30d, HITL validation ≤30d; High: TA snapshot ≤180d, IR ≤12mo, ST ≤60d, HITL validation ≤60d).
- Exception aging reviewed monthly; zero exceptions past expiry un-escalated.
- FRIA review schedule met; no Annex III workflow past FRIA review date un-escalated.
- HITL override rates reviewed monthly; workflows with override rate below expected threshold flagged for HITL quality review.

#### Effectiveness Metrics (business value)

- Regulatory inquiry turnaround, evidence bundle open time for a regulator or auditor request ≤5 business days.
- Audit findings on AI-embedded workflow controls trending down; repeat findings = 0.
- HITL override rate trending toward healthy range (neither zero (rubber-stamp) nor excessive (AI output unhelpful)), program drives toward meaningful human oversight.

#### Success Criteria

- Three priority policies extended with tier-specific addenda; tier-appropriate sign-off in place for ≥100% of Critical workflows in the last 12 months.
- Compliance evidence bundle live for every Critical/High workflow; staleness inside target.
- FRIA gate operational; 100% of Annex III workflows have a completed FRIA on file before production.
- HITL validation evidence current for 100% of Critical/High workflows.
- Sector-specific evidence bundles complete for all in-scope workflows.
- Exception register comprehensive; reviewed monthly; zero exceptions past expiry un-escalated.

---

## Maturity Level 3
### Objective: Automate compliance attestation from workflow-execution telemetry and BPM signals; drive policy updates from monitoring signals, HITL validation data, and regulatory motion; and contribute to AI-process-governance and Art. 14 / Art. 22 implementation standards

At this level, compliance is a byproduct of the workflow-execution pipeline rather than a separate artifact assembly step. BPM events, HITL event logs, override-rate data, and AI-step output logs feed the compliance evidence bundle continuously. Policy updates are data-driven, IM-Processes incident learnings, ML-Processes detection trends, and HITL validation signals refresh the policy stack on a known cadence. The program contributes to AI-process-governance standards development, regulators, standards bodies, and the business-process community receive evidence-backed artifacts from the organization's experience operating a mature AI-embedded workflow governance program.

#### Dependencies

- **PC-Processes L2 (required):** evidence bundle, FRIA gate, and exception register must be running.
- **SM-Processes L3 (required):** automation substrate, signal-driven inventory and tier updates feed the continuous attestation pipeline.
- **ML-Processes L2+ (required):** HITL event logs, AI-step output logs, BPM events, and override-rate data feed the policy-refresh cycle.
- **Supports / unblocks:** PC-Processes L3 evidence posture enables the other 11 Processes-domain practices to claim continuous attestation rather than periodic evidence snapshots.

#### Desired Outcomes

- Compliance attestation for any AI-embedded workflow is generated on demand in hours, with full provenance from the BPM events, HITL logs, and override-rate data that constitute the evidence.
- Policy refresh is evidence-driven and externally anchored, HITL quality signals, FRIA outcomes, IM incident learnings, EU AI Act implementing acts, state AI laws, sector enforcement actions, and OECD AI guidance feed a versioned, dated policy changelog.
- The program is a recognized contributor to AI-process-governance regulation, EU AI Act Art. 14 / Art. 26 implementing guidance, GDPR EDPB AI guidance on Art. 22, ISO/IEC 42005 FRIA methodology, and sector-specific AI deployment frameworks receive substantive contributions from operators.
- Contributed HITL design standards, FRIA methodology templates, and compliance evidence schemas lead the industry, external organizations reference and adopt them.

#### Activities

**A) Continuous compliance attestation from BPM and HITL telemetry**

- Evidence bundles auto-update from: BPM platform go-live events (artifact checklist attached to workflow version record), HITL event logs (override rates, review times, escalation events updated in real time), AI-step output logs (output-integrity test results, logging-baseline confirmation), workflow-version change events (new AI step added auto-opens a PC finding if workflow not yet in inventory), FRIA review schedule triggers (Annex III workflow reaching annual FRIA review date auto-opens review task), sector-specific renewal triggers (NYC LL144 annual bias audit due date, CO SB-21-169 annual report due date).
- Attestation-generation pipeline: any regulatory or auditor request produces a provenance-complete evidence pack for any workflow, regulation-keyed (EU AI Act evidence pack, GDPR Art. 22 / Art. 26 deployer-duty pack, sector-specific pack) or workflow-keyed, within 3 business days.
- SLO: all Critical/High workflows continuously attested; attestation currency SLO ≤24 hours latency after a triggering event; attestation completeness ≥99% of active Critical/High workflows.

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

- Quarterly policy-refresh cycle driven by: ML-Processes detection trends (what workflow-integrity violation classes are rising), IM-Processes incident learnings (which policy gaps created the incident conditions), HITL validation signals (which archetypes show rubber-stamp patterns that need HITL Standards Policy tightening), tier-movement data (which workflow archetypes are growing fastest and at what risk level), external regulatory and standards updates (EU AI Act Art. 14 / Art. 26 implementing acts, GDPR EDPB AI guidance on Art. 22, OECD AI Policy Observatory guidance, FTC / CFPB / EEOC AI enforcement actions, state AI laws, sector-specific guidance).
- Refresh output: versioned changelog for each of the three policies, approved by Legal/Privacy and Security; EG-Processes training content updated within 30 days of any policy change; SM-Processes inventory archetypes and tier rubric reviewed for needed updates.
- Regulatory-motion tracker: a maintained log of open regulatory instruments with expected effective dates (state AI laws, sector-specific AI rules, EU AI Act implementing acts), mapped to the policy they will affect; the working group reviews it quarterly.

**C) Standards contribution and external engagement**

- Participate in AI-process-governance standards and regulatory forums: EU AI Act Art. 14 / Art. 26 deployer-guidance consultations; GDPR EDPB AI guidance rounds (Art. 22 implementation guidance); ISO/IEC 42005 AI impact assessment working groups; OECD AI Policy Observatory practitioners network; sector regulators (CFPB credit AI guidance, EEOC AI employment guidance, FINRA/OCC model-risk for automated advice, NYC / CO state AI law implementation, HHS clinical AI guidance, FRT governance frameworks).
- Contribute AI-process-specific artifacts to public standards: HITL design standards (substantive vs. rubber-stamp taxonomy, review-SLA calculation methodology, override-rate benchmarks), FRIA methodology templates for each Annex III use category (employment, credit, education, clinical), compliance evidence bundle schemas for Art. 22 / Art. 26, workflow-archetype policy addendum patterns, through CSA AI Safety Initiative, ISO/IEC 42005 community, OECD, and sector-specific working groups.
- Target: at least 2 substantive public comments or standards contributions per year on AI-process governance and Art. 14 / Art. 22 implementation topics.

#### Outcome Metrics (L3)

| Metric | Baseline | L3 Target | Source |
|---|---|---|---|
| Attestation-pack generation SLA for regulator / auditor | measure | ≤3 business days | Evidence-ops telemetry |
| Attestation currency SLO for Critical/High workflows | measure | ≤24h latency post-triggering event | Evidence pipeline telemetry |
| Policy refresh cadence met | measure | quarterly, on calendar | Policy changelog |
| % policy changes traceable to ML/IM telemetry, HITL validation signals, or named regulatory update | measure | 100% | Policy change rationale |
| Public regulatory / standards contributions per year | 0 | ≥2 | Contribution log |
| External recognition (citations, adoptions, invitations) | 0 | tracked, trending up | External artifacts |

#### 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.
- FRIA review schedule current; zero Annex III workflows overdue for FRIA review.
- Contribution pipeline ≥2 items in-flight at any time.

#### Effectiveness Metrics (business value)

- Regulator / auditor / customer feedback explicitly positive on Art. 22 / Art. 26 attestation posture.
- Material audit findings on AI-embedded workflow controls = 0 in the last 12 months.
- Policy changes measurably close HITL quality problems and workflow-integrity violation classes identified in prior quarters.
- Contributed HITL design standards and FRIA templates adopted externally, measured by citations, standards-body acknowledgment, sector-regulator reference.

#### Success Criteria

- On-demand attestation pack generation inside 3 business days for any active AI-embedded workflow; SLA met in last 12 months.
- Continuous attestation pipeline operational with ≤24h currency SLO; completeness ≥99% of Critical/High workflows.
- Quarterly telemetry-driven policy-refresh cycle operating with a versioned, externally-auditable changelog.
- ≥2 substantive public regulatory or standards contributions per year on AI-process governance topics; external recognition documented.
- Zero material audit findings on AI-embedded workflow controls in the last 12 months.

---

## Key Success Indicators

**Level 1:**
- Three priority policies published and approved by Legal/Privacy and Security: AI-in-Business-Process Policy, HITL Standards Policy, AI-Process Intake / Sanction Gate Policy.
- One-page priority compliance map published, covering EU AI Act Art. 26 / Art. 50 / Annex III / Art. 9 / Art. 14, GDPR Art. 22, ISO/IEC 42001, NIST AI RMF, and applicable sector-specific obligations (HIPAA, FCRA, FINRA, EEOC, NYC LL144, CO SB-21-169, FRT).
- Intake gate operational with a per-archetype artifacts checklist, published SLA, and amnesty path for previously ungated workflows.
- ≥90% of function heads and process owners have acknowledged the AI-in-Business-Process Policy in the current year.
- ≥80% of AI-embedded workflows going live in the last 12 months passed the gate; 100% for Critical/High-tier.

**Level 2:**
- Tier-specific policy addenda in place; Critical workflows carry explicit executive + DPO/CPO sign-off, completed FRIA, and HITL validation evidence; compliance evidence bundles live for all Critical/High workflows with staleness inside tier-specific targets.
- FRIA gate operational with 100% Annex III workflow coverage before production.
- HITL validation evidence current for all Critical/High workflows; override rates in healthy range.
- Sector-specific evidence bundles (FCRA / NYC LL144 / CO SB-21-169 / HIPAA / FINRA / EEOC as applicable) complete for in-scope workflows.
- Exception register comprehensive; reviewed monthly; Critical-tier missing artifacts treated as blocking findings with no amnesty.

**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, HITL validation signals, or named regulatory update.
- ≥2 substantive public regulatory or standards contributions per year on AI-process governance; external recognition documented.
- Zero material audit findings on AI-embedded workflow controls in the last 12 months.

---

## Common Pitfalls

**Level 1:**
- ❌ Reusing the generic AUP without AI-process-specific clauses, no rule on HITL standards, no archetype-specific oversight requirements, no deployer-duty owner requirement; auditors cannot trace Art. 22 or Art. 26 to an artifact.
- ❌ Intake gate applies only to new workflows submitted through product management, misses AI-embedded steps added informally by function teams, AI-routing rules added to ticketing systems, and AI-embedded SaaS features silently enabled in approved tools.
- ❌ Compliance map lists regulations but does not say which policy carries which regulation, auditors must trace coverage themselves and typically conclude it is untraceable.
- ❌ No amnesty path, function heads with ungated AI-embedded workflows hide them rather than surface them; shadow AI inventory stays incomplete.
- ❌ Gate checklist is archetype-agnostic, a decision pipeline and a back-office augmentation workflow receive the same checklist; FRIA requirement, Art. 22 safeguards checklist, and HITL standards confirmation are never actually required for decision pipelines.
- ❌ Deployer-duty owner role not assigned, decision pipelines affecting customers ship with no named human-oversight authority; EU AI Act Art. 26 obligation is acknowledged in policy but not operationalized.
- ❌ HITL "confirmation" at intake is a checkbox rather than a documented review SLA and override-rate target, rubber-stamp HITL is logged as compliant.

**Level 2:**
- ❌ Tier-specific addenda published but FRIA gate never enforced, Annex III decision pipelines reach production without a completed FRIA because no blocking mechanism was built.
- ❌ HITL validation evidence is self-reported override rates from the business function, not independently measured from HITL event logs, rubber-stamp patterns persist invisibly.
- ❌ 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.
- ❌ Sector-specific bundles are treated as "covered by the DPA", NYC LL144 annual bias audit, CO SB-21-169 state reporting, and FCRA adverse-action notice specifics are not operationalized.
- ❌ Exception register exists but expiry dates are never enforced, stale exceptions from the amnesty window quietly become the permanent state.

**Level 3:**
- ❌ Attestation pipeline generates evidence that is technically complete but narratively thin, a regulator still needs a human to explain what the FRIA and HITL validation data mean; the 3 BD SLO is met but follow-up hearings are needed.
- ❌ Policy refresh is cadence-only, quarterly ritual without real HITL validation or IM-incident input; the changelog reads like formatting updates and Legal cannot explain what signal prompted which change.
- ❌ FRIA methodology templates contributed to ISO/IEC 42005 are generic and untested, other organizations adopt them and find they do not cover real Annex III use-case complexity; the program's credibility suffers.
- ❌ HITL design standards contributed externally go stale, the program publishes once, does not maintain, and practitioners find override-rate benchmarks that no longer reflect current sector practice.
- ❌ ROI narrative omits compliance cost-reduction evidence, the biggest L3 business case (lower audit preparation overhead, faster regulatory response, avoided enforcement actions) is never measured or reported.

---

## Practice Maturity Questions

**Level 1:**
1. Have you published and formally approved the three priority AI/HAI process policies, AI-in-Business-Process Policy, HITL Standards Policy, and AI-Process Intake / Sanction Gate, with archetype-specific oversight requirements, HITL standards (distinguishing substantive review from rubber-stamp), 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. 14, GDPR Art. 22, ISO/IEC 42001, NIST AI RMF, and applicable sector-specific obligations) to the specific policy that carries it?
2. Is the intake gate operational with a per-archetype artifacts checklist (including FRIA commissioning and Art. 22 safeguards for decision pipelines), a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and does ≥80% of AI-embedded workflows going live in the last 12 months have a gate record (100% for Critical/High)?
3. Are ≥90% of function heads and process owners covered by a current-year AI-in-Business-Process Policy acknowledgment, and does every customer-facing or decision-affecting AI-embedded workflow in production have a named deployer-duty owner with a documented HITL model logged in the SM-Processes inventory?

**Level 2:**
1. Have the three priority policies been extended with tier-specific addenda (per the SM-Processes L2 rubric), and do Critical workflows carry explicit executive plus DPO/CPO sign-off, a completed FRIA on file before production, and HITL validation evidence (override rates and review-time data) in a live compliance evidence bundle?
2. Is the FRIA gate operational for 100% of EU AI Act Annex III workflows, and is a compliance evidence bundle continuously maintained for every Critical/High workflow 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 (FCRA / NYC LL144 / CO SB-21-169 / HIPAA / FINRA / EEOC as applicable) complete for in-scope workflows?

**Level 3:**
1. Does a continuous attestation pipeline auto-update compliance evidence bundles from BPM events, HITL event logs, override-rate data, and AI-step output logs, with an attestation currency SLO of ≤24 hours latency and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High workflows continuously attested?
2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Processes detection trends + IM-Processes incident learnings + HITL validation signals + regulatory-motion tracker) 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-process governance and Art. 14 / Art. 22 implementation topics (EU AI Act implementing guidance, GDPR EDPB Art. 22 guidance, ISO/IEC 42005, OECD AI guidance, or sector-regulator forums), with documented external recognition?

---

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