2. 持续审计核心概念

在持续审计（Continuous Auditing，CA）平台的实战中，最先遇到的障碍往往不是技术，而是术语。业务方说“我们要实时审计”，IT 部门说“我们做的是持续监控”，内审团队又强调“目标是持续保证”。如果这些词不先对齐，后续的需求、架构、指标都会走偏。本节把五个高频术语放在同一张“语义地图”上辨析，并说明它们在平台中的位置与协作关系。

一、核心原理：从“审计动作”到“保证结果”的语义分层

这五个术语并非同义词，而是分布在三个不同层面：动作层（持续审计、持续监控）、时效层（实时审计、近实时审计）、结果层（持续保证）。理解这一点，是辨析所有混淆的钥匙。

• 持续审计：由审计主体发起，对交易、控制、余额进行持续性的独立评价与验证，强调“审计”的独立性与结论性，输出审计发现与意见。
• 持续监控：由管理层或业务系统发起，对流程、控制、KPI 进行常态化监督，强调“管理”的及时性与纠偏，输出预警与整改任务。
• 持续保证：是前两者共同追求的结果状态——在任意时点，利益相关者都能获得关于控制有效性的合理保证，而非仅在年末获得一次。
• 实时审计：时效维度的极端形态，事件发生后毫秒至秒级完成采集、规则判断与告警，通常只对高风险、高频、结构化事件启用。
• 近实时审计：时效维度的工程折中，分钟至小时级完成，覆盖绝大多数业务场景，是平台默认的“持续”节奏。

二、方法流程：术语在平台中的落地位置

在 CA 平台中，这五个概念对应不同的功能模块与数据流。下面用一段配置片段说明“近实时审计”与“实时审计”在规则引擎中的参数差异：

# 规则调度配置示例（YAML）
rule: "AP_INVOICE_DUPLICATE_CHECK"
mode: near_real_time      # 近实时审计
schedule: "*/15 * * * *"  # 每15分钟
latency_sla: "PT30M"      # 30分钟内出结果
data_source: "erp_ap_ledger"

rule: "FRAUD_HIGH_VALUE_TXN"
mode: real_time           # 实时审计
trigger: "event_driven"   # 事件驱动
latency_sla: "PT5S"       # 5秒内告警
data_source: "payment_gateway_stream"

可以看到，持续监控通常由业务系统内置的规则完成，持续审计则由审计域独立拉取数据、独立执行规则，二者共享数据源但保持审计独立性。而持续保证是这些动作累积后对外呈现的保证水平，通常以仪表盘和保证报告的形式交付。

三、案例/场景：一次采购舞弊排查中的术语协作

某制造企业发现供应商付款异常。平台中的术语协作如下：

1. 持续监控：ERP 内置规则发现同一供应商银行账号在 30 天内被修改两次，触发预警工单。
2. 近实时审计：审计域每 15 分钟拉取付款流水，执行重复付款、拆分付款规则，2 小时内锁定 7 笔可疑交易。
3. 实时审计：对高风险供应商启用事件驱动规则，付款指令生成瞬间即拦截并告警，防止资金流出。
4. 持续保证：上述动作累积后，管理层在月度保证报告中看到“采购付款控制有效性 98.2%”，并附审计发现清单。

这个场景说明：持续监控负责“发现苗头”，持续审计负责“独立验证”，实时/近实时负责“控制节奏”，持续保证负责“对外交付信心”。四者缺一不可。

四、误区/复盘：三个最常见的混淆