Secure Architecture (SA)

Processes Domain - HAIAMM v3.0

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 and MITRE ATLAS). 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 multi-region/sector-specific complexity, include HITL-capacity patterns that auto-throttle decision volume to reviewer capacity, and are encoded as IaC where workflows are code-defined (Temporal, Camunda, Argo Workflows). At L3, patterns are open artifacts contributed to OECD AI, ISO/IEC 42005, 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. 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

At this level, architecture becomes prescriptive rather than advisory. Reference patterns are named, versioned, and the first thing a team reaches for when designing a decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, or knowledge-management workflow that embeds AI.

Dependencies

• SR-Processes L1 (required): patterns implement the base + archetype requirement packs; without the pack, pattern controls are stylistic choices rather than requirement-backed decisions.
• TA-Processes L1 (required): threat library drives which controls appear in each pattern and which threats each pattern claims to mitigate.
• PC-Processes L1 (required): patterns operationalize AI Acceptable Use, Disclosure, and Human Oversight policy constraints.
• SM-Processes L1 (required): inventory shows which workflow archetypes the org actually operates; patterns are authored for that archetype list.
• Supports / unblocks: DR-Processes L1 (design reviews use the pattern as the baseline), IR-Processes L1 (implementation reviews check pattern adherence), EH-Processes L1 (hardening targets the pattern's surface areas), ST-Processes L1 (security tests target the pattern's controls).

Desired Outcomes

• Every team designing an AI/HAI-embedded workflow finds a documented reference pattern within one click of the SM inventory record.
• Each pattern is concrete enough to implement: workflow diagram, oversight design, disclosure mechanism, logging points, controls with SR traceability, and named threats mitigated.
• Known anti-patterns, the workflow design mistakes that have produced real incidents, are named, explained, and linked to the reference pattern element that replaces them.
• Deviations from reference patterns are visible and reviewed, not accidental or silent.
• Architecture decisions carry explicit traceability to SR requirements and TA threats.

Activities

A) Publish reference architectures per AI/HAI workflow archetype

Publish one pattern per archetype the org actually operates. Each pattern is concise (≤3 pages), includes a labeled workflow diagram, and covers the same structural elements.

Pattern skeleton (every archetype): - Scope, what the pattern covers and what it explicitly 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, how and when affected persons or customers are informed of AI involvement (Art. 50 implementation point). - Logging spec, what is logged: AI output, decision record, HITL review event, override event; retention and exportability meeting the longest applicable regulation. - Controls mapped to SR requirements, explicit row-by-row mapping; gaps acknowledged. - Threats mitigated, which TA-Processes archetype threats the pattern addresses, which remain residual; HAI TTP tags (EA / AGH / TM / RA); MITRE ATLAS mitigation IDs where applicable.

Archetype reference patterns:

• Decision pipeline pattern. AI scoring layer with documented threshold; HITL gate required for Critical-tier decisions (blocking, not advisory); threshold-change governance (any threshold change is a material workflow change requiring re-review); override audit trail wired at the gate (reviewer identity, direction, rationale, timestamp, AI output reference); decision-distribution monitor with baseline established at launch and alert threshold defined; appeal/explanation path for affected persons (Art. 22 lawful basis recorded and accessible); drift alert routes to the HITL queue for human review before the next batch processes. Threats mitigated: decision-laundering (audit trail + HITL gate), silent-decision-drift (distribution monitor), adversarial-input-against-decision (threshold governance). HAI TTP: EA mitigated by HITL gate; RA mitigated by distribution monitor. ATLAS: TA0008 Defense Evasion mitigated by audit trail; TA0043 Impact mitigated by drift alert.

• Customer-facing flow pattern. PII redaction layer at the input edge before any data reaches the AI component; output filter and integrity check before AI-generated content is delivered to the customer; Art. 50 disclosure placed at the point of first AI interaction (not buried in terms); escalation path to a human agent for any request the AI cannot handle, refuses, or handles with confidence below defined threshold; brand-safety filter on outbound AI-generated content; prompt + completion logging with customer interaction identifier; degraded-mode fallback when AI component is unavailable (human routing, not silent failure). Threats mitigated: hallucination reaching customer with material consequence (output filter + integrity check), Art. 50 disclosure failure (disclosure at interaction point), prompt injection via customer input (input edge treated as untrusted). HAI TTP: AGH mitigated by input-edge treatment; EA mitigated by escalation path. ATLAS: TA0003 Initial Access mitigated by input handling; TA0043 Impact mitigated by output filter and brand-safety filter.

• HITL chain pattern. Review UI designed to surface AI rationale and any available confidence indicator, the reviewer sees not only the AI output but why the AI produced it; counterfactuals surfaced for Critical and High tier (what input change would flip the AI output); review SLA enforcement, queue-depth monitoring with automatic escalation when SLA is approaching breach; reviewer-capacity gating, a queue cap that throttles new workflow inputs when reviewer capacity is exhausted, preventing auto-approve as a fallback; reviewer-side prompt-injection defense, the review UI treats AI-generated content as untrusted display data, not executable or clickable content; auditable override wired at every gate; reviewer calibration cadence (reviewers periodically assessed on inter-rater reliability). Threats mitigated: rubber-stamp HITL (rationale surfacing + calibration), reviewer overload (capacity gating + queue cap), reviewer-side prompt injection (UI defense). HAI TTP: RA mitigated by calibration; AGH mitigated by UI injection defense. ATLAS: TA0008 Defense Evasion mitigated by auditable override and capacity gating.

• Back-office augmentation pattern. Scoped AI assistant with a workflow-specific tool list, the AI assistant can only invoke tools declared for the specific workflow (no general-purpose tool access); output-review gate, a documented step in the workflow where staff review AI output before acting on it, with the gate enforced by workflow design (not policy alone); classification-aware routing, workflows involving regulated data classes (PII, PHI, financial) require DPO sign-off before AI augmentation is sanctioned; session-bounded context, AI assistant session context is bounded to the current workflow instance (no cross-instance memory without explicit design and DPO review); AI output logged per session with the workflow instance identifier. Threats mitigated: confidential-data egress (scoped tool list + classification-aware routing), AI output incorporated without review (output-review gate), EA (scoped tool list). HAI TTP: EA mitigated by scoped tool list; TM mitigated by tool list governance. ATLAS: TA0011 Exfiltration mitigated by classification-aware routing; TA0007 Privilege Escalation mitigated by scoped tool list.

• Approval/review workflow pattern. AI classifier with documented threshold and calibration history; HITL gate for borderline cases (cases within a defined confidence band around the threshold are always routed to human reviewers, not auto-decided); queue routing by tier (Critical/High cases routed to senior reviewers; Low cases to standard queue); class-shift monitor on approval/rejection rates per protected-class group, with alert threshold triggering a hold on new auto-decisions; audit trail for all AI classifications including borderline cases routed to HITL; threshold-change governance same as decision pipeline pattern. Threats mitigated: AI-screen poisoning (borderline HITL gate + audit trail), approval-bypass via classifier exploit (threshold governance + audit trail), class-shift (class-shift monitor). HAI TTP: RA mitigated by class-shift monitor. ATLAS: TA0040 ML Attack Staging mitigated by borderline gate; TA0007 Privilege Escalation mitigated by threshold governance.

• Content-generation pattern. Generation prompt-template versioning, prompts stored in source control; changes treated as material content-policy changes requiring review and re-validation; output-review gate, a human review step before any material AI-generated content is published, submitted to a regulator, or delivered to a customer (the review gate is workflow-enforced, not advisory); copyright filter applied before publication (no AI-generated content bypasses copyright check for material outputs); brand-voice check applied before publication (deviation from brand standards or legal safe-harbor language triggers review hold); downstream-system input validation, AI-generated content passed to other systems (APIs, databases, processing pipelines) is validated before ingestion to prevent AGH propagation. Threats mitigated: generated content reaching customers or regulators without review (output-review gate), copyright liability (copyright filter), injection-via-generated-content (downstream input validation). HAI TTP: AGH mitigated by downstream input validation. ATLAS: TA0004 Execution mitigated by downstream validation; TA0043 Impact mitigated by output-review gate.

• Knowledge-management pattern. RAG retrieval with provenance, every retrieved chunk carries its source identifier, classification label, and last-verified date; injection defense, the prompt structure explicitly separates retrieved content from instructions (retrieved content is data, not trusted input); per-role retrieval scoping, retrieval results are filtered to the querying user's access entitlements at query time (the retrieval layer enforces access control, not only the UI); freshness SLA, corpus documents older than the defined threshold are flagged or excluded; retrieval logging with user identifier and retrieved-source identifiers per query. Threats mitigated: RAG-poisoning of internal corpus (provenance + injection defense), retrieval extraction by malicious insiders (per-role retrieval scoping), misinformation propagation (freshness SLA + provenance). HAI TTP: AGH mitigated by injection defense; TM mitigated by per-role scoping. ATLAS: TA0005 Persistence mitigated by provenance and freshness SLA; TA0010 Collection mitigated by per-role retrieval scoping.

B) Publish the anti-pattern catalog

Name, describe, and prohibit the AI/HAI workflow design patterns that reliably produce incidents. Each anti-pattern entry: description, why it is dangerous, real-incident flavor (industry or first-party), and the reference pattern element that replaces it.

L1 anti-pattern set:

• Rubber-stamp HITL, a human approval gate is present in the workflow, but the reviewer has no AI rationale, no time to review substantively, and approves everything; the gate provides legal cover with no actual oversight. Replaced by: HITL chain pattern review-UI rationale surfacing + calibration + capacity gating.
• Autonomous decisions affecting persons without override path, an AI scoring or classification component directly drives a consequential decision (account closure, loan rejection, employment screening) with no human review gate and no explained appeal path for the affected person; EU AI Act Art. 14 and GDPR Art. 22 obligations are unmet. Replaced by: decision pipeline pattern HITL gate + Art. 22 lawful basis + appeal/explanation path.
• Back-office AI with unbounded tool scope, an AI assistant used in a back-office workflow has access to production APIs, file systems, email, and databases far beyond what any individual task requires; one poorly-worded request or prompt injection can cause the assistant to take actions the user did not intend. Replaced by: back-office augmentation pattern scoped tool list.
• Content-generation without review for material outputs, AI-generated reports, customer communications, regulatory filings, or legal documents are published or submitted without a human review gate; errors, hallucinated facts, and regulatory violations in the generated content reach external audiences unchecked. Replaced by: content-generation pattern output-review gate.
• Knowledge-base without provenance, a RAG corpus serves internal or customer queries from documents whose origin, classification, and last-verified date are unknown; outdated, incorrect, or confidential content is served with high apparent confidence, and there is no mechanism to identify and quarantine a poisoned or stale source. Replaced by: knowledge-management pattern RAG with provenance + classification labels + freshness SLA.
• HITL gate that silently becomes auto-approve on queue overflow, a workflow designed with a human review gate falls back to auto-approval when the review queue exceeds capacity; the fallback is undocumented and untested; the workflow operates as if reviewed when it is not. Replaced by: HITL chain pattern reviewer-capacity gating + queue cap (throttle input, not approval).
• Decision-distribution monitor never established, a decision pipeline is launched without a baseline for the approval/rejection rate or score distribution; silent-decision-drift goes undetected for quarters; outcomes have shifted materially before anyone notices. Replaced by: decision pipeline pattern drift monitor with baseline at launch.
• Art. 50 disclosure buried in terms, a customer-facing AI workflow technically discloses AI involvement in the privacy policy or terms of service, but the disclosure is not at the point of interaction; users interact with the AI without awareness; EU AI Act Art. 50 compliance intent is not met even if the text exists somewhere. Replaced by: customer-facing flow pattern Art. 50 disclosure at the point of first AI interaction.

C) Integrate patterns into the intake/inventory flow and establish the deviation-review path

Reference patterns are only useful if teams encounter them at the right moment, when they are proposing or designing an AI/HAI-embedded workflow.

• 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 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 are a signal to update the pattern, not to keep 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)

Process Metrics (leading)

• Pattern review cadence, quarterly refresh with change-log maintained.
• New-archetype lead time, new pattern published within 30 days of the first intake in a new archetype category.
• Deviation-review SLA, ≤5 business days from deviation request to decision.
• Anti-pattern catalog linked from the AI Acceptable Use Policy and the SM intake gate.

Effectiveness Metrics (business value)

• Process design lead time, time-to-sanctioned-production for a workflow designed via the reference pattern (should decrease after patterns land and the green path is clear).
• Avoided-incident stories, documented cases where the pattern (HITL gate, distribution monitor, review gate) blocked or contained a real risk before it reached production.
• Pattern reuse rate, % of new workflows using the pattern unchanged vs. deviating; rising reuse indicates the pattern is fit for purpose and the program scales.

Success Criteria

• Seven reference patterns published, each with: labeled workflow diagram, scope declaration, data boundary, oversight design, disclosure mechanism, logging spec, and row-by-row mapping to SR-Processes requirements and TA-Processes threats with HAI TTP tags (EA / AGH / TM / RA) and applicable MITRE ATLAS mitigation IDs.
• Anti-pattern catalog published (minimum 8 entries), linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Processes training.
• Deviation-review path operational with a named reviewer population and ≤5 BD 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, not only in terms of service.

Maturity Level 2

Objective: Extend reference patterns to multi-region/sector-specific complexity; add HITL-capacity patterns that auto-throttle decision volume to reviewer capacity; encode patterns as IaC where workflows are code-defined; update the anti-pattern catalog from IM-Processes incidents

At this level, architecture moves from "single-path reference" to "production-scale reference set." Tier-conditional patterns apply: Critical-tier workflows receive the full pattern with class-shift monitors, data-residency variants, and kill-switch design; HITL-capacity patterns are explicit and auto-throttle mechanisms are specified; code-defined workflows (Temporal, Camunda, Argo Workflows) are encoded as IaC so teams fork rather than handcraft; sector-specific overlays (employment, credit, clinical, financial) are covered.

Dependencies

• SA-Processes L1 (required): base reference patterns and anti-pattern catalog are the substrate L2 extends.
• SR-Processes L2 (required): quantitative and tier-calibrated requirements drive the L2 pattern controls.
• TA-Processes L2 (required): per-workflow and per-tier deep threat models surface the controls each L2 pattern must cover.
• SM-Processes L2 (required): risk-tier rubric determines which tier-conditional pattern variant applies to each workflow.
• IM-Processes L1+ (required): incidents feed anti-pattern additions and drive pattern evolution.

Desired Outcomes

• Teams designing Critical or High-tier AI/HAI-embedded workflows have a production-grade pattern to fork rather than a sketch to interpret.
• Tier-conditional pattern variants are explicit: Critical gets class-shift monitoring IaC, DPIA/FRIA evidence hooks, and kill-switch design; High gets HITL-capacity monitoring modules; Medium and Low follow the base pattern.
• Anti-pattern catalog reflects real incidents from IM-Processes, not only theoretical harms.
• Pattern drift is detectable: IaC-encoded workflow patterns enable conformance testing; workflows using old or hand-modified patterns are flagged.
• HITL-capacity patterns are code-enforced, auto-throttle is a workflow property, not a policy aspiration.

Activities

A) Tier-conditional pattern extensions

Publish extended pattern variants calibrated to SM-Processes L2's tier-treatment matrix:

• Critical-tier overlay (any archetype at Critical tier): class-shift monitor with per-protected-class segmentation (approval rate, rejection rate, score distribution tracked separately per group); DPIA/FRIA evidence hook (the workflow design includes a documented link to the current DPIA/FRIA record; a workflow change that materially affects the risk assessment triggers DPIA/FRIA re-review before launch); EU / sector data-residency variant (decision data residency enforcement, cross-region data-flow legal basis under GDPR Art. 44–49); kill-switch design, a documented halt procedure that stops the workflow, suspends AI output, and routes pending items to human queue within a defined SLA; EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern.
• High-tier overlay: HITL-capacity monitoring modules included in the fork (queue-depth signal, reviewer-per-volume ratio signal, SLA-approaching-breach alert, auto-throttle trigger wired to the workflow orchestrator); standard detections from ML-Processes L2 pre-wired.
• Sector-specific overlays: employment-decision overlay (EEOC bias-audit schedule wired; NYC LL 144 third-party auditor integration point; FCRA adverse-action notice generation step); credit/insurance overlay (FCRA adverse-action notice; CO SB-21-169 insurance use constraints); clinical-decision overlay (FDA SaMD documentation hook; clinical-escalation path for low-confidence output); financial-advisory overlay (FINRA model-risk evidence generation; SEC suitability documentation step).
• Multi-region pattern: decision-data residency enforcement for global workflows (region pinning, cross-region transfer legal basis selection step, GDPR Art. 44–49 mechanism selection included as a required decision gate in the IaC module or workflow definition).
• HITL-capacity pattern (auto-throttle): the workflow orchestrator monitors the HITL queue depth in real time; when queue depth exceeds the defined cap, new workflow items are held in a staging queue rather than routed to auto-approve; the staging queue has a maximum hold time after which items are escalated to a senior reviewer or the workflow owner; auto-throttle is a first-class workflow property, not a downstream alert.

B) Patterns-as-IaC for code-defined workflows

For workflows defined in code-based orchestrators (Temporal, Camunda, Argo Workflows, or equivalent): - All Critical and High-tier pattern variants encoded as forkable workflow definition templates; 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). - Template version-pinned; template updates trigger a drift-detection pass against all deployed workflow instances. - Template change log maintained; workflow owners consuming a template are notified of updates requiring remediation.

C) Incident-informed anti-pattern catalog refresh

• Every IM-Processes incident classified to an anti-pattern (existing or new); classification recorded in the IM finding.
• Catalog refreshed monthly from IM-Processes findings; new anti-patterns surfaced to teams at intake time.
• 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)

Process Metrics (leading)

• Pattern refresh cadence, at least one substantive pattern change per quarter, change-logged.
• Anti-pattern review cadence, monthly from IM-Processes findings.
• Template pipeline health monitored, template-update notification and drift-detection pass tracked.
• Tier-treatment matrix adherence check, quarterly reconciliation of Critical/High workflow list against template-encoded pattern adoption.

Effectiveness Metrics (business value)

• Process design time-to-production drops for teams designing Critical/High-tier workflows that fork templates rather than handcraft.
• Incident rate on template-encoded workflow deployments lower than on hand-crafted deployments, tracked as a rolling 12-month comparison.
• Conformance test failures caught before production, not in DR or IR.

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 sector standards bodies; engage regulators on AI workflow architecture norms

At this level, the reference patterns are open artifacts that the industry adopts, forks, and builds on. The org contributes patterns to OECD AI Principles implementation guidance, ISO/IEC 42005 AIMS process standards, and sector bodies (FS-ISAC, H-ISAC, sector AI working groups). Pattern adoption telemetry is operational. Regulatory engagement on EU AI Act implementing acts and sector-specific AI workflow guidance is active.

Dependencies

• SA-Processes L2 (required): IaC/template-encoded patterns and conformance test suites are the substrate L3 publishes and maintains externally.
• SM-Processes L3 (alignment): automation and benchmarking substrate supports the telemetry and benchmarking activities at L3.
• IM-Processes L2+ (required): incident-to-pattern feedback loop must be operational before incident data drives external contributions.

Desired Outcomes

• At least two SA-Processes reference patterns are cited or forked by recognized industry or sector bodies (OECD, ISO, sector ISACs, OWASP AI, CSA).
• ISO/IEC 42005 or OECD AI Principles implementation guidance carries at least two process-design pattern contributions attributable to SA-Processes (HITL-capacity gating, decision-distribution monitoring, or equivalent).
• Internal practice is aligned to the published external version, not an aspirational document the org once published and no longer follows.
• Regulatory bodies and sector organizations reference SA-Processes patterns in AI workflow architecture guidance or implementing-act consultations.

Activities

A) Publish reference patterns as open artifacts

• Patterns published under Apache 2.0 or equivalent open license 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).
• Maintained upstream in the public repository; internal use aligns with the external version; internal deviations are documented with rationale and fed back as upstream proposed changes.
• Pattern adoption telemetry tracked: forks, citations in published work, documented adopters.
• New archetypes or overlays developed internally proposed for inclusion in the external catalog within 90 days of internal publication.

B) Contribute to OECD AI, ISO/IEC 42005, and MITRE ATLAS

• For each control in the process 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.
• 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 SA-Processes decision-pipeline and HITL-chain patterns as concrete examples of Art. 14 and Art. 50 implementation.
• Sector-specific: engage sector regulators (CFPB, EEOC, FDA, FINRA) with sector-relevant pattern variants; seek inclusion in sector AI workflow guidance documents.

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 / MANAGE, focusing on the HITL-chain and decision-pipeline patterns as concrete GOVERN-level implementations.

Outcome Metrics (L3)

Process Metrics (leading)

• External contribution pipeline, ≥2 pattern items in-flight (draft, in-review, or in-publication) at all times.
• Internal-external alignment audit, quarterly diff between internal pattern versions and published external versions; unexplained divergence queued for resolution.
• ATLAS/ISO contribution cadence, at least one contribution or validation per 6 months.
• Regulatory engagement calendar maintained with active items and target timelines.

Effectiveness Metrics (business value)

• Industry recognition, invitations to working groups, citations in published standards, peer adoption of SA-Processes patterns.
• Regulatory benefit, SA-Processes patterns referenced in implementing-act or guidance documents reduce compliance uncertainty for the org and the industry.
• Talent, external publication and standards participation attracts experienced architects with AI-process-specific expertise.
• Faster process design, industry adoption of patterns means external teams the org integrates with arrive already familiar with the workflow norms; integration friction decreases.

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, no unexplained internal deviations; all deviations proposed as upstream contributions.
• At least one documented regulatory or standards-body reference to SA-Processes patterns in implementing-act, guidance, or standards text.

Key Success Indicators

Level 1: - 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, scope, data boundary, oversight design, disclosure mechanism, logging spec, and row-by-row mapping to SR-Processes requirements and TA-Processes threats; HAI TTP tags (EA / AGH / TM / RA) and applicable MITRE ATLAS mitigation IDs present. - Anti-pattern catalog published (minimum 8 entries), each linked to a reference pattern element that replaces it; linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Processes training. - ≥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. - Deviation-review path operational with a named reviewer population, ≤5 BD SLA, and a repeat-deviation signal that queues pattern updates.

Level 2: - 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 workflows running on template-encoded patterns. - 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; drift-detection operational. - 100% of Critical-tier workflows with EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern documentation.

Level 3: - ≥5 reference patterns published as open artifacts under a recognized open license; ≥2 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 published external versions; all deviations proposed as upstream contributions, none silently forked. - At least one documented reference to SA-Processes patterns in a regulatory implementing-act, sector guidance document, or standards text.

Common Pitfalls

Level 1: - ❌ Patterns are written but not linked from the SM inventory record or the intake gate, workflow designers 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, so designers do not recognize the hazard when they encounter it. - ❌ Deviations are approved individually but the repeat-deviation signal is never wired, patterns never update because nobody aggregates the pattern-update trigger. - ❌ Art. 50 disclosure is mapped to the pattern but not verified at implementation, the pattern describes disclosure at the interaction point and the IR spot-check was never configured, so disclosure is buried in terms in practice. - ❌ 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: - ❌ IaC/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. - ❌ 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. - ❌ Anti-pattern catalog grows from incidents but is only accessible as a reference document; workflow designers encounter the anti-pattern again before they encounter the catalog entry. - ❌ 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; 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 / sector standards, external recognition is aspirational. - ❌ Pattern adoption telemetry is not tracked, the org claims patterns are "widely adopted" but has no evidence; external benchmarking is not possible.

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? 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? 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?

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? 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? 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?

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

Document Version: HAIAMM v3.0 Practice: Secure Architecture (SA) Domain: Processes Last Updated: 2026-05-14 Author: Verifhai