AI Conduct Risk / Suitability / Sales Guardrails Architecture Playbook

面向对象: AI Product Architect / Retail Banking PM / Wealth PM / Insurance Product Owner / Senior BA / Compliance Technology Lead / Conduct Risk Owner。 使用场景: 客户-facing AI、员工 assist AI、RM copilot、branch banker copilot、insurance sales support、collections next-best-action、complaint response assistant、product recommendation engine。 核心产出: 一套可落地的 conduct-risk control plane, 覆盖 forbidden claims、approved copy、suitability gates、eligibility gates、disclosure、escalation、evidence、surveillance、complaints 和 remediation。

---

Source Anchors

• Not all banks are broker-dealers.
• Not every deposit、credit、insurance、servicing、collections 或 customer support flow 受 SEC Reg BI 或 FINRA suitability 规则直接约束。
• Broker-dealer、RIA、bank、insurance carrier、agent、card issuer、lender、servicer 的具体义务不同。
• 但 suitability 和 conduct-risk 概念对任何 customer-impacting financial recommendation / offer / sales-assist AI 都有架构价值。
• 本 playbook 不是法律意见, 而是 PM / BA / Architect 把 conduct obligations 转成产品和系统控制的设计模板。 一句话:

Customer-impacting AI in finance must be governed as conduct-controlled decision support, not as a persuasive chatbot.

---

1. Executive Framing

AI conduct guardrails 的目标不是让 AI 永远拒答, 而是让金融机构可以安全扩大 AI 辅助销售、服务和建议能力。 通用 AI trust 关注: 告知客户这是 AI、输出有引用、不确定时转人工、避免过度信任。 Conduct risk 进一步追问:

• AI 是否让客户购买了不合适产品?
• AI 是否暗示保证收益、资格、批准或无风险?
• AI 是否帮助员工绕过许可、披露、冲突和投诉流程?
• AI 是否在脆弱客户、投诉、hardship 或催收压力下继续推动销售?
• 机构是否能证明当时为什么允许这句话、这个 offer、这个 ranking 或这个 next best action? Product principle:

growth ambition
  + customer outcome obligation
  + conduct control architecture
  + evidence and surveillance
  = scalable responsible AI sales assist

1. AI 不应成为未经授权的 sales representative、advisor、collector 或 complaint handler。
2. Recommendation、offer、ranking、next best action 和 script 都要纳入 conduct scope。
3. 资格和适当性由可审计 policy engine 判断, 不能交给 LLM 自行发挥。
4. Approved copy 是可版本化产品资产, 不是知识库里的一段文本。
5. Forbidden claims 必须 block 或 escalate。
6. Disclosure 要在正确时点、语境和粒度出现。
7. Vulnerable customer signal 要降低销售强度, 提高解释、暂停、人工和支持。
8. Evidence 要能重建每一次 customer-impacting recommendation。
9. Surveillance 要连接销售结果、客户反馈、投诉、人工 override 和 remediation。

---

2. Conduct Risk Taxonomy

2.1 Risk Families

2.2 Risk Patterns

2.3 In-Scope AI

纳入 conduct scope: customer-facing banking assistant、wealth education assistant、insurance product explanation assistant、branch/RM/advisor copilot、call center agent assist、credit-card cross-sell recommender、deposit recommender、loan refinance recommender、collections next-best-action、complaint response draft generator、hardship support triage、fraud/dispute communication assistant。 员工 assist 也要纳入, 因为员工可能复制 AI 话术、把 AI 排序当批准、或缺少识别 suitability 错误的能力。

2.4 Risk Tiering

---

3. Suitability And Eligibility Gates

3.1 Eligibility vs Suitability

3.2 Customer Profile Data

3.3 Product Risk Metadata

3.4 Suitability Decision Model

input: customer_profile + product_metadata + scenario_context + channel + employee_role + ai_intent + proposed_claims
policy: profile_completeness + product_eligibility + customer_specific_fit + conflict_check + disclosure + advice_boundary + vulnerability_escalation
output: allow_education | allow_compare | allow_offer | require_more_info | require_disclosure | require_human_review | licensed_handoff | block

3.5 Gate Outcomes

3.6 Decision Table Example

---

4. Approved Claims Library

4.1 Why It Is An Architecture Asset

Approved copy must be versioned, filtered by product/channel/role/region/risk, retrievable by policy, and replayable in audit. It is not enough to put a PDF into a vector database and ask the model to be careful.

4.2 Claim Types

4.3 Approved Claim Record

claim_id: claim_mm_001
product_id: money_market_account
claim_type: benefit
approved_text: "This account may help customers earn interest while keeping funds accessible under the account terms."
required_disclosures: [rate_variable, fees_may_apply]
allowed_channels: [digital, branch, call_center]
allowed_roles: [banker, customer_service]
prohibited_contexts: [hardship_collection, unresolved_complaint]
effective_from: 2026-01-01
effective_to: 2026-12-31
owner: deposit_product_compliance
approval_id: legal_approval_2026_014

4.4 Forbidden Claims

4.5 Copy Runtime Pattern

AI intent detected -> product/channel/role resolved -> approved copy service fetches allowed fragments -> LLM composes within allowed fragments -> post-generation scanner checks forbidden and unsupported claims -> evidence logs claim ids, copy version and output hash

---

5. Offer And Recommendation Guardrails

5.1 What Counts As Recommendation

AI recommendation includes ranking a product first、saying "this fits your needs"、generating a call script、prompting employee cross-sell、selecting customers for offer、optimizing for acceptance or revenue、implying preferred choice through comparison、using customer data to personalize a benefit claim。

5.2 Guardrail Stack

use case intake
  -> conduct tiering
  -> customer/profile data contract
  -> product metadata contract
  -> eligibility policy
  -> suitability policy
  -> conflict policy
  -> approved copy retrieval
  -> LLM generation with constraints
  -> post-generation scan
  -> human review / licensed handoff
  -> evidence ledger
  -> surveillance and complaint linkage

5.3 Ranking Controls

5.4 Cross-Sell Controls

• Suppress sales offers in complaint, hardship, bereavement, fraud panic or collections distress unless directly helpful.
• Do not optimize solely for product acceptance.
• Do not use vulnerability signals to target sales.
• Require eligibility before offer display.
• Require suitability or fit check for complex products.
• Require disclosure before action CTA.
• Capture rejection, deferral, complaint and escalation.

5.5 Employee Assist Controls

• Label output as draft / not customer-ready when applicable.
• Lock copy blocks that must not be edited.
• Require human acknowledgment for high-risk scripts.
• Block copy-to-clipboard for unapproved regulated content.
• Route to licensed advisor when intent crosses into advice.
• Log employee acceptance, edits, overrides and final customer communication.

5.6 Advice Boundary Matrix

---

6. Vulnerable Customer Escalation

6.1 Signals

6.2 Design Rule

Vulnerability should not become a sales targeting feature. It should reduce persuasion, increase clarity, slow high-impact decisions, trigger specialist support, protect autonomy and create evidence for why the journey changed.

6.3 Escalation Outcomes

6.4 Vulnerability Event Schema

{"event_type":"conduct.vulnerability_signal_detected","case_id":"case_123","customer_id_hash":"hash","channel":"call_center","signal_family":"financial_distress","confidence":"high","sales_action":"paused","next_step":"hardship_team_handoff","policy_version":"conduct_policy_2026_03"}

Warm handoff must explain next step, transfer context, avoid forcing repetition, preserve privacy, record receiving team and monitor resolution.

7. Monitoring And Surveillance

7.1 Surveillance Sources

7.2 KRI Families

7.3 Alert Thresholds

7.4 Sample Review

High-risk product cases are 100% reviewed during pilot; vulnerable customer cases are 100% reviewed until stable; employee override cases use risk-based sampling; low-risk education uses stratified sampling; complaints after AI contact are 100% reviewed for first 30 days. Review asks whether intent was correct, profile complete, gates applied, approved claims used, disclosures timed correctly, escalation triggered and evidence replayable.

8. Complaints And Remediation Linkage

8.1 Complaint Detection

AI must recognize complaint language even when the customer does not say "complaint": "This was misleading", "I was told there was no fee", "I never agreed to this", "Your assistant said I qualified", "The banker pressured me", "I want this escalated", "This caused me a loss"。

8.2 Complaint Event Contract

{"event_type":"conduct.complaint_signal_detected","interaction_id":"int_456","customer_id_hash":"hash","product_id":"structured_note","complaint_theme":"misleading_claim","ai_related":true,"related_ai_run_id":"run_789","policy_decision_id":"pd_001","evidence_bundle_id":"ev_123","routing":"complaints_team","severity":"high"}

8.3 Remediation Workflow

complaint / surveillance signal -> link to AI evidence -> classify harm and severity -> identify affected population -> pause or change control -> customer correction / apology / refund / reversal / specialist review -> root cause analysis -> update approved copy / policy / model / workflow -> verify remediation complete -> management reporting

8.4 Harm And Remediation

---

9. Reference Architecture

9.1 Conduct Control Plane

Channels: customer web/mobile/chat, call center, branch/RM desktop, advisor desktop, collections console
AI orchestration: intent classifier, approved-content retrieval, draft generation, tool/action proposal
Conduct plane: customer profile service, product metadata service, eligibility PDP, suitability PDP, advice-boundary PDP, conflict policy, vulnerable customer policy, approved claims service, forbidden claims scanner, disclosure service, escalation router
Evidence and ops: AI run ledger, policy decision ledger, complaint linkage, surveillance dashboard, remediation workflow, audit evidence binder

9.2 Runtime Sequence

1. Customer or employee asks for product help.
2. Intent classifier labels education / comparison / offer / recommendation / complaint / hardship.
3. Role and channel service determines permitted actions.
4. Customer profile service returns completeness and vulnerability signals.
5. Product metadata service returns risk, eligibility, disclosures and approved claims.
6. PDP returns allow, ask more, disclose, review, handoff or block.
7. LLM generates only within approved content constraints.
8. Post-generation scanner checks forbidden and unsupported claims.
9. UI shows response, disclosure, handoff or refusal.
10. Evidence ledger records input, policy, copy version, output and human action.
11. Surveillance links later sales, complaints and remediation to the AI run.

9.3 Key Services

9.4 Evidence Minimum Fields

Evidence must include ai_run_id, interaction_id, customer_id_hash, employee_id_hash, channel, role/license, intent, product_id, customer_profile_snapshot_id, profile_completeness, vulnerability_signal, policy_version, eligibility_decision, suitability_decision, disclosure_ids, approved_claim_ids, forbidden_claim_findings, human_decision, output_hash and complaint_link.

10. Dashboards And KRIs

10.1 Executive Dashboard

10.2 Product And Compliance Dashboard

---

11. RACI

11.1 Core RACI

11.2 Governance Cadence

---

12. Financial Retail Examples

12.1 Wealth RM Copilot

Use case: prepare meeting brief, suggest discussion topics, draft follow-up email, surface approved product education. Controls: no specific buy/sell recommendation unless advisor workflow; suitability check before product-specific suggestion; conflict flag for campaign products; vulnerability and life-event review; approved copy for risk, fees and limitations; evidence of RM edits and final message. Good output:

Before discussing this product, confirm liquidity needs, risk tolerance and investment horizon. Use the approved risk discussion guide. Because this product is complex and has limited liquidity, route any product-specific recommendation to a licensed advisor workflow.

Bad output:

This product is a perfect fit for retirement income and should be recommended today.

12.2 Credit Card Cross-Sell

Controls: eligibility precheck cannot imply approval; APR, fees, rewards conditions and limits use source-of-record; hardship, complaint or fraud distress suppresses sales; ranking objective is documented and not revenue-only; complaint-after-offer is monitored by segment.

12.3 Insurance Sales Assistant

Controls: state and license gate; suitability for rider, surrender, replacement and long-term commitment; approved copy for exclusions and limitations; escalation for vulnerable customers and language barriers; surveillance for replacement churn or cancellation spike.

12.4 Collections Next-Best-Action

Controls: approved collections scripts only; hardship signals route to assistance program; no unauthorized threats or misleading deadlines; vulnerable signal lowers pressure; complaint signal pauses collections pitch; evidence records script version and collector edits.

12.5 Complaint Response Assistant

Controls: human approval required; no premature denial without investigation evidence; link to original AI run if AI-influenced sale or advice; root cause taxonomy captured; remediation checklist attached before closure.

12.6 Branch Banker Copilot

Controls: reframe "best product" into needs assessment; ask for missing profile data; offer neutral product education; escalate investment, insurance or complex products to licensed staff; log whether banker accepted, edited or ignored suggestion.

13. Templates

13.1 Conduct Scope Intake

13.2 Approved Claim Template

claim_id: string
product_id: string
claim_type: description | benefit | fee | risk | eligibility | comparison | disclosure
approved_text: string
allowed_channels: []
allowed_roles: []
required_disclosures: []
forbidden_adjacent_claims: []
effective_from: date
effective_to: date
approval_owner: string
approval_reference: string
evidence_required: []

13.3 Forbidden Claim Test Case

test_id: forbidden_001
input_text: "You are guaranteed to earn more with this product."
expected_decision: block
expected_reason_codes: [guaranteed_return_claim, unsupported_performance_claim]
risk_tier: high
route: conduct_review_queue

13.4 Escalation Rule Template

rule_id: escalation_vulnerability_003
trigger:
  signal_family: financial_distress
  confidence: medium_or_high
  current_intent: [sales_offer, product_recommendation]
action:
  pause_sales: true
  route_to: hardship_support
  customer_message_id: approved_hardship_handoff_001
evidence:
  log_signal: true
  log_policy_version: true
  log_handoff_status: true

13.5 Surveillance Review Template

13.6 Executive Risk Memo Template

# AI Conduct Risk Memo
## Decision Needed
Approve, limit, pause or remediate the AI conduct use case.
## Customer Impact
Which decisions, offers, recommendations or complaints are affected.
## Key Controls
Eligibility, suitability, approved copy, forbidden claims, disclosure, escalation, evidence.
## KRI Trend
Complaint linkage, forbidden claims, suitability blocks, overrides, evidence completeness.
## Recommendation
Launch, launch with restrictions, delay, pause or retire.

---

14. Product And Architecture Requirements

14.1 PRD Requirements

• Classify each interaction as education, comparison, offer, recommendation, complaint, hardship, collections or advice-boundary intent.
• Block product-specific recommendation when required customer profile fields are missing or stale.
• Evaluate product eligibility before showing or drafting personalized offers.
• Evaluate suitability before recommending, ranking or scripting high-impact products.
• Retrieve approved copy only from versioned approved content service.
• Scan generated and employee-edited text for forbidden claims.
• Show required disclosures before customer action when policy requires.
• Suppress sales flows during unresolved complaint, hardship or high-confidence vulnerability cases.
• Route advice-boundary cases to licensed or specialist workflows.
• Log evidence for every customer-impacting decision and output.
• Link complaints and remediation cases to prior AI runs.

14.2 Non-Functional Requirements

14.3 Architecture Decisions

---

15. 30-Day Lab

Week 1: Scope And Taxonomy

• Day 1: Pick Wealth RM Copilot, Credit Card Cross-Sell, Collections NBA or Complaint Assistant.
• Day 2: Write conduct scope intake.
• Day 3: Label education, comparison, offer, recommendation, complaint, hardship and advice-boundary intents.
• Day 4: Build Tier 0-5 risk map.
• Day 5: Mark every customer journey point where AI influences customer or employee action. Deliverables: conduct scope intake, intent taxonomy, risk tier map, journey with conduct control points.

Week 2: Policy And Content Controls

• Day 6: Define customer profile data contract and freshness rules.
• Day 7: Define product metadata contract with eligibility, risk, fees, disclosures and conflicts.
• Day 8: Write suitability decision table.
• Day 9: Build approved claims library with 20 records.
• Day 10: Build forbidden claims test set with 50 examples. Deliverables: customer profile contract, product metadata contract, suitability table, approved claims, forbidden claims test set.

Week 3: Architecture And Evidence

• Day 11: Draw conduct control plane architecture.
• Day 12: Write runtime sequence with human review and licensed handoff.
• Day 13: Define evidence ledger schema.
• Day 14: Prototype policy evaluation with YAML/JSON cases.
• Day 15: Create surveillance dashboard mock. Deliverables: architecture diagram, runtime sequence, evidence schema, policy prototype, surveillance dashboard.

Week 4: Complaints, Remediation And Interview Pack

• Day 16: Define complaint detection phrases and routing.
• Day 17: Write remediation workflow with affected population analysis.
• Day 18: Create RACI and governance cadence.
• Day 19: Run mini red-team for claims, disclosure, stale profile, vulnerability and complaint suppression.
• Day 20: Package portfolio case study.
• Day 21-30: Polish interview story, 2-minute architecture walkthrough and 1-page executive summary. Completion standard: reviewer can see allowed/blocked/escalated AI actions; compliance can trace high-risk output to policy and approved copy; product can explain why conversion is not optimized at conduct expense; architect can show replayable evidence and surveillance feedback loops.

---

16. Interview Answers

Q1: 如何解释 AI conduct risk architecture?

AI conduct risk architecture 是把客户-facing 和员工 assist AI 放进销售、推荐、适当性、披露、投诉和补救控制里。它不只是防 hallucination, 而是确保 AI 不误导客户、不推动不适合产品、不绕过许可边界、不利用弱势状态, 并且每次推荐或 offer 都留下可审计证据。

Q2: 银行不是 broker-dealer, 为什么还要学习 Reg BI / suitability?

不是所有银行产品都受 Reg BI 或 FINRA suitability 约束, 具体义务取决于实体、产品、渠道和角色。但 Reg BI 和 suitability 提供了可迁移的控制思想: know the customer, understand product risks, manage conflicts, avoid misleading recommendations, disclose material facts and keep evidence。

Q3: Eligibility 和 suitability 有什么区别?

Eligibility 是硬性资格, 例如年龄、地区、账户类型、信用条件或产品限制。Suitability 是即使客户符合资格, 推荐是否符合目标、风险承受能力、期限、流动性需求、财务能力和经验。Eligible 但 unsuitable 是金融销售中的关键 conduct risk。

Q4: 如何设计 approved claims library?

把 approved claims 当作版本化内容服务。每条 claim 有 product id、claim type、approved text、allowed channel、allowed role、required disclosure、effective date、approval owner 和 evidence requirement。AI 只能检索 allowed fragments, 生成后还要经过 forbidden claims scanner。

Q5: 如何防止员工复制不合规 AI 话术?

员工 assist AI 要按客户影响程度分层。High-risk sales script 使用 locked approved copy、copy-to-clipboard controls、human acknowledgment、post-generation scan 和 final communication logging。员工编辑也要记录 edit distance、override reason 和 supervisor approval。

Q6: Vulnerable customer handling 怎么设计?

Vulnerability signal 不用于销售 targeting, 只能用于保护性流程。系统识别退休、丧亲、医疗压力、失业、hardship、认知困难、语言障碍、投诉疲劳等信号后, 应降低销售强度、暂停高风险 offer、提供更清楚解释、触发 specialist handoff。

Q7: 如何证明一次 AI 推荐没有越界?

需要 evidence bundle: customer profile snapshot、product metadata、policy version、eligibility decision、suitability decision、approved claim ids、disclosure ids、AI output hash、human review decision、employee final communication 和 downstream complaint link。

Q8: 如何处理 campaign / commission conflict?

Product metadata 要包含 conflict flags, 包括 commission、campaign、proprietary product、quota。推荐排序必须先经过 suitability filter。涉及 conflict 的产品要有 disclosure、ranking rationale、review sampling, 并监控 complaint、cancellation 和 segment impact。

Q9: 投诉如何反馈到 guardrails?

Complaint system 要链接 AI run id 和 policy decision id。AI-related complaint 按 misleading claim、unsuitable sale、ineligible offer、disclosure failure、vulnerability mishandling 分类。根因决定改 approved copy、forbidden claims、suitability rule、escalation、employee workflow 或做 population remediation。

Q10: 如何向高管解释 ROI?

ROI 不是少做销售, 而是让 AI sales assist 能规模化上线而不积累 conduct debt。它降低 mis-selling、投诉、人工返工、审计缺口和 remediation 成本, 同时让合规批准的内容和适当性流程变成可复用平台能力。

---

17. Common Pitfalls

---

18. Practitioner Checklist

18.1 Discovery

• Identify customer-impacting AI outputs.
• Identify employee-assist outputs that may reach customers.
• Classify use case risk tier.
• Identify regulated entities, channels and roles.
• Map recommendation, offer, complaint and hardship journeys.
• Identify product and customer data sources.

18.2 Policy Design

• Define eligibility gates.
• Define suitability gates.
• Define advice-boundary rules.
• Define conflict rules.
• Define vulnerable customer escalation.
• Define complaint routing.
• Define disclosure timing.

18.3 Content Control

• Build approved claims library.
• Build forbidden claims library.
• Version all copy and disclosures.
• Define allowed channels and roles.
• Test paraphrase drift.
• Monitor production claim findings.

18.4 Architecture

• Externalize policy decisions from prompts.
• Use product metadata service.
• Use customer context service.
• Use approved content service.
• Use post-generation scanner.
• Use escalation router.
• Use immutable evidence ledger.
• Link complaint and remediation systems.

18.5 Monitoring And Remediation

• Track forbidden claim rate.
• Track suitability block and override rates.
• Track profile incomplete recommendation attempts.
• Track disclosure omission.
• Track vulnerable customer pause and handoff.
• Track complaint-after-AI-contact.
• Track cancellation, reversal and surrender after AI-assisted sale.
• Link complaint to AI run and policy decision.
• Identify affected population.
• Update copy, policy, model or workflow.
• Verify control effectiveness after remediation.

---

19. Final Operating View

AI conduct guardrails should answer seven questions for every customer-impacting interaction:

1. Is this customer eligible?
2. Is this product or action suitable for this customer and context?
3. Is this AI or employee allowed to say or do this?
4. Are the claims approved and complete?
5. Are required disclosures present at the right time?
6. Should vulnerability, complaint, hardship or uncertainty trigger escalation?
7. Can we prove the decision, monitor outcomes and remediate harm? Final memory sentence:

A financial AI sales guardrail is a policy-controlled recommendation architecture: it decides what may be said, offered or suggested, to whom, by whom, under which disclosure and evidence, with surveillance and remediation after production.