金融政务内网部署 Cherry Studio，模型 API 接入要做哪些合规配置？

Cherry Studio 在金融政务场景下的 API 合规配置，核心是把「模型从哪来、密钥谁管、日志留哪」三件事从桌面客户端上移到可控的服务端网关上，客户端只保留交互与本地会话。只调整客户端界面里的开关、不做网关侧治理的方案，难以通过数据不出域和调用可追溯这两条硬要求。这套配置适用于内网或专网内部署，员工用公网个人版直连公有云模型的方式不在此列。 模型来源必须可备案、可追责，这是金融政务场景的第一道门槛。Cherry Studio 的服务商条目只能指向已完成生成式人工智能服务备案的境内模型服务，或行内自建的推理服务；直接填境外厂商的公有云地址，会同时触发数据出境和生成内容安全两类问题。做法是先在网关侧把可用模型收敛成白名单，再在客户端只暴露白名单内的模型名。 接入地址应当填内网网关的兼容接口，而不是模型厂商的官方域名。这样所有请求都经过同一个出口，限流、审计、脱敏才有落点；如果客户端允许自行填写任意 Base URL，员工就能绕过网关直连外网。实施时把服务商配置做成不可编辑的预设，或通过统一配置文件下发，并关闭「自动获取模型列表」这类会外联的选项。 API Key 不能以长期明文形式留在终端。桌面客户端的配置文件、日志、崩溃转储都可能带出密钥；正确做法是网关按人下发短期凭证，绑定工号与设备，设置额度与有效期，人员离职或凭证泄露时可即时吊销。多人共用一个 Key 的做法，在审计上等于没有审计。 客户端的隐私与外联开关必须在打包阶段处理，而不是让员工自己关。更新检查、错误与使用数据上报、模型联网检索、插件市场下载都属于外联行为，在隔离网内要么关闭，要么指向内网镜像与代理。验收时用抓包看客户端从启动到完成一次问答之间有没有计划外的域名请求，比看设置界面可靠。 审计日志的落点应该在网关侧，终端只保留业务必需的会话内容。网关记录调用人、时间、模型名、输入输出摘要与 token 用量，敏感字段按规则脱敏后再入库，保存期限对齐监管与内部审计要求；终端侧则关闭自动云同步，会话与知识库索引留在本地加密盘。这样即使终端丢失，也不会连带丢失一份完整的调用记录。 知识库入库前必须完成数据分级，涉密信息与个人金融信息不应进入向量库。RAG 的风险不在模型，而在把不该检索的文档切碎后长期存放；做法是先建立文档准入清单，再对切片做权限继承，让不同岗位检索到不同范围。Embedding 模型同样要走内网网关，不能因为「只是向量化」就放行外网调用。 桌面客户端本身不是权限系统，租户隔离、模型白名单和内容过滤要放在网关。Cherry Studio 是单机应用，助手、提示词、知识库都在本地，无法承担行内多岗位的细粒度授权；把用户身份、可用模型、可检索知识库绑定在网关的令牌上，客户端只做呈现，权限变更才能即时生效。 终端与供应链也要纳入配置范围。客户端版本应统一分发、校验签名、禁止自动升级到未审版本，MCP 与插件按白名单开放，避免一个第三方工具把内网数据带出去。对无法管控个人安装软件的岗位，宁可只提供网页版入口，也不要放开桌面端的自定义服务商权限。 生成内容需要保底过滤与人工复核，尤其是在对外答复、信贷材料、政策解读这类场景。网关侧接入敏感词与合规审核，对高风险输出做拦截与提示；面向公众的输出必须有人复核，纯内部草稿和检索辅助可以放宽到提示级。把「模型说什么就发什么」的流程直接搬到政务窗口，风险不在技术而在责任归属。 验收可以用三条测试：断网后客户端能否正常启动并只用内网模型、把 Key 从终端复制到外部环境是否立即失效、按工号能否查到完整调用记录。三条都过，说明配置基本到位；只过第一条，通常意味着密钥和审计还停在终端侧。最常见的误区是认为装了客户端、选了本地知识库就算合规，实际上模型请求照样在往外发。