AI Conduct Risk / Suitability / Sales Guardrails Architecture Playbook

配对阅读：本手册的原理/架构解读版是 docs/ai-foundations/papers/118-ai-conduct-risk-suitability-sales-guardrails-architecture.md。先读 paper 建立机制与取舍，再用本手册落地为模板、RACI 与门禁，两者不需要重复精读。 核心导读: 金融销售、推荐、服务和催收场景中的 AI 不能只按通用 trust UX 管理, 必须被治理为 conduct-controlled decision support。 学习主线: 从 conduct risk taxonomy 出发, 系统化设计 eligibility / suitability gates、approved claims library、offer and recommendation guardrails、vulnerable customer escalation、surveillance、complaints、remediation 和 evidence ledger。 系统边界: 适用于客户-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 和 management review pack。

---

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 不是法律意见, 而是把 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 Control 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 Evidence 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 system evidence case study.
• Day 21-30: Polish decision narrative, architecture walkthrough and executive decision brief. 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. Decision Narrative

本节把 conduct-risk guardrails 组织成系统叙事。重点不是把概念压缩成回答, 而是说明每个控制如何约束推荐、话术、排序、升级、投诉和补救, 并留下可审计证据。

16.1 Conduct-Control Architecture

核心判断: AI conduct risk architecture 是把客户-facing 和员工 assist AI 放进销售、推荐、适当性、披露、投诉和补救控制里。

系统展开: 它不只是防 hallucination, 而是确保 AI 不误导客户、不推动不适合产品、不绕过许可边界、不利用弱势状态, 并且每次 recommendation、offer、ranking、next-best-action 或 script 都留下可审计证据。控制平面必须覆盖 policy decision、approved content、human handoff、surveillance 和 remediation。

证据输出: conduct scope intake、risk tier map、control plane diagram、runtime sequence、evidence ledger schema 和 surveillance dashboard。

16.2 Suitability Concepts as Transferable Controls

核心判断: 不是所有银行产品都受 Reg BI 或 FINRA suitability 约束, 具体义务取决于实体、产品、渠道和角色; 但相关概念提供了可迁移的控制思想。

系统展开: 可迁移原则包括 know the customer、understand product risks、manage conflicts、avoid misleading recommendations、disclose material facts and keep evidence。即使不直接适用某项证券规则, customer-impacting financial recommendation / offer / sales-assist AI 也需要把客户画像、产品风险、冲突、披露和证据纳入架构。

证据输出: source-anchor map 应把外部规则思想转成 internal control objective、policy rule、test case 和 evidence requirement。

16.3 Eligibility and Suitability Boundary

核心判断: Eligibility 是硬性资格, suitability 是情境适当性; eligible 但 unsuitable 是金融销售中的关键 conduct risk。

系统展开: Eligibility 关注年龄、地区、账户类型、信用条件、KYC 状态或产品限制。Suitability 关注推荐是否符合客户目标、风险承受能力、期限、流动性需求、财务能力和经验。一个产品可能 eligible, 但在客户画像缺失、期限不匹配、风险偏好过期或集中度过高时不适合推荐。

证据输出: decision table 要分别记录 eligibility decision、suitability decision、profile freshness、missing-data path、reason code 和 allowed outcome。

16.4 Approved Claims Library as Control Service

核心判断: 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。对于高风险话术, 系统应优先组合 approved fragments, 而不是允许自由改写。

证据输出: approved claim record、forbidden claim test case、paraphrase drift test、approval log 和 production finding trend。

16.5 Employee Assist Control Boundary

核心判断: 员工 assist AI 也要纳入 conduct scope, 因为员工可能复制 AI 话术、把 AI 排序当批准, 或缺少识别 suitability 错误的能力。

系统展开: 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。低风险内部解释可以更灵活, 但一旦内容可能进入客户沟通, 就要进入 control plane。

证据输出: employee final communication log、edit-distance record、override reason、supervisor approval 和 downstream complaint linkage。

16.6 Vulnerable Customer Protective Routing

核心判断: Vulnerability signal 不用于销售 targeting, 只能用于保护性流程。

系统展开: 系统识别退休、丧亲、医疗压力、失业、hardship、认知困难、语言障碍、投诉疲劳等信号后, 应降低销售强度、暂停高风险 offer、提供更清楚解释、触发 specialist handoff。这里的目标是避免压力、误导或过度销售, 不是用 vulnerability 提升转化。

证据输出: vulnerability event schema 要记录 signal type、confidence、protective action、sales suppression、handoff path、retention rule 和 access constraint。

16.7 Recommendation Evidence Boundary

核心判断: 证明一次 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。没有这些字段, 事后只能解释模型意图, 不能证明控制有效。

证据输出: immutable evidence ledger、policy decision id、AI run id、communication id、complaint link 和 audit replay report。

16.8 Campaign and Commission Conflict Controls

核心判断: Campaign、commission、proprietary product 和 quota 不能直接驱动推荐排序, 必须被 suitability filter、disclosure 和 surveillance 约束。

系统展开: Product metadata 要包含 conflict flags。推荐排序先经过 eligibility / suitability filter, 再考虑业务目标。涉及 conflict 的产品要有 disclosure、ranking rationale、review sampling, 并监控 complaint、cancellation、reversal、surrender 和 segment impact。

证据输出: conflict flag、ranking rationale、disclosure id、sampling plan、complaint trend、post-sale cancellation 和 segment impact dashboard。

16.9 Complaint-to-Guardrail Feedback Loop

核心判断: 投诉不是售后流程的孤岛, 而是 guardrail effectiveness 的核心反馈信号。

系统展开: 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。

证据输出: complaint event contract、root-cause classification、affected population analysis、control update record 和 remediation verification。

16.10 Investment Value Narrative

核心判断: ROI 不是少做销售, 而是让 AI sales assist 能规模化上线而不积累 conduct debt。

系统展开: Conduct control plane 降低 mis-selling、投诉、人工返工、审计缺口和 remediation 成本, 同时让合规批准的内容和适当性流程变成可复用平台能力。系统价值应同时看 revenue enablement、risk avoidance、operational capacity、audit readiness 和 customer outcome。

证据输出: executive risk memo 应展示 blocked high-risk outputs、approved-claim reuse、suitability override trend、complaint-after-AI-contact、remediation cost avoided 和 residual risk。

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 operating principle:

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.