GRC 平台 PoC 的八组验证问题

合规风控平台的产品介绍往往覆盖相似名词，真正的差异只有放进同一批数据、同一条业务链和同一套责任约束后才会出现。PoC 的目的不是让厂商重复演示标准功能，而是让关键假设可以被证伪。

一、建模能力

准备一条包含金额阈值、时间窗口、明细聚合与例外条件的真实制度。观察平台如何从业务对象建立规则，是否支持主表与明细、跨行、跨对象和外部标准。不能只看表达式是否能写，还要看业务人员能否读懂和维护。

二、方案与执行

验证规则怎样进入填单、提交、审批、付款和离线巡检。多条规则同时命中时如何排序，服务超时如何降级，批量任务怎样分片，刚性阻断和柔性提示如何区分。

三、AI 与附件

准备格式不同、质量不同、包含歧义的附件。检查 OCR、多模态或大模型结果是否能定位原文，模型和提示版本是否记录，失败时是否转人工，数据是否离开约定边界。

四、三层穿透

分别验证监管层级、业务链路与交易关系。不要只展示关系图，要让一条异常从结果回到关联对象、原始字段和责任组织。

五、风险闭环

让一次命中进入确认、分派、整改、复核和关闭。检查风险等级、责任人、时限、例外放行和升级规则是否可配置，过程证据是否保留。

六、治理与运营

修改一条已发布规则，观察草稿、测试、审批、发布、回滚和历史结果的行为。再检查命中率、误报、失效规则、制度版本和多组织继承如何管理。

七、集成与中立性

使用至少一个非同源业务系统验证接口、身份、权限和对象映射。平台是否只能在自家 ERP 中顺畅工作，还是能通过稳定适配器复用规则底座，需要用实际接入成本判断。

八、AI 可治理性

选择一条高影响 AI 检查，要求现场展示输入、检索材料、输出、置信或判断依据、人工终局以及版本变化后的回放。能够生成答案不等于能够承担合规责任。

输出不是一个总分

PoC 最终应交付证据包：测试数据、配置快照、执行记录、失败样本、人工判断和未解决问题。总分只能帮助排序，证据才能解释为什么选择，以及哪些风险将在合同和实施阶段继续控制。