制度与监管知识库问答
合规 / 全员
输入
法规与监管文件、内部规章制度与操作手册、产品说明与费率规则、历史问答。
输出
自然语言提问返回答案，并附原文条款、文件名与版本；查不到依据时明确拒答，不编造条款。
人在哪里介入：对外与对内的正式口径以合规、法务部门确认为准；文件有效版本由各部门维护，失效文件标记后不进召回。
我们做五件事：查依据、抽要素、对不一致、起初稿、留痕迹
这五件事是金融机构里工作量最大、却几乎没有系统覆盖的部分，也恰好不触及任何需要牌照或不得外包的环节。下面分两组：一组已经有可运行实现、可以直接演示；一组按机构情况评估接入。每个模块都按“输入什么—系统给出什么—人在哪里介入”定义。机构不必一次全上，通常先跑通一到两个再扩。
核心模块
已有可运行实现与我们在律所、知产所、学校已经落地的同一套检索与生成能力，换成金融的资料、口径与权限规则。
信贷与尽调材料整理
信贷 / 风控中后台
输入
机构按自身合法来源取得的材料：征信报告、财务报表、银行流水、合同、工商与司法公开信息、押品评估报告。
输出
要素抽取（结构化字段 + 原文定位）、材料之间的交叉不一致清单、缺件清单、尽调与申报材料初稿、疑点提示。
人在哪里介入：客户经理与信审人员核对原件后使用；系统不给准入、额度、定价结论，不计算信用评分。
坐席与客服辅助
运营 / 客服
输入
产品说明、费率与规则、常见问题、历史工单与内部知识库。
输出
给坐席的应答要点与话术初稿、工单摘要与分类、质检关注点清单。
人在哪里介入：对客内容由坐席发出，口径经合规审核；不做以机构名义无人值守地直接答复客户。
营销与对外材料合规预检
合规 / 市场
输入
拟发布的营销文案、产品宣传、客户经理话术、对外报告初稿，以及机构内部的禁用语与红线清单。
输出
风险点逐条标注、对应的制度或监管依据、修改建议。
人在哪里介入：审核结论由合规、法务出，系统只做初筛；不出具“已通过合规审核”的判定；对外使用 AI 生成内容的标识义务由机构履行。
报送与运营文档口径助手
计财 / 数据管理
输入
监管报送口径文件与填报说明、历史报表、内部制度与指标定义。
输出
填报口径问答（哪个指标按哪份文件哪一条）、口径差异说明初稿、报送说明与分析文字初稿。
人在哪里介入：数据准确性与报送由业务和数据部门负责；不代取数、不代签署、不代报送。
数据资产与开发助手
科技部门自用
输入
数据字典、表结构、指标口径文档、历史 SQL、系统与接口文档。
输出
指标口径问答、查询 SQL 初稿、接口文档与测试用例初稿、系统文档检索。
人在哪里介入：SQL 初稿经开发复核，默认只给查询语句；生产变更走机构既有的变更与投产流程。
扩展模块
按机构情况评估接入这些来自不同类型机构提出的实际需求，技术路径与核心模块相同；但能不能做、做到什么程度，取决于资料条件、现有系统与监管要求，需在评估阶段逐项确认，不作为默认现成功能。
合同与协议审阅
法务 / 风控
输入
信贷合同、担保与同业协议、外包与采购合同，以及机构的标准模板与条款清单。
输出
与模板的差异清单、缺失与非标条款提示、修改建议初稿。
人在哪里介入：法律结论与签署由法务与授权人负责，系统只做对照与提示。
反洗钱预警工单材料整理
反洗钱岗
输入
已由现有监测系统命中规则的预警工单、客户资料与交易背景说明。
输出
尽调材料汇总、客户与交易背景的结构化梳理、调查说明初稿。
人在哪里介入：不改规则与阈值、不判断是否可疑、不做自动上报；是否报告由反洗钱岗按机构制度决定。
投研与信息摘要
研究岗内部自用
输入
公开披露资料、年报与公告、会议记录、机构已订阅的研究资料。
输出
要点摘要、会议纪要整理、行业与指标信息的结构化归集。
人在哪里介入：不生成投资建议、不做标的推荐、不预测收益、不对外发布；成稿与署名由研究人员负责。
保险条款与理赔材料辅助
保险运营 / 中介
输入
保险条款与产品说明、理赔材料清单与操作规程、销售可回溯相关材料。
输出
条款问答、理赔材料缺件提示与清单核对、回溯材料归集整理。
人在哪里介入：不做核保结论、不做定损定责与赔付结论；核赔由岗位人员按制度判定。
审计与内控自查
内审 / 内控
输入
制度与流程文件、留痕记录、检查要点与问询清单。
输出
制度—流程—留痕三者的对照清单、缺项提示、工作底稿与自查报告初稿、问询材料归集。
人在哪里介入：审计结论与报送材料由内审部门负责；不承诺通过任何检查或评估。
消保与投诉处理辅助
消保 / 运营
输入
投诉工单、处理规程与答复模板、同类历史案例。
输出
工单归类与同类问题归集、答复初稿、重复投诉的成因线索整理。
人在哪里介入：不做责任认定与赔付结论；答复以消保部门审定口径发出。
贷后材料与合规抽检要点
贷后管理
输入
贷后检查材料、台账与制度要求，以及机构自有的话术规范。
输出
贷后检查材料归集、台账与报告初稿、催收话术的合规预检要点。
人在哪里介入：不做对客自动外呼、不参与催收执行；风险分类与处置由岗位人员决定。
模型治理与合规档案
科技 / 合规 / 内审
输入
系统内的模型与版本信息、提示词与配置变更、评估集与评估结果、访问与操作日志。
输出
模型与版本清单、评估记录、变更与下线回退记录、数据流与权限图、第三方安全评估问卷应答包。
人在哪里介入：台账由机构科技与合规部门认领维护；我们负责系统侧的记录完整与可导出。
为什么不把模块写成一张固定清单
金融场景和监管要求都在变：制度会修订、报送口径会调整、模型半年前做不了的事现在能做。把能力钉成一张封闭的清单，对机构没有好处，对我们也不诚实——要么很快过期，要么为了显得全面而写上做不到的东西。
所以我们固定的是方法，不是清单。任何一个新场景都按同一套流程接进来：先说清输入什么、输出什么，再定人在哪里介入、谁对结果负责，最后用机构自己出的评估集验收。上面两组不是能力上限——机构提出的场景只要这几件事能说清，就可以进入评估；说不清的，我们会直接讲为什么现在不适合做，而不是先接下来再说。
不随模块增加而放宽的只有硬边界：无论加多少模块，授信与定价结论、投资建议、核保理赔结论、可疑交易是否上报、信用评分，都不由系统给出。见明确不做的事与能力边界三档。
本页讲的是金融业务里做什么。底层的模型选型、显存与算力卡、国产化适配与部署档位，见AI 大模型私有化部署与配置计算器。供应链金融的单证、保理与应收账款平台等系统建设，见货代管理与供应链协同平台。
覆盖哪些机构，各自先上什么
不同类型的金融机构，监管口径、决策方式和采购流程差别很大，不能用一套方案套到底。下表是我们按机构类型区分的切入建议。判断标准只有三条：材料类人工工作是否集中、是否有合规留痕压力、能不能自己决定。
| 机构类型 | 建议先上的模块 | 要特别注意的 | 决策与采购路径 |
|---|---|---|---|
| 地方金融组织（融资担保、小额贷款、融资租赁、商业保理、典当） | 信贷与尽调材料整理、合同审阅 | 材料来源的合法性与客户授权；不做信用评分与替代数据评价 | 决策链短，多为直接商务签约，可先云端验证 |
| 农商行 / 村镇银行 / 农信社 | 制度与监管知识库问答、数据资产与开发助手 | 第三方服务商准入与安全评估；常有国产化（信创）要求 | 询价或集中采购，需科技部门与合规部门共同推动 |
| 城商行、省农信联社、银行科技子公司 | 制度问答 + 信贷材料整理，按一个分行或产品线试点 | 多机构统一部署时的数据隔离、归属与运维责任划分 | 正式采购与招标，周期较长，通常以区域试点起步 |
| 保险公司分支机构、保险中介与经纪代理 | 条款问答、理赔材料缺件提示、营销合规预检 | 销售行为可回溯与禁止误导的要求；不做核保与理赔结论 | 分支或中介负责人决策，周期短；总部报备视制度而定 |
| 企业金融相关部门（集团财务公司、资金管理部、财务共享中心、供应链金融与保理平台、上市公司董办） | 信贷与尽调材料整理、单证与合同核对、信息披露合规预检 | 无金融牌照约束，落地最快；但集团数据密级与审批流程要先理清 | 企业采购流程，周期最短 |
| 私募基金管理人、券商分支、期货公司、地方 AMC、信托 | 制度与监管问答、审计与内控自查、信息摘要 | 严格避开投顾与荐股：不生成投资建议，不对外发布 | 合规与中后台部门推动，需走信息安全管理要求 |
| 金融 IT 集成商、持牌机构的外包服务商 | 按最终客户场景组合，我们交付 AI 层 | 资质、入围资格与最终客户的准入要求由合作方承担 | 技术分包与联合交付，是进入大中型机构的现实路径 |
| 国有大行、股份制银行总行 | — | 需入围供应商库、信创清单与完整安全评估 | 直销成本高，通常只以分包形式参与 |
上表是常见情况的归纳，不代表每家机构都如此，实际路径以机构自身制度为准。我们不参与也不代办招标评标环节；需要进入正式采购流程时，可与具备相应资质的集成商合作。我们不承接的业务：无牌放贷与助贷导流、现金贷、虚拟货币与数字资产、荐股与投资建议类平台、以替代数据对个人作信用评价的服务，以及任何以规避监管为目的的需求。
哪些工作适合交给 AI，哪些我们明确不做
适合 AI 的是“重复、耗时、有依据可查”的工作。涉及金融决策、客户权益与持牌业务的部分，仍由机构岗位人员负责。右侧这十条是我们写进方案的硬边界，不随模块增加而放宽。
通常成立的场景
- 查依据：制度、监管文件、产品与费率规则的条款级问答，答案附原文出处
- 抽要素：征信报告、财报、合同、流水的字段抽取，可定位回原文
- 对不一致：材料之间、材料与业务规则之间的交叉比对与缺件清单
- 起初稿：尽调与申报材料、调查说明、报送说明、答复与报告初稿
- 留痕迹：提问、命中片段、模型版本、生成内容与人工修改全程可追溯
- 合规预检：对外文案与话术的风险点标注与依据提示
- 口径问答：报送与指标口径“按哪份文件哪一条”的查询
- 科技自用：指标口径、查询 SQL 初稿、接口文档与测试用例
我们明确不做的事
- 不输出授信、额度、利率定价与准入拒绝的结论，不替代信贷审批判断
- 不提供投资建议、不荐股、不预测收益，不面向金融消费者做理财顾问
- 不做自动核保，不做理赔定损定责与赔付、拒赔结论
- 不判断交易是否可疑、不调整监测规则阈值、不做自动上报
- 不做信用评分与替代数据信用评价，不承接征信类持牌业务，不做数据聚合变现
- 不以机构名义无人值守地直接答复客户，不做对客自动外呼与催收执行
- 不接入核心账务、支付清算与交易链路做写操作，不参与实时交易决策
- 不使用境外大模型 API、不发生数据出境；未经书面授权不用机构数据训练模型
- 不代机构签署、不代取数、不代报送监管数据
- 不承诺具体准确率数字，不承诺通过任何监管检查、评估或审计
数据、依据与留痕：先把规则定下来
金融数据的敏感度与监管密度都高于一般企业场景。《银行保险机构数据安全管理办法》对数据分级、第三方合作与外部服务商准入提出了要求，证券基金期货机构适用《证券期货业网络和信息安全管理办法》；《个人信息保护法》《数据安全法》《网络安全法》与网络安全等级保护、商用密码应用的要求同样适用。业务侧的边界来自另一组文件：《商业银行互联网贷款管理暂行办法》明确核心风控环节不得外包，《银行业保险业数字化转型指导意见》要求模型可解释、人工复核，不得完全依赖模型自动决策；《征信业务管理办法》下以替代数据对个人作信用评价属持牌业务；提供具体投资建议需投顾资质；《保险销售行为管理办法》对销售可回溯与禁止误导有要求；《反洗钱法》下客户尽职调查与可疑交易报告义务在机构，不可转移。
我们的做法：一、需要牌照的业务一律不做，也不帮助规避；二、所有需要判断与承担后果的环节都留给岗位人员，系统只给依据、清单与初稿，并把每一条结论定位回原文；三、按机构的数据分级做权限设计，权限过滤前置到检索阶段，越权资料不进入召回结果；四、全链路留痕——提问、命中片段、模型与提示词版本、生成内容、人工修改与采纳记录，按人按时间可追溯，可直接用于内审与检查；五、只使用国产已完成备案或登记的模型，不接境外 API、不发生数据出境；六、涉及牌照、决策与报送的责任划分，在项目启动前书面约定。
理解边界：以上是技术与流程上的配合，不代替机构自身的合规责任。我们在机构的合规框架内是信息系统供应商与第三方技术服务商，不是金融业务的参与方。具体适用哪些要求、谁是个人信息处理者、谁是受托处理方、模型风险管理责任如何划分，需在项目启动前以书面方式约定。若机构计划把能力接到对客渠道，适用的义务与本页假设不同（《生成式人工智能服务管理暂行办法》针对向境内公众提供服务的情形），需单独判断；对外发布的 AI 生成内容，机构按《人工智能生成合成内容标识办法》履行标识义务，系统提供生成标记与导出留痕来配合。本页引用的文件仅用于说明我们的设计取向，不构成法律意见，机构应以自身法务、合规部门与监管部门的口径为准。
政策依据：《银行保险机构数据安全管理办法》｜《证券期货业网络和信息安全管理办法》｜《商业银行互联网贷款管理暂行办法》｜《银行业保险业数字化转型指导意见》｜《征信业务管理办法》｜《保险销售行为管理办法》｜《反洗钱法》｜《个人信息保护法》《数据安全法》《网络安全法》｜《生成式人工智能服务管理暂行办法》｜《人工智能生成合成内容标识办法》
数据处理
- 本地部署：模型权重与数据全部在机构内网，推理不调用外部接口，可在不连公网环境运行
- 自有云账号：限定在机构控制的云资源内，按机构安全策略配置访问、备份与运维
- 按机构数据分级做角色授权，权限过滤在检索阶段前置，越权资料不进召回
- 提问、命中片段、生成内容与导出全程留日志，可按人按时间追溯
- 云端验证期只用脱敏或虚构的测试数据，开始前书面确认
- 未经书面授权，不把机构数据用于任何模型训练或调优
人机协同与模型治理
- 系统提供依据、清单与初稿，决策与签署由岗位人员完成并留痕
- 每条答案附原文出处与版本，查不到依据时明确拒答，不编造条款
- 比率与口径计算走代码与 SQL，不交给模型计算
- 只选用国产已完成备案或登记的模型，不接境外 API
- 交付模型与版本清单、评估记录、变更与下线回退记录，可用于内审
- 不承诺具体准确率数字，以机构自出的评估集与并行期比对为准
能力边界：现成能力 / 项目评估 / 后续方向
把三件事分开说清楚，避免把规划当成现成功能。第一档可以演示，第二档需要用机构的真实材料与现场条件实测确认，第三档不作为交付承诺。
现成能力
已有可运行实现
以下能力已有可运行实现，具体配置与交付边界以合同及演示确认为准。
- 制度、监管文件与业务资料批量入库与增量更新
- 版式文档与表格解析（Word / PDF / 扫描件）
- 按条款与章节切分、版本与失效标记管理
- 向量与关键词混合检索
- 重排序精排
- 答案附原文出处与条款定位
- 低置信拒答策略
- 角色权限与资料密级隔离，权限前置到检索
- 结构化要素抽取（schema 约束 + 置信度 + 原文定位）
- 抽取结果之间与业务规则之间的交叉比对、缺件清单
- 材料初稿、答复初稿与说明文字生成
- 对外文案的风险点标注与依据提示
- 提问、命中片段、生成内容与导出留痕审计
- 模型与版本、提示词变更记录台账
- 评估集管理与版本回归对比
- 云端模型与本地模型双接入
项目评估
需按机构现场条件确认实现方案
以下内容不作为默认现成功能，需在需求与技术评估阶段逐项确认，并用机构自己的真实样本实测。
- 复杂表格的识别与结构还原：财务报表与银行流水中的扫描件、影印件、跨页表格、手写批注与非标格式，难度远高于文本材料，需先用真实样本做质量摸底，再按材料类型与字段确定可自动化的范围与比例。
- 与业务系统对接：信贷、核心、CRM、影像、OA 与统一身份认证的接口，取决于对方是否提供开放接口、数据库读取权限及原厂商配合程度，需逐个系统评估。默认只读不写回，核心账务与交易链路不做写操作。
- 第三方服务商准入与安全评估：资质材料、安全能力说明、数据流与权限图、渗透测试配合与整改、保密与审计条款，按机构流程推进，工作量需单独计入周期。
- 等级保护与商用密码应用：日志留存、身份认证、传输与存储加密、密码产品合规等系统侧配合，需与机构的测评与密评安排对齐。
- 信创与国产化适配：国产算力卡、麒麟 / 统信操作系统、达梦 / 人大金仓数据库、国产中间件的适配情况在评估阶段实测确认，不预先承诺。
- 多机构统一部署：省联社、集团或科技子公司统一部署时的租户隔离、使用配额、数据归属与运维责任划分，需共同设计。
- 行业与机构口径的术语对齐：同一指标在不同机构、不同报送口径下定义不同，需先完成术语与口径表的梳理与确认。
- 工作流与审批集成：把初稿与清单接入机构既有的审批与留痕流程，取决于流程平台的开放程度。
- 模型微调：多数场景通过检索优化与提示设计即可满足，不默认微调；确需微调时需评估标注规模、数据使用授权、许可条款与后续维护成本。
- 语音相关场景：坐席录音转写、质检与外呼需另配语音识别模型，不属于文本模型能力，单独评估；对客自动外呼不做。
后续方向
持续增强方向
当前不作为现有功能承诺；如项目有明确需求，可在需求阶段确认实现条件与范围。这一档会随模型能力与监管要求的变化定期调整，不是一张写死的清单——今天在这里的条目，确认可稳定交付后会移到前两档。
- 制度修订后，自动比对受影响的流程文件与操作手册并给出待更新清单
- 监管报送口径变化的差异提示与影响范围梳理
- 跨部门长流程的多智能体协作（如一次检查迎检中的材料调度与进度跟踪）
- 尽调材料的时序分析（同一客户多期材料的变化与异常提示）
- 面向岗位的个性化助手（按岗位与使用习惯沉淀提示词与模板）
- 影像与票据的多模态核验（涉及客户影像资料，须先完成合规论证，当前不作为可交付功能）
验收依据：机构出题，机构判定
下面每一项都可以在机构自己的材料上复现。测试集由机构出题、机构判定，我们不预设通过率，也不以准确率百分比作为合同承诺指标。
| 测试项 | 怎么测 | 通过标准 |
|---|---|---|
| 制度问答的依据正确性 | 机构自己出 50 道真实业务与合规问题，逐题核对答案引用的文件、条款与版本。 | 引用的文件、条款与版本正确，答案与现行制度、监管文件不冲突。 |
| 没有依据时的拒答 | 另出 20 道知识库内确实没有依据的问题，含几道容易被“编条款”的提问。 | 全部回答“未找到依据”并给出相近文件线索，不编造条款与文号。 |
| 要素抽取的字段准确性 | 按材料类型各取真实样本（征信报告、财报、合同、流水），逐字段与人工录入结果比对。 | 按字段分类给出结论：哪些可自动化、哪些需人工复核、哪些暂不可用；每个字段可定位回原文。 |
| 不一致与缺件的发现能力 | 在真实材料中由机构人为植入若干处不一致与缺件，统计漏报与误报。 | 漏报与误报逐条可解释；清单可作为复核起点，而非直接采用。 |
| 计算口径的正确性 | 抽查比率与汇总类指标，核对取数口径说明与计算路径。 | 计算由代码完成、路径可复现；模型只给口径定位与说明文字，不自行算数。 |
| 权限与数据边界 | 用不同部门、不同角色的账号问同一个问题，并抽查日志。 | 越权资料不出现在召回结果中；每次提问、命中片段与导出都有日志，可按人按时间追溯。 |
| 模型治理档案完整性 | 按内审视角抽查模型清单、版本、提示词与配置变更、评估记录与回退预案。 | 记录完整、可导出，能回答“某一天某个答案是哪个模型、哪个版本给出的”。 |
| 并行期实际效果 | 选一个部门或一条产品线，人工与系统并行跑一个完整业务周期。 | 实际节省的工时、返工率与遗留问题清单，由机构记录并确认。 |
验收口径：以上述可复现的测试项为准，不以“系统已部署完成”或“功能已上线”作为验收。评估集与通过标准在项目启动时一并写入验收口径；我们不承诺具体准确率数字，也不承诺通过任何监管检查、评估或审计。
四种部署形态与四种合作方式
“数据不出机构”有几种不同程度，对应的数据边界、采购方式与运维责任都不同，需要先对齐概念再谈方案。
机构内网本地部署
部署在机构自有服务器或一体机上，模型权重与数据都在内网，推理不调用外部接口；可在不连公网的环境运行。适合已确认要处理真实业务数据、且有机房与运维条件的机构。
机构自有云账号 / 金融云专区
部署在机构自己控制的云资源内，按机构安全策略配置访问、备份与运维方式。省去机房与硬件采购，数据边界仍在机构名下。
集团 / 省联社统一部署
由集团、省联社或科技子公司统一部署，按下属机构划分租户与使用配额。需在设计阶段明确数据隔离、数据归属与运维责任划分。
云端先验证
先用云端形态验证场景是否成立，再决定是否上硬件。验证期只用脱敏或虚构的测试数据，不传真实客户信息与业务数据；这一点需要在开始前书面确认。
怎么开始：从一轮场景评估起步
不建议一上来就铺全机构。四种合作方式按投入从小到大排列，多数客户从第一种开始。
一、场景评估（2–4 周）
现状梳理、用机构真实样本做质量摸底、评估集设计，产出可行性结论与“现成能力 / 项目评估 / 后续方向”分档清单，以及数据边界与合规责任划分的书面确认。这份报告可直接用于机构内部立项。
二、单场景试点交付（6–12 周）
一个模块落地，范围限定在一个部门或一条产品线；用机构自出的评估集验收，加一个完整业务周期的并行期，再决定是否扩大。
三、平台化交付与年度服务
知识库、多模块、权限体系、留痕与模型治理台账一并交付，按年提供模型与制度更新维护、评估集回归与版本升级。
四、技术分包与联合交付
与集成商或金融 IT 厂商合作：我们交付 AI 层与配套文档，合作方承担资质、入围资格与最终客户的准入要求。
每个项目都交付一份模型治理与合规档案：模型与版本清单、评估集与评估结果、提示词与配置变更记录、数据流与权限图、留痕与审计方案、第三方安全评估问卷应答包、下线与回退预案。这套做法沿用我们在 GxP 计算机化系统验证上的文档方法，目的是让机构在内审与检查时说得清。国产算力卡的型号与供货变化较快，硬件型号、供货与项目预算一律以评估时的当期情况为准，官网不标价；硬件量级可先用配置计算器估算，再以实测确认。
常见问题
你们是做智能风控的吗？能不能直接给出授信结论？
不是，也不能。我们做的是材料侧的工作：把征信报告、财报、流水、合同里的要素抽出来，做交叉比对，列出不一致和缺件，生成尽调与申报材料初稿，并把每个字段定位回原文。是否准入、给多少额度、什么价格，由机构的信贷岗位和审批流程决定——《商业银行互联网贷款管理暂行办法》明确核心风控环节不得外包，《银行业保险业数字化转型指导意见》也要求模型可解释、人工复核，不得完全依赖模型自动决策。我们不做信用评分，也不承接任何征信类持牌业务。
模块就这些吗？我们想要的场景不在列表里怎么办？
列出来的是目前已经在做和已经评估过的，不是能力上限。金融场景和监管要求都在变，所以我们固定的是方法而不是清单：任何新场景都按同一套流程判断——输入什么、输出什么、人在哪里介入、谁对结果负责。这四件事能说清就可以进入评估，再用机构自己出的评估集验收；说不清的，我们会直接讲为什么现在不适合做。唯一不随模块增加而改变的是硬边界：授信与定价结论、投资建议、核保理赔结论、可疑交易上报判断、信用评分，始终不由系统给出。
数据会不会出机构？会不会用我们的数据训练模型？
不会。本地部署形态下模型权重与数据都在机构内网，推理不调用外部接口，可在不连公网的环境运行；云账号形态限定在机构自己控制的云资源内。我们只使用国产已完成备案或登记的模型，不接境外大模型 API，不发生数据出境。未经机构书面授权，不把机构数据用于任何模型训练或调优。需要先验证场景时可以用云端形态，但验证期只用脱敏或虚构的测试数据，这一点开始前书面确认。
我们是农商行，上这类系统需要走第三方服务商准入吗？
需要，而且这通常是项目周期里最长的一段。《银行保险机构数据安全管理办法》对数据分级、第三方合作与外部服务商准入有明确要求，证券基金期货机构则适用《证券期货业网络和信息安全管理办法》。我们会配合提供公司资质、安全能力说明、数据流与权限图、渗透测试配合、运维与保密责任划分等准入材料，并按机构的变更与投产流程走。建议把这部分工作量单独计入周期，不要按普通企业项目估。
AI 生成的内容对外用，要不要标识？
要看用在哪里。《人工智能生成合成内容标识办法》对生成合成内容的标识义务有规定，机构对外发布的营销材料、客户答复等如使用 AI 生成内容，标识义务在机构一侧，我们在系统里提供生成内容的标记与导出留痕来配合。另外，《生成式人工智能服务管理暂行办法》针对的是向境内公众提供服务的情形——我们交付的是机构内部员工使用、不面向公众的系统，但如果机构要把能力接到对客渠道，适用的义务会不同，需要在方案阶段单独判断。
能接我们的核心系统、信贷系统、CRM 吗？
要逐个系统评估，取决于对方是否提供开放接口、能否给到数据库读取权限以及原厂商的配合程度。我们的默认做法是只读取、不写回：从业务系统取材料和参数做整理与比对，结果以初稿和清单的形式交给岗位人员，由人在原系统里操作。核心账务、支付清算与交易链路一律不做写操作。这属于项目评估项，不是开箱即用的现成功能。
财报和银行流水这种表格，抽取能做到什么程度？
必须先用你们自己的真实样本摸底，不在评估前承诺。文本类材料（合同、征信报告文字段、制度文件）相对成熟；标准版式的报表抽取可做；扫描件、影印件、跨页表格、手写批注和非标格式的流水，识别与结构还原的难度大得多。标准做法是先取一批真实样本做一轮质量摸底，按材料类型和字段逐类确定哪些能自动化、自动化到什么比例、哪些仍需全量人工。还有一条原则：比率与口径的计算一律走代码，不交给模型算，模型只负责定位取数口径和写说明文字。
预算怎么估？多久能看到效果？
官网不标价。常规做法是先做一轮 2–4 周的场景评估：用你们的真实样本做摸底，产出可行性结论、分档能力清单和评估集设计，这份报告本身可以用于内部立项。之后按单场景试点交付（通常 6–12 周，一个部门或一个产品线，不铺全机构），用你们自己出的评估集加并行期验收。预算按实施、资料整理、接口、硬件与年度服务分项评估；硬件型号、供货与价格一律以评估时当期情况为准。
预约一次金融场景交流
告诉我们机构类型和最想减轻的材料类工作，我们给出适合先上的模块、部署形态，以及一个可以验收的试点范围。
- 按机构类型选出先做的一到两个模块
- 对齐数据边界：哪些资料进知识库，客户信息要不要进
- 给出部署形态建议（内网本地 / 自有云 / 统一部署 / 先云端验证）
- 一起设计由机构出题的评估集与并行期验收口径
- 明确哪些事我们不做，并写进方案
- 不把规划能力当作现成功能承诺
电话：13716687203 邮箱：info@zzxytech.com
沟通前可以先准备
以下信息能让第一次沟通直接进入实质讨论，没有也可以先聊。
- 机构类型（银行、保险、担保小贷租赁保理、企业金融部门、基金券商等）
- 最想减轻的具体工作，以及目前每月的大致材料量
- 可以进知识库的资料类型与数量（制度、监管文件、产品与费率、历史工单）
- 是否涉及客户个人信息与业务数据，以及本机构的数据分级制度
- 是否有国产化、信创、等保与密评方面的要求
- 第三方服务商准入流程，以及需要对接的业务系统与接口条件