三个职能，三种时钟

每当我们考虑进入一个新市场，总会出现一场无法干净收尾的讨论。

产品部门问这个市场值不值得进入。法务部门问我们要承担什么责任。工程部门问需要建什么。三个答案单独看都成立，放在一起却都不完整。产品可能想要一个法务尚未界定范围的市场。法务可能描述一项工程需要一年才能满足的义务。工程可能为一个始终没有到来的监管体系做了准备。

通常的解决方式是让其中一个视角主导。地面稳定时这样可行。眼下并不稳定。

欧盟通过的简化方案于 2026 年 7 月 27 日生效，将《人工智能法案》附件三的高风险义务从 2026 年 8 月 2 日推迟至 2027 年 12 月 2 日，附件一中嵌入产品的系统推迟至 2028 年 8 月 2 日。这是成本最高的一层：风险管理体系、合格评定、CE 标识、质量管理体系、注册、上市后监测。官方给出的理由是欧洲标准化机构尚未完成协调标准。你无法依据一份尚未发布的标准取得认证。

与此同时，第 50 条已于 2026 年 8 月 2 日起可强制执行，并未推迟。它适用于任何直接与人交互的系统，不论风险等级，要求让对方知道自己面对的是 AI，生成内容必须加标识。上限为 1500 万欧元或全球年营业额的 3%。

加拿大走了相反的方向。AIDA 随 C-27 法案在 2025 年 1 月议会休会时失效，此后没有重新提出。主管部长表示它不会以原有文本回归，未来框架应当保持轻量。目前联邦层面推进的是隐私与数字安全立法，而非综合性的 AI 法律。加拿大没有生效的 AI 法。

这并不意味着无需遵守任何规定。魁北克第 25 号法自 2024 年 9 月起全面生效，罚则最高可达 2500 万加元，其自动化决策条款与欧洲的规定十分接近：告知当事人、解释逻辑与判断标准、允许其提出意见、在其要求时提供人工复核。在加拿大，具有约束力的义务来自省级隐私法，而这些规定更接近欧洲模式，而不是它们之上的联邦立场。

"我们合规吗"是有保质期的

把两者放在一起看，有用的启示与哪一个法域都无关。

一家为 2026 年 8 月构建了完整高风险体系的机构，比标准发布的时间提早了十六个月投入。一家什么都没做的机构，则错过了那项已经可强制执行、并附带实际罚则的透明度义务。两者都不是尽职方面的失误，而是同一个错误：把一个移动中的要求当成固定要求，过早地朝错误方向作出承诺。

所以"我们合规吗"并不是一个答案能长期成立的问题。它的有效期以月计。

真正持久的问题

在这种变动中仍然成立的，是一个交付层面的问题：

当下一次实质性变化到来时，我们是否有能力承接，还是退出那个市场？

两个答案都是正当的。判断一个市场不值得为其付出维护成本，是一项真实的战略选择，主动作出要好过在投标进行到一半时才发现。不正当的，是因为多年前一个与监管毫无关系的决定，而发现自己无法承接某项变化。

回答这个问题不需要预测立法，而是要知道规则变化时负担会落在哪里，并让那些具体的位置保持松动。

负担会落在哪里

对于运营系统内部的 AI 功能，我们关注一份很短的清单。其中每一项都是规则一旦变化就会加压的位置。

模型提供方。 如果提供方的名称出现在单一配置文件以外的任何地方，更换就意味着改代码。我们这里是管理员选择的一项设置，存放在数据库中，管线的其他部分不预设任何提供方。

数据存放在哪里，以及由哪一部法律管辖。 这是两个不同的问题。每位客户拥有独立实例和独立数据库，部署在客户选择的司法辖区，使这两个问题可以分别回答。

流程中是否有人。 助手提出建议，由人决定采纳或放弃，它不会自行写入。我们查阅的各套监管体系几乎都要求人工监督，而这一点很难在一个按自主执行设计的系统上事后加装。

什么内容离开实例。 姓名、电子邮件和电话号码在请求发出前会被替换为确定性令牌，对照表保留在客户自己的数据库中。

事后能证明什么。 仅追加的审计日志记录谁在何时做了什么。我们读到的每一套体系都要求留痕。它们在留存期限和格式上有差异，而这些比"是否留痕"这个决定更容易调整。

告知义务。 这是目前在欧洲可强制执行的一项，也是成本最低的一项：每种支持语言中的一段文字，以及生成内容上的标识。我们并不在欧盟销售，因此第 50 条目前对我们没有约束力，我们的公共门户当前也没有 AI 告知。这项工作会在情况改变之前补上，而且坦白说，无论在哪里销售它都应当存在。

合规文档。 技术文件、模型卡、正式的影响评估。我们没有制作这些。这是刻意的决定而非疏漏，因为触发它们的是一次我们尚未进行的市场进入。关键在于，我们已经构建的任何部分都不会让日后制作这些文档变得更难。

不属于产品的那一半

上面那份清单属于架构，而架构是较容易的一半。组织层面的对应部分，往往才是团队被锁死得比自己以为更严重的地方。

是否有客户合同点名了某一家模型提供方？是否有已签署的数据处理协议锁定了某个国家，日后要退出还得重新谈判？如果监管机构要求提供文档，你是从系统记录中生成，还是需要立项并投入人力？谁在关注下一个"第 50 条"，又会通过什么渠道得知？当结论是某个市场不再值得投入时，这个决定归谁作出？

真正困难的部分在这里，而它不是技术问题。

那些证明你重视治理的产物，往往同时削弱你调整的能力。 认证有适用范围，合同承诺有期限，驻留保证指定了具体地点。它们在签署当天看起来都像是严谨，而每一项都在收窄你明年可以做的事。这种张力无法在法务职能内部或工程职能内部解决，只能在一场有人同时兼顾两端的对话中解决。

最后一个开关属于客户

我们销售的是运营软件。AI 是让其中一部分工作更省力的手段，而不是产品本身。

这带来一个设计上的结果，我们认为它与任何监管无关也依然成立：助手在新实例上默认关闭，直到管理员将其开启。这个开关握在客户手里，而不是我们手里。如果客户自身的义务发生变化、议会作出表态，或者只是不希望使用，都无需我们发布版本，也无需向我们提出申请。

这些做法都算不上新奇。这个领域中的多数团队都在作类似的判断，也有不少团队在某些方面比我们走得更远。比较容易被跳过的，是把这些受压点明确说出来，并诚实说明哪些是自己刻意没有构建的。

"敏捷"在这里的含义

人们通常把敏捷当作团队安排工作方式的一种属性。在这样的环境里，它更接近两种速度的比较：地面移动的速度，与你能够响应的速度。

如果后者小于前者，能救你的就不是流程。而退出某个市场是这种比较的正当结果，不是失败的自白。真正的失败，是在没有意识到自己正在作出这个决定的情况下就已经作出了。

当规则的变化快过你的发布周期