目录
AI Product Responsibility / Accountability Boundary / Decision Ownership Playbook
Applicable audience: Senior AI PM, AI Architect, Enterprise Architect, CBAP-level BA, Product Governance Lead, Model Risk Partner, Risk / Compliance Partner, Operations Owner, Vendor Owner, Platform Owner, and Financial Retail Business Owner.
Core question: how do teams execute responsibility boundary design so AI product promises, human accountability, vendor/platform responsibilities, release gates, customer recourse, and executive evidence are explicit before launch and measurable after launch?
Important note: this playbook is an execution guide for product, architecture, BA, and internal governance work. It is not legal advice, regulatory advice, audit opinion, model validation, contract interpretation, liability conclusion, or release approval. Formal decisions must be made by institution-authorized roles using applicable jurisdiction, product scope, customer impact, internal policy, contracts, and governance forums.
1. Source Anchors
Access discipline: official anchors reviewed for this learning artifact on 2026-06-30. Use these sources as governance and evidence design anchors, not as automatic compliance conclusions.
Anchor Official link Playbook use NIST AI Risk Management Framework https://www.nist.gov/itl/ai-risk-management-framework Structure responsibility work through Govern, Map, Measure, and Manage activities. ISO/IEC 42001 AI management system https://www.iso.org/standard/81230.html Define scope, roles, operation, performance evaluation, management review, and improvement. ISO/IEC/IEEE 42010 Architecture Description https://www.iso.org/standard/74393.html Create views for product promise, decision ownership, human oversight, vendor boundary, and evidence trace. ISO/IEC/IEEE 29148 Requirements Engineering https://www.iso.org/standard/72089.html Convert stakeholder needs and product claims into requirements, acceptance criteria, verification, validation, and traceability. OECD AI Principles https://oecd.ai/en/ai-principles Anchor human-centered values, transparency, robustness, safety, security, and accountability expectations.
2. One-Page Executive Summary
Responsibility boundary work converts vague AI governance into executable product decisions:
Product promise
-> AI behavior boundary
-> decision and action rights
-> human accountability
-> vendor/platform boundary
-> recourse and harm prevention
-> release gate evidence
-> residual risk ownership
-> post-release monitoring
The playbook has five operating principles:
Principle Execution meaning Start from promise Define what the product claims before debating model metrics Separate AI roles Retrieval, summarization, recommendation, decision, drafting, execution, and escalation carry different responsibilities Name decision rights Decision authority, action authority, exception authority, stop authority, and residual risk authority must be explicit Prove human accountability Humans need authority, evidence, capacity, training, escalation, and audit trail Tie boundary to recourse Customers must be able to challenge, correct, recover, or reach a human when AI influences high-impact outcomes
Recommended operating artifact set:
1. Responsibility Boundary Canvas
2. Product Promise Inventory
3. AI Behavior Boundary Matrix
4. Decision Ownership Map
5. Human Accountability Evidence Pack
6. Vendor / Platform Shared Responsibility Matrix
7. Customer Harm and Recourse Map
8. Release Gate Decision Record
9. Residual Risk Record
10. Executive Accountability Evidence Pack
3. Quick Start Workflow
Use this workflow for a new AI product, a material feature change, or a scale decision.
Step Output Owner Pass condition 1. Identify product promise Product promise inventory AI PM Claims, exclusions, customer/user audience, and evidence owner are explicit 2. Classify AI behavior AI behavior boundary matrix PM + BA + Architect AI role is classified as retrieve, summarize, classify, recommend, draft, decide, execute, or escalate 3. Map decisions and actions Decision ownership map BA + PM Decision authority and action authority are separated 4. Design human accountability Human accountability evidence pack Ops + PM + BA Reviewer authority, capacity, UI evidence, training, and escalation are proven 5. Define vendor/platform boundary Shared responsibility matrix Architect + Vendor / Platform Owner Data, model, logs, versioning, SLA, incident, and exit boundaries are documented 6. Link recourse and harm Harm and recourse map PM + Ops + Risk Customer challenge, correction, remediation, and evidence path are defined 7. Build release evidence Gate decision record PM + Architect + Risk Evidence supports release scope, conditions, exceptions, and stop triggers 8. Assign residual risk Residual risk record Business Owner + Risk Owner, scope, expiry, monitoring, and escalation are named 9. Launch with monitoring Boundary dashboard PM + SRE + Ops Breach signals trigger action 10. Review and improve Management action log Governance forum Actions close with evidence and product boundary is refreshed
4. Operating Model
4.1 Core Roles
Role Responsibility in this playbook AI PM Owns product promise, scope, user value, boundary narrative, release recommendation, and executive evidence CBAP-level BA Owns decision modeling, process impact, stakeholder needs, rules, exceptions, escalation, and traceability AI Architect Owns responsibility architecture views, system boundaries, logs, versioning, tool permissions, rollback, and platform controls Business Owner Accountable for business outcome, customer-impacting decisions, and residual risk within authorized scope Operations Owner Owns SOP, staffing, training, human review, queue management, escalation, and action closure Risk / Compliance Partner Challenges customer impact, control design, recourse, residual risk, and governance evidence Model Risk / Eval Lead Owns eval approach, model performance evidence, reviewer calibration, and critical failure analysis Vendor / Platform Owner Owns shared responsibility evidence, service monitoring, change notices, incident routing, and exit readiness Executive Sponsor Owns funding, strategic priority, scale/stop decision, and management action when residual risk exceeds appetite
4.2 Forum Design
Forum Frequency Decisions Boundary design workshop Before pilot or material change Product promise, AI role, decision ownership, human boundary Release readiness gate Before pilot, release, and scale Go, conditional go, hold, stop, or reduce scope Weekly boundary operations review During pilot and early launch Overrides, escalations, incidents, recourse, queue pressure Monthly product accountability review After launch Product promise evidence, residual risk, customer harm, vendor changes Quarterly management review Portfolio level Scale, restrict, retire, invest, update governance, refresh controls
5. Responsibility Boundary Canvas
Use this canvas as the first artifact.
Field Guidance Example use_case_id Stable identifier AI-DISPUTE-EVIDENCE-2026-01 business capability Capability affected Payment dispute operations product promise Specific claim Reduce incomplete dispute evidence packets customer-visible impact Money, access, eligibility, advice, explanation, delay, privacy, or none Potential dispute outcome and explanation internal user Role using AI Claims analyst AI behavior Retrieve, summarize, classify, recommend, draft, decide, execute, escalate Retrieve, summarize, recommend missing evidence prohibited AI behavior Actions AI must not perform Deny dispute, send final notice, issue credit human decision owner Role owning final case judgment Claims analyst / dispute operations lead action owner Role or system allowed to change state Dispute workflow after human approval vendor/platform dependency External or internal services Model gateway, RAG index, observability recourse owner Role owning customer challenge and recovery Dispute servicing owner residual risk owner Authorized owner Payments business risk owner release forum Decision forum AI release readiness forum stop authority Named role or forum Incident commander with business owner
Canvas acceptance standard:
Every customer-impacting action has a human or authorized system owner.
Every product promise has evidence and exclusions.
Every vendor/platform dependency has a responsibility boundary.
Every residual risk has owner, scope, expiry, and monitoring.
6. Product Promise Inventory
6.1 Inventory Structure
Field Required content promise_id Stable claim identifier audience Customer, employee, manager, executive, regulator-facing team promise_text Exact claim or intended message promise_type Speed, quality, consistency, safety, explanation, automation, education, advice boundary evidence_standard What proves the claim exclusion What the AI does not do owner PM or business owner accountable for claim review_date Date claim must be refreshed customer_visible Yes or no recourse_link Challenge or correction path if claim fails
6.2 Promise Examples
Weak claim Strong claim AI improves underwriting AI drafts a credit memo and checklist for underwriter review; it does not approve, decline, price, or send adverse notices AI resolves payment disputes AI organizes evidence and identifies missing items for analyst review; final outcomes remain in approved dispute workflow AI helps with AML AI summarizes alert evidence and drafts escalation rationale; authorized investigators decide SAR escalation AI gives wealth guidance AI provides educational content; it does not determine suitability or recommend a transaction AI automates KYC AI extracts and classifies onboarding documents; analysts own RFI and decline decisions
6.3 Promise Review Checklist
The claim is specific to a workflow, cohort, channel, and AI role.
The claim states what AI does not do.
The claim does not use model confidence as business certainty.
The claim does not imply legal, financial, credit, or investment advice unless approved through the appropriate product and governance path.
The claim has measurement evidence, not only user anecdotes.
Customer-facing language aligns with the actual decision boundary.
Internal training does not encourage users to over-rely on AI outputs.
7. AI Behavior Boundary Matrix
AI behavior Allowed examples Prohibited examples Evidence Retrieve Find approved policy, case facts, transaction records, or source documents Retrieve unauthorized customer records or stale policy source manifest, ACL test, retrieval QA Summarize Summarize documents, notes, calls, transactions, and evidence Omit required facts or present summary as final decision summary QA, edit history, missing fact test Classify Classify dispute type, alert typology, document completeness, or queue priority Classify protected or vulnerable status without approved use classification eval, false positive/negative analysis Recommend Suggest missing evidence, next review step, or escalation Recommend decline, fee, freeze, or investment action outside scope recommendation catalog, confidence calibration Draft Draft memo, narrative, response, checklist, or explanation support Send customer notice or regulator-facing document without review draft approval record, citation QA Decide Select outcome or eligibility Decide credit decline, KYC rejection, SAR filing, hardship denial, investment suitability unless formally approved decision authority record, model risk evidence Execute Change account, issue credit, freeze funds, send notice, update case Execute high-impact state change without authorization tool permission, action ledger, rollback test Escalate Route high-risk, low-confidence, or vulnerable-customer case to human Hide escalation path or route to unstaffed queue escalation trigger test, SLA report
Design rule: the higher the behavior moves from retrieve to execute, the stronger the authority, evidence, review, and recourse requirements become.
8. Decision Ownership Map
8.1 Map Structure
Decision or action AI role Decision authority Action authority Consulted Informed Evidence Start pilot Provides readiness evidence Business owner / release forum Product team Risk, Ops, Architect Executive sponsor gate memo Recommend case action Generates recommendation Human specialist Human specialist or workflow Policy owner Supervisor AI output, evidence, reason Send customer communication Draft support Authorized business or communications owner Workflow after approval Legal / Compliance as applicable Service team approved message, source trace Pause AI capability Alert signal Stop authority Platform owner executes PM, Risk, Ops Executive sponsor incident record, stop event Accept residual risk Provides uncertainty evidence Authorized risk/business owner Governance forum records Legal, Compliance, Model Risk as applicable Executive sponsor residual risk record
8.2 Decision Rights Tests
One role or forum has final decision authority.
The person pressing a button has authority to make that decision.
Tool execution cannot exceed the approved action authority.
Escalation route is staffed and has SLA.
Exceptions have a higher authority than standard decisions.
Residual risk owner is not the delivery team unless formally authorized.
Informed roles are not treated as approvers.
9. RACI and RAPID-Like Decision Rights
9.1 RACI Matrix
Activity PM BA Architect Business Owner Ops Risk / Compliance Vendor / Platform Executive Promise inventory A/R R C A C C I I AI behavior boundary A/R R R A C C C I Decision ownership map A/R A/R C A C C I I Human accountability design R R C A A/R C C I Vendor/platform boundary C C A/R A C C A/R I Harm and recourse map A/R R C A A/R C I I Release gate memo A/R R R A R R R I Residual risk record C R C A C A/R C A for material risk Stop trigger operation R C R A R C R I Scale decision R C C A R C C A
Legend: A = accountable, R = responsible, C = consulted, I = informed.
9.2 RAPID-Like Decision Table
Decision Recommend Agree Perform Input Decide Approve customer-visible boundary PM Legal / Compliance when applicable Product team BA, CX, Ops, Risk Business owner Release limited pilot PM Risk, Ops, Architecture Product and platform teams Eval, BA, Vendor Release forum Expand from recommendation to execution PM Risk, Compliance, Architecture, Ops Product and platform teams Model Risk, BA, customer evidence Business owner / governance forum Accept residual risk Risk partner prepares challenge Legal / Compliance / Model Risk when applicable PM tracks conditions Architect, Ops, Vendor Authorized risk or business owner Pause or rollback Incident lead Business and Risk Platform owner PM, Ops, Vendor Stop authority
10. Human Accountability Evidence Pack
10.1 Required Evidence
Evidence Description role charter Human reviewer role, authority, and limitations UI evidence view Screens or field list showing source evidence, AI output, confidence, limitations, and actions reviewer capacity model Expected volume, time per case, SLA, staffing, and queue aging thresholds AI literacy training Scenario-specific training on hallucination, automation bias, missing evidence, prompt injection, and escalation reviewer calibration Sample review exercises showing reviewers can identify AI errors and boundary breaches override reason taxonomy Reasons for accept, edit, reject, escalate, and request more information escalation runbook Trigger, route, SLA, owner, and case status during escalation stop authority record Who can pause route, model, workflow, tool, or full product audit trace What the reviewer saw, did, changed, and approved
10.2 Automation Bias Control Checklist
AI recommendation is not the only visually dominant item in high-impact review.
Source evidence and missing data are visible before final decision.
Reviewer can reject, edit, escalate, and request more evidence.
Accepting AI requires reason or policy confirmation for material decisions.
Review quality metrics are balanced against speed metrics.
Override and appeal outcomes are reviewed by segment and case type.
Low-confidence or conflicting evidence triggers escalation.
Reviewer training includes challenge cases and not only product use instructions.
Domain Product team owns Platform or vendor owns Evidence to collect Use-case scope Workflow, customer impact, accepted AI role Capability documentation and limitations scope memo, vendor documentation Data Allowed data, purpose, minimization, retention need Processing, storage, deletion, access logs as agreed data flow, retention record, access report Model version Approved model route and regression requirement Version support, change notice, service behavior version manifest, release note, regression result RAG / knowledge Source selection, policy owner, freshness rules Indexing, ACL enforcement, retrieval telemetry as agreed source manifest, ACL test, freshness report Tool use Permission tier, approval rules, action limits Tool gateway, auth, idempotency, trace tool permission matrix, action ledger Observability Metrics, thresholds, review cadence Logs, traces, dashboards, export telemetry schema, dashboard, export test Incident Customer impact assessment and remediation Service incident notification and root cause support incident notice, timeline, action closure Exit Replacement plan and migration decision Export, deletion, transition support as agreed exit test, export file, deletion proof
Vendor boundary acceptance standard:
Vendor claims are mapped to use-case requirements.
Contract or internal platform service commitments cover logs, changes, incidents, and support.
Regression is triggered by model, prompt, data, policy, tool, or vendor service change.
Exit path is credible for material dependencies.
12. Customer Harm and Recourse Map
12.1 Map Structure
Field Required content harm_scenario What can go wrong for the customer AI contribution Retrieve, summarize, classify, recommend, draft, decide, execute, escalate customer impact Money, access, delay, privacy, explanation, eligibility, advice, burden detection signal Complaint, appeal, override, queue aging, QA, monitoring, external inquiry recourse path How customer challenges or corrects remediation action Restore access, correct record, reimburse, reissue notice, rerun review, apologize, escalate evidence Logs, decision record, customer notice, remediation record, owner approval owner Role accountable for recovery recurrence control Product, process, model, policy, or training change
12.2 Recourse Checklist
Customer can reach a human for high-impact outcomes.
Customer can submit corrected or additional evidence.
Appeal or reconsideration uses the final decision record and AI trace where relevant.
Customer communication explains actionable next steps, not model mechanics.
Remediation owner has authority to correct accounts, records, notices, or fees within policy.
Batch impact analysis is possible when a model, prompt, source, or rule causes repeated harm.
Recourse signals feed back into eval, release gates, training, and product roadmap.
13. Release Gate Evidence
13.1 Gate Checklist
Gate Required evidence Decision options Opportunity problem baseline, promise inventory, owner fund discovery, redirect, stop Risk tier customer impact, data sensitivity, decision/action impact, reversibility low, controlled, material, high-impact Boundary AI behavior matrix, prohibited actions, decision rights approve scope, reduce scope, hold Human accountability reviewer authority, UI evidence, training, capacity, escalation ready, conditional, not ready Vendor/platform shared responsibility, SLA, change route, incident route, exit path approve dependency, add condition, replace Eval and UAT domain eval, critical failures, segment review, workflow UAT pilot, improve, hold Recourse harm map, appeal path, remediation evidence model ready, conditional, hold Release decision gate memo, residual risk, exceptions, stop triggers go, conditional go, no-go Launch monitoring dashboard, alert thresholds, rollback, stop authority continue, pause, rollback Scale production evidence, value, risk, recourse, vendor performance scale, restrict, redesign, retire
13.2 Gate Decision Record
Field Content gate_name Opportunity, pilot, release, launch, scale, or change gate decision_requested Pilot, release, scale, restrict, pause, rollback, retire scope Cohort, channel, region, customer segment, workflow, AI behavior product_promise Claims and exclusions reviewed evidence_reviewed Links to eval, UAT, architecture, vendor, oversight, recourse, monitoring accountable_owner Business owner accountable for outcome residual_risk_owner Authorized role accepting remaining risk conditions Scope limits, extra review, sampling, manual controls, traffic caps exceptions Open gaps with owner, expiry, compensating control stop_triggers Thresholds that pause, rollback, or escalate next_review Date, forum, and evidence required
14. Scenario Playbooks
14.1 Credit Underwriting Recommendation
Step Execution guidance Promise "AI drafts credit memo and policy checklist for underwriter review." Boundary AI may summarize, calculate from verified inputs, and recommend missing evidence; it may not approve, decline, price, or issue adverse action. Decision owner Underwriter owns recommendation; credit officer owns final decision. Human evidence Source documents, policy citations, ratio calculations, missing data, confidence limitations. Recourse Customer can correct data, provide evidence, and use appeal or reconsideration path. Release evidence Reason-code trace, fairness review, adverse explanation QA, override analytics, segment monitoring.
14.2 AML SAR Escalation Support
Step Execution guidance Promise "AI summarizes alert evidence and drafts escalation rationale for investigator review." Boundary AI may retrieve transactions, summarize notes, suggest typology tags; it may not file SAR or decide no-SAR. Decision owner Investigator owns disposition; financial crime governance owns SAR escalation standards. Human evidence Transaction timeline, typology source, confidence limits, contradictory evidence, prior case context. Recourse Customer recourse may be constrained; internal review, confidentiality, and evidence integrity are still required. Release evidence False negative review, typology coverage, confidentiality controls, investigator override, audit trace.
14.3 KYC Onboarding Decline / RFI
Step Execution guidance Promise "AI identifies missing or inconsistent onboarding evidence for analyst review." Boundary AI may extract, classify, and suggest RFI items; it may not decline onboarding or send final RFI without review. Decision owner Onboarding analyst owns RFI; KYC policy owner owns decline rules. Human evidence Document image, extraction confidence, policy requirement, customer-provided context. Recourse Customer can provide corrected documents, access assistance, and receive clear next steps. Release evidence Document accuracy by segment, language and accessibility review, RFI reason trace, abandonment monitoring.
14.4 Collections Hardship Treatment
Step Execution guidance Promise "AI suggests hardship support options within approved collections policy." Boundary AI may summarize hardship signals and suggest approved options; it may not threaten, deny support, or make unsupported promises. Decision owner Collections specialist owns treatment; supervisor owns exceptions. Human evidence Customer statement, account status, policy options, vulnerability flags, tone guidance. Recourse Customer can request human review, correct facts, and challenge treatment path. Release evidence Vulnerable customer safeguards, tone QA, complaint monitoring, hardship outcome review.
14.5 Robo-Advisor Education / Advice Boundary
Step Execution guidance Promise "AI provides educational content and helps customers prepare questions for advisors." Boundary AI may explain concepts; it may not recommend transactions, assess suitability, guarantee returns, or replace a licensed advisor. Decision owner Wealth product owner owns content boundary; licensed advisor owns advice interactions. Human evidence Approved content source, prohibited advice tests, escalation route to qualified human. Recourse Customer can report inaccurate content and reach human support. Release evidence Advice-boundary eval, suitability refusal tests, customer comprehension review, escalation metrics.
14.6 Payment Dispute Evidence Assistant
Step Execution guidance Promise "AI organizes dispute evidence and suggests missing information for analyst review." Boundary AI may summarize evidence, classify dispute type, and draft checklist; it may not deny dispute rights or issue final outcome. Decision owner Claims analyst owns recommendation; dispute operations owner owns final workflow. Human evidence Transaction record, customer statement, merchant evidence, network rule source, deadline indicator. Recourse Customer can submit additional evidence, appeal outcome, and receive clear explanation. Release evidence Deadline monitoring, evidence completeness QA, appeal upheld trend, customer communication review.
15. Liability and Residual Risk Evidence Pack
This pack supports internal governance and legal or compliance review without making legal conclusions.
Evidence category Required content product claims UI, training, sales, internal guidance, customer communications actual AI behavior Logs showing retrieve, summarize, classify, recommend, draft, decide, execute, or escalate human review What human saw, action taken, reason, edits, escalation, override decision authority Role, forum, policy, and approval trail vendor/platform dependency Service, version, change notice, incident, SLA, logs, data use control operation Evidence that controls existed and operated customer impact Affected cohort, money, access, delay, privacy, explanation, eligibility, burden recourse and remediation Customer challenge, correction, reimbursement, account restoration, notice management action When issue was known, decision made, actions assigned, closure evidence residual risk Owner, scope, expiry, monitoring, thresholds, escalation
15.1 Residual Risk Record
Field Example content risk_statement AI may omit one evidence category in complex dispute cases, causing incomplete analyst review affected_promise "Reduce incomplete dispute evidence packets" affected_customer_impact Potential delay or incorrect dispute outcome if analyst does not catch omission controls Required evidence checklist, analyst review, QA sample, appeal monitoring remaining_uncertainty Low-frequency complex cases not fully represented in eval set owner Payments business risk owner scope Pilot cohort, credit card disputes, English-language cases, 60 days expiry End of pilot review date monitoring Omission rate, analyst override, appeal upheld, customer complaints escalation Pause AI checklist recommendation if omission rate breaches threshold
16. Boundary Dashboard
Dashboard lane Metric Action threshold Promise evidence Claims with expired evidence or unsupported wording Refresh or remove claim before next release Human oversight Accept/edit/reject/escalate rate by reviewer and case type Investigate default acceptance or abnormal rejection Automation bias Median review time, evidence panel opens, challenge prompt completion Redesign UI or training if review is superficial Recourse Appeal rate, appeal upheld, time to correction, complaint trend Review decision boundary and customer communication Harm Customer impact events, near misses, segment disparity Escalate, pause, or remediate Vendor/platform Model changes, SLA breaches, incident notices, evidence export failures Trigger regression or dependency review Residual risk Open exceptions, expired risk acceptance, condition breaches Governance escalation Release Stop trigger status, rollback readiness, action closure Continue, restrict, pause, rollback
17. Anti-Pattern Review
Run this review before each release gate.
Anti-pattern Detection question Required correction Vague human accountability Can we name who decides, acts, escalates, pauses, and accepts residual risk? Update decision ownership map Model confidence misuse Are model scores presented as decision certainty? Add calibration, limitation, and evidence completeness design Advisory AI becoming automation Do users accept AI by default because workflow or metrics pressure them? Change UI, incentives, review sampling, and reason capture Vendor assurance overreach Are vendor claims treated as use-case proof? Map vendor evidence to internal requirements and eval Recourse missing Can the customer challenge or correct a high-impact outcome? Add recourse path and remediation evidence RACI dilution Are multiple roles marked accountable for one decision? Assign one accountable owner and clarify consulted roles No stop authority Who can pause the capability during harm or evidence breach? Name stop authority and implement switch Internal AI treated as low risk Does internal output influence customer-impacting decisions? Risk tier based on downstream impact Release without residual risk owner Are exceptions open without owner, expiry, or monitoring? Create residual risk record or hold release
18. Interview Answers
18.1 How would you build accountability boundaries for an AI product?
I would start with a product promise inventory and classify each AI behavior as retrieval, summarization, classification, recommendation, drafting, decisioning, execution, or escalation. Then I would map decision authority, action authority, human accountability, vendor/platform responsibility, recourse, release evidence, and residual risk ownership. The output is not a policy statement; it is a set of artifacts that can pass a release gate and support post-launch monitoring.
18.2 How do you avoid the weak answer "the human is responsible"?
I test whether the human has real authority, capacity, training, evidence, and escalation rights. If the UI hides source evidence, the queue pressure forces fast acceptance, or the reviewer cannot reverse or escalate, then the human is not meaningfully accountable. I would require reviewer calibration, override analytics, reason capture, and stop triggers.
18.3 What should a vendor own versus what the institution owns?
The vendor may own service commitments, model or platform operation within contract, change notices, data processing controls, support, and evidence export. The institution owns use-case suitability, product claims, customer impact, human oversight, recourse, release decisions, and residual risk. I make this explicit with a shared responsibility matrix.
18.4 How do accountability boundaries improve customer trust?
They prevent over-promising and make recovery possible. Customers trust systems when high-impact outcomes have clear explanation, human access, correction routes, appeal paths, and remediation. Accountability boundaries connect product claims to those paths and make the evidence reconstructable.
18.5 What evidence would you bring to an executive release forum?
I would bring the product promise inventory, AI behavior boundary, decision ownership map, human accountability pack, vendor/platform matrix, eval and UAT evidence, harm and recourse map, release gate memo, residual risk record, stop triggers, and launch dashboard. I would state what evidence supports release, what uncertainty remains, who owns it, and when the next review occurs.
19. Portfolio Exercise
Build a complete boundary pack for one of the six financial retail scenarios:
Credit underwriting recommendation.
AML SAR escalation support.
KYC onboarding decline or RFI support.
Collections hardship treatment.
Robo-advisor education versus advice boundary.
Payment dispute evidence assistant.
19.1 Required Portfolio Assets
Asset Content One-page executive memo Release recommendation, scope, evidence, uncertainty, residual risk owner Responsibility Boundary Canvas Use case, promise, AI behavior, decision/action owners, recourse, stop authority Product Promise Inventory Claims, exclusions, evidence standard, owner, review date Decision Ownership Map Decision authority, action authority, consulted, informed, evidence Human Accountability Evidence Pack UI evidence, training, calibration, capacity, escalation, audit trail Vendor / Platform Matrix Data, model, RAG, tool, logs, SLA, change, incident, exit Harm and Recourse Map Harm scenarios, detection, recourse, remediation, owner Release Gate Record Conditions, exceptions, stop triggers, next review Boundary Dashboard Mock Metrics, thresholds, owner, action rule
19.2 Scoring Rubric
Dimension Strong portfolio evidence Product thinking Promise is specific, valuable, bounded, and measurable BA discipline Decisions, rules, exceptions, and recourse are traceable Architecture discipline Logs, versions, permissions, rollback, and dependency boundaries are concrete Governance discipline RACI, RAPID-like rights, residual risk, and gate evidence are explicit Customer trust Harm prevention and recovery are designed before launch Executive narrative Memo explains evidence, uncertainty, options, and recommended decision
20. Implementation Calendar
Week Workstream Outputs Week 1 Promise and boundary discovery product promise inventory, AI behavior matrix, initial risk tier Week 2 Decision and human accountability design decision ownership map, RACI/RAPID, human accountability pack Week 3 Vendor/platform and architecture evidence shared responsibility matrix, evidence trace view, logging and rollback design Week 4 Harm, recourse, and release readiness harm map, recourse path, release gate record, residual risk record Week 5 Pilot launch and monitoring dashboard, stop triggers, weekly review cadence, action closure Week 6 Scale or restrict decision production evidence review, executive memo, updated boundaries
21. Final Acceptance Checklist
Use this checklist before release:
Product promise is specific and has exclusions.
AI behavior is classified and prohibited actions are documented.
Decision authority and action authority are separated.
Human reviewers have authority, capacity, training, evidence, and escalation.
Vendor/platform responsibilities are mapped and evidenced.
Customer harm scenarios and recourse paths are defined.
Release gates include evidence, conditions, exceptions, and stop triggers.
Residual risk has owner, scope, expiry, monitoring, and escalation.
Runtime dashboard can detect boundary breaches.
Executive memo states what is known, what remains uncertain, who owns it, and when it will be reviewed.
The practical standard: no material AI release should depend on a vague sentence like "the human remains accountable." The product should prove accountability through decision rights, evidence, recourse, and operating controls.