文档AI采购安全合规评估清单：
功能和价格之前，先问这14个问题

为什么安全合规应该放在第一位看

这不是危言耸听。2025年，一家金融科技公司因将含用户身份证号、银行卡号和交易明细的客服对话记录直接用于AI模型微调训练——未脱敏、未告知、未取得单独同意——被网信部门行政处罚，约12万条敏感信息泄露至黑市，平台当月GMV下滑17%。处罚依据是《个人信息保护法》第28条（敏感个人信息的处理规则）和第34条（需取得单独同意）。

这个案例暴露了一个普遍盲区：很多企业评估文档AI工具时，评估的是"能不能识别发票上的金额""支持多少种格式""导出Excel方不方便"——这些是功能维度。但没人问"处理完的文件去了哪里""供应商会不会用我的数据训练模型""数据存在哪个国家"——这些是安全合规维度。而安全合规维度的任何一项出问题，后果都可能让功能优化的全部收益归零。

这篇评估清单的设计逻辑是：把安全合规从"事后验收"提到"事前筛选"。在PoC跑通功能之前，先用这14个维度过滤一轮——能通过的供应商才有资格进入下一轮的功能比较。

14项评估清单：从基础安全到持续运营

以下14项按从基础安全到持续运营的逻辑排列。每一项都给出：核心核查问题、为什么重要，以及判断标准（哪些是不可妥协的底线，哪些是可以协商的变通项）。

1. 数据存储位置

核心问题：上传的文档和处理后的结果数据，物理存储在哪个国家/地区的服务器上？是否支持指定存储区域？

为什么重要：这直接关系到《数据安全法》和《个人信息保护法》的合规义务。如果数据存储在境外服务器上，可能触发数据出境安全评估——对于涉及个人信息或重要数据的企业，这是一项独立且耗时的合规流程。对于国有企业、政府机构、关键信息基础设施运营者，数据本地化是刚性要求。

判断标准：如果你们企业的合规政策要求数据不出境，供应商必须能提供中国大陆境内存储的选项。部分工具提供混合模式（国内用户数据存国内、海外用户数据存海外），注意确认数据分区是物理隔离而非逻辑标记。底线是：供应商必须能明确回答"数据物理存储在哪里"——连这个都回答不了的，直接排除。

2. 数据传输加密

核心问题：文件上传和结果下载的过程中，数据是否全程加密？加密协议是什么版本？

为什么重要：文档AI工具的核心交互是"上传文件→等待处理→下载结果"，数据在网络中传输的每一个环节都存在被拦截的风险。加密不是"有了就行"——TLS 1.0和1.1已被主流浏览器弃用，如果供应商仍在使用老旧协议，说明其安全基础设施的维护水平堪忧。

判断标准：要求传输层加密至少达到TLS 1.2，静态存储加密至少AES-256。端到端加密（仅用户持有密钥）是加分项但不是必需品——文档AI需要分析文档内容，纯端到端加密在技术上与AI处理流程存在冲突。另一个实际可检查的点：浏览器访问工具页面时，地址栏显示的是否是HTTPS（小锁图标）——如果在生产环境还使用HTTP明文传输，直接排除。

3. 数据保留策略

核心问题：上传的文件和处理结果在供应商的服务器上保留多长时间？用户是否可以自主配置保留期限？

为什么重要：保留时间越长，数据暴露窗口越大。《个人信息保护法》第19条要求个人信息保存期限为实现处理目的所必要的最短时间。文档AI的处理场景是"上传→处理→导出"，理想情况下处理完成后文件即应删除。

判断标准：明确询问默认保留时长和是否支持自定义。一些工具默认为"付费期内一直保留"，这对企业用户来说是不可接受的风险——内部文件（合同、工资单、财务报表）不应在第三方服务器上永久留存。可接受的最低标准：处理完成后48小时内自动删除原始文件，或允许用户手动即时删除。如果你需要定期批量处理同类文件（如月度发票），则更应确保上一批次文件在处理完成后已被清除。

4. 是否用于模型训练

核心问题：供应商是否将用户上传的文档用于其AI模型的训练或改进？

为什么重要：这是安全评估中最容易被忽视、也最危险的一项。将客户数据混入训练集意味着：你的发票信息可能成为模型参数的一部分，在回答其他用户的查询时被"泄露"出来。《生成式人工智能服务管理暂行办法》第7条明确规定，涉及个人信息的训练数据应取得个人同意。如果供应商默认将用户数据用于模型训练——而你没有阻止——你可能在不知情的情况下违反了PIPL。

判断标准：这是不可妥协的底线问题。要求供应商在合同或服务协议中明确承诺不使用客户上传文档进行模型训练。如果供应商的回答是"我们匿名化处理后再训练"——追问他们"匿名化"的具体技术方案和是否经独立第三方验证。对于API调用模式（供应商底层调用OpenAI、Claude等大模型API），还需要确认底层模型提供商是否使用API输入进行训练——例如OpenAI的API政策中声明API数据不用于训练，但需要确认供应商是否使用了不提供此承诺的模型。

5. 数据隔离

核心问题：不同客户的数据是如何隔离的？是多租户共享存储，还是每个客户独立的存储空间？

为什么重要：文档AI工具处理的数据通常包含竞争敏感信息——客户名单、采购价格、合同条款。多租户共享环境中的逻辑隔离如果有任何配置错误，就可能导致跨租户数据泄露。

判断标准：对于SaaS模式的文档AI工具，逻辑隔离是可接受的基线（通过数据库层面的租户ID区分），但需要确认隔离机制经第三方渗透测试验证。对于金融、医疗、政府等高合规要求行业，应要求单租户部署或VPC私有部署（见第12项）。追问：是否有历史数据被发送到错误租户的情况？最近的渗透测试结果是什么时候的？

6. 访问控制

核心问题：企业内部使用该工具的人员如何管理和分级？支持哪些身份验证方式？

为什么重要：如果全公司共用一个账号和处理队列——财务上传发票、HR上传工资单、法务上传合同全部混在一起——任何一个人都能看到所有部门的敏感文件。等保2.0（GB/T 22239-2019）明确要求"三员分立"（系统管理员、审计管理员、安全管理员分权）。

判断标准：至少支持角色权限分级（管理员、操作员、只读查看者）；支持SSO/SAML企业单点登录；支持双因素认证（TOTP或硬件Key）。加分项：支持IP白名单限制（仅允许公司内网IP访问）、支持API访问权限独立管理、支持按部门/项目隔离文件可见性。如果工具只提供"用户名+密码"一种登录方式，在高合规要求场景中是不够的。

7. 审计日志

核心问题：是否能完整记录"谁在什么时间上传了什么文件、执行了什么操作、导出了什么结果"？日志能否导出？

为什么重要：审计日志是合规的生命线。当发生数据泄露事件时，没有审计日志意味着你无法确定：泄露范围多大、从谁开始、有多少文件可能被波及。《个人信息保护法》第54条要求个人信息处理者定期进行合规审计——没有日志，审计无从做起。

判断标准：审计日志至少覆盖：用户登录/登出、文件上传（文件名/大小/时间）、处理任务创建/完成、结果导出（格式/条数/时间）、权限修改、账户配置变更。日志应支持按时间范围和用户筛选，且支持导出（CSV或JSON格式）。重点确认：日志保留多久？供应商的管理员是否拥有查看客户日志的权限？（应该有，但需有操作日志记录该管理员自己的行为）日志是否不可篡改？

8. 合规认证

核心问题：供应商通过了哪些第三方安全认证？认证的覆盖范围是什么？

为什么重要：第三方认证是供应商安全管理体系最可信的客观证据——比供应商自己怎么说更可靠。在中国市场，等保2.0（网络安全等级保护）是基础要求；面向海外业务的企业还需要关注ISO 27001和SOC 2。

判断标准：

• 等保2.0：供应商的云基础设施是否通过等保2.0三级或以上测评？——这是国内云服务的行业基线。三级要求231项安全控制项，覆盖物理安全、网络安全、主机安全、应用安全、数据安全和管理安全。
• ISO 27001：信息安全管理体系国际标准，适合有跨国业务的企业。注意确认证书的"覆盖范围"是否包含文档处理服务本身，而非仅限于供应商的公司管理后台。
• SOC 2 Type II：美国注册会计师协会的审计框架，报告涵盖一段持续期（通常6-12个月）内的控制有效性。Type II（持续运行测试）比Type I（某一时点的设计评价）更有意义。

底线：要求供应商提供认证证书的最新版本和覆盖范围说明。只拿了"咨询证明"没有正式认证的，不算。

9. 数据处理协议（DPA）

核心问题：供应商是否愿意与你签署数据处理协议（Data Processing Agreement）？

为什么重要：DPA是法律层面最重要的保护文件。它定义了供应商作为"数据处理者"的责任边界、数据处理的目的和范围、数据安全措施、数据泄露通知时限、以及合同终止后的数据处理方式。没有DPA，PIPL第21条要求的委托处理关系就缺少合同基础的约束。

判断标准：供应商必须能够签署DPA——这是不可妥协项。审查DPA时重点关注：是否明确写入了数据处理目的限制（禁止将数据用于合同约定之外的用途）、子处理者清单和批准机制（见第13项）、数据泄露通知时限（见第14项）、合同终止后数据删除的具体方式和时限。如果供应商只提供"我们重视你的数据安全"的口头承诺而无DPA，直接排除。关于PIPL合规与DPA的深度关系，参见我们的PIPL文档AI合规详解。

10. 数据删除

核心问题：用户能否主动删除已上传的文件和处理结果？删除是逻辑删除还是物理删除？备份中的数据是否同步删除？

为什么重要：PIPL第47条规定了用户请求删除个人信息的权利。对企业而言，原始文件（尤其是合同、工资单）不应在完成处理任务后仍保留在供应商系统中。

判断标准：确认三个层面：(1) 主动删除——用户界面是否提供"删除文件/结果"按钮，且操作即时生效？(2) 定期自动清理——供应商是否有策略定期清理（而非永久保留）已处理文件？(3) 删除的彻底性——删除操作是否覆盖生产环境、备份和灾难恢复副本？备份中的延迟删除（30-90天）是可以接受的，但需要有时间上限。底线：界面中没有"删除"按钮或者删除后数据仍可通过URL直接访问的，直接排除。

11. PIPL合规

核心问题：如果上传的文档中包含个人信息（如工资单上的身份证号、发票上的个人姓名和电话），供应商作为个人信息处理受托方，是否履行了PIPL要求的义务？

为什么重要：文档AI处理的很多文件天然包含个人信息——发票上的购买人信息、合同上的签字人信息、医院报告上的患者姓名。如果用户是个人信息处理者（企业），供应商构成PIPL第21条下的"受托处理者"。供应商的合规状态直接影响用户的合规状态。

判断标准：要求供应商明确：(1) 是否建立了个人信息保护管理制度和操作规程（PIPL第51条）；(2) 是否指定了个人信息保护负责人并公开其联系方式（第52条）；(3) 是否提供个人信息保护影响评估（第55条——如果处理敏感个人信息的情况下）；(4) 用户行使查阅、更正、删除等权利的响应机制（第45-47条）。如果供应商说"我们是工具、数据在用户手里我们没碰"——让他解释清楚数据是否经过他的服务器、是否在内存中被读取，如果答案是有，那他就在"处理"个人信息。关于PIPL的详细分析，参见PIPL合规完整指南。

12. 供应商安全架构

核心问题：供应商的文档处理服务运行在什么基础设施上？是公共SaaS、私有云，还是可以部署到客户自己的VPC中？

为什么重要：部署方式直接决定了你能控制多少安全边界。公有SaaS模型下，整个基础设施在供应商控制中——你只能依赖合同和认证来确保安全。VPC/私有部署模型下，数据完全在你的网络边界内处理。

判断标准：

• 公有云SaaS：是大多数文档AI工具的默认模式，适合中小企业。确认使用的云服务商（阿里云、腾讯云、AWS？）和可用区。在国内，等保2.0三级对SaaS已有较完善的要求框架。
• 私有云 / 单租户部署：供应商在你的云账号内单独部署实例，数据与其他客户物理隔离。适合中等合规要求场景。
• VPC / 本地部署：供应商将软件部署到你的虚拟私有云或本地服务器，所有数据处理不出你的网络边界。适合金融、政务等高合规要求场景——此时数据完全在控制者手中，供应商实质上退化为软件许可方。

关键判断：如果你属于高合规要求行业（医疗、金融、政务），优先要求至少是单租户或VPC部署。如果是中小企业SaaS模式，至少确认供应商的云基础设施已通过等保2.0三级。

13. 子处理者管理

核心问题：供应商是否使用了第三方子处理者？具体是谁？用于什么目的？

为什么重要：这是文档AI工具的一个特殊问题，也是大多数采购者在评估时完全没有想到的。很多文档AI工具的本质是在OpenAI、Claude等大模型API之上的一层应用封装——你的文件实际上是先上传到供应商的服务器，然后被发送到OpenAI或Claude的API进行内容理解和提取。这就意味着：你不仅需要信任文档AI供应商，还需要信任它的底层模型提供商。

PIPL第21条第3款明确规定：受托人未经个人信息处理者同意，不得转委托他人处理个人信息。如果供应商将文件发送给底层大模型API而没有在DPA中披露——这本身就可能构成违规。

判断标准：要求供应商提供完整的子处理者清单，包括：(1) 底层AI模型提供商（如OpenAI、Anthropic、智谱AI、百度文心）；(2) 云基础设施提供商；(3) 其他可能接触数据的第三方（日志分析、监控、客服工具）。确认：(a) 每个子处理者的数据处理目的和范围；(b) 子处理者的安全认证状态；(c) 供应商是否有子处理者变更通知机制；(d) 底层模型提供商是否承诺不使用API输入进行模型训练（如OpenAI API政策的声明）。如果供应商拒绝提供子处理者清单或回答含糊，这是红色警报。关于子处理者的进一步讨论，也适用于电子发票归档场景——可参考电子发票归档合规指南。

14. 事件响应

核心问题：如果发生数据泄露，供应商的通知时限是多长？响应流程是什么？

为什么重要：PIPL第57条规定，发生个人信息泄露时，个人信息处理者应当立即采取补救措施，并通知履行个人信息保护职责的部门和个人。如果你依赖供应商处理文档，供应商的响应速度直接影响你的合规义务履行。

判断标准：要求供应商提供书面的事件响应计划（至少是摘要版），包含：(1) 发现数据泄露后的通知时限——可接受的上限是72小时，行业最佳实践是48小时以内；(2) 是否承诺配合你的调查和数据泄露报告义务；(3) 是否定期进行安全事件演练。底线：如果供应商无法提供事件响应计划或没有明确的泄露通知时限承诺——说明他们可能根本没有想过会出问题，或者在出问题后第一反应是掩盖而不是通知。

如何将这份清单纳入采购流程

这份清单不是让你看完就放下的——而是让你在采购的每个阶段都用上它。

阶段一：供应商初筛（用时1-2天）

把14项中的第1、4、8、13项作为初筛过滤条件。发送一份简短的邮件问卷给候选供应商，就这4个问题要求书面答复。原因：这4项最容易一票否决——数据存在哪里、训练数据政策、有无认证、子处理者是谁——如果其中任何一项的答案触及底线，这家供应商就不需要进入下一轮。

阶段二：安全问卷深度评估（用时3-5天）

对通过初筛的供应商，发送完整的14项安全评估问卷。要求不仅回答"是否支持"，还要求提供技术文档、认证证书、日志样例、DPA模板作为佐证。这阶段的目标是：收集足够多的客观证据，让法务和IT能独立评估每家供应商的安全能力——而非依赖供应商的营销话术。

阶段三：PoC验证（用时1-2周）

安全问卷的答案只是供应商的自我声明——PoC阶段需要验证3项内容：(1) 审计日志的真实性——实际操作一轮上传→处理→导出，检查日志是否如实记录每一个操作；(2) 删除功能的实际效果——删除一个文件后，尝试通过分享链接或API再次访问，确认删除是否真正生效；(3) 传输加密——使用浏览器开发者工具的Network面板，确认所有API请求均通过HTTPS。

常见问题

Q: 小企业也需要关注所有这些维度吗？

不一定需要每项满分，但需要每项都过一遍——至少知道自己承担了什么风险。对于只有5-10人的小团队，优先级可以调整为：第4项（不用于模型训练）、第1项（数据存在哪里）、第10项（能删除数据）、第14项（事件响应）是必须确认的底线；第6项（访问控制）如果就1个人用那确实不紧迫；第12项（安全架构）VPC部署可能超出预算，SaaS模式也能接受。但底线是：小企业也需要问供应商这些问题——如果供应商连回答都不愿意，那比答"不支持"更危险。

Q: 供应商说"我们通过了ISO 27001认证"但拒绝提供证书副本——这种情况常见吗？

常见，但有疑点。ISO 27001证书通常是公开可查的，或者至少可以在NDA下提供。如果供应商声称通过了认证但不能提供任何证据，有几种可能：认证已过期、认证范围不包含你关心的服务、或者根本就没有认证。处理方式：要求提供发证机构和证书编号，自己通过发证机构的公开数据库查询验证。

Q: 我们用的是免费工具，还需要关心这些问题吗？

免费工具更需要关心。免费工具的商业模式通常意味着你的数据本身就是产品或间接贡献了价值——比如用于模型训练或产品改进。如果一个工具完全免费且没有明确的隐私政策说明数据使用方式，默认假设你的上传文件正在被用于训练。

Q: 如果供应商使用OpenAI API但OpenAI的政策说API数据不用于训练——这算安全的吗？

部分安全。OpenAI的API政策确实声明API输入不用于训练模型，但依赖这个声明有几个前提：(1) 供应商确实使用了OpenAI的API而非其他渠道；(2) 供应商没有在OpenAI之外额外保存或复制一份你的数据；(3) OpenAI的政策可能在未来变化。最佳做法是：要求供应商在DPA中明确写出"底层模型提供商不使用客户数据训练模型"的承诺——这样即使底层政策变化，供应商也有合同义务保护你的数据。

Q: 等保2.0对所有企业都适用吗？

等保2.0的法律依据是《网络安全法》第21条，适用于在中华人民共和国境内建设、运营、维护和使用的网络——理论上所有网络运营者都需要落实。实践中，第二级（含）以上的信息系统需要做等保测评。如果你的企业通过网络提供服务、处理用户数据、或者被行业监管要求过等保合规，就需要关注。对于采购文档AI工具的场景，你不需要自己做工具本身的等保——你需要确认供应商的云基础设施已通过相应级别的等保测评。