Implementation Review (IR)

Processes Domain - HAIAMM v3.0

Practice Overview

Objective: Verify, at go-live and on a recurring cadence, that the actually-running AI-embedded business workflow matches the design approved at DR, and that it stays there as the workflow and its underlying AI components evolve.

Description: IR-Processes is the configuration and operational check for AI-embedded business workflows, the moment a reviewer opens the workflow-tool configuration, the HITL queue logs, the decision-logging pipeline, the override-audit trail, and the product-flow analytics and confirms that what is running matches the DR decision record. At L1 the review runs at go-live, at least annually, and on material change (AI component swapped, HITL gate configuration changed, new affected-person population added, Art. 50 disclosure removed, decision-logging scope reduced). At L2, IR consumes workflow-config webhooks (BPM tool change events from Camunda / Temporal / Argo / ServiceNow), HITL-queue logs, decision-distribution monitoring, and product-flow analytics to detect configuration drift continuously for High and Critical-tier workflows. Findings are severity-tagged and SLA-bound per the SM-Processes L2 tier-treatment matrix; they feed IM-Processes for tracking and resolution. HITL substantiveness, Art. 50 disclosure presence, decision-logging completeness, and the contestation path's responsiveness are all probed recurrently, not trusted from design text alone.

Context: The gap between the approved workflow design and the running workflow is the primary source of silent compliance and safety exposure in AI-embedded business processes. A decision pipeline's HITL gate is specified as requiring a substantive rationale in the DR record but the deployed queue interface has no rationale field, so reviewers click through in seconds. An approval workflow's class-shift monitor is documented in the SA pattern but was never wired to the deployed scoring service. A customer-facing flow's Art. 50 disclosure is approved in DR but removed in a UI A/B test without a corresponding DR re-review. IR-Processes closes these gaps by making the implementation check systematic, evidence-based, and recurring, not a one-time pre-launch checkbox or a scramble when an affected person files a contestation request.

Maturity Level 1

Objective: Run per-archetype implementation reviews at go-live, annually, and on material change, verifying the running workflow matches the DR-approved design, HITL gates are substantive, Art. 50 disclosure is present, decision logging is complete, and affected-persons rights surface is responsive

At this level, the gap between the approved workflow design and the running workflow is systematically checked at the moments that matter most. Every review produces findings with severity tags, named owners, and SLA-bound resolution dates.

Dependencies

• DR-Processes L1 (required): the approved DR decision record is the specification IR checks against; without it there is no authoritative baseline.
• SR-Processes L1 (required): the REM defines which requirements must be evidenced; IR verifies the evidence is current and accurate.
• SA-Processes L1 (required): the SA reference pattern defines the intended workflow control shape; IR checks adherence to the pattern's HITL, logging, and disclosure controls.
• EG-Processes L1 (required): reviewers must understand AI-embedded workflow archetypes, HITL design patterns, and applicable compliance obligations to produce a credible IR finding set.
• Supports / unblocks: ST-Processes L1 (tests run against the verified workflow configuration), EH-Processes L1 (hardening acts on IR findings), IM-Processes L1 (IR findings become issues in the backlog), ML-Processes L1 (monitoring configuration verified here feeds detections).

Desired Outcomes

• The gap between the DR-approved workflow design and the live workflow stays small and short-lived.
• Material configuration and operational drift is found by the program, not by an affected person's contestation request or an external audit.
• Every finding has a named owner, a severity tag, and a SLA-bound resolution date; aging findings are visible to the program sponsor.
• Material changes to a live AI-embedded workflow always trigger a review before the change affects affected persons, AI component swaps, HITL gate reconfigurations, new affected-person populations, and disclosure changes do not bypass the gate.
• HITL gates are verified as substantive, not just present in configuration, by sample-checking that reviewer SLA is met and override rationale is recorded.

Activities

A) Publish the per-archetype workflow implementation review checklist

One checklist per SM-Processes archetype, focused on the configuration and operational points where production reality most commonly drifts from the approved workflow design. Each item is a yes/no with a required evidence artifact (screenshot, config export, queue-log sample, decision-log sample, test record).

Common spine across all archetypes: - HITL gates actually present and substantive, sample-check that (a) the HITL gate fires for the declared trigger conditions (test with a synthetic trigger event and confirm the gate blocks progression), (b) reviewer SLA is being met (pull HITL queue logs and confirm median review time is within the declared SLA), and (c) override rationale is recorded in the queue log for a stratified sample of reviewed items (not just present as an optional field). - Art. 50 disclosure actually shown to users, pull product-flow analytics and confirm the disclosure element fires on every AI-touched interaction (not only on sampled sessions); screenshot-audit the deployed UI against the approved disclosure design from the DR record. - Decision logging actually capturing required fields, pull a decision-log sample and confirm all required fields (decision identifier, timestamp, AI recommendation, human decision if HITL, reviewer identity, override flag, affected-person reference) are present and populated at the rate expected from workflow throughput. - Override audit trail actually queryable, execute a sample query for a known override event; confirm the audit log returns the required fields (reviewer identity, rationale, timestamp, decision outcome) within the declared SLA. - Affected-persons rights surface actually responsive, sample-test the contestation path (submit a synthetic contestation request and confirm it is received, acknowledged, and routed to the correct review queue within the declared SLA). - Fallback / kill-switch actually testable, execute the fallback path or kill-switch test and record the result; confirm the AI component is bypassed or halted within the declared SLA.

Archetype-specific additions:

• Decision pipeline: Annex III registration status confirmed in SM-Processes inventory (not assumed from the DR record alone, confirm with Legal and the current regulatory register); Art. 22 lawful-basis documentation current and linked from the DR record; appeal / explanation path tested (submit a synthetic appeal and confirm the explanation is generated and returned within SLA); class-shift monitor confirmed wired and producing signal (pull a recent distribution snapshot and confirm it matches the declared monitoring design).

• Customer-facing flow: Art. 50 disclosure presence confirmed via product-flow analytics on a sampled traffic slice (not only the happy path); brand-safety filter active and tested (inject a known-bad AI output and confirm the filter intercepts it); escalation path from AI output to human agent tested end-to-end within the declared SLA.

• Human-AI collaboration chain: review-UI confirmed to surface AI rationale, confidence level, and at least one counterfactual (screenshot audit against approved UI design); reviewer-capacity model re-run against current staffing and volume (confirm SLA is still achievable); injection-defense confirmed (pull a review-UI session log and confirm no embedded content from AI output was executed in the UI).

• Back-office augmentation: tool scope bounded and confirmed in the deployed configuration (pull the AI component's tool-access config and compare against the DR-approved scope); classification-aware routing confirmed active (test with a synthetic sensitive output and confirm it triggers the review gate rather than direct downstream consumption); output-review gate confirmed wired and logging.

• Approval / review workflow: class-shift monitor data pulled and reviewed (approval rate by tier and by protected-characteristic proxy matches the declared monitoring design and has not drifted beyond the declared threshold); tier-routing logic confirmed in the deployed workflow config (compare routing rules against DR-approved logic).

• Content-generation workflow: copyright and brand-voice filter confirmed active (test with a known-bad generation and confirm the filter intercepts); output-review gate confirmed wired for material outputs (pull the output-review queue and confirm it is receiving the expected volume of items); downstream-input-validation confirmed (test with a generation containing injection syntax and confirm the downstream system rejects or sanitizes it).

• Knowledge-management workflow: provenance labels confirmed in a retrieval-result sample (pull a sample of recent retrieval events and confirm each chunk carries source, classification, and trust label); classification-aware retrieval confirmed active (query with a cross-classification test input and confirm it is rejected or filtered); injection-defense confirmed in the deployed prompt structure (review the deployed prompt template and confirm retrieved content is in a designated untrusted block).

B) Perform reviews at the right moments

Three triggers at L1:

• Go-live review: before the workflow begins processing real affected persons (or before a materially changed version does), verify the as-deployed configuration and operations against the DR-approved design. No go-live with a blocker finding open.
• Annual review: every active AI-embedded workflow reviewed at least annually; scheduled from the SM-Processes inventory (last-IR-date field linked to a review-due alert).
• Material-change review: any of the following triggers an ad-hoc review before the change affects affected persons: AI component swap (model version, model family, or underlying AI service changed); HITL gate configuration changed (routing, SLA, reviewer role, trigger conditions); new affected-person population added; Art. 50 disclosure removed or substantially changed; decision-logging scope reduced; contestation path changed; class-shift monitor disabled or reconfigured; workflow moved to a new jurisdiction with different regulatory obligations.

Reviews are evidence-based, screenshots, config exports, queue-log samples, and test records stored with the IR record. Target timebox: 45–90 minutes per workflow depending on archetype complexity.

Drift sources verified at L1 (without continuous tooling): - Workflow-tool config repos: review BPM model versions and workflow-step configuration changes since the last IR (Camunda BPMN file diff, Temporal workflow code diff, ServiceNow flow designer export, Argo workflow manifest diff). - HITL queue logs: review reviewer-throughput and override-rationale completion rate since the last IR. - Override-audit logs: review schema (required fields present) and completeness (entries present at expected rate given workflow volume). - Product-flow analytics: review where the AI step actually fires and compare to the approved design, confirm no silent bypass. - Decision-distribution snapshot: pull a recent approval-rate or decision-rate distribution and compare to the DR-approved monitoring baseline.

C) Track findings to closure

Every review produces zero or more findings. Each finding carries: - Severity: Critical (e.g., HITL gate absent or trivially bypassed on a High/Critical-tier workflow; Art. 50 disclosure absent on a customer-facing flow; decision log not capturing required fields for an Annex III workflow) / High / Medium / Low. - Owner: named workflow owner or team; not "the business team." - SLA: Critical blocker resolved before go-live or rollback required; High ≤7 days; Medium ≤30 days; Low ≤90 days or accepted residual. - Evidence: after-fix evidence artifact linked to the finding before closure.

Findings feed IM-Processes as issues and loop back to SR-Processes where a finding reveals that an REM row's cited evidence was inaccurate, the REM row is updated before the finding is closed.

Outcome Metrics (L1)

Process Metrics (leading)

• Annual review calendar populated from the SM-Processes inventory; workflows nearing review-due date visible in advance.
• Material-change trigger wired to SM-Processes inventory material-change events; reviews queued within 5 business days of a confirmed material change.
• Reviewer backlog aging, no single reviewer more than 3 workflows overdue.
• SR REM update loop active, % of IR findings that trigger an REM row update for the affected requirement.

Effectiveness Metrics (business value)

• Drift-caught-early rate, findings closed before they surface in a contestation request or an external audit.
• HITL substantiveness improvement, reviewer SLA adherence and override-rationale completion rate trending toward declared targets as the IR / SA feedback loop operates.
• Avoided-regulatory-finding stories, documented cases where IR caught a configuration regression before it was observed by a regulator or an affected person.

Success Criteria

• Per-archetype IR checklists published, owned, and linked from the SM-Processes inventory record and the DR decision record; all seven archetypes covered.
• Go-live, annual, and material-change review triggers wired to the SM-Processes inventory; 100% of new AI-embedded workflows in the last 90 days have a go-live IR record.
• ≥90% of active AI-embedded workflows carry a current-year IR record.
• All Critical / blocker findings resolved before go-live; High findings closed within 7 days with evidence linked.
• Findings-aging dashboard reviewed at least monthly by the program sponsor.

Maturity Level 2

Objective: Detect workflow configuration drift continuously for Critical and High-tier workflows via BPM-tool change events, HITL-throughput monitoring, decision-distribution monitoring, and Art. 50 disclosure UI verification; probe affected-persons rights-response timing recurrently; calibrate IR cadence per SM-Processes tier

At this level, implementation review stops being a point-in-time check and becomes a continuous signal for Critical and High-tier workflows. Drift sources are wired to automated detection. HITL-throughput monitoring alerts when reviewer SLA is missed or queues saturate. Decision-distribution monitoring detects drift in approval rates by class. The affected-persons rights-response path is tested recurrently, not trusted from design text alone.

Dependencies

• IR-Processes L1 (required): per-archetype checklists and findings workflow must be established.
• SM-Processes L2 (required): the risk-tier rubric drives IR cadence and depth per the tier-treatment matrix (Critical: go-live + semi-annual + continuous drift; High: go-live + annual + material change; Medium: go-live + annual; Low: go-live).
• SA-Processes L2 (required): tier-conditional pattern overlays establish the "correct" baseline that continuous drift detection measures against.
• Supports / unblocks: ST-Processes L2 (tests run against the continuously verified workflow configuration), EH-Processes L2, ML-Processes L2 (monitoring configuration verified here feeds detections).

Desired Outcomes

• Configuration drift on Critical-tier workflows is detected within days, not months.
• HITL-throughput saturation and reviewer-SLA misses are detected automatically, before they become systemic rubber-stamping.
• Decision-distribution drift (approval rate by class diverging from the DR-approved baseline) is detected continuously for Critical-tier workflows.
• Art. 50 disclosure presence in the deployed UI is verified via A/B-test monitoring rather than a one-time screenshot audit.
• Affected-persons rights-response timing is measured against the declared SLA on a recurrent basis, not trusted from process documentation alone.
• IR cadence visibly differentiates by tier: Critical gets semi-annual reviews plus continuous drift detection; Low gets go-live only.

Activities

A) Continuous drift detection from BPM-tool change events, HITL logs, decision-distribution monitoring, and product-flow analytics

Wire the following signal sources to an automated drift-detection pipeline for Critical and High-tier workflows:

• BPM-tool change events: workflow-config webhooks from Camunda / Temporal / Argo / ServiceNow emit events on BPM model version changes; any change to HITL gate configuration, routing rules, or AI-step parameters triggers an automated diff against the DR-approved baseline; material deviations open an IR finding automatically.
• HITL-throughput monitoring: HITL queue telemetry monitored for (a) reviewer SLA miss (median review time exceeds declared SLA for the archetype and tier, alert within 24 hours); (b) queue saturation (queue depth exceeds the capacity declared in the reviewer-capacity model, alert when queue depth implies SLA miss within 4 hours); (c) override-rationale completion drop (rate of rationale-field completion drops below the declared minimum, alert within 24 hours).
• Decision-distribution monitoring: decision-rate and approval-rate distribution by class compared against the DR-approved baseline on a rolling 30-day window; drift beyond the declared threshold (e.g., approval rate for a protected-characteristic proxy shifts by more than the declared alert threshold) opens an IR finding.
• Art. 50 disclosure UI A/B-test verification: product-flow analytics monitored for the disclosure element's presence rate across all traffic slices; any traffic slice where the disclosure element is absent or fires at <100% rate opens an IR finding within 24 hours; A/B-test framework changes that could affect disclosure presence wired to the change-event trigger.
• Affected-persons rights-response monitoring: DSAR-equivalent timing for contestation requests measured recurrently (monthly for Critical-tier); median response time compared against the declared contestation-path SLA; breaches open an IR finding.

Detection latency targets: Critical-tier drift detection ≤7 days from change event to finding opened; High-tier ≤30 days.

B) Recurrent probe of HITL substantiveness and rights-response path

HITL substantiveness and the affected-persons rights-response path are probed recurrently rather than trusted from process documentation:

• HITL substantiveness probe: for Critical and High-tier workflows, a stratified random sample audit of HITL queue decisions is run monthly (Critical) and quarterly (High). The audit checks: (a) reviewer decision time (unusually short decisions, below a declared minimum meaningful review time, are flagged as possible rubber-stamps); (b) override-rationale quality (rationale entries that are empty, boilerplate, or below the declared minimum character count are flagged); (c) decision variance (if the human decision matches the AI recommendation at ≥98% of the time across a sample, the HITL gate is flagged as potentially non-substantive and escalated to the program sponsor and Business owner). These thresholds are calibrated to the archetype and tier by the SR-Processes pack.
• Affected-persons rights-response probe: a synthetic contestation request is submitted monthly (Critical) and quarterly (High); response receipt, acknowledgment, routing to review queue, and explanation generation are all timed and compared against the declared SLA; failures open an IR finding with severity matching the rights-impact level of the workflow.

Probe cadence: Critical-tier, monthly; High-tier, quarterly.

C) Tier-calibrated IR cadence

Publish and enforce per the SM-Processes L2 tier-treatment matrix: - Critical: go-live + semi-annual + material-change-triggered + continuous drift detection. - High: go-live + annual + material-change-triggered. - Medium: go-live + annual. - Low: go-live + re-review on material change.

Every workflow in the SM-Processes inventory has a last-IR-date and next-IR-due field; Critical-tier workflows with no IR in the last 180 days are escalated to the program sponsor.

D) Tier-calibrated IR cadence

Publish and enforce per the SM-Processes L2 tier-treatment matrix. Every workflow in the SM-Processes inventory carries a last-IR-date and next-IR-due field; Critical-tier workflows with no IR in the last 180 days are escalated to the program sponsor. IR findings generated by continuous drift detection are automatically severity-tagged and routed to IM-Processes with owner pre-populated from the SM-Processes inventory.

Outcome Metrics (L2)

Process Metrics (leading)

• Drift-detection pipeline health monitored, % Critical workflows producing a fresh signal in the last 7 days; on-call alert if feed silent for >48 hours.
• HITL substantiveness audit calendar maintained; missed audits tracked as process-metric failures.
• Rights-response probe calendar maintained; missed probes tracked.
• IR backlog tier-aware; Critical-tier findings never wait behind Low-tier queue items.

Effectiveness Metrics (business value)

• HITL rubber-stamp risk reduced, % of HITL audits where decision variance drops below the 98% threshold (trending toward 0 for Critical-tier).
• Drift caught before ST/ML detections or regulatory inquiries, trend measured over quarters.
• Reduced audit findings on operational claims, external auditors (ISO 42001, sector regulators) find IR evidence sufficient without supplemental screenshots or interviews.

Success Criteria

• ≥90% of Critical-tier workflows under continuous drift detection; median detection latency ≤7 days.
• HITL substantiveness probe and affected-persons rights-response probe completed monthly for Critical-tier and quarterly for High-tier, with ≥100% coverage of Critical/High-tier workflows.
• Tier-cadence adherence ≥95%; Critical-tier findings aged per the SM-Processes L2 tier-treatment matrix SLAs.
• Decision-distribution monitoring operational for Critical-tier workflows; distribution drift beyond declared thresholds opens IR findings.

Maturity Level 3

Objective: Daily attestation per Critical-tier workflow confirming HITL substantiveness, Art. 50 disclosure presence, decision-logging completeness, and override-audit freshness; drift opens an IM-Processes ticket automatically; contribute attestation schemas to ISO/IEC 42005 and sector AI governance bodies

At this level, the operational posture of every Critical-tier AI-embedded workflow is attested daily rather than periodically reviewed. Workflow-execution telemetry across HITL queues, decision-logging pipelines, Art. 50 disclosure analytics, and override-audit logs produces a composite attestation signal. Drift automatically opens an IM-Processes ticket. Per-archetype operational baseline schemas are contributed to ISO/IEC 42005 and sector AI governance bodies.

Dependencies

• IR-Processes L2 (required): continuous drift detection, HITL substantiveness probing, rights-response probing, and tier-calibrated cadence must be in place.
• SA-Processes L3 (required): externalized patterns supply the attestation frame for automated compliance checks.
• ML-Processes L2+ (required): runtime signals (HITL-throughput telemetry, decision-distribution telemetry, disclosure-presence analytics) are evidence sources the attestation pipeline reads.
• SR-Processes L3 (alignment): machine-readable REM schema provides the evidence-freshness signals the attestation pipeline validates against.

Desired Outcomes

• Every Critical-tier AI-embedded workflow produces a daily attestation signal, HITL gate health, decision-logging completeness, Art. 50 disclosure presence, and override-audit freshness are continuously within tolerance.
• Drift automatically opens an IM-Processes ticket; the program does not wait for the next scheduled review to act.
• Per-archetype operational baseline schemas, what "correctly running" looks like for each workflow archetype at each tier, are published to ISO/IEC 42005 working groups and applicable sector AI governance bodies.
• IR reviewer-hours per workflow trend down as attestation absorbs routine checks; reviewers focus on novel workflow configurations and exception escalations.

Activities

A) Daily attestation signal for Critical-tier workflows

Each Critical-tier AI-embedded workflow produces a daily composite attestation signal covering four dimensions:

1. HITL gate health: HITL-queue telemetry confirms reviewer SLA is met (median review time within declared SLA), override-rationale completion is at or above declared minimum, and queue depth is below saturation threshold. Anomalies open a finding automatically.

2. Decision-logging completeness: decision-logging pipeline confirms all required fields are populated at expected volume; any field dropout or throughput drop below expected rate opens a finding automatically.

3. Art. 50 disclosure presence: product-flow analytics confirm the disclosure element fires on ≥99.9% of AI-touched interactions across all traffic slices; any slice falling below threshold opens a finding within the hour.

4. Override-audit freshness: override-audit log confirms entries are being written at the rate implied by HITL queue throughput; schema drift (required fields missing from new entries) or entry-rate drop below expected rate opens a finding automatically.

Attestation artifacts are machine-readable, signed, and stored in the SM-Processes inventory record. They are regulator-consumable for EU AI Act Art. 9 risk-management evidence, Art. 26 deployer-duty documentation, and ISO/IEC 42001 AIMS operational records. Drift opens an IM-Processes ticket automatically; the ticket carries the drift dimension, the specific signal that failed tolerance, and a link to the DR decision record.

B) Contribute per-archetype operational baseline schemas

Publish per-archetype IR operational baseline schemas, defining what "correctly running" looks like for each AI-embedded workflow archetype at each SM-Processes tier, to: - ISO/IEC 42005 (AI impact assessment standard), operational monitoring criteria for AI-embedded workflows; machine-readable format where the standard supports it. - Sector AI governance bodies (financial-services AI supervisory guidance, healthcare AI governance, public-sector AI governance), per-archetype operational criteria calibrated to sector-specific HITL and logging obligations. - OWASP SAMM AI extensions, Verification function, Implementation Review stream; practitioner-level checklist items and evidence-type definitions for AI-embedded workflow archetypes.

Internal practice remains aligned to the published external versions; internal-only deviations are proposed as upstream changes.

C) Automated drift-to-IM escalation and post-incident feedback loop

• All IR findings, whether from daily attestation or periodic reviews, flow into IM-Processes automatically with severity and SLA pre-populated from the SM-Processes L2 tier-treatment matrix.
• IM-Processes SLA clock starts when the finding is opened; overdue Critical findings escalate to the program sponsor automatically at 50% and 100% of the SLA window.
• Post-incident reviews in IM-Processes that touch a workflow operational control automatically re-examine the IR record for the affected workflow, was the drift detectable earlier? What attestation dimension would have caught it? The answer updates the attestation rule and the IR checklist.

Outcome Metrics (L3)

Process Metrics (leading)

• Attestation-pipeline health monitored, % Critical workflows producing a fresh attestation signal in the last 24 hours; on-call paged if any Critical workflow silent for >24 hours.
• Schema publication pipeline, at least one schema in-draft, in-review, or published at any time.
• IM escalation automation tested quarterly, confirm Critical-finding auto-escalation fires correctly for a synthetic finding.
• Post-incident IR feedback loop active, % of IM post-incident reviews that produce an attestation rule update.

Effectiveness Metrics (business value)

• IR reviewer-hours per workflow trending down as attestation absorbs routine checks.
• Zero Critical-tier go-live events where the DR-approved design and the running workflow are materially different, attestation enforces what was once a periodic audit.
• Regulator inquiries on Art. 26 deployer-duty documentation answered via machine-readable attestation artifacts without manual assembly; audit findings approaching zero.
• External recognition, operational baseline schemas cited by peer organizations, sector bodies, or regulatory guidance documents.

Success Criteria

• Daily attestation operating for ≥90% of Critical-tier workflows across all four dimensions (HITL gate health, decision-logging completeness, Art. 50 disclosure presence, override-audit freshness); deviations auto-opening IM-Processes tickets within 1 hour.
• Zero Art. 50 disclosure-presence violations for Critical-tier workflows persisting beyond 1 hour; override-audit completeness violations trending toward 0.
• Per-archetype operational baseline schemas published to ISO/IEC 42005 or sector AI governance bodies with documented external adoption.
• IR reviewer-hours per Critical workflow per year trending down over two consecutive quarters.

Key Success Indicators

Level 1: - Per-archetype IR checklists published, one per SM-Processes archetype (decision pipeline, customer-facing flow, human-AI collaboration chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), covering HITL gate substantiveness verification, Art. 50 disclosure presence check, decision-logging completeness check, override-audit-trail queryability test, affected-persons rights-response test, and fallback / kill-switch test. - Go-live, annual, and material-change review triggers wired to the SM-Processes inventory; 100% of new AI-embedded workflows in the last 90 days have a go-live IR record; ≥90% of active workflows carry a current-year IR record. - All Critical / blocker findings resolved before go-live; High findings closed within 7 days with evidence linked; findings-aging dashboard reviewed monthly by the program sponsor. - SR REM update loop active, IR findings that reveal stale or inaccurate REM evidence trigger REM row updates before the finding is closed.

Level 2: - ≥90% of Critical-tier workflows under continuous drift detection (BPM-tool change events, HITL-throughput monitoring, decision-distribution monitoring, Art. 50 disclosure presence monitoring); median detection latency ≤7 days. - HITL substantiveness probe completed monthly for Critical-tier and quarterly for High-tier; workflows where human decision matches AI recommendation at ≥98% of the time in a sample are escalated to the program sponsor and Business owner. - Affected-persons rights-response probe completed monthly for Critical-tier and quarterly for High-tier; response-time SLA breaches open IR findings. - Tier-cadence adherence ≥95%: Critical on semi-annual + continuous, High on annual, Medium on annual, Low on go-live + material-change.

Level 3: - ≥90% of Critical-tier workflows producing a daily attestation signal across all four dimensions; deviations auto-opening IM-Processes tickets within 1 hour. - Zero Art. 50 disclosure-presence violations for Critical-tier workflows persisting beyond 1 hour; zero override-audit completeness violations for Critical-tier workflows. - Per-archetype operational baseline schemas published to ISO/IEC 42005 or sector AI governance bodies with documented adoption. - IR reviewer-hours per Critical workflow per year trending down over two consecutive quarters.

Common Pitfalls

Level 1: - ❌ IR treated as a one-time go-live formality, no annual re-review and no material-change trigger; HITL gate reconfiguration and AI component swaps ship without triggering a review; the approved design and the running workflow diverge silently. - ❌ Reviewers accept the DR decision record as evidence without checking the deployed queue configuration, the HITL gate is declared as requiring a rationale but the deployed interface has no rationale field; the checklist item is checked without opening the queue interface. - ❌ Art. 50 disclosure verified by checking the staging environment, the deployed production UI has a different A/B test variant where the disclosure was removed; the IR record is correct for staging but wrong for production. - ❌ HITL substantiveness is assumed from reviewer training records, queue logs are never pulled; decision variance and reviewer SLA are never measured; rubber-stamping accumulates without detection. - ❌ Affected-persons rights-response path is documented in the process map but never tested, IR checklist has a "contestation path: designed" box that is checked without submitting a synthetic request and measuring response time. - ❌ Material-change trigger is not wired to SM-Processes inventory events, AI component swaps and HITL gate reconfigurations ship to production without triggering an IR.

Level 2: - ❌ BPM-tool change events are ingested but generate no IR findings on deltas, the pipeline exists but automated finding creation was never configured; drift detection is manual in practice. - ❌ HITL-throughput monitoring alerts fire but are treated as operations noise rather than IR findings, SLA misses accumulate without being opened as findings in IM-Processes. - ❌ Decision-distribution monitoring is configured for the approval rate overall but not by protected-characteristic proxy, class-shift drift is undetectable. - ❌ Art. 50 disclosure monitoring covers the happy path only, A/B-test variants that remove the disclosure element are not monitored; the disclosure element disappears from 20% of traffic for weeks before the IR detects it. - ❌ Tier-calibrated cadence exists on paper but Critical and Low-tier workflows sit in the same review queue with no prioritization; Critical-tier workflows wait behind Low-tier backlogs.

Level 3: - ❌ Daily attestation signals show green across all Critical workflows but the underlying checks cover only decision-log volume, HITL gate health, override-rationale completion, and Art. 50 disclosure presence by traffic slice are not checked; attestation is cosmetic. - ❌ Operational baseline schemas published externally diverge from internal practice, what is published reflects the L1 checklist; internal practice has advanced to L2 continuous detection; external adopters build on a stale baseline. - ❌ Attestation-exception queue overwhelms the team because HITL-throughput thresholds are too sensitive, every reviewer lunch-hour queue fluctuation opens an IR finding; reviewers suppress the signal source rather than tune the sensitivity threshold. - ❌ Post-incident IR feedback loop exists in policy but never fires in practice, IM-Processes post-incident reviews do not include the IR-record re-examination step; attestation rules never update from incident learning.

Practice Maturity Questions

Level 1: 1. Is there a published, per-archetype IR checklist, one per SM-Processes archetype (decision pipeline, customer-facing flow, human-AI collaboration chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), covering HITL gate substantiveness verification (gate fires, SLA met, rationale recorded), Art. 50 disclosure presence check, decision-logging completeness check, override-audit-trail queryability test, affected-persons rights-response test, and fallback / kill-switch test? 2. Do 100% of new AI-embedded workflows going live in the last 90 days carry a go-live IR record, and do ≥90% of all active workflows carry a current-year IR record, with material-change triggers wired to SM-Processes inventory events, Critical / blocker findings resolved before go-live, and High findings closed within 7 days with evidence linked? 3. Are findings severity-tagged and tracked in IM-Processes with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR REM row update before the finding is closed?

Level 2: 1. Are ≥90% of Critical-tier AI-embedded workflows under continuous drift detection, via BPM-tool change events, HITL-throughput monitoring, decision-distribution monitoring, and Art. 50 disclosure presence monitoring, with median detection latency ≤7 days and automated finding creation on material deviations? 2. Are HITL substantiveness probes completed monthly for Critical-tier and quarterly for High-tier, including decision-variance audits (escalation if ≥98% match rate) and override-rationale quality checks, and are affected-persons rights-response probes completed on the same cadence, with response-time SLA breaches opening IR findings? 3. Are 100% of Critical/High-tier workflows covered by HITL substantiveness and rights-response probes in the current period, and is tier-cadence adherence ≥95% with Critical-tier findings aged per the SM-Processes L2 tier-treatment matrix SLAs?

Level 3: 1. Are ≥90% of Critical-tier AI-embedded workflows producing a daily attestation signal across all four dimensions (HITL gate health, decision-logging completeness, Art. 50 disclosure presence, override-audit freshness), with deviations auto-opening IM-Processes tickets within 1 hour and zero Art. 50 disclosure-presence violations for Critical-tier workflows persisting beyond 1 hour? 2. Has the program published per-archetype operational baseline schemas to ISO/IEC 42005 or sector AI governance bodies, with documented adoption and internal practice aligned to the published versions, and is IR reviewer-hours per Critical workflow per year trending down over two consecutive quarters? 3. Is the post-incident IR feedback loop operational, IM-Processes post-incident reviews include a mandatory IR-record re-examination step, and ≥1 attestation rule update is produced per material incident, ensuring incident learning continuously improves the attestation coverage?

Document Version: HAIAMM v3.0 Practice: Implementation Review (IR) Domain: Processes Last Updated: 2026-05-14 Author: Verifhai