第 31 篇 金融与医疗：高合规行业的 AI 产品方法论
小系列〔行业纵深〕第 1 篇 · 定位：把通用 AI 方法论落到高合规、高 stakes 行业；衔接《第 14 篇：安全合规》的"风险是产品风险"与《第 11 篇：交互设计》的"人在环"。
通用 AI 产品方法论在金融与医疗面前会撞上一堵墙：同样的"先跑通再优化"在互联网场景里是敏捷，在这两个行业里是事故。本篇不重复前两季的结论，而是把"风险是产品风险""人在环"这两条原则推向最严苛的落地现场，给出一套可操作的行业化框架------它关心的不是模型多强，而是出错时谁担责、能否溯源、能否回滚。
很多团队带着互联网经验进入这两个行业，第一反应是"模型准了就能上"。这个判断忽略了行业的第一性约束。在互联网，一次 badcase 的代价是"用户骂一句走了"；在金融，一次错的信贷建议可能让一个家庭背上不该有的负债；在医疗，一次错的影像提示可能延误治疗。错的成本结构不同，产品的设计哲学就必须不同。所以本篇的核心立场是：在高合规行业，合规边界优先于能力边界，辅助优先于替代，溯源与可回滚是底线而非加分项。下面所有方法都围绕这三条展开。
一、为什么这类行业落地慢而难
互联网产品的失败成本通常是"体验变差、用户流失"，而金融与医疗的失败成本可能是"资金损失、人身伤害、监管处罚"。这一根本差异决定了两者在方法论上的五个分叉点：监管不确定性、可解释要求、责任归属、数据隔离、容错成本。把五个维度并排列出，才能看清为什么"通用打法"在这里失效。
| 维度 | 互联网行业 | 金融 / 医疗 |
|---|---|---|
| 监管确定性 | 事后监管为主，先上线后规范 | 前置审批与持续合规，变更需报备 |
| 可解释要求 | 弱，效果够好即可 | 强，关键决策必须能说明依据 |
| 责任归属 | 多为平台与用户之间 | 涉及客户资产 / 生命健康，主体明确且重 |
| 数据隔离 | 可共用中台、联合建模较自由 | 强隔离、最小授权、跨域需合规审批 |
| 容错成本 | 低，撤回成本低 | 极高，一次误判即不可逆后果 |
结论先行：在这两类行业做 AI 产品，第一性约束不是"能力边界"而是"合规边界"。产品经理必须先把合规边界画清楚，再在边界内谈能力。否则模型再准，过不了审批也上不了线；上线后出一次责任事故，前面所有效率收益都会被一次性抹平。
监管不确定性是最隐蔽的坑。互联网团队习惯"政策出来再调"，但金融与医疗的监管往往要求"上线前就证明合规"。这意味着需求阶段就要把合规、法务、风控拉进评审，而不是开发完再送审。可解释要求则直接改变产品形态------互联网可以接受"黑盒但好用"，这里必须"每一句输出都有迹可循"。容错成本极高带来一个产品原则：凡涉及资金划拨、诊疗动作，默认不交给模型自主执行。
数据隔离常被技术团队低估。互联网喜欢"数据打通、联合建模",而金融与医疗对数据有严格的边界与授权要求,跨域使用往往要走过合规审批。产品经理在这里的职责,是把"数据从哪来、谁能看、用在哪"写成明确的需求,而不是默认"反正都在公司内网"。隔离不仅是合规要求,也是事故时责任划分的依据:数据来源不清,出了问题连归责都做不到。
这五个维度合起来说明一件事:高合规行业的 AI 产品,其方法论的重心从"怎么把模型用好"转移到了"怎么让模型在约束内可控地用"。能力是入场券,可控才是通行证。
二、金融场景图谱
金融是 AI 渗透较早、但"自动化程度"差异极大的行业。核心规律只有一条：辅助不替代决策。下面按场景拆开看，每个场景标注"AI 能做"与"AI 不能做"，避免团队在禁区里用力。
| 场景 | 可行形态 | 核心约束 | AI 能做 | AI 不能做 |
|---|---|---|---|---|
| 智能客服 | 问答、业务引导、工单预填 | 禁止承诺收益、误导销售 | 理解意图、生成话术草稿 | 代客做实质性业务承诺 |
| 投研辅助 | 公告摘要、数据提取、异动归因 | 研报需分析师署名负责 | 信息压缩、初筛线索 | 下达买卖建议、替代投资结论 |
| 风控反欺诈 | 实时评分、异常识别、规则补位 | 拒贷须可解释、可申诉 | 特征挖掘、可疑模式发现 | 单模型终局否决且无人工复核 |
| 财富投顾 | 组合建议、再平衡提醒 | 适当性管理、风险提示 | 方案生成、教育内容 | 越权代客交易、保证收益 |
| 合规审查 | 合同比对、制度检索、报送校验 | 审查结论需合规人员签字 | 文档结构化、缺失项提示 | 出具终局合规意见 |
这张表的价值在于划禁区。很多团队在"投研辅助"上翻车，不是因为模型不行，而是把"线索初筛"悄悄做成了"买卖建议"。产品设计的纪律是：在禁区边界上放一道人确认闸，且闸的位置要写进需求文档，而不是靠运营自觉。
"辅助不替代决策"不是口号，而是产品架构选择。具体做法是把 AI 的输出固定为"建议 + 依据 + 置信度"，把"决定 + 执行"留给授权人。这样即便 AI 给错建议，决定环节的人仍能纠偏，责任链清晰。这里有个容易被忽视的细节：置信度不能只是摆设。当置信度低时，产品应当自动降级为"仅参考"或升级确认层级，而不是照常呈现。把"低置信即弱化"做成系统行为，比写十遍规范都管用。
财富投顾场景还要叠加"适当性管理"：同样一份组合建议，对不同风险承受能力的客户含义完全不同。AI 生成的方案必须先过适当性校验，再触达用户，否则再"精准"也是违规。这一点提醒产品经理，金融里的"准"不仅要对模型准，还要对监管准。
三、医疗场景图谱
医疗的 stakes 比金融更硬------错误的代价是健康与生命。因此医疗场景的红线只有一条：诊断权与责任必须在人。AI 可以极大提升效率，但任何涉及"下结论"的环节，最终签名权都在执业医师。
| 场景 | 可行形态 | 核心约束 | AI 能做 | AI 不能做 |
|---|---|---|---|---|
| 病历结构化 | 语音转写、字段抽取、质控校验 | 隐私脱敏、授权使用 | 自动生成结构化病历草稿 | 替代医师书写最终病历 |
| 问诊分诊 | 症状预问、科室推荐、紧急度提示 | 不延误急症、不误导 | 信息收集、分诊建议 | 给出确诊结论 |
| 文献 / 指南检索 | 指南问答、证据汇总、用药提醒 | 来源权威、版本可追溯 | 检索聚合、要点提炼 | 替代临床诊疗决策 |
| 影像辅助 | 病灶标注、疑似提示、量化测量 | 需医师复核签字 | 初筛、测量、比对 | 独立出具影像诊断报告 |
| 患者管理 | 随访提醒、用药依从、健康教育 | 不替代医患沟通 | 自动化触达、风险分层 | 调整治疗方案 |
红线管理要有机制而非靠自觉。建议在产品里把"AI 建议"与"医师结论"做成两个独立字段、两个独立签名，任何把两者混为一谈的界面都视为设计缺陷。影像辅助尤其容易越界------标注工具若默认"高亮即确诊",会让医师产生依赖,反而降低复核质量。正向设计是"标注 + 不确定区间提示",把"不确定"显式呈现,逼出人工判断。
问诊分诊有一个特殊风险：延误急症。AI 如果为了"体验顺畅"而把本该直送急诊的症状轻描淡写地分到了普通科室，后果可能是致命的。因此分诊产品的设计原则应当是"宁可错杀、不可放过"------对高风险信号优先提示就医，哪怕牺牲一点准确率。这和互联网"追求召回与精准平衡"的思路不同，医疗分诊要主动偏向安全侧。
患者管理同样不能越过"替代医患沟通"的线。自动化的随访提醒、用药提醒是减负利器，但一旦涉及"建议调整用药"，就必须回到医师。产品要在触达文案里明确"这是系统提醒，具体方案请遵医嘱"，既发挥效率又守住边界。
四、可解释性与审计
高合规行业的 AI 输出必须"可溯源、可复核",这呼应前两季对评测与溯源的要求,但在此处变成强制项而非加分项。每个面向用户或内部决策者的输出,都应携带一组溯源字段,使任何结论都能被还原到"依据什么、由谁确认、何时生成"。
下面是"输出溯源字段"模板,建议作为所有高合规 AI 输出的标准结构,直接落进数据 schema:
| 字段 | 含义 | 是否必填 |
|---|---|---|
| output_id | 输出唯一标识,用于追溯 | 必填 |
| source_refs | 引用来源列表(文档ID/规则ID/数据快照) | 必填 |
| model_version | 生成所用模型与版本 | 必填 |
| prompt_version | 所用提示词 / 流程版本 | 必填 |
| confidence | 置信度或风险等级 | 必填 |
| human_reviewer | 复核人标识(若需人确认) | 按风险分级 |
| review_ts | 复核时间戳 | 按风险分级 |
| rollback_ref | 可回滚到的前置状态 | 涉及执行动作时必填 |
可解释性的产品落点有三处:一是在界面上让授权用户看到"为什么"(source_refs 与 confidence 可见);二是在后台留存完整链路供审计;三是在事故时能通过 output_id 秒级定位到生成链条的每一环。这三点合起来,才叫"可审计",而不是嘴上说说可解释。
注意:置信度不是装饰。当 confidence 低于阈值,产品应自动升级到人确认或降级为"仅参考",而非硬给结论。把阈值写进配置并随监管反馈调整,是持续合规的一部分。还有一点常被忽略:source_refs 必须指向"可追溯的快照"而非"实时数据源"。如果引用的是一份会变动的文档,事后审计时原文已改,溯源就失效了。所以审计链路要存储数据快照或版本号,保证"当时依据什么"可还原。
可解释还要区分"对内向监管"与"对外向用户"两层。对外只需让用户理解"这条建议基于什么、是否要咨询医生/理财师";对内则必须详尽到能支撑监管检查。产品经理要同时设计这两套表达,而不是用一套应付两边。
五、人在环的分级设计
《第 11 篇:交互设计》提出"人在环",本篇把它落成一张可执行的"分级确认表"。核心思想:不是所有动作都要人确认(那样等于没自动化),也不是所有动作都能全自动(那等于赌事故),而是按风险等级匹配确认强度。
| 风险等级 | 操作类型 | 是否需人确认 | 确认方式 |
|---|---|---|---|
| 低 | 浏览建议、信息展示、草稿生成 | 否 | 无需确认,可一键采纳 |
| 中 | 生成对外内容、触发内部流程 | 是(轻量) | 编辑预览 + 明确采纳按钮 |
| 高 | 资金动作、信贷决策辅助结论 | 是(强) | 双人复核 / 电子签名 + 留痕 |
| 极高 | 诊疗结论、处方相关、代客交易 | 是(强制) | 授权人独立判断 + 书面签名 |
分级的价值在于把"确认成本"花在刀刃上。低风险的浏览建议若每次都弹确认,用户会疲劳性一键过,反而削弱了对高风险动作的注意力。所以确认强度要和风险等级严格挂钩,且阈值由合规与风控共同定义,产品经理的职责是保证界面把分级真实呈现,而不是把"极高"悄悄降级成"中"。
一个常见反模式是"伪人在环":界面上放了个确认按钮,但默认勾选、且按钮文案模糊,用户根本没看清就点了。这既骗了合规也骗了用户。真正的人在环要求确认动作"有意识、可举证"------用户必须做出明确、不可被默认跳过的选择,且该选择被记入审计链。
分级不是静态的。同一个动作在不同上下文里风险等级会变:一笔小额转账是"高",一笔大额跨行转账可能升到"极高";一条常规用药提醒是"低",一条涉及抗凝药的提醒可能升到"中"。产品经理要把"上下文敏感的风险升级"做成规则,而不是把风险等级写死在功能上。这是让分级机制真正有用的关键。
六、与合规、法务、监管的协作机制
通用产品可以把法务当"上线前过一道"的关卡,高合规行业必须把法务、合规、风控做成"需求阶段的共创者"。协作机制的要害是前置与留痕,下面给出一张协作清单,建议固化为跨职能流程。
| 阶段 | 协作动作 | 产出物 | 责任方 |
|---|---|---|---|
| 需求前置 | 合规 / 法务参与场景评审,标注禁区 | 场景合规边界清单 | 产品 + 合规 |
| 设计评审 | 影响评估(隐私 / 公平 / 安全) | 影响评估报告 | 合规 + 算法 |
| 开发留痕 | 所有输出携带溯源字段 | 审计 schema | 工程 |
| 上线审批 | 监管所需材料 + 内部评审 | 上线批准记录 | 合规 + 风控 |
| 运行监测 | 定期合规复盘 + 红队复测 | 监测报告 | 产品 + 安全 |
需求前置是最容易被砍的环节,却是最值钱的。一个在需求阶段被合规否掉的"自动拒贷"功能,省下的是上线后整个系统的返工与潜在处罚。影响评估要落到具体维度:数据是否最小化、模型是否有偏见风险、错误输出会不会误导弱势群体。这些不是法务一个人的事,产品经理要能把这些维度翻译成需求条目。
上线审批不是走形式。涉及监管报送的行业,很多变更需要事前报备,产品要做"变更影响分级":哪些改动只需内部记录,哪些必须报备后再发。把分级规则写清楚,避免"灰度发布救了一时、踩了监管红线"的窘境。运行监测阶段要把红队复测常态化------模型换了、提示词改了,高合规场景的攻击面和风险点也会变,不持续测就等于把安全寄希望于运气。
跨职能协作还有一个组织层面的坑:合规与产品目标天然张力。产品要快、要体验,合规要稳、要留痕。解决张力不能靠谁压谁,而要靠"共同语言"------把合规要求翻译成可勾选的检查项(见第七节清单),让双方在同一张表上对齐。产品经理的价值,正是在这里做"翻译"与"缓冲",而不是选边站。
七、责任归属与事故处理
高合规产品必须回答一个尖锐问题:出错了谁担责。产品层面无法替法律定责,但可以通过设计让责任链可还原、可划分、可回滚,从而把"扯皮"变成"定位"。
责任归属的产品设计原则有三条。第一,决策签名链完整:每一个最终动作都要能指向"谁在什么依据下做的决定",AI 的建议与人的决定分存。第二,可回滚:涉及执行类动作(如已发出的合规报送、已触发的风控标记),必须保留前置状态,事故时能快速回到出错前。第三,事故分级响应:按影响范围(单客户 / 批量 / 系统性)定义响应时效与上报路径,避免小事故因隐瞒拖成大事故。
事故处理不是事后救火,而是事前演练。建议把"输出溯源字段"直接接入事故看板:一旦投诉或异常,输入 output_id 即可拉出完整生成链,定位是数据问题、模型问题还是人确认失效。回滚机制则要求执行动作都有"反向操作"设计------这在金融尤其重要,因为很多动作具有外部性(已通知客户、已报监管),回滚要考虑对外的补救沟通。
最后强调:本篇所有合规相关表述均为通用原则。具体行业的监管要求、报备流程、责任认定以官方发布为准,重大功能上线前务必咨询法务与合规部门,切勿以本文作为合规依据。产品能做的,是把"可控、可溯、可回滚"的产品骨架搭好,让合规与法务能在骨架上填肉,而不是事后补丁。
模板:高合规场景 AI 功能立项检查清单
以下清单建议在需求评审前逐项打勾,任一高风险项未闭环不得立项。复制填用即可。
高合规场景 AI 功能立项检查清单
─────────────────────────────
[ ] 1. 场景是否触及监管禁区? 禁区清单已与合规确认: □是(停止) □否
[ ] 2. 该功能是"辅助"还是"替代决策"? 若替代决策: □已改为辅助形态
[ ] 3. 输出是否携带溯源字段(output_id/source_refs/model_version/confidence)? □是
[ ] 4. 风险等级(低/中/高/极高)是否已定? 对应确认方式: ________
[ ] 5. 人在环是否"有意识可举证"? 默认勾选/模糊文案: □已清除
[ ] 6. 影响评估是否完成(隐私/公平/安全)? 报告ID: ________
[ ] 7. 数据是否最小化且已授权? 跨域使用审批: □有 □无
[ ] 8. 执行类动作是否可回滚? 回滚方案: ________
[ ] 9. 上线是否需监管报备? 报备状态: □不需 □已报备 □待报备
[ ] 10. 事故分级响应机制是否就绪? 看板接入 output_id: □是
结论: □可立项 □需补材料(列:____) □暂缓
评审人/日期: ________一页速查
金融与医疗 AI 落地 一页速查
─────────────────────────────
第一性约束:合规边界 > 能力边界,先画合规再谈能力
金融铁律:辅助不替代决策;禁区=代客承诺/买卖建议/终局否决/代客交易
医疗红线:诊断权与责任必须在人;AI 建议≠医师结论(双字段双签名)
输出溯源字段(必带):output_id|source_refs|model_version|prompt_version|
confidence|human_reviewer|review_ts|rollback_ref
人在环分级:低=免确认 / 中=轻量采纳 / 高=双人复核 / 极高=授权人签名
协作前置:需求阶段拉合规法务;影响评估(隐私/公平/安全)必做
责任设计三原则:签名链完整 + 可回滚 + 事故分级响应
合规表述:通用原则,具体以官方发布为准,重大功能咨询法务常见坑
- 把"线索初筛"悄悄做成"买卖建议",在投研辅助禁区里越界而不自知。
- 医疗影像辅助默认"高亮即确诊",诱导医师依赖、削弱复核质量。
- 可解释只做界面文章,后台不留存完整生成链,事故时无法溯源。
- 置信度低时仍硬给结论,未自动升级人确认或降级为"仅参考"。
- 人在环是"伪确认":默认勾选、文案模糊,用户无意识点过。
- 砍掉需求阶段的合规前置,上线后被监管打回整体返工。
- 把"有数据"当"可用数据",忽视跨域授权与最小化的合规审批。
- 执行类动作无回滚设计,出错后对外影响(已通知/已报送)无法补救。
- 变更灰度发布踩监管红线,未做"变更影响分级"与事前报备。
- 把本文通用原则当合规依据,重大功能未咨询法务与合规部门。
结语
高合规行业的 AI 方法论,本质是把"风险是产品风险"和"人在环"推到最硬的场景:合规边界先于能力边界,辅助先于替代,溯源与可回滚是底线而非选项。
本文为「AI 产品经理入门与进阶」系列第三季·小系列〔行业纵深〕第 1 篇（总第 31 篇）。数据来源:行业通用合规原则与产品实践整理;涉及具体监管要求、报备流程与责任认定以官方发布为准,重大功能上线前请咨询法务与合规部门。具体数值随技术迭代变化,请以最新数据为准。