本地部署 AI 工作平台要划清哪些数据边界

服务器放在企业机房，不代表每一次AI处理都留在内网。提示词、附件、向量索引、连接器返回值、模型日志和生成物可能经过不同组件。企业要画清数据流，逐项决定哪些可出域、谁能批准、保留多久、出了问题如何追溯。文中给出可执行的检查方式，并明确真实数据、权限配置、责任人和审计记录必须同时成立。

“系统部署在我们自己的服务器上”是一句起点，不是完整的安全结论。企业AI通常还会连接模型服务、对象存储、向量数据库、文档解析组件和业务系统。只看应用服务器放在哪里，很容易漏掉真正的数据流。

安全负责人需要的不是一句“支持私有化”，而是一张可以逐条确认的数据流图：哪类数据从哪里来，经过哪些组件，是否离开网络边界，保存多久，由谁查看，出现异常如何追溯。

“部署在本地”不等于数据从此不出去

财务主管在本地部署的 AI 工作台里上传了《2026 年客户报价底价表.xlsx》，让 AI 整理各区间毛利。平台页面在内网，文件也存在本地，但实际生成请求调用了外部模型 API。如果系统没有提示哪些单元格被发送、是否脱敏、请求日志保留多久，“本地部署”四个字不能代替数据边界说明。

企业 AI 的数据路径至少包括文件原文、检索片段、提示词、模型请求、生成结果和调用日志。只盯着文件存储位置，会漏掉真正离开边界的那一段。

先把六类数据分开

第一类是身份和组织数据，包括员工、部门、项目角色与登录信息。第二类是业务原文，例如合同、源码、客户资料和项目文档。第三类是AI处理中间数据，包括切片、向量索引、缓存和提示词。第四类是连接器返回值。第五类是模型输出。第六类是调用日志、用量和费用数据。

这些数据敏感程度不同，保存要求也不同。业务原文可能禁止出域，用量统计却可以只保留匿名计数；模型输出可以进入项目，原始提示词未必适合长期留存。把它们混成“AI数据”，策略就会过粗。

本地平台调用外部模型时要问四个问题

发送出去的是整份文件、检索片段，还是经过脱敏的摘要？模型服务是否保留请求内容？传输和密钥如何管理？调用失败时是否会自动切换到另一模型？

最后一个问题常被忽略。模型路由能提高可用性，但如果备选服务的数据政策不同，自动切换可能突破原先边界。企业应按资料级别配置可用模型，而不是让所有任务共享同一条路由。

对于不允许出域的资料，可以使用内网模型或关闭相关AI能力；对于可控的公开内容，可以使用外部模型提高效果。安全设计的目标是允许有条件使用，不是用一个开关处理所有场景。

连接器是另一条数据通道

AI读取ERP、项目系统或数据库时，连接器不应只保存一个管理员级账号。更稳的方式是区分系统凭据和用户授权，限制可调用的工具、字段和数据范围，并记录谁在什么任务里读取了什么。

嘟哩的连接器、技能和应用助理适合承担这种业务接入，但上线前仍要确认外部系统是否提供足够细的权限接口。如果源系统只能返回全部数据，嘟哩侧的过滤不能被描述成源系统已经完成授权隔离。

输出和日志同样需要边界

AI生成的总结可能包含原文中的敏感信息。即使模型调用本身合规，把结果发进一个更大范围的群，仍然会造成越权。因此输出应继承来源权限，或在发送前重新校验接收对象。

审计日志需要足以还原调用，但不必无条件保存全部正文。可以记录调用人、时间、模型、工具、资料标识、输出位置和审批结果，对高敏场景再按制度保留必要快照。日志保存过多本身也会形成新的敏感库。

评审时用数据流，而不是功能清单

把一个真实问题走完：员工让AI读取某项目的客户合同并生成风险摘要。画出身份校验、资料检索、模型请求、结果返回、项目保存和审计记录。每经过一个边界都标注协议、权限、保存期限和责任方。

这张图能回答清楚，本地部署才真正有意义。否则“数据自主可控”只停留在服务器归属，没有覆盖AI实际工作过程。

用一张数据流记录表把边界说清楚

审查不应只问“支不支持私有化”，而要沿一次真实任务把每个节点记下来。

节点	要记录的字段	必须能回答的问题
源文件	所属空间、密级、所有人、有效期	这份资料是否允许进入 AI
检索层	命中片段、权限校验身份、脱敏规则	用户没权限的段落是否在检索前就被排除
模型调用	模型商、地域、请求内容、留存策略	哪些内容会越过企业边界
连接器	源账号、可调工具、读写范围、凭据到期时间	AI 是否可能用高权限账号绕过个人权限
输出与日志	结果存储位置、共享对象、操作人、引用来源	事后能否还原“谁用了什么数据做了什么”

嘟哩可以把组织、云盘和项目权限作为 AI 使用的基础边界，但是否完全不出网，仍取决于企业配置的模型和连接器。只有本地模型、本地检索、本地存储且不调用外部服务时，才能对具体任务说“数据未出企业环境”。

审计不能靠抽象承诺

验收时选一份带三个密级字段的测试表，分别用普通成员、部门主管和管理员发起同一个任务。检查请求记录、模型去向、输出内容和日志追溯是否一致。不能查到实际请求路径时，就不应对外使用“全程可控”这类表述。

把一次 AI 调用拆成可审计的数据路径

选一份包含客户名称、价格、联系方式的脱敏表格，让普通员工、部门主管和管理员分别发起同一个 AI 总结任务。系统要展示哪些内容被读取、是否脱敏、模型在哪里处理、结果保存到哪里。

环节	要记录什么	通过标准
源文件	空间、密级、所有人、允许进入 AI	无权限片段在检索前被排除
提示词	用户问题、命中片段、脱敏规则	敏感字段不进入模型请求
模型调用	模型供应方、区域、留存策略、耗时	外部调用必须明示边界
结果	保存位置、可见范围、引用来源	输出不扩大原文件权限

企业关心的不是页面部署在内网就够了，而是一次任务中哪些数据真正离开了哪些边界。嘟哩做私有化 AI 工作平台时，要把模型、连接器和文件权限放到同一条记录里。

怎么验收

验收时不听抽象承诺，直接查调用日志。日志还原不了“谁用什么资料生成了什么结果”时，这个场景就不能对外说已经可控。

真正落到产品页面时，要看到这些东西

信息化负责人进入嘟哩 AI 工作台时，第一眼应该看到一次内部 AI 试点的当前状态，而不是一段功能介绍。入口动作也要直接：从一个真实业务问题新建任务，不从空白对话开始。用户每做一步，系统都要把输入、确认人、状态和产物留下来，后面 AI 才有可靠上下文。

页面区域	业务字段	系统状态	AI 动作
源文件	空间、密级、所有人、允许进入 AI	当前状态、责任人、来源链接、更新时间	AI 检查“无权限片段在检索前被排除”，并给出缺口待办
提示词	用户问题、命中片段、脱敏规则	当前状态、责任人、来源链接、更新时间	AI 检查“敏感字段不进入模型请求”，并给出缺口待办
模型调用	模型供应方、区域、留存策略、耗时	当前状态、责任人、来源链接、更新时间	AI 检查“外部调用必须明示边界”，并给出缺口待办
结果	保存位置、可见范围、引用来源	当前状态、责任人、来源链接、更新时间	AI 检查“输出不扩大原文件权限”，并给出缺口待办

一天的真实使用路径可以这样设计：早上先打开看板看今日待确认事项；上午补齐缺失资料或接口数据；下午让 AI 生成分析、脚本、用例、风险或方案；执行前由负责人确认关键动作；晚上把结果、问题和下一步沉淀到同一个项目。这样用户不会觉得自己在“找 AI 聊天”，而是在推进一件有开始、有负责人、有产物、有复盘的工作。

产品里还要保留两个不太讨好、但很重要的状态：一个是“资料不足，不能判断”，另一个是“超出当前范围，建议拆分或延期”。这两句话会让页面看起来没有那么神奇，却能减少错误决策。企业场景里，靠谱比炫技更值钱。

边界说明

这一类文章涉及的是平台落地方法，不能写成嘟哩已经接入所有外部系统。外部系统暂未接通时，应先用脱敏文件或人工导入跑试点，并在页面上明确标注数据缺口。

读者真正会感受到的变化

以前是把资料临时丢给 AI，让它尽量回答；现在是先把问题、资料、权限和输出位置定清楚，再让 AI 工作。一线人员少做复制粘贴，管理者看到的是有来源的判断，安全负责人也能追踪一次调用经过了哪些边界。这段体验变化要在试点中被记录下来：用了几个入口、问了几个人、返工发生在哪一步、最终产物是否能被下一次复用。只有这些细节存在，文章里的方案才不是概念说明，而是能被团队带回去照着检查的工作方法。

常见问题

本地部署是否必须使用本地模型？

不一定。可以采用混合架构，但要按资料级别明确哪些数据可调用外部模型，并完成脱敏、授权和日志管理。

向量数据库是否保存原文？

不同实现不同。企业应确认索引内容、元数据、删除机制和备份范围，不能假设向量天然不可还原。

数据边界由IT部门单独决定吗？

不应。业务负责人定义资料重要性，安全制定规则，IT落地架构，法务和合规确认外部处理条件。