DORA 与 ICT 风险
AI 编码平台属于 ICT 工具。供应商托管的智能体会进入你的 ICT 第三方登记册；自托管平台则落入你自己的韧性范围——这些义务你本来就知道如何履行。参见<a href={`/${localeInfo[locale].prefix}/blog/ai-coding-agents-delivery-stability-dora/`}>DORA 与交付稳定性分析</a>。
部署场景 · 已核对 2026-08-05
金融服务的 AI 编码：要经得起审计，而不仅是评审。
银行、保险公司和金融科技公司在采纳 AI 编码时，面对的是这些工具当初并非为之设计的框架：DORA 运营韧性、ICT 第三方风险、外包规则与内部审计。一个可自托管的开源平台，可以把决定性的控制——代码位置、出站、日志、保留——移到你的边界之内。本页梳理金融行业特有的问题；它不是认证，也不是法律意见。
金融视角
三大框架决定采纳的形态。
你的义务取决于实体类型与司法辖区；先对工具分类，再开展试点。
外包与供应商风险
对大多数外包框架而言，由外部智能体服务处理的源代码是一项重大依赖。自托管可以把这种评估转化为内部控制。在<a href={`/${localeInfo[locale].prefix}/self-hosted/`}>自托管指南</a>中比较部署路径。
欧盟 AI 法案触点
内部编码使用与面向客户的 AI 输出是两种不同的分析——第 50 条透明度义务自 2026 年 8 月 2 日起适用于后者。<a href={`/${localeInfo[locale].prefix}/blog/eu-ai-act-article-50-transparency-deadline/`}>阅读第 50 条简报</a>。
许可证透明度
AGPL-3.0 源码可得性让安全与审计团队能够检查实际运行的内容；修改或网络服务相关的义务需要<a href={`/${localeInfo[locale].prefix}/license/`}>合格的法律评审</a>。
审计证据包
上线前，内部审计应当拿到什么。
这些证据要从你自己的部署中产出；任何供应商页面都无法提供。
01 · ICT 分类
平台在 ICT 登记册中的位置：关键性、依赖关系、恢复目标，以及必须停用时如何退出。
02 · 数据流图
每一个边界——Git 提供方、模型端点、软件包、日志、备份——都要有负责人、凭据、保留规则与允许的路径。从<a href={`/${localeInfo[locale].prefix}/security/`}>安全与数据流边界</a>入手。
03 · 变更控制记录
哪些智能体操作需要人工批准——合并、部署、依赖变更——以及证明这些评审关卡在真实任务上得到执行的日志。
04 · 试点结果
用<a href={`/${localeInfo[locale].prefix}/pilot-methodology/`}>试点方法论</a>和<a href={`/${localeInfo[locale].prefix}/coding-agent-evaluation-dataset/`}>开放数据集结构</a>记录任务、验收结果、评审工作量与失败，形成可复现的记录。
部署姿态
让隔离与数据分级相匹配。
并非每个仓库都需要同样的边界；把分级写下来并强制执行。
托管评估
非敏感仓库可以先试用托管工作流，在投入任何基础设施之前确认适配度。先在<a href={`/${localeInfo[locale].prefix}/pricing/`}>定价事实页面</a>核验供应商条款。
自托管生产
专有代码在你运营的基础设施上运行，模型路由由你配置。要求与步骤见<a href={`/${localeInfo[locale].prefix}/install/`}>安装指南</a>。
气隙飞地
对于交易、支付或其他高敏感代码，零出站运行要求本地模型与内部镜像——参见<a href={`/${localeInfo[locale].prefix}/air-gapped/`}>气隙部署</a>。
容量与成本
用<a href={`/${localeInfo[locale].prefix}/tools/self-hosting-capacity-calculator/`}>容量计算器</a>和<a href={`/${localeInfo[locale].prefix}/tools/self-hosting-tco-estimator/`}>TCO 估算器</a>，按并发任务数而非人头数来规划环境主机规模。
DORA 支柱对照
AI 编码平台如何触及 DORA 的每一根支柱。
这是对五大支柱的工程视角，而非法律意见——请与法律顾问和风险职能部门确认贵实体的范围。
| DORA 支柱 | AI 编码平台如何牵涉其中 | 应持有的证据 |
|---|---|---|
| ICT 风险管理 | 平台及其模型路由是风险框架中的 ICT 资产 | 在 ICT 登记册中登记条目，注明关键性与依赖关系 |
| 事件管理 | 智能体操作与失败需要检测、日志与上报路径 | 每任务日志，以及覆盖智能体行为的事件手册 |
| 韧性测试 | 升级、模型中断与环境故障都必须演练 | 记录的恢复演练与分阶段升级测试结果 |
| 第三方风险 | 托管智能体属于 ICT 第三方；自托管将其转为内部控制 | 供应商评估或内部控制证据，外加退出计划 |
| 信息共享 | 关于智能体发起攻击的威胁情报为你的控制提供依据 | 将外部事件与你控制更新的关联记录 |
自托管像 MonkeyCode 这样的平台，可以把若干第三方问题转化为你的审计职能已经在提供证据的内部控制问题。此对照是工程指导，不是合规意见。
分阶段上线
一个每一步都产出审计证据的推进顺序。
每个阶段都会产出一份你的风险与审计职能可在下一阶段开始前评审的产物。
- 阶段 1分类与界定范围
把平台登记为 ICT 资产，定义仓库敏感度分级，并写下一个试点必须满足的验收标准。
- 阶段 2在低敏感代码上开展有边界试点
在非敏感仓库上运行经过验收的任务，用试点数据集结构记录结果、评审工作量与失败。
- 阶段 3控制与证据加固
强制执行出站白名单、凭据轮换、评审关卡与保留规则；演练事件与恢复手册。
- 阶段 4带评审的有范围生产
对获批分级推进到生产环境，保持 ICT 登记册与证据包最新，并安排定期的韧性测试。
常见问题
金融服务的采纳，逐一回答。
相关阅读：<a href={`/${localeInfo[locale].prefix}/answers/is-monkeycode-gdpr-compliant/`}>GDPR 与部署</a>、<a href={`/${localeInfo[locale].prefix}/answers/is-monkeycode-safe-for-proprietary-code/`}>专有代码安全</a>、<a href={`/${localeInfo[locale].prefix}/regulated-industries/`}>更广泛的受监管行业指南</a>。
MonkeyCode 是否通过了银行或金融机构的认证？
本站不声称任何认证。MonkeyCode 是一个开源的 AGPL-3.0 平台，其公开文档描述了私有与离线部署方式。某次部署是否满足你的监管机构、审计师或内部风险框架的要求，取决于你的配置、运营与证据——而非供应商的声明。
DORA 与 AI 编码工具有什么关系？
DORA 要求欧盟金融实体对 ICT 风险、运营韧性和 ICT 第三方风险负责。AI 编码平台正属于该范围内的 ICT 工具：供应商托管的智能体成为需要评估的第三方依赖，而自托管平台则把同样的义务转移到你自己的运营中。无论哪种方式，都要在 ICT 登记册中对该工具进行分类；并针对你的实体咨询法律意见。
为什么金融团队偏好可自托管的 AI 编码平台？
因为外包与供应商风险框架把外部处理的源代码视为重大依赖。自托管可以把平台、代码与任务历史保留在你的边界之内，并把云供应商问题转变为内部控制问题——这恰恰是你现有的审计机制已经知道如何提供证据的领域。
上线前内部审计应该索取什么？
一份涵盖模型端点与 Git 提供方的数据流图、凭据范围与轮换记录、每任务执行日志、合并与部署的人工评审关卡证据、任务历史与备份的保留规则，以及可复现的试点结果。本站的试点方法论与评估数据集结构提供了可复用的模板。
欧盟 AI 法案的透明度规则会影响我们的工程使用吗？
《欧盟 AI 法案》第 50 条的透明度义务自 2026 年 8 月 2 日起适用，针对的是与人互动或生成展示给人看的内容的 AI 系统。纯粹内部使用的编码场景通常不在该范围内，但如果 AI 输出进入面向客户的界面，分析结果就可能改变。梳理你的触点，并与法律顾问确认。
从证据开始