先做字段分级
同一份周报里，形象进度可以公开，分包结算价、索赔意向和人员身份信息不能。上线前把字段分成公开、内部、敏感三级，敏感字段默认不进入模型调用，需要时做替换或聚合。这一步决定后面所有部署选项。也是分级是否有效的边界。
三种部署的取舍
内网部署数据不出场，适合业主有明确要求的项目，代价是算力投入与运维人力；专有云兼顾隔离与弹性；公有云接口最省事，但必须确认数据不被留存与训练。选择依据是数据级别和合同条款，不是模型效果。而不是模型效果，这是选型的边界。
权限与日志要能查
周报系统要按项目、按角色分配可见范围，跨项目不可互查；导出、下载与批量查询都留日志。日志保留多久、谁能查阅写进管理办法，否则一旦出现泄露，既定位不到人，也说不清影响范围。所以怎么留痕要提前定。
合同里写清数据条款
与服务方约定数据用途仅限本项目，不留存、不训练，支持导出与删除，分包处理需报备。等保与网络数据安全管理的通用要求可作基线，具体条款仍要由企业信息安全与法务审核后签署，不能由业务部门单独拍板。这是职责边界。
适用与不适用
适合谁
- 周报含产值、分包与人员信息的施工企业
- 业主对数据出网有明确限制的项目
- 设有信息安全责任人或等保任务的集团
不适合谁
- 愿意把全部项目数据放到公开试用平台的企业
- 尚未理清字段就要求定部署方案的项目
典型场景
某集团有十二个在建项目，周报口径统一到经营部。信息部门把字段分为三级，产值与分包价格留在内网数据库，只把进度百分比与劳力人数脱敏后送外部模型生成文字段落。系统按项目授权，导出需审批并留日志，每季度由信息安全岗抽查一次。
可执行步骤
- 梳理周报的全部字段，按公开、内部、敏感三级标注，形成字段清单
- 按项目与角色配置可见范围，默认关闭跨项目查询与批量导出等功能
- 把脱敏规则放在取数环节执行，避免导出之后再靠人工删改，减少遗漏
- 与服务方签署数据处理条款，明确不用于训练、项目结束可导出并删除
- 每季度抽查访问日志与导出记录，发现越权访问即收回账号权限并通报
常见坑
- 把整份周报直接贴进公网对话工具，产值与分包价格一并外泄，事后难以补救，也无法证明未被留存。
- 只设登录密码、不做项目隔离，任一账号都能查到全部在建项目的经营数据与分包价格，事后无从追查。
- 供应方口头承诺不训练，合同里却没有对应条款，出现争议时无法追责，也拿不出任何举证材料。
- 日志开了却无人查看，越权导出发生数月后才被发现，损失已经无法挽回，责任也难界定。
自检与验收清单
- 字段是否完成公开、内部、敏感三级分类并经人确认
- 敏感字段是否默认不进入任何模型调用范围内
- 是否按项目隔离权限，并留存完整的导出日志
- 合同是否包含不用于训练、可删除的明确条款
- 日志是否指定岗位定期抽查并留存完整的核查记录
常见问题
内网部署是不是最安全？
相对可控，但不等于安全。内网同样要管账号、补丁、备份与日志，模型和依赖也要更新。运维人力不足时，长期不更新的内网反而积累风险，需先评估自身运维能力再决定。
用外部模型接口就一定违规吗？
不一定。关键看数据类型与合同约定：公开或脱敏后的进度数据风险较低，含价格与个人信息的字段应留在内部。具体是否合规要由企业信息安全与法务判断，本文不构成合规意见。
项目结束后数据怎么处理？
合同应约定导出格式与删除时限，供应方出具删除确认；企业侧保留必要的履约记录以备审计，其余按内部留存制度清理。删除动作要有记录，不能只做口头说明。