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.

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)

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)

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)

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