营销团队几小时做出应用，为什么过不了合规这一关？

一个营销创意，从想法到能跑起来的应用，现在可能只需要几个小时。但把它推到能正式使用的状态，往往要难得多。

它能不能碰客户数据？输出内容会不会泄露重大非公开信息？上线前该由谁来审？这些问题决定了一个看起来不错的实验，究竟能不能变成团队真正能用的东西。而答案取决于你具体在建什么。

一个用公开信息做投放排期的工具，和一个处理机密记录的投资者门户，需要的审查力度完全不同。这份面向金融服务行业营销团队的说明，正是围绕这种差异展开：平台本身怎么保护，建在上面的应用怎么保护，以及发布之前团队该想清楚哪些事。

平台安全与应用安全，是两件事

安全被拆成两个层面来看：团队搭建所依托的平台，以及团队自己创建出来的应用。

平台安全保护的是构建环境，并让组织对访问权限有控制力。它涵盖的措施包括加密、工作区之间的隔离、企业身份控制、审计日志，以及个人身份信息（PII）的检测、拦截与清除。这些能力帮助安全团队把平台当作一个供应商来评估，并对其使用进行治理。

应用安全则用来识别你建出来的东西里存在哪些风险。平台会针对不安全的数据权限、暴露的凭证、存在漏洞的依赖项，以及应用代码漏洞等问题提供检查。这些安全发现，为构建者和技术团队在发布前审查和改进应用提供了依据。

动手之前，先给项目定个风险档

在开始构建之前，有几个问题可以帮助评估项目的风险。这些问题用来建立一个实际的风险画像，相关示例只是内部评估的起点，而不是正式的监管分类。

需要特别注意的是，“内部”并不自动等于低风险。一个包含重大非公开信息的内部应用，可能需要相当严格的控制措施。

这些示例描述的是风险，而不是把某一类数据提供给平台的许可。在接入客户记录之前，要对照你的协议核查数据是否被允许。商业版和企业版数据处理协议（DPA）第3.8节禁止提供敏感数据，包括金融账号、政府身份标识、生物特征数据，以及受保护的健康信息。访问控制和欧盟推理都不能凌驾于这些限制之上。

根据上面的答案来决定应用应该允许什么，前提是已经确认数据在协议下是被允许的。对于被允许的内部或机密信息，要明确谁能看到它。如果应用会修改记录或发送消息，就要定义谁可以执行这些操作。

在向平台描述需求时把这些要求写清楚，然后测试它们是否真的生效。

连接器、训练数据与合规，逐项确认

连接器让你可以在平台里使用客户关系管理系统、电子表格和文档库这类工具。有几种连接类型需要熟悉，它们是连接方式，而不是彼此独立的工具清单——一个工具可能支持不止一种连接类型。

对于应用加聊天这类连接器，你可以选择哪些同事能用这个连接来构建应用。另外，每个已发布应用谁能查看，是在发布设置里单独选择的。

一个具体例子：给营销团队五个人用的仪表盘。

搞清楚应用需要什么数据之后，还要检查这些数据会被如何处理。

关于训练：根据组织与平台签订的协议，商业版和企业版客户的内容，包括提示词、附件、代码、项目文件和生成结果，默认被排除在模型训练之外。而在免费版和专业版上，除非你主动选择退出，数据可能会被用于训练。

关于GDPR：平台支持GDPR相关要求，并在商业版和企业版计划中提供数据处理协议。该协议规定了平台代表组织处理个人数据时的义务，包括安全措施、次级处理者、国际传输，以及协助行使数据保护权利。

关于欧盟推理与数据驻留的区别：欧盟推理控制的是AI模型请求在哪里被处理，数据驻留关心的则是数据存储在哪里。在企业版上，欧盟推理会把构建过程中以及已发布应用内置AI连接器发出的模型请求，路由到指定的欧盟端点。如果没有可用的合规端点来服务某个请求，请求会失败，而不是被转到别处。不同供应商的边界不一样，部分功能不可用，某些代理工具仍在美国处理数据。

这个设置不会改变应用数据存储的位置。如果你直接接入某个AI供应商，需要单独评估那条连接。

关于托管：通过平台发布时，应用会被托管在一个 lovable.app 地址上。付费计划可以连接自定义域名。平台云提供内置后端，用于数据库、文件存储、身份验证和服务端函数等功能。

前端在全球分发。云项目的区域决定其后端数据库和文件存储在哪里，这一点要和AI处理位置分开核查。你也可以使用接入的 Supabase 后端，或者在平台之外部署。

数据安全方面还要检查什么？限制对私有文件和数据库记录的访问，只收集应用真正需要的信息。定义保留和删除要求，包括从已连接工具导入的副本。

对于密钥和凭证，使用平台的安全输入和后端密钥存储。存储在那里的值会被加密，并在后端函数调用时提供。