你用 Lovable 搭建了应用——数据泄露时谁来负责？
一位产品经理需要一个内部仪表盘。他没有提交工单、等工程团队排期一个季度，而是打开 Lovable，用日常语言描述想要的功能，把它连接到公司的 Google Workspace，当天下午就上线了一个能用的应用。它读取 Drive 中的内容，抓取几份表格，每周发送一次摘要邮件。它能用。人人满意。
六个月后，安全审查员或监管机构问出那个关键问题时，没有人事先想到过：这个应用如何处理它所接触的数据，谁来负责？
答案不是生成代码的那个平台。是部署它的那家公司。本文将解释为什么“我们是用 AI 搭建的”不能成为一种免责理由，AI 构建的应用具体会在哪些地方出问题，以及如何在这个问题被愤怒地提出之前就获得可见性。
“AI 构建的应用”到底是什么意思
一类新工具——Lovable、Base44、Bolt.new、Cursor 以及越来越多的同类产品——让人们可以用自然语言提示来构建和部署真正的网络应用。它们常被称为“vibe coding”平台。其吸引力显而易见：一个非开发人员也能产出以前需要一整个团队才能完成的东西，而且只需几个小时。
这些应用并非玩具。它们被部署给真实用户使用，并且经常通过普通的 OAuth 授权连接到真实的公司系统——Google Workspace、Salesforce、内部数据库。从数据的角度来看，一个用提示词在一个下午搭建出来的应用，和一个工程团队花几个月开发出来的应用看起来毫无区别：两者都持有访问令牌，两者都能读取该令牌所允许读取的内容。
这种对称性正是问题的核心。让 AI 构建工具具有吸引力的那种速度，同样也让一个应用能够触及敏感数据，而没有任何人审查它对这些数据做了什么。
用 AI 搭建，并不等于是安全的
这里有必要说清楚、说公道话：用 Lovable 或 Base44 搭建的应用本身并不一定不安全。这些平台完全可以产出相当合理的应用，而且很多确实如此。风险并不在于 AI 写出了糟糕的代码。风险在于治理，它体现在三种可预见的方式上。
部署者很少去读代码。 vibe coding 的整个价值主张就是你不需要读代码。所以那个上线应用的人往往说不清它如何存储数据、是否记录敏感字段、把信息发送到了哪里、又保留多久。承担责任的一方，对自己所负责的事物的可见性却最少。
权限范围广泛而不可见。 AI 构建工具会请求让演示能够运行所需的权限范围，而“让它能运行”往往意味着大范围的读取权限。一个原本只需要读取一个文件夹的内部仪表盘，可能持有对整个 Drive 的读取权限。因为这种授权是通过普通的 OAuth 同意页面完成的，它从未出现在任何人的安全监测雷达上——按定义，这就是影子 IT。
没有成文的数据处理政策。 如果你询问一个手工搭建的生产系统的保留政策，通常能得到答案。但如果你询问同事上周二生成的一个应用的保留政策，往往没有任何记录。在数据保护法之下，“我们不知道它保留数据多久”不是一个中立的回答——它是一项调查发现。
为什么该承担责任的是公司——而不是平台
这正是让人意外的部分。当一个 AI 构建的应用不当处理数据时，法律和监管责任落在部署它的组织身上，而不是生成它的那个 AI 构建平台身上。
这与目前正在重塑整个 AI 法律格局的责任转移是同一逻辑。根据欧盟《通用数据保护条例》，决定个人数据处理目的和方式的主体是数据控制者，控制者承担相应义务——合法依据、数据最小化、存储限制，以及证明上述一切的责任。当你的公司部署一个处理客户数据的应用时，你的公司就是控制者。构建平台，最多只是你使用的一个工具。
2026 年更广泛的法律格局也指向同一个方向。法院已经开始将使用 AI 系统的公司视为对其行为负责——美国的 *Mobley v. Workday* 诉讼案就是基于代理理论推进的，后来还赢得了全国性集体诉讼的有条件认证。在德国，OLG Hamm（哈姆高等地方法院）针对 AI 系统向客户传达的信息所涉及的责任问题作出裁决，表明一份泛泛的“不作担保”免责声明本身并不能为部署公司提供保护。欧盟《人工智能法案》在此基础上又叠加了针对部署者的特定义务，对高风险用途设有重大处罚。关于这一转变，我们在《AI 代理泄露数据时谁承担责任》概览文章中有更深入的介绍。
共同的线索是：部署一个 AI 构建的应用，是你的组织做出的一个决定，而法律认定决定即须承担责任。 AI 编写了代码这一事实，丝毫改变不了究竟是谁选择把它连接到公司数据上。
具体的盲点
把这些拼在一起，就会浮现出一种具体而常见的失败模式：
- 一名非技术员工用 AI 构建工具搭建了一个应用。
- 该应用通过 OAuth 连接到 Google Workspace，并获得了大范围的权限。
- 它接触到了客户或员工的个人数据——联系人、邮件内容、文件。
- 没有人审查过数据处理方式，也没有留档的保留政策。
- 安全团队没有为该应用建立库存记录，因为它从未经过任何审查流程。
每一步单独看都合情合理。但合在一起，就产生了一个处理个人数据、你的公司须承担法律责任、而你的安全团队却不知道它存在的应用。这正是审计员会去探查、也是数据泄露会加以利用的那个缺口。
如何弥合这个缺口
解决方法不是禁用 AI 构建工具——那场竞赛早已输掉了，而且生产力提升是真实的。解决方法是可见性与证据：知道哪些 AI 构建的应用已连接，知道每一个能触及什么，并能证明你对它们进行了治理。
这正是 8200.dev 所做的事。它会发现连接到你 Google Workspace 的 OAuth 应用，并标记出那些源自 AI 构建工具——Lovable、Base44、Bolt.new、Cursor 及类似产品——的应用，依据它们的应用名称和重定向主机特征，以及一种典型模式：一个未经验证、最近创建、却已持有广泛权限的应用。对于每一个应用，你都能看到其构建平台、被授予的确切权限范围、授权人，以及一个风险评分，这些信息会在专门的AI 构建应用视图中呈现，与你其他的 AI 代理和 OAuth 应用并列展示。
当一个 AI 构建的应用能够触及客户 PII，或者持有广泛权限却没有留档的保留政策时，它会触发一条具体的调查发现——于是这个缺口变成了一项有明确负责人的任务，而不是审计中的一个意外。而且每一个 AI 构建的应用都可以记录到 AI 代理注册表中，因此即便某些应用没有任何连接器能触及到，也会出现在这份完整的库存清单里。你可以在此查看完整功能列表。
重点不是要拖慢你团队的速度。而是要确保当问题真正被提出时——来自监管机构、审计员，或是客户的安全审查——你能够回答。不是“我们是用 AI 搭建的，那是平台的问题”，这不能成为一种免责理由，而是“这就是这个应用，这就是它确切能访问的内容，这就是我们审查过它的证据”。要更深入了解如今审查方的期望，请参阅2026 年审计员对 AI 治理的要求。
用 AI 搭建速度很快。对你所搭建的东西负责，却不是可选项。要把这两者统一起来，只需要做到一件事：知道你的 AI 构建应用实际能触及什么。
从查看你的 Workspace 已经连接了什么开始。你可以在免费版中绘制你的 AI 构建应用地图、评估其访问权限评分，并生成你的第一份证据——查看方案并免费开始。
*本文为一般性信息，不构成法律意见。如需针对你所在组织的具体指导，请咨询合格的法律顾问。*