当AI系统产出一段幻觉合同条款、做出带有歧视性的招聘判断，或者员工偷偷用未批准的工具泄露了客户文件，欧洲中小企业的CTO、DPO们会突然发现，自己只有72小时去完成GDPR第33条的通知。而此刻，大多数公司的抽屉里根本没有一份AI事故响应程序——有的只是一套为传统数据泄露设计的应急模板，根本对不上现在的局面。

这不是过度担忧。一份被大模型“脑补”进商业合同的虚假条款，足以触发合同纠纷和监管问询。一个依赖AI筛选简历的公司，如果算法对某些群体产生系统性偏差，就可能面临数据主体的投诉和执法调查。更隐蔽的是“影子AI”：市场部同事注册了一个免费AI办公工具，上传了带个人信息的客户清单，而供应商的处理协议里完全没写清楚数据用途。这些场景都不是标准IT安全事件，但每一件都可能让你在72小时倒计时里手忙脚乱。

现在通行的应急逻辑是：既然我们有数据泄露响应流程，那AI事故来了也能用。但这两个东西根本不一样。数据泄露是一个边界清晰的事件——只要确认个人数据遭到未授权的访问、泄露或破坏，法律义务就紧接着启动。AI事故的范畴要宽得多，也更难预测。它可能是一次由第三方AI供应商训练数据处理不当引发的数据泄露，也可能是一个纯机器决策导致的歧视性结果，甚至可能是AI生成的错误信息进入了正式的客户交付件。而这些不同情形对应的通知义务、补救路径和时间窗口各不相同，硬塞进同一张检查表只会漏掉关键动作。

想扭转被动局面，第一步反倒是最不起眼的：在AI使用政策里写清楚，什么算一次AI事故。没有这条基准线，一线员工不知道什么时候该向上报告，管理层在事后审计时也拿不出一份连贯的事故记录。对大多数欧洲中小企业来说，一个可操作的定义可以这样写：当AI系统的输出、行为或参与，导致了对组织或利益相关者造成损害，或者产生了法律、监管、声誉风险的事件。这里的“损害”包括个人信息暴露、歧视性对待、实质性经济损失、业务中断；法律风险则涵盖通知义务、违约和针对数据主体的处理请求。一旦这个定义写进政策，升级门槛就不再靠个人直觉，而是有据可查。

有了定义之后，响应框架才有骨架。按事型分类比泛泛的检查表有效得多。在中小企业的实际运营里，常见AI事故可以压缩成五类，每一类都直接对应不同的监管压力：第一类是经由AI工具发生的数据泄露，即第三方工具在处理公司交给它的个人数据时出了纰漏；第二类是歧视性自动决策，比如招聘、授信或定价模型产生对某些群体的不公结果；第三类是AI幻觉导致的错误输出进入业务交付物，客户据此做了决策；第四类是员工未经审批使用AI工具，导致敏感文件外流；第五类是AI供应商自身发生安全事件，而模型的输出或API调用记录间接暴露了公司的数据。对每类场景事先划定责任人和应触发的外部沟通节点，72小时的压力就会从“到处找条文”变成“按步骤执行”。

这套框架不需要一支专职的AI法务团队。手册为CEO、CTO、DPO和运营负责人量身设定角色，从发现事故到证据保全，再到决定是否通知监管机构和受影响的数据主体，每个环节都拆成几个人可以完成的操作。关键在于把“AI事故”和现有的IT事件管理流程并列，而不是让前者被后者淹没。事故结束后再补一个简单的复盘环节，把本次触发的原因、响应耗时和遗漏点记录下来，既是为下一次应对提速，也是在为监管审计预留可追溯的因果链。