明确数据可以流向哪里

区分两条数据流

Vibe coding 适合用虚构记录探索工作流。当真实公司信息进入工具时，风险就会变化。这可能发生在应用尚无用户之前。

需要检查两条数据流。开发数据流包括提示词、代码仓库上下文、附件、工具输出和诊断日志。应用数据流包括用户请求、数据库、集成、遥测和备份。两者可能有不同接收方和控制措施。

考虑一个虚构的费用报销应用。数据库运行在获准的云账户中。开发者为了修复解析器，将一份真实报销申请粘贴进助手。申请包含员工姓名、收据和银行信息。数据库位置已经获准，不能证明这次单独披露也得到许可。

检查完整路径

加入机密数据前先画出路径，标明每一步的实际服务和账户。“企业版”这样的产品标签不是数据流图。

记录适用合同和配置。在相关情况下，检查次级处理方、删除行为、训练条款和跨境传输。请隐私与安全负责人解决不确定事项。

GDPR 要求取决于具体处理情境。相关规定包括数据最小化、处理方安排、安全和影响评估。公司保密要求还涵盖非个人数据，例如源代码或商业计划。阅读法规。

从有用的虚构测试数据开始

安全示例仍需保留贴近实际的结构。替换姓名、标识符和账号。保留导致缺陷的条件，例如缺失字段、异常日期或过长描述。

不要只改一个名字，就把复制的生产记录标成“合成数据”。剩余字段仍可能识别个人或泄露交易。应根据数据模式和失败条件创建新记录。

不要将凭据放入提示词或测试夹具。如果任务需要秘密信息，使用获准的秘密信息机制，并限制访问。“请保密”这样的指令不能强制落实技术边界。

先验证，再扩大使用

写一份简短的允许用途决定，包含数据类别、获准服务配置、允许操作和负责人。加入失效条件或复核触发条件。新增连接器、模型路由或日志配置，都可能改变这个决定。

如果信息流向未经批准的接收方，停止进一步披露并遵循事件处理流程。记录共享了什么、发到了哪里。不要将敏感材料复制到更多工单或聊天中。

实际目标是受控使用。虚构数据支持快速探索。经过验证的处理边界，支持下一步接入公司工作流。精美演示或某个云区域，都不能回答所有必要问题。