企业官网建设流程全解析

欧盟 AI 法案正式进入实施阶段之后，很多工程师的第一反应是：这不关我的事，法务去研究就好了。

但实际做 AI 应用开发的人很快会发现，这件事没法只推给法务。因为法案里要求的“技术文档”“日志记录”“人工监督”“风险管理”，本质上都是工程交付物。换句话说，它不是在给你一张合规表格，而是在给 AI 系统的开发过程加一套工程约束。

我从做模型落地的视角看下来，最值得说的判断是：这是一次把“跑通模型”改成“可控制、可审计、可追溯系统”的工程升级。合规压力固然存在，但真正落地之后，团队拿到的不只是免责证明，还有一套更扎实的 AI 工程底座。

今天这篇不聊法条细节，从工程师能动手的角度，拆成六个环节来讲。

1. 别把欧盟 AI 法案读成法律文件，要读成系统需求

1.1 法案真正约束的是“AI 系统进入使用场景”这一步

很多团队对 AI 法案的认知还停留在“它限制大模型、限制生成内容”这个层面。但从工程交付的角度看，它管的其实不是某一个模型，而是“把 AI 用在一个具体任务里”的这套系统。

举个例子。你是开发了一个文本分类模型，还是一个用于筛选简历的 AI 系统？表面上看，工作量差不多，但在合规语境下，两者的差别非常大。前者可能只是内部辅助工具，后者如果被判定为高风险场景，就会触发一整套质量与文档义务。

这里的关键变化是：你的交付物不再只是“模型精度报告”，而是“系统如何被使用、边界是什么、出问题时谁来负责”的完整说明。

1.2 先建立一张风险分层地图

AI 法案的核心逻辑不是“所有 AI 都禁止”，而是“按风险等级分层监管”。工程团队需要做的第一步，是把公司现有的 AI 功能全部摊开，按法案的风险分类做一次映射。

大概可以这样理解：

这张表的价值，是让团队明确“力气该往哪里使”。不是每个 AI 功能都需要按最高标准去堆砌流程，那样成本太高，也不符合法案的分层思路。

1.3 工程师要做的不是解释条款，而是转化成需求

法务同事给你解释风险类别时，可能会说“这个场景可能涉及高风险”。但工程团队不能停留在“可能涉及”这个层面。

我建议每个涉及 AI 的产品都单独建立一份需求文档，把合规义务翻译成系统要求。比如：

• “需要技术文档” → 要产出模型卡、版本号、训练数据来源说明、评估报告。
• “需要日志记录” → 要设计请求日志、决策日志、人工审核日志。
• “需要人工监督” → 要设计回退机制、人工审核队列、超时策略。
• “需要准确性说明” → 要定评测集、指标口径、失败案例归档。

这一翻译过程，才是合规真正落地的开始。

2. 第一步不是调模型，是建立一份 AI 系统清册

2.1 先盘点：团队到底在跑多少个 AI 功能

很多公司实际在用的 AI 功能，比大家意识到的多得多。有正式立项的还好，更多是某个部门自己用 API 搭的辅助脚本、某个同事用开源模型做的内部工具、或者产品里试探性上线的“智能推荐”。

这些散落的 AI 功能，在合规审查时是最大的问题。因为你不知道它是否存在，它运行在什么数据上，它输出的结果会不会影响用户决策。

我建议第一步做一个全公司范围内的 AI 系统盘点。形式上可以是一张表，每一行代表一个 AI 功能。基础字段至少有：功能名称、负责人、使用的大模型或算法、部署环境、输入数据、输出结果、是否影响用户决策、当前日志情况。

这个动作没有技术难度，难的是把散落在各处的信息收齐。但它是之后所有工作的基础。

2.2 为每个系统建立“模型卡”或“系统卡”

模型卡这个概念在机器学习社区已经存在很久，核心思想是把模型的用途、训练数据、评估结果、已知局限写清楚。现在需要把这件事变成工程日常。

一份最小可用的系统卡大概长这样：

# AI 系统卡 - 系统名称：客服自动回复 v2 - 责任人：张三 - 部署日期：2025-11-01 - 基础模型：某个开源 7B 模型 + 企业微调 - 模型版本：v2.1.0 - 使用场景：客服工单自动生成初稿 - 不适用场景：情绪激动用户、投诉升级 - 数据来源：历史工单（已脱敏） - 评估准确率：验证集 0.86 - 已知局限：对口语化表达容易误解 - 人工监督：初稿需客服确认后发送 - 日志保留：90 天

这个卡片的作用不是给审计人员看的，而是给团队自己看的。当模型出问题、需要回滚、或者要回答“这个系统为什么这样设计”时，你有一份可以直接翻阅的记录。

2.3 版本管理要延展到模型和提示词

传统软件工程里，代码有 Git，发布有版本号。但 AI 系统的版本管理更复杂，因为“模型的权重”和“提示词”也属于系统的一部分。

实际开发中，同一个模型，不同提示词跑出来的效果差异很大。如果只记录代码版本，不记录提示词版本，出了问题根本没法复现。

工程上可以这样做：把提示词也纳入版本管理，并在请求日志中记录当时的提示词版本号。这样每次真实请求，都能对应到一个确定的模型和提示词组合，排查问题时就不是在猜。

3. 数据、评估与监控：高风险场景里最容易被审到的地方

3.1 数据治理先从“来源”和“流向”两张表开始

AI 系统里的数据，至少分成两条线：训练数据和运行数据。

训练数据决定了模型的行为。如果用的是开源模型，需要记录基础模型的训练数据说明；如果做了微调，还要把微调数据的来源、筛选规则、清洗流程写清楚。这里不要求你能验证别人的训练集，但至少要知道“当前这个模型是基于什么数据训练出来的”。

运行数据是用户输入和系统输出。很多团队在这个环节会犹豫，担心日志采集会带来隐私问题。这里的处理原则是：能少记就少记，能不记原始文本就不记原始文本。

常见做法是：

• 记录请求的唯一 ID。
• 记录模型版本号、调用时间、耗时。
• 记录输出的命中策略、风险分数，而不是完整输出文本。
• 如果确实需要记录完整输入输出，要做权限控制和保留期限制。

3.2 评估不只是上线前做一次，要固化到 CI/CD 里

我在很多团队里看到同一个现象：模型上线前做了详细评估，但上线之后，评估就停了。

这在合规语境下是不够的。因为系统上线后还要持续证明自己是“符合预期”的。如果没有持续评估，一旦系统行为发生变化，你既不能及时发现，也没有记录可以说明变化发生的时间点。

工程上能做的是，把评测脚本集成到 CI/CD 流水线里。每次有新模型版本、新提示词、新检索策略时，自动跑一遍回归测试。回归测试集要覆盖几个维度：

• 核心功能准确性。
• 边界输入的表现。
• 敏感场景下是否输出合理。
• 已知的历史失败案例是否被修复。

这个过程做得越早，后面的合规材料就越自然，因为所有证据都是日常工作自动产生的。

3.3 监控不是看延迟，而是看“偏离”

传统监控关注的是系统可用性，比如接口延迟、错误率、CPU 占用。AI 系统的监控还要增加一层：模型行为偏离。

行为偏离有很多种表现：

• 持续返回空结果。
• 回答长度突然变短。
• 同一类问题在不同时间的答案差异变大。
• 输出中出现了明显不该出现的内容。
• 用户反馈中的投诉占比上升。

这些信号不一定代表模型“坏了”，但它们是模型行为变化的开始。在合规视角下，团队需要有能力发现这些变化，并记录变化发生后采取了什么动作。

监控的落地不一定需要很重的平台。初期可以先用日志和定时脚本，把关键指标的曲线画出来。关键是有“基线”和“告警”，而不是什么都没有。

注意：监控要分成“系统层”和“行为层”两层。只看系统层，你只能知道服务还活着；只有加上行为层，你才知道系统是不是还在按预期工作。

4. 人工监督和透明义务：不是加一个按钮那么简单

4.1 人力介入不只是“人在流程里点一下确认”

很多系统号称有人工监督，实际做的是“系统输出结果，人工直接确认”。这在合规视角下可能不够。

人工监督的本质，是让系统在关键决策点上具备“可被人类纠正、拒绝或覆盖”的能力。也就是说，人工要能对系统的输出产生实际影响，而不仅仅是走一个形式。

工程实现上，至少要明确这几点：

• 哪些类型的输出必须人工确认。
• 人工不响应时，系统是默认通过还是默认拒绝。
• 人工的修改结果是否会被记录，并用于后续模型改进。
• 人工审核的职责、权限和操作留痕。

比如自动生成客服回信的场景，最简单的人工监督是：AI 先生成回信草稿，人工点击确认后才发送。这个流程比“全自动发送”多了一步，但能明显降低错误内容直接触达用户的风险。

4.2 透明度义务：用户有权知道自己在和 AI 打交道

法案对有限风险系统的要求主要是透明义务。用大白话说，就是用户应该知道“这是 AI 在和我交互”。

落到工程上，需要在产品交互层处理：

• 聊天机器人开场白，直接说明“我是 AI 助手”。
• AI 生成的内容，在界面里标注“AI 生成”。
• 合成的语音或视频，添加合适的标识。

这块在后端也有对应动作。比如 API 返回结构里加一个字段is_ai_generated或source: ai，方便前端展示标识。如果是音视频内容，可以在元数据里写入来源信息。

很多工程团队觉得这里没技术含量，容易忽略。但它是用户信任最直接的部分，而且实施成本低，早做早省心。

4.3 可解释性：不要求你解释每一个参数，但要能说出决策路径

大模型本身的决策过程很难逐参数解释。这一点法案的制定者也清楚，所以工程上更看重的是“记录决策路径”。

比如系统帮你生成了一段客服回复，它基于哪些背景信息？检索了哪些知识库？为什么拒绝回答某类问题？这些信息可以记录在日志或响应结构的扩展字段里。

如果用户或审计人员问“为什么这个回答是合理的”，团队至少能拿出当时的模型版本、输入上下文、检索来源和生成策略。这种记录不解决算法可解释性的根本问题，但能帮助团队回答“系统是在什么条件下做出这个输出的”。

5. 工程上如何落实一套可复用的合规检查表

5.1 把合规要求固化成代码和脚本，而不是纸面文档

合规意识最终要靠工具来承载。如果每次都是人工检查，既低效又容易漏。

比较好的做法是，把检查表变成自动化脚本。例如：

• 检查每个模型目录下是否有模型卡。
• 检查请求日志中是否包含版本号。
• 检查新发布的服务是否声明了风险等级。
• 检查高风险接口是否有超时和人工审核策略。

这些检查可以放在发布流程里，作为上线的前置门禁。不符合条件的，提交会被阻止，或者至少会被标记为风险项。

这个做法不是为了让流程变繁琐，而是让团队在交付时“顺手”把合规要求完成。相比事后补材料，效率高得多。

5.2 一个可复用的检查表，按项目阶段拆分

按照项目的生命周期，可以把检查表拆成几个阶段：

这个表格可以直接拿去做项目启动模板。不同团队可以根据实际情况增减条目，但核心漏斗不能丢：从设计到开发、从上线到运行，每个阶段都有可验证的产出物。

5.3 设计“退出机制”，确保系统可以被安全下架

AI 系统不是只能上线和优化，还必须有“下线”的能力。

什么时候需要下架或回滚？比如模型更新后效果严重下降，或者监管问询时发现某个系统存在重大隐患，或者数据来源被判定不合规。

工程上要提前准备这些机制：

• 模型版本可以一键切换回旧版本。
• 系统日志可以导出，便于审计查看。
• 对违规使用场景，要有终止服务的入口。

这个思路和传统软件的高可用设计是一脉相承的。只是在 AI 系统里，“系统异常”不只包含服务崩溃，还包含“模型行为不符合预期”。所以回滚机制要覆盖模型权重、提示词配置和检索策略这三个层面。

6. 适合谁、不适合谁：边界与优先级判断

6.1 哪些团队受影响的成本最高

从工程角度看，受 EU AI Act 影响最直观的，是那些把 AI 嵌到核心业务决策链路里的产品。

典型的高感知场景包括：

• 自动化客服，但系统能直接给出最终答复。
• 招聘筛选，AI 参与候选人排序。
• 信贷审批，AI 输出风险评估建议。
• 医疗健康建议，AI 根据症状给出参考。
• 教育系统里 AI 为学生评分或分级。

这些场景的共同特点是：AI 的输出会影响真实世界里某个人的机会或权益。所以法案对它们的要求也最严格，工程改造的投入也最大。

6.2 哪些系统可能不那么敏感，但也别完全无所谓

另一类系统，比如内部知识库问答、代码补全、文本摘要、内部数据分析辅助，它们通常是辅助工具，人类有最终决策权，不直接影响用户权益。这类系统在法案框架下的合规负担通常较轻，主要涉及透明度。

即使如此，我仍然建议团队保留基本的模型记录和日志能力。原因有二：一是很多内部工具慢慢会变成对外功能，之前的数据基础可以复用；二是如果审计时要对全公司 AI 系统做说明，“什么都不记得”比“没有完整文档”更麻烦。

6.3 一个务实的落地优先级

如果团队现阶段还没有任何合规动作，我建议按下面这个顺序推进：

1. 先盘点当前所有 AI 系统，列出一张总清单。
2. 对每个系统做粗略的风险分级，先标出“可能高风险”的系统。
3. 优先完善高风险系统的文档、日志、数据和人工监督。
4. 把透明度交互（AI 标注）做成所有对用户系统的默认能力。
5. 再把评估和监控逐步固化到 CI/CD 里。

不要一开始就追求全公司统一的高标准合规平台。先让高风险系统达标，再逐步提高整体阈值，比一次推倒重来更可控。

6.4 把握“能做”和“应做”之间的平衡

工程师在面对合规要求时，容易走两个极端：一个极端是我行我素，认为合规只是流程上的事，先上线再说；另一个极端是把所有能想到的合规措施都堆上去，结果一个小工具被改造成了重型系统。

这两种做法都不对。

更好的做法是，在项目开始时就把“合规成本”当作一个普通的需求项来评估。高风险场景，按高标准做；低风险场景，只做透明度。这样既不会漏掉关键义务，也不会过度消耗团队精力。

合规应该是一套适配系统风险的工程水位，而不是一刀切的最大化配置。

最后说一点真实感受

EU AI Act 真正进入实施阶段后，我最大的体感是：AI 系统终于开始被当作“正式系统”来对待了。

过去很长一段时间，AI 开发很像在做实验。模型跑出来效果不错，就放进产品里。集成、版本管理、监控、回滚这些传统软件工程的工具，在 AI 场景里经常被简化甚至忽略。最典型的场景是：模型代码在 Git 里有记录，但训练用的数据版本、微调参数、提示词内容全部不在版本管理里。出了线上问题，根本讲不清“现在线上跑的到底是什么版本”。

合规压力带来了一个副产品：团队被迫把基础工程能力补上。这其实是好事。

你不一定每一行都要按最严格的框架来做，但至少应该开始建立模型清册、记录数据来源、固化评估流程、设计人工监督机制、加装行为监控。这些能力放在任何规范化的 AI 工程团队里，都是基本功。

如果你所在的团队正在做 AI 产品，我建议今天先从第一件事开始：把公司所有 AI 功能列一张清册，标出每个系统用什么模型、处理什么数据、输出如何被使用。

这一步花不了多少时间，却能让你和团队在讨论合规时，不再只是在抽象层面争论“需不需要做”，而是能看着具体的东西说：这个系统已经有什么，还缺什么，下一步补什么。

AI 法案带来的不只是限制，它也在帮整个行业建立一个更可靠的 AI 交付基线。早点把这条基线内化成工程习惯，后面才不会手忙脚乱。