Cherry Studio 接入金融政务场景时，API 合规配置到底要盯住哪几个关键环节？

Cherry Studio 在金融政务场景做 API 合规配置，重点不在客户端本身，而在把「接入哪个模型、数据从终端流向哪里、留下什么记录」这三件事固定成可审计的配置项。它只负责终端侧的调用发起与本地留痕，既不替代模型服务商的备案资质，也不替代单位内部的数据分级制度；如果指望靠一个客户端解决全部合规问题，在测评和检查中通常过不了关。 Cherry Studio 是安装在办公终端上的多模型客户端，对话内容与 API Key 默认保存在本机，推理请求则发往用户配置的接口地址。这一结构决定了它的合规基线是终端可控、链路可查、出口可管：谁能在这台机器上配接口、请求最终打到哪个域名、内容落在了哪个目录，都必须能在事后说清楚，否则审计时无法还原调用行为。 模型入口要先通过资质审核。金融政务场景对外提供服务的模型，应当是已完成生成式人工智能服务备案的模型，配置时核对服务商主体、备案信息与接口域名三者是否一致，Base URL 指向官方域名，不要填写来源不明的转发地址。转发地址一旦被中间环节记录或二次利用，数据流向就脱离了原本的授权范围。 传输层不能留下降级空间。接口地址统一使用 HTTPS，客户端里忽略证书校验一类的选项保持关闭，终端出网走单位统一的代理白名单，只放行已登记的模型域名，其余出网请求一律拦截。做这一步的原因是，明文传输和任意出网会让前面的资质核对失去意义。 密钥要按人按岗管理。一人一 Key、按项目分环境，测试密钥与生产密钥分离，定期轮换，人员离岗当天回收；不要把共享密钥写进统一分发的配置文件，客户端本地保存的凭据需要配合终端磁盘加密与开机口令。密钥共用是金融政务场景里最常见也最难追责的漏洞，一旦泄露无法定位到具体使用人。 数据分级是配置前的必备工作，而不是配置后的补充。先明确哪些字段允许离开终端，身份证号、银行账号、公文原文等敏感内容在粘贴前完成脱敏，涉密信息一律不进对话框；知识库向量化虽然在本机完成，索引范围也要按岗位授权收敛，避免把全单位材料装进一台普通办公机。 日志留存要能对外举证。客户端侧开启对话记录本地保存并定期导出归档，接口侧调用日志由服务商提供，需在合同里约定留存期限、调取方式与配合审计义务，满足《网络安全法》对网络日志留存不少于六个月的要求。只留界面截图不留原始日志，在检查中通常不被认可。 工具调用与联网能力默认关闭。MCP 类外部工具、网页检索、自动更新与使用数据上报，在政务内网终端上应逐项确认关闭；系统提示词里写清禁止输出的内容类型，减少不可控的外部请求。这些能力本身不是问题，问题在于它们会绕过已经设定好的出网白名单。 部署形态决定合规重心落在哪一侧。纯内网离线环境把推理放到本地模型服务，重点转向模型来源的合法性与许可证约定；混合部署则要划清内外网边界，明确哪类问题走内网模型、哪类允许出网，并在客户端里用不同的服务商条目把两条通道物理区分开。 合同条款比界面配置更能定责。签署前确认服务商是否将输入数据用于模型训练、数据存储地域、泄露通知时限、二次转委托情况以及对等保与密评的配合义务，把这些写进协议，出问题时才能分清终端侧与服务侧的边界。界面上的开关可以随时改，合同里的义务改不了。 常见误区集中在三处：装了客户端就认为合规、用个人账号处理公务、把测试密钥直接用于生产。三者都会让原本清晰的审计链断掉，事后既无法证明数据未被留存，也无法说明是谁在什么时间调用了哪个模型，补救成本远高于前期配置。 落地顺序建议是：先定数据分级与可用模型清单，再固化网络与密钥策略，最后补齐日志归档与合同条款，每一步保留配置基线截图与变更记录。这样形成的合规档案既能应对检查，也能在更换模型服务时快速复制，不必从零重来。