Strategy & Metrics (SM)
Processes Domain - HAIAMM v3.5
Generated from the canonical cell records in
cells/. Do not edit by hand; editcells/SM-Processes-L*.cell.jsonand re-runtools/render.py.
Practice Overview
Business Function: Governance
Objective: Stand up governance for business workflows with AI in the decision path, map where AI touches decisions, and baseline the metrics that prove ungoverned AI decisioning is shrinking.
Description: A program at this level knows where AI has entered its business processes. This is the hardest domain to inventory because the assets are not systems but workflows, and AI often arrives inside a step nobody re-documented. The seven archetypes span decision pipelines, customer-facing flows, human-in-the-loop chains, back-office augmentation, approval and review workflows, content generation and knowledge management. Discovery is interview-led and process-register-led rather than telemetry-led, which makes it slower and makes business-owner engagement the critical success factor. This is also the domain that owns the denominator for the whole model: a unit of business work is only definable here.
Maturity Level 1, Foundational
Objective: Stand up governance for business workflows with AI in the decision path, map where AI touches decisions, and baseline the metrics that prove ungoverned AI decisioning is shrinking.
A program at this level knows where AI has entered its business processes. This is the hardest domain to inventory because the assets are not systems but workflows, and AI often arrives inside a step nobody re-documented. The seven archetypes span decision pipelines, customer-facing flows, human-in-the-loop chains, back-office augmentation, approval and review workflows, content generation and knowledge management. Discovery is interview-led and process-register-led rather than telemetry-led, which makes it slower and makes business-owner engagement the critical success factor. This is also the domain that owns the denominator for the whole model: a unit of business work is only definable here.
Dependencies
- Required: None.
- Alignment (not blocking): Existing business process management and internal control frameworks, so AI decision points attach to processes already documented for other reasons
- Supports / unblocks: PC-Processes-L1; TA-Processes-L1; SR-Processes-L1; DR-Processes-L1; IM-Processes-L1; ML-Processes-L1; Required by: EG-Processes-L1, EH-Processes-L1, IR-Processes-L1, SA-Processes-L1, SM-Processes-L2, ST-Processes-L1
Desired Outcomes
- Every business process with AI in its decision path is mapped, with the decision point and its human oversight arrangement recorded.
- Processes making decisions with legal or significant effect on people are identified and flagged against GDPR Art. 22 and EU AI Act Annex III.
- Each AI-enabled process has a named business owner who is accountable for its outcomes, not only for its throughput.
- The unit of business work each AI-enabled process delivers is defined, which is the denominator the rest of the model depends on.
- Human oversight arrangements are described concretely enough to be tested rather than asserted.
Activities
A) Charter process AI governance and engage business owners
Publish a charter within the first 30 days sponsored by the CISO jointly with the Chief Operating Officer or equivalent business leader, because in this domain a security-only sponsor has no authority over the processes being governed. Name the seven in-scope archetypes, being decision pipeline, customer-facing flow, human-in-the-loop chain, back-office augmentation, approval and review workflow, content-generation workflow, and knowledge-management workflow. Constitute the working group around business-process owners rather than around technologists, with Security, Compliance, Legal and Privacy counsel, internal audit and one representative per major business function. Define decision rights over who may introduce AI into a decision path, who must approve it where the decision affects a person, who can suspend an AI-enabled process, and who owns the fallback when it is suspended. Commit to a numeric year-one target per outcome metric, and state explicitly that the program measures decision quality and oversight, not only throughput.
B) Map AI decision points and define the unit of work
Build one AI-enabled process inventory recording per process the archetype, business owner, the specific decision or output AI contributes, whether AI advises or decides, the human oversight arrangement including who reviews and with what authority to refuse, volume and throughput, the population affected, whether the decision has legal or significant effect on a person, the fallback when AI is unavailable, and links to the systems that implement it. Discover through three mechanisms, since telemetry will not find these: structured workflow-mapping sessions with each business function, reconciliation against the business process register and internal control catalogue, and targeted interviews following the money and the complaints, because an AI-enabled process that has begun generating disputes is usually known to someone. For every process, define and record the unit of business work it delivers, being the resolved ticket, the processed application, the reviewed document or the completed transaction. This definition is the denominator that makes consumption measurable across the whole model, and no other domain can supply it.
C) Baseline the process scoreboard and open the per-transaction ledger
Instrument and report quarterly: process inventory coverage against the business process register, the share of AI-enabled processes with a named business owner, the share with a documented and testable human oversight arrangement, the count of processes making decisions with legal or significant effect that lack a documented Art. 22 safeguard, and the share with a defined fallback. Open the per-transaction ledger recording AI cost per unit of business work for each process, using the denominator defined in Activity B, and record the pre-AI baseline cost per unit where it is known, because the unit economics of an AI-enabled process against the human process it replaced is the only honest test of whether the transformation delivered what it was funded on. Track human review time per transaction alongside AI cost, since a process that halves AI cost while doubling review burden has not improved, and only the combined figure reveals it.
Outcome Metrics (L1)
| Metric | Baseline | L1 Target | Source |
|---|---|---|---|
| AI-enabled process inventory coverage against the business process register | first mapping pass across business functions | ≥80% of in-scope processes within 12 months | Process inventory reconciled against the business process register |
| AI-enabled processes with a named accountable business owner | first mapping pass | 100% | Process inventory owner field |
| AI-enabled processes with a documented and testable human oversight arrangement | first mapping pass | ≥90%, and 100% where the decision affects a person | Process inventory oversight field |
| Decision-affecting processes lacking a documented Art. 22 safeguard | first legal review pass | 0 | Process inventory cross-referenced with the privacy assessment register |
| AI-enabled processes with a defined and exercised fallback for AI unavailability | first mapping pass | ≥85%, and 100% for customer-facing flows | Process inventory fallback field with last-exercised date |
Process Metrics (leading)
- Workflow-mapping sessions completed on schedule across business functions, with coverage tracked by function.
- Process inventory reconciled against the business process register quarterly.
- New AI-in-process requests triaged within 10 business days.
- Business-owner working group meets at least quarterly with minutes published.
Effectiveness Metrics (business value)
- Cost per unit of business work for AI-enabled processes compared against the pre-AI baseline, reported honestly including review burden.
- Time to suspend an AI-enabled process and fall back, measured by exercise rather than estimated.
- Documented cases where mapping surfaced an AI decision point that nobody had assessed for Art. 22 exposure.
Consumption Metrics (denominated, never absolute spend)
| Metric | Denominator | Economic failure it detects | Source |
|---|---|---|---|
| AI cost per unit of business work, by process, against the pre-AI baseline | per business transaction completed | an AI-enabled process costing more per completed unit than the human process it replaced, which absolute spend and throughput reporting both conceal | Consumption ledger joined to the process inventory transaction counts |
| Combined AI cost and human review time per unit of business work | per business transaction completed | cost displaced from AI spend onto human reviewers, so the process looks cheaper while total cost per unit rose and reviewer load quietly became unmanageable | Consumption ledger joined to workflow review-time telemetry |
| Cost per human-in-the-loop review, with review volume per reviewer | per HITL review | oversight degrading into rubber-stamping as review volume per reviewer rises, which is an economic signal before it is a quality signal | Workflow system review records joined to the consumption ledger |
Level of Effort (incremental over the level below)
- Stand-up: 200 hours · Ongoing: 90 hours/quarter
- Program Manager / Practice Lead — primary, 30 days/year
- Business Owner / PM — regular, 20 days/year
- Compliance / Audit — regular, 14 days/year
- Legal / Privacy Counsel — regular, 10 days/year
- Executive Sponsor — low, 4 days/year
- Material new tooling: Process inventory extending the existing business process register rather than a separate tool
Success Criteria
- A charter is published and jointly sponsored by the CISO and a business leader, with business-process owners constituting the working group.
- One AI-enabled process inventory covers all seven archetypes at 80% coverage or better against the business process register within 12 months.
- Every AI-enabled process has a named accountable business owner and a defined unit of business work.
- No decision-affecting process lacks a documented Art. 22 safeguard, and every such process has a testable human oversight arrangement.
- A per-transaction ledger is open recording AI cost per unit of business work with human review time tracked alongside.
Maturity Level 2, Comprehensive
Objective: Tier AI-enabled processes by decision impact and oversight burden, calibrate control intensity per tier, and measure whether human oversight can actually refuse.
At this level control intensity follows the consequence of the decision rather than the volume of the process. A published rubric derives a tier from decision impact on people, reversibility, throughput, oversight burden and fallback viability, and a treatment matrix states what each tier receives in oversight design, review authority, testing and monitoring. This is the domain where the oversight question becomes concrete: an approver clearing hundreds of items a day who has never refused one is not a control, and the metrics here are designed to detect exactly that. Unit economics per transaction are tiered too, because oversight is the largest cost in high-tier processes.
Dependencies
- Required: SM-Processes-L1, PC-Processes-L1, TA-Processes-L1
- Alignment (not blocking): Internal control framework tiering, so AI process tiers compose with existing control ratings
- Supports / unblocks: PC-Processes-L2; TA-Processes-L2; SR-Processes-L2; SA-Processes-L2; DR-Processes-L2; IR-Processes-L2; ST-Processes-L2; EH-Processes-L2; IM-Processes-L2; ML-Processes-L2; Required by: EG-Processes-L2, SM-Processes-L3
Desired Outcomes
- Every AI-enabled process carries a tier derived from decision impact, reversibility, throughput, oversight burden and fallback viability.
- Oversight design is differentiated per tier, with review authority and refusal capacity scaled to the consequence of the decision.
- Human oversight is measured rather than asserted, so rubber-stamping and approver overload are visible.
- Fallbacks for high-tier processes are exercised on a schedule rather than documented and left untested.
- Cost per transaction including review burden is reported per tier, so oversight cost is a governed figure.
Activities
A) Publish the process risk-tier rubric
Derive four tiers from five auditable dimensions. Decision impact on people is the dominant dimension: a process producing legal or significant effects under GDPR Art. 22, or falling in an EU AI Act Annex III category such as hiring, credit, education, essential services or law enforcement, is Critical regardless of volume. Reversibility elevates where the decision is difficult or impossible to undo once acted upon, which is what separates a rejected application from a drafted email. Throughput elevates because scale converts a modest error rate into a material population harm, and because it is the dimension that most reliably degrades oversight. Oversight burden elevates where the human review load per reviewer is high enough that meaningful scrutiny is doubtful, which is a property of the process design rather than of the reviewers. Fallback viability elevates where there is no workable manual path, since a process that cannot be suspended cannot be governed. Publish the rubric and re-derive when volume, population or decision scope changes.
B) Calibrate oversight design and control intensity per tier
Publish a tier-treatment matrix covering per tier: oversight model, ranging from post-hoc sampling through mandatory review before effect to dual review for Critical; the reviewer's authority, information and time budget per decision, stated numerically rather than as a principle, because an oversight arrangement that does not specify how long a reviewer has is an arrangement that will be compressed until it is meaningless; escalation path and the criteria that force escalation; contestability and appeal route where the decision affects a person; testing obligations including decision-quality sampling and adversarial review; monitoring detections; fallback exercise cadence; and re-review triggers. Add the consumption row: report cost per transaction inclusive of review time per tier, and set a reviewer load ceiling per tier above which the process must be redesigned rather than the reviewers exhorted. Treat a volume increase, a population change, a model change or an oversight reduction as a material change triggering re-review, including when the oversight reduction was justified as an efficiency gain.
C) Measure whether oversight can refuse, and report per tier
Instrument the oversight arrangement itself rather than its existence. Record per process and per reviewer: review volume per reviewer per day, override or rejection rate, median decision latency, escalation rate and escalation precision, and the proportion of decisions that reach effect without any human touch. Report these per tier quarterly alongside inventory state, fallback exercise currency and per-tier service-level adherence. A sustained override rate near zero at high volume is the signature of rubber-stamping and should be treated as a finding rather than as evidence of model quality, and the same is true of a decision latency that implies less time per item than reading it would take. Pair the override rate with sustained-override rate and escalation precision, because override rate alone is gameable once it becomes a target. Maintain a tier-movement log recording the triggering dimension, and review it quarterly with the business sponsor.
Outcome Metrics (L2)
| Metric | Baseline | L2 Target | Source |
|---|---|---|---|
| AI-enabled processes carrying a current tier assignment | L1 inventory coverage | 100% of mapped processes, with tier age under 12 months | Process inventory tier field |
| Critical-tier processes whose oversight arrangement specifies reviewer authority, information and time budget numerically | first oversight design audit | 100% | Process inventory oversight specification field |
| Critical- and High-tier processes with a fallback exercised within the last 12 months | first fallback exercise round | 100% of Critical, ≥90% of High | Fallback exercise log with dates |
| Decision-affecting processes with a documented and reachable contestability route | first contestability review | 100% | Process inventory cross-referenced with customer-facing appeal channels |
| Per-tier service-level adherence across review, testing, monitoring and issue management | first quarter of per-tier telemetry | ≥90% per tier | Program telemetry from each practice's log |
Process Metrics (leading)
- Tier re-derivation triggers on volume, population or decision-scope change, and each run is logged.
- Oversight telemetry collected continuously per reviewer, not sampled at audit time.
- Fallback exercises scheduled and completed per the tier cadence, with results recorded.
- Oversight-reduction changes routed to re-review inside the tier window regardless of their stated justification.
Effectiveness Metrics (business value)
- Cost per transaction including review time falls at Low and Medium tiers without oversight metrics degrading at Critical.
- Contested and overturned decisions fall as oversight design improves, reported per tier.
- Documented cases where oversight metrics surfaced rubber-stamping before a decision-quality incident.
- Fallback exercise results improve, measured as time to suspend and resume service.
Oversight Metrics (the HAI control, measured)
| Metric | Oversight failure it detects | Source |
|---|---|---|
| Override or rejection rate per reviewer, paired with sustained-override rate | rubber-stamping, where approval is recorded without review; pairing with sustained-override rate counters the gaming that follows once override rate becomes a target | Workflow system review records per reviewer |
| Review volume per reviewer per day against the tier's published ceiling | approver overload, where scrutiny cannot survive the volume regardless of reviewer diligence, which is a process design defect rather than a personnel one | Workflow system review records aggregated per reviewer |
| Median decision latency per item against the tier's stated time budget | pro-forma approval, where the time taken per item is less than the time required to read it | Workflow system decision timestamps |
| Escalation rate and escalation precision | escalation blindness, where reviewers never escalate, or escalate indiscriminately so that escalation carries no signal | Workflow escalation records with downstream disposition |
Consumption Metrics (denominated, never absolute spend)
| Metric | Denominator | Economic failure it detects | Source |
|---|---|---|---|
| Cost per completed transaction inclusive of human review time, by tier | per business transaction completed | AI cost reductions achieved by displacing work onto reviewers, which reads as efficiency until review burden and total unit cost are reported together | Consumption ledger joined to workflow review-time telemetry and process tier |
| Cost per human-in-the-loop review against the tier reviewer-load ceiling | per HITL review | oversight degrading economically before it degrades visibly, as review cost per item is squeezed toward the point where meaningful scrutiny is not purchasable | Workflow review records joined to the consumption ledger |
| Assured Spend Ratio for process AI consumption at Critical tier | per dollar of process AI consumption within the tier | AI consumption in decision-affecting processes flowing through systems the program has not mapped, which is the highest-consequence form of shadow AI in this domain | Consumption ledger joined to the process inventory |
Level of Effort (incremental over the level below)
- Stand-up: 160 hours · Ongoing: 120 hours/quarter
- Program Manager / Practice Lead — primary, 24 days/year
- Business Owner / PM — regular, 22 days/year
- Compliance / Audit — regular, 16 days/year
- Legal / Privacy Counsel — regular, 10 days/year
- Executive Sponsor — low, 4 days/year
- Material new tooling: Oversight telemetry from the workflow system, per reviewer rather than aggregate, Fallback exercise scheduling and recording
Success Criteria
- A process tier rubric is published and applied to 100% of mapped processes, re-derived on volume, population or decision-scope change.
- A tier-treatment matrix is published specifying oversight model, reviewer authority, information and numeric time budget, escalation, contestability, testing and fallback cadence.
- Oversight is measured continuously per reviewer, with override rate paired against sustained-override rate and escalation precision.
- Every Critical-tier process has exercised its fallback within the last 12 months and has a reachable contestability route.
- Cost per transaction inclusive of review time is reported per tier, with a published reviewer-load ceiling per tier.
Maturity Level 3, Industry-Leading
Objective: Derive process decision mapping and oversight telemetry from live workflow signals, benchmark decision quality and unit economics externally, and compute the transformation return.
At this level the process picture is maintained by the workflow systems themselves. Decision points, oversight arrangements and tier inputs derive from workflow telemetry rather than from interview cycles, so a process whose volume doubled or whose human review quietly stopped surfaces within days. Decision quality and oversight effectiveness are benchmarked externally, which is the only way to know whether an override rate is healthy for the decision type. The transformation return is computed from the per-transaction ledger against the pre-AI baseline, which is the honest test of whether AI-enabling the process delivered what it was funded on.
Dependencies
- Required: SM-Processes-L2, ML-Processes-L2, EG-Processes-L2
- Alignment (not blocking): FinOps at Run maturity for per-transaction cost attribution
- Supports / unblocks: Every other Processes-domain practice at L3, which inherits automated decision mapping and oversight telemetry
Desired Outcomes
- Decision points, oversight arrangements and tier inputs derive from workflow telemetry rather than from periodic interview cycles.
- A process whose oversight has quietly degraded surfaces within days rather than at the next assessment.
- Decision quality and oversight effectiveness are benchmarked against peers for the same decision type.
- The transformation return is computed per transaction against the pre-AI baseline rather than asserted from throughput.
- The organization contributes oversight design patterns and decision-quality methods back to the ecosystem.
Activities
A) Derive process mapping and oversight state from workflow telemetry
Instrument the workflow and case-management systems to emit the facts the inventory needs, rather than re-collecting them by interview. Emit per decision: which step invoked AI, whether the output was accepted, modified or rejected, which reviewer acted, how long they took, whether the decision reached effect without human touch, and whether it was later contested or overturned. From this, derive tier inputs continuously, since volume, population and oversight burden all change without anyone filing a change request. Publish a data-quality objective covering detection of a material oversight change within 5 business days, which is the interval that matters because oversight degrades gradually rather than abruptly. Wire tier increases to open downstream obligations automatically. Reserve human curation for processes spanning systems that cannot emit telemetry, which will remain a real category in most organizations and should be recorded as such rather than quietly assumed covered.
B) Benchmark decision quality and oversight effectiveness externally
Publish a semi-annual brief comparing the program against named peers on at least five metrics: process coverage, override rate by decision type, reviewer load against ceiling, contested-and-overturned rate, and cost per transaction inclusive of review. Benchmarking matters more here than anywhere else in the model because the provisional oversight thresholds are exactly that, provisional, and almost certainly vary by decision type: an override rate that indicates healthy scrutiny in credit adjudication may indicate a broken model in content moderation. Only cross-organization comparison for the same decision type can calibrate them, which is why contributing data matters as much as consuming it. Draw from sector bodies, regulatory working groups where they exist for the decision type, professional associations for the relevant function, and the FinOps Foundation for unit economics. Name the cohort, defend its selection, and publish where the program trails.
C) Compute the transformation return and contribute oversight methods
Compute the return honestly from the per-transaction ledger against the pre-AI baseline captured at L1, covering: change in fully loaded cost per completed transaction including review time and rework, not AI spend alone; change in decision quality measured as contested-and-overturned rate; change in cycle time; and avoided loss from contained decision-quality incidents. Report the result even when it is unfavourable, because a process whose fully loaded unit cost rose after AI enablement is a finding the organization needs and will not get from a throughput dashboard. Reconcile with Finance annually. Separately, contribute at least four externally accepted artifacts per year weighted toward the calibration problem: oversight design patterns with measured outcomes, override-rate and reviewer-load data by decision type contributed to sector bodies and regulatory consultations, contestability and appeal route patterns, and EU AI Act Art. 14 human oversight implementation guidance. Anonymize and legally vet every submission.
Outcome Metrics (L3)
| Metric | Baseline | L3 Target | Source |
|---|---|---|---|
| Process decision points and oversight state derived from workflow telemetry rather than interview | L2 interview-derived coverage | ≥80% telemetry-derived, with the non-emitting remainder explicitly listed | Workflow telemetry pipeline joined to the process inventory |
| Time to detect a material oversight change | L2 quarterly review interval | ≤5 business days at the 90th percentile | Oversight telemetry change-detection log |
| Peer-comparable metrics in the semi-annual brief, including override rate by decision type | 0 | ≥5 metrics with a named and defended peer cohort | Published benchmarking brief |
| Fully loaded cost per completed transaction against the pre-AI baseline | pre-AI baseline captured at L1 | computed and published per process annually, including where the result is unfavourable | Per-transaction ledger joined to workflow review-time and rework telemetry |
| Externally accepted oversight and decision-quality contributions per year | 0 | ≥4 accepted, weighted toward threshold-calibration data | Contribution log with external acceptance references |
Process Metrics (leading)
- Workflow telemetry feed freshness and error rate monitored, with alerting on staleness breach.
- Oversight change detection runs continuously rather than at review time.
- Processes on systems that cannot emit telemetry are listed explicitly and reviewed quarterly by interview.
- Contribution pipeline carries at least two artifacts in draft or external review.
Effectiveness Metrics (business value)
- Sponsor and business-owner decisions cite benchmark deltas for the relevant decision type rather than internal averages.
- Contested-and-overturned rate falls as oversight design improves, reported per tier and decision type.
- Computed transformation return reconciles with Finance annually and is published including unfavourable results.
- External adoption of published oversight design patterns.
Oversight Metrics (the HAI control, measured)
| Metric | Oversight failure it detects | Source |
|---|---|---|
| Override rate by decision type, benchmarked against the peer cohort for that decision type | rubber-stamping judged against a universal threshold that does not fit the decision type, which either masks a broken oversight arrangement or condemns a healthy one | Workflow review records compared against the semi-annual benchmarking brief |
| Oversight degradation detection latency | oversight eroding gradually as volume grows or staffing changes, which no periodic assessment catches because each individual month looks like the last | Oversight telemetry change-detection log |
| Contested-and-overturned rate, per tier and decision type | oversight that records approvals at healthy rates while the decisions it approved are being reversed downstream, which is the outcome measure that override rate only proxies | Case management contest and appeal records joined to decision records |
Consumption Metrics (denominated, never absolute spend)
| Metric | Denominator | Economic failure it detects | Source |
|---|---|---|---|
| Fully loaded cost per completed transaction against the pre-AI baseline, including review and rework | per business transaction completed | an AI-enabled process that is cheaper in AI spend and more expensive overall once review time and rework are counted, which throughput and spend dashboards both conceal | Per-transaction ledger joined to workflow review-time and rework telemetry |
| Cost per completed transaction benchmarked against the peer cohort for the same process type | per business transaction completed | an internally improving unit cost that remains well above what peers achieve, which internal trend lines are structurally unable to reveal | Per-transaction ledger compared against the semi-annual benchmarking brief |
| Avoided loss from contained decision-quality incidents | per contained incident | decision-quality drift running long enough to affect a material population, where time to detect is the whole of the harm | Incident records joined to decision volume and the per-transaction ledger |
Level of Effort (incremental over the level below)
- Stand-up: 210 hours · Ongoing: 80 hours/quarter
- Program Manager / Practice Lead — primary, 18 days/year
- Business Owner / PM — regular, 20 days/year
- DevOps / Platform Engineer — regular, 14 days/year
- Compliance / Audit — low, 8 days/year
- Executive Sponsor — low, 3 days/year
- Material new tooling: Workflow and case-management telemetry emission per decision, Contest and appeal outcome linkage back to originating decisions
Success Criteria
- Process decision points and oversight state are telemetry-derived at 80% or better, with the non-emitting remainder explicitly listed rather than assumed covered.
- A material oversight change is detected within 5 business days at the 90th percentile.
- A semi-annual benchmarking brief covers at least five peer-comparable metrics including override rate by decision type, with the cohort named and defended.
- Fully loaded cost per completed transaction is computed against the pre-AI baseline and published annually including unfavourable results.
- At least four externally accepted contributions per year, weighted toward oversight threshold-calibration data.
Key Success Indicators
Level 1:
- A charter is published and jointly sponsored by the CISO and a business leader, with business-process owners constituting the working group.
- One AI-enabled process inventory covers all seven archetypes at 80% coverage or better against the business process register within 12 months.
- Every AI-enabled process has a named accountable business owner and a defined unit of business work.
- No decision-affecting process lacks a documented Art. 22 safeguard, and every such process has a testable human oversight arrangement.
- A per-transaction ledger is open recording AI cost per unit of business work with human review time tracked alongside.
Level 2:
- A process tier rubric is published and applied to 100% of mapped processes, re-derived on volume, population or decision-scope change.
- A tier-treatment matrix is published specifying oversight model, reviewer authority, information and numeric time budget, escalation, contestability, testing and fallback cadence.
- Oversight is measured continuously per reviewer, with override rate paired against sustained-override rate and escalation precision.
- Every Critical-tier process has exercised its fallback within the last 12 months and has a reachable contestability route.
- Cost per transaction inclusive of review time is reported per tier, with a published reviewer-load ceiling per tier.
Level 3:
- Process decision points and oversight state are telemetry-derived at 80% or better, with the non-emitting remainder explicitly listed rather than assumed covered.
- A material oversight change is detected within 5 business days at the 90th percentile.
- A semi-annual benchmarking brief covers at least five peer-comparable metrics including override rate by decision type, with the cohort named and defended.
- Fully loaded cost per completed transaction is computed against the pre-AI baseline and published annually including unfavourable results.
- At least four externally accepted contributions per year, weighted toward oversight threshold-calibration data.
Common Pitfalls
Level 1:
- ❌ Staffing the working group with technologists, which produces an inventory of systems rather than of decisions and leaves the program with no authority over the processes it governs.
- ❌ Recording that a human reviews the output without recording whether that human has the authority, information and time to refuse it.
- ❌ Omitting the unit of business work, which leaves every consumption metric in the model without a denominator.
- ❌ Reporting throughput gains without review burden, so cost displaced onto human reviewers reads as efficiency.
- ❌ Documenting a fallback without ever exercising it, so its viability is first tested during the outage it exists for.
Level 2:
- ❌ Tiering by transaction volume alone, which rates a high-volume content-drafting workflow above a low-volume credit decision.
- ❌ Specifying oversight as a principle rather than numerically, so the reviewer's time per item is compressed until scrutiny is impossible and nothing in the design objects.
- ❌ Reading a near-zero override rate as evidence of model quality rather than as the signature of rubber-stamping.
- ❌ Using override rate as a standalone target, which reliably produces manufactured overrides within a quarter.
- ❌ Reducing oversight as an efficiency measure without routing the change through re-review, because the saving is visible and the risk is not.
Level 3:
- ❌ Claiming telemetry-derived coverage while quietly excluding processes on systems that cannot emit, which turns a coverage metric into a selection effect.
- ❌ Applying one override-rate threshold across all decision types, when the healthy rate for credit adjudication and content moderation are not the same number.
- ❌ Computing the return from AI spend alone, which reliably produces a favourable answer and an inaccurate one.
- ❌ Suppressing unfavourable return results, which destroys the credibility of every favourable one that follows.
- ❌ Monitoring override rate without contested-and-overturned rate, so approvals look healthy while the decisions behind them are being reversed.
Practice Maturity Questions
Level 1:
- Is there a published charter jointly sponsored by the CISO and a business leader, with the working group constituted around business-process owners and explicit decision rights over introducing AI into a decision path and suspending an AI-enabled process?
- Does one inventory map every AI-enabled process across the seven archetypes, recording the decision AI contributes, whether it advises or decides, the human oversight arrangement, the affected population, legal or significant effect, and the fallback, at 80% coverage or better against the business process register?
- Is a unit of business work defined for every AI-enabled process, and is a per-transaction ledger open recording AI cost per unit against the pre-AI baseline with human review time tracked alongside it?
Level 2:
- Is every AI-enabled process assigned a tier from a published rubric covering decision impact on people, reversibility, throughput, oversight burden and fallback viability, re-derived when volume, population or decision scope changes?
- Does the tier-treatment matrix specify the reviewer's authority, information and time budget numerically for every Critical-tier process, along with escalation criteria, contestability route, testing obligations and fallback exercise cadence?
- Is human oversight measured continuously per reviewer covering override rate paired with sustained-override rate, review volume against a published ceiling, decision latency against the stated time budget, and escalation precision, and is a sustained near-zero override rate at high volume treated as a finding?
Level 3:
- Are decision points and oversight state derived from workflow telemetry at 80% or better against a published objective of detecting a material oversight change within 5 business days, with processes on non-emitting systems listed explicitly rather than assumed covered?
- Does the semi-annual benchmarking brief compare override rate, reviewer load and contested-and-overturned rate by decision type against a named peer cohort, acknowledging that the provisional oversight thresholds require cross-organization calibration per decision type?
- Is the transformation return computed as fully loaded cost per completed transaction including review and rework against the pre-AI baseline, published annually including unfavourable results, and reconciled with Finance?
Lightweight Questions (E0 rung)
Answerable yes/no by one person in under 30 seconds, with nothing open.
Level 1:
- Can you list the business processes where AI now makes or shapes a decision?
- Does every AI-enabled process have a named business owner?
- Do you know what one unit of work costs in your AI-enabled processes?
Level 2:
- Does every AI-enabled process carry a risk tier?
- Do you know how often your reviewers actually reject an AI recommendation?
- Has any high-impact AI process fallback been exercised this year?
Level 3:
- Does your oversight data come from the workflow system or from a survey?
- Would you notice within a week if reviewers stopped rejecting anything?
- Do you know whether AI made your process cheaper once review time is counted?
Tracking
Level 1 — Jira Epic, labels haiamm-sm-processes-l1, haiamm-governance
- Done when: Process inventory coverage at or above 80% against the business register with zero AI-enabled processes lacking an owner, a defined unit of business work, or an Art. 22 safeguard where the decision affects a person.
- Git artifacts:
process-governance/ai-process-inventory.json,process-governance/ai-process-charter.md,process-governance/unit-of-work-definitions.json,finops/per-transaction-ledger.json - Git signal: unit-of-work-definitions.json carries an entry for every process in the inventory, and per-transaction-ledger.json joins to it on the process key rather than carrying its own denominators.
- CI check:
process-denominator-check
Level 2 — Jira Epic, labels haiamm-sm-processes-l2, haiamm-governance
- Done when: Process tier coverage at 100% with every Critical-tier process carrying a numerically specified oversight arrangement and a fallback exercised within 12 months, sustained across two quarters.
- Git artifacts:
process-governance/process-tier-rubric.md,process-governance/tier-treatment-matrix.md,process-governance/fallback-exercise-log.json,process-governance/oversight-telemetry.json - Git signal: oversight-telemetry.json is regenerated from workflow system records per reviewer rather than aggregated by hand, and fallback-exercise-log.json carries a dated result per Critical-tier process.
- CI check:
oversight-metrics-check
Level 3 — Jira Epic, labels haiamm-sm-processes-l3, haiamm-governance
- Done when: Telemetry-derived decision and oversight coverage at or above 80% with oversight change detection within 5 business days at the 90th percentile, sustained two quarters, and the transformation return published annually.
- Git artifacts:
process-governance/telemetry-pipeline/,process-governance/non-emitting-processes.json,governance/benchmarking-brief.md,finops/transformation-return.json - Git signal: non-emitting-processes.json is maintained as an explicit exclusion list reviewed quarterly, and transformation-return.json is regenerated from ledger and workflow data rather than hand-authored.
- CI check:
process-telemetry-coverage
Mappings
| Level | HAI TTP | ATLAS | OWASP LLM 2025 | Compliance |
|---|---|---|---|---|
| L1 | EA | AML.T0048 | LLM06, LLM09 | GDPR Art. 22; EU AI Act Annex III; EU AI Act Art. 14; EU AI Act Art. 26; ISO/IEC 42001 8.2; NIST AI RMF GOVERN 3.2 |
| L2 | EA, RA | AML.T0048 | LLM06, LLM09 | GDPR Art. 22; EU AI Act Art. 14; EU AI Act Annex III; EU AI Act Art. 26; ISO/IEC 42001 8.2; NIST AI RMF GOVERN 3.2; NIST AI RMF MANAGE 2.3 |
| L3 | EA, RA | AML.T0048 | LLM06, LLM09 | GDPR Art. 22; EU AI Act Art. 14; EU AI Act Art. 72; EU AI Act Annex III; ISO/IEC 42001 9.1; NIST AI RMF MEASURE 2.8 |
Document Version: HAIAMM v3.5 (generated) / Practice: Strategy & Metrics (SM) / Domain: Processes
✓ Interactive Self-Assessment
Answer each question based on your current, implemented practices only. Progress saves automatically in your browser.