审计 AI：先把「AI 到底负责哪一段」说清楚
审计 AI，在 iModel 里指的是在数据处理工作流中调用本地部署的大模型，用它处理合同、说明、备注这类非结构化文本，把内容转成可比对的结构化字段，再交由既定规则判定。模型参与的是理解文字这一段，不是下结论那一段。
这个划分不是保守，是审计场景的必然要求。审计结论必须能解释、能复核、能重跑。一个每次回答都略有不同的模型，无法承担「这条疑点为什么成立」的举证责任；而一条写死的规则可以。把两者混在一起，看起来更智能，实际上把整条链路的可核查性一起丢掉了。
iModel 基于 KNIME 开源内核二次开发，中文化、信创适配与企业级增强部分为自主研发，源代码可向客户提供审查。大模型调用能力来自内核生态中的相关扩展节点（KNIME 官方扩展页，2026-09-09 核实）。整体方法论见审计数据分析解决方案。
关键事实
| 已具备能力 | 在工作流中调用本地部署的大模型，处理非结构化文本；模型调用作为一个节点参与流程，输入与输出均为表格数据 |
|---|---|
| 模型部署方式 | 模型由客户自行选定并在本地部署，平台通过节点对接；平台侧不绑定特定模型供应商 |
| 数据边界 | 模型与平台均在本地运行，支持完全离线的内网环境，明细数据不出域 |
| 判定方式 | 模型只负责把非结构化内容转为结构化字段；是否命中疑点由确定性规则判定，规则可读可改 |
| 过程留痕 | 模型节点的输入与输出与其它节点一样保留，可与规则结果一并逐步回放 |
| 已验证操作系统 | 麒麟 V10 / V11、统信 UOS（均为 x86-64 版本）、Windows |
| 已验证处理器 | 海光 C86（x86-64），已测试、已部署。iModel 目前不支持 ARM 架构（鲲鹏、飞腾），相关版本仍在规划中 |
| 不提供的能力 | 不提供由模型自动生成审计结论、不提供替代人工判断的自主决策、不提供将明细数据发往公有云模型服务的调用方式 |
表中信创口径按已实测部署范围填写；模型侧的实际可用范围取决于客户所部署的模型与硬件条件，请以实际测试结论为准。
审计 AI：模型在这条链路的哪一格
下面这条链路是本页最需要看懂的一张图。模型只在第二格，它的输出立刻变回表格，后面全是可读可改的规则。
输入
非结构化文本
合同条款、报销事由、往来说明、系统备注，原本只能靠人逐份读。
模型节点
抽取与归类
本地大模型把文字转成字段：条款类型、事由分类、涉及主体、金额与期间。
结构化
变回表格
输出即表格数据，可人工抽查、可与其它系统数据关联比对。
规则判定
确定性规则
是否命中由写死的规则决定，与不含模型的测试完全一致，可复核可重跑。
输出
疑点清单
每条疑点可倒推回原文与模型抽取结果，举证链完整。
为什么要这么切：模型抽错了字段，人工抽查阶段就能发现，因为中间结果是表格不是黑箱；而如果让模型直接给结论，错在哪一步没人说得清。这一格切下去，AI 的价值保住了，审计的举证责任也保住了。
工作流为什么天然适合承载这种链路，见为什么要用可视化工作流；模型之外的统计与建模能力，见统计分析和机器学习。
审计 AI：我们做什么，我们不做什么
这一节写得比同类页面直白。原因很实际：审计和监管场景的采购评审，最先被问的就是边界在哪。把边界写清楚，比多写几个形容词有用。
现在就能做
- 从合同、协议文本中抽取关键条款要素，转成可比对的字段
- 把报销事由、费用说明这类自由文本归类到既定类目
- 对往来单位、供应商名称的多种写法做消歧与归并的辅助判断
- 把结构化的疑点结果整理成可读的说明文字，供核查底稿使用
- 以上全部在本地部署的模型上完成，明细数据不出内网
我们不做
- 不由模型直接判定某笔业务是否存在问题，判定权在规则
- 不由模型决定阈值、抽样范围或风险等级
- 不提供把明细数据发往公有云模型服务的调用方式
- 不宣称模型输出可以直接作为审计结论或审计证据
- 不用「AI 自动完成审计」这类说法描述本页涉及的能力
右栏中的每一条，都是我们在项目里被问过、并且明确答复过的问题。写在这里，是为了让评审阶段少一轮来回。
四个已经能落地的具体用法
共同点是：处理的都是原本只能靠人逐份读的文字，而且模型的输出立刻回到表格，接受人工抽查。
📄
合同条款要素抽取
从合同文本中抽出付款条件、验收条款、违约约定等要素，与实际付款记录比对是否一致。
🏷️
费用事由归类
把报销单上的自由填写事由归入既定费用类目，让后续的全量筛查有统一口径可用。
🔗
往来单位名称消歧
同一实体的多种写法与重复建档，模型给出归并建议，人工确认后再进入关联比对。
📝
疑点说明成文
把命中的规则与关键字段整理成可读的说明，减少底稿撰写的重复劳动，内容仍需复核。
在信创环境里落地：已实测的软硬件范围
引入模型不改变部署前提。审计与监督数据敏感度高，绝大多数场景要求内网离线、国产化底座；以下是已完成测试并有实际部署的范围，未列入的项请先做适配验证。
- 操作系统：麒麟 V10 / V11、统信 UOS，均为 x86-64 版本；Windows 环境同样支持
- 处理器：海光 C86（x86-64），已测试、已部署
- 部署方式：完全离线安装，不需要连接外网许可服务器；数据全程不出内网
- 模型侧：由客户自行选定并本地部署，平台通过节点对接，不绑定特定模型供应商
- 界面与文档：全中文界面，节点名称、参数与报错提示均已中文化
关于 ARM：iModel 目前不支持 ARM 架构（鲲鹏、飞腾），相关版本仍在规划中。若底座已确定为 ARM，请在方案阶段就提出。另需注意，本地部署大模型对显存与内存有额外要求，与 iModel 本身的运行要求是两笔账，选型时应分开测算。
常见问题
不能，我们也不建议这样用。模型负责把文字变成字段，判定由规则完成。原因是审计结论要能解释、能复核、能重跑，而模型的输出存在不确定性，无法承担举证责任。把这两段分开，AI 的效率保住了，结论的可核查性也保住了。
不会。模型由客户在本地部署，平台通过节点对接本地模型，整条链路在内网内完成，支持完全离线运行。平台侧不提供将明细数据发往公有云模型服务的调用方式。
不绑定。模型由客户根据自身合规要求与硬件条件选定并本地部署，平台通过节点对接。选型时建议先用一小批真实文本做实测，比较抽取准确率与响应时间，再决定规模化部署的模型与硬件配置。
这正是把模型输出立刻转回表格的原因。抽取结果是一张可以打开看的表，可以按比例人工抽查，也可以设置校验规则做交叉验证。发现系统性偏差时，调整提示词或改用其它模型重跑即可。相比之下，让模型直接出结论时，错在哪一步是查不出来的。
取决于所选模型的规模与实际处理量。本地部署大模型对显存与内存的要求，与 iModel 本身的运行要求是两笔账，需要分开测算。iModel 不含模型能力时在普通服务器上即可运行，模型侧的硬件方案建议在方案阶段单独评估。
可以，而且这是多数项目的起点。取数、清洗、全量规则筛查、定时执行这些能力都不依赖模型，先把这条链路跑稳，再在需要处理非结构化文本的环节引入模型节点，是更稳妥的推进顺序。
带一批真实文本来，现场跑一次抽取
合同、报销事由、往来说明都可以，脱敏后几十份就够。我们用一次演示把它接进工作流跑给你看，包括模型抽出来的字段表和后续的规则判定。
