HAIAMM v3.0, Processes Domain Handbook

AI/HAI Process Assurance, security of the business workflows the organization operates that embed AI/HAI

Version: 3.0 Domain: Processes Audience: Security, Privacy/Legal, Compliance, Internal Audit, Operations, Business Process Owners, AI/ML Engineering, HR Use: Conduct a maturity assessment of the AI/HAI Process Assurance program, and build the practices that move it from Foundational to Industry-Leading.

Preface

This handbook is a self-contained, practitioner-facing document. Read it end to end to understand the Processes domain of HAIAMM, or jump to Part IV to perform an assessment.

The handbook makes three commitments to the reader:

1. Fundamentals first. It teaches the load-bearing practices an organization must have to claim mastery of the security of the AI/HAI-embedded business workflows it operates, not a catalog of everything one could do.
2. Measurable by default. Every activity prescribed in these pages is paired with at least one outcome metric (with a baseline, a target, and a source). Activity counts are not metrics; outcomes are.
3. Self-contained. The document does not require the reader to follow links, open companion files, or chase references. Every concept used in the assessment is defined inside these pages.

If a statement in this handbook treats AI as a tool performing security rather than the AI-embedded workflow as the subject being secured, that statement is wrong. Flag it.

Table of Contents

Part I, Domain Overview

1. About this handbook
2. The Processes domain in v3.0 terms
3. Why a domain-specific handbook
4. The seven AI/HAI workflow archetypes
5. Domain boundary rules
6. Stakeholders and roles
7. How to use this handbook

Part II, Foundations

1. The four Business Functions in this domain
2. The three maturity levels
3. HAI-specific threat tactics (EA, AGH, TM, RA)
4. The priority compliance map
5. Shadow AI in the Processes domain (ungoverned AI-embedded workflows)
6. Metrics taxonomy

Part III, The Twelve Practices in the Processes Domain

1. Strategy & Metrics (SM)
2. Policy & Compliance (PC)
3. Education & Guidance (EG)
4. Threat Assessment (TA)
5. Security Requirements (SR)
6. Secure Architecture (SA)
7. Design Review (DR)
8. Implementation Review (IR)
9. Security Testing (ST)
10. Environment Hardening (EH)
11. Issue Management (IM)
12. Monitoring & Logging (ML)

Part IV, Maturity Assessment Workbook

1. How the assessment works
2. Scoring methodology
3. The questionnaire (108 questions)
4. Practice-level rollup
5. Domain-level rollup
6. Improvement roadmap template

Part V, Reference

1. Glossary
2. Reference frameworks
3. Change log

Part I, Domain Overview

1. About this handbook

HAIAMM is the Human-Assisted Intelligence Assurance Maturity Model. It is an AI assurance maturity model, structured after OWASP SAMM and BSIMM in shape, and scoped to AI/HAI in content. HAIAMM has six domains, Software, Data, Endpoints, Infrastructure, Vendors, Processes, and twelve practices that apply across all six.

This handbook covers the Processes domain. It contains:

• A definition of what the Processes domain is and is not.
• The twelve practices, each described in Processes-domain terms with three maturity levels (Foundational, Comprehensive, Industry-Leading).
• A complete maturity assessment workbook with 108 yes/no questions and a scoring methodology.
• A reference section with a glossary and the major frameworks HAIAMM aligns with.

This is one of six domain handbooks. Processes-specific assessment questions live only in this handbook; the Software handbook contains only Software questions, the Data handbook only Data questions, and so on.

2. The Processes domain in v3.0 terms

The Processes domain governs the business workflows the organization operates that embed AI/HAI, the human-and-AI workflows that make consequential decisions, deliver customer experiences, and run back-office operations with AI in the loop. The organization operates these workflows itself; the AI components inside them may be built in-house (Software domain) or sourced from vendors (Vendors domain), but the workflow that wraps the AI step is governed here.

In scope:

• Decision pipelines, workflows in which AI output materially drives a decision affecting a person (credit, hiring, benefits, insurance underwriting, content moderation with legal effect).
• Customer-facing flows, workflows in which AI output reaches a customer directly (chatbots that respond, AI-drafted responses, conversational interfaces, AI-generated content surfaced to customers).
• Human-AI collaboration chains (HITL chains), workflows in which an AI recommendation is followed by a substantive or rubber-stamp human review before action.
• Back-office augmentation, workflows in which AI assists internal operations (AI-assisted research, AI-drafted internal documents, AI-summarized reports).
• Approval and review workflows, workflows that classify, route, and approve internal artifacts using AI scoring (resume screening, invoice triage, expense approval).
• Content-generation workflows, workflows that produce material content with AI for publication, customer communication, or downstream consumption.
• Knowledge-management workflows, workflows backed by RAG retrieval over an internal corpus that serve queries to employees or customers.

Out of scope of the Processes domain:

• The AI software that produces the recommendations, that is the Software domain (and is cross-referenced).
• The AI tools the organization buys to embed in these workflows, that is the Vendors domain.
• The endpoints on which the AI surface is delivered, that is the Endpoints domain.
• The data corpora the workflows process, that is the Data domain.
• The infrastructure that hosts the workflow orchestrator, that is the Infrastructure domain.

The subject of every cell in this handbook is the AI-embedded business workflow the organization operates. The workflow is what is being secured.

3. Why a domain-specific handbook

Operating an AI-embedded business workflow is not the same as operating a classic business process. Five reasons motivate the standalone handbook:

• Decision-laundering risk. A workflow that routes a credit, hiring, or benefits decision through an AI recommendation and then through a rubber-stamp human review produces an outcome the organization treats as "human-made" but that no human meaningfully reviewed. The decision is laundered through the workflow design; affected persons have no real recourse.
• Regulators have addressed AI-embedded workflows specifically. EU AI Act Art. 14 imposes human-oversight obligations on high-risk AI systems; Art. 22 of GDPR places safeguards on automated decisions with legal or similarly significant effect; Art. 50 of the EU AI Act requires disclosure when a person interacts with an AI system; Art. 26 places deployer duties on the organization that operates the workflow; Annex III enumerates high-risk use categories; sector regulators (FCRA, EEOC, NYC LL 144, CO SB-21-169, FINRA, FDA, HIPAA) reach AI-embedded workflows in their domains.
• Shadow AI in business processes is the program's primary L1 outcome. Function teams add AI-routing rules to ticketing systems, embed AI scoring in approval workflows, and use consumer GenAI to augment back-office tasks, all without governance. The shadow surface is harder to discover than in Software or Data because business workflows are often informal and undocumented in code.
• HITL design is a substantive engineering discipline, not a checkbox. "Human in the loop" without reviewer-capacity modeling, override authority, rationale recording, anchoring-prevention design, and substantive-review SLA enforcement produces rubber-stamp HITL that satisfies no Art. 14 oversight requirement and creates direct Art. 22 exposure when an affected person contests.
• Seven archetypes, one program. The seven AI/HAI workflow archetypes behave differently enough that threats, requirements, reference patterns, design reviews, and tests are archetype-keyed throughout the handbook.

4. The seven AI/HAI workflow archetypes

Most of the practices in this handbook key their content to seven archetypes. Knowing the archetypes well is a prerequisite for using the handbook.

1. Decision pipeline. A workflow in which AI output materially drives a decision affecting a person, credit approve/deny, hiring screen pass/fail, benefit eligibility, insurance underwriting, content moderation with legal effect. Risk shape: wrongful automated decisions, decision-laundering through rubber-stamp HITL, silent decision-drift as thresholds shift, adversarial input flipping borderline decisions, class-shift creating disparate impact, GDPR Art. 22 contestation exposure, EU AI Act Annex III obligations.

2. Customer-facing flow. A workflow in which AI output reaches a customer directly, a chatbot session, an AI-drafted email, a conversational UI, an AI-generated explanation surfaced to the customer. Risk shape: EU AI Act Art. 50 disclosure failure or suppression, prompt injection via customer input propagating to downstream systems (AGH), hallucination reaching customer, brand-safety failure, customer-data egress via the AI step.

3. Human-AI collaboration chain (HITL chain). A workflow in which an AI recommendation is presented to a human reviewer who decides whether to approve, override, or escalate before action. Risk shape: rubber-stamp HITL (the dominant failure mode, RA TTP), reviewer-side prompt injection via review-UI display, reviewer overload, anchoring bias to the AI recommendation, override-without-rationale.

4. Back-office augmentation. A workflow in which AI assists internal operations, AI-summarized reports, AI-assisted research, AI-drafted internal documents, back-office assistants. Risk shape: confidential-data egress to AI provider (TM), tool-scope creep (EA), AI output incorporated without review, regulated data flowing to uncleared AI tools.

5. Approval / review workflow. A workflow that classifies, routes, and approves internal artifacts using AI scoring, resume screening, invoice triage, expense approval, suspicious-activity routing. Risk shape: classifier-threshold drift, queue-saturation auto-approve fallback, class-shift on protected-characteristic groups, approval-bypass via classifier exploit, biased outcome accumulation.

6. Content-generation workflow. A workflow that produces material content with AI for publication, customer communication, or downstream consumption, marketing copy, support-response drafts, internal communications, regulatory submissions. Risk shape: harmful or non-compliant content reaching publication, copyright violation, brand-voice violation, injection syntax in generated content reaching downstream systems (AGH), content-attribution gaps.

7. Knowledge-management workflow. A workflow backed by RAG retrieval over an internal corpus that serves queries to employees or customers, knowledge bases, internal search, customer self-service. Risk shape: RAG-poisoning via adversarial documents (ATLAS TA0003, AGH), retrieval-extraction by malicious insiders (TM), cross-classification retrieval bleed, misinformation propagation via stale or poisoned content.

A single workflow can compose more than one archetype simultaneously, a customer loan-application flow is both a decision pipeline and a customer-facing flow; a customer support workflow may compose a chatbot, a back-office AI assistant, and an approval/review workflow. Threat libraries, requirements packs, reference patterns, design reviews, and tests in this handbook accommodate that.

5. Domain boundary rules

When in doubt about whether something belongs in the Processes domain, ask: what is being secured, the workflow that makes the decision, or the AI component that produces the recommendation?

• If the concern is the workflow design (HITL placement, disclosure UX, decision-logging schema, contestation path, approval-chain integrity): it is a Processes artifact.
• If the concern is the AI component itself (the model, the training data, the inference service, the prompt template): it is a Software / Data / Infrastructure / Vendors concern. The two cross-reference.

Common boundary cases:

• A credit-decision workflow that uses an internally built LLM for risk scoring is a Processes artifact (decision pipeline archetype); the LLM is a Software artifact (model-serving service); the credit-bureau data feed is a Data artifact; the workflow's HITL gate, Art. 22 lawful-basis documentation, and contestation path are Processes concerns.
• A customer-support chatbot using a vendor LLM is a Processes artifact (customer-facing flow archetype); the vendor LLM is a Vendors artifact; the prompt-template repo is a Software artifact; the workflow's Art. 50 disclosure UX, escalation-to-human path, and prompt/completion logging are Processes concerns.
• An employee-facing knowledge base backed by RAG retrieval over internal documents is a Processes artifact (knowledge-management workflow archetype); the retrieval pipeline is a Software artifact; the vector store is a Data artifact; the workflow's per-role retrieval scoping and provenance display are Processes concerns.

6. Stakeholders and roles

The AI/HAI Process Assurance program is cross-functional by design. The following roles appear throughout this handbook:

• Executive sponsor. Typically the CISO co-sponsored by the COO or Chief Process Owner; co-sponsorship by the Chief Risk Officer, General Counsel, and DPO/CPO is common where Annex III or Art. 22 workflows are in scope. Owns budget, scope, and decision rights for the program.
• Program lead. Operationally accountable for the program day-to-day. Often the Privacy Engineering or AI Governance lead. Maintains the AI/HAI process inventory, runs the working group, owns the metrics.
• Cross-functional working group. Security, Privacy/Legal, Compliance, Internal Audit, Operations, AI/ML Engineering, HR (acceptable use), and Business Process Owners from each function embedding AI in workflows. Meets at least monthly.
• Business Process Owners. Named owners for each in-scope workflow archetype, accountable for the workflow's design, operation, and outcomes. The deployer-duty owner under EU AI Act Art. 26 is typically the Business Process Owner.
• Intake reviewers. A small population trained to assess AI-embedded workflows against the threat library, the requirements pack, and the priority compliance map. Drawn from AppSec, Privacy, Compliance, and the business function representatives.
• Architect reviewers. Senior architects with sign-off authority on design reviews for AI-embedded workflows; for full-lane reviews, Privacy and Legal participate alongside the architect.
• Reviewer pool. For HITL chains and decision pipelines, the human reviewers who substantively assess AI recommendations before action. Reviewer capacity, rotation, and substantiveness are measured.
• DPO / CPO. Sign-off authority on Art. 22 and Annex III workflows; named owner for the FRIA evidence and the affected-persons rights surface.

7. How to use this handbook

Three modes of use are supported:

• Read it linearly. Parts I and II ground the reader in the domain and foundations. Part III walks the twelve practices in the Processes-domain context. Part IV provides the assessment instrument. Part V is reference.
• Run an assessment. Skim Parts I and II for context (one to two hours), then go directly to Part IV. The 108 questions are organized by practice and by maturity level, with explicit evidence prompts. Scoring methodology and rollup tables follow.
• Build a program from scratch. Read Part II carefully, then implement the twelve practices' Level 1 in the order described in Part II's dependency text. Use the Level 1 questions in Part IV as a self-check for completeness.

The questions in Part IV are duplicated as a per-practice "Practice Maturity Questions" section at the end of each practice in Part III. They are the same questions; the duplication is deliberate so the practice-by-practice reader sees the assessment instrument inline.

Part II, Foundations

8. The four Business Functions in this domain

The twelve practices group into four Business Functions. Each function exists for a distinct intent. Every practice belongs to exactly one function.

Governance, Strategy & Metrics (SM), Policy & Compliance (PC), Education & Guidance (EG). Establish why, what, who, and how: the program's strategic frame, its enforceable rules, and the workforce literacy that makes everything downstream possible. In this domain, Governance answers: who owns AI-embedded workflow risk, what policies apply, what training every process owner and reviewer must complete, and how a new AI-embedded workflow enters a sanctioned production state.

Building, Threat Assessment (TA), Security Requirements (SR), Secure Architecture (SA). Decide what could go wrong, what the workflow must do about it, and how the workflow is shaped to do it, before go-live begins. In this domain, Building answers: what threats AI-embedded workflow archetypes carry, what requirements every workflow must meet, what reference patterns process designers should reach for.

Verification, Design Review (DR), Implementation Review (IR), Security Testing (ST). Prove that the designed workflow, the implemented workflow, and the running workflow actually meet the Building-function outputs. In this domain, Verification answers: did the workflow design follow the SA reference pattern, do the live BPM configuration and HITL queue match the design, and does the workflow actually behave correctly under adversarial probes.

Operations, Environment Hardening (EH), Issue Management (IM), Monitoring & Logging (ML). Run the program safely in production, harden the workflow envelope, manage the issues, and watch what is actually happening. In this domain, Operations answers: which controls keep sanctioned workflows frictionless and unsanctioned AI steps observable, where AI-embedded workflow issues go, and what telemetry produces deployer-duty and Art. 14 oversight evidence on demand.

Cross-function rule: progress in one function without the others is unstable. The handbook is balanced across the four by design. L1 build order follows the dependency graph: SM precedes everything; PC and EG follow SM; TA, SR, and SA follow Governance; DR and ST run after SA L1 exists; IR follows DR; EH, IM, and ML form the Operations layer that depends on SM inventory, SA patterns, and PC policies all being in place.

9. The three maturity levels

Every cell in this handbook is one of three maturity levels. The levels are cumulative, Level 2 assumes Level 1 is in place; Level 3 assumes Level 2 is in place.

Level 1, Foundational. Stand up the minimum viable capability. Discover what AI-embedded workflows the organization operates, publish the core policies, run the first version of the controls, baseline the metrics. Typical outputs: an inventory of workflows across all seven archetypes, short published policies (AI-in-Business-Process, HITL Standards, Intake / Sanction Gate), per-archetype threat models, per-archetype requirements packs, per-archetype reference patterns, first detections, first logging baselines, AI-specific workflow incident playbook. Reality check: if the program cannot answer "what AI-embedded workflows do we operate, what rules apply to them, and who is the deployer-duty owner" within a week, it is not at Level 1.

Level 2, Comprehensive. Calibrate the program's intensity by risk tier. Move from one-size-fits-all to differentiated depth. Replace point-in-time activities with continuous validation. Typical outputs: a published risk-tier rubric, a tier-treatment matrix, per-tier calibrated activities, per-workflow deep threat models for Critical-tier, template-encoded reference patterns with conformance test suites, scenario-based design reviews with FRIA workshops for Annex III, continuous workflow-drift detection, HITL substantiveness probes, per-tier red-team cadence, tier-calibrated hardening, tier-calibrated logging. Reality check: if the same review effort goes to a Low-tier internal back-office augmentation workflow and to a Critical-tier customer-facing decision pipeline, the program is not at Level 2.

Level 3, Industry-Leading. Automate the substrate. Benchmark externally against peers. Contribute back to the AI-assurance ecosystem. Typical outputs: signal-driven inventory and tier updates, machine-readable requirements with workflow-execution attestation, continuous compliance attestation, automated canary-input adversarial testing on production workflows, IaC-driven hardening with adaptive tightening from ML and IM signals, detection-as-code, external benchmarking briefs, contributions to MITRE ATLAS (process-level), OECD AI, ISO/IEC 42005, CSA AI Safety Initiative, sector ISACs. Reality check: if all activity is still internally generated, no external contributions, no benchmarking deltas, no automation replacing routine review work, the program is mature for its own purposes but is not industry-leading.

10. HAI-specific threat tactics (EA, AGH, TM, RA)

Four AI-specific threat-tactic categories appear throughout this handbook. In the Processes domain they manifest in the workflows that embed AI.

EA, Excessive Agency. The workflow grants the AI step broader scope than the use case requires, an AI participating in consequential decisions with no accountability boundary, a back-office assistant with unbounded tool scope, an autonomous customer-facing flow without circuit breakers. The over-broad workflow grant.

AGH, Agent Goal Hijack. Indirect injection via customer-supplied content propagating to downstream systems, reviewer-side prompt injection via review-UI display of AI-generated rationale, RAG retrieval-path injection, knowledge-base content poisoning. The workflow's input handling redirects the AI step's purpose.

TM, Tool Misuse. Back-office AI assistant invoked with data outside its authorized scope (regulated data egress to AI provider), retrieval-extraction by malicious insiders bypassing document-level access controls, workflow tool combinations abused to bypass approval gates. The workflow's tool wiring is exploited.

RA, Rogue Agents. Silent decision-drift as model versions or thresholds shift outcomes without governance review, rubber-stamp HITL where reviewers approve unread, AI-suggestion bias accumulating into systematic outcome skew, autonomous-action drift in customer flows. The workflow's quality-control loop fails to detect accumulating effects.

The four categories sit alongside workflow-native failure modes, decision laundering, disclosure suppression, classifier-threshold drift, approval-bypass, RAG poisoning, content-policy violation, and are tagged where the threat libraries, requirements, and tests reference them.

11. The priority compliance map

Every Processes-domain Policy & Compliance practice at Level 1 publishes (and downstream practices reference) a one-page priority compliance map. The set below is the priority set for the Processes domain. Sector-specific items are added as applicable.

The map's purpose is traceability: an auditor or regulator asking "how is Art. 14 human oversight addressed for our AI-embedded workflows?" should reach a single cell in the map and from there one policy and from there one evidence artifact.

12. Shadow AI in the Processes domain (ungoverned AI-embedded workflows)

Shadow AI in the Processes domain takes a specific shape: ungoverned AI-embedded business workflows.

• Shadow AI in processes is the unsanctioned AI step. AI-routing rules added to ticketing systems, AI-scoring steps embedded in approval workflows without intake, AI-drafted customer responses without disclosure UX, RPA bots calling LLM APIs without governance, employees using consumer GenAI to augment back-office tasks, AI-embedded SaaS features silently enabled in workflows the org operates. The AI step exists but is not in the SM-Processes inventory and carries no SR REM, no FRIA, and no deployer-duty owner.
• Shadow workflows compound regulatory exposure. Every month of ungoverned operation increases the number of affected persons, the regulatory blast radius, and the contestation surface. A shadow decision pipeline producing employment screening decisions without an EEOC adverse-impact analysis, without NYC LL 144 bias audit, and without Art. 22 lawful basis creates a continuing compliance failure.
• Shadow workflows are observable today. The signals already exist, BPM platform events (Camunda, ServiceNow, Salesforce flows with AI steps), RPA platform run logs (UiPath, Automation Anywhere with AI plugins), ticketing system AI-routing events, CX-platform AI events (chatbot deployments, AI-generated responses), internal wiki and handbook search ("AI-assisted," "AI-drafted," "automated decision"), function-by-function survey, vendor invoice and contract review for AI-embedded SaaS, and self-attestation. No new tooling is required at L1.
• Shadow workflows manifest through more than one domain. The handbook treats them primarily in SM and EG, but they appear in TA (shadow-AI-in-processes threat view), PC (intake gate amnesty path), EH (workflow-config drift detection, signed workflow definitions), IM (shadow-AI-in-process containment play), and ML (shadow-AI-in-process detection).

Every Level 1 activity in this handbook contributes to making shadow AI in business processes visible, attributable, and trending down. The Level 1 outcome metric "shadow-AI-in-processes ratio" appears in Strategy & Metrics, Policy & Compliance, Education & Guidance, Threat Assessment, Environment Hardening, and Monitoring & Logging, six of the twelve practices. That is intentional.

13. Metrics taxonomy

Every level block in this handbook carries three metric types. The taxonomy is the canonical vocabulary; examples and targets are practice-specific.

• Outcome metrics (lagging). Directly measure whether the level's goal was achieved. Reported monthly or quarterly. Stated in a four-column table: Metric · Baseline · Target · Source.
• Process metrics (leading). Predict outcome metrics by measuring execution. Reported weekly or at the cadence of the underlying activity.
• Effectiveness metrics (business value). Measure what the outcome means to the business. Reported quarterly, often qualitative supported by quantitative.

Metric selection follows two rules: SMART (specific, measurable, achievable, relevant, time-bound) and outcome over output (results are preferred to activity counts). If a metric does not have a baseline column, the baseline is the value the program records on first measurement. The first cycle of measurement is itself an L1 activity.

Part III, The Twelve Practices in the Processes Domain

Each practice section follows the same shape:

• Practice Overview. Objective, description, context.
• Maturity Level 1. Objective, activities (A, B, C), outcome metrics, success criteria.
• Maturity Level 2. Same structure.
• Maturity Level 3. Same structure.
• Common Pitfalls. Three to four per level.
• Practice Maturity Questions. Three yes/no questions per level, the same questions also appear in the Part IV assessment workbook.

14. Strategy & Metrics (SM)

Practice Overview

Objective: Stand up an AI/HAI Process Assurance program that discovers, inventories, and strategically governs the business workflows that embed AI/HAI, with shadow-AI-in-processes prevention as the primary L1 outcome and a defensible risk-tier rubric as the primary L2 deliverable.

Description: SM-Processes establishes the program charter, the authoritative inventory of business workflows that embed AI/HAI, and the practice-maturity metrics that prove the program is working. The Processes domain governs the workflows the organization operates across seven archetypes: decision pipelines, customer-facing flows, human-AI collaboration chains, back-office augmentation workflows, approval/review workflows, content-generation workflows, and knowledge-management workflows. SM-Processes L2 produces the risk-tier rubric every other Processes-domain L2 practice depends on per the v3.0 dependency graph; every downstream practice (PC, TA, SR, SA, DR, IR, ST, EH, ML, IM) inherits its tier-calibration from the rubric authored here.

Context: Business workflows embed AI faster than governance catches up, a credit decision pipeline quietly routes to an LLM-generated score, a customer support team uses AI-drafted responses without a documented review standard, an HR team runs resumes through an AI screener before a human sees them, a finance team uses an AI summarizer to triage invoices with no accuracy check, an RPA bot calls an LLM API without a sanctioning record. None of this is malicious, it is the normal pace of AI adoption inside business functions. But it bypasses the deployer duties EU AI Act Art. 26 places on whoever owns the production decision, the human-oversight obligations Art. 14 places on Annex III high-risk uses, and the safeguards GDPR Art. 22 places on automated decisions with legal or similarly significant effect. Discovery is harder than in Software or Data because business workflows are often informal, undocumented in code, described in team wikis or tribal knowledge, and spread across HR, Finance, Legal, Customer Support, Sales, Engineering, and Operations. The AI/HAI Process Assurance program makes this surface visible, attaches accountable ownership to each workflow, and puts a governance gate on the path from informal AI adoption to sanctioned embedded workflow, so high-risk workflows surface before they create legal exposure.

Maturity Level 1

Objective: Stand up the AI/HAI Process Assurance program, build an inventory of business workflows that embed AI/HAI across the seven archetypes, and establish baseline metrics that prove shadow AI in business processes is decreasing.

Activities.

A) Charter the AI/HAI Process Assurance program. Publish a short program charter that names the problem (shadow AI in business processes, undisclosed AI steps in customer-facing and decision-affecting workflows, workflows lacking human-oversight standards or regulatory assessment, RPA bots calling LLM APIs outside governance), defines scope, and assigns accountable ownership. Charter elements include a problem statement grounded in AI-process-specific failure modes (AI output directly drives decisions affecting people's legal status, financial standing, employment, and service access; customer-facing flows using AI output may violate Art. 50 transparency obligations; human-AI collaboration chains without HITL standards expose the org to output-integrity failures at scale; sector regulations carry enforcement risk sitting in business functions, not in the security team); in-scope archetypes (decision pipeline, customer-facing flow, human-AI collaboration chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow); an executive sponsor (CISO co-sponsored by the COO / Chief Process Owner / Chief Risk Officer / General Counsel; co-signed by the DPO/CPO where Art. 22 or Annex III workflows are in scope); a working group spanning Security, Legal/Privacy, Compliance, Internal Audit, Operations, AI/ML engineering, and function representatives from each business unit embedding AI in workflows; decision rights for approval, block, exception, and sanctioning of new AI-embedded workflows; and a numerical year-one success target tied to the L1 outcome metrics below.

B) Build the AI/HAI process inventory and discover shadow AI in business processes. Establish a single AI/HAI process inventory as the program's source of truth. Minimum inventory fields are workflow name, owning function, owning team, workflow archetype, AI/HAI capability embedded (which AI tool / model / system provides the AI step, vendor or internal), decision-affecting effect (does the AI output materially drive a decision with legal or significant effect on a person, GDPR Art. 22 trigger, EU AI Act Annex III trigger), customer reach (number and type of customers affected per month), reversibility of the AI-driven action, human-oversight depth (autonomous, HITL substantive, HITL rubber-stamp, full human review before output leaves the org), regulatory scope (clinical, financial, employment, insurance, biometric, content moderation with legal effect), data classes processed (regulated PII / PHI / financial / biometric / employment data), business criticality, approval status (Sanctioned / Provisional / Under review / Prohibited / Awaiting Intake), risk tier (populated at L2), and linked artifacts (TA snapshot, SR REM, SA pattern, latest DR decision, latest IR finding, ML logging-baseline status). Discovery at L1 uses signals across system and human sources because informal workflows leave no code footprint: BPM and workflow platforms (Camunda, ServiceNow workflow catalog, Salesforce flows with AI steps, Microsoft Power Automate, business-process-mapping repos); RPA platforms (UiPath, Automation Anywhere, Blue Prism) with AI plugins or AI-decision steps; ticketing systems labeled "AI-assisted," "AI-generated," "AI-reviewed," and support routing rules sending to an AI step before human; customer-journey maps showing AI touchpoints; internal handbook and wiki search (Confluence, Notion) for "AI-assisted," "AI-generated," "automated decision," "model-based," "LLM-drafted"; function-by-function survey sent to HR, Finance, Legal, Customer Support, Sales, Engineering, Operations heads with explicit amnesty framing; vendor invoice and contract review for AI-embedded SaaS (Salesforce Einstein, Workday AI, Greenhouse AI, Intercom AI, lending platforms with model-score APIs); and a short self-attestation form publicized to function heads and operations managers with an amnesty window for previously undisclosed AI-embedded steps.

C) Establish foundational metrics that measure practice maturity and shadow-AI-in-processes reduction. Baseline and track a small, automatable set of outcome, process, and effectiveness metrics tied to the L1 outcome (shadow AI in processes reduced; inventory coverage growing). Publish a quarterly shadow-AI-in-processes scoreboard to the executive sponsor that reports total inventory by approval status broken out by archetype, new AI-embedded workflows discovered this quarter and their intake status, the shadow-AI-in-processes ratio trend across the last four quarters, AI-in-Business-Process Policy attestation coverage across function heads and process owners, and the top five unmitigated process risks (TA-flagged, compliance-flagged, or external-advisory-flagged) with owners and remediation status. Keep activity counts (surveys completed, forms submitted) out of the outcome view, they belong to process metrics.

Outcome Metrics (L1).

Success Criteria.

• Program charter published and sponsored by an accountable executive (CISO co-sponsored by COO / Chief Process Owner / CRO / General Counsel / DPO) with a cross-functional working group spanning Security, Legal/Privacy, Compliance, Internal Audit, Operations, AI/ML engineering, and function representatives.
• AI/HAI process inventory exists as a single source of truth with ≥85% coverage of discovered AI-embedded workflows within 12 months, broken out by archetype.
• Shadow-AI-in-processes ratio baselined and trending down for two consecutive quarters.
• ≥90% of function heads and process owners have acknowledged the AI-in-Business-Process Policy.
• Quarterly shadow-AI-in-processes scoreboard delivered to the executive sponsor with archetype-level breakdown.

Maturity Level 2

Objective: Risk-tier every AI-embedded workflow using the canonical rubric, calibrate the program's intensity per tier, and measure practice maturity and shadow-AI reduction per tier, establishing the rubric every other Processes-domain L2 practice depends on.

Activities.

A) Define the AI/HAI process risk-tier rubric. Four tiers, Critical / High / Medium / Low, assigned from a small set of auditable dimensions specific to AI-embedded workflows. Decision-affecting effect (AI output materially drives a decision with legal or significant effect, credit approve/deny, employment hire/reject, benefit eligibility, insurance underwriting, content-moderation account action → Critical via EU AI Act Annex III trigger and GDPR Art. 22 trigger; AI output influences but a human decides → High; AI output informs internal operational decisions with limited personal effect → Medium; AI assists internal drafting/summarization with full human review and no decision affecting persons → Low). Customer exposure (AI-embedded step reaches >10,000 customers per month → elevate; 1,000–10,000 → High or above; internal-only → neutral). Reversibility of the AI-driven action (effectively irreversible, credit denial processed, account terminated, employment rejected, medical triage decision acted on → elevate; reversible with a tested, documented override mechanism → neutral). Automation degree and human-oversight depth (autonomous with no human in the loop → elevate to Critical or High; HITL with rubber-stamp review, SLA too short for substantive judgment, no override training, override rate not tracked → elevated and requires HITL design assessment; HITL with substantive review, human reads, edits, or escalates meaningfully → neutral; full human review before output leaves the org → neutral or lower). Regulatory scope (EU AI Act Annex III high-risk use categories, employment, credit, education, biometric, critical infrastructure, law enforcement, immigration, justice, essential services → Critical; sector-specific AI rules in scope, FCRA credit, EEOC employment AI, NYC Local Law 144 AI hiring, CO SB-21-169 insurance AI, FINRA model risk for automated advice, FDA clinical workflow, FRT facial recognition → Critical or High depending on severity; GDPR Art. 22 automated decisioning with legal or similarly significant effect → Critical). Data classes processed (biometric, PHI, financial/credit, employment, special-category GDPR data → elevate to Critical or High; regulated PII → High; internal business data only → Medium or Low). Process criticality and blast radius (workflow on the critical path of a revenue-generating product, customer onboarding, safety-critical service, or regulated-control surface → elevate; internal back-office with low volume and full human review → neutral or lower). Tier derivation is deterministic from the rubric inputs; human overrides are allowed but recorded with rationale and reviewed by the working group.

B) Calibrate program intensity per tier. Publish a tier-treatment matrix specifying what each tier receives from each downstream practice, intake depth, FRIA gate for Annex III workflows, HITL standards assessment depth, TA depth, SA pattern adherence, design-review lane, IR cadence and re-review triggers, ST battery and red-team cadence, EH controls, ML detection set, and IM SLAs by severity. Critical artifacts receive the full program (full SR pack with REM, FRIA gate for Annex III, executive and DPO/CPO sign-off before go-live, substantive-review SLA documented and tested with override authority named, per-workflow deep threat model covering output-integrity / AGH via workflow inputs / EA in automated steps / RA in long-running pipelines, full-lane DR with named architect and Legal/Privacy representative, IR at go-live plus semi-annual plus on every material change within 14 days, full ST battery plus quarterly red-team, full workflow telemetry producing Art. 26/22 audit evidence, Critical IM SLA, ack ≤4h, mitigate ≤48h, root-cause ≤30d). High artifacts use full SR pack with privacy-officer review, archetype-plus-deltas threat model, fast-lane DR with deviation escalation, annual IR with material-change re-review within 30 days, full ST battery, core telemetry plus HITL event logging. Medium artifacts use base SR pack with HITL documentation, archetype-level threat model, fast-lane DR, annual IR with material-change re-review within 60 days, subset ST battery. Low artifacts use base SR pack only, archetype-level threat model, no required DR, spot-check ST, baseline logging. Each downstream Processes-domain L2 practice inherits this calibration; the rubric and matrix are authored here in SM L2 and changes flow through the SM working group.

C) Per-tier scoreboard and governance. The L1 shadow-AI-in-processes scoreboard becomes tier-aware. Inventory state is reported by tier and by archetype, a Critical-tier customer-facing decision pipeline is its own row, the count of Low-tier internal back-office augmentation workflows is one line. Shadow-AI-in-processes ratio is reported per tier, a Critical-tier undisclosed AI decision pipeline is a headline, a Low-tier back-office augmentation is a line item. Per-tier SLA adherence across intake, DR, IR, ST, ML, and IM is reported monthly. FRIA completion status for all Annex III workflows (commissioned, in-progress, completed, overdue) is reported on the scoreboard. The tier-movement log records upgrades (a workflow that gained customer-facing output, automated-decision capability, regulated data flow, or scope expansion) and downgrades with rationale, reviewed by the program sponsor. Quarterly executive review explicitly discusses tier-balance: is the program's effort matching the program's risk profile?

Outcome Metrics (L2).

Success Criteria.

• Risk-tier rubric published and applied; tier assigned to 100% of inventory from auditable dimensions.
• Tier-treatment matrix published; downstream practices (PC, TA, SR, SA, DR, IR, ST, EH, ML, IM) calibrated to it.
• Per-tier shadow-AI-in-processes ratio reported quarterly; Critical-tier unsanctioned AI in production = 0.
• Per-tier SLA adherence ≥90% across practices.
• FRIA gate operational; 100% of EU AI Act Annex III workflows have a FRIA on file before production.
• Tier-movement governance active, changes logged with rationale and reviewed by the sponsor.

Maturity Level 3

Objective: Automate inventory and tier maintenance from workflow-execution telemetry, benchmark the program against external peers (NIST AI RMF community, CSA AI Safety, sector ISACs, APQC, BPM-community AI-governance groups), and contribute anonymized AI-process-governance intelligence back to industry standards.

Activities.

A) Continuous inventory and tier automation from workflow-execution telemetry. Inventory auto-updates from BPM platform events (new workflow created, AI-step added or removed, routing rule changed), RPA platform run-log events (new AI-plugin invocation, new process including an AI decision step), ticketing-system AI-routing events (new queue routing rule sends to an AI step), CX-platform AI events (new AI chatbot flow, new AI-generated response template activated), contract and procurement events (new AI-embedded SaaS tool licensed to a business function auto-opens a Processes intake), workflow-execution telemetry showing new AI-step latency patterns, self-attestation, and the intake queue. Tier assignments are rule-based on the L2 rubric inputs; rule changes are versioned and replayable; tier changes auto-trigger downstream practice obligations within 24 hours (a Medium-to-Critical upgrade for a workflow that added an automated credit-scoring step triggers FRIA commissioning, DR, ST, and ML reconfiguration). Human curation handles new archetypes, ambiguous workflow descriptions, dimensional-input conflicts, and workflows that span multiple archetypes. A data-quality SLO is published: ≥99% of active AI-embedded workflows correctly tiered within 48 hours of a material change; ≥95% inventory completeness against discovery-source reconciliation. The auto-curation rate target reflects the informal nature of Processes-domain workflows: ≥75% auto vs. human-curated.

B) External benchmarking. Program metrics are compared against peer benchmarks through NIST AI RMF community of practice, CSA AI Safety Initiative (controls matrix benchmarks for AI-embedded processes), sector ISACs with AI working groups (FS-ISAC FinAI track, H-ISAC ClinAI track, IT-ISAC), APQC process-maturity frameworks adapted for AI-embedded workflows, BPM-community AI-governance working groups (Object Management Group BPM + AI, Camunda community, SAP Signavio practitioner networks), HR-AI working groups (SHRM AI in HR initiative, IEEE Ethically Aligned Design for HR AI), sector-specific enforcement-action learnings (FTC AI enforcement, CFPB AI credit-decision guidance, EEOC AI employment guidance), and formal peer roundtables. A semi-annual "how we compare" brief covers inventory coverage, shadow-AI-in-processes ratio, per-tier SLA adherence, FRIA completion rate, HITL substantive-review SLA adherence, automation level, and time from "new AI-embedded workflow proposed" to "provisional approval issued." Benchmark deltas inform program investment, board-level narrative, and next-year L2/L3 work priorities.

C) Contribute anonymized AI-process-governance ecosystem intelligence. Contribute to NIST AI RMF Playbook and successor editions (real-world implementation experience for AI-in-processes use cases), CSA AI Safety Initiative controls matrix for AI-embedded processes, ISO/IEC 42005 AI impact assessment (implementation guidance for AI-embedded business workflows, FRIA methodology for Annex III use cases), ISO/IEC 42001 AIMS community implementation guidance for Processes-domain workflows, OECD AI Policy Observatory AI-in-business-processes guidance, sector AI deployment-officer credentialing paths (emerging credentials in financial services, healthcare, HR, and public sector), BPM-community AI-governance frameworks (process-archetype taxonomy, HITL design standards, workflow-telemetry logging patterns for AI steps), and sector ISACs (FS-ISAC, H-ISAC, IT-ISAC). Target minimum four substantive contributions per year; quality over volume; every contribution anonymized and legally vetted.

Outcome Metrics (L3).

Success Criteria.

• Inventory auto-update SLO published and met; tier-rule change-log versioned and replayable.
• Tier-assignment automation operational with exception-based human review; tier changes auto-trigger downstream obligations within 24 hours.
• Semi-annual external-benchmarking brief published to the sponsor with ≥5 peer-comparable metrics.
• ≥4 substantive industry contributions per year, anonymized and cited.
• Executive / board ROI narrative refreshed at least annually with external benchmarks and avoided-loss examples.

Common Pitfalls

Level 1. - Inventory seeded only from "AI features the product team announced", misses informal AI-embedded steps in HR screening, finance approval, legal review, customer support routing, and back-office ops that exist entirely outside any code repo or BPM tool. - Relying only on engineering signals (LLM SDK imports, model registry) to discover Processes-domain workflows, most informal AI-embedded steps involve AI-embedded SaaS tools leaving no engineering footprint in the monorepo. - Survey is optional and unaccompanied by amnesty framing, function heads assume disclosure creates compliance liability and decline to surface existing AI-embedded steps; the shadow inventory stays incomplete. - Executive sponsor is security-only, COO / Chief Process Owner / General Counsel / DPO are not co-owners, so the program lacks cross-functional authority to require function-head participation; metrics count surveys completed instead of outcomes (shadow-AI-in-processes ratio down, compliance events trending down).

Level 2. - Tier-rubric inputs are subjective ("important decision," "many customers"), reviewers tier differently, auditors do not trust the derivation, and tier movements feel political rather than evidenced. - FRIA gate announced but never enforced, Annex III decision pipelines reach production without a completed FRIA because no blocking mechanism was built into intake. - HITL standards treated as binary (human exists vs. does not exist) rather than assessed for substantive depth, rubber-stamp HITL is logged as compliant; Art. 14 oversight obligations go unmet; scoreboard reported in aggregate hides that Critical-tier workflows lack real coverage. - Downstream practices treat tier as advisory rather than operational, DR / IR / ST / ML do not differentiate scope by process tier, defeating the purpose of L2; tier upgrades meet resistance from business functions because they trigger heavier review and no governance enforces the upgrade.

Level 3. - Automation runs without a data-quality SLO, signal-driven inventory silently drifts, informal workflows added by function teams are never captured, and Legal and Compliance stop trusting the inventory. - Benchmarking chooses peers that flatter the program (small-scale AI pilots when operating regulated customer-facing AI workflows at enterprise scale) rather than stretching it against comparable deployers. - Industry contributions are panels and press releases, not technical artifacts (HITL design standards, workflow-archetype taxonomies, FRIA methodology templates) that NIST / ISO / CSA / sector ISACs actually consume. - Automated tiering rules under-tier function-owned workflows because the dominant signal source (self-attestation) systematically under-reports criticality; FRIA completion metric is reported but FRIA quality is never assessed, so completed FRIAs are superficial box-checks.

Practice Maturity Questions

Level 1. 1. Is there a published AI/HAI Process Assurance program charter with a named executive sponsor (CISO co-sponsored by COO / Chief Process Owner / CRO / General Counsel / DPO), a cross-functional working group spanning Security, Legal/Privacy, Compliance, Internal Audit, Operations, AI/ML engineering, and function representatives, and clear decision rights for approval, block, exception, and sanctioning of new AI-embedded workflows, with an explicit amnesty path publicized to function heads? Evidence: charter document with sponsor signatures, working-group roster, and the amnesty communication. 2. Does a single AI/HAI process inventory exist, seeded from function-by-function surveys, BPM/RPA/ticketing-system signals, internal wiki/handbook search, vendor-contract review, and self-attestation, covering all seven Processes-domain archetypes with ≥85% coverage of discovered AI-embedded workflows within 12 months? Evidence: inventory export reconciled against discovery-source query results. 3. Are the L1 outcome metrics baselined and reported quarterly to the sponsor, inventory coverage, shadow-AI-in-processes ratio (≤20% and trending down), AI-in-Business-Process Policy attestation (≥90% of function heads and process owners), named-owner-and-HITL-model coverage (100% for decision-affecting and customer-facing), and known compliance events? Evidence: most recent quarterly shadow-AI-in-processes scoreboard.

Level 2. 1. Is every AI-embedded workflow in the inventory assigned a risk tier based on an auditable rubric covering decision-affecting effect (EU AI Act Annex III / GDPR Art. 22), customer exposure, reversibility, automation degree and human-oversight depth, regulatory scope, data classes, and process criticality? Evidence: rubric document plus inventory column showing tier and derivation inputs per workflow. 2. Is there a published tier-treatment matrix driving differential intensity across PC, TA, SR, SA, DR, IR, ST, EH, ML, and IM, with ≥95% of Critical workflows receiving full-scope treatment in the last 12 months, and is a FRIA gate operational with 100% of EU AI Act Annex III workflows holding a completed FRIA before production? Evidence: tier-treatment matrix, cross-practice adherence report for Critical workflows, and the FRIA register. 3. Does the quarterly shadow-AI-in-processes scoreboard report per tier and per archetype (with Critical-tier unsanctioned AI in production tracked at zero), and is tier-movement logged and reviewed by the sponsor? Evidence: tier-aware scoreboard and tier-movement log for the prior two quarters.

Level 3. 1. Do inventory and tier assignment auto-update from workflow-execution telemetry (BPM events, RPA logs, ticketing-system AI-routing events, CX-platform AI events, contract/procurement events) with a published data-quality SLO, and is ≥75% of curation handled automatically with exception-based human review? Evidence: pipeline diagram, SLO dashboard, curation-source breakdown. 2. Do you publish a semi-annual external-benchmarking brief comparing the program against ≥5 peer-comparable metrics via NIST AI RMF community / CSA AI Safety / sector ISACs / APQC / BPM-community AI-governance groups, and does it drive investment decisions? Evidence: most recent brief and a budget or staffing decision traceable to a benchmark delta. 3. Does the program contribute ≥4 substantive, anonymized artifacts per year to the AI-process-governance ecosystem (NIST AI RMF Playbook, CSA AI Safety Initiative, ISO/IEC 42005, ISO/IEC 42001 AIMS community, OECD AI guidance, sector ISACs, BPM-community frameworks), and does the ROI narrative cite external benchmarks? Evidence: contribution log with acceptance confirmations and the most recent ROI narrative.

15. Policy & Compliance (PC)

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 documented rules, gated before going 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 Art. 26 deployer duties, Art. 50 transparency, Annex III high-risk classification, Art. 9 risk management, and Art. 14 human oversight; GDPR Art. 22 automated decision-making, Art. 32 security, Art. 33 breach; NIST AI RMF GOVERN/MAP/MEASURE/MANAGE; ISO/IEC 42001 AIMS; SOC 2 CC9.2; 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 AI, FRT facial recognition).

Context: Organizations operating AI-embedded workflows inherit a generic Acceptable Use Policy and a generic data-handling policy. Neither answers the questions 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 "human oversight" actually means for a loan-decision workflow where the reviewer approves 200 cases per day, what evidence the go-live gate produces, or how EU AI Act Art. 26 deployer-duty compliance flows 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 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.

Activities.

A) Publish the three priority AI/HAI process policies. Ship each in its smallest useful form, short, readable, specific enough to be enforceable against business-function decisions. The AI-in-Business-Process Policy enumerates permitted workflow archetypes and the AI-tool archetypes permitted per archetype, specifies the required human-oversight model per archetype (autonomous steps require explicit approval at intake with HITL design documented; customer-facing flows require a disclosure mechanism; decision pipelines with legal or significant effect require GDPR Art. 22 safeguards; Annex III high-risk uses require a FRIA), requires disclosure to affected persons in line with EU AI Act Art. 50 and Art. 26 deployer duties, prohibits operating a decision pipeline affecting persons without a named human-oversight owner, prohibits operating a customer-facing AI flow without an Art. 50 disclosure mechanism, prohibits embedding AI in an Annex III workflow without a commissioned FRIA, prohibits AI in employment screening without EEOC and Art. 22 safeguards documented, and requires annual attestation by all function heads, process owners, and operations managers. The HITL Standards Policy defines 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 with SLA too short for substantive review, no override training, and no override-rate tracking does not satisfy Art. 14 human oversight), sets a minimum review SLA per archetype (decision pipelines require enough time per item for substantive review based on item complexity; queue size per reviewer per shift must not exceed the rate that makes substantive review impossible), names the override authority for every AI-embedded workflow with the override path trained, practiced, and logged with overrides tracked and reported to the sponsor quarterly, requires the reviewer have access to AI output / confidence score / key inputs / basis for the AI recommendation without anchoring presentation, defines escalation criteria, and requires HITL documentation at intake for all customer-facing and decision-affecting workflows with annual or on-material-change review. The AI-Process Intake / Sanction Gate Policy makes intake mandatory before production deployment for all in-scope archetypes, lists archetype-keyed required go-live artifacts (decision pipeline, GDPR Art. 22 safeguards checklist, Annex III high-risk assessment, FRIA commissioned or rationale-documented as not-required, HITL standards documented and confirmed substantive; customer-facing flow, Art. 50 disclosure mechanism confirmed, human-oversight model documented, HITL SLA confirmed; HITL chain, HITL standards reviewed, override authority named, override-rate tracking active; approval/review workflow, AI pre-classification accuracy baseline, override rate tracked, escalation documented; content-generation workflow, human review and publication accountability documented, output attribution policy; knowledge-management workflow, retrieval-source governance, output-integrity-in-decisions risk assessed), exposes an amnesty path for previously ungated production workflows (routed as open IM findings), and names the program sponsor (or delegated Compliance / AppSec lead) as the go-live decision authority.

B) Map the three policies to the priority compliance requirements. Build a one-page priority compliance map that an auditor can read in 60 seconds. The map ties EU AI Act Art. 26 deployer duties to the AI-in-Business-Process Policy (oversight model, disclosure requirement, deployer-duty owner) plus the Intake Gate (go-live artifact checklist, logged decision, named deployer-duty owner); Art. 50 transparency to AI-in-Business-Process (disclosure requirement for customer-facing and decision-affecting flows) plus HITL Standards (disclosure mechanism confirmed at intake); Annex III high-risk classification to the Intake Gate (Annex III assessment required and FRIA gate for decision pipelines); Art. 9 risk management to AI-in-Business-Process (TA + SR + SA required artifacts) plus the gate checklist; Art. 14 human oversight to the HITL Standards Policy (substantive review definition, override authority, escalation path, SLA, anchoring-prevention). GDPR Art. 22 automated decision-making maps to AI-in-Business-Process (Art. 22 safeguards required for decision pipelines) plus HITL Standards (substantive review satisfies right to human review) plus Intake Gate (safeguards checklist at go-live); Art. 32 security and Art. 33 breach to AI-in-Business-Process and the gate. NIST AI RMF GOVERN/MAP/MEASURE/MANAGE traces to the full three-policy stack and the gate; ISO/IEC 42001 AIMS traces to the program charter (from SM) plus all three L1 policies; SOC 2 CC9.2 traces to vendor-AI confirmation at gate. Sector-specific rules flow into the archetype controls or the gate's required-artifacts checklist for affected workflows, HIPAA BAA for PHI in clinical AI, FCRA adverse-action and accuracy obligations for credit AI, EEOC and NYC Local Law 144 bias-audit and candidate-notice requirements for AI hiring, CO SB-21-169 anti-discrimination and explainability for insurance AI, FINRA model-risk documentation for automated financial advice, FDA AI/SaMD where clinical workflows trigger device regulation.

C) Operate the intake gate and track foundational compliance outcomes. Run a single intake ticket queue with a published SLA (triage within 5 business days; provisional approval within 10 business days for Low-tier archetypes with no regulated data, no customer exposure, and full human review). The artifacts checklist is archetype-keyed, the function team submitting intake receives the checklist for their archetype and missing artifacts block go-live. Gate approval creates or updates the SM-Processes inventory record with artifact links. The amnesty path is visibly linked from the intake form, the AI-in-Business-Process Policy, and the function-head communications from SM. Exceptions are logged with owner, rationale, and review date; no exception may remain open longer than 90 days without re-review. HITL "confirmation" at intake is not a checkbox, it is a documented review SLA, named override authority, and override-rate tracking commitment.

Outcome Metrics (L1).

Success Criteria.

• Three priority policies (AI-in-Business-Process Policy, HITL Standards Policy, AI-Process Intake / Sanction Gate Policy) published, approved by Legal/Privacy and Security, communicated to all function heads and process owners.
• One-page priority compliance map published, covering EU AI Act Art. 26/50/Annex III/Art. 9/Art. 14, GDPR Art. 22/32/33, NIST AI RMF GOVERN/MAP/MEASURE/MANAGE, ISO/IEC 42001, SOC 2 CC9.2, and applicable sector-specific obligations (HIPAA / FCRA / FINRA / EEOC / NYC LL144 / CO SB-21-169 / FRT); linked from each policy.
• Intake gate operational with a per-archetype artifacts checklist, published SLA, and visible amnesty path.
• ≥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 or decision-affecting workflow has a named deployer-duty owner.

Maturity Level 2

Objective: Deepen policy controls and compliance evidence per AI-embedded workflow risk tier, operate the FRIA gate for EU AI Act Annex III workflows continuously, and produce audit-ready evidence trails per tier.

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 workflows require full SR pack with REM, executive (CISO or COO) and DPO/CPO sign-off before go-live, EU AI Act Annex III high-risk assessment reviewed by Legal, FRIA commissioned and 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), and mandatory re-review within 14 days on every material change (new AI tool, new decision population, new data class, scope expansion). High workflows require full SR pack plus REM with fast-track exemptions, CISO-delegated AppSec / Compliance lead sign-off, EU AI Act and GDPR assessments, FRIA if Art. 22 applies and scale exceeds threshold, HITL model documented and confirmed, and re-review within 30 days on material change. Medium workflows use base SR pack plus REM with fast-lane DR (or DR waiver for sanctioned reference-pattern implementations), HITL documented, and re-review annually or within 60 days on material change. Low workflows use base SR pack only with self-attested checklist, HITL confirmed, and re-review at annual review. Policy exceptions require named owner, compensating control, Legal / Compliance reviewer acknowledgment, and expiry date (max 12 months); Critical-tier workflows have no amnesty for missing go-live artifacts after L2 is established, missing artifacts become blocking findings 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 the current TA snapshot, the SR REM with gap status and owner, the SA reference-pattern confirmation or DR-approved deviation, the latest DR decision and date, the latest IR attestation 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, the deployer-duty record (named human-oversight owner, Art. 26 disclosure mechanism confirmation, Art. 26 obligations checklist), HITL validation evidence (override rate over last 90 days, average review time per item, escalation rate, most recent HITL standards review date), FRIA status for Annex III workflows (not applicable / commissioned / completed / last reviewed date), and sector-specific compliance checklist status. Staleness rules trigger PC-Processes findings routed to IM: Critical TA snapshot 90 days, IR attestation 6 months, ST evidence 30 days, HITL validation 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 a specific workflow.

C) FRIA gate operation, exception management, and sector-specific bundle assembly. 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 covers workflow archetype and AI system, affected population, 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, and named author/reviewer. FRIA review schedule: Critical-tier Annex III workflows reviewed annually and on material change; High-tier Art. 22 workflows reviewed on material change. Integrate the exception register with the intake gate: no exception approved without tier-appropriate compensating control and expiry; monthly exception aging review escalates exceptions >90 days past expiry to the program sponsor. Sector-specific evidence bundles are generated from the compliance evidence bundle for the workflows they apply to and completeness is tracked (FCRA, adverse-action notice process, AI-model documentation, accuracy-rate tracking, dispute-handling path; NYC LL144, annual bias audit on file, candidate notice mechanism, audit publication; CO SB-21-169, anti-discrimination evidence, explainability documentation, state reporting; HIPAA clinical, BAA with AI provider, PHI-in-clinical-workflow documentation, human-oversight of AI-assisted clinical decisions; FINRA model-risk, model documentation, validation evidence, ongoing monitoring; EEOC AI employment, adverse-impact analysis, explanation mechanism, override-rate tracking).

Outcome Metrics (L2).

Success Criteria.

• Three priority policies extended with tier-specific addenda; 100% of Critical workflows carry executive plus DPO/CPO sign-off at go-live in the last 12 months.
• Compliance evidence bundle live for every Critical/High workflow; staleness inside tier-specific targets.
• FRIA gate operational; 100% of EU AI Act Annex III workflows hold a completed FRIA on file before production.
• HITL validation evidence current for 100% of Critical/High workflows; override rates monitored monthly.
• Sector-specific evidence bundles (FCRA / NYC LL144 / CO SB-21-169 / HIPAA / FINRA / EEOC as applicable) complete for in-scope workflows.
• Exception register comprehensive and reviewed monthly; zero exceptions past expiry un-escalated; Critical-tier missing go-live artifacts treated as blocking findings.

Maturity Level 3

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

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 auto-opens a PC finding if the workflow is not yet in inventory), FRIA review schedule triggers (Annex III workflow reaching annual FRIA review date auto-opens a review task), and sector-specific renewal triggers (NYC LL144 annual bias audit due date, CO SB-21-169 annual report due date). The attestation-generation pipeline produces a provenance-complete evidence pack for any workflow, regulation-keyed (EU AI Act Art. 26 deployer-duty pack, GDPR Art. 22 pack, ISO 42001 AIMS evidence set, sector-specific pack) or workflow-keyed, within 3 business days. The currency SLO is ≤24 hours latency after a triggering event; completeness is ≥99% of active Critical/High workflows.

B) Telemetry-driven policy refresh and regulatory-motion tracking. Operate a quarterly policy-refresh cycle driven by ML-Processes detection trends (which 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), and external regulatory and standards updates (EU AI Act Art. 14 / Art. 26 implementing acts, GDPR EDPB AI guidance on Art. 22, NIST AI RMF Playbook updates, OECD AI Policy Observatory guidance, FTC / CFPB / EEOC AI enforcement actions, state AI laws, sector-specific guidance from FDA/FINRA/OCC/NYDFS/HHS). Refresh output is a versioned changelog for each of the three policies approved by Legal/Privacy and Security; EG-Processes training content updates within 30 days of any policy change; the SM-Processes inventory archetypes and tier rubric are reviewed for needed updates. A regulatory-motion tracker maintains a log of open regulatory instruments with expected effective dates mapped to the policy each will affect; the working group reviews 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); NIST AI RMF Playbook working groups; ISO/IEC 42005 AI impact assessment working groups; ISO/IEC 42001 AIMS community; 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 through CSA AI Safety Initiative, NIST AI RMF community of practice, and sector ISACs (FS-ISAC, H-ISAC, IT-ISAC): HITL design standards (substantive vs. rubber-stamp taxonomy, review-SLA calculation methodology, override-rate benchmarks), FRIA methodology templates for each Annex III use category, compliance evidence bundle schemas for Art. 22 / Art. 26, workflow-archetype policy addendum patterns. Target at least two substantive public comments or standards contributions per year on AI-process governance and Art. 14 / Art. 22 implementation topics.

Outcome Metrics (L3).

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.

Common Pitfalls

Level 1. - Reusing the generic AUP and data-handling policy 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, RPA bots that started calling LLM APIs, 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. - 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; HITL "confirmation" is a checkbox rather than a documented SLA and override-rate target so 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; sector-specific bundles are treated as "covered by the DPA" so NYC LL144 annual bias audit and FCRA adverse-action specifics are not operationalized. - Compliance evidence bundle is a folder of PDFs only the compliance lead can navigate, a second reviewer cannot assemble the regulator pack without them. - Exception register exists but expiry dates are never enforced, stale exceptions from the amnesty window quietly become the permanent state; Critical-tier missing artifacts continue to ship under exception.

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. - External regulatory contributions are deadline-only comment letters rather than technical artifacts (FRIA methodology templates, HITL design standards, compliance evidence schemas) that standards bodies actually use. - Contributed policy templates and schemas are published once and then go stale, external practitioners find outdated versions and stop trusting the program; ROI narrative omits compliance cost-reduction evidence.

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, AI-Process Intake / Sanction Gate Policy) with archetype-specific oversight requirements, HITL standards distinguishing substantive review from rubber-stamp, and a deployer-duty owner requirement, and is there a one-page compliance map tying each priority requirement (EU AI Act Art. 26/50/Annex III/Art. 9/Art. 14, GDPR Art. 22/32/33, NIST AI RMF, ISO/IEC 42001, SOC 2 CC9.2, sector-specific) to the policy that carries it? Evidence: published policy set, approval signatures, and one-page compliance map. 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)? Evidence: intake queue export reconciled against SM-Processes inventory. 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 SM-Processes inventory? Evidence: LMS attestation report and inventory column showing deployer-duty owners and HITL models.

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 covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record, and FRIA status? Evidence: tier addenda, gate records showing dual sign-off, and a sample evidence bundle for a Critical workflow. 2. Is the FRIA gate operational for 100% of EU AI Act Annex III workflows, and is the 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? Evidence: FRIA register, evidence-registry staleness report, and last inquiry-response log. 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? Evidence: exception register, monthly review minutes, and sector-bundle completeness report.

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 attestation currency ≤24h latency and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High workflows continuously attested? Evidence: pipeline architecture, SLO dashboard, currency and completeness metrics. 2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML detection trends + IM incident learnings + HITL validation signals + regulatory-motion tracker + tier-movement data) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update? Evidence: most recent policy changelog with rationale entries citing telemetry or regulatory source. 3. Does the program contribute ≥2 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 AI guidance, NIST AI RMF Playbook, ISO/IEC 42005, ISO/IEC 42001 AIMS, OECD, sector regulators) with documented external recognition? Evidence: contribution log with publication links and recognition citations.

16. Education & Guidance (EG)

Practice Overview

Objective: Build the AI-assurance literacy every process owner, product manager, operations manager, and business analyst touching AI-embedded workflows needs and the practitioner skills the smaller population performing FRIA composition, HITL design assessment, process intake review, and workflow-archetype threat modeling must have, with shadow-AI-in-processes awareness as the primary L1 cultural outcome.

Description: EG-Processes covers two audiences. The first is the workforce population, every person who touches AI-embedded business workflows across HR, Finance, Legal, Customer Support, Sales, Engineering, and Operations; they need AI-process literacy covering what the seven Processes-domain archetypes are, what EU AI Act Art. 26 deployer duties and Art. 14 human oversight mean for the workflows they run, what GDPR Art. 22 automated-decisioning safeguards require, what HITL design standards mean in practice, how to recognize when a workflow step carries enough output-integrity risk to escalate, and how to submit intake or disclose prior shadow AI use. The second is the practitioner population, AppSec reviewers, Privacy and Legal counsel, Compliance officers, Internal Audit, and business-unit representatives who perform FRIA composition, HITL design assessment, workflow-archetype intake review, and fairness/bias-indicator review where they intersect with security and legal obligations.

Context: AI-embedded business workflows create exposure points classic security and compliance training does not cover. A process owner who has only taken the org's data-privacy course will not recognize that an AI-assisted HR screening workflow may require a FRIA, an annual bias audit under NYC Local Law 144, and EEOC adverse-impact analysis. A compliance officer who has only reviewed static policy documents will not know how to assess whether a loan-decision pipeline's "human review" step is substantive enough to satisfy Art. 22 rights or rubber-stamp enough to fail Art. 14 oversight. A customer support operations manager who approved an AI-drafted-response workflow without reading the HITL Standards Policy will not know that the 45-second review SLA makes substantive review impossible. Without deliberate EG practice targeted at these gaps, AI-process compliance surfaces late, at regulatory inquiry, in enforcement actions, or when a customer exercises their Art. 22 right to explanation and the org cannot provide one.

Maturity Level 1

Objective: Deliver foundational AI-process literacy to ≥90% of the workforce touching AI-embedded business workflows and role-based practitioner training to 100% of the reviewer population, with an active shadow-AI-in-processes awareness campaign.

Activities.

A) Ship workforce AI-process literacy training. A single short course (≤25 minutes) every function head, process owner, product manager, operations manager, and business analyst touching AI-embedded workflows takes on first exposure and refreshes annually, tied to the AI-in-Business-Process Policy attestation from PC-Processes L1. Content covers what the seven AI-embedded workflow archetypes are with concrete examples from the org's own inventory (decision pipeline, customer-facing flow, human-AI collaboration chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow); EU AI Act Art. 26 deployer duties in plain language (the organization that deploys an AI system is the deployer; deployer duties include assigning human oversight, monitoring the system, informing affected persons, and keeping logs for high-risk systems; a decision pipeline the finance team runs is a deployment, not a tool purchase); EU AI Act Art. 14 human oversight in plain language (oversight means the human can meaningfully understand, can exercise judgment independently, can override, and is not rubber-stamping; what a 45-second review SLA with a 200-item queue means for whether oversight is real); GDPR Art. 22 automated decision-making in plain language (when AI output materially drives a decision with legal or significant effect, the person has the right to human review, the right to an explanation, and the right to contest; the org must have a mechanism for each right before the workflow goes live); HITL design substantive vs. rubber-stamp with one concrete example of each from a workflow archetype the trainee's function operates; how the AI-Process intake gate works (submission, per-archetype artifacts checklist, provisional approval, amnesty path); when to escalate to a FRIA (Annex III use categories, employment, credit, education, biometric, critical infrastructure, law enforcement, immigration, justice, essential services, with a 30-second check); shadow-AI-in-processes disclosure (why disclosure carries no penalty under the amnesty window; how to disclose in under 5 minutes); and a before-you-deploy 10-second decision aid. Delivery is an LMS module plus a one-page reference card pinned in function-team Slack/Teams plus a brief at function all-hands when the program launches; no role gating.

B) Deliver role-based practitioner training for the reviewer population. A deeper module (approximately 2.5 hours) for the practitioner population only, AppSec reviewers performing TA and SR intake reviews, Privacy / Legal counsel performing Art. 22 lawful-basis analysis and FRIA composition, Compliance officers reviewing HITL design and sector-specific obligations, Internal Audit, and business-unit representatives participating in intake review panels. Completion is a prerequisite to approving intakes. Content covers the workflow-archetype threat walkthrough for each of the seven archetypes with HAI TTP exposure points (EA, AI step acts beyond intended scope; AGH, workflow inputs redirect the AI recommendation; TM, tool calls in the AI step are misused; RA, long-running AI pipelines drift from intended behavior) and the regulatory-scope assessment (which archetype patterns trigger Annex III, Art. 22, and sector rules); FRIA composition (what a Fundamental Rights Impact Assessment must cover for each Annex III use category; the seven FRIA sections, workflow description, affected population, decision effects and reversibility, fundamental rights assessment, human oversight design, residual risks, sign-off; how to assess whether a submitted FRIA is substantive or superficial); HITL design assessment (how to evaluate whether human-oversight design satisfies Art. 14; review-SLA calculation relative to queue size and item complexity; override-rate target ranges by archetype; anchoring-prevention assessment; escalation-path adequacy); Art. 22 lawful-basis analysis (three lawful bases, explicit consent, contractual necessity, Union or Member State law, and what safeguards must be present for each; right-to-explanation mechanism adequacy); fairness and bias indicators at the intersection with security and legal obligations (indicators that an AI-embedded decision pipeline may carry disparate impact creating EEOC liability, FCRA adverse-action exposure, or EU AI Act Art. 9(7) data-quality obligations; how to flag these as compliance issues); sector-specific deep-dives (HR-AI, FinAI, ClinAI as applicable); the priority compliance map in practice; and a calibration exercise where three sample workflow intakes (an AI-assisted hiring screening pipeline, a customer-facing AI-drafted response flow, an AI-driven credit pre-approval routing) are scored independently with instructor-facilitated debrief.

C) Run the shadow-AI-in-processes awareness campaign. An always-on communications program that makes it easy to disclose existing AI-embedded workflow steps and uncomfortable to operate them outside the program. Elements include a launch moment with the executive sponsor (CISO + COO / CRO co-signed) naming shadow AI in processes, announcing the amnesty window, and publishing the sanctioned-archetype catalog with explicit framing that disclosing is safe and not disclosing creates regulatory exposure for the function team; recurring monthly short content (a fast-track win such as intake-to-provisional in 3 BD for a back-office augmentation workflow, an anonymized example of an Art. 22 safeguard caught at intake review, an external enforcement action, CFPB credit AI, FTC AI hiring, reframed as "what would we find in our own inventory?", a new sector HITL-design resource); an "Is this a decision pipeline?" series calling out workflow patterns that may cross the Art. 22 threshold (AI-assisted loan decisions, AI-scored job applications, AI-routed benefit eligibility); amnesty path visibly linked from the AI-in-Business-Process Policy, the intake form, and function-team channel pins; a feedback channel for process owners and operations managers to ask "does this workflow need intake?" with response within 5 BD; and deployer-duty micro-content for teams running customer-facing or decision-affecting workflows. Campaign channel links are tagged so attribution of intake submissions and amnesty disclosures to campaign touchpoints is tracked.

Outcome Metrics (L1).

Success Criteria.

• Workforce AI-process literacy module launched; ≥90% current-year completion sustained across function teams.
• Practitioner training launched, completion gated on intake-approval permissions, and reviewer calibration drift inside target for two consecutive quarters.
• Shadow-AI-in-processes awareness campaign running with at least monthly content cadence and measurable attribution.
• Deployer-duty micro-content deployed for every customer-facing or decision-affecting AI-embedded archetype active in the inventory.
• Training content owner named; content updated within 30 days of any change to policies, archetype list, or compliance map.

Maturity Level 2

Objective: Deepen practitioner skill through scenario-based training from real intake cases, deliver sector-specific tracks (HR-AI, FinAI, ClinAI) calibrated to SM-Processes L2 risk tiers, and run seasonal shadow-AI-in-processes campaigns tied to business planning and regulatory release cycles.

Activities.

A) Scenario-based reviewer training from real intakes. Build a scenario library from anonymized real intakes from the org's own queue; each scenario includes the as-submitted workflow description, the original reviewer decisions (tier, FRIA assessment, HITL design adequacy, Art. 22 lawful-basis analysis, SR gaps), any reviewer disagreement, and the resolved outcome after calibration or post-launch review. Organize scenarios per archetype (decision-pipeline scenarios, customer-facing-flow scenarios, HITL-chain scenarios, back-office augmentation scenarios) and per compliance cluster (Annex III FRIA scenarios, Art. 22 automated-decisioning scenarios, HITL rubber-stamp scenarios, sector-specific scenarios). Run paired calibration exercises in which two reviewers independently score the same scenario, with instructor-facilitated debrief on tier delta, FRIA adequacy, HITL design gap list, and SR requirement mismatches. Weight curriculum to tier: Critical-tier decision-pipeline and customer-facing-flow scenarios dominate the advanced modules; Medium/Low back-office augmentation scenarios streamline fast-track calibration. Practitioners graduate by running three live intakes end-to-end with a senior-reviewer shadow and producing a passing TA snapshot, SR REM, FRIA assessment, and HITL design assessment.

B) Sector-specific tracks for HR-AI, FinAI, and ClinAI. Deliver distinct training tracks for the three primary high-regulatory-exposure sectors operating AI-embedded workflows. The HR-AI track covers employment-AI decision pipelines (AI-assisted resume screening, interview scoring, promotion scoring); EEOC adverse-impact analysis in the context of AI screening tools; NYC Local Law 144 bias audit requirement and annual reporting; OFCCP contractor AI obligations; HITL design for employment decisions (what substantive review means when 150 resumes are reviewed per hour); FRIA composition for employment Annex III use cases; Art. 22 lawful-basis analysis for employment. The FinAI track covers credit and lending decision pipelines; AI-assisted financial advice workflows; FCRA adverse-action notice requirements; CFPB AI credit guidance (explanation, disparate impact); FINRA model-risk documentation; CO SB-21-169 insurance AI anti-discrimination and explainability; HITL design for high-volume financial decisions; FRIA for credit Annex III use cases. The ClinAI track covers clinical decision-support AI workflows; AI-assisted triage, diagnostics, and treatment recommendation; HIPAA PHI in clinical AI (BAA, minimum-necessary, audit logs); ONC clinical decision-support guidance; FDA AI/SaMD applicable scope; HITL design for clinical decisions; documentation of AI-assisted clinical decisions for malpractice and audit. Each track is paired with the SA reference pattern for the relevant archetype. Required for any team owning a Critical or High-tier workflow in the applicable sector; target ≥1 trained practitioner per workflow.

C) Seasonal, behavior-driven shadow-AI-in-processes campaigns. Tie campaigns to observed shadow-AI risk windows in the business-planning and regulatory cycle: Q1 OKR planning (teams add AI to workflow roadmaps without intake), major product releases (new customer-facing AI features embedded in workflows), post-sector-enforcement-action moments (a public EEOC action against an AI hiring tool, a CFPB enforcement on AI credit decisions, a FTC AI action creates a teachable window), hiring surges (new operations staff arrive with pre-existing habits), and regulatory effective dates (NYC LL144 compliance deadline, CO SB-21-169 effective date). Each campaign carries a pre-measured behavior target (for example, "increase decision-pipeline intake submissions before Q2 OKR sign-off by 40%" or "reduce undisclosed HR-AI screening steps by 60% in Q3") and a post-campaign measurement. Amnesty windows run alongside campaigns; disclosure volume and source attributed to campaign channels. Campaigns missing behavior targets by more than 20% are redesigned by the program sponsor.

Outcome Metrics (L2).

Success Criteria.

• Scenario library of ≥25 real-sourced scenarios across workflow archetypes; reviewer calibration drift inside target for two consecutive quarters.
• Sector-specific tracks (HR-AI, FinAI, ClinAI) delivered; ≥1 trained practitioner per Critical/High-tier workflow.
• ≥2 behavior-driven campaigns run in the last 12 months with measured outcomes; ≥70% of campaigns hit behavior target.
• Training content refresh cadence met; ≥80% of content updated in last 90 days.

Maturity Level 3

Objective: Operate continuous calibration at scale, externalize the AI-process curriculum and HITL design reviewer rubric as industry-shared artifacts, and contribute to emerging AI-deployment-officer and AI-process-officer certification pathways.

Activities.

A) Externalize the curriculum, scenario library, FRIA methodology guide, and HITL design reviewer rubric. Publish the workforce AI-process literacy module (learning objectives, assessment questions, reference-card template), the practitioner role-based training curriculum (module outlines, sector-track coverage matrix, per-archetype reviewer job aids), the anonymized scenario library (scenario format, per-archetype examples, calibration debrief format), the FRIA methodology guide for each Annex III use category (structure, scope, key fundamental-rights dimensions, sign-off requirements, review frequency), and the HITL design reviewer rubric (substantive vs. rubber-stamp taxonomy, review-SLA calculation methodology, override-rate benchmarks by archetype, anchoring-prevention assessment criteria, escalation-path adequacy scoring) under a permissive license or as a consortium deliverable through CSA AI Safety Initiative, NIST AI RMF community of practice, ISO/IEC 42005 community, OECD AI practitioners network, or applicable sector ISAC (FS-ISAC FinAI working group, H-ISAC ClinAI working group, SHRM HR-AI initiative). Accept community contributions; flow changes back into internal content within 30 days. Track adoption via citations in external publications, standards-body reference, downloads, and direct adoption acknowledgment from other organizations.

B) Continuous live calibration. Run monthly calibration rounds: a current anonymized intake sampled from the program's live queue is shared with the reviewer cohort; each reviewer independently scores tier, FRIA adequacy, HITL design adequacy, and top three SR gaps; drift is reported to the program sponsor. Individual reviewer drift is a development signal, not a performance metric, reviewers with persistent drift on specific sector types or FRIA composition receive targeted coaching and additional scenario exposure. Calibration results feed the scenario library directly; new scenarios drawn from intakes where calibration revealed drift are added within 30 days.

C) AI-deployment-officer / AI-process-officer certification contribution. Contribute to AI-deployment-officer and AI-process-officer certification pathways as they emerge: sector-specific ISAC credentials (FS-ISAC AI Risk Certification, H-ISAC AI Safety Certification), OECD AI Practitioners framework, ISO/IEC AI management system implementer credentials, ISACA AI Audit and AI Risk certificates, CSA AI Safety practitioner pathways, and emerging public-sector AI-deployment credentials. Align the org's practitioner capstone with certification-grade rubrics where credentials exist; support reviewers pursuing external credentials. Contribute FRIA methodology real-world experience (how many FRIAs completed, what outcome patterns emerged, what gaps in ISO/IEC 42005 guidance the program encountered) to the ISO/IEC 42005 community at least once per year. Target ≥2 substantive contributions per year to industry curriculum or certification working groups.

Outcome Metrics (L3).

Success Criteria.

• Curriculum, scenario library, FRIA methodology guide, and HITL design reviewer rubric published externally with documented adoption.
• Monthly live calibration operating; drift inside target for two consecutive quarters; calibration results feeding the scenario library continuously.
• ≥50% of Critical-tier reviewers credentialed where credentials exist.
• ≥2 substantive contributions to industry certification / curriculum per year.
• ≥1 ISO/IEC 42005 / OECD FRIA methodology contribution per year where real-world experience justifies.

Common Pitfalls

Level 1. - Workforce training covers data-privacy basics but not EU AI Act Art. 26 deployer duties, Art. 14 human oversight, or GDPR Art. 22 automated-decisioning safeguards, process owners run Annex III workflows without knowing what a FRIA is or that they are responsible for one. - Practitioner training is a one-hour "AI ethics overview" rather than a hands-on module covering FRIA composition, HITL design assessment, Art. 22 lawful-basis analysis, and calibration exercises against real workflow intake scenarios. - Reviewer training is optional, intake-approval permissions granted without training completion; calibration drift is never measured; two reviewers regularly arrive at different FRIA and HITL assessments for the same workflow. - Shadow-AI campaign launches once with an executive message then goes silent, no monthly content, no amnesty attribution, no sector-specific call-outs; training is archetype-agnostic so practitioners apply the wrong compliance lens to decision pipelines and back-office augmentation alike.

Level 2. - Scenario library built from invented examples rather than anonymized real intakes, reviewers learn the shape of a "good" intake but not the actual edge cases (rubber-stamp HITL patterns, Annex III scope ambiguities, sector-specific compliance gaps) that surface in the org's queue. - Sector tracks are optional; teams skip them and produce workflow designs in DR that do not account for FCRA adverse-action obligations or NYC LL144 bias audit requirements; DR catches the gaps late and at high cost. - Campaigns launched without a pre-measured behavior target, "shadow-AI awareness" is claimed as a success without data on whether undisclosed decision pipelines decreased or amnesty disclosures increased. - Calibration drift is measured but not acted on, reviewers with persistent FRIA or HITL assessment drift never receive coaching; the calibration exercise becomes a box-check rather than a development signal.

Level 3. - External publication without ongoing maintenance, other organizations find a stale FRIA methodology guide or an outdated HITL design rubric and stop trusting the program; citations dry up. - Credentialing becomes performative, reviewers pursue credentials that do not map to the org's actual tier-treatment rubric and FRIA gate requirements; credential acquisition is celebrated but calibration drift stays unchanged. - Live calibration becomes a gotcha rather than a development signal, reviewers learn to game the monthly exercise and improve scores without improving actual intake quality. - Contributions to ISO/IEC 42005 / OECD do not loop back internally, what is published externally drifts from what reviewers use internally; HITL design benchmarks contributed externally reflect the org's under-developed early L1 practice and mislead other organizations.

Practice Maturity Questions

Level 1. 1. Have all process owners, product managers, operations managers, and business analysts touching AI-embedded workflows completed a current-year AI-process literacy course covering the seven workflow archetypes, EU AI Act Art. 26 deployer duties / Art. 14 human oversight / Art. 50 transparency, GDPR Art. 22 automated-decisioning safeguards, HITL design (substantive vs. rubber-stamp), Annex III FRIA triggers, and the intake gate process, with ≥90% completion and content updated within 30 days of any policy or archetype change? Evidence: LMS completion report, content change-log, and the most recent literacy module. 2. Has the practitioner population (AppSec reviewers, Privacy/Legal counsel, Compliance officers, Internal Audit, business-unit review representatives) completed role-based training covering workflow-archetype threat walkthrough with HAI TTPs (EA/AGH/TM/RA), FRIA composition for Annex III use categories, HITL design assessment (substantive review SLA, override-rate targets, anchoring-prevention criteria), Art. 22 lawful-basis analysis, fairness/bias-at-compliance-intersection indicators, and sector-specific deep-dives (HR-AI, FinAI, ClinAI), with completion gated on intake-approval permissions and calibration drift ≤1 tier step and ≤2 FRIA/HITL mismatches per sample for two consecutive quarters? Evidence: practitioner curriculum, permission-gating record, and calibration-exercise results. 3. Is a shadow-AI-in-processes awareness campaign running with at least monthly content, a visible amnesty path linked from the AI-in-Business-Process Policy and intake form, and measurable attribution of intake submissions and amnesty disclosures to campaign channels, with disclosures rising in Q1–Q2 after launch then declining as the sanctioned-workflow program grows? Evidence: campaign content calendar, channel-attribution report, and amnesty disclosure trend.

Level 2. 1. Is there a scenario library of ≥25 anonymized real intake cases powering practitioner training across the org's in-scope workflow archetypes, with paired calibration exercises showing Critical-tier drift ≤1 tier step and ≤1 FRIA/HITL mismatch per sample for two consecutive quarters? Evidence: scenario library index and quarterly Critical-tier calibration drift report. 2. Have sector-specific tracks (HR-AI, FinAI, ClinAI as applicable) been delivered to ≥1 practitioner per Critical/High-tier workflow, with team-level training coverage tracked in the SM-Processes inventory? Evidence: track rosters reconciled against the inventory's Critical/High workflow list. 3. Are shadow-AI campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets and post-campaign measurement, with ≥70% of campaigns hitting their target, and is ≥80% of training content updated in the last 90 days? Evidence: campaign plans with pre/post measurements and content-refresh changelog.

Level 3. 1. Has the practitioner curriculum, anonymized scenario library, FRIA methodology guide, and HITL design reviewer rubric been published externally (CSA, NIST AI RMF community, ISO/IEC 42005, OECD, or sector ISAC) with documented adoption, citations, standards-body reference, or direct acknowledgment, and do contributions loop back into internal content within 30 days? Evidence: external publication links, adoption telemetry, and internal update changelog. 2. Is a monthly live calibration cadence operating (anonymized intake from the live queue, independent reviewer scoring, drift reported to sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier reviewers hold an external AI-deployment-officer or AI-process-governance credential where one exists? Evidence: calibration log, scenario-library update trail, and credential registry. 3. Does the program contribute ≥2 substantive artifacts per year to industry AI-process certification or curriculum working groups, and ≥1 FRIA methodology or HITL design contribution to ISO/IEC 42005 or OECD per year where real-world experience justifies a contribution? Evidence: contribution log with acceptance confirmations and the most recent ISO/IEC 42005 / OECD submission.

17. Threat Assessment (TA)

Practice Overview

Objective: Build and maintain a reusable threat library for the AI/HAI-embedded business workflows the organization operates, one archetype-level threat model per workflow type, so every workflow entering the SM inventory produces a threat snapshot in minutes rather than a blank-page exercise.

Description: TA-Processes catalogs the threats specific to AI/HAI-embedded business workflows the organization operates. At L1 the library covers one threat model per workflow archetype, decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow, mapped to HAIAMM's HAI-specific TTPs (EA, AGH, TM, RA), to MITRE ATLAS tactics (TA0001–TA0014), and to OWASP LLM/Agentic Top 10. Each workflow registered in the SM inventory generates a threat snapshot by pulling the archetype model and adding workflow-specific deltas: decision stakes, customer reach, HITL placement and depth, data classes in scope, regulatory exposure, and downstream systems receiving AI output. L2 layers per-workflow deep models for Critical-tier workflows and red-teams the threat library quarterly against real in-scope workflows. L3 automates library maintenance from telemetry and contributes discovered process-level TTPs back to MITRE ATLAS, AVID, and sector ISACs.

Context: Classic business-process risk management was not designed to enumerate AI-specific workflow failure modes, decision-laundering via AI endorsement, rubber-stamp HITL that creates governance theater without substantive review, silent-decision-drift as AI scoring thresholds shift outcomes without human awareness, adversarial prompt injection arriving through customer-supplied content and propagating to downstream systems, knowledge-base poisoning that contaminates every query. These are process-level risks owned by the teams that design, operate, and govern workflows that embed AI output. TA-Processes closes the gap by making workflow-specific threats a first-class library that threat modelers pull from at every intake, and by tying every archetype threat to a specific ATLAS tactic so the walk from attacker capability to workflow exposure is concrete rather than narrative.

Maturity Level 1

Objective: Build the AI/HAI workflow archetype threat library, integrate a threat snapshot into every workflow intake, and ensure every workflow's threat surface is documented before AI embedding is sanctioned.

Activities.

A) Build the AI/HAI workflow archetype threat library. Author one threat model per AI/HAI workflow archetype the org operates. Each is concise (target two pages), scoped to workflows that embed AI/HAI output or decisions, and maps threats to HAI TTPs, ATLAS tactic IDs, OWASP LLM/Agentic Top 10 references, and the PC-Processes priority compliance map. Archetypes to cover: decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow. Per-archetype threat content covers EA patterns, AI participating in consequential decisions with no recorded accountability boundary, back-office assistants with unbounded tool scope, autonomous customer-facing flow drift; AGH patterns, indirect prompt injection via customer-supplied content propagating to downstream systems, reviewer-side prompt injection through review-UI display of AI-generated rationale, RAG retrieval-path injection, knowledge-base content poisoning; TM patterns, back-office AI assistant invoked with data outside its authorized scope (regulated data egress to AI provider), retrieval-extraction by malicious insiders bypassing document-level access controls, workflow tool combinations abused to bypass approval gates; RA patterns, silent-decision-drift as model versions or thresholds shift outcomes without governance review, rubber-stamp HITL where reviewers approve unread, AI-suggestion bias accumulating into systematic back-office outcome skew, autonomous-action drift in customer flows. Beyond HAI TTPs, each archetype model documents the ATLAS full tactic walk with techniques selected or excluded with rationale, and cross-references OWASP LLM Top 10 items (LLM01 Prompt Injection, LLM02 Insecure Output Handling, LLM06 Excessive Agency, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation) and compliance linkage (EU AI Act Art. 14 human oversight, Art. 22 GDPR automated decisioning, Art. 26 deployer duties, Art. 50 transparency, Art. 35 DPIA, Art. 27 FRIA, FCRA, EEOC, NYC LL 144, CO SB-21-169, FINRA model risk). Owner: named TA-Processes library steward; cadence: reviewed quarterly; versioned in a single location linked from every SM inventory record.

B) Produce a per-intake threat snapshot for every SM workflow registration. Bind TA into the SM intake flow, every new workflow registration emits a threat snapshot before Sanctioned status is issued; Provisional-status workflows receive a snapshot within five business days. Snapshot contents (designed to fit one screen): which archetype(s) apply, a workflow may be composite (e.g., a customer loan application is both decision pipeline and customer-facing flow); workflow-specific deltas over the archetype model covering decision stakes (what outcome changes for which population), HITL placement and depth, data classes in scope, regulatory exposure (Annex III trigger, Art. 22 lawful basis, sector-specific rules), and downstream systems receiving AI output; top-five threats for this workflow each with HAI TTP tag, ATLAS tactic ID, OWASP reference, and compliance linkage; controls already evident from the workflow design vs. gaps for SR/SA follow-up; reviewer, date, and re-snapshot expiry triggered by scope change, new data classes, AI model swap, material HITL restructuring, or regulatory change. Time target: one business day per intake with the library available.

C) Author the shadow-AI-in-processes threat view. Shadow AI in processes, AI tools embedded in workflows without governance, staff using consumer GenAI to augment business tasks outside sanctioned channels, has its own threat surface. The shadow-AI-in-processes threat document covers entry vectors (staff copying customer data into consumer GenAI for task support, departmental SaaS tools with AI features silently enabled, business units building lightweight automation with AI APIs outside intake, AI-embedded features in approved SaaS without corresponding workflow governance); elevated threats for shadow workflows (no threat model applied, no SR requirements pack, no disclosure or oversight design, EU AI Act Art. 26 deployer duties unmet because the workflow is unknown); specific failure modes (customer PII reaching unsanctioned AI providers via copy-paste, AI-generated decisions affecting persons without Art. 22 lawful basis, regulated content reaching AI tools without DPA coverage); and detections available at L1 (DLP signals for AI provider domains, SaaS admin console reports of newly enabled AI features, staff survey discovery, expense/billing signals for consumer AI subscriptions). Output: a "Shadow AI in Processes, Threat View" one-pager reviewed by the program sponsor and feeding the ML-Processes detection backlog and IM-Processes triage playbook.

Outcome Metrics (L1).

Success Criteria.

• Seven archetype threat models published (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), each tagged to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs, OWASP LLM/Agentic Top 10 references, and the PC-Processes priority compliance map.
• Threat snapshot gate live in the SM intake flow, 100% of newly Sanctioned AI/HAI-embedded workflows in the last 90 days have a snapshot attached.
• Shadow-AI-in-processes threat view published, reviewed by the program sponsor, and feeding the ML-Processes detection backlog.
• Named library steward and quarterly refresh cadence operating.
• ≥90% of active AI/HAI-embedded workflows in the inventory carry a current-year snapshot.

Maturity Level 2

Objective: Layer per-workflow deep threat models on top of archetype snapshots for Critical-tier workflows, integrate external AI-security threat intelligence, and red-team the threat library quarterly against real in-scope workflows.

Activities.

A) Per-workflow deep threat modeling for Critical-tier workflows. For every Critical-tier workflow in the SM inventory, produce a full per-workflow threat model that goes beyond the archetype snapshot. Coverage: workflow-specific attack trees including per-stakeholder abuse paths, specific HITL placement with failure modes at each gate, specific data classes with exfiltration and misuse paths, and specific downstream system dependencies with propagation risks; an abuse-case catalog with named adversary archetypes (affected persons gaming the system, malicious insiders, compromised AI vendor, external attacker via customer input channel) and concrete attack narratives for this specific workflow; deployer-duty mapping covering EU AI Act Art. 26 obligations and the threat-control chain specific to this workflow, Art. 14 human oversight and Art. 15 accuracy/robustness; and a full ATLAS tactic walk for the workflow with technique-level specificity across all 14 tactics. High-tier workflows receive archetype snapshot plus workflow-specific deltas and an ATLAS full tactic walk; no High-tier workflow remains on archetype-only. Refresh cadence: Critical semi-annual plus change-driven on HITL restructuring, AI model swap, scope expansion, or regulatory change; High annual plus change-driven.

B) External AI-security threat intelligence integration. Subscribe to and operationalize MITRE ATLAS updates relevant to process-level techniques, AVID entries for process-domain abuse patterns, sector ISACs with AI working groups relevant to the org's process domains (HR-AI for employment decision systems, FinAI for credit decision systems, ClinAI for clinical decision support), and regulatory enforcement actions and supervisory guidance touching AI-in-processes (FTC actions on AI decision systems, CFPB adverse-action guidance, EEOC AI bias enforcement, EU AI Act Annex III enforcement developments). Quarterly triage cadence determines which new items change the archetype library, change per-workflow models, or require updates to dependent SR or ST artifacts. Changes are change-logged and reviewed by the library steward and the IM backlog owner. Intel-to-library update lead time targets 30 days on Critical-impact items.

C) Red-team the threat library itself. Each quarter, ST-Processes runs an adversarial probe against an in-scope AI/HAI-embedded workflow using only the threat scenarios documented in the library for that archetype. Threats the exercise identifies that are not in the library are library gaps, not passing findings. Gap closure is a governance activity: every gap becomes a ticket with a named owner and an expiry date; Critical-tier gaps close within 30 days, High-tier within 60 days. The gap rate per quarter trends down as the library matures. Gaps are also reviewed for SR and ST update implications, a threat absent from the library is also likely absent from a requirement and a test.

Outcome Metrics (L2).

Success Criteria.

• Per-workflow deep threat models live for 100% of Critical-tier and ≥90% of High-tier workflows, with refresh cadences met.
• External threat intel integrated with quarterly triage and documented change-log; intel-to-library update ≤30 days on Critical-impact items.
• Quarterly red-team-the-library exercise operating; every gap carries a named owner and expiry date; Critical-tier gaps close within 30 days.

Maturity Level 3

Objective: Automate threat-library maintenance from telemetry and external feeds, and contribute discovered process-level AI/HAI TTPs back to MITRE ATLAS, AVID, and sector ISACs.

Activities.

A) Telemetry-driven library updates. Wire ML-Processes detection alerts, IM-Processes post-incident review records, external feeds (ATLAS technique additions, AVID new entries, OWASP LLM/Agentic Top 10 revision drafts, sector-ISAC AI advisories, regulatory enforcement actions), and academic publication scanning into an auto-proposal pipeline. Human curators approve, reject, or defer each auto-proposal. The change-log is machine-readable; downstream SR, SA, and ST artifacts subscribe to the change feed and receive update-required notifications when a threat they reference changes. Target: ≥60% of library changes auto-proposed; lead time from signal to update ≤14 days.

B) Industry contribution. Contribute emerging first-party-observed process-level TTPs to MITRE ATLAS, decision-laundering as a Defense Evasion technique, rubber-stamp HITL as a Persistence-of-effect technique, silent-decision-drift as an Impact technique, following ATLAS evidence-and-provenance requirements; to AVID via structured disclosure submissions for newly discovered process-domain vulnerabilities; to sector ISACs (HR-AI, FinAI, ClinAI) with operationally-observed process-abuse patterns; and to ISO/IEC 42005 and OECD AI with practitioner input on process-level AI risk taxonomy. Target: at least four substantive contributions per year, quality-graded and legally vetted before submission, every contribution anonymized.

C) Shared threat-model artifacts. Publish anonymized workflow archetype threat models (scrubbed of org-specific tool names and process details) under a permissive license for peer-org adoption. Host or co-host at least one industry tabletop per year tied to the library, ATLAS practitioner table, sector ISAC AI working group, or OWASP AI chapter.

Outcome Metrics (L3).

Success Criteria.

• Library auto-update pipeline operating with ≤14-day lead time from signal to update; ≥60% of changes auto-proposed.
• ≥4 industry contributions per year; ≥2 recognized in external artifacts (ATLAS merge, AVID entry, sector ISAC advisory).
• Anonymized archetype threat models published under permissive license with tracked peer-org adoption.
• Industry tabletop hosted or co-hosted in last 12 months.

Common Pitfalls

Level 1. - Threat models describe "the AI" as the actor performing a security task rather than the AI-embedded workflow as the subject being assessed, the library catalogs what AI does rather than what threats face the workflows the org operates. - Archetype library covers only customer-facing workflows; back-office augmentation and knowledge-management workflows are excluded because "they're internal only", the largest actual-harm surface for data-egress and decision-bias is missed. - Threat snapshot is a checklist checkbox without workflow-specific deltas, no HITL placement documented, no decision stakes recorded, making snapshots useless for SR and SA follow-through. - ATLAS tactic walk is performed for narrative completeness but no technique IDs are assigned, the walk produces prose, not structured references that ST and IR can act on.

Level 2. - "Per-workflow deep model" is the archetype snapshot with the workflow name swapped in, no workflow-specific decision stakes, no HITL failure-mode analysis, no regulatory mapping; the depth is cosmetic. - External intel is subscribed but never triaged, ATLAS updates and sector ISAC advisories pile up unread; the library is frozen at L1 publication while the threat landscape evolves. - Red-team-the-library exercise adds findings to a log but never cross-checks against the library, gaps are never surfaced because the comparison was never made. - Deep modeling stops at Critical tier; High-tier workflows affecting regulated populations remain on archetype-only snapshots.

Level 3. - Auto-proposal pipeline accepts signals without curation, false-positive ML-Processes detections pollute the library with phantom threats; downstream SR and ST artifacts generate incorrect requirements and tests. - Contributions to MITRE/AVID/sector ISACs are observer submissions, comments, conference talks, rather than technical artifacts with evidence that produce substantive change. - Published anonymized archetype models are not maintained after release, external adopters build on a stale version while the internal library has advanced; the divergence becomes visible when discrepancies are cited publicly. - Telemetry-driven update loop fires on every minor workflow change; teams disable the telemetry feed to stop the noise rather than tune signal sensitivity.

Practice Maturity Questions

Level 1. 1. Are there published, versioned threat models for all seven AI/HAI workflow archetypes, decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow, each mapping archetype threats to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs, OWASP LLM/Agentic Top 10 references, and PC-Processes compliance items, with a named library steward and a documented quarterly refresh cadence? Evidence: TA library with seven versioned archetype documents and a named owner record. 2. Does every AI/HAI-embedded workflow entering the SM inventory receive a threat snapshot (delivered within one business day of intake) that documents the applicable archetype(s), workflow-specific deltas (decision stakes, HITL placement, data classes, regulatory exposure, downstream systems), top-5 threats with HAI TTP tags and ATLAS tactic IDs, and gaps for SR/SA follow-up, with 100% of newly Sanctioned workflows carrying a snapshot in the last 90 days? Evidence: SM intake tickets with snapshot attachments dated within intake SLA. 3. Is there a published shadow-AI-in-processes threat view, reviewed by the program sponsor in the last 12 months, that documents entry vectors, elevated threat scenarios for unsanctioned AI-embedded workflows, and the specific detections used to surface them? Evidence: Dated threat view document with program-sponsor review record and links to ML-Processes and IM-Processes backlogs.

Level 2. 1. Does every Critical-tier AI/HAI-embedded workflow have a current-year per-workflow deep threat model covering workflow-specific attack trees, an abuse-case catalog, deployer-duty mapping, and a full ATLAS tactic walk with technique-level specificity, with a semi-annual refresh cadence and change-driven updates on HITL restructuring, AI model swap, or scope change? Evidence: Per-workflow threat model documents dated within cycle, with change-driven update records. 2. Is external AI-security threat intel (MITRE ATLAS, AVID, sector ISACs, regulatory enforcement actions) integrated with a quarterly triage cadence and a documented change-log, with intel-to-library update ≤30 days on Critical-impact items? Evidence: Quarterly triage meeting records and change-log entries with signal-to-update timestamps. 3. Do you run a quarterly red-team-the-library exercise that probes an in-scope AI/HAI-embedded workflow using only library threats and surfaces misses as library gaps, with every gap carrying a named owner and expiry date, and Critical gaps closing within 30 days? Evidence: Quarterly exercise artifacts with gap register showing owner assignments and closure dates.

Level 3. 1. Does the threat library auto-update from telemetry (ML-Processes, IM-Processes) and external feeds via a human-curated auto-proposal pipeline, with ≥60% of changes auto-proposed, a ≤14-day lead time from signal to update, and a machine-readable change-log consumed by downstream SR and ST practices? Evidence: Pipeline telemetry showing proposal rate and lead-time distribution; SR/ST subscription confirmation. 2. Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS / AVID / sector ISACs / ISO/OECD AI, with at least two externally recognized in published advisory, standard revision, or ATLAS merge? Evidence: Contribution log with external recognition citations. 3. Are anonymized workflow archetype threat models published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year tied to the library? Evidence: License artifact, adoption tracking data, tabletop event record.

18. Security Requirements (SR)

Practice Overview

Objective: Translate the threats from TA-Processes and the policies from PC-Processes into a reusable Requirements Pack for AI/HAI-embedded business workflows the organization operates, a base set plus per-archetype deltas, so every workflow entering production carries a testable Requirements-Evidence Map rather than a blank slate.

Description: SR-Processes authors a small, archetype-keyed AI/HAI Workflow Requirements Pack: one base requirement set that applies to every AI/HAI-embedded workflow, plus per-archetype deltas for decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, and knowledge-management workflow. Each requirement is stated as a testable condition, either a measurable SLA or a binary evidence condition, not a narrative aspiration. Every workflow reaching SM intake carries a Requirements-Evidence Map (REM) linking each applicable pack requirement to current evidence, accepted gaps (with a named owner and expiry date), and compensating controls. Cross-domain linkage is explicit: a workflow REM cross-references the underlying Software, Data, and Infrastructure REMs for components the workflow depends on. Downstream practices, SA, DR, IR, ST, inherit the REM rather than re-deriving requirements per workflow.

Context: Without a shared requirements pack, each design review, implementation review, and process audit invents the acceptance bar from scratch. Two reviewers score the same customer-facing decision pipeline differently. EU AI Act Art. 26 deployer duties, Art. 50 disclosure requirements, Art. 14 human oversight, and GDPR Art. 22 automated-decisioning safeguards are not traceable to specific requirements in specific workflows. Human oversight design is undocumented; override audit trails are missing; affected-persons rights surfaces are untested. SR-Processes closes that gap with the minimum viable pack, not a checklist of 60 items, but the 20-ish requirements that matter for every AI/HAI-embedded workflow the org operates, plus archetype-specific additions for decision pipelines, customer-facing flows, HITL chains, content-generation workflows, and knowledge-management workflows.

Maturity Level 1

Objective: Publish the AI/HAI Workflow Requirements Pack (base plus per-archetype deltas), wire it into the SM intake gate, and produce a Requirements-Evidence Map for every workflow entering production.

Activities.

A) Author the base AI/HAI Workflow Requirements Pack. The base pack applies to every AI/HAI-embedded workflow the org operates, regardless of archetype. Keep it to 20 or fewer base requirements at L1. Each requirement has an ID, a statement, a rationale (threat tag from TA-Processes and compliance tag from PC-Processes), an evidence source, a test method, and an acceptance criterion. Minimum base categories: human oversight design, explicit documentation of HITL placement, depth of review at each gate (substantive vs. notification-only), override authority, override trigger conditions, and reviewer-unavailable fallback (escalate or hold, never silent auto-approve), aligned to EU AI Act Art. 14; disclosure, for any workflow delivering AI output to an external person, a documented disclosure mechanism (how and when the affected person is informed of AI involvement, what the disclosure says, how compliance is verified), aligned to EU AI Act Art. 50; decision logging, every AI-output-driven decision logged with the AI output, timestamp, subject identifier, model/version, and reviewing human (if any), retention meeting the longest applicable regulation; override audit trail, every HITL override recorded with reviewer identity, override direction, rationale, timestamp, and AI output reference, with no override unrecorded; output-integrity SLA, drift-detection mechanism with baseline established at launch and alert threshold defined (e.g., ≥5% shift in approval/rejection rate) that triggers human review before the next production batch; reviewer-capacity SLA, maximum HITL queue depth, minimum reviewer-per-volume ratio, maximum review SLA, and capacity-breach procedure that escalates rather than auto-approves; affected-persons rights surface, documented path for GDPR Arts. 15–22 subject access, explanation of decision logic, and contestation, tested at L1; DPIA / FRIA evidence, for workflows triggering GDPR Art. 35 DPIA or EU AI Act Art. 27 FRIA obligations, evidence the assessment is completed and current; fallback / kill-switch, documented degraded-mode procedure for AI component failure, halt criterion defined and tested; sector-specific overlays where applicable, FCRA adverse-action notice, EEOC bias-audit documentation, NYC LL 144 bias audit, CO SB-21-169, FINRA model-risk management. Every base requirement is tagged to at least one TA-Processes archetype threat and at least one item from the PC-Processes priority compliance map.

B) Author per-archetype requirement deltas. Each archetype carries a short delta (three to eight additional requirements) reflecting the threat-specific obligations from TA-Processes' archetype threat models. The decision pipeline delta covers Art. 22 lawful-basis documentation, Annex III FRIA requirement when applicable, and per-protected-class outcome-distribution monitoring with an alert threshold. The customer-facing flow delta requires Art. 50 disclosure UX tested with representative users, an escalation path to a human agent for low-confidence or refused requests, and an output filter between AI generation and customer delivery. The HITL chain delta requires a review UI that surfaces AI rationale and confidence indicators, counterfactuals for Critical and High tier (what input change would flip the AI output), and reviewer-side injection defense (AI-generated content treated as untrusted display data). The back-office augmentation delta requires a scoped tool list, an output-review gate enforced by workflow design, DPO sign-off when regulated data classes are involved, and session-bounded context. The approval/review workflow delta requires documented classifier threshold with calibration justification, borderline-case routing to human reviewers, and class-shift monitoring on approval/rejection rates per protected-class group. The content-generation workflow delta requires prompt-template versioning, an output-review gate before publication of material outputs, a copyright filter, and a brand-voice check. The knowledge-management workflow delta requires per-chunk provenance (source, classification, last-verified date), injection defense (retrieved content treated as untrusted), per-role retrieval scoping enforced at query time, and a freshness SLA on corpus documents.

C) Wire the pack into the SM intake gate and produce a REM per workflow. Every workflow approved for production carries a REM. Each applicable pack requirement is marked Met, Met-with-compensating-control, Gap-accepted, or Not-applicable with justification. Each Met row cites specific evidence: process-design document element, HITL gate implementation evidence, admin-console screenshot, test result reference, DPA clause citation, DPIA/FRIA completion date and registry reference, or live-system demonstration note. Each Gap-accepted row names a compensating control, a named owner, and a re-review date (maximum 90 days at L1). The REM is stored with the SM inventory record for the workflow. Cross-domain linkage: the workflow REM cross-references the REMs for underlying Software, Data, and Infrastructure components, a gap in a component REM that affects the workflow is surfaced in the workflow REM, not silently omitted. Material changes, AI model swap, HITL restructuring, new data classes, scope expansion, regulatory change, trigger REM re-review before the change ships to production.

Outcome Metrics (L1).

Success Criteria.

• Base pack plus seven archetype deltas published, tagged to TA-Processes threats and the PC-Processes priority compliance map.
• 100% of new AI/HAI-embedded workflows approved in the last 90 days have a REM on file.
• ≥90% of active AI/HAI-embedded workflows in the SM inventory carry a current-year REM.
• Named pack owner and quarterly refresh cadence operating.
• Accepted-gap backlog tracked with every gap carrying a named owner and re-review date; median age inside ≤90 days.
• Workflow REMs cross-reference underlying Software, Data, and Infrastructure component REMs.

Maturity Level 2

Objective: Replace qualitative requirements with quantitative, SLA-bound, and binary-evidence conditions; calibrate the requirements pack per risk tier; and validate REM evidence continuously for Critical and High-tier workflows.

Activities.

A) Quantitative and binary requirement pack. For every requirement in the base pack and each archetype delta, replace qualitative language with measurable or binary conditions. Decision logging retention: specify exact retention periods by workflow tier and regulation (decision logs ≥24 months for EU AI Act Art. 26 deployer-duty evidence; ≥36 months for FCRA adverse-action workflows). Override audit trail completeness: binary, last audit sample of 50 random override records confirmed 100% have reviewer identity, override direction, rationale, timestamp, and AI output reference, with audit date on file. Output-integrity drift alert: drift-detection baseline established at launch; a ≥5% shift in approval/rejection rate or ≥10% shift in score distribution triggers a human review gate within 24 hours, with last alert test date and result on file. Reviewer-capacity SLA: HITL queue depth ≤N cases, reviewer-per-volume ratio ≥R reviewers per V cases per day, maximum review SLA ≤T hours, queue metrics reported daily, breach of any threshold triggers the capacity-breach procedure. Kill-switch test: binary, emergency-halt mechanism exists, tested quarterly, halts the workflow within ≤T minutes, and produces a halt-record confirming no unreviewed AI output was acted upon after halt. Art. 22 lawful basis: binary, lawful basis documented at a referenced section of the DPIA/FRIA, reviewed by Legal in a stated month/year, current with no review outstanding. DPIA/FRIA currency: binary, completed date, last reviewed date, next review scheduled, no DPIA/FRIA more than 24 months stale for Critical-tier workflows.

B) Per-tier requirement depth. Publish a per-tier pack overlay aligned to the SM-Processes L2 tier-treatment matrix. Critical tier: full base pack and all applicable archetype deltas; executive sponsor sign-off on the completed REM before Sanctioned status is issued; EU AI Act Art. 26 full deployer-duty checklist as a discrete appendix; DPIA/FRIA evidence required and current; accepted-gap aging SLA of 60 days maximum before mandatory escalation to the program sponsor; re-validation of all Critical-tier REM evidence quarterly. High tier: full base pack and applicable archetype deltas; REM required; DPIA/FRIA required for Annex III triggers; accepted-gap aging SLA of 90 days; re-validation semi-annually. Medium tier: base pack and applicable archetype deltas; accepted-gap aging SLA of 120 days; re-validation annually. Low tier: base pack only; fast-track process with abbreviated evidence citations acceptable; re-validation at annual review.

C) Continuous REM-evidence validation and cross-domain linkage. Critical-tier REMs re-validated quarterly; High-tier semi-annually. Validation method: select a stratified sample of REM rows per workflow, at least one row per base category, and verify each cited evidence artifact against current observable reality: decision logging volume, retention, and exportability checked against actual settings; override audit trail sampled against recent overrides; kill-switch re-run and result verified against SLA; HITL queue metrics checked against stated thresholds; Art. 50 disclosure tested with a representative user interaction. REM auto-revalidation is triggered by IR-Processes findings (implementation drift), IM-Processes incidents (post-incident reviews touching a pack requirement), and TA-Processes library updates (new threat intelligence that changes a threat the requirement addresses). Cross-domain linkage is re-verified at the same cadence: component REM changes (Software, Data, Infrastructure) that affect workflow requirements are surfaced to the workflow REM owner within 5 business days. Validation deltas (a row claimed Met but evidence fails re-validation) are routed to IM-Processes as findings with severity tags and remediation SLAs matching the workflow's tier.

Outcome Metrics (L2).

Success Criteria.

• 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative language removed.
• ≥95% of Critical-tier workflow REMs re-validated against observed reality in the last 90 days; validation deltas routed to IM-Processes.
• No Critical-tier accepted gap open beyond 60 days without documented escalation to the program sponsor.
• 100% of Critical-tier workflows carry full EU AI Act Art. 26 deployer-duty checklist evidence and current DPIA/FRIA evidence in their REM.
• Per-tier pack overlay published and enforced; SM intake routing verified.

Maturity Level 3

Objective: Express the AI/HAI Workflow Requirements Pack as a machine-readable artifact, automate REM-evidence validation from process telemetry and runtime signals, and contribute to industry-standard AI process security requirements bodies.

Activities.

A) Machine-readable pack and workflow-execution attestation. Express the Requirements Pack (base plus archetype deltas) in a structured schema, JSON or YAML, where each requirement has an ID, a machine-readable evidence type (log-query, config-check, test-result-reference, or manual-attestation), an acceptance predicate, and a tier applicability field. For workflow-execution monitoring on Critical and High-tier workflows: automated checks run against the workflow's REM at defined intervals or on execution triggers (decision-log volume and completeness confirmed, HITL queue depth within threshold, override audit trail completeness sampled, kill-switch test result within defined age, drift-detection baseline within alert threshold); checks that pass write a signed attestation to the REM record; checks that fail for Critical-tier workflows emit an immediate alert to the workflow owner and the IM-Processes backlog; checks that fail for High-tier emit a warning and route a finding to IM-Processes; manual-attestation rows (Art. 22 lawful basis review, DPIA/FRIA currency, brand-voice check) are prompted for re-confirmation at the defined cadence.

B) Automated REM-evidence validation from runtime signals. Subscribe the REM validation pipeline to ML-Processes monitoring (decision-log completeness signal, HITL queue-depth signal, drift-detection output, reviewer-capacity signal), IM-Processes incident records (post-incident reviews touching a pack requirement auto-flag relevant REM rows for re-validation), and SM inventory change events (a tier upgrade auto-triggers a full REM re-validation run under the new tier's requirements depth). Human review is reserved for novel requirement types not yet in the structured schema, accepted-gap escalations, and workflow-specific clauses outside the standard archetype deltas.

C) Standards contribution. Contribute the machine-readable workflow requirement schema and REM schema to ISO/IEC 42005 as an open artifact for AI process assurance; submit practitioner input to OECD AI Principles implementation guidance on process-level human oversight requirements and decision-logging standards; submit concrete, testable AI process security requirements as candidate clause language to sector standards bodies (FINRA model-risk management, CFPB adverse-action requirements, FDA SaMD guidance, EEOC AI bias audit standards); and submit practitioner commentary grounded in REM experience to NIST AI RMF Playbook GOVERN and MANAGE function process-level requirement language. Target: at least two substantive contributions per year, legally vetted and anonymized.

Outcome Metrics (L3).

Success Criteria.

• Machine-readable pack schema published; ≥80% of Critical-tier workflow REM requirements have automated execution-time attestation.
• ≥70% of REM evidence rows auto-validated; human review reserved for exceptions and novel clauses.
• Zero Critical-tier workflows operating with failing REM checks undetected; monitoring telemetry confirms enforcement.
• Pack and REM schema published under permissive license with tracked external adoption.
• ≥2 substantive industry-standard contributions per year.

Common Pitfalls

Level 1. - The base pack is authored with 40+ requirements at L1, reviewers cannot complete a workflow REM in three business days and begin skipping rows, producing REMs that are structurally complete but evidentially hollow. - Per-archetype deltas are written but never wired into the intake process, every workflow gets the base pack only; Art. 22 lawful-basis requirements and HITL design requirements are missed on every intake for decision pipelines and HITL chains. - Gap-accepted rows lack expiry dates and named owners, the backlog grows silently until an audit surfaces a Critical-tier gap accepted for 18 months with no action. - DPIA/FRIA requirement is in the pack but the evidence row is accepted with "in progress", no completion date, no registry reference, no actual assessment, and the gap never closes.

Level 2. - Quantitative conditions are set too loosely to be testable ("HITL review within a reasonable timeframe" becomes "≤5 business days" on paper but is never verified against actual review queue metrics); the SLA exists but is never confirmed. - REM re-validation is scheduled quarterly for Critical-tier but samples only what process owners self-report, decision-log completeness, HITL queue metrics, and ML drift signals are never cross-referenced; evidence integrity is unverified. - Critical-tier accepted-gap escalation process exists in policy but no escalation has ever reached the sponsor, the threshold is written but the mechanism to invoke it is absent. - Per-tier differentiation is documented in the pack overlay but not enforced at intake, Low-tier workflows receive the same review depth as Critical-tier because the intake routing logic was never built.

Level 3. - The machine-readable pack schema is published but the org stops maintaining the public version, the external artifact becomes stale while the internal version evolves; external adopters discover discrepancies during implementation. - Workflow-execution attestation covers launch-time checks but not drift, a kill-switch that passes at launch is disabled six weeks later with no detection; the attestation record shows "passed." - Standards contributions are submitted to working groups with no active AI process security track, they appear in the contribution log but have no path to adoption and no measurable industry impact. - Automated REM validation reports pass/fail counts to the program dashboard but never feeds failures back to the pack, repeatedly failing checks stay in the pack, generating noise and eroding trust in the gate.

Practice Maturity Questions

Level 1. 1. Is there a published, versioned AI/HAI Workflow Requirements Pack containing a base set of 20 or fewer requirements plus seven per-archetype deltas, with every requirement tagged to at least one TA-Processes archetype threat and one PC-Processes priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per workflow at intake? Evidence: Pack document with ID-tagged requirements, quarterly refresh record, and named pack owner. 2. Do 100% of new AI/HAI-embedded workflows approved in the last 90 days have a completed REM on file, with every applicable requirement marked Met, Met-with-compensating-control, Gap-accepted, or Not-applicable, each Met row citing specific verifiable evidence, each Gap-accepted row naming a compensating control, owner, and re-review date, and do workflow REMs cross-reference the underlying Software, Data, and Infrastructure component REMs? Evidence: SM intake tickets with attached REM artifacts; gap register with owner and expiry fields populated; cross-domain linkage records. 3. Is the pack on a quarterly refresh cadence with a named owner, and are SA, DR, IR, and ST practices citing REM rows rather than independently re-deriving requirements from scratch? Evidence: Quarterly refresh records; cross-references from DR, IR, and ST artifacts back to REM row IDs.

Level 2. 1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (review queue depth, kill-switch response time, drift-detection threshold, log-retention days) and binary state (Art. 22 lawful basis documented, DPIA/FRIA current, override audit trail confirmed, Art. 50 disclosure tested) specified, and has all qualitative "reasonable" and "appropriate" language been removed? Evidence: Pack document with no instances of qualitative acceptance language. 2. Are ≥95% of Critical-tier workflow REMs re-validated against observed reality (decision-log volume, HITL queue metrics, kill-switch test, Art. 50 disclosure test, override audit sample) in the last 90 days, with validation deltas routed to IM-Processes and no Critical-tier accepted gap aging beyond 60 days without documented escalation? Evidence: Validation log with timestamps; gap register with escalation records. 3. Do 100% of Critical-tier workflows carry a full EU AI Act Art. 26 deployer-duty checklist and current DPIA/FRIA evidence in their REM with verifiable evidence (not process-owner assertion alone), and is the per-tier pack overlay enforced at SM intake, with Critical-tier workflows receiving full depth and Low-tier workflows receiving base pack only? Evidence: Critical-tier REM appendices; SM intake routing log showing tier-differentiated processing.

Level 3. 1. Is the AI/HAI Workflow Requirements Pack expressed in a machine-readable schema and monitored via workflow-execution attestation, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier workflows operating with failing REM checks undetected, and the schema published under a permissive license with tracked external adoption? Evidence: Monitoring attestation log; zero-failure operating-workflow record; external adoption tracking. 2. Are ≥70% of REM evidence rows auto-validated via workflow monitoring (ML-Processes), incident feeds (IM-Processes), and SM inventory change events, with automation error-rate monitored and human review reserved for exceptions, novel clauses, and accepted-gap escalations? Evidence: Validation telemetry showing auto-vs-manual split; false-positive and false-negative rate tracking. 3. Does the program contribute at least two substantive artifacts per year (machine-readable requirement schema, REM schema, process requirement clauses) to recognized standards bodies (ISO/IEC 42005, OECD AI, sector standards, NIST AI RMF Playbook), with contributions publicly documented and traceable to adoption? Evidence: Contribution log with public links to accepted or in-progress submissions.

19. Secure Architecture (SA)

Practice Overview

Objective: Publish the reference patterns for safely designing each AI/HAI-embedded workflow archetype the organization operates, so process designers have a vetted green path that already implements SR-Processes requirements and contains the threats identified by TA-Processes.

Description: SA-Processes ships a catalog of reference patterns, one per AI/HAI workflow archetype, showing how to place HITL gates, enforce disclosure, route decisions, log outputs, scope AI tools, and contain workflow failure modes for business processes that embed AI/HAI. Each pattern covers scope, data boundary, oversight design, disclosure mechanism, logging spec, controls mapped to SR requirements, and threats mitigated, tagged to HAI TTPs (EA/AGH/TM/RA) and MITRE ATLAS mitigation IDs. The catalog is accompanied by an anti-pattern list derived from real incidents and first-party post-incident reviews. Process designers use the reference pattern as the starting point; deviations require design review. At L2, patterns cover sector-specific complexity calibrated to SM L2's tier-treatment matrix, include HITL-capacity patterns that auto-throttle decision volume to reviewer capacity, and are encoded as forkable workflow templates (Temporal, Camunda, Argo Workflows) with conformance test suites. At L3, patterns are published as open artifacts contributed to OECD AI, ISO/IEC 42005, MITRE ATLAS, and sector bodies.

Context: Without reference patterns, every team embedding AI in a business workflow makes the same architectural mistakes, HITL gates placed too late to be meaningful, Art. 50 disclosure absent or invisible to users, decision-distribution monitoring never established, override audit trails never wired, back-office AI assistants with unbounded tool scope, content-generation pipelines with no review gate, knowledge bases without provenance. The downstream cost is threat models that discover problems too late, SR requirements that exist on paper with no architectural implementation, and incidents that replay avoidable anti-patterns. SA-Processes makes the secure path the default path, not by blocking process design, but by publishing a pre-vetted pattern for each workflow archetype so teams reach for it first.

Maturity Level 1

Objective: Publish reference architectures per AI/HAI workflow archetype and an anti-pattern catalog derived from real incidents; link each pattern to SR-Processes requirements and TA-Processes threats.

Activities.

A) Publish reference architectures per AI/HAI workflow archetype. Publish one pattern per archetype the org actually operates. Each pattern is concise (target three pages), includes a labeled workflow diagram, and covers a consistent skeleton: scope (what the pattern covers and does not); data boundary (what data classes enter the AI component, what exits, who is affected); oversight design (HITL gate placement, review depth, override authority, fallback when reviewer unavailable); disclosure mechanism (Art. 50 implementation point); logging spec (AI output, decision record, HITL review event, override event, retention meeting the longest applicable regulation); controls mapped row-by-row to SR-Processes requirements; threats mitigated (which TA-Processes archetype threats the pattern addresses, residual threats, HAI TTP tags, ATLAS mitigation IDs). All seven archetype reference patterns ship at L1. The decision pipeline pattern includes an AI scoring layer with documented threshold, a blocking HITL gate for Critical-tier decisions, threshold-change governance, an override audit trail wired at the gate, a decision-distribution monitor with baseline established at launch and alert threshold defined, and an appeal/explanation path for affected persons; threats mitigated include decision-laundering (audit trail + HITL gate), silent-decision-drift (distribution monitor, RA TTP), and adversarial-input-against-decision (ATLAS TA0008 Defense Evasion mitigated by audit trail; TA0043 Impact mitigated by drift alert). The customer-facing flow pattern places a PII redaction layer at the input edge, an output filter and integrity check before customer delivery, Art. 50 disclosure at the point of first AI interaction (not buried in terms), a confidence-threshold escalation to a human agent, a brand-safety filter, prompt/completion logging, and a degraded-mode human-routing fallback; threats mitigated include hallucination reaching customer (output filter), Art. 50 disclosure failure, and prompt injection via customer input propagating to downstream systems (AGH; ATLAS TA0003 Initial Access mitigated by input handling). The HITL chain pattern requires a review UI that surfaces AI rationale and confidence, counterfactuals for Critical and High tier, review SLA enforcement with queue-depth monitoring, reviewer-capacity gating that throttles workflow input rather than auto-approving, reviewer-side prompt-injection defense in the UI, auditable override at every gate, and reviewer calibration cadence; threats mitigated include rubber-stamp HITL (RA), reviewer overload, and reviewer-side prompt injection (AGH; ATLAS TA0008 Defense Evasion mitigated by auditable override and capacity gating). The back-office augmentation pattern requires a scoped AI assistant with a workflow-specific tool list, an output-review gate enforced by workflow design, classification-aware routing with DPO sign-off for regulated data, session-bounded context, and per-session logging tied to workflow instance identifier; threats mitigated include confidential-data egress (TM; ATLAS TA0011 Exfiltration mitigated by classification-aware routing), AI output incorporated without review, and excessive agency (EA mitigated by scoped tool list; TA0007 Privilege Escalation mitigated). The approval/review workflow pattern requires a documented classifier threshold with calibration history, a HITL gate for borderline cases within a confidence band, queue routing by tier, a class-shift monitor on approval/rejection rates per protected-class group, audit trail for all classifications, and threshold-change governance; threats mitigated include AI-screen poisoning (borderline HITL gate + audit trail; ATLAS TA0040 ML Attack Staging), approval-bypass via classifier exploit, and class-shift (RA TTP). The content-generation pattern requires prompt-template versioning in source control, an output-review gate before publication of material outputs, a copyright filter, a brand-voice check, and downstream-system input validation to prevent AGH propagation through generated content; threats mitigated include generated content reaching customers or regulators without review and injection-via-generated-content (AGH; ATLAS TA0004 Execution mitigated by downstream validation). The knowledge-management pattern requires RAG retrieval with per-chunk provenance (source, classification, last-verified date), injection defense separating retrieved content from instructions, per-role retrieval scoping enforced at query time, a freshness SLA, and retrieval logging with user and source identifiers; threats mitigated include RAG-poisoning (provenance + injection defense; ATLAS TA0005 Persistence), retrieval extraction by malicious insiders (TM; TA0010 Collection mitigated by per-role scoping), and misinformation propagation.

B) Publish the anti-pattern catalog. Name, describe, and prohibit AI/HAI workflow design patterns that reliably produce incidents. Each entry includes description, why it is dangerous, real-incident flavor (industry or first-party), and the reference pattern element that replaces it. The L1 set covers: rubber-stamp HITL (reviewer has no AI rationale, no time, approves everything, RA TTP) replaced by HITL chain pattern rationale surfacing and capacity gating; autonomous decisions affecting persons without override path (unmet EU AI Act Art. 14 and GDPR Art. 22) replaced by decision pipeline HITL gate and Art. 22 lawful basis; back-office AI with unbounded tool scope (EA TTP) replaced by scoped tool list; content-generation without review for material outputs replaced by output-review gate; knowledge-base without provenance replaced by RAG-with-provenance and freshness SLA; HITL gate that silently becomes auto-approve on queue overflow replaced by reviewer-capacity gating that throttles input; decision-distribution monitor never established (silent-decision-drift undetectable) replaced by drift monitor with baseline at launch; Art. 50 disclosure buried in terms of service replaced by disclosure at the point of first AI interaction; confidential-data egress via staff copy-paste to consumer GenAI (TM TTP) replaced by sanctioned assistant with classification-aware routing; reviewer-side prompt injection via review-UI display of AI-generated content (AGH TTP) replaced by HITL chain UI injection defense.

C) Integrate patterns into the intake/inventory flow and establish the deviation-review path. SM inventory records link to the applicable reference pattern(s) at intake. Teams choosing an archetype see the reference pattern and declare "using pattern" or "deviating from pattern." Deviations require a lightweight design review (DR-Processes L1) with a named architect reviewer and a documented rationale stored with the workflow's inventory record. Patterns are reviewed and change-logged quarterly; repeat deviations in the same direction signal the need to update the pattern rather than continue approving exceptions. New workflow archetypes that do not fit an existing pattern trigger a pattern-authoring sprint within 30 days of the first intake.

Outcome Metrics (L1).

Success Criteria.

• Seven reference patterns published, one per archetype, each with a labeled workflow diagram, scope declaration, data-boundary definition, oversight design, disclosure mechanism, logging spec, and row-by-row mapping to SR-Processes requirements and TA-Processes threats with HAI TTP tags and applicable MITRE ATLAS mitigation IDs.
• Anti-pattern catalog published with at least 8 entries, linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Processes training.
• Deviation-review path operational with a named architect-reviewer population and ≤5 business day SLA.
• ≥85% of active AI/HAI-embedded workflows in the SM inventory classified as "on pattern" or "deviation with review"; no silent deviations.
• 100% of customer-facing AI workflows with Art. 50 disclosure at the point of first AI interaction, confirmed by IR spot-check, not only policy declaration.

Maturity Level 2

Objective: Extend reference patterns to multi-region and sector-specific complexity calibrated to SM L2's tier-treatment matrix; add HITL-capacity patterns that auto-throttle decision volume to reviewer capacity; encode patterns as forkable workflow templates with conformance test suites; update the anti-pattern catalog from IM-Processes incidents.

Activities.

A) Tier-conditional pattern extensions. Publish extended pattern variants calibrated to SM-Processes L2's tier-treatment matrix. The Critical-tier overlay adds a class-shift monitor with per-protected-class segmentation, a DPIA/FRIA evidence hook, EU/sector data-residency variants with cross-region data-flow legal basis under GDPR Art. 44–49, kill-switch design with a defined halt SLA that suspends AI output and routes pending items to human queue, and EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern. The High-tier overlay includes HITL-capacity monitoring modules pre-wired (queue-depth signal, reviewer-per-volume ratio signal, SLA-approaching-breach alert, auto-throttle trigger wired to the workflow orchestrator) and standard ML-Processes L2 detections pre-wired. Sector-specific overlays include employment-decision (EEOC bias-audit schedule, NYC LL 144 third-party auditor integration, FCRA adverse-action notice generation), credit/insurance (FCRA adverse-action, CO SB-21-169 insurance constraints), clinical-decision (FDA SaMD documentation hook, clinical-escalation path for low-confidence output), and financial-advisory (FINRA model-risk evidence, SEC suitability documentation). The multi-region pattern covers decision-data residency enforcement, region pinning, cross-region transfer legal basis selection, and GDPR Art. 44–49 mechanism selection as a required decision gate. The HITL-capacity auto-throttle pattern wires queue-cap logic into the workflow orchestrator: when queue depth exceeds the defined cap, new items are held in a staging queue rather than routed to auto-approve; staging queue items have a maximum hold time after which they escalate to a senior reviewer or workflow owner.

B) Patterns-as-IaC for code-defined workflows. For workflows defined in code-based orchestrators (Temporal, Camunda, Argo Workflows, or equivalent), encode all Critical and High-tier pattern variants as forkable workflow definition templates so teams fork rather than handcraft; deviations surface at definition-review or CI time. Each workflow template ships with a conformance test suite: automated checks that the deployed workflow matches the pattern's controls (HITL gate present for required tier, override audit trail wired, disclosure mechanism present for customer-facing flows, queue-cap logic present for HITL chain patterns, scoped tool list declared for back-office augmentation, class-shift monitor present for Critical-tier decision pipelines). Templates are version-pinned; template updates trigger a drift-detection pass against all deployed workflow instances. A template change log is maintained; workflow owners consuming a template are notified of updates requiring remediation.

C) Incident-informed anti-pattern catalog refresh. Every IM-Processes incident is classified to an anti-pattern (existing or new); classification is recorded in the IM finding. The catalog is refreshed monthly from IM-Processes findings; new anti-patterns are surfaced to teams at intake time rather than stored only in a reference document. Quarterly review: if three or more workflows have deviated from a pattern in the same direction, the pattern is queued for update rather than continued exception approval. Anti-patterns originating from Critical-tier incidents are escalated to the SM working group for a pattern-update sprint within 30 days.

Outcome Metrics (L2).

Success Criteria.

• Five or more tier-conditional extended patterns published (Critical overlay, High overlay, sector-specific overlays, multi-region, HITL-capacity auto-throttle), each encoded as a forkable workflow template with a conformance test suite.
• ≥80% of Critical and High-tier AI/HAI-embedded workflows running on template-encoded patterns with drift-detection.
• Anti-pattern catalog updated from ≥3 real IM-Processes incidents in the last 12 months; new entries surfaced at intake time.
• Conformance test coverage at 100% of template-encoded workflow deployments.
• 100% of Critical-tier workflows with EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern documentation.

Maturity Level 3

Objective: Publish reference patterns as open industry artifacts; contribute process-level architecture patterns to OECD AI, ISO/IEC 42005, and MITRE ATLAS; engage regulators on AI workflow architecture norms.

Activities.

A) Publish reference patterns as open artifacts. Publish patterns under Apache 2.0 or equivalent via OECD AI, ISO/IEC 42005 community guidance, OWASP AI chapter, CSA AI Safety Initiative, or sector bodies (FS-ISAC, H-ISAC, sector AI working groups). Maintain the public repository as the upstream source; internal use aligns with the external version; internal deviations are documented with rationale and fed back as upstream proposed changes rather than silent forks. Track pattern adoption telemetry: forks, citations in published work, documented adopters. New archetypes or overlays developed internally are proposed for inclusion in the external catalog within 90 days of internal publication.

B) Contribute to MITRE ATLAS, ISO/IEC 42005, and OECD AI. For each control in the reference patterns that corresponds to a threat technique in the ATLAS taxonomy, propose or validate a mitigation entry in the ATLAS mitigation library (AML.M00xx): HITL-capacity gating as a mitigation for TA0043 Impact (availability of oversight), decision-distribution monitoring as a mitigation for TA0043 (silent-decision-drift), injection-defense in review UI as a mitigation for TA0004 Execution, per-role retrieval scoping as a mitigation for TA0010 Collection. Contribute to ISO/IEC 42005 AIMS community guidance on human oversight design patterns and decision-logging requirements for AI-embedded workflows. Contribute to OECD AI Principles working groups on process-level human oversight and transparency patterns; submit decision-pipeline and HITL-chain patterns as concrete examples of Art. 14 and Art. 50 implementation. Sector-specific: engage CFPB, EEOC, FDA, and FINRA with sector-relevant pattern variants. Target at least two contributions per year accepted to ATLAS or ISO/IEC 42005 community guidance, traceable to specific SA-Processes pattern controls.

C) Engage regulators on workflow architecture norms. Active participation in EU AI Act implementing-act consultations where architecture standards for high-risk AI workflow systems (Annex III use cases) are under discussion; submit SA-Processes patterns as evidence of "state of the art" practice under Art. 9. Engage NIST AI RMF Playbook successor editions with SA-Processes pattern mappings to GOVERN, MAP, MEASURE, and MANAGE, focusing on the HITL-chain and decision-pipeline patterns as concrete GOVERN-level implementations. Maintain a regulatory engagement calendar with active items, target timelines, and evidence of substantive participation.

Outcome Metrics (L3).

Success Criteria.

• ≥5 reference patterns published as open artifacts under a recognized open license via at least one industry or sector body.
• ≥2 patterns externally cited or forked by recognized industry or sector bodies.
• ≥2 contributions accepted to MITRE ATLAS mitigation library or ISO/IEC 42005 community guidance, traceable to SA-Processes pattern controls.
• Internal practice 100% aligned to the published external version; all deviations proposed as upstream contributions, none silently forked.
• At least one documented regulatory or standards-body reference to SA-Processes patterns in implementing-act, guidance, or standards text.

Common Pitfalls

Level 1. - Patterns are written but not linked from the SM inventory record or the intake gate, teams skip them because they are hard to find, not because they disagree with them. - The HITL chain pattern omits the reviewer-capacity gating, the most consequential control is the most commonly missing; auto-approve on overflow is the failure mode the pattern was designed to prevent. - Anti-patterns remain theoretical; they are not tied to real incidents or to the specific pattern element that replaces them, designers do not recognize the hazard when they encounter it. - Decision pipeline pattern includes a distribution monitor but the baseline is never established at launch, the monitor exists but has nothing to measure against; silent-decision-drift is undetectable.

Level 2. - Workflow templates are forked once and then hand-edited at each deployment, drift is immediate and the template substrate provides no baseline enforcement; conformance tests are skipped because they block the fastest path to production. - HITL-capacity auto-throttle is documented in the tier-conditional pattern but the workflow orchestrator does not implement the queue cap, the throttle exists on paper; queue overflow silently falls through to auto-approve. - Sector-specific overlays exist in documents but the workflow templates do not enforce the sector-specific controls, the FCRA adverse-action notice step is in the pattern diagram but not in the Temporal/Camunda workflow definition. - Tier-conditional patterns cover the Critical overlay in documentation but the conformance test suite does not test for class-shift monitor presence, the Critical-tier requirement is not enforced at deployment.

Level 3. - Externally contributed patterns diverge from internal practice, what is published reflects what the org once designed; external adopters discover the discrepancy during implementation and trust erodes. - ATLAS/ISO contribution targets are treated as a compliance checkbox, entries are proposed but never followed through to publication because internal legal or security review creates indefinite delay. - Regulatory engagement is declaratory ("we participated in the consultation") rather than substantive ("our pattern text was incorporated into the guidance"), the program cannot demonstrate that engagement produced outcomes. - Industry contributions are conference presentations and blog posts; no technical artifacts actually land in ATLAS, ISO, OECD, or sector standards, external recognition is aspirational.

Practice Maturity Questions

Level 1. 1. Are seven reference patterns published, one per archetype (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), each with a labeled workflow diagram, oversight design, disclosure mechanism, logging spec, and explicit row-by-row mapping to SR-Processes requirements and TA-Processes threats with HAI TTP tags and applicable MITRE ATLAS mitigation IDs, accessible within one click of the SM inventory record? Evidence: Pattern catalog with seven versioned documents; SM inventory record containing direct links. 2. Are 100% of customer-facing AI workflows verified (via IR spot-check, not only policy declaration) to place Art. 50 disclosure at the point of first AI interaction, and is the anti-pattern catalog linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Processes training, with each entry tied to the real-incident pattern that generated it? Evidence: IR spot-check results; anti-pattern catalog linked from AUP, intake gate, and EG training curriculum. 3. Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA ownership, and are ≥85% of active AI/HAI-embedded workflows in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations? Evidence: Pattern metadata showing on-pattern or deviation-with-review status; deviation aggregation report from the last quarter.

Level 2. 1. Are the tier-conditional extended patterns (Critical overlay, High overlay, sector-specific overlays, multi-region, HITL-capacity auto-throttle) published as forkable workflow templates with conformance test suites, and are ≥80% of Critical and High-tier AI/HAI-embedded workflows running on template-encoded patterns as confirmed by the workflow and SM inventory registries? Evidence: Template repository with five variant directories; conformance test run history; SM inventory showing tier-to-pattern alignment. 2. Has the anti-pattern catalog been updated from ≥3 real IM-Processes incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and does conformance testing cover 100% of template-encoded workflow deployments with findings tracked to resolution? Evidence: Anti-pattern change log with IM incident references; intake gate showing current anti-pattern catalog version; CI/workflow conformance test coverage report. 3. Are 100% of Critical-tier workflows carrying explicit EU AI Act Art. 9 and Art. 15 control mappings in the pattern documentation, and does the HITL-capacity auto-throttle pattern enforce queue capping in the workflow orchestrator definition (not only in policy), verified by conformance test? Evidence: Critical-tier pattern documents with Art. 9/Art. 15 mapping sections; orchestrator definition with queue-cap logic; conformance test results.

Level 3. 1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry or sector body, and have ≥2 been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version? Evidence: External repository with license file; citation or fork count; internal-vs-external pattern diff audit with no unexplained deviations. 2. Have ≥2 contributions been accepted to the MITRE ATLAS mitigation library or ISO/IEC 42005 community guidance, traceable to specific SA-Processes pattern controls, and is there an active contribution cadence (at least one contribution or validation per 6 months)? Evidence: Contribution log with PR or submission references; meeting records from ATLAS or ISO/IEC 42005 community engagement. 3. Is there at least one documented reference to SA-Processes patterns in a regulatory implementing-act, sector guidance document, or published standards text, and is the regulatory engagement calendar maintained with active items, target timelines, and evidence of substantive participation? Evidence: Regulatory engagement log with document references and citation extracts; engagement calendar with active items.

20. Design Review (DR)

Practice Overview

Objective: Operate the design checkpoint between intake approval and build-out for every new AI-embedded business workflow the organization operates, confirming the proposed workflow design follows the applicable SA-Processes reference pattern, covers the SR-Processes requirements pack, satisfies applicable compliance obligations, and documents residual risks before the workflow goes live to affected persons.

Description: DR-Processes is the single moment where workflow architecture (SA-Processes), requirements (SR-Processes), and threats (TA-Processes) meet a specific planned AI-embedded business workflow, decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, or knowledge-management workflow. The review runs before the workflow begins processing real affected persons, catching design flaws when correction costs hours, not months of production rollback. A two-lane model routes Low / Medium-tier workflows to an async fast-lane (target ≤2 business days) and High / Critical-tier, Annex III, Art. 22, or sector-regulated workflows to a full-lane architect review (target ≤5 business days) with Privacy and Legal participation. Every review produces a written decision (approve / approve-with-conditions / send-back) stored against the SM-Processes inventory record. Loop-back signals ensure the review process improves SA-Processes patterns and SR-Processes packs over time rather than accumulating silent governance debt.

Context: Without a design checkpoint, AI-embedded business workflows go live without verified HITL gates, without Art. 50 disclosure UX designed, without decision logging scoped, without appeal or contestation paths surfaced. The SA reference pattern and SR requirements pack exist, but delivery teams skip them under pressure, deviate without recording rationale, or simply launch before the archetype pattern is consulted. DR-Processes enforces the handoff between "design approved" and "workflow goes live," making deviations visible and deliberate. EU AI Act Art. 9 risk management requires documented pre-deployment decisions for high-risk AI systems; Art. 14 requires human-oversight design for high-risk systems; Art. 22 GDPR requires safeguards for solely-automated decisions with legal or similarly significant effect; the DR decision record is the documented pre-deployment decision that FRIA and DPIA evidence references. Cross-domain handoff is explicit: when a workflow embeds AI features built in-house, the AI features receive DR-Software; the workflow orchestrating those features receives DR-Processes.

Maturity Level 1

Objective: Run a per-archetype design checkpoint for every new AI-embedded workflow before go-live, producing a written decision traceable to the SA-Processes pattern, SR-Processes requirements pack, and TA-Processes threat snapshot.

Activities.

A) Publish the per-archetype AI-Embedded Workflow Design Checklist. One checklist per SM-Processes archetype, derived from the applicable SA-Processes reference pattern and keyed to the SR-Processes base pack and archetype delta. The seven checklists share a common spine, pattern adherence (using the SA-Processes reference pattern or documented deviation with rationale), HITL placement and depth (Art. 14 human-oversight gate placement declared with reviewer role, trigger condition, timeout, and fallback; reviewer-capacity model confirming the declared SLA is arithmetically achievable without rubber-stamping), Art. 50 disclosure design (disclosure UX present on every AI-touched customer interaction where applicable), decision logging (which decisions are logged, at what field granularity, with what retention period; traceability to affected person confirmed), override audit trail (every human override captured with reviewer identity, rationale, and timestamp), output-integrity SLA (acceptable error rate, staleness window, and degraded-mode behavior declared), affected-persons rights surface (the channel through which an affected person can contest an AI-assisted outcome is identified and tested in design), DPIA / FRIA status (DPIA triggered if personal data processed at scale under GDPR Art. 35; FRIA required if workflow qualifies as Annex III high-risk AI), and fallback / kill-switch (documented manual-process path for AI component outage; kill-switch design specified and test plan defined), plus archetype-specific additions. The decision pipeline checklist adds Annex III screen completion, Art. 22 lawful basis documentation, appeal and explanation path design, and class-shift monitoring baseline. The customer-facing flow checklist adds Art. 50 disclosure UX visible on every AI-touched interaction, brand-safety filter placement, and escalation path to human agent with SLA. The HITL chain checklist adds review-UI design that surfaces AI rationale, confidence level, and at least one counterfactual to the reviewer (not only the recommendation), and injection-defense confirmation that the review UI does not execute embedded content. The back-office augmentation checklist adds tool-scope bounding, classification-aware routing, and output-review gate design. The approval/review workflow checklist adds class-shift monitor design and explicit tier-routing logic. The content-generation checklist adds copyright and brand-voice filter placement, output-review gate for material outputs, and downstream-input-validation. The knowledge-management checklist adds provenance requirements on every retrieved chunk, classification-aware retrieval, injection-defense scope, and role-based retrieval access.

B) Triage and route reviews by risk tier and deviation status. The two-lane model is driven by the SM-Processes tier assignment and the deviation flag. Fast-lane (Low / Medium tier, on-pattern, no Annex III, no Art. 22, no sector-regulated): async checklist review, target SLA ≤2 business days; output is one structured decision record, approve / approve-with-conditions (explicit list) / send-back (reasons stated), stored against the SM-Processes inventory record. Full-lane (High / Critical tier, or Annex III trigger, or Art. 22 solely-automated-decision risk, or sector-regulated, or any pattern deviation): architect review with Privacy and Legal walking the SA-Processes reference pattern section-by-section with the business owner, target SLA ≤5 business days; output is a written decision record with the residual-risk list reviewed by a named architect, plus Privacy and Legal sign-off recorded for Art. 22 and Annex III workflows. Before SM-Processes L2 tiers are established, decision pipelines and customer-facing flows processing personal data default to full-lane; all others default to fast-lane with override available on reviewer judgment. Every decision record carries: decision, checklist completed with evidence pointers, deviations listed with rationale, residual risks with named owner and expiry, reviewer name and date, Privacy and Legal acknowledgment for Art. 22 / Annex III workflows, and links to the SM-Processes inventory record, TA threat snapshot, SR REM, and FRIA / DPIA status.

C) Close the loop with SA-Processes, SR-Processes, and IM-Processes. Design review is a learning surface for the program. Three deviations in the same direction for the same archetype auto-queue a pattern-update review with SA-Processes ownership, recurring deviations signal the pattern is miscalibrated, not that delivery teams are wrong. An SR requirement repeatedly waived with a compensating control auto-queues an SR pack-revision review; if every decision-pipeline team waives the same base requirement, the pack needs recalibration. Every IM-Processes incident re-examines the DR decision record that approved the affected workflow: was the issue visible at design time, and which checklist item would have caught it? The answer updates the checklist and feeds the next archetype review cycle.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype AI-Embedded Workflow Design Checklists published, versioned, and traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot, all seven archetypes covered.
• Two-lane review model operational with published SLAs (≤2 BD fast-lane, ≤5 BD full-lane) and named lead reviewers per archetype trained on EG-Processes L1; Privacy and Legal participation confirmed for full-lane reviews.
• ≥95% of AI-embedded workflows going live in the last 90 days carry a completed DR decision record; 100% of Annex III / Art. 22 workflows include FRIA / DPIA status with named owner.
• SA pattern-update and SR pack-update triggers wired; every IM-Processes incident re-examines the DR record that approved the affected workflow.

Maturity Level 2

Objective: Upgrade Critical-tier reviews to scenario-based walkthroughs driven by TA-Processes per-workflow deep threat models, conduct FRIA workshops for Annex III workflows, detect design drift for High and Critical workflows on a published cadence, and coordinate joint DR-Processes / DR-Software reviews for Critical-tier workflows wrapping first-party AI features.

Activities.

A) Scenario-based reviews for Critical and High-tier workflows. For every Critical-tier workflow, the full-lane checklist walkthrough is replaced by a scenario walkthrough. The reviewer sources 3–5 specific threat or compliance scenarios from the TA-Processes per-workflow deep threat model, from anonymized IM-Processes incidents of the same archetype, and from applicable regulatory scenarios (Annex III high-risk category, Art. 22 automated-decision challenge, Art. 50 disclosure failure, sector-specific). Scenarios must be specific to this workflow's HITL placement, data classes, affected-person population, and AI component, not generic archetype scenarios. Each scenario is walked as: "If this workflow produces an incorrect AI recommendation and the reviewer rubber-stamps it, what is the outcome for the affected person? Which design control prevents or detects this?" The DR decision record maps each scenario to a design control or an accepted residual risk with a named owner and expiry. Scenario sources include the TA-Processes per-workflow deep threat model, anonymized IM-Processes incidents from the same archetype, MITRE ATLAS technique candidates relevant to the AI components in the workflow (EA / AGH / TM / RA as applicable), and OWASP LLM / Agentic Top 10 entries relevant to the embedded AI feature's archetype. For High-tier workflows, the standard full-lane review is augmented with at least one scenario from the TA archetype library.

B) FRIA workshops for Annex III workflows and cross-domain joint reviews. For any workflow that clears the Annex III screen, the DR-Processes full-lane review is replaced or extended with a structured Fundamental Rights Impact Assessment workshop. Workshop attendees: named architect, Privacy, Legal, business owner, and a representative of the affected-person population (or their proxy) where feasible. Workshop agenda walks (1) affected-person populations and impacts, (2) fundamental rights at stake (Art. 22 right to explanation, Art. 8 data protection, Art. 47 right to an effective remedy, sector-specific rights), (3) likelihood and severity of rights impact across the workflow's decision paths, (4) mitigations designed or confirmed, and (5) residual rights exposure documented with named owner and review cadence. Workshop output is the completed FRIA artifact linked from the DR decision record; FRIA status is updated in the SM-Processes inventory and fed back to TA-Processes and SR-Processes. Cross-domain joint reviews: when a Critical-tier workflow wraps a first-party AI feature (an approval workflow calling an internally built scoring model, a customer-facing flow surfacing an internally built LLM output), DR-Processes coordinates a joint session with DR-Software. The handoff boundary, which controls are the workflow's responsibility vs. the AI feature's responsibility, is explicitly documented in both DR records; residual risks spanning both are noted with shared ownership and a single named resolution owner; where the AI feature has no DR-Software record, DR-Processes flags the gap and holds the workflow's Sanctioned status until DR-Software completes.

C) Design-drift detection. The live production workflow is compared against its approved DR design at a published cadence. Critical-tier: quarterly drift check, examining workflow-tool config repos (Camunda / Temporal / Argo / ServiceNow BPM model versions), product-flow analytics (where the AI step actually fires compared to the approved design), HITL queue configuration (reviewer routing, timeout settings, escalation rules), override-audit-log schema (fields captured vs. fields declared in the DR), and Art. 50 disclosure presence in the deployed UI (screenshot audit vs. approved disclosure design). High-tier: annual drift check using the same sources. Material drift, HITL gate removed or bypassed, AI component swapped, new affected-person population added, Art. 50 disclosure removed, decision-logging scope reduced, class-shift monitor disabled, automatically re-opens the DR record and routes back through the appropriate lane. Each drift check produces a written artifact: the diff between approved design and live workflow, each delta classified as material or non-material, with material deltas tracked to DR re-review or accepted residual.

Outcome Metrics (L2).

Success Criteria.

• 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs with the decision tied to how the design handles each scenario.
• 100% of Annex III workflows with a completed FRIA workshop before go-live; FRIA artifacts linked from DR records.
• Design-drift detection operating quarterly for Critical and annually for High; 100% of material drifts re-routed to DR.
• Joint DR-Processes / DR-Software review records on file for 100% of Critical-tier workflows wrapping first-party AI features.
• IR-stage design surprises measurably fewer than at L1 over consecutive quarters.

Maturity Level 3

Objective: Operate continuous design attestation from workflow-execution telemetry, automate drift-triggered DR exception tickets, and contribute review rubrics, FRIA workshop frameworks, and scenario templates to OECD AI, ISO/IEC 42005, and sector standards bodies.

Activities.

A) Continuous design attestation via workflow-execution telemetry. Critical-tier workflows produce a daily attestation signal covering HITL gate health (HITL queue telemetry confirms reviewer SLA is met, override-rationale field populated at the declared rate, queue throughput within capacity), decision-logging completeness (decision-logging pipeline confirms required fields are flowing at expected volume, stale or silent logs open a finding), Art. 50 disclosure presence (product-flow analytics confirm the disclosure element fires on every AI-touched interaction across all traffic slices, A/B-test variant drift alerts if disclosure disappears from a slice), override audit freshness (override-audit log confirms entries are being written with required fields at the rate implied by HITL queue throughput, silence or schema drift opens a finding), and fallback / kill-switch readiness (synthetic test of the fallback or kill-switch path runs on the published cadence). Deviations automatically open a DR-exception ticket in IM-Processes, triaged within 3 business days. Attestation artifacts are machine-readable and regulator-consumable, EU AI Act Art. 9 risk-management evidence, Art. 14 human-oversight evidence, Art. 26 deployer-duty documentation, and ISO/IEC 42001 AIMS operational records are produced by the attestation pipeline without manual assembly. Human reviewers handle exceptions, novel workflow designs that do not fit existing attestation rules, and escalations from the IM-Processes backlog.

B) Contribute review rubrics and scenario templates to industry. Publish under Apache 2.0 or equivalent through OECD AI Policy Observatory, ISO/IEC 42005 working groups, applicable sector bodies (financial-services AI supervisory guidance, healthcare AI governance bodies), or OWASP SAMM AI extensions: per-archetype AI-Embedded Workflow Design Review Rubrics (tier-assignment criteria, checklist items with evidence pointers, scenario-selection guidance, FRIA trigger indicators), FRIA workshop frameworks (agenda template, rights-impact mapping tool, mitigation-design guide, residual-exposure documentation format), scenario template libraries (scenario format, per-archetype examples including Art. 22 challenge scenarios, debrief rubric for reviewer calibration), and a pattern-evolution framework (how external signals, OECD AI guidance, ISO/IEC 42005 updates, sector regulatory guidance, IM-Processes incidents, feed DR checklist and scenario updates on a quarterly cadence). Internal rubrics and templates remain aligned to the published external versions; internal deviations are proposed as upstream changes, not silently forked.

C) Pattern evolution driven by external and internal signals. A quarterly pattern-evolution review combines external signals (OECD AI guidance on high-risk AI systems and HITL requirements; ISO/IEC 42005 AI impact assessment standard updates; sector regulatory AI guidance; Annex III expansion or amendment updates) with internal signals (IM-Processes incident patterns by archetype, ML-Processes telemetry anomalies, ST-Processes red-team and canary findings) to produce structured checklist and scenario library updates. Updates are change-logged with signal provenance; downstream DR records for in-flight reviews are notified of pattern changes affecting their archetype. Where a new regulatory update or IM incident reveals a checklist gap, the gap is propagated to SA-Processes and SR-Processes to maintain the full traceability chain from threat or compliance obligation to requirement to design review.

Outcome Metrics (L3).

Success Criteria.

• Daily attestation operating for ≥90% of Critical-tier workflows; DR-exception tickets opened on deviation and triaged within 3 business days.
• ≥2 externally contributed review artifacts per year, per-archetype rubrics, FRIA workshop frameworks, or scenario templates, with documented adoption.
• Review backlog for non-exception work inside ≤7 days; attestation has absorbed the routine review volume.
• Quarterly pattern-evolution cadence traceable to external (OECD AI, ISO/IEC 42005, sector guidance, Annex III updates) and internal (IM-Processes, ML-Processes, ST-Processes) signals with a versioned change log.

Common Pitfalls

Level 1. - Design review runs after the workflow has already gone live, the checkpoint loses leverage because affected persons have already received AI-assisted decisions; the review becomes a retrospective audit, not a gate. - HITL gate is declared in the checklist but reviewer capacity is never modeled, the declared SLA is arithmetically impossible and reviewers rubber-stamp every AI recommendation to keep up with volume. - Annex III screen is skipped because "this doesn't feel like high-risk AI", a decision pipeline affecting employment, credit, or education goes live without a FRIA; regulatory exposure is undocumented. - Approve-with-conditions is issued but conditions (HITL gate, override audit trail, contestation path) have no named owner and no expiry date, conditions sit unresolved at go-live.

Level 2. - "Scenario-based" review is the same checklist read aloud in a meeting, the scenario-to-design-control mapping is never performed; no one asks "what happens to the affected person if the AI recommendation is wrong and the reviewer doesn't catch it?" - FRIA workshop is a template filled in by the Legal team without the business owner or affected-person proxy, rights impacts are theorized rather than grounded in the specific workflow; mitigations are generic. - Design-drift detection runs on a schedule but findings dead-end in a spreadsheet, no DR-exception ticket is opened; the approved design remains fiction while the live workflow has diverged. - Joint DR-Processes / DR-Software reviews never happen because the coordination channel with DR-Software was never established, the handoff boundary between the workflow and the embedded AI feature is undocumented.

Level 3. - Attestation signals show green across all Critical workflows but underlying checks cover only decision-logging volume, HITL gate health, override-rationale completion, and Art. 50 disclosure presence by traffic slice are not checked; attestation is cosmetic. - Externally published rubrics diverge from internal practice, the published FRIA framework reflects how the org assessed workflows 18 months ago; peer adopters find inconsistencies when comparing the framework to actual DR records. - Exception queue overwhelms reviewers because attestation thresholds are too sensitive, every reviewer-queue fluctuation opens a DR-exception ticket; reviewers suppress the signal source rather than tune the sensitivity threshold. - Industry contributions are conference talks and blog posts describing the program, no technical artifacts (rubrics, FRIA frameworks, scenario templates) land in OECD AI / ISO/IEC 42005 / sector bodies with documented adoption.

Practice Maturity Questions

Level 1. 1. Is there a published, versioned per-archetype AI-Embedded Workflow Design Checklist for all seven archetypes, each covering the common spine (HITL placement and depth, Art. 50 disclosure design, decision logging, override audit trail, output-integrity SLA, reviewer-capacity gating, affected-persons rights surface, DPIA / FRIA status, fallback / kill-switch) plus archetype-specific items, and traceable to the applicable SA pattern, SR requirements pack, and TA threat snapshot? Evidence: Checklist documents per archetype with version history; traceability matrix linking each item to an SA pattern control and SR requirement; archetype-specific checklist sections signed off by the named lead reviewer. 2. Do ≥95% of AI-embedded workflows going live in the last 90 days carry a completed DR decision record, with two-lane routing (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Processes L1, Privacy and Legal participation on full-lane reviews, and 100% of Annex III / Art. 22 workflows including FRIA / DPIA status with a named owner? Evidence: SM-Processes inventory query showing last-90-days go-live entries with DR decision record IDs linked; review SLA telemetry report; sample of 5 decision records showing residual-risk and FRIA / DPIA sections populated. 3. Are recurring pattern deviations and repeatedly-waived SR requirements automatically queuing SA pattern-update and SR pack-update reviews, and does every IM-Processes incident trigger a re-examination of the DR record that approved the affected workflow? Evidence: SA pattern-update queue entries with triggering deviation counts; SR pack-update tickets linked to waiver patterns; IM incident post-mortems with a DR-record re-examination section completed.

Level 2. 1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat or compliance scenarios sourced from TA-Processes per-workflow deep models and anonymized IM-Processes incidents, with the DR decision tied explicitly to how the proposed workflow design handles each scenario rather than checklist conformance alone? Evidence: Critical-tier DR decision records from the last 90 days, each showing a scenario-to-design-control mapping table and a decision statement tied to scenario outcomes. 2. Do 100% of Annex III workflows receive a completed FRIA workshop before go-live, with the workshop output linked from the DR decision record and the SM-Processes inventory, and is design-drift detection running quarterly for Critical-tier and annually for High-tier with 100% of material drifts re-routed to DR? Evidence: Annex III register cross-referenced to FRIA workshop artifacts; drift-detection run log with cadence dates; material-drift classification report showing re-routed workflows. 3. Are joint DR-Processes / DR-Software review records on file for 100% of Critical-tier workflows wrapping first-party AI features, with an explicit handoff boundary and shared residual-risk ownership documented in both DR records? Evidence: Cross-reference report of Critical-tier workflows wrapping first-party AI features; matching DR-Processes and DR-Software decision records; handoff-boundary section in each record.

Level 3. 1. Are ≥90% of Critical-tier AI-embedded workflows producing a daily attestation signal, covering HITL gate health, decision-logging completeness, Art. 50 disclosure presence, override-audit freshness, and fallback readiness, with deviations auto-opening DR-exception tickets triaged within 3 business days? Evidence: Attestation telemetry dashboard showing daily signal per Critical workflow across all five dimensions; DR-exception ticket queue with open/triage timestamps; sample attestation artifact in machine-readable format. 2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, FRIA workshop frameworks, scenario templates) to OECD AI, ISO/IEC 42005, or applicable sector bodies, with documented adoption and internal practice aligned to the published versions? Evidence: Contribution log with external publication links and adoption indicators; comparison document showing internal checklist aligned to the published version. 3. Is there a quarterly pattern-evolution review driven by external signals (OECD AI guidance, ISO/IEC 42005 updates, sector regulatory guidance, Annex III changes) and internal signals (IM-Processes incidents, ML-Processes telemetry, ST-Processes findings), with a versioned change log and notification to in-flight DR reviews affected by pattern changes? Evidence: Quarterly pattern-evolution review minutes with signal-source citations; versioned checklist change log; in-flight DR review notification records for the most recent pattern update.

21. Implementation Review (IR)

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 the affected-persons rights surface is responsive.

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). The common spine covers HITL gates actually present and substantive (test with a synthetic trigger event and confirm the gate blocks progression; pull HITL queue logs and confirm median review time is within the declared SLA; confirm 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 (product-flow analytics 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), decision logging actually capturing required fields (pull a decision-log sample and confirm all required fields are present 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 within the declared SLA), affected-persons rights surface actually responsive (submit a synthetic contestation request and confirm it is received, acknowledged, and routed to the correct review queue within the declared SLA), and fallback / kill-switch actually testable (execute the fallback path or kill-switch test and record the result). The decision pipeline checklist adds Annex III registration status confirmation, Art. 22 lawful-basis currency, appeal/explanation path testing, and class-shift monitor wired-and-producing-signal verification. The customer-facing flow checklist adds Art. 50 presence via product-flow analytics on sampled traffic slices, brand-safety filter test, and escalation-path end-to-end test. The HITL chain checklist adds review-UI screenshot audit against approved UI design, reviewer-capacity model re-run against current staffing and volume, and injection-defense session-log check. The back-office augmentation checklist confirms tool-scope bounded in deployed configuration, classification-aware routing active, and output-review gate wired and logging. The approval/review checklist pulls class-shift monitor data and verifies tier-routing logic against DR-approved logic. The content-generation checklist tests the copyright and brand-voice filter, confirms the output-review gate is receiving expected volume, and runs downstream-input-validation tests. The knowledge-management checklist confirms provenance labels in retrieval samples, classification-aware retrieval against cross-classification test inputs, and injection-defense in the deployed prompt structure.

B) Perform reviews at the right moments. Three triggers at L1. Go-live: 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: every active AI-embedded workflow reviewed at least annually, scheduled from the SM-Processes inventory with a last-IR-date field linked to a review-due alert. Material-change: 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 include workflow-tool config repos (BPM model versions and workflow-step configuration diffs since the last IR), HITL queue logs (reviewer-throughput and override-rationale completion rate), override-audit logs (schema and entry-rate completeness), product-flow analytics (where the AI step actually fires vs. approved design), and decision-distribution snapshots (current decision rate vs. the DR-approved baseline).

C) Track findings to closure. Every review produces zero or more findings. Each finding carries a severity (Critical, HITL gate absent or trivially bypassed on a High/Critical workflow; Art. 50 disclosure absent on a customer-facing flow; decision log not capturing required fields for an Annex III workflow, / High / Medium / Low), a named owner (the workflow owner or team, not "the business team"), an SLA (Critical blocker resolved before go-live or rollback required; High ≤7 days; Medium ≤30 days; Low ≤90 days or accepted residual), and an after-fix evidence artifact linked to the finding before closure. Findings feed IM-Processes as issues for tracking and aging 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).

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 HITL substantiveness and affected-persons rights-response timing recurrently; calibrate IR cadence per SM-Processes tier.

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 and material deviations open an IR finding automatically. HITL-throughput monitoring: HITL queue telemetry monitored for reviewer SLA miss (median review time exceeds the declared SLA for the archetype and tier, alert within 24 hours), queue saturation (queue depth exceeds the capacity declared in the reviewer-capacity model, alert when queue depth implies SLA miss within 4 hours), and 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 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 is absent or fires below 100% opens an IR finding within 24 hours. Affected-persons rights-response monitoring: DSAR-equivalent timing for contestation requests measured monthly for Critical-tier; median response time compared against the declared contestation-path SLA. Detection latency targets: Critical-tier ≤7 days from change event to finding opened; High-tier ≤30 days.

B) Recurrent probe of HITL substantiveness and affected-persons rights-response path. HITL substantiveness and the affected-persons rights-response path are probed recurrently rather than trusted from process documentation. HITL substantiveness probe (monthly for Critical, quarterly for High): a stratified random sample audit of HITL queue decisions checks reviewer decision time (unusually short decisions below a declared minimum meaningful review time are flagged as possible rubber-stamps), override-rationale quality (rationale entries that are empty, boilerplate, or below the declared minimum character count are flagged), and 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). Thresholds are calibrated to archetype and tier by the SR-Processes pack. Affected-persons rights-response probe (monthly for Critical, quarterly for High): a synthetic contestation request is submitted on the same cadence; 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.

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 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).

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: Operate 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 per-archetype operational baseline schemas to ISO/IEC 42005 and sector AI governance bodies.

Activities.

A) Daily attestation signal for Critical-tier workflows. Each Critical-tier AI-embedded workflow produces a daily composite attestation signal across four dimensions. HITL gate health: HITL-queue telemetry confirms reviewer SLA is met, override-rationale completion is at or above declared minimum, and queue depth is below saturation threshold; anomalies open a finding automatically. Decision-logging completeness: the 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. 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. Override-audit freshness: the 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. 14 human-oversight 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 working groups (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), and 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. The 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).

Success Criteria.

• Daily attestation operating for ≥90% of Critical-tier workflows 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; 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.

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 and the approved design diverges silently from the running workflow. - 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. - Affected-persons rights-response path is documented in the process map but never tested, the IR checklist has a "contestation path: designed" box checked without submitting a synthetic request and measuring response time.

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 disappears from 20% of traffic for weeks before IR detects it.

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 while 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, 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? Evidence: Checklist documents per archetype with version history; sample IR record showing the common-spine items completed with evidence artifacts attached. 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? Evidence: SM inventory query showing go-live entries with linked IR records; findings backlog report showing closure times and aging; material-change event log cross-referenced to IR records. 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? Evidence: IM-Processes query for IR-originated issues showing severity, owner, and SLA; REM row update log linked to IR findings.

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? Evidence: Drift-detection pipeline configuration; telemetry report showing per-Critical-workflow drift signals; IM-Processes findings auto-created from drift events. 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? Evidence: HITL substantiveness audit reports per Critical/High workflow for the last period; synthetic contestation request log with timing; escalations to program sponsor for non-substantive HITL detection. 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? Evidence: IR coverage matrix per Critical/High workflow showing current-period probe completion; tier-cadence adherence report; Critical-tier findings backlog showing SLA adherence.

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? Evidence: Attestation telemetry dashboard per Critical workflow; IM-Processes ticket creation timestamps showing ≤1-hour latency from attestation deviation; Art. 50 violation log. 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? Evidence: External publication links for the schemas; adoption indicators from ISO/IEC 42005 or sector bodies; reviewer time-tracking report showing QoQ trend. 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? Evidence: Post-incident review template showing the IR-record re-examination section; attestation rule change log linked to incident IDs.

22. Security Testing (ST)

Practice Overview

Objective: Prove that every AI-embedded business workflow behaves correctly under adversarial and failure conditions, by running a foundational per-archetype test battery, maintaining versioned regression corpora, and escalating to scheduled red-team exercises and continuous adversarial testing at higher maturity levels.

Description: ST-Processes exercises the AI-embedded business workflows the organization operates, decision pipelines, customer-facing flows, HITL chains, back-office augmentation workflows, approval and review workflows, content-generation workflows, and knowledge-management workflows, against a battery of workflow-specific test classes tied directly to the threats in the TA-Processes library and the requirements in the SR-Processes pack. At L1, every archetype has a published test battery (decision-bypass tests, Art. 50 disclosure-presence tests, rubber-stamp detection, RAG-poisoning probes, class-shift monitoring accuracy tests, downstream-input-validation tests, HITL-bypass tests, workflow-injection tests, approval-chain bypass tests, autonomous-action boundary tests, content-review gate tests) plus six versioned regression corpora (adversarial-decision, rubber-stamp-detection, content-generation-safety, RAG-poisoning, Art. 50 disclosure-presence, class-shift detection) running in CI where the workflow has programmatic interfaces. L2 adds per-tier red-team exercises per archetype using TA L2 per-workflow deep threat models and cross-archetype composition tests. L3 operates continuous automated adversarial testing on production workflows via controlled canary inputs and contributes findings to MITRE ATLAS (process-level techniques), sector ISACs, and OECD AI.

Context: Classic workflow QA exercises the happy path and leaves the adversarial path untested. A decision pipeline passes all functional tests and then produces systematically biased outcomes for a protected-characteristic group that was never tested. An approval workflow passes UAT and then routes every edge-case to auto-approve when the HITL queue is saturated. A customer-facing flow passes staging tests and then silently removes the Art. 50 disclosure in a UI A/B test. A RAG-powered knowledge-management workflow passes integration tests and then returns confidential documents to users without classification-checking. These failures are invisible to classic QA because classic QA was not designed to enumerate AI-specific failure modes, decision laundering, rubber-stamp accumulation, disclosure bypass, retrieval poisoning (ATLAS TA0003), and downstream injection. ST-Processes closes this gap by making AI-workflow-specific tests a first-class citizen and connecting them directly to the TA threat library so test coverage tracks threat coverage, not only functional coverage.

Maturity Level 1

Objective: Establish a foundational per-archetype test battery and versioned regression corpora that run in CI where applicable, and verify that every AI-embedded workflow reaches production with a passed go-live battery on record.

Activities.

A) Publish the foundational per-archetype test battery. One test battery per AI-embedded workflow archetype targeting the top archetype threats from TA-Processes and the archetype-specific SR requirements. L1 target: ≤8 named test classes per archetype. Each test class specifies inputs, expected output, pass/fail criteria, an evidence artifact (queue-log sample, decision-log entry, screenshot, CI run link), and the TA threat and SR requirement it maps to. The decision pipeline battery covers a decision-bypass test (exercise the override path end-to-end and verify the override is logged with required fields, ATLAS TA0008 Defense Evasion analog, EA), decision-laundering detection (pull a sample of decisions and confirm each entry carries AI recommendation, human decision if HITL, reviewer identity, override flag, affected-person reference, and timestamp), silent-decision-drift test (inject synthetic inputs previously classified one way and confirm the classification has not silently shifted beyond the declared drift threshold), adversarial-input test (craft inputs designed to push a borderline decision into the opposite class, ATLAS TA0012 ML Attack Staging analog), and class-shift monitor accuracy test (inject a synthetic protected-characteristic distribution shift and confirm the class-shift monitor fires within the declared detection window). The customer-facing flow battery covers Art. 50 disclosure presence test (instrument a session that exercises the full AI-touched interaction path; confirm the disclosure fires on every interaction across A/B variants), brand-safety filter test, and escalation-path test (synthetic customer escalation acknowledged within SLA). The HITL chain battery covers rubber-stamp detection (stratified random sample of HITL decisions, minimum 50 per test cycle; if the human decision matches the AI recommendation at ≥98% across the sample, flag as a potential rubber-stamp and escalate to the program sponsor, the primary failure mode for HITL chains; EA through process design), reviewer-overload test (inject a burst of synthetic workflow items that saturates reviewer capacity and verify the queue triggers the saturation alert and routes overflow to the declared fallback path rather than auto-approving), and reviewer-side injection test (seed a workflow item with HTML, script tags, or prompt-injection patterns and confirm the review UI renders the content as inert, ATLAS TA0003 Initial Access analog applied to the human-review interface, AGH). The back-office augmentation battery covers tool-scope test (out-of-scope request rejected and logged, EA / TM), classification-gating test (sensitive-classification marker triggers output-review gate), and output-review-gate wiring verification. The approval/review battery covers class-shift test on synthetic protected-class samples (approval rates do not differ beyond declared variance, EA through systemic bias), threshold-drift test (current threshold compared against the DR-approved baseline), and queue-routing-by-tier test. The content-generation battery covers copyright filter test, brand-voice check test, and downstream-input-validation test (generated content containing injection syntax rejected or sanitized by the downstream system, ATLAS TA0003, AGH / TM). The knowledge-management battery covers RAG-poisoning probe (seed the retrieval corpus with adversarial instructions and confirm the workflow does not follow them, ATLAS TA0003, AGH), retrieval-extraction probe (attempt to extract classified content via crafted query), role-based-retrieval test (queries with two different access roles respect the role boundary), and provenance-required test (every returned chunk carries source, classification, and trust label).

B) Build and maintain regression corpora. Six versioned regression corpora, each a collection of structured test fixtures (input, expected safe output pattern, threat tag with HAI TTP and ATLAS tactic ID where applicable, SR requirement, source, date added). The adversarial-decision corpus carries synthetic decision inputs designed to flip decisions via boundary probing or protected-characteristic proxies; run against decision-pipeline and approval-workflow archetypes. The rubber-stamp-detection corpus carries synthetic HITL decision batches where all items recommend the same AI output and baselines expected human decision variance. The content-generation-safety corpus carries generation prompts designed to produce copyright violations, brand-safety failures, or downstream-injection payloads. The RAG-poisoning corpus carries adversarial documents and crafted queries designed to redirect workflow purpose or extract cross-classification content. The Art. 50 disclosure-presence corpus carries UI interaction sequences designed to exercise edge cases where disclosure might be suppressed (first session, A/B variant, escalation path, mobile interface). The class-shift detection corpus carries synthetic input batches with controlled protected-characteristic proxy distribution shifts. Corpora are versioned in source control; corpus refresh cadence is monthly minimum from internal observations (IR findings, IM incidents), external sources (regulatory guidance, academic adversarial-ML research, ATLAS technique examples), and red-team exercises. CI is budget-capped for computational tests. New workflow intake triggers a corpus-completeness check against the archetype's declared threat coverage.

C) Operate the go-live battery and wire test failures to IM-Processes. Every AI-embedded workflow must pass its archetype battery before receiving Sanctioned status in the SM-Processes inventory. Go-live triggers: pre-go-live (all applicable archetype tests must pass before the workflow begins processing real affected persons; the go-live test record is linked from the SM-Processes inventory and the PC intake artifact); post-AI-component-update (any AI component swap, model-version change, or underlying AI service change triggers a re-run of the full archetype battery within 14 days, Critical-tier within 7 days); post-incident (any IM-Processes incident involving the workflow triggers a re-run of the relevant battery subset before the incident is closed); quarterly (all active AI-embedded workflows re-run their battery, results reviewed by the named test-battery owner). All test failures route to IM-Processes within one business day with a severity tag. Named battery owner per archetype is a named role, not a shared-team responsibility.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype foundational test battery published for all seven archetypes, linked from the SM-Processes inventory record and the DR/IR artifacts.
• Six regression corpora published in source control with named corpus owners and a monthly refresh cadence.
• 100% of AI-embedded workflows reaching production in the last 90 days have a passed go-live battery on record.
• All test failures routed to IM-Processes with a 1-day handoff SLA and named owner.
• TA-Processes archetype threat coverage ≥80%.

Maturity Level 2

Objective: Calibrate test depth per risk tier using the SM-Processes L2 tier-treatment matrix, run per-tier red-team exercises using TA-Processes L2 per-workflow deep threat models, and test cross-archetype compositions for Critical-tier workflows.

Activities.

A) Tier-calibrated test battery and corpus depth. Publish a per-tier test treatment aligned to SM-Processes L2's tier-treatment matrix. Critical tier: full archetype battery at go-live with executive sign-off on results; all six corpora running on every CI cycle with the Critical corpus separately tuned; AI-component-update re-run of the full battery within 7 days; class-shift detection verified quarterly with findings routed to IM within 1 BD; rubber-stamp detection audit run monthly with the ≥98% match-rate escalation threshold. High tier: full archetype battery; all six corpora on merge; AI-component-update re-run within 14 days; class-shift detection verified semi-annually; rubber-stamp detection audit quarterly. Medium tier: subset battery (top-4 threat classes); adversarial-decision and disclosure-presence corpora on merge; AI-component-update subset re-run within 30 days; class-shift detection annually; rubber-stamp detection annually. Low tier: spot-check (3 test classes) at go-live; disclosure-presence corpus; decision-distribution regression at next quarterly; class-shift detection at go-live; rubber-stamp detection at go-live.

B) Scheduled per-tier red-team exercises using TA L2 threat models. Red-team cadence by tier: Critical (quarterly, 4 per year, scope derived from TA-Processes L2 per-workflow deep threat model, covering adversarial-decision inputs, rubber-stamp induction via queue saturation, disclosure-bypass techniques, RAG-poisoning paths, class-shift induction, downstream injection via generated content, HITL-saturation attacks, approval-chain bypass, and autonomous-action boundary breaches); High (semi-annual, 2 per year, scope from TA-Processes L2 workflow deltas covering the top-5 threats from the per-workflow model); Medium / Low (ad-hoc before major AI-component changes or scope expansions, archetype snapshot driving scope). Each exercise follows the AI Security Testing Methodology: written rules of engagement, test plan reviewed with workflow owner, execution log, structured findings report (severity / root cause / SR requirement traced / HAI TTP tagged). Cross-archetype composition tests for Critical-tier: decision pipeline plus customer-facing flow composition (adversarial decision input produces a biased recommendation surfaced to the customer with the Art. 50 disclosure absent; test that the disclosure and the override path both fire correctly for the composed output), back-office augmentation plus content-generation output reaching customer-facing flow (back-office content generation produces output containing injection syntax; test that the customer-facing flow's input-validation layer sanitizes it before customer display), and knowledge-management plus decision pipeline (RAG-poisoned document injects into the decision pipeline's context window and shifts the decision; test that the decision pipeline's HITL gate catches the anomalous recommendation and logs the event).

C) Red-team findings to corpus pipeline. Every Critical or High-severity red-team finding produces a new corpus entry (input, expected safe output, threat tag, SR requirement, date, source reference) committed to the relevant regression corpus within 30 days, an IM-Processes finding with severity tag and the named workflow owner as assignee, and a TA-Processes library-gap ticket if the finding was not in the archetype library, tracked with a named owner and a 30-day close SLA for Critical-tier gaps. This pipeline ensures every quarterly red-team exercise produces durable regression coverage for the findings it surfaces.

Outcome Metrics (L2).

Success Criteria.

• Quarterly red-team for 100% of Critical-tier workflows; semi-annual for 100% of High-tier; scope tied to TA-Processes L2 per-workflow deep threat models.
• Critical-tier regression corpora (all six) running for all Critical-tier workflows; per-tier calibration enforced.
• ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days.
• Cross-archetype composition tests documented and run for all Critical-tier composite workflows.
• Per-tier SLA adherence for testing activities ≥90%.

Maturity Level 3

Objective: Operate continuous automated adversarial testing on production workflows via canary inputs, publish workflow-level test patterns and regression corpora, and contribute process-level attack techniques to MITRE ATLAS, sector ISACs, and OECD AI.

Activities.

A) Continuous automated adversarial testing via canary inputs. Deploy a canary-input framework that injects synthetic adversarial workflow items into production traffic at a controlled rate (≤1% of total workflow volume, clearly flagged in decision logs as synthetic canary items so they do not affect affected persons and are excluded from regulatory reporting). Adversarial-decision canaries: synthetic decision inputs near classification boundaries injected into decision pipelines and approval workflows; verify the class-shift monitor and HITL gate respond correctly (ATLAS TA0012 ML Attack Staging analog). Rubber-stamp-induction canaries: synthetic HITL items with a known "wrong" AI recommendation injected into HITL chains and approval workflows; verify that human reviewers do not simply match the AI recommendation for a statistically significant sample (≥5% override rate on canaries injected with wrong recommendations expected; below 2% override rate flags potential rubber-stamping and triggers an IM-Processes finding). Disclosure-bypass canaries: synthetic UI interaction sessions instrumented to detect whether the Art. 50 disclosure element fires correctly across A/B test variants, mobile breakpoints, and escalation paths. RAG-poisoning canaries: synthetic documents containing adversarial instructions injected into the retrieval corpus at a controlled rate; verify the knowledge-management workflow does not follow adversarial instructions and that the poisoned document is flagged (ATLAS TA0003 Initial Access, retrieval path, AGH). Canary findings are triaged by a named ST owner at least weekly. New process-level TTPs (patterns not in the TA-Processes library) are fed into the TA L3 auto-proposal pipeline within 14 days. High-severity canary findings route to IM-Processes within 24 hours.

B) Contribute findings to industry. Contribute anonymized, legally-vetted process-level findings to MITRE ATLAS (process-level attack technique observations, novel decision-laundering patterns, rubber-stamp induction via queue saturation, disclosure-bypass via A/B test manipulation, RAG-poisoning targeting workflow purpose, following ATLAS evidence-and-provenance requirements; target ≥2 contributions per year), sector ISACs (AI-embedded workflow security advisories relevant to the org's sector, financial-services AI decision-making, healthcare AI workflow governance, public-sector AI decision pipelines; target ≥2 substantive advisory contributions per year), and OECD AI Policy Observatory (real-world telemetry evidence on Art. 22 and Art. 50 operational compliance patterns during policy revision cycles).

C) Publish workflow-level regression corpora and test patterns as open artifacts. Publish anonymized versions of the six regression corpora under an open license, scrubbed of org-specific workflow names, data classes, and decision thresholds. The internal corpora are a superset of the published versions; updates that belong upstream are proposed as contributions, not silently retained. Host or co-host at least one industry workflow-security benchmark per year (OWASP AI chapter, ATLAS practitioner table, or sector ISAC AI working group); collect cross-org adversarial-workflow detection data from participants.

Outcome Metrics (L3).

Success Criteria.

• ≥80% of Critical-tier AI-embedded workflows under continuous canary-input testing with daily probe execution; novel process-level TTPs triaged into the TA-Processes library within 14 days; high-severity canary findings routed to IM-Processes within 24 hours.
• ≥4 industry contributions per year to MITRE ATLAS (process-level), sector ISACs, or OECD AI.
• ≥6 open regression corpora published under a permissive license and maintained upstream.
• ≥1 industry-shared exercise hosted per year plus ≥2 participated; cross-org adversarial-workflow detection data documented.

Common Pitfalls

Level 1. - Test battery reduced to a logging-completeness check and a UI screenshot, no behavioral adversarial probes (decision-bypass, rubber-stamp detection, RAG-poisoning, downstream injection) are actually exercised. - Regression corpora committed to source control but not wired into CI, they exist but run only when a reviewer manually triggers them; coverage erodes after every sprint. - Go-live battery runs once pre-production but is never re-run after AI-component updates, test coverage erodes as AI models change and decision thresholds drift. - Rubber-stamp detection test is absent from the HITL chain battery because "we trust our reviewers", systematic rubber-stamping accumulates without detection.

Level 2. - Red-team scope defined as "prompt-injection probes" on the AI feature but the workflow-level failure modes (rubber-stamp induction via queue saturation, disclosure bypass via A/B test manipulation, class-shift induction via adversarial input distribution, approval-chain bypass) are excluded, the top process-level threat classes go untested. - Per-tier calibration documented in the tier-treatment matrix but the test runner applies the same battery to all tiers, Critical and Low-tier workflows run the same tests; differentiation exists on paper only. - Red-team findings route to IM-Processes but the finding-to-corpus pipeline is never executed, 12 months of Critical/High findings sit in IM as closed tickets with no corpus entries; the same vulnerabilities are re-discovered at the next red-team exercise. - Cross-archetype composition tests scoped but not executed because "no team owns the end-to-end composition", composition-specific failure modes are in the threat model but not in any test.

Level 3. - Canary inputs run against the workflow's test environment rather than production traffic, canary results reflect test-environment behavior; production-specific configurations (A/B test variants, traffic-slice-specific disclosure suppression) are never exercised. - Industry contributions are process descriptions and blog posts rather than actionable, reproducible technique descriptions, ATLAS reviewers cannot map them to a technique ID; contributions lack the reproducibility notes needed for external validation. - Open corpora published once and then not maintained, external organizations build on a stale version while the internal corpus has new entries from recent red-team exercises; discrepancies surface at community exercises. - Hosted industry exercise becomes a capabilities showcase rather than an adversarial-workflow detection-benchmarking session, no measurable improvement data is collected from participants; the "≥1 hosted per year" metric is met without producing cross-org security uplift.

Practice Maturity Questions

Level 1. 1. Is a per-archetype foundational test battery published for all seven AI-embedded workflow archetypes, with each test class tied to a TA-Processes archetype threat (HAI TTP plus ATLAS tactic ID where applicable) and an SR-Processes requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact, and are 100% of new AI-embedded workflows required to pass the battery before production Sanctioned status is issued? Evidence: Published battery documents per archetype with TA-threat and SR-requirement traceability table; SM-Processes inventory showing Sanctioned entries with a passed go-live battery record linked; sample test run with evidence artifact attached. 2. Are six regression corpora (adversarial-decision, rubber-stamp-detection, content-generation-safety, RAG-poisoning, Art. 50 disclosure-presence, class-shift detection) versioned in source control with named corpus owners, a monthly refresh cadence from internal and external sources, and budget-capped CI runs, and are Critical/High-tier workflows verified to have run and passed the applicable corpus before go-live? Evidence: Source-control repository showing six corpus directories with version history and corpus owners in CODEOWNERS; CI telemetry report showing corpus run results for the last 30 days; monthly corpus refresh commit log. 3. Are all test failures routed to IM-Processes within 1 business day with a severity tag and named owner, and does TA-Processes archetype threat coverage by the test battery and corpus reach ≥80% by end of year one? Evidence: IM-Processes query for ST-originated issues with creation timestamps within 24 hours of test failure; threat-coverage matrix mapping TA archetype threats to battery test classes and corpus entries showing ≥80% coverage ratio.

Level 2. 1. Are 100% of Critical-tier AI-embedded workflows red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Processes L2 per-workflow deep threat models, covering adversarial-decision inputs, rubber-stamp induction, disclosure-bypass techniques, RAG-poisoning paths, class-shift induction, downstream injection via generated content, HITL-saturation attacks, and approval-chain bypass, with findings routed to IM-Processes and remediation tracked? Evidence: ST records showing red-team exercise dates per Critical and High-tier workflow for the last 12 months; red-team report for the most recent Critical-tier exercise showing scope sourced from the TA L2 per-workflow model; IM-Processes findings linked from the report. 2. Is per-tier corpus calibration enforced (Critical-tier: all six corpora plus monthly rubber-stamp detection audit and quarterly class-shift verification; Low-tier: disclosure-presence corpus), and are ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days? Evidence: CI pipeline configuration showing per-tier corpus routing; rubber-stamp audit log per Critical workflow for the current period; finding-to-corpus pipeline telemetry showing conversion rate and lead times. 3. Are cross-archetype composition tests (decision pipeline plus customer-facing flow, back-office content generation plus downstream injection surface, knowledge-management plus decision pipeline) documented and executed for all Critical-tier composite workflows, and is per-tier SLA adherence for testing activities ≥90%? Evidence: Composition test plans per Critical-tier composite workflow; execution logs with pass/fail results; per-tier SLA adherence report from program telemetry for the last two quarters.

Level 3. 1. Are ≥80% of Critical-tier AI-embedded workflows under continuous canary-input testing with daily probe execution, covering adversarial-decision, rubber-stamp-induction, disclosure-bypass, and RAG-poisoning canaries, with novel process-level TTPs triaged into the TA-Processes library within 14 days and high-severity canary findings routed to IM-Processes within 24 hours? Evidence: ST canary telemetry showing daily probe execution per Critical workflow; canary-to-TA-library pipeline log with lead time per novel TTP; IM-Processes high-severity finding creation timestamps within 24 hours of canary detection. 2. Has the program contributed ≥4 anonymized, legally-vetted process-level findings per year to MITRE ATLAS (process-level), sector ISACs, or OECD AI, with at least one accepted as a new or refined technique or advisory, and are ≥6 open regression corpora published under a permissive license and maintained upstream? Evidence: Contribution log with external submission links and acceptance confirmation; open-source repository links for the six published corpora with commit history showing active maintenance; legal review records for each submission. 3. Has the program hosted at least 1 industry-shared adversarial-workflow exercise per year and participated in ≥2 additional cross-org exercises, with documented cross-org adversarial-workflow detection data from participants? Evidence: Exercise log with hosted and participated entries for the last 12 months; post-exercise report showing detection data collected from participants; testimonials or co-published results from at least one cross-org partner.

23. Environment Hardening (EH)

Practice Overview

Objective: Harden the workflow operational envelope, the controls around how a business workflow embedding AI/HAI executes, who can change it, and what data flows through it, so each AI/HAI-embedded workflow runs within a least-privilege, observable, and auditable boundary and unsanctioned workflow modifications or shadow-AI insertions are detectable before they affect outputs.

Description: EH-Processes tunes the organization's existing identity, change-management, DLP, BPM-tooling-admin, and audit controls for the specific surfaces that AI/HAI-embedded business workflows create. Five envelope dimensions are in scope: the workflow-definition envelope (signed workflow definitions in Camunda, Temporal, Argo, or equivalent BPM/orchestration tooling; version control and peer review for workflow changes; promote-to-production gate requiring DR re-review for material changes; rollback playbook); the HITL envelope (SSO + MFA on review UIs, reviewer rotation and load balancing, reviewer-capacity monitoring with SLA-at-risk alerts, override-authority enforcement blocking auto-override); the disclosure envelope (EU AI Act Art. 50 disclosure UX templates centrally managed and version-controlled, A/B-test results monitored to prevent disclosure suppression, affected-persons-rights-surface SLA monitoring); the data-flow envelope (classification-aware routing through workflow steps, PII redaction at workflow ingress where required, per-tenant workflow isolation for customer-facing flows); and the audit envelope (immutable decision logs, tamper-evident override audit trail, reviewer-action logging, affected-persons-rights-response logging, retention meeting the longest applicable regulation). Decision-threshold guardrails, autonomous-action rate-limits and circuit breakers, and content-generation output filters are baseline controls for the decision-pipeline, approval/review, autonomous-action, and content-generation archetypes.

Context: Business workflows adopt AI features incrementally and often without coordinated security review. An approval workflow gains an AI-scoring step added directly to a production BPMN definition by a developer with no change-management gate. A customer-facing chatbot workflow is updated by a product team to suppress a disclosure screen because conversion rates improved in an A/B test. A HITL review step accumulates queue depth until reviewers rubber-stamp every item to clear the backlog, the review becomes a compliance-theater control with no protective value. A back-office augmentation workflow routes confidential HR data through an AI step cleared only for public-classification content. EH-Processes closes these gaps not by adding new tooling but by applying governance the organization already has, change management, IAM, DLP, BPM admin controls, to the specific operational surfaces that the seven AI/HAI process archetypes create. The HAI TTPs EA, AGH, TM, and RA are mitigated here at the workflow envelope level: EA via least-privilege workflow service accounts and HITL gate runtime enforcement; AGH via classification-aware routing and disclosure governance that resists covert workflow modifications; TM via approval-chain authentication, decision-threshold guardrails, and autonomous-action rate-limits; RA via circuit breakers, kill-switch wiring on autonomous workflow steps, and tamper-resistant audit trails.

Maturity Level 1

Objective: Harden the workflow-definition, HITL, disclosure, data-flow, and audit envelopes for every AI/HAI-embedded business workflow in the SM-Processes inventory so each workflow runs within a governed perimeter and unsanctioned modifications or AI insertions are observable.

Activities.

A) Harden the workflow-definition and audit envelopes. Every AI/HAI-embedded workflow registered in the SM-Processes inventory, decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow, is stored in version control (Git or the BPM platform's native versioning) with signed commits or equivalent integrity attestation; the runtime BPM engine loads only definitions whose signature is verified at deploy time and unsigned definitions are rejected at the deploy gate. Any change to a workflow definition that adds, removes, or modifies an AI step requires peer review (at minimum one reviewer other than the author) before merge, and a change-log entry is produced for every workflow-definition version promoted to production. A material change, defined as any change that alters the AI step's model, threshold, HITL configuration, data-routing rule, or disclosure placement, triggers a DR-Processes re-review before the new definition is promoted; immaterial changes use a fast-lane review checklist. Each workflow in the inventory has a documented rollback playbook specifying the last-known-good definition version, the rollback trigger criteria, the named role authorized to invoke rollback, and the maximum rollback time target (≤1 hour for Critical-tier workflows, ≤4 hours for High-tier); rollback playbooks are tested at least annually. Decision logs for every AI/HAI output that affects a business outcome are written to write-once or append-only storage; application-tier service accounts cannot delete or overwrite decision-log records. Whenever a HITL reviewer overrides an AI recommendation, the override event is logged with reviewer identity resolved from SSO, override direction, mandatory rationale for Critical/High-tier workflows, timestamp, and decision context; the audit trail uses an append-only log with hash chain or equivalent tamper-evident mechanism.

B) Harden the HITL and override-authority envelopes. All HITL review interfaces, BPM task lists, review queues, decision-approval UIs, require SSO/SAML/OIDC with MFA; local-account access to review UIs is disabled for org-domain identities and shared review accounts are a blocking finding. Each review-queue action is associated with the reviewer's authenticated identity from the SSO session; anonymous or pseudonymous reviewer actions are blocking findings for Critical and High-tier workflows. For Critical and High-tier decision pipelines and approval workflows, reviewer rotation policy is documented and enforced; no single reviewer handles more than a defined maximum proportion of items in any rolling seven-day window, to prevent fatigue-driven rubber-stamping; load-balancing configuration is part of the workflow definition and version-controlled. A reviewer-capacity monitor tracks queue depth and estimated SLA-breach time for every HITL-gated step; when projected SLA-breach time falls below a configurable threshold (e.g., ≤4 hours for Critical-tier) a named escalation alert fires to the workflow owner and IM-Processes backlog; no automated queue-clearing or SLA-override is permitted without human escalation acknowledgement. Override authority is defined per workflow and per step; only reviewers in the authorized override role can override an AI recommendation; bulk-override and auto-override actions are blocked at the review-UI layer and detected as anomalous by ML-Processes.

C) Harden the disclosure and data-flow envelopes. All customer-facing UI templates surfacing EU AI Act Art. 50 disclosures are managed in a central template registry; product teams consume templates from the registry and no product team can modify or suppress a disclosure template without a governed update process (change request, Privacy/Legal review, registry version bump); the registry is version-controlled and deployed template versions are auditable. Any workflow A/B test that tests a variant with a disclosure component must be registered with Privacy/Legal before launch; A/B traffic splits involving disclosure variants are logged and a metric alert fires if the disclosure-present variant's traffic share falls below the policy-defined minimum. For workflows subject to GDPR Art. 22, the contestation response SLA is monitored per workflow; a named escalation alert fires when the SLA is at risk and response-completion events are logged in the audit trail. At workflow ingress, each data payload is classified (or inherits its classification label from the upstream system of origin); a routing policy enforced by the BPM engine or an inline classification gateway ensures that data classified Confidential or higher, including regulated PII, is routed only to AI steps cleared for that data class per SR-Processes requirements; routing decisions are logged as classification-routing events in the workflow audit log. For customer-facing flows and decision pipelines where regulated PII enters from an external source, a PII redaction or tokenization layer is applied at workflow ingress before the data reaches any AI step; workflows that pass raw regulated PII to AI steps without Privacy/Legal sign-off are blocking findings. For customer-facing flows serving multiple tenants, workflow execution contexts are isolated per tenant; one tenant's input data, AI-step context, and decision outputs are not accessible to another tenant's workflow execution, and isolation is verified in ST-Processes isolation tests.

Outcome Metrics (L1).

Success Criteria.

• 100% of AI/HAI-embedded workflows in production running against a signed, version-controlled workflow definition; peer-review enforced for all AI-step changes; DR re-review gate enforced for material changes.
• 100% of HITL review UIs require SSO + MFA; reviewer-capacity monitoring active for all Critical/High-tier HITL steps; SLA-at-risk alerts tested and functioning.
• Art. 50 disclosure templates managed exclusively through the central registry; no unregistered disclosure templates deployed; disclosure-suppression detection active.
• Classification-aware routing enforced at workflow ingress for all workflows processing regulated PII; PII redaction layer active where required; per-tenant isolation enforced for customer-facing flows.
• Immutable decision logs and tamper-evident override audit trails active for all Critical/High-tier workflows; retention meets the longest applicable regulation.

Maturity Level 2

Objective: Calibrate hardening depth per SM-Processes L2 risk tier, Critical-tier workflows receive dedicated reviewer pools, JIT access for workflow-definition changes, tamper-evident log integrity verification, and per-execution disclosure-completeness monitoring; Low-tier workflows stay on baseline L1 controls.

Activities.

A) Tier-conditional hardening calibration. Publish and enforce a hardening tier-treatment matrix aligned to the SM-Processes L2 risk-tier rubric. Critical: JIT, time-limited (≤4-hour), approval-gated workflow-definition change access with full change log; dedicated reviewer pool with rotation policy and load monitoring; named-individual override authority with mandatory rationale and tamper-evident log; write-once decision log storage with scheduled integrity verification and per-workflow partitioning; per-execution disclosure-completeness metric with SLA-at-risk alert and mandatory A/B-test registry; classification-routing enforced at the BPM engine layer with routing-anomaly alerts to IM; per-tenant isolation enforced at runtime through context isolation and key separation for multi-tenant decision outputs. High: peer-review and change-log requirements; shared reviewer pool with rotation policy; named-individual override with required rationale; append-only decision log with access-control separation; template-registry enforcement with quarterly version audit; ingress-gateway classification routing; application-layer per-tenant isolation. Medium: peer-review and change-log; shared reviewer pool baseline; named-individual override; append-only decision log; template-registry enforcement; ingress-gateway classification routing; application-layer isolation. Low: change-log only baseline; baseline reviewer pool; baseline named-individual override; append-only decision log baseline; template-registry enforcement; ingress-gateway classification routing baseline; application-layer isolation baseline. Each workflow record in the SM-Processes inventory carries its tier's hardening status; gaps between required and actual controls become open IM-Processes findings.

B) JIT access for workflow changes and dedicated reviewer pools. For Critical-tier workflows replace standing developer write access to BPM definitions with JIT access grants, scoped to the specific workflow definition, time-limited to ≤4 hours, approval-gated by the workflow owner or security lead, and fully logged; access revocation is automatic at grant expiry and the change log records the JIT access grant ID alongside every definition version produced under it. For Critical-tier decision pipelines, HITL collaboration chains, and approval workflows, designate a reviewer pool assigned exclusively to Critical-tier items; pool membership is documented in the workflow definition and version-controlled; pool capacity is continuously monitored and cross-tier queue bleed, Critical items reviewed by a reviewer not in the designated pool, is a compliance finding; pool-size reviews occur when the SM-Processes tier-treatment matrix changes or when capacity utilization consistently exceeds 80%. For Critical-tier workflows, override authority is limited to named individuals in a defined role (not a team or functional group); override events without a completed rationale field are automatically escalated to the workflow owner within one hour; repeated overrides without rationale by the same reviewer trigger a reviewer-pool audit.

C) Log-integrity verification, per-execution disclosure monitoring, and per-tenant runtime isolation. Decision logs and override audit trails for Critical-tier workflows are stored in a write-once backend (object storage with Object Lock, WORM-capable log management platform, or equivalent); a scheduled integrity verification job runs at least weekly, verifying the log chain hash for each Critical-tier workflow's decision log; any hash mismatch or detected log gap is an immediate IM-Processes finding, and the last successful verification timestamp is a compliance-evidence artifact reviewed in IR-Processes. For Critical-tier customer-facing flows, instrument the workflow execution engine to emit a disclosure-completion event for each execution, disclosure step reached (yes/no), template version rendered, timestamp, execution-id, and aggregate into a per-workflow disclosure-completion rate; a rate below 100% for any rolling 24-hour window triggers an IM-Processes finding, and the metric is part of the compliance evidence bundle for Art. 50. For Critical-tier workflows subject to GDPR Art. 22, the contestation-response handling path is formalized, named Privacy/Legal owner, response SLA documented in the workflow configuration, escalation alert at 75% of SLA elapsed, and responses are logged with decision outcome and reviewer identity in the tamper-evident audit trail. Multi-tenant Critical-tier customer-facing flows enforce tenant boundaries at the runtime layer, with isolation verified by IR-Processes implementation review and ST-Processes isolation tests.

Outcome Metrics (L2).

Success Criteria.

• 100% of Critical-tier workflow-definition changes executed under JIT access with approval gate; no standing write access for Critical-tier definitions.
• Dedicated reviewer pools operational for all Critical-tier HITL steps; pool capacity monitored; SLA-at-risk alerts functioning; cross-tier queue bleed zero; rubber-stamp rate trending down.
• Critical-tier decision-log integrity verification running weekly on schedule; 100% of Critical-tier workflows; zero unresolved integrity failures.
• Per-execution disclosure completion metric active for all Critical-tier customer-facing flows; 100% completion rate maintained; any deviation routes to IM-Processes within 4 hours.
• Tier-hardening matrix published and enforced at provisioning; per-tenant runtime isolation confirmed by IR review and ST isolation test on Critical-tier multi-tenant flows.

Maturity Level 3

Objective: Express all EH-Processes controls as IaC; drive adaptive policy tightening from ML-Processes detections and IM-Processes incidents; auto-provision tier-appropriate hardening for new workflows within 24 hours of SM-Processes registration; contribute AI/HAI workflow hardening baselines to OECD AI, ISO/IEC 42005, CSA AI Safety Initiative, and sector ISACs.

Activities.

A) Hardening-as-code. Express every EH-Processes control as a version-controlled, parameterized IaC module: a workflow-definition integrity module (BPM-as-code templates encoding the signing policy, peer-review gate configuration, and DR-re-review gate rule for each archetype, parameterized by archetype and tier, consumed by the BPM platform's CI/CD pipeline); a HITL configuration module (reviewer-pool membership declaration, capacity-monitoring thresholds, load-balancing rules, and SLA-at-risk alert configuration as code, with reviewer-pool changes version-controlled and requiring code review); a disclosure-template registry module (template IDs, version history, permitted deployment targets, A/B-test registration requirements encoded as IaC, with deployed inventory reconciled against the registry on a scheduled basis); a classification-routing module (classification-aware routing rules, PII-redaction ingress configuration, and data-class-to-AI-step clearance mapping expressed as policy-as-code); a JIT access module (JIT access policy for Critical-tier workflow-definition changes, scope, time limit, approver roles, automatic revocation, expressed as IAM policy-as-code); a log-integrity module (write-once storage configuration, integrity-verification schedule, hash-chain parameters, and alert thresholds for log-gap detection); and a per-tenant isolation module (tenant-context isolation enforcement rules expressed as runtime policy-as-code, with isolation tests in the module's test suite). IaC modules are version-pinned; updates notify consuming workflow teams with a required-remediation flag. A drift-detection pipeline runs on a scheduled cadence against all deployed workflow configurations; low-risk findings (configuration noise) are auto-remediated; high-risk drift, JIT policy removed, disclosure template suppressed, log integrity disabled, triggers a human-review alert within 2 business days and opens an IM-Processes finding.

B) Adaptive policy tightening from ML and IM signals. Wire ML-Processes detection signals and IM-Processes incident patterns to a human-approved adaptive-tightening pipeline. Rubber-stamp HITL detection (reviewer-matches-AI rate ≥98% on a Critical-tier workflow) triggers a dedicated-reviewer-pool audit proposal and capacity-increase trigger; disclosure-suppression detection (per-execution completion rate falling below threshold) triggers a per-execution alerting threshold tightening proposal; shadow-AI-in-process detection (new AI step in a workflow definition not in inventory) triggers a JIT access tightening proposal and an SM-Processes inventory intake alert. From the IM side, post-incident reviews identifying a workflow hardening gap generate an IaC module update proposal; Critical-tier workflow incidents involving a HITL failure generate a reviewer-pool structure review proposal; incidents involving log tampering generate a log-integrity verification frequency increase proposal. Proposals are human-reviewed by the workflow security lead before deployment; the change log is machine-readable and affected workflow teams are notified within 24 hours of a tightening change affecting their workflow's hardening profile. Hardening changes that reflect a new workflow attack pattern are fed back to TA-Processes as a candidate new threat entry and to SR-Processes as a candidate new requirements-pack item. Auto-provisioning fires on SM-Processes inventory registration: when a new AI/HAI-embedded workflow is registered, the IaC automation provisions its tier-appropriate hardening profile within 24 hours.

C) Contribute AI/HAI workflow hardening baselines to industry. Contribute anonymized EH-Processes hardening baseline modules to OECD AI governance working groups (AI/HAI workflow operational envelope controls, signed definitions, HITL integrity, disclosure governance), to ISO/IEC 42005 AI incident management process guidance (process hardening patterns relevant to incident prevention in AI-embedded workflows), to the CSA AI Safety Initiative (workflow-definition integrity and HITL operational controls), and to sector ISACs, FS-ISAC, H-ISAC, IT-ISAC AI working groups, with sector-relevant hardening patterns for decision pipelines and customer-facing AI workflows. Target ≥2 substantive contributions per year; contributions maintained upstream; internal practice aligned with the published external version.

Outcome Metrics (L3).

Success Criteria.

• ≥90% of EH-Processes controls expressed as authoritative IaC; drift detected continuously; ≥70% of low-risk drift auto-remediated; high-risk drift human-reviewed within 2 business days.
• Adaptive-policy pipeline operational with ML-Processes and IM-Processes signal sources; every change traceable to a source signal; downstream workflow teams notified within 24 hours.
• New AI/HAI-embedded workflows auto-provisioned with tier-appropriate hardening within 24 hours of SM-Processes registration.
• ≥2 industry hardening baseline contributions per year (OECD AI, ISO/IEC 42005, CSA, sector ISACs) with documented adoption.

Common Pitfalls

Level 1. - Workflow-definition signing policy declared but the BPM runtime loads definitions from a shared folder any developer can overwrite, the signing requirement lives in documentation, is not enforced at deploy time, and unsigned definitions enter production undetected. - HITL review UI requires SSO but uses a shared service account for the review-API backend, individual reviewer actions are not attributable to named identities and the override audit trail lists a service account for all decisions. - Reviewer-capacity monitoring is a dashboard that nobody watches, queue depth spikes over a long weekend, reviewers clear the queue by bulk-approving items on Monday morning, and the rubber-stamp incident is never detected because no alert fired. - Classification-aware routing documented in the workflow architecture but the BPM engine has no enforcement hook, a developer changes the data-routing configuration directly in the workflow step and regulated PII reaches an uncleared AI step.

Level 2. - JIT access policy for Critical-tier workflow changes created but the BPM platform's API accepts changes from service tokens with standing permissions, developers continue using long-lived tokens that predate the JIT policy, and the JIT requirement is enforced only on the UI, not the API. - Dedicated reviewer pool declared in documentation but the review-queue UI serves items from all tiers to all reviewers, the dedicated pool designation is a label, not an enforcement boundary, and Critical-tier items are reviewed by whoever picks them up first. - Log-integrity verification job runs weekly but alert routing is misconfigured, hash mismatches produce a log entry in the verification job's own output, not an IM-Processes ticket, and the first log-integrity failure goes unnoticed until the next quarterly review. - Per-execution disclosure completion metric is computed on a daily batch basis, a disclosure suppression affecting thousands of customer interactions is not detected until the next morning's batch run, well past the window for immediate regulatory notification evaluation.

Level 3. - IaC coverage declared at ≥90% but the registry includes workflow configuration stubs with placeholder values, actual deployed configurations diverge from the stubs and drift detection fires against the stub, not the real configuration. - Adaptive-policy pipeline wired to ML-Processes but not to IM-Processes, post-incident review findings that identify a hardening gap never reach the adaptive-tightening pipeline and the loop is incomplete. - Industry contributions to OECD AI are submitted once and not maintained, internal practices advance while the published baseline reflects the original L2 configuration and external adopters build on stale guidance. - Auto-provisioning trigger fires on SM-Processes registration but uses the tier assignment from the registration event rather than the current tier, a workflow reclassified from Medium to Critical after a DR finding receives Medium-tier hardening because the provisioning pipeline cached the original tier.

Practice Maturity Questions

Level 1. 1. Does every AI/HAI-embedded workflow in the SM-Processes inventory (across all seven archetypes, decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow) run against a signed, version-controlled workflow definition with peer review enforced for all AI-step changes and DR re-review triggered for material changes, and are all HITL review UIs requiring SSO + MFA with reviewer identities individually attributable? Evidence: BPM platform / VCS audit × SM inventory; IdP audit × workflow inventory; reviewer-session log sample. 2. Are Art. 50 disclosure templates managed exclusively in a central registry with no unregistered templates deployed in production, is disclosure-suppression detection (A/B-test registration requirement and traffic-split alerting) active, and are contestation-response SLAs under GDPR Art. 22 monitored with escalation alerts for at-risk workflows? Evidence: template registry export × deployed-UI reconciliation; A/B-test registry log; Art. 22 SLA telemetry. 3. Is classification-aware routing enforced at workflow ingress preventing regulated PII from reaching uncleared AI steps, is a PII redaction layer active where required, and are immutable decision logs and tamper-evident override audit trails active for all Critical/High-tier workflows with retention meeting the longest applicable regulation? Evidence: routing-policy configuration; redaction pipeline export; decision-log retention audit; override audit-trail sample.

Level 2. 1. Are 100% of Critical-tier workflow-definition changes executed under JIT access (≤4-hour time-limited, approval-gated, with automatic revocation at expiry) with no standing write access for Critical-tier definitions, and are dedicated reviewer pools operational for all Critical-tier HITL steps with capacity monitoring, SLA-at-risk alerting, and zero cross-tier queue bleed? Evidence: IAM / BPM access log × change log; workflow configuration audit × SM inventory; reviewer-pool registry. 2. Is a hardening tier-treatment matrix published and enforced per SM-Processes L2 risk tiers, are Critical-tier decision-log integrity verification jobs running weekly with results as compliance evidence, and does the per-execution disclosure completion metric for Critical-tier customer-facing flows maintain 100% completion with deviations routing to IM-Processes within 4 hours? Evidence: published matrix and provisioning-gate configuration; integrity-check telemetry; disclosure-completion metric export. 3. Are HITL rubber-stamping rates trending down for Critical-tier workflows after dedicated-reviewer-pool and capacity-monitoring activation, is enhanced override-authority enforcement (mandatory rationale, repeated-no-rationale escalation) active for Critical-tier, and are per-tenant runtime isolation controls operational for Critical-tier multi-tenant customer-facing flows confirmed by IR-Processes reviews and ST-Processes isolation tests? Evidence: reviewer-match-rate trend chart; override-rationale completeness report; IR isolation findings; ST isolation-test results.

Level 3. 1. Are ≥90% of EH-Processes controls expressed as authoritative IaC (not stubs) in a version-controlled registry with drift detected on a scheduled cadence, ≥70% of low-risk drift auto-remediated, and high-risk drift (JIT policy removed, disclosure template suppressed, log integrity disabled) human-reviewed within 2 business days, and are new AI/HAI-embedded workflows auto-provisioned with tier-appropriate hardening within 24 hours of SM-Processes inventory registration? Evidence: IaC registry inventory; drift-detection telemetry; auto-remediation rate; provisioning telemetry tied to SM registration events. 2. Is the adaptive-policy pipeline operational with ML-Processes detections (rubber-stamp HITL, disclosure suppression, shadow-AI-in-process) and IM-Processes incident patterns generating human-approved tightening proposals on a tracked cadence, every change traceable to a source signal, and affected workflow teams notified within 24 hours of a tightening change? Evidence: adaptive-policy change log with ML/IM source references; human-approval records; downstream-team notification log. 3. Does the program contribute ≥2 AI/HAI workflow hardening baselines per year to industry bodies (OECD AI governance, ISO/IEC 42005, CSA AI Safety Initiative, sector ISACs) with documented adoption, and are these contributions maintained current with internal practice rather than published once and left to diverge? Evidence: contribution log with submission dates and upstream adoption references; version-alignment record between internal and published baselines.

24. Issue Management (IM)

Practice Overview

Objective: Run a single unified backlog and a tier-calibrated incident playbook for every AI/HAI workflow issue the organization operates, findings from TA-Processes snapshots, SR-Processes REM gaps, DR-Processes conditions, IR-Processes drifts, ST-Processes failures, ML-Processes detections, and external advisories, with named owners, tier-aware SLAs, AI-specific workflow containment plays, and regulatory SLA tracking covering GDPR Arts. 22/33, EU AI Act Arts. 14/26/50/73, HIPAA, FCRA, FINRA, NYC LL 144, and CO SB-21-169 that never misses a notification window because of organizational diffusion.

Description: IM-Processes is the clearinghouse for everything the other Processes-domain practices produce. Every TA-Processes threat-snapshot row carrying residual risk, every SR-Processes REM accepted gap with an owner and expiry, every DR-Processes approve-with-conditions item, every IR-Processes drift finding, every ST-Processes failure, every ML-Processes detection that fires, and every external advisory (sector regulator enforcement actions, NYC LL 144 bias-audit findings, EEOC bias enforcement, EU AI Act enforcement decisions, DPA advisories, customer reports) flows into a single, prioritized backlog with named owners, tier-calibrated SLAs, and an unambiguous playbook. The playbook contains AI-specific workflow containment plays, wrongful-decision containment for decision-pipeline manipulation, HITL failure / rubber-stamp response, workflow injection containment, approval-chain breach handling, autonomous-action drift containment, disclosure-failure remediation, content-generation policy-violation containment, knowledge-base poisoning containment, and shadow-AI-in-process containment. Pre-established escalation paths cover Privacy/Legal, the deployer-duty owner, the executive sponsor, and Communications for customer-facing impact. Every Critical or blocker incident receives a post-incident review whose outputs feed back to SA-Processes (pattern update), SR-Processes (requirements-pack update), EG-Processes (training content), and ML-Processes (detection update).

Context: Without a unified backlog, AI/HAI workflow issues scatter across product JIRA projects, compliance trackers, legal dashboards, and BPM alert channels. TA-Processes residual risks from a decision-pipeline threat age without remediation owners. An ML-Processes rubber-stamp HITL detection fires on a Friday and routes to a Slack channel with no named on-call owner. A GDPR Art. 22 contestation request arrives and nobody can locate the decision log because the IR-Processes finding about log-retention compliance still sits open in a separate queue. An EU AI Act Art. 50 disclosure failure affects 10,000 customer interactions and the organization does not know whether Art. 73 serious-incident reporting is required because no playbook entry covers that scenario. The GDPR Art. 33 72-hour clock starts at the moment the organization becomes aware of a personal-data breach, not when the responsible team processes the notification. EU AI Act Art. 14 imposes human-oversight obligations whose failure must be evaluated against Art. 26.5 deployer-suspension triggers. IM-Processes closes these gaps with a single backlog, one triage rubric, AI-specific workflow incident classes named in advance, and a regulatory SLA tracker that escalates automatically as clocks approach expiry.

Maturity Level 1

Objective: Operate a single unified AI/HAI workflow issue backlog with a standard triage rubric, an AI-specific workflow incident playbook covering the primary process incident classes, and regulatory SLA tracking for GDPR Arts. 22/33, EU AI Act Arts. 14/26/50/73, HIPAA, FCRA, FINRA, NYC LL 144, and CO SB-21-169 obligations.

Activities.

A) Stand up the AI/HAI workflow issue backlog and triage rubric. One backlog with standardized metadata per issue: source (TA / SR / DR / IR / ST / ML / external, including sector regulator enforcement actions, NYC LL 144 audit findings, EEOC bias enforcement, EU AI Act enforcement decisions, DPA advisories, customer reports); affected workflow(s) linked to the SM-Processes inventory with archetype and tier; severity (Critical / High / Medium / Low anchored to AI-specific axes); named owner from the SM-Processes inventory with escalation path to the program sponsor; SLA target; evidence link to the originating artifact (TA snapshot row, REM gap row, DR decision, IR finding, ST test result reference, ML alert ticket, external advisory URL); and a regulatory flag indicating whether the issue carries a notification obligation (GDPR Art. 33 clock started, EU AI Act Art. 73 clock started, HIPAA breach-notification triggered, FCRA adverse-action remediation triggered, NYC LL 144 audit finding, sector-specific). The AI/HAI Processes-domain severity rubric: Critical means a wrongful automated decision affecting a named individual or class in an Annex III workflow context, a HITL failure confirmed on a workflow with real-world consequential outcomes (credit denial, employment, benefits), a confirmed Art. 50 disclosure failure affecting ≥1,000 customer interactions or a regulated context, a personal-data breach in an AI/HAI workflow triggering GDPR Art. 33, shadow AI confirmed handling regulated data without intake, or RAG-poisoning confirmed delivering false information in a consequential decision context; High means a confirmed HITL rubber-stamp on a Critical/High-tier workflow, a confirmed workflow-definition change deployed without DR re-review for material changes, Art. 50 disclosure suppression in a non-regulated context, a GDPR Art. 22 contestation request that cannot be fulfilled within the statutory window, or a class-shift / decision-distribution anomaly on a protected-attribute security-intersection workflow pending root-cause; Medium covers confirmed gaps in non-production or compensating-control-protected production workflows, SR-Processes REM accepted gaps past expiry without renewal, IR-Processes drift findings on Medium-tier workflows, and reviewer-capacity SLA-at-risk alerts unresolved after 24 hours; Low captures informational items, non-urgent gaps, recommendations from external advisories not yet assessed, Low-tier workflow logging gaps, and minor classification-routing discrepancies without active data-flow impact. Published SLAs: Critical acknowledge ≤4h / contain ≤48h / root-cause ≤30d; High ack ≤24h / contain ≤7d / root-cause ≤45d; Medium ack ≤48h / remediate ≤14d; Low ack ≤5 business days / remediate ≤30d. Triage cadence: daily for Critical and new High; weekly for Medium; monthly aging review for the full backlog.

B) Publish the AI-specific workflow incident playbook. Publish playbook entries for the primary AI/HAI workflow incident classes; each entry names trigger conditions, pre-assigned roles (deployer-duty owner, Privacy/Legal, executive sponsor escalation path, workflow operations on-call, Communications for customer-facing impact), step-by-step containment, artifacts to collect, evidence-capture instructions for the deployer-duty record, closure criteria, and SLA targets. Wrongful-decision containment for decision-pipeline manipulation: pause the affected workflow step pending manual review, pull decision-log records for the affected period, route affected decisions to a named senior reviewer, notify affected individuals of contestation rights under GDPR Art. 22, evaluate EU AI Act Art. 73 serious-incident reporting for Annex III workflows, evaluate Art. 26.5 deployer-suspension obligation on confirmed non-conformance, and preserve the full decision log for the affected period. HITL failure / rubber-stamp containment for HITL gate bypass: pause the affected HITL workflow step, audit the reviewer pool, assess whether decisions during the rubber-stamp period require retroactive review, escalate mandatory reviewer training for affected reviewers, evaluate whether the period constitutes Art. 26 deployer-duty non-conformance, and implement enhanced reviewer-capacity monitoring and load-balancing before restarting the step. Workflow injection / approval-chain breach containment: identify the injected step or breached approval, freeze the affected workflow definition, audit upstream artifacts and downstream effects, restore the last-known-good signed definition through the rollback playbook, evaluate Art. 22 and Art. 33 obligations for any regulated-data exposure, and rotate any approval-chain credentials whose integrity is suspect. Disclosure failure (Art. 50): identify the surface or workflow step where disclosure was suppressed, fix the rendering defect or restore the suppressed template from the central registry, assess scope (how many interactions over what period), perform retroactive disclosure where appropriate, evaluate Art. 26 deployer-duty non-conformance, and route the responsible team's A/B test or product change to its own IM backlog. Autonomous-action drift containment: trip the circuit breaker on the affected autonomous step, freeze rate-limited capacity, reverse reversible actions under human review, audit the autonomous-action log for prior drift indicators, and evaluate cross-domain coordination with the Software domain if the underlying agent is org-built. Content-generation policy-violation containment: recall or retract the harmful output where technically feasible, issue customer-facing correction notification as appropriate, pause the content-generation workflow step pending root-cause, identify the generation prompt / model version / workflow template responsible, roll back to the last-known-good version, evaluate regulator notification if regulated topics were touched, and update the brand-safety filter with new patterns from the incident. Knowledge-base poisoning containment for knowledge-management RAG-poisoning: quarantine the affected corpus segment, disable the retrieval pipeline pending re-indexing, identify users who received responses influenced by the poisoned retrieval, notify affected users where the retrieval materially affected a consequential decision, evaluate GDPR Art. 33 for any regulated-data exposure, re-index the corpus after removal of the poisoned document and validation by ST-Processes retrieval-poisoning tests, and assess whether the poisoning was adversarial or incidental. Shadow-AI-in-process containment: freeze the unrecognized AI step pending intake, identify the workflow, team, and developer responsible, route the AI step through SM-Processes intake under an amnesty path where appropriate, assess the shadow step's data-flow, evaluate GDPR Art. 33 and EU AI Act Art. 73 obligations if regulated personal data transited, and route any unvetted vendor to the Vendors-domain IM backlog for TPRM intake.

C) Track regulatory SLAs and run post-incident reviews. The regulatory SLA tracker is live with named obligations and automated escalation as deadlines approach. GDPR Art. 33: 72-hour supervisory-authority notification window after the controller becomes aware of a personal-data breach; the clock starts on the first internal alert that constitutes awareness; named owner Privacy/Legal; daily-at-minimum status updates required until the notification is filed or the clock expires. GDPR Art. 22: organizations subject to Art. 22 must provide individuals with the right to obtain human intervention, express their point of view, and contest the decision; the contestation response SLA is defined per workflow per SR-Processes requirements; named owners Privacy/Legal plus the workflow owner. EU AI Act Art. 14: human-oversight obligations for high-risk AI systems; failure events feed both the IM incident response and the Art. 26.5 evaluation chain; named owner Privacy/Legal plus the deployer-duty owner. EU AI Act Art. 26.5: deployer obligation to suspend use of the AI system on discovered non-conformance with Art. 26 deployer duties; named owners Privacy/Legal plus CISO; evaluation triggered by wrongful-decision, HITL failure, and disclosure failure incidents. EU AI Act Art. 73: serious-incident reporting for Annex III high-risk systems on the timeline set by the implementing act; named owners Privacy/Legal plus executive sponsor; escalation immediate on any Annex III-classified workflow incident. HIPAA: 60-day discovery-to-notification ceiling for covered entities and business associates where AI/HAI workflow incidents involve PHI; named owner Privacy/Legal. FCRA adverse-action: adverse-action notices required within the applicable timeframe when AI/HAI decision pipelines produce adverse credit, employment, or insurance decisions; named owner Compliance / Legal. NYC LL 144 bias audit: annual bias-audit requirement for automated employment decision tools used in NYC; audit findings publicly posted; IM tracks open audit findings from the most recent LL 144 cycle; named owner Compliance. CO SB-21-169 insurance unfair-discrimination: Colorado SB 21-169 requires insurers using external consumer data and AI/ML to demonstrate non-discrimination; named owner Compliance / Legal. FINRA model-risk: material model-risk incidents in financial-sector decision pipelines tracked in IM; named owner Compliance / Legal. Every Critical or blocker incident receives a post-incident review within 14 days of containment covering what happened (root cause, initiation path, controls that failed or were absent), what caught it (which detection, source, or external report surfaced it first; whether this was the expected detection path or a gap), what did not catch it (controls that should have detected or prevented this but did not), and update outputs to SA-Processes (pattern-update request if the incident exploited an architectural gap), SR-Processes (requirements-pack update if the incident exploited a missing or vague requirement), EG-Processes (training-content update if the incident indicates a literacy gap in the workflow-operations population), and ML-Processes (detection-update request, new detection, tuned query, or evidence an existing detection can be sharpened). Post-incident review outputs are tracked as IM issues of type "improvement" and age against the same process-metric cadence as other issues.

Outcome Metrics (L1).

Success Criteria.

• Single AI/HAI workflow issue backlog established with standardized metadata; AI-specific triage rubric with severity definitions published.
• Seven AI-specific workflow incident playbook entries published (wrongful-decision containment, HITL failure / rubber-stamp, workflow injection / approval-chain breach, disclosure failure, autonomous-action drift, content-generation policy violation, knowledge-base poisoning, shadow-AI-in-process) with named roles, containment plays, evidence-capture steps, and SLA targets; each exercised in at least one tabletop in the last 12 months.
• Regulatory SLA tracker live covering GDPR Arts. 22/33, EU AI Act Arts. 14/26/50/73, HIPAA, FCRA adverse-action, FINRA model-risk, NYC LL 144, CO SB-21-169, and sector-specific obligations; 100% adherence in the last 90 days.
• Post-incident review loop wired to SA-Processes, SR-Processes, EG-Processes, and ML-Processes; every Critical/blocker incident produces a review within 14 days with named update outputs per downstream practice.
• Program-sponsor dashboard refreshed monthly showing backlog aging, SLA adherence, and post-incident learning outputs.

Maturity Level 2

Objective: Calibrate incident response depth per SM-Processes L2 risk tier; operate dedicated 24/7 on-call coverage and pre-staged escalation for Critical-tier workflows; auto-flow post-incident review outputs to SA/SR/EG/ML practice backlogs; activate cross-domain coordination when a Processes-domain workflow incident implicates Software, Data, or Vendors.

Activities.

A) Tier-calibrated incident playbook and on-call. Extend L1 playbook entries with tier-specific activation criteria and on-call coverage. Critical tier: full IM activation, CISO or delegate plus Privacy/Legal plus the workflow deployer-duty owner plus executive sponsor notification plus Communications routing for customer impact; ≤1 hour acknowledgement; ≤4 hours containment-action initiated; 24/7 on-call coverage with a named AI/HAI workflow incident responder in each on-call rotation; pre-staged communication templates (internal, customer-facing, regulatory) loaded and reviewed quarterly. High tier: scoped response, AppSec lead plus Privacy/Legal if regulated data is involved plus the deployer-duty owner; ≤4 hours acknowledgement; ≤24 hours containment-action initiated; business-hours on-call with after-hours escalation path defined. Medium tier: standard response with ≤1 business day acknowledgement and queue-based triage. Low tier: tracked in queue with aggregated weekly handling. Critical-tier on-call rotation is documented per week with named individuals, a coverage-handoff protocol, and an on-call briefing that includes the current Critical-tier workflow list, the pause-workflow and rollback paths for each, and the active detection set.

B) Post-incident review auto-flow integration. Wire IM-Processes post-incident review outputs to downstream practice backlogs via a defined integration. SA-Processes pattern-update requests auto-create architecture-backlog tickets with the IM incident reference linked. SR-Processes requirements-pack update requests auto-create pack-backlog tickets with the requirements-pack version and failing requirement row linked. EG-Processes training-content update requests auto-create training-backlog tickets with the affected workflow-operations population segment and the incident summary linked. ML-Processes detection-update requests auto-create detection-registry update tickets with the detection name, current query, and proposed change linked. SLA for downstream updates: Critical-tier post-incident review outputs must be accepted or rejected by the downstream practice owner within 14 days; accepted updates are treated as High-severity issues in the receiving practice's backlog. The program sponsor reviews post-incident review quality quarterly, are update outputs substantive (concrete change to a pattern, pack, curriculum, or detection) or nominal (a note saying "consider reviewing")?

C) Cross-domain coordination protocol. Publish a cross-domain coordination protocol that activates when a Processes-domain AI/HAI workflow incident implicates another domain. Processes → Software: a production agent (Software domain) makes unauthorized writes to a business-process workflow (customer records, financial records, case management system), activates Software-domain IM's agent-rogue-action playbook alongside Processes-domain wrongful-decision containment; named Software-domain IM contact on file. Processes → Data: a decision-pipeline workflow's AI model is producing anomalous outputs attributable to training-corpus poisoning (Data domain), activates Data-domain IM's training-corpus-poisoning playbook alongside Processes-domain class-shift / wrongful-decision response; named Data-domain IM contact on file. Processes → Vendors: a third-party AI model embedded in a decision pipeline produces harmful outputs attributable to a vendor model update, activates Vendors-domain IM's vendor-material-change playbook alongside Processes-domain wrongful-decision containment; named Vendors-domain IM contact on file. Cross-domain activations share a single status board, a single IC from the primary impacted domain, coordinated remediation tracking, and a joint post-incident review spanning all affected domains. Tier-movement in the SM-Processes inventory auto-triggers IM configuration updates: a Medium → Critical re-tier updates the on-call path, playbook variant, and SLA targets within 14 days.

Outcome Metrics (L2).

Success Criteria.

• Critical-tier MTTA ≤1 hour; MTTC ≤4 hours; 24/7 on-call coverage with a documented rotation including a current Critical-tier workflow briefing.
• Post-incident review auto-flow integration live; 100% of Critical-tier review outputs auto-routed; ≥90% of downstream practice owners responding within 14 days.
• Cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI workflow incidents; named cross-domain contacts for Software, Data, and Vendors verified quarterly.
• Tier-movement in SM-Processes inventory auto-triggers IM configuration updates within 14 days for Critical re-tiers.

Maturity Level 3

Objective: Contribute workflow incident patterns and playbook templates to sector ISACs, OECD AI, ISO/IEC 42005, and the CSA AI Safety Initiative; execute pre-authorized automated containment for defined low-severity high-confidence detections; benchmark MTTR against industry peers and link deltas to investment proposals.

Activities.

A) Industry-coordinated incident sharing and contribution. Participate in sector-ISAC AI incident-sharing programs (FS-ISAC AI working group, H-ISAC, IT-ISAC, sector-specific). Consume ISAC AI incident feeds and integrate relevant advisories into the IM-Processes external-advisory source. Contribute anonymized incident classification (incident type, archetype, containment play used, regulatory SLA activated, MTTR achieved) on a per-incident-class basis; target ≥4 ISAC contributions per year. Contribute to AI workflow-incident taxonomy standards: OECD AI (workflow incident classification schema, playbook template structures, regulatory SLA tracking models); ISO/IEC 42005 AI incident management (workflow-specific incident patterns, wrongful-decision, HITL failure, disclosure failure, knowledge-base poisoning containment plays, as candidate process guidance); CSA AI Safety Initiative (workflow incident severity-anchor definitions, evidence-capture standards for deployer-duty compliance). Target ≥2 OECD AI / ISO/IEC 42005 / CSA contributions per year; all contributions anonymized, legally vetted, and maintained.

B) Pre-authorized automated runbook decisioning. Define and publish a pre-authorization policy for automated containment actions, the set of actions that may execute without human approval when a detection fires at a defined confidence threshold. Pre-authorized actions include pausing a Low-tier or Medium-tier HITL workflow step when a reviewer-capacity saturation detection fires above 95% confidence (pausing new-item routing pending human escalation acknowledgement), quarantining a knowledge-management corpus segment when a RAG-poisoning detection fires with a specific flagged document ID on a non-Critical-tier workflow, freezing execution of an unrecognized AI step when the ML-Processes shadow-AI-in-process detection fires on a Low/Medium-tier workflow, and rolling back a disclosure template to the last registry-registered version when a disclosure-suppression detection fires on a non-Critical-tier customer-facing flow. Pre-authorized actions for Critical-tier workflows require human confirmation within 15 minutes; the action fires after that window if no confirmation arrives, with executive notification at fire time. All pre-authorized actions produce a full audit-log entry in the IM-Processes backlog, a human-review ticket auto-created at execution, and notification to the workflow's deployer-duty owner. The pre-authorization policy is reviewed quarterly by Privacy/Legal and the executive sponsor; any automated action producing an unexpected outcome triggers an out-of-cycle review.

C) MTTR benchmarking. Establish MTTR benchmarks from ISAC AI incident data exchanges, OECD AI incident database contributions from peer organizations, and peer roundtables (CISO and AI-safety practitioner communities, workflow governance practitioners). Publish a quarterly MTTR benchmark brief to the program sponsor covering MTTR per incident class vs. benchmark (wrongful-decision containment, HITL failure, disclosure failure, knowledge-base poisoning, shadow-AI-in-process, content-generation policy violation, autonomous-action drift), MTTR per tier (Critical, High, Medium) vs. benchmark, delta trend (improving, stable, degrading), and an investment driver, where MTTR is above benchmark, root-cause mapped to a specific practice gap (missing detection, unclear playbook, on-call latency) with a budget-linked improvement proposal.

Outcome Metrics (L3).

Success Criteria.

• ≥4 ISAC AI incident contributions per year; ≥2 OECD AI / ISO/IEC 42005 / CSA contributions per year; all contributions anonymized, legally vetted, and maintained.
• ≥3 pre-authorized automated containment actions live, vetted by Privacy/Legal and the executive sponsor, producing 100% audit records and human-review tickets on execution.
• Quarterly MTTR benchmark brief published to sponsor; Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes; deltas above benchmark linked to investment proposals.
• Pre-authorization policy reviewed quarterly; no unauthorized automated action executed; all unexpected automation outcomes reviewed within 5 business days.

Common Pitfalls

Level 1. - "Single backlog" exists in name only, ST-Processes failures stay in the CI dashboard, ML-Processes alerts route to a Slack channel, TA-Processes residual risks live in a spreadsheet; coverage stalls near 40% and the ≥95% target is never achieved. - Triage rubric severity anchors are generic probability × impact scoring without AI-specific axes, a wrongful automated decision affecting a named individual under an Annex III workflow is triaged Medium because the rubric has no axis for EU AI Act Art. 73 applicability. - GDPR Art. 33 72-hour clock is tracked informally, an Art. 50 disclosure failure involving PII lands on a Friday evening, the clock starts, no named owner confirms the start time, and the SLA slips before anyone documents the awareness event. - Shadow-AI-in-process incidents are treated as vendor intake events (routed to Vendors-domain IM) rather than triggering the Processes-domain shadow-AI-in-process playbook, the data-flow assessment and GDPR Art. 33 evaluation never happen.

Level 2. - Critical-tier activation criteria are vague, wrongful-decision incidents involving Annex III workflows stay in the standard queue until the deployer-duty owner escalates, and the ≤1-hour MTTA SLA is already missed by the time the right people engage. - Post-incident review auto-flow integration is wired but downstream practice backlogs treat the auto-created tickets as nominal, the ML-Processes team closes the detection-update ticket as "acknowledged" without updating the detection query, and the feedback loop produces no change. - Cross-domain coordination protocol exists on paper but no IC is pre-designated, the first cross-domain incident where a Software-domain agent rogue action writes to a Processes-domain workflow produces ownership confusion, with both domains waiting for the other to take the IC role. - 24/7 on-call coverage is implemented but the on-call briefing is stale, new Critical-tier workflows are not in the briefing, and on-call responders do not know the pause-workflow path for recently tiered workflows.

Level 3. - ISAC participation limited to consuming feeds, contributions are absent, the organization is labeled a free-rider, and influence over AI workflow incident taxonomy standards diminishes as the feed quality degrades without reciprocal intelligence. - Pre-authorized automated containment fires on a Critical-tier workflow because the confidence threshold was set too loosely, a false positive pauses a production customer-facing flow handling thousands of active sessions because the pre-authorization policy had no Critical-tier exception check. - MTTR benchmark brief cites benchmarks from organizations with fundamentally different AI/HAI workflow portfolio scale, "we are at benchmark" is true but the benchmark set was chosen to flatter rather than stretch. - OECD AI / ISO/IEC 42005 contributions submitted once and never updated, novel workflow incident classes evolve, and the org's contribution reflects patterns from 18 months ago that have since been mitigated.

Practice Maturity Questions

Level 1. 1. Is a single AI/HAI workflow issue backlog operating with standardized metadata (source, affected workflow linked to SM-Processes inventory, severity rubric anchored to AI-specific axes, wrongful automated decision / HITL failure / disclosure failure / regulated-data breach for Critical; confirmed control failure with potential impact for High, owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA, SR, DR, IR, ST, ML, external)? Evidence: backlog audit cross-referenced against per-practice source queues for the last 90 days. 2. Is the AI/HAI workflow incident playbook published with named AI-specific workflow incident classes (wrongful-decision containment, HITL failure / rubber-stamp, workflow injection / approval-chain breach, disclosure failure, autonomous-action drift, content-generation policy violation, knowledge-base poisoning, shadow-AI-in-process), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months? Evidence: published playbook; tabletop exercise records covering each class. 3. Is the regulatory SLA tracker live covering GDPR Arts. 22/33, EU AI Act Arts. 14/26/50/73, HIPAA, FCRA adverse-action, FINRA model-risk, NYC LL 144, CO SB-21-169, and sector-specific obligations with 100% adherence in the last 90 days, and does every Critical/blocker incident produce a post-incident review within 14 days with named update outputs to SA-Processes, SR-Processes, EG-Processes, and ML-Processes? Evidence: SLA tracker export; post-incident review records with downstream-practice update tickets.

Level 2. 1. Is a tier-calibrated incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier workflow briefing, and tier-movement in the SM-Processes inventory automatically triggering IM configuration updates within 14 days for Critical re-tiers? Evidence: IM telemetry showing MTTA/MTTC distributions; on-call rotation registry with briefing; auto-update log for tier-movement events. 2. Is a post-incident review auto-flow integration live routing Critical-tier review outputs to SA/SR/EG/ML practice backlogs with ≥90% of downstream practice owners responding within 14 days, and is sponsor review of output quality occurring quarterly to distinguish substantive changes from nominal acknowledgements? Evidence: integration telemetry; downstream backlog aging report; quarterly sponsor review notes. 3. Is a cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI workflow incidents with named cross-domain contacts for Software, Data, and Vendors verified quarterly, a single IC from the primary impacted domain, and joint post-incident reviews spanning all affected domains? Evidence: published protocol; cross-domain contact registry with quarterly verification log; joint post-incident review records.

Level 3. 1. Does the program contribute ≥4 anonymized AI workflow incident-classification entries per year to sector ISACs and ≥2 contributions per year to OECD AI, ISO/IEC 42005, or CSA AI Safety Initiative with all contributions maintained current, legally vetted, and tracked for external adoption? Evidence: contribution log with submission dates and upstream adoption references. 2. Are ≥3 pre-authorized automated containment actions live (HITL-step pause, RAG-corpus quarantine, shadow-AI-step freeze, or disclosure-template rollback classes), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets, with the pre-authorization policy reviewed quarterly and any unexpected outcome triggering an out-of-cycle review? Evidence: pre-authorization policy; automation execution log with audit records and human-review tickets; quarterly review minutes. 3. Is a quarterly MTTR benchmark brief published to the sponsor comparing the program's MTTR per incident class and per tier against ISAC-sourced and peer-sourced benchmarks with Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes and deltas above benchmark linked to specific practice gaps and investment proposals? Evidence: quarterly benchmark briefs for the last 12 months with benchmark sources and investment-proposal references.

25. Monitoring & Logging (ML)

Practice Overview

Objective: Establish the logging baseline per AI/HAI process archetype, operate a small high-signal detection set targeted at the top threats from TA-Processes, and produce the evidence trail that proves EU AI Act Art. 14 human-oversight evidence and Art. 12 deployer-duty logs, GDPR Art. 22 contestation evidence, and ISO/IEC 42001 AIMS requirements on demand inside a published SLA.

Description: ML-Processes captures the signals produced by every AI/HAI-embedded business workflow the organization operates, decision pipelines, customer-facing flows, HITL chains, back-office augmentation workflows, approval/review workflows, content-generation workflows, and knowledge-management workflows. For each archetype it specifies the exact events to capture (decision events, HITL invocations and override events, approval events, autonomous-action executions, content-generation events, knowledge-base updates, disclosure events, admin-audit events, and identity events), the retention window required to satisfy the longest applicable regulation (EU AI Act Art. 12 high-risk-system logs ≥6 months; GDPR Art. 22 contestation evidence per the applicable contestation window; FCRA 25 months for adverse-action records; FINRA 6 years; HIPAA 6 years), and the export path that supports auditor review and DSAR fulfillment within a published SLA. On top of the logging baseline it operates a bounded, purposeful detection set, each detection tied to a TA-Processes archetype threat, each with a named owner, a defined query, an SLA, and a tuning record. The full corpus is the primary evidence artifact for PC-Processes's compliance map: EU AI Act Art. 14 human-oversight evidence, Art. 12 deployer-duty logs, GDPR Art. 22 contestation evidence, GDPR Art. 30 records of processing, and ISO/IEC 42001 AIMS operational evidence.

Context: Logging AI/HAI-embedded workflows is not the same as logging classic business process events. A decision-pipeline event must carry the request-id, principal, AI output and confidence score, decision threshold, final decision, model and version, and override flag, not merely a workflow step completion status. A HITL review event must record the reviewer's authenticated identity, the AI suggestion, the reviewer's decision, time-spent, and rationale, not only the queue-item closure. An Art. 50 disclosure event must capture the template version rendered and the execution-id to support an individual's contestation claim. An audit-trail event must be tamper-evident so an Art. 14 oversight-evidence pull can demonstrate the integrity of the chain. None of this exists by default in standard BPM audit logs or SIEM tooling unless the archetype's event schema has been explicitly defined and instrumented. ML-Processes makes that schema explicit, per archetype, from day one, so the organization is not reconstructing an evidence trail from incomplete telemetry at the moment a regulator, DSAR, or adverse-action contestation demands it. ML-Processes is also the upstream feed for IM-Processes: detections route directly to the unified backlog, and post-incident review outputs return to ML as detection-update requests.

Maturity Level 1

Objective: Establish the per-archetype logging baseline, operate a small high-signal detection set targeting the top TA-Processes threats and HAI TTPs, and produce an on-demand evidence trail satisfying EU AI Act Art. 14 / Art. 12, GDPR Arts. 22 and 30, and ISO/IEC 42001 AIMS within a published SLA.

Activities.

A) Establish the per-archetype logging baseline. Define and instrument the minimum event schema for each archetype in the SM-Processes inventory. Every event carries an event-id / correlation-id, principal (user or service account), timestamp, archetype tag, workflow-id linked to the SM-Processes inventory, and the archetype-specific fields below; PII scrubbing is applied per SR-Processes data-boundary requirements before logging where logging the raw field would create a regulated-data exposure. Decision pipeline: decision event (request-id, principal, AI output or hash where regulated data may be present, AI confidence score, decision threshold, final decision, model and version, override flag, timestamp); override event (reviewer identity from SSO, override rationale, AI recommendation before, decision after, timestamp, workflow-id); decision-distribution metric event (rolling distribution of decision outcomes by class for protected-attribute intersection monitoring, security-relevant only, not fairness-standalone). Customer-facing flow: interaction event (session-id, PII-redacted content hash, AI step identifier, disclosure-shown flag, template version, timestamp); escalation event (session-id, escalation trigger, destination, timestamp); brand-safety filter event (filter triggered, action taken, session-id, timestamp). HITL chain: review event (reviewer identity from SSO, item-id, AI suggestion, reviewer decision, time-spent in seconds, mandatory rationale for Critical/High-tier, timestamp); reviewer-capacity event (queue depth, estimated-SLA-breach time, SLA-at-risk flag, timestamp). Back-office augmentation: assistant-session event (session-id, principal, workflow step, timestamp); tool-call event (tool name, arguments or hash for sensitive parameters, return value or hash, principal, success/fail, timestamp); output-review-gate event (gate triggered, reviewer identity, decision, timestamp). Approval/review workflow: screen event (item-id, AI screening result, threshold applied, tier-routing decision, timestamp); threshold event (threshold value, model version, workflow version, timestamp); tier-routing event (item-id, tier assigned, routing rule applied, timestamp); class-shift-monitor event (decision-distribution delta vs. baseline, protected-attribute class shift flag, security-intersection only, timestamp). Content-generation workflow: generation event (request-id, principal, content type, model and version, timestamp); output-review event (reviewer identity, item-id, review decision, timestamp); copyright-filter event (filter triggered, action taken, request-id, timestamp); downstream-emission event (where the generated content was published or routed, request-id, timestamp). Knowledge-management workflow: query event (query-id, principal, query text or hash, workflow-id, timestamp); retrieval event (document IDs retrieved, classification labels, provenance references, query-id, timestamp); provenance event (source attribution confirmed yes/no, provenance chain, query-id, timestamp); role-based-policy event (access policy checked, role, document-id, decision allowed/denied, timestamp). Admin-audit events across all archetypes capture workflow-definition changes (version, author, change type, AI step add/modify/remove vs. other), threshold changes, HITL-policy changes (reviewer-pool membership, rotation rules, capacity thresholds), disclosure-template changes, reviewer-pool membership changes, and any configuration change to a workflow step's AI model binding or version. Identity events capture SSO sign-ins to BPM tools (Camunda, Temporal, Argo admin consoles), review UIs, and workflow management consoles, plus reviewer-session start and end events. Retention meets or exceeds the longest applicable requirement (EU AI Act Art. 12 ≥6 months; GDPR Art. 22 contestation window per jurisdiction; FCRA 25 months for adverse-action records; FINRA 6 years; HIPAA 6 years); where multiple windows apply the longest governs. Export path (JSON or structured CSV) tested at least annually; on-demand pull SLA ≤24 hours for evidence requests from auditors, regulators, or legal hold; DSAR-capable export ≤72 hours for individual rights requests touching a decision or contestation record. Log integrity uses write-once or append-only storage for admin-audit and decision-log tiers with access-control separation between workflow application teams and log-store administrators.

B) Operate a small high-signal detection set. L1 target ≤12 detections, each tied to a TA-Processes archetype threat and at least one HAI TTP tag (EA / AGH / TM / RA) or ATLAS tactic, each with named owner, detection query, SLA (time-to-IM-ticket), and last-tuned date. Core detections: rubber-stamp HITL detection (EA TTP, reviewer decision matches AI recommendation ≥98% over a rolling 100-item window for a given reviewer on Critical/High-tier workflows; fires per-reviewer and per-workflow); reviewer-capacity saturation detection (EA TTP, estimated time to SLA breach for a HITL queue falls below the configured warning threshold; fires per HITL step); decision-distribution drift detection (security-intersection only, class-shift on protected-attribute decision distribution beyond a defined sigma from baseline; fires per decision pipeline where this monitoring is in scope per SR-Processes requirements); override-audit anomaly detection (ATLAS TA0008 Defense Evasion, override event present in the workflow log without a corresponding rationale field for a Critical/High-tier workflow); disclosure-suppression detection (ATLAS TA0008, Art. 50 disclosure UI not rendered in a customer-facing flow execution where the workflow definition requires it); affected-persons-rights-response SLA breach detection (contestation response window has elapsed without a logged response event for a GDPR Art. 22 workflow); shadow-AI-in-process detection (ATLAS TA0001 / EA TTP, new AI step detected in a workflow-definition version that does not appear in the SM-Processes inventory); workflow-config drift without DR record detection (ATLAS TA0008, a workflow definition version was promoted to production without a corresponding DR-Processes decision record in the last 5 business days for material changes); autonomous-action drift detection (RA TTP, autonomous step exceeds declared rate-limit envelope or circuit-breaker threshold); knowledge-base poisoning canary detection (AGH TTP, flagged document ID detected in a retrieval sequence for a knowledge-management workflow); content-generation policy-violation detection (brand-safety filter event with severity above threshold). Each detection routes to the IM-Processes backlog on fire; median detection-to-ticket time ≤1 hour for Critical-tier workflows; false-positive rate tracked per detection with monthly tuning review.

C) Produce and drill the deployer-duty evidence trail. ML-Processes is the primary evidence source for PC-Processes's priority compliance map. Wire the log store to the compliance requirements. EU AI Act Art. 14 human-oversight evidence: for every workflow assessed as involving an Annex III high-risk AI system use case, confirm that HITL review events, override events, reviewer-capacity events, and admin-audit events capture the human-oversight chain at the fidelity Art. 14 expects; produce a human-oversight evidence view (review records + override rationales + reviewer-capacity events + admin-audit chain) for each such workflow. EU AI Act Art. 12 high-risk-system deployer-duty logs: for every workflow assessed as Annex III high-risk, confirm that decision events, override events, disclosure-shown events, and admin-audit events are captured and retained at the required window. GDPR Art. 22 automated decision-making contestation evidence: for every decision-pipeline workflow subject to Art. 22, confirm that the decision log contains the AI output, threshold, final decision, and override flag for each individual decision and that the export path can produce this record for a named individual within the DSAR response window. GDPR Art. 30 records of processing: for every workflow processing personal data, the decision events, interaction events, and reviewer events with principal identity, data-class tag, and purpose label constitute the records-of-processing operational entries. ISO/IEC 42001 AIMS operational evidence: workflow-definition version events, admin-audit events, threshold change events, and reviewer-pool change events constitute the AIMS operational records. Quarterly deployer-duty drill: pull the deployer-duty evidence package for one randomly selected production workflow per archetype within the published SLA (≤24 hours from request to assembled package); record drill results; gaps route to IM-Processes.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype logging baseline published and instrumented for ≥90% of production AI/HAI-embedded workflows; PII scrubbing applied before long-term storage.
• ≤12-detection high-signal set live, each with owner, detection query, SLA, archetype tag, ATLAS-tactic or HAI-TTP tag, and monthly tuning record; false-positive rate tracked per detection.
• Retention meets the longest applicable regulatory window for every production workflow; export path tested at least annually; DSAR-capable export ≤72 hours.
• EU AI Act Art. 14 and Art. 12, GDPR Arts. 22 and 30, and ISO/IEC 42001 AIMS evidence-trail wiring documented; quarterly deployer-duty drill executed inside the ≤24-hour SLA.

Maturity Level 2

Objective: Calibrate logging depth and detection set to the SM-Processes L2 risk-tier rubric; integrate ML feeds into the SIEM for cross-workflow correlation; operate a quarterly detection-tuning loop fed by IM-Processes post-incident reviews and ST-Processes findings; establish anomaly-detection baselines for Critical and High-tier workflows.

Activities.

A) Tier-calibrated logging depth. Apply the SM-Processes L2 tier-treatment matrix to logging configuration. Critical: full decision event content (AI output text or hash where regulated, full confidence scores, override rationale text), full HITL review event content (reviewer identity, time-spent, full rationale), full disclosure-completion events, full admin-audit events at maximum fidelity, retained for the longest regulatory window with per-workflow log partitioning so Critical-tier workflow logs are partitioned from other tier logs. High: full decision and HITL events retained; standard admin-audit and identity events; core detections active. Medium: decision and HITL events with hashed content retained for the regulatory window; standard admin-audit; baseline detections active. Low: baseline logging schema only; workflow-config drift and shadow-AI detections only. For every Critical-tier workflow, the ML-Processes log store is the primary source for PC-Processes's compliance evidence bundle, completing inside the PC L2 staleness threshold (≤30 days). Retention-tier calibration reconciles with SM-Processes inventory tier changes within 14 days for Critical re-tiers and 30 days for other tiers.

B) SIEM integration and cross-workflow correlation. Ingest all tier-appropriate ML-Processes log feeds into the SIEM. Author and maintain at least three cross-workflow correlation rules: multi-workflow rubber-stamp correlation (the same reviewer exhibits rubber-stamp behavior, matches-AI ≥98%, on two or more Critical/High-tier workflows in the same rolling window, fires a unified incident); disclosure-suppression plus decision-outcome-shift (disclosure-suppression detection on a customer-facing flow correlates to a shift in that flow's decision distribution in the same time window, escalates to Critical regardless of workflow tier); shadow-AI-in-process plus admin-audit-gap (a shadow-AI-in-process detection correlates to a missing admin-audit event for a workflow-definition change in the same time window, signals a covert workflow modification). Cross-workflow correlation alerts route to IM-Processes at the tier of the highest-tier workflow involved with links to component-workflow findings to preserve triage context.

C) Detection tuning loop and anomaly baselines. Operate a quarterly detection review cycle. IM-Processes post-incident reviews that touch a logging or detection gap generate detection-update requests (new detection, tuned query, or retired false-positive rule). ST-Processes findings (HITL bypass test, disclosure rendering test, workflow-isolation test) that are not caught by the current detection set generate detection-gap findings routed to ML-Processes. External advisory updates (EU AI Act enforcement decisions, NYC LL 144 audit findings, EEOC bias enforcement relevant to decision pipelines, OECD AI incident disclosures) are assessed quarterly; each applicable update either adds a candidate detection or updates an existing detection's query. Monthly anomaly-baseline refresh for Critical and High-tier workflows: normal reviewer behavior baseline (decision-match rate, time-spent distribution, rationale length distribution) and decision-distribution baseline refreshed from the previous 30-day window; anomaly threshold auto-tunes to maintain target FP rate. Detections that have not fired a true positive in 90 days or exceed a 20% FP rate are reviewed for retirement at the quarterly cycle.

Outcome Metrics (L2).

Success Criteria.

• Tier-calibrated logging depth applied to 100% of SM-Processes inventory with current tier assignments; Critical-tier full event corpus retention confirmed; calibration auto-updated on re-tier within 14 days.
• SIEM integration live with ≥3 cross-workflow correlation rules active.
• Quarterly detection tuning loop operating from IM-Processes and ST-Processes feedback with ≥1 net change per cycle.
• ≥90% of Critical/High-tier workflows with anomaly-detection baselines refreshed monthly; FP rate tracked and trending down.
• ML logging-baseline validation element fresh (≤30 days) for all Critical-tier workflows in PC-Processes compliance evidence bundles.

Maturity Level 3

Objective: Express detections as code deployed through CI/CD; apply behavioral anomaly detection on reviewer and decision-distribution corpora; contribute anonymized detection signatures and telemetry schemas to OECD AI, ISO/IEC 42005, CSA AI Safety Initiative, and sector ISACs.

Activities.

A) Detection-as-code. Every detection in the set is a version-controlled, tested artifact in source control with detection query plus metadata (owner, SLA, archetype tag, HAI-TTP or ATLAS-tactic tag, FP threshold, last-test-result). A detection CI/CD pipeline triggers a test suite (unit tests over synthetic workflow log data, integration tests against a log replay environment) before production deployment. Detection deployment runs through the same change-management pipeline as workflow configuration; detection changes are reviewed, not applied ad hoc in the SIEM console. Detection coverage is automatically checked on SM-Processes inventory change events: when a new archetype is registered or a workflow is re-tiered to Critical, the automation verifies the required detection set is active and opens a gap finding within 24 hours if not.

B) Behavioral anomaly detection on workflow corpora. Apply unsupervised and semi-supervised anomaly models to the reviewer-behavior and decision-distribution corpora for Critical and High-tier workflows. Reviewer-behavior anomaly identifies reviewer sessions whose decision-pattern sequence (match rate, time-spent distribution, rationale frequency, override rate) is a statistical outlier from that reviewer's normal baseline and from the reviewer-pool baseline, signals reviewer fatigue, coercion, or systematic override manipulation. Decision-distribution anomaly identifies a rolling decision-outcome distribution that shifts beyond a defined threshold from the established baseline; for security-intersection cases where a bias-driven shift could constitute a gate-bypass or fairness-manipulation attack, fires a detection even without a specific prohibited-attribute signal. Disclosure-completion anomaly identifies per-execution disclosure completion rates dropping below baseline on a rolling time window, may indicate a rendering failure, a covert A/B-test suppression, or a workflow modification that removed the disclosure step. Knowledge-management RAG-behavior anomaly identifies retrieval patterns (document-id sequences, provenance chain distributions) that deviate from normal query behavior for a given role-class, a potential RAG-poisoning or unauthorized knowledge-base manipulation signal. Anomaly model outputs feed the same detection-to-IM-ticket pipeline as rule-based detections; anomaly severity is tagged to the workflow's tier. Anomaly models retrained monthly; retraining produces a new version in the model registry. Retraining excludes incident-period logs where reviewers were operating under audit pressure to avoid baseline poisoning.

C) Contribute detection signatures and telemetry schemas. Contribute AI/HAI workflow monitoring telemetry schema (decision event, HITL review event, disclosure-completion event, override audit event) to OECD AI governance as a candidate schema for cross-jurisdictional AI deployer-duty evidence standards. Contribute detection-pattern examples for rubber-stamp HITL, disclosure suppression, and shadow-AI-in-process from production telemetry to ISO/IEC 42005 AI incident management; target at least one detection pattern per cycle. Contribute anonymized detection signatures for workflow-specific AI risks (decision-distribution manipulation, HITL bypass, disclosure suppression) to the CSA AI Safety Initiative. Share anonymized, generalized detection signatures with sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups); target ≥12 signatures per year; signatures implementable by partner organizations without significant adaptation. Target ≥2 telemetry-standard contributions per year and ≥12 ISAC detection signatures per year; all contributions anonymized, legally vetted, and maintained, not point-in-time submissions.

Outcome Metrics (L3).

Success Criteria.

• ≥90% of detections expressed as version-controlled, CI/CD-deployed artifacts; detection coverage auto-verified for 100% of new or re-tiered SM-Processes inventory entries within 24 hours.
• ≥90% of Critical/High-tier workflows running behavioral anomaly detection on reviewer and decision-distribution corpora with monthly retraining and lineage tracking.
• ≥2 telemetry-standard contributions per year to OECD AI or equivalent; ≥12 anonymized detection signatures per year to sector ISACs.

Common Pitfalls

Level 1. - Logging baseline defined at the archetype level but actual production workflows never audited against it, gaps accumulate inside the SM-Processes inventory without appearing in any backlog. - HITL review events are logged at the queue-item-close level (item-id and timestamp only) rather than at the review-action level, rubber-stamp detection is architecturally impossible without the reviewer identity, AI suggestion, and time-spent fields. - Decision events capture the final decision but not the AI output and threshold, Art. 22 contestation evidence cannot show what the AI recommended vs. what the final decision was, and individual rights requests cannot be fulfilled. - Retention meets GDPR Art. 30 but not FCRA 25-month adverse-action record requirements for decision pipelines used in credit or employment contexts, evidence requests for those workflows cannot be satisfied.

Level 2. - Tier-calibrated logging configured at deployment time but not maintained, when a workflow is re-tiered from Medium to Critical, logging depth is not updated and full event corpora are absent for the first Critical-tier incident on that workflow. - SIEM correlation rules are built once and never validated, a rule that has not fired in 90 days may be broken rather than evidence that no correlatable events occurred. - Anomaly baselines established at onboarding and never refreshed, natural reviewer-population turnover makes the baseline stale and FP rates spike as new reviewers' behavior patterns differ from the original cohort. - Detection tuning loop exists on paper but IM and ST feedback never actually feeds into the review cycle, the same false-positive rubber-stamp detection remains in the set for years because the quarterly process has no dedicated owner.

Level 3. - Detection-as-code pipeline deployed but detection tests use synthetic data that does not resemble production workflow log patterns, tests pass in CI and detections fail silently in production. - Behavioral anomaly models retrained on full reviewer log corpus including incident-period logs where reviewers were operating under audit pressure, poisoned baseline, and the model learns to treat incident-period behavior patterns as normal. - Contributed telemetry schemas published as point-in-time artifacts and then diverge from internal practice, external adopters build against v1.0 while the org operates v1.3 internally. - ISAC detection signatures generalized to the point of uselessness, partner organizations cannot implement them without reconstructing the context removed for anonymization.

Practice Maturity Questions

Level 1. 1. Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each AI/HAI process archetype in the SM-Processes inventory (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), and has compliance of each production workflow been measured against it within the last quarter with ≥90% meeting the baseline? Evidence: published baseline; logging configuration audit cross-referenced against SM inventory. 2. Is a high-signal detection set of ≤12 detections active, each with a named owner, detection query, SLA, archetype tag, and last-tuned date, including rubber-stamp HITL, reviewer-capacity saturation, decision-distribution drift (security-intersection only), override-audit anomaly, disclosure suppression, affected-persons-rights-response SLA breach, shadow-AI-in-process, workflow-config drift, autonomous-action drift, knowledge-base poisoning canary, and content-generation policy violation, with false-positive rates tracked per detection and monthly tuning reviews occurring? Evidence: detection registry export; monthly tuning-review records; FP-rate trend per detection. 3. Has the evidence trail for EU AI Act Art. 14 human-oversight and Art. 12, GDPR Arts. 22 and 30, and ISO/IEC 42001 AIMS been wired to the ML-Processes log store with retention meeting the longest applicable regulation (including FCRA 25 months, FINRA 6 years, HIPAA 6 years where applicable), and has a quarterly deployer-duty drill confirmed that the evidence package for a randomly selected production workflow can be assembled within the ≤24-hour SLA? Evidence: documented wiring of log store to compliance requirements; quarterly drill records for the last 12 months with assembly times.

Level 2. 1. Is tier-calibrated logging depth applied per the SM-Processes L2 tier-treatment matrix, Critical-tier workflows retaining full decision and HITL event corpora at the longest regulatory window, Low-tier workflows receiving baseline only, and is this calibration automatically updated within 14 days when a workflow is re-tiered to Critical? Evidence: log-store retention audit × SM-Processes inventory tier assignments; re-tier auto-update log. 2. Is the SIEM ingesting ML-Processes log feeds with ≥3 cross-workflow correlation rules active (covering at minimum multi-workflow rubber-stamp correlation, disclosure-suppression plus decision-outcome-shift, and shadow-AI-in-process plus admin-audit-gap) and is a quarterly detection tuning cycle operating from IM-Processes post-incident and ST-Processes finding inputs? Evidence: SIEM rule registry; correlation-alert sample; quarterly detection change log. 3. Are ≥90% of Critical/High-tier workflows running anomaly-detection baselines refreshed monthly with FP rates tracked and trending down, and is the ML logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier workflows in PC-Processes compliance evidence bundles? Evidence: detection telemetry showing baseline-refresh cadence; FP-rate trend; PC-Processes compliance evidence bundle freshness report.

Level 3. 1. Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic workflow log data, and is detection coverage auto-verified for 100% of new or re-tiered SM-Processes inventory entries within 24 hours of the inventory change event? Evidence: detection registry × source control; CI test results; automation telemetry for inventory-change events. 2. Are ≥90% of Critical/High-tier workflows running behavioral anomaly detection on reviewer and decision-distribution corpora with anomaly models retrained monthly on production log data (excluding incident-period logs to avoid baseline poisoning), model versions tracked in the model registry, and anomaly-model alerts feeding the IM-Processes incident backlog through the same detection-to-ticket pipeline as rule-based detections? Evidence: anomaly model registry with monthly retraining records; lineage-tracking export; IM backlog showing anomaly-sourced tickets. 3. Has the program contributed ≥2 telemetry-standard artifacts per year to OECD AI, ISO/IEC 42005, or equivalent and ≥12 anonymized detection signatures per year to sector ISACs with contributions maintained current and external adoption tracked? Evidence: contribution log with submission dates, upstream adoption references, and maintenance records.

Part IV, Maturity Assessment Workbook

26. How the assessment works

Scope. A single assessment covers all 12 practices in the Processes domain, with 3 questions per maturity level per practice, 108 questions total. The assessment measures the organization's ability to secure the AI/HAI-embedded workflows it operates, decision pipelines, customer-facing flows, human-AI collaboration chains, back-office augmentation, approval/review workflows, content-generation workflows, and knowledge-management workflows. The unit of analysis is the workflow, not the model that powers it and not the application that delivers it.

Cumulative levels. Maturity levels are cumulative. A practice cannot be at Level 2 unless it is at Level 1; it cannot be at Level 3 unless it is at Level 2. Score Level 1 questions before answering Level 2 questions for the same practice. This is not optional, the gate is by design and exists because L2 capabilities depend on L1 capabilities for their inputs.

Answers. Each question accepts one of three answers: Yes (fully implemented, evidence-backed, sustained over time, requires an artifact, BPM/workflow telemetry pull, HITL audit record, FRIA on file, or process record the assessor has actually seen), Partial (partially implemented, or implemented but not sustained, or evidence is incomplete, counts as half credit), or No (not implemented, or implemented inconsistently to the point that no evidence supports it).

Evidence. Every "Yes" requires a citation in the Evidence box. "The process owner says so" is not evidence. "FRIA document dated Y for workflow W, override-audit query export from BPM tool Z covering the last 90 days, screenshot of HITL queue dashboard, LMS completion export for AI-in-Business-Process Policy attestation" is.

Honesty. The assessment is for the program, not for the assessor. A "No" honestly recorded is more useful than a "Yes" that does not survive auditor or regulator scrutiny, and AI-process gaps surface in regulatory action (EU AI Act Art. 26, GDPR Art. 22, FCRA, NYC LL 144) more directly than gaps in any other domain.

Cadence. Run the full assessment at least annually. Run a Level 1 self-check quarterly during the first year of program operation. Re-run on a per-workflow basis when an AI-embedded workflow is re-tiered to Critical or when an Annex III scope change occurs.

Roles. The assessment is led by the AI/HAI Process Assurance program lead working with the cross-functional working group that includes CISO and COO / Process Owner co-sponsorship, named Business Process Owners for each in-scope archetype, Privacy and Legal (DPO/CPO), Compliance, Internal Audit, AppSec, and operations management. The assessor should be independent of day-to-day program operations, Internal Audit, a peer assessor from another business unit, or an external assessor works best. The program lead should not assess their own program. Business Process Owners provide workflow evidence; Privacy/Legal provide FRIA and Art. 22 / Art. 50 evidence; Compliance and Internal Audit provide regulatory-mapping evidence; operations management provides HITL throughput and override telemetry.

Scope boundary. This assessment covers only Processes-domain practices. The same 12 practices applied to the Software, Data, Infrastructure, Vendors, and Endpoints domains are assessed in their own handbooks. Processes-domain answers must concern how the workflow is governed, designed, reviewed, tested, hardened, and monitored, not how the underlying model is trained, how the application is coded, or how the cloud account is configured. Where a workflow wraps a first-party application or a vendor service, the Processes assessment records joint-review handoffs but does not absorb those domains' questions.

27. Scoring methodology

Two scoring approaches are supported. Use the simplified scoring for self-assessments and quarterly check-ins. Use the precise scoring for formal audits, regulator-facing evidence packs, and external benchmarking.

Simplified scoring (recommended for self-assessment)

For each practice:

Level 1 achieved (all 3 Level 1 questions = Yes): 1.0 point
Level 2 achieved (all 3 Level 2 questions = Yes, AND Level 1 achieved): +1.0 (total 2.0)
Level 3 achieved (all 3 Level 3 questions = Yes, AND Level 2 achieved): +1.0 (total 3.0)

A "Partial" answer counts as half toward the level, but the level is only achieved when all three questions are at full Yes. Partial credit shows up in the precise score.

Precise scoring (recommended for formal audits)

For each practice, with Y = Yes (1.0), P = Partial (0.5), N = No (0):

L1_score = (sum of L1 answers) / 3
L2_score = (sum of L2 answers) / 3 × L1_score
L3_score = (sum of L3 answers) / 3 × L2_score

Practice Score = L1_score + L2_score + L3_score    (max 3.0)

The L2 and L3 multipliers enforce the cumulative rule, a practice cannot earn full L2 credit if L1 is incomplete. The Processes domain is especially sensitive to this gate because L2 capabilities (per-workflow deep threat models, FRIA-bundle continuous attestation, HITL substantiveness probes, decision-log integrity verification) all consume L1 outputs (inventory, archetype models, base requirements pack, base playbook) as their authoritative inputs.

Domain rollup.

Domain Maturity = (sum of all 12 Practice Scores) / 12    (max 3.0)

Maturity bands.

• 0.0 – 0.9, Ad-hoc. No AI/HAI Process Assurance program in operational use; AI-embedded workflows operate without inventory, oversight design, or FRIA.
• 1.0 – 1.9, Foundational. L1 in place across most practices; inventory and intake gate operational; archetype threat models and base requirements pack published; HITL standards declared; some L2 progress.
• 2.0 – 2.9, Comprehensive. L2 calibrated by risk tier across most practices; FRIA gate operational for Annex III workflows; per-workflow deep threat models for Critical; HITL substantiveness probes running; some L3 contributions.
• 3.0, Industry-Leading. L3 automation, benchmarking, and ecosystem contribution sustained across all practices.

Worked example, precise scoring

Suppose the DR-Processes practice scores as follows:

L1_score = 2.5 / 3 = 0.833
L2_score = (1.5 / 3) × 0.833 = 0.500 × 0.833 = 0.417
L3_score = (0.0 / 3) × 0.417 = 0.0

DR Practice Score = 0.833 + 0.417 + 0.0 = 1.25 / 3.0

Interpretation: the practice is solidly in the Foundational band, with a partial L2 story. The per-archetype design checklists and DR decision records exist; the IM-to-DR feedback loop is incomplete (the L1 Q3 Partial); scenario-based walkthroughs for Critical workflows are in place but FRIA workshops are not consistently linked to DR decisions, and design-drift detection has not been operationalized. The cumulative multiplier correctly suppresses L2 credit because L1 is not complete.

28. The questionnaire

The 108 questions follow. Each question has the same workbook layout: question text, answer field, evidence box, and notes box. Practice and level headings are repeated so the workbook is usable as a printout or as a standalone assessment instrument. Every question asks about securing the AI-embedded workflow itself, its governance, design, oversight, testing, hardening, monitoring, and incident handling, not about the security of the AI components the workflow uses.

28.1 Strategy & Metrics (SM)

SM Level 1.

Q-SM-L1-1. Is there a published AI/HAI Process Assurance program charter with a named executive sponsor (CISO co-sponsored by COO / Chief Risk Officer / General Counsel / DPO), a cross-functional working group spanning Security, Privacy/Legal, Compliance, Internal Audit, and named Business Process Owners across all major business functions, and clear decision rights for approving, blocking, sanctioning, and granting exceptions to AI-embedded workflows, with an explicit amnesty path publicized to function heads?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L1-2. Does a single AI/HAI process inventory exist, seeded from function-by-function surveys, BPM/RPA/ticketing-system signals, internal wiki and handbook search, CX-platform configuration review, and vendor-contract review, covering all seven Processes-domain archetypes (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), with ≥85% coverage of discovered AI-embedded workflows within 12 months and per-workflow tier, archetype, and deployer-duty owner fields populated?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L1-3. Are the L1 outcome metrics baselined and reported quarterly to the executive sponsor, inventory coverage (≥85%), shadow-AI-in-processes ratio (≤20% and trending down), AI-in-Business-Process Policy attestation coverage (≥90% of function heads and process owners), workflows with named owning team and documented HITL model (100% for decision-affecting and customer-facing), and known compliance events from AI-embedded workflows?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SM Level 2.

Q-SM-L2-1. Is every AI-embedded workflow in the inventory assigned a risk tier based on an auditable rubric covering decision-affecting effect (EU AI Act Annex III / GDPR Art. 22), customer reach, reversibility of the AI-driven action, human-oversight depth, regulatory scope, data classes processed, and business criticality, with tier rationale recorded and re-tier triggers defined?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L2-2. Is there a published tier-treatment matrix driving differential program intensity across PC, TA, SR, SA, DR, IR, ST, EH, ML, and IM, including substantive HITL standards assessment, deep TA, full SR pack, and full-lane DR for Critical-tier, with ≥95% of Critical-tier workflows receiving full-scope treatment in the last 12 months and a functional FRIA gate for all EU AI Act Annex III workflows?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L2-3. Does the quarterly shadow-AI-in-processes scoreboard report per tier and per archetype, with Critical-tier unsanctioned AI-embedded workflows explicitly tracked at zero, and does tier-movement get logged with rationale and reviewed by the program sponsor, with each Critical re-tier triggering downstream IM/IR/ML reconfiguration within 14 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SM Level 3.

Q-SM-L3-1. Does inventory and tier assignment auto-update from workflow-execution telemetry (BPM events, RPA logs, ticketing-system AI-routing events, CX-platform AI events, HITL queue events) with a published data-quality SLO, and is ≥75% of curation handled automatically with exception-based human review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L3-2. Does the program publish a semi-annual external-benchmarking brief comparing the program against at least five peer-comparable metrics from APQC, BPM-community AI-governance bodies, sector ISACs, and FinAI / HR-AI / ClinAI working groups, and does it drive program investment decisions?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SM-L3-3. Does the program contribute at least four substantive, anonymized artifacts per year to the AI/HAI process-governance ecosystem (ISO/IEC 42005, OECD AI guidance, sector deployment-officer pathways, BPM AI-governance frameworks, CSA AI Safety Initiative, ISO/IEC 42001 AIMS community), and does the executive/board ROI narrative cite external benchmarks?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.2 Policy & Compliance (PC)

PC Level 1.

Q-PC-L1-1. Have the three priority AI/HAI process policies been published and formally approved, 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, and is there a one-page priority compliance map tracing each requirement (EU AI Act Arts. 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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L1-2. Is the intake / sanction 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-tier)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L1-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

PC Level 2.

Q-PC-L2-1. Have the three priority policies been extended with tier-specific addenda, 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, review-time data, decision-variance audit) in a live compliance evidence bundle covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, and deployer-duty record?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L2-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L2-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 LL 144 / CO SB-21-169 / HIPAA / FINRA / EEOC as applicable) complete for in-scope workflows?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

PC Level 3.

Q-PC-L3-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 attestation currency ≤24 hours latency and ≤3 BD on-demand evidence pack generation, and is ≥99% of Critical/High workflows continuously attested?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L3-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, and are EG-Processes training materials updated within 30 days of any policy change?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-PC-L3-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.3 Education & Guidance (EG)

EG Level 1.

Q-EG-L1-1. Have all process owners, product managers, operations managers, and business analysts touching AI-embedded workflows completed a current-year AI-process literacy course covering the seven workflow archetypes, EU AI Act Art. 26 deployer duties / Art. 14 human oversight / Art. 50 transparency, GDPR Art. 22 automated-decisioning safeguards, HITL design (substantive vs. rubber-stamp), recognition of Annex III FRIA triggers, and the intake gate process, with ≥90% completion and content updated within 30 days of any policy or archetype change?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L1-2. Has the practitioner population (AppSec reviewers, Privacy/Legal counsel, Compliance officers, Internal Audit, business-unit review representatives) completed role-based training covering workflow-archetype threat walkthrough, FRIA composition for Annex III use categories, HITL design assessment (substantive review SLA, override-rate targets, anchoring-prevention criteria), Art. 22 lawful-basis analysis, fairness/bias-at-compliance-intersection indicators, and sector-specific deep-dives (HR-AI, FinAI, ClinAI), with completion gated on intake-approval permissions and calibration drift ≤1 tier step and ≤2 FRIA/HITL mismatches per sample for two consecutive quarters?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L1-3. Is a shadow-AI-in-processes awareness campaign running with at least monthly content, a visible amnesty path linked from the AI-in-Business-Process Policy and intake form, and measurable attribution of intake submissions and amnesty disclosures to campaign channels, with disclosures rising in Q1–Q2 after launch then declining as the sanctioned-workflow program grows?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EG Level 2.

Q-EG-L2-1. Is there a scenario library of ≥25 anonymized real intake cases powering practitioner training across the org's in-scope workflow archetypes, with paired calibration exercises showing Critical-tier drift ≤1 tier step and ≤1 FRIA/HITL mismatch per sample for two consecutive quarters?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L2-2. Have sector-specific tracks (HR-AI, FinAI, ClinAI as applicable) been delivered to ≥1 practitioner per Critical/High-tier workflow in each applicable sector, with team-level training coverage tracked in the SM-Processes inventory, and are awareness campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L2-3. Is ≥80% of training content updated in the last 90 days, including FRIA methodology, HITL design rubric, and sector-specific compliance content, and are ≥70% of campaigns hitting their pre-set behavior target?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EG Level 3.

Q-EG-L3-1. Has the practitioner curriculum, anonymized scenario library, FRIA methodology guide (for each Annex III use category), and HITL design reviewer rubric been published externally (CSA, ISO/IEC 42005 community, OECD, or sector ISAC) with documented adoption, citations, standards-body reference, or direct acknowledgment, and do contributions loop back into internal content within 30 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L3-2. Is a monthly live calibration cadence operating (anonymized intake from the live queue, independent reviewer scoring, drift reported to sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier reviewers hold an external AI-deployment-officer or AI-process-governance credential where one exists?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EG-L3-3. Does the program contribute ≥2 substantive artifacts per year to industry AI-process certification or curriculum working groups, and ≥1 FRIA methodology or HITL design contribution to ISO/IEC 42005 or OECD per year where real-world experience from the org's own FRIA and HITL practice justifies a contribution?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.4 Threat Assessment (TA)

TA Level 1.

Q-TA-L1-1. Are published, versioned threat models in place for all seven AI/HAI workflow archetypes (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), each mapping archetype-specific threats to HAI TTPs (EA / AGH / TM / RA), ATLAS tactic IDs, OWASP LLM/Agentic Top 10 references, and PC-Processes compliance items, with a named library steward and a documented quarterly refresh cadence?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L1-2. Does every AI/HAI-embedded workflow entering the SM inventory receive a threat snapshot (delivered within one business day of intake) that documents the applicable archetype(s), workflow-specific deltas (decision stakes, HITL placement, data classes, regulatory exposure, downstream systems), top-5 threats with HAI TTP tags and ATLAS tactic IDs, and gaps for SR/SA follow-up, with 100% of newly Sanctioned workflows carrying a snapshot in the last 90 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L1-3. Is there a published shadow-AI-in-processes threat view, reviewed by the program sponsor in the last 12 months, that documents entry vectors, elevated threat scenarios for unsanctioned AI-embedded workflows, and the specific detections (from SM discovery sources) used to surface them?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

TA Level 2.

Q-TA-L2-1. Does every Critical-tier AI/HAI-embedded workflow have a current-year per-workflow deep threat model (not an archetype snapshot) covering workflow-specific attack trees, an abuse-case catalog, deployer-duty mapping, and a full ATLAS tactic walk with technique-level specificity, with a semi-annual refresh cadence and change-driven updates on HITL restructuring, AI model swap, or scope change?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L2-2. Is external AI-security threat intelligence (MITRE ATLAS updates, AVID, sector ISACs, regulatory enforcement actions on Art. 22 / FCRA / NYC LL 144 type matters) integrated with a quarterly triage cadence and a documented change-log, with intel-to-library update ≤30 days on Critical-impact items?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L2-3. Does the program run a quarterly red-team-the-library exercise that probes an in-scope AI/HAI-embedded workflow using only library threats and surfaces misses as library gaps, with every gap carrying a named owner and an expiry date, Critical gaps closing within 30 days, and the gap rate trending down quarter over quarter?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

TA Level 3.

Q-TA-L3-1. Does the threat library auto-update from telemetry (ML-Processes detections, IM-Processes incidents) and external feeds (ATLAS, AVID, sector ISACs, regulatory actions) via a human-curated auto-proposal pipeline, with ≥60% of changes auto-proposed, a ≤14-day lead time from signal to update, and a machine-readable change-log consumed by downstream SR and ST practices?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L3-2. Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS / AVID / sector ISACs / ISO / OECD AI, with at least two externally recognized in published advisory, standard revision, or ATLAS merge?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-TA-L3-3. Are anonymized workflow-archetype threat models published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year (ATLAS practitioner table, sector ISAC AI working group, or OWASP AI chapter) tied to the library?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.5 Security Requirements (SR)

SR Level 1.

Q-SR-L1-1. Is there a published, versioned AI/HAI Workflow Requirements Pack containing a base set (≤20 requirements) plus seven per-archetype deltas, with every requirement tagged to at least one TA-Processes archetype threat and one PC-Processes priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per workflow at intake?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L1-2. Do 100% of new AI/HAI-embedded workflows approved in the last 90 days have a completed Requirements-Evidence Map (REM) on file, with every applicable requirement marked Met / Met-with-compensating-control / Gap-accepted / Not-applicable, each Met row citing specific verifiable evidence, each Gap-accepted row naming a compensating control with owner and re-review date, and workflow REMs cross-referencing the underlying Software, Data, and Infrastructure component REMs?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L1-3. Is the pack on a quarterly refresh cadence with a named owner, and are SA, DR, IR, and ST practices citing REM rows rather than independently re-deriving requirements from scratch?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SR Level 2.

Q-SR-L2-1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (review queue depth, kill-switch response time, drift-detection threshold, log-retention days) and binary state (Art. 22 lawful basis documented, DPIA/FRIA current, override audit trail confirmed, Art. 50 disclosure tested) specified, and has all qualitative "reasonable" and "appropriate" language been removed from the pack?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L2-2. Are ≥95% of Critical-tier workflow REMs re-validated against observed reality (decision-log volume, HITL queue metrics, kill-switch test, Art. 50 disclosure test, override audit sample) in the last 90 days, with validation deltas routed to IM-Processes and no Critical-tier accepted gap aging beyond 60 days without documented escalation to the program sponsor?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L2-3. Do 100% of Critical-tier workflows carry a full EU AI Act Art. 26 deployer-duty checklist and current DPIA/FRIA evidence in their REM with verifiable evidence (not process-owner assertion alone), and is the per-tier pack overlay enforced at SM intake, with Critical-tier workflows receiving full depth and Low-tier workflows receiving base pack only?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SR Level 3.

Q-SR-L3-1. Is the AI/HAI Workflow Requirements Pack expressed in a machine-readable schema and monitored via workflow-execution attestation, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier workflows operating with failing REM checks undetected, and the schema published under a permissive license with tracked external adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L3-2. Are ≥70% of REM evidence rows auto-validated via workflow monitoring (ML-Processes), incident feeds (IM-Processes), and SM inventory change events, with automation error-rate monitored and human review reserved for exceptions, novel clauses, and accepted-gap escalations?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SR-L3-3. Does the program contribute at least two substantive artifacts per year (machine-readable requirement schema, REM schema, process requirement clauses) to recognized standards bodies (ISO/IEC 42005, OECD AI, sector standards, NIST AI RMF Playbook), with contributions publicly documented and traceable to adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.6 Secure Architecture (SA)

SA Level 1.

Q-SA-L1-1. Are seven reference patterns published, one per archetype (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), each with a labeled workflow diagram, oversight design, disclosure mechanism, logging spec, and explicit row-by-row mapping to SR-Processes requirements and TA-Processes threats with HAI TTP tags and applicable MITRE ATLAS mitigation IDs, accessible within one click of the SM inventory record?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L1-2. Are 100% of customer-facing AI workflows verified (via IR spot-check, not only policy declaration) to place Art. 50 disclosure at the point of first AI interaction, and is the anti-pattern catalog linked from the AI-in-Business-Process Policy, the SM intake gate, and EG-Processes training, with each entry tied to the real-incident pattern that generated it (rubber-stamp HITL, post-hoc disclosure, missing kill-switch, override-without-rationale, unbounded HITL queue)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L1-3. Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA ownership, and are ≥85% of active AI/HAI-embedded workflows in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SA Level 2.

Q-SA-L2-1. Are the tier-conditional extended patterns (Critical overlay, High overlay, sector-specific overlays for HR / Fin / Clin, multi-region, HITL-capacity auto-throttle) published as forkable workflow templates with conformance test suites, and are ≥80% of Critical and High-tier AI/HAI-embedded workflows running on template-encoded patterns as confirmed by the workflow orchestrator and SM inventory registries?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L2-2. Has the anti-pattern catalog been updated from ≥3 real IM-Processes incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and is conformance testing covering 100% of template-encoded workflow deployments with findings tracked to resolution?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L2-3. Are 100% of Critical-tier workflows carrying explicit EU AI Act Art. 9 and Art. 15 control mappings in the pattern documentation, and does the HITL-capacity auto-throttle pattern enforce queue capping in the workflow orchestrator definition (not only in policy), verified by conformance test?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

SA Level 3.

Q-SA-L3-1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry or sector body, and have ≥2 of those patterns been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L3-2. Have ≥2 contributions been accepted to the MITRE ATLAS mitigation library or ISO/IEC 42005 community guidance, traceable to specific SA-Processes pattern controls, and is there an active contribution cadence (at least one contribution or validation per 6 months)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-SA-L3-3. Is there at least one documented reference to SA-Processes patterns in a regulatory implementing-act, sector guidance document, or published standards text, and is the regulatory engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.7 Design Review (DR)

DR Level 1.

Q-DR-L1-1. Is there a published, versioned per-archetype AI-Embedded Workflow Design Checklist, one per SM-Processes archetype, covering the common spine (HITL placement and depth, Art. 50 disclosure design, decision logging, override audit trail, output-integrity SLA, reviewer-capacity gating, affected-persons rights surface, DPIA/FRIA status, fallback/kill-switch) plus archetype-specific items, and traceable to the applicable SA pattern, SR requirements pack, and TA threat snapshot?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L1-2. Do ≥95% of AI-embedded workflows going live in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back), with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Processes L1, Privacy and Legal participation for full-lane reviews, and 100% of Annex III / Art. 22 workflows including FRIA / DPIA status with a named owner in the record?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L1-3. Are recurring pattern deviations and repeatedly-waived SR requirements automatically queuing SA pattern-update and SR pack-update reviews, and does every IM-Processes incident trigger a re-examination of the DR record that approved the affected workflow?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

DR Level 2.

Q-DR-L2-1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat or compliance scenarios sourced from TA-Processes per-workflow deep models and anonymized IM-Processes incidents, with the DR decision tied explicitly to how the proposed workflow design handles each scenario rather than checklist conformance alone?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L2-2. Do 100% of Annex III workflows receive a completed FRIA workshop before go-live, with the workshop output linked from the DR decision record and the SM-Processes inventory, and is design-drift detection running quarterly for Critical-tier and annually for High-tier, with 100% of material drifts automatically re-routed to DR for a new review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L2-3. Are joint DR-Processes / DR-Software (and DR-Vendors where the workflow wraps a vendor AI service) review records on file for 100% of Critical-tier workflows, with an explicit handoff boundary and shared residual-risk ownership documented in both DR records?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

DR Level 3.

Q-DR-L3-1. Are ≥90% of Critical-tier AI-embedded workflows producing a daily automated attestation signal, covering HITL gate health, decision-logging completeness, Art. 50 disclosure presence, override-audit freshness, and fallback readiness, with deviations auto-opening DR-exception tickets triaged within 3 business days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L3-2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, FRIA workshop frameworks, scenario templates) to OECD AI, ISO/IEC 42005, or applicable sector bodies, with documented adoption and internal practice aligned to the published versions?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-DR-L3-3. Is there a quarterly pattern-evolution review driven by external signals (OECD AI guidance, ISO/IEC 42005 updates, Annex III changes, sector regulatory AI guidance) and internal signals (IM-Processes incidents, ML-Processes telemetry, ST-Processes findings), with a versioned change log and notification to in-flight DR reviews affected by pattern changes?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.8 Implementation Review (IR)

IR Level 1.

Q-IR-L1-1. Is there a published, per-archetype IR checklist, one per SM-Processes archetype, 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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L1-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L1-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IR Level 2.

Q-IR-L2-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L2-2. Are HITL substantiveness probes completed monthly for Critical-tier and quarterly for High-tier, including decision-variance audits (escalation if ≥98% match rate between AI recommendation and reviewer outcome) 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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L2-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IR Level 3.

Q-IR-L3-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L3-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?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IR-L3-3. Is the post-incident IR feedback loop operational, with IM-Processes post-incident reviews including a mandatory IR-record re-examination step, and ≥1 attestation rule update produced per material incident, ensuring incident learning continuously improves the attestation coverage?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.9 Security Testing (ST)

ST Level 1.

Q-ST-L1-1. Is a per-archetype foundational test battery published for all seven AI-embedded workflow archetypes, with each test class tied to a TA-Processes archetype threat (HAI TTP + ATLAS tactic ID where applicable) and an SR-Processes requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact, and are 100% of new AI-embedded workflows required to pass the battery before production Sanctioned status is issued?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L1-2. Are six regression corpora (adversarial-decision, rubber-stamp-detection, content-generation-safety, RAG-poisoning, Art. 50 disclosure-presence, class-shift detection) versioned in source control with named corpus owners, a monthly refresh cadence, and budget-capped CI runs, and are Critical/High-tier workflows verified to have run and passed the applicable corpus before go-live?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L1-3. Are all test failures routed to IM-Processes within 1 business day with a severity tag and named owner, and does TA-Processes archetype threat coverage by the test battery and corpus reach ≥80% by end of year one?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ST Level 2.

Q-ST-L2-1. Are 100% of Critical-tier AI-embedded workflows red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Processes L2 per-workflow deep threat models, covering adversarial-decision inputs, rubber-stamp induction, disclosure-bypass techniques, RAG-poisoning paths, class-shift induction, downstream injection via generated content, and HITL-saturation attacks, with findings routed to IM-Processes and remediation tracked?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L2-2. Is per-tier corpus calibration enforced (Critical-tier: all 6 corpora plus monthly rubber-stamp audit and quarterly class-shift verification; Low-tier: disclosure-presence corpus), and are ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L2-3. Are cross-archetype composition tests (decision pipeline + customer-facing flow, back-office content generation + downstream injection surface, knowledge-management + decision pipeline) documented and executed for all Critical-tier composite workflows, and is per-tier SLA adherence for testing activities ≥90%?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ST Level 3.

Q-ST-L3-1. Are ≥80% of Critical-tier AI-embedded workflows under continuous canary-input testing with daily probe execution, covering adversarial-decision, rubber-stamp-induction, disclosure-bypass, and RAG-poisoning canaries, with novel process-level TTPs triaged into the TA-Processes library within 14 days and high-severity canary findings routed to IM-Processes within 24 hours?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L3-2. Has the program contributed ≥4 anonymized, legally-vetted findings per year to MITRE ATLAS (process-level), sector ISACs, or OECD AI, with at least one accepted as a new or refined technique or advisory, and are ≥6 open regression corpora published under a permissive license and maintained upstream?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ST-L3-3. Has the program hosted at least 1 industry-shared adversarial-workflow exercise per year and participated in ≥2 additional cross-org exercises, with documented cross-org adversarial-workflow detection data from participants?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.10 Environment Hardening (EH)

EH Level 1.

Q-EH-L1-1. Does every AI/HAI-embedded workflow in the SM-Processes inventory (across all seven archetypes) run against a signed, version-controlled workflow definition, with peer review enforced for all AI-step changes and DR re-review triggered for material changes, and are all HITL review UIs requiring SSO + MFA with reviewer identities individually attributable?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L1-2. Are Art. 50 disclosure templates managed exclusively in a central registry with no unregistered templates deployed in production, is disclosure-suppression detection (A/B-test registration requirement and traffic-split alerting) active, and are contestation-response SLAs under GDPR Art. 22 monitored with escalation alerts for at-risk workflows?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L1-3. Is classification-aware routing enforced at workflow ingress (preventing regulated PII from reaching uncleared AI steps), is a PII redaction layer active where required, and are immutable decision logs and tamper-evident override audit trails active for all Critical/High-tier workflows with retention meeting the longest applicable regulation?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EH Level 2.

Q-EH-L2-1. Are 100% of Critical-tier workflow-definition changes executed under JIT access (≤4-hour time-limited, approval-gated, with automatic revocation at expiry), with no standing write access for Critical-tier definitions, and are dedicated reviewer pools operational for all Critical-tier HITL steps with capacity monitoring, SLA-at-risk alerting, and cross-tier queue-bleed enforcement?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L2-2. Is a hardening tier-treatment matrix published and enforced per SM-Processes L2 risk tiers, are Critical-tier decision log integrity verification jobs running weekly with results recorded as compliance evidence, and does the per-execution disclosure-completion metric for Critical-tier customer-facing flows maintain 100% completion with deviations routing to IM-Processes within 4 hours?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L2-3. Are HITL rubber-stamping rates trending down for Critical-tier workflows after dedicated-reviewer-pool and capacity-monitoring activation, is enhanced override-authority enforcement (mandatory rationale, repeated-no-rationale escalation) active for Critical-tier, and are per-tenant runtime isolation controls operational for Critical-tier multi-tenant customer-facing flows confirmed by IR-Processes reviews and ST-Processes isolation tests?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

EH Level 3.

Q-EH-L3-1. Are ≥90% of EH-Processes controls expressed as authoritative IaC or workflow-as-code (not stubs) in a version-controlled registry, with drift detected on a scheduled cadence, ≥70% of low-risk drift auto-remediated, and high-risk drift (JIT policy removed, disclosure template suppressed, log integrity disabled) human-reviewed within 2 business days, and are new AI/HAI-embedded workflows auto-provisioned with tier-appropriate hardening within 24 hours of SM-Processes inventory registration?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L3-2. Is the adaptive-policy pipeline operational, with ML-Processes detections (rubber-stamp HITL, disclosure suppression, shadow-AI-in-process) and IM-Processes incident patterns generating human-approved tightening proposals on a tracked cadence, every change traceable to a source signal, and affected workflow teams notified within 24 hours of a tightening change?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-EH-L3-3. Does the program contribute ≥2 AI/HAI workflow hardening baselines per year to industry bodies (OECD AI governance, ISO/IEC 42005, CSA AI Safety Initiative, sector ISACs) with documented adoption, and are these contributions maintained current with internal practice rather than published once and left to diverge?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.11 Issue Management (IM)

IM Level 1.

Q-IM-L1-1. Is there a single AI/HAI workflow issue backlog with standardized metadata (source, affected workflow linked to SM-Processes inventory, severity rubric anchored to AI-specific axes, wrongful automated decision / HITL failure / disclosure failure / regulated-data breach for Critical; confirmed control failure with potential impact for High; and so on, owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA, SR, DR, IR, ST, ML, external)?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L1-2. Is the AI/HAI workflow incident playbook published with seven named AI-specific workflow incident classes (wrongful-decision containment, HITL failure / rubber-stamp, disclosure failure, class-shift / fairness at the security intersection, content-generation harmful output, knowledge-management RAG-poisoning, shadow-AI-in-process), each with pre-assigned roles, containment plays (HITL-step pause, RAG-corpus quarantine, disclosure-template rollback, workflow kill-switch), evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L1-3. Is the regulatory SLA tracker live covering GDPR Arts. 22 / 33 (72h), EU AI Act Arts. 26.5 / 50 / 73, HIPAA, FCRA adverse-action, FINRA model-risk, NYC LL 144, CO SB-21-169, and sector-specific obligations, with 100% adherence in the last 90 days, and does every Critical / blocker incident produce a post-incident review within 14 days with named update outputs flowing to SA, SR, EG, and ML?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IM Level 2.

Q-IM-L2-1. Is a tier-calibrated incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier workflow briefing, and tier-movement in the SM-Processes inventory automatically triggering IM configuration updates (on-call path, playbook variant, SLA targets) within 14 days of a Critical re-tier event?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L2-2. Is a post-incident review auto-flow integration live, routing Critical-tier review outputs to SA / SR / EG / ML practice backlogs, with ≥90% of downstream practice owners responding within 14 days, and the sponsor reviewing output quality quarterly to distinguish substantive changes from nominal acknowledgements?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L2-3. Is a cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI workflow incidents, with named cross-domain contacts for Software, Data, and Vendors domains verified quarterly, a single Incident Commander from the primary impacted domain, and joint post-incident reviews spanning all affected domains?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

IM Level 3.

Q-IM-L3-1. Does the program contribute ≥4 anonymized AI workflow incident-classification entries per year to sector ISACs and ≥2 contributions per year to OECD AI, ISO/IEC 42005, or CSA AI Safety Initiative, with all contributions maintained current, legally vetted, and tracked for external adoption?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L3-2. Are ≥3 pre-authorized automated containment actions live (HITL-step pause, RAG-corpus quarantine, shadow-AI-step freeze, or disclosure-template rollback classes), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets on execution, with the pre-authorization policy reviewed quarterly and any unexpected outcome triggering an out-of-cycle review?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-IM-L3-3. Is a quarterly MTTR benchmark brief published to the sponsor, comparing the program's MTTR per incident class and per tier against ISAC-sourced and peer-sourced benchmarks, with Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes and deltas above benchmark linked to specific practice gaps and investment proposals?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

28.12 Monitoring & Logging (ML)

ML Level 1.

Q-ML-L1-1. Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each AI/HAI process archetype in the SM-Processes inventory (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), and has compliance of each production workflow been measured against it within the last quarter?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L1-2. Is a high-signal detection set of ≤12 detections active, each with a named owner, detection query, SLA, archetype tag, and last-tuned date, including rubber-stamp HITL detection, reviewer-capacity saturation, decision-distribution drift (security-intersection only), override-audit anomaly, disclosure-suppression, affected-persons rights-response SLA breach, shadow-AI-in-process emergence, and workflow-config drift, with false-positive rates tracked per detection and monthly tuning reviews occurring?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L1-3. Has the evidence trail for EU AI Act Art. 12, GDPR Arts. 22 and 30, and ISO/IEC 42001 AIMS been wired to the ML-Processes log store with retention meeting the longest applicable regulation (including FCRA 25 months, FINRA 6 years, HIPAA 6 years where applicable), and has a quarterly deployer-duty drill confirmed that the evidence package for a randomly selected production workflow can be assembled within the ≤24-hour SLA?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ML Level 2.

Q-ML-L2-1. Is tier-calibrated logging depth applied per the SM-Processes L2 tier-treatment matrix, Critical-tier workflows retaining full decision and HITL event corpora at the longest regulatory window, Low-tier workflows receiving baseline only, and is this calibration automatically updated when a workflow is re-tiered?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L2-2. Is the SIEM ingesting ML-Processes log feeds with ≥3 cross-workflow correlation rules active (covering at minimum multi-workflow rubber-stamp correlation, disclosure-suppression plus decision-outcome-shift, and shadow-AI-in-process plus admin-audit-gap), and is a quarterly detection tuning cycle operating from IM-Processes post-incident and ST-Processes finding inputs?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L2-3. Are ≥90% of Critical/High-tier workflows running behavioral anomaly-detection baselines with reviewer-behavior and decision-distribution profiles refreshed monthly and FP rates tracked and trending down, and is the ML logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier workflows in PC-Processes compliance evidence bundles?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

ML Level 3.

Q-ML-L3-1. Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic workflow log data, and is detection coverage auto-verified for 100% of new or re-tiered SM-Processes inventory entries within 24 hours of the inventory change event?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L3-2. Are ≥90% of Critical/High-tier workflows running behavioral anomaly detection on reviewer and decision-distribution corpora, with anomaly models retrained monthly, model versions tracked in the model registry, and anomaly-model alerts feeding the IM-Processes incident backlog through the same detection-to-ticket pipeline as rule-based detections?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

Q-ML-L3-3. Has the program contributed ≥2 telemetry-standard artifacts per year to OECD AI, ISO/IEC 42005, or equivalent and ≥12 anonymized detection signatures per year to sector ISACs, and has it proposed or validated ≥2 process-level MITRE ATLAS detection-mitigation entries, with contributions maintained current and external adoption tracked?

Answer: ☐ Yes ☐ Partial ☐ No Evidence: _______ Notes: _________

29. Practice-level rollup

After completing all 108 questions, fill in the table below. For each practice, count Yes (Y), Partial (P), and No (N) answers per level. Compute the precise score as described in Section 27: L1_score = (Y + 0.5P) / 3; L2_score = (Y + 0.5P) / 3 × L1_score; L3_score = (Y + 0.5P) / 3 × L2_score; Practice Score = L1_score + L2_score + L3_score.

Worked example

The assessment team answers for DR-Processes: L1 Q1 = Y, L1 Q2 = Y, L1 Q3 = P; L2 Q1 = Y, L2 Q2 = P, L2 Q3 = N; L3 all N.

L1_score = (1.0 + 1.0 + 0.5) / 3 = 0.833
L2_score = (1.0 + 0.5 + 0.0) / 3 × 0.833 = 0.417
L3_score = 0.0

DR Practice Score = 0.833 + 0.417 + 0.0 = 1.25 / 3.0

Interpretation: DR-Processes scored L1 = 0.83, L2 = 0.42, L3 = 0.0, yielding a practice maturity of 1.25, solidly Foundational with partial L2. The per-archetype design checklists and DR decision records exist; the IM-to-DR feedback loop is incomplete (L1 Q3 Partial); scenario-based walkthroughs for Critical workflows have started, but FRIA workshops are not consistently linked to DR decisions for Annex III workflows (L2 Q2 Partial) and the joint Processes/Software DR records are not yet routine (L2 Q3 No). Roadmap priority: close the IM-to-DR feedback loop (closes the L1 Partial), wire FRIA workshop outputs into DR records for Annex III (L2 Q2), establish the joint review protocol with the Software domain (L2 Q3). L3 work is premature.

Notes column for assessor. Use the space below to record per-practice observations: which questions were hardest to answer, where evidence was thin, where Partial answers cluster, and what the most actionable next step is.

SM: _________ PC: _________ EG: _________ TA: _________ SR: _________ SA: _________ DR: _________ IR: _________ ST: _________ EH: _________ IM: _________ ML: _________

30. Domain-level rollup

Domain Maturity = (sum of all 12 Practice Scores) / 12 = ____ / 3.0

Maturity band achieved: ☐ Ad-hoc (0.0–0.9) ☐ Foundational (1.0–1.9) ☐ Comprehensive (2.0–2.9) ☐ Industry-Leading (3.0)

Per-Business-Function rollup

A domain is mature when all four Business Functions are at the same band. A Processes domain whose Operations function trails the others has designed and reviewed workflows well but cannot run them under regulatory scrutiny. A Processes domain whose Verification function trails Building has approved workflow designs that no one can prove actually operate as designed in production, the most common cause of a failed deployer-duty audit. The most common pattern in early-stage Processes programs is Governance ahead of Building, and both well ahead of Verification and Operations, because the AI-in-Business-Process Policy and an intake gate are easier to publish than HITL substantiveness probes are to operate and decision-log retention is to maintain across regulatory windows.

Worked example, domain-level rollup

The following shows a plausible result for an organization 18 months into its Processes-domain program.

Domain Maturity = 14.92 / 12 = 1.24 / 3.0

Band: Foundational. This organization has crossed L1 across most practices but has not yet closed L2 for any practice. The Operations function is weakest (EH 0.83, ML 0.75 both sub-Foundational), which is typical for Processes-domain programs because workflow hardening (immutable decision logs, dedicated reviewer pools, disclosure-template registry) and workflow logging (per-archetype baselines, HITL telemetry, override-audit retention to FCRA / FINRA / HIPAA windows) require engineering investment that is easy to defer when the policy and gate are already live. IR is also weak (0.92) because HITL substantiveness probes are the L2 capability most often deferred.

Per-Business-Function summary for this example:

The imbalance is clear: Governance is at 1.69 while Operations is at 0.92. The program has published a solid AI-in-Business-Process Policy, HITL Standards Policy, and intake gate, and has trained process owners, but it has not yet instrumented its in-production AI-embedded workflows to prove decision logs are retained, HITL is substantive rather than rubber-stamp, and Art. 50 disclosures actually fire. The roadmap should front-load EH L1 and ML L1 before deepening Governance to L2, because an Annex III audit lands on what runs in production, not on what is written in policy.

Strengths

Gaps

Highest-priority remediation areas (top 5)

31. Improvement roadmap template

Use this template to convert assessment findings into a 12-month roadmap. Each entry names a target gap, the practice and level it addresses, the owner, the success metric, and the deadline.

A 12-month roadmap for the Processes domain follows four natural quarters. The sequencing mirrors the dependency graph in HAIAMM v3.0 §9: Governance must be in place before Building can operate; Building must be in place before Verification can produce meaningful results; Operations depends on all three preceding functions. For the Processes domain specifically, the FRIA gate (PC L2) and the per-workflow deep threat model (TA L2) are gating capabilities for any L2 work elsewhere, both depend on the SM L2 tier rubric, which depends on the SM L1 inventory.

Quarter 1 (months 1–3). Stabilize L1 across the four Business Functions. Priority practices: SM L1, PC L1, EG L1, TA L1.

Quarter 1 focus: make every AI-embedded workflow in production visible, named, and governed. The inventory, the charter, the three priority policies, the intake gate, and the archetype threat library must all exist at L1 before business units can self-serve on intake. A shadow-AI-in-processes discovery sweep should run within the first 30 days so the inventory is seeded from signals (BPM/RPA/ticketing AI events, CX-platform configuration, internal handbook search, vendor-contract review) rather than declared from memory.

Quarter 2 (months 4–6). Complete remaining L1 practices. Priority practices: SR L1, SA L1, DR L1, IR L1, ST L1, EH L1, IM L1, ML L1; SM L2 risk-tier rubric.

Quarter 2 focus: close the Building, Verification, and Operations L1 gaps, and begin the L2 calibration work starting with the SM L2 risk-tier rubric, which is the prerequisite every other practice needs to move to L2 in the Processes domain.

Quarter 3 (months 7–9). Operationalize L2 across the Governance and Building functions. Priority practices: PC L2 evidence bundles, TA L2 per-workflow deep models, SA L2 template-encoded patterns, DR L2 scenario-based walkthroughs + FRIA workshops, SR L2 quantitative requirements.

Quarter 3 focus: the tier rubric and FRIA gate now exist, use them. Evidence bundles for Critical/High workflows should be assembling continuously. Deep threat models for Critical-tier replace archetype snapshots. Design reviews for Critical-tier move to scenario-based walkthroughs with FRIA workshops attached for all Annex III items. The SR pack sheds all qualitative "reasonable" / "appropriate" language in favor of SLAs and binary states.

Quarter 4 (months 10–12). Complete L2 across all 12 practices and prepare L3 entries for selected practices. Priority practices: IR L2 continuous drift detection + HITL substantiveness probes, ST L2 red-team cadence, EH L2 JIT + dedicated reviewer pools, ML L2 anomaly detection + tier-calibrated logging, IM L2 tier-calibrated playbook + cross-domain coordination; begin L3 scope decisions for SM, TA, and EG.

Quarter 4 focus: close the Verification and Operations L2 gaps. Continuous workflow drift detection, HITL substantiveness probes, dedicated reviewer pools, decision-log integrity verification, anomaly baselines on reviewer behavior, and tier-calibrated incident response are the six load-bearing L2 capabilities that most Processes programs defer because they require operational engineering investment and dedicated business-unit coordination. The L3 scope decisions for SM, TA, and EG can be made now even if the automation work begins in year 2.

Reassessment date (12 months from this assessment): ____

When the next annual assessment runs, compare practice scores to this baseline. The expected trajectory for a program executing this roadmap is: Domain maturity moves from the Foundational band toward the low end of the Comprehensive band (1.6 to 2.0). The Operations function moves from Ad-hoc to Foundational, the most common single-year jump possible for the Processes domain. The Governance function moves from mid-Foundational to low-Comprehensive. The largest score gains come from practices where the Q1–Q2 L1 foundation was weakest: typically IR (HITL substantiveness probes), EH (immutable decision logs, dedicated reviewer pools), and ML (decision-log retention to regulatory windows, behavioral anomaly baselines).

Part V, Reference

32. Glossary

AI-in-Business-Process Policy. The first of the three priority AI/HAI process policies. Enumerates permitted workflow archetypes, the AI tools permitted per archetype, the required human-oversight model per archetype, the disclosure obligation under EU AI Act Art. 50, and the deployer-duty owner requirement under Art. 26.

HITL Standards Policy. The second priority policy. Defines substantive review vs. rubber-stamp review, sets minimum review SLAs per archetype, names override authority, requires HITL design documentation at intake, and requires override-rate tracking.

AI-Process Intake / Sanction Gate Policy. The third priority policy. Makes intake mandatory before production for all seven archetypes, lists archetype-keyed required go-live artifacts (FRIA for Annex III, Art. 22 safeguards for decision pipelines, disclosure UX for customer-facing flows), exposes an amnesty path, and names the gate-decision authority.

AI/HAI workflow archetype. One of seven categories of AI-embedded business workflow the organization operates: decision pipeline, customer-facing flow, human-AI collaboration chain (HITL chain), back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow.

AI/HAI process inventory. The single source of truth for all AI-embedded business workflows the organization operates, owned by the program lead. Seeded from BPM/RPA/ticketing-system signals, internal wiki search, function-by-function survey, vendor-contract review, and self-attestation.

Critical / High / Medium / Low. The four risk tiers introduced at SM-Processes L2. Driven by decision-affecting effect (EU AI Act Annex III / GDPR Art. 22), customer reach, reversibility, human-oversight depth, regulatory scope, data classes, and process criticality.

Deployer-duty owner. The named individual or role accountable for EU AI Act Art. 26 deployer duties for a specific workflow, human-oversight assignment, monitoring, affected-persons notification, log retention. Typically the Business Process Owner.

EA, Excessive Agency. One of the four HAI-specific TTPs. In Processes terms, the workflow grants the AI step broader scope than the use case requires.

AGH, Agent Goal Hijack. One of the four HAI-specific TTPs. In Processes terms, the workflow's input handling redirects the AI step's purpose via injection.

FRIA, Fundamental Rights Impact Assessment. Required under EU AI Act Art. 27 for deployers of Annex III high-risk AI systems. Covers affected persons, decision effects, fundamental rights at stake, human-oversight design, residual rights exposure.

HAI TTPs (EA, AGH, TM, RA). The four AI-specific threat-tactic categories carried throughout HAIAMM v3.0: Excessive Agency, Agent Goal Hijack, Tool Misuse, Rogue Agents.

HITL chain. A human-AI collaboration workflow archetype in which an AI recommendation is presented to a human reviewer for substantive review before action. The primary failure mode is rubber-stamp HITL.

Priority compliance map. A one-page artifact tying each priority regulatory requirement to the specific organizational policy that carries it.

RA, Rogue Agents. One of the four HAI-specific TTPs. In Processes terms, the workflow's quality-control loop fails to detect accumulating effects from AI drift.

Reference pattern. A vetted "green path" workflow pattern published per AI/HAI workflow archetype. Process designers reach for the pattern first; deviations require design review.

REM, Requirements-Evidence Map. A per-workflow map that records, for each applicable requirement in the AI/HAI Workflow Requirements Pack, whether the requirement is Met, Met-with-compensating-control, Gap-accepted, or Not-applicable, with a citation to evidence.

Rubber-stamp HITL. A failure mode in which the human reviewer in a HITL chain matches the AI recommendation at near-100% rate without substantive review, typically because review SLA is arithmetically impossible against queue volume, rationale is not required, or anchoring presentation biases the reviewer. Fails EU AI Act Art. 14 oversight obligation.

Shadow AI in processes. Ungoverned AI-embedded business workflows, AI-routing rules in ticketing systems without intake, AI-scoring steps in approval workflows without governance, RPA bots calling LLM APIs without sanction. The program's primary L1 outcome is to make these visible, attributable, and trending down.

Shadow-AI-in-processes ratio. Unsanctioned AI-embedded workflows in production divided by total AI-embedded workflows in production. A primary L1 outcome metric. Reported quarterly and trending down; reported per tier at L2.

Substantive review. A HITL review in which the human has enough time and information to meaningfully evaluate the AI output, can exercise judgment independently, and can override without disincentive. The opposite of rubber-stamp HITL.

TM, Tool Misuse. One of the four HAI-specific TTPs. In Processes terms, the workflow's tool wiring is exploited to cause out-of-scope effects.

33. Reference frameworks

This handbook is one of six domain handbooks that, together with a master handbook, constitute HAIAMM v3.0. The frameworks named here are referenced throughout. They are listed by name only; consult the issuing body's current published version when running an assessment.

Maturity-model lineage.

• OWASP SAMM (Software Assurance Maturity Model). HAIAMM borrows SAMM's lifecycle shape (Governance, Building, Verification, Operations) and practice-per-function structure.
• BSIMM (Building Security In Maturity Model). HAIAMM borrows the observational "this is what organizations actually do" posture at higher maturity levels.

AI-governance frameworks (complementary).

• NIST AI RMF 1.0 + Playbook. The risk-management-framework counterpart to HAIAMM's maturity-model shape; GOVERN, MAP, MEASURE, and MANAGE functions align closely to Processes-domain practices.
• ISO/IEC 42001 (AI Management System). A management-system standard for AI. HAIAMM Processes-domain practices supply the workflow operational evidence an ISO 42001 AIMS requires.
• ISO/IEC 42005 (AI Impact Assessment). Methodology guidance for AI impact assessment, including FRIA composition for Annex III use cases.
• OECD AI Principles and AI Policy Observatory. Practitioner network for AI governance practice and policy.
• CSA AI Safety Initiative / AI Controls Matrix. Cross-organization AI controls work; HAIAMM contributes the workflow-level controls at L3.

Regulations applicable to AI-embedded business workflows.

• EU AI Act. Articles 9 (risk management), 14 (human oversight), 26 (deployer duties), 27 (FRIA), 50 (transparency), 73 (serious-incident reporting), Annex III (high-risk classification).
• GDPR. Articles 22 (automated decision-making), 32 (security), 33 (breach notification), 35 (DPIA).
• SOC 2. CC9.2 vendor and process controls.
• Sector-specific. FCRA (credit AI adverse-action); EEOC, NYC Local Law 144 (employment AI bias audit); CO SB-21-169 (insurance AI anti-discrimination); FINRA model-risk (financial AI); FDA AI/SaMD (clinical AI); HIPAA (PHI in clinical AI workflows).

Threat taxonomies.

• MITRE ATLAS (Adversarial Threat Landscape for AI Systems). Canonical adversarial-ML reference. Processes-domain TA consumes ATLAS technique IDs and contributes back process-level techniques at L3.
• AVID (AI Vulnerability Database). AI vulnerability disclosure database; Processes-domain TA consumes AVID entries and contributes back.
• OWASP Top 10 for LLM Applications / Agentic AI Top 10. Threat references relevant to AI components inside Processes-domain workflows.

Industry communities.

• NIST AI RMF community of practice. Implementation guidance from peer organizations on NIST AI RMF.
• CSA AI Safety Initiative. Cross-organization AI controls work.
• OECD AI Policy Observatory practitioners network. Policy and practice exchange.
• Sector ISACs. FS-ISAC (FinAI working group), H-ISAC (ClinAI working group), IT-ISAC, and others; HR-AI (SHRM AI in HR initiative).
• APQC. Process-maturity frameworks adaptable to AI-embedded workflows.
• BPM community AI-governance working groups. Object Management Group BPM + AI, Camunda community, SAP Signavio practitioner networks.

HAIAMM canonical companions.

• HAIAMM-v3.0-Framing.md, model master document; canonical definitions for the 12 practices, 6 domains, 3 maturity levels, cell template, dependency graph, through-lines, and authoring rules.
• AI-Attack-Taxonomy.md (HAA), high-impact AI attacks catalog cross-referenced to MITRE ATLAS.
• Threat-Modeling-Methodology.md, per-workflow threat-modeling methodology referenced by TA-Processes L2.

Threat-tactic categories specific to HAIAMM (reproduced for reference).

• EA, Excessive Agency. The workflow grants the AI step broader scope than the use case requires.
• AGH, Agent Goal Hijack. The workflow's input handling redirects the AI step's purpose via injection.
• TM, Tool Misuse. The workflow's tool wiring is exploited to cause out-of-scope effects.
• RA, Rogue Agents. The workflow's quality-control loop fails to detect accumulating effects from AI drift.

34. Change log

End of HAIAMM v3.0 Processes Domain Handbook.