3. 自动化技术概览
合规检查的本质，是把外部法规、内部制度与业务事实进行比对，并输出可追溯的判断结论。不同自动化技术在“谁来做判断、谁来驱动流程、谁来操作界面、谁来承载配置”这四个问题上分工不同。理解它们的边界，比记住产品名称更重要。
一、核心原理：四类技术的能力边界
规则引擎负责“条件—结论”的显式推理。它把合规条款拆成事实、条件与动作，例如“当合同金额大于100万且缺少法务审批时，判定为高风险”。规则引擎擅长确定性判断、批量校验和可解释性输出，但通常不负责跨系统调度。
工作流引擎负责“任务—状态—流转”。它管理审批链、会签、退回、超时升级等状态迁移，适合把检查结果转化为整改任务，并跟踪闭环。它不擅长复杂计算，但擅长让流程可审计。
RPA负责“界面—操作—采集”。当合规数据只存在于老旧系统、网银、税务或供应商门户中，且没有API时，RPA可以模拟人工登录、下载、录入和截图留痕。它的优势是快速连接孤岛，弱点是界面变化敏感、并发成本高。
低代码平台负责“表单—页面—集成—轻量逻辑”。它适合快速搭建检查台账、证据上传、看板与人工复核入口，把规则、流程和RPA结果汇聚成可运营的应用。它本身不是判断引擎，但常作为合规自动化的“前台”。
二、方法流程：从条款到自动化流水线
落地时建议按以下顺序推进，避免“先选工具再找场景”：
- 条款结构化：把制度拆成可判定字段，如主体、金额、时间、缺失项、阈值。
- 数据可得性评估：有API走接口，无API走RPA，半结构化走低代码表单补录。
- 判断逻辑分层：确定性规则进规则引擎，需要人工裁量的进工作流复核节点。
- 流程闭环设计：检查结果自动生成整改任务，设置超时升级与证据归档。
- 运营与度量：用低代码看板跟踪命中率、误报率、整改时长。
三、案例/场景：采购合同合规检查
某制造企业要对采购合同做合规检查。合同文本在OA中，供应商资质在旧ERP中，付款信息在网银中。若只上一套规则引擎，会卡在“数据取不到”；若只上RPA，会卡在“判断不可解释”。
合理组合是：RPA每日登录旧ERP和网银，下载供应商资质与付款记录；规则引擎校验“资质过期、金额超限、缺少法务审批”三类条款；工作流引擎把命中项派给采购负责人整改，超时升级至合规部；低代码平台提供检查台账、证据上传和风险看板。上线后，单份合同检查时间从40分钟降至6分钟，误报率通过规则调优从18%降至7%。
规则示例（伪代码）：
IF 合同金额 > 1000000 AND 法务审批 = 缺失
THEN 风险等级 = 高, 动作 = 生成整改任务
IF 供应商资质有效期 < 当前日期
THEN 风险等级 = 中, 动作 = 通知采购复核四、选型对比与误区复盘
| 技术 | 最适合的场景 | 不擅长的场景 | 关键成本 |
|---|---|---|---|
| 规则引擎 | 确定性判断、批量校验、可解释结论 | 跨系统调度、界面操作 | 规则维护与版本管理 |
| 工作流引擎 | 审批、整改闭环、状态审计 | 复杂计算、数据采集 | 流程建模与组织变更 |
| RPA | 无API系统取数、界面录入、留痕 | 高并发、界面频繁变更 | 机器人授权与运维 |
| 低代码平台 | 表单台账、看板、人工复核入口 | 核心推理、复杂算法 | 平台许可与集成开发 |
选型的最终标准不是技术先进，而是合规目标能否被稳定、可解释、可审计地达成。先明确检查点属于“判断、流转、取数、运营”中的哪一类，再匹配对应技术，通常比一次性采购大平台更有效。