即将到来的 AI 法规：向海外销售的泰国企业要准备什么

要点速览

在法律强制要求之前，海外客户就会开始发来问卷，询问您是怎样使用 AI 的。
需要做的是让系统从一开始就自动记录工作证据，用不着准备一大堆文件。
解读法律条文是法律顾问的工作；我们能帮上忙的，是让系统真正把证据保存下来。

1. 为什么泰国企业应该在客户开口之前就关注这件事

通常比法律来得更早的，是大客户发来的问卷：您在哪些环节用了 AI，客户数据传到了哪些地方，谁来检查 AI 给出的结果。一周之内答不上来的公司，往往在不知不觉中就丢了生意。

规则的适用范围可能取决于市场和影响，开发者所在地只是因素之一。欧洲的企业客户会在法规生效之前，就把问卷和合同条款层层传递给供应链上的企业。没有系统清单和相关文档的公司，即使产品质量好，也可能丢掉订单。

除了欧盟《人工智能法案》（EU AI Act），还有泰国《个人数据保护法》（PDPA）、消费者保护法、知识产权法以及相关的行业规定。每个应用场景（Use Case）都要单独分析，不能以“我们只是 API 的使用者”为由，就认为自己没有任何义务。

注意事项本文提供的是企业做准备的框架。法律和时间表都可能变化，作决定之前，应请法律顾问审查您实际的产品、市场、角色和合同。

2. 应该写进产品计划的时间表

好消息是，需要准备的大部分内容，本来就是企业该做的事，比如知道数据存放在哪里、谁能访问，以及系统判断出错时怎样纠正。

根据欧盟的官方信息，这套规则分阶段实施。大部分透明度要求和执法措施从 2026 年开始生效；附件三（Annex III）中部分高风险系统的要求定在 2027 年末；嵌入部分受监管产品的高风险 AI，则定在 2028 年。

企业不应等到截止日期才动手，因为数据治理（Data Governance）、质量管理、技术文档和监控都需要时间。销售周期长的产品尤其如此，客户可能会提前要求您证明已经准备就绪。

时间段	企业应该做的事
现在至 2026 年	系统清单、AI 素养、透明度和合同
2027 年	高风险分类、证据、质量管理体系（QMS）和供应商准备情况
2028 年	按适用范围落实产品合规、监控和审计

3. 先弄清公司是提供者（Provider）、部署者（Deployer）还是中间方

义务因角色而异。以自己的名义开发系统的公司可能属于提供者；在业务流程中使用系统的属于部署者；进口商和分销商可能还有各自特定的义务。如果对系统做了重大修改，或改变了它的预期用途（Intended Purpose），角色也可能随之改变，所以要为整条供应链画一张合同关系图（Contract Map）。

建立应用场景清单（Use-case Inventory），写明用途、受影响的人、决策流程、数据、模型、市场和人工监督（Human Oversight）措施，然后交给法务团队分类。不要只凭技术名称判断风险。同一套系统用在营销上，和用来筛选员工，风险可能完全不同。

4. 无论划入哪个风险等级都该准备的证据

经过批准的用途和限制条件
数据来源、使用权限、数据质量和保存期限
模型及版本、供应商和变更记录
按人群和高风险情形分别做的评测
人工监督机制，以及叫停或修正的权限
日志、事故、投诉和纠正措施
面向用户的说明，以及视情况披露 AI 生成的内容

写给开发团队 · 技术细节

采用文档即代码（Documentation as Code）的做法，把证据和每次发布关联起来，不要每年补写一次文档。模型、知识库或预期用途每变更一次，都要评估影响并留下决策记录（Decision Record）。

5. 供应商合同要写明提供证据，只约定服务水平协议（SLA）的可用性还不够

写给开发团队 · 技术细节

向供应商了解训练与数据政策（Training/Data Policy）、安全措施、模型变更、评测、次级处理方（Subprocessor）、数据存放地点、事故通知（Incident Notification）以及退出和数据删除（Exit/Deletion）安排。在合同中约定，公司有权获取履行自身义务所需的文件。如果供应商不提供这些信息，公司可能无法证明自己的产品合规。

写给开发团队 · 技术细节

按影响程度给供应商分级（Supplier Tier）。用于内部起草的模型和嵌入高风险产品的模型，需要的尽职调查（Due Diligence）深度不同。还要准备模型替换计划（Model Replacement Plan），以防供应商改变条款或达不到要求。

6. 透明度要落实在用户体验（UX）和流程里

根据具体场景，在用户和 AI 交互时告知对方，说明 AI 能处理的范围和联系真人的渠道。对影响较大的决定，要展示所用的数据，并在适用时告知用户有权提出异议或要求复核。不要把免责声明藏在冗长的条款里。

合成内容应按风险高低附上来源信息（Provenance）并经过审批。标签和元数据要能在下游渠道中保留下来。培训员工，避免过度依赖 AI，并准备好话术，坦诚地向客户解释。

合规本身就是卖点企业客户买的是放心。如果公司能说清楚哪个 AI 智能体（AI Agent）用了什么数据、谁来负责、出了事故怎么处理，安全和法务审查就能更快通过，也能和只拿得出演示的竞争对手拉开差距。

7. 建立不会变成瓶颈的合规计划

写给开发团队 · 技术细节

采用按风险分级的工作流（Risk-tier Workflow）：低风险自评，中风险由数据和安全团队审查，高风险做跨部门评估。准备模板、已批准的设计模式（Approved Pattern）和沙箱，让团队在护栏（Guardrail）之内快速推进。法务应该从设计阶段就参与，不要等到上线前最后一天才介入。

写给开发团队 · 技术细节

设立规模适中的 AI 治理委员会（AI Governance Committee），重点处理政策和例外情况，不逐条审批提示词（Prompt）。维护 AI 登记册（AI Register），写明负责人和复审日期，并用仪表盘跟踪事故和证据。实际执行情况通过抽查来核实。

8. 不必等法律每一行都明确，今天就能做的事

为所有 AI 系统及其涉及的市场建立登记册
明确负责人、预期用途和初步风险等级
建立数据和模型的血缘（Lineage）记录及版本记录
确定人工监督、事故处理和投诉处理机制
在采购合同和供应商合同中加入 AI 条款
请法务审查重要应用场景和市场拓展路线图

总结：向海外销售的泰国企业，应该在客户或法规强制要求之前，就把证据和治理体系准备好。系统清单、风险分类、数据血缘、评测和人工监督，无论法律怎样调整，都是有用的基础。目标是让系统可以解释、可以控制、可以纠正，只为通过检查清单而做的文件帮不了多少忙。

官方参考资料European Commission: EU AI Act implementation timeline
European Commission: Navigating the AI Act

DNA MAKER · SOLUTION BLUEPRINT

从第一天起，就留下能回答客户和审核方的工作证据

解读法律要求，是您的法律顾问和合规团队的职责，软件公司不该越俎代庖。DNA Maker 能做的，是把您的团队已经梳理好的要求，转化为系统自动完成的事情，比如记录每次决策用了哪组数据，保存当时使用的模型版本和规则，征求用户同意并留存记录，以及让用户知道自己正在和自动化系统对话。这些应该是日常工作顺带产生的结果，不该变成事后到处追着补的额外工作。

系统应该自动替您保存的内容

我们设计的系统，通常有一个独立于核心逻辑的记录层，这样更换模型或服务商时，证据也不会中断。系统还提供仪表盘，合规团队可以自己导出报告，不用等开发团队；另有一套测试集，每次改动后都能重新运行，证明质量没有下滑。如果海外客户已经开始发来关于 AI 使用情况的问卷，而您要逐个询问好几个团队才答得上来，这正是系统能真正帮上忙的地方。

SOFTWARE ENGINEERING GLOSSARY

软件工程术语表

这组术语可以帮助您和开发团队讨论证据和事后追溯。

术语	是什么	通俗示例	高管应问开发团队的问题
Traceability	能够追溯某个结果来自哪些数据和规则	能查到拒绝这个申请时用的是哪个版本的标准	我们能追溯到多细的程度？记录保存多久？
Versioning	保存模型、规则或文档的各个版本，以便知道某一时刻用的是什么	记录上个月系统用的是第 3 版规则	如果要解释三个月前的某个结果，我们手上的信息够吗？
Consent	在收集或使用数据之前，征求并记录用户的同意	记录客户在什么时候同意保存对话记录	事后我们怎样证明用户确实同意过？
PII	能识别出具体个人的信息，需要特别保护	客户的姓名、电话号码和证件号码	个人数据传到了哪些外部系统？
Model Card	说明模型用途、局限以及评估方式的总结文档	概括适用范围，以及不应使用的情形	我们正在用的系统，有没有这样的文档？