企业官网建设流程全解析

1. 为什么这次谈“岗位”，而不是继续谈框架

1.1 框架不落到岗位，就是纸面治理

读《人工智能安全治理框架3.0》的时候，我脑子里冒出的第一个问题不是“这个定义对不对”，而是“这段要求在企业里由谁来执行、怎么证明他执行了”。这两年AI治理最典型的困境，不是缺少制度文本，而是制度文本越写越厚，落到岗位上的动作越来越少。

我见过不少团队，花了两三个月把框架里的要求复制粘贴成一套内部制度，也安排了全员线上学习，可一旦真问起来：“咱们的AI资产有多少项？每一项当前责任人在哪个部门？如果模型出了安全事件，第一处置人是谁？”会议室里经常是一片沉默。这种状态我一般叫“纸面治理”：文件是齐全的，动作是没有的。

3.0相比前面版本，给我的整体感觉是更强调“按岗位落实”。它把AI系统的全生命周期切成了可管理、可验证的模块；每个模块下的要求，本质上都可以翻译成某个岗位的日常动作。既然这样，解读它的正确方式就不是再写一篇“概括全文”的笔记，而是回答一个具体问题：怎么在90天内，把这些要求铺到岗位上。

这篇文章就是围绕这个目标展开的。适合谁看，我再说直白一点：如果你要牵头企业内部AI安全自查、要给AI产品做上线风险评估、要建一套可持续运行的AI治理机制，或者只是被领导安排负责“对接AI安全治理”，那这篇文章解决的就是你接下来三个月里最常遇到的问题。

1.2 90天不是拍脑袋，三个30天各管一件事

把框架落地周期定成90天，经历过的人应该能理解。时间太短，连第一轮资产盘点都做不完；时间太长，项目热度一过，管理层的注意力和资源就散了。三个月刚好够走完一轮“现状盘点、岗位设计、试点运行、复盘修正”的闭环。

具体节奏我倾向于这样切：

这里有一个很多人会忽略的前提：三个阶段的顺序不能乱。有人一上来就喜欢先建一个“AI安全治理委员会”，再把各种职责往下分，结果连资产有哪些都不知道，分工表只能在空中楼阁上写。先把盘点做扎实，后续的动作才有对象。

写到这里，我想先强调一个我踩过坑的原则：岗位设计不是越多越好。大企业可以设独立岗位，中小企业完全可以把职责合并到现有岗位里。90天要交付的，不是一个全新的组织架构，而是一张“谁在什么时间、对什么资产、做什么动作、留下什么证据”的责任网络。

2. 第一个30天：先盘资产，再谈责任

2.1 一张AI资产总表，是所有岗位动作的前提

第一个30天，我把大部分时间花在资产盘点上是值得的。道理很简单：岗位职责是动词，AI资产是宾语。没有宾语，动词再好看也没意义。

盘点对象包括哪些？我一般按下面几类来扫：

• 数据集：训练用的、测试用的、外部采购的、业务系统自动沉淀的。
• 模型：大语言模型、传统机器学习模型、推荐模型、风控模型，甚至是嵌入在某个业务流程里的规则推理。
• 算法能力：对外提供的API接口、按需调用的推理服务、嵌入在客户端本地的模型。
• 应用场景：客服对话、内容审核、代码生成、简历筛选、审批辅助等。
• 支撑环境：训练平台、推理平台、模型仓库、数据标注平台。

每类资产盘完之后，都应该整理成表格，至少包含这些字段：资产编号、资产名称、所属业务线、当前负责人、数据敏感级别、使用方式、上线状态、关联的模型或数据。

实操中，不要追求一步到位。第一轮盘点只要做到“能让人按名称找到资产、知道谁负责”就算及格。评估报告、安全等级这些后续再补。我试过先追求完美，结果拖了一个月连台账都没建出来；后来改成“先有后优”，一周就能完成第一版。

2.2 把框架控制项翻译成“动作+岗位”

资产盘点完成之后，紧接着要做一件最花力气的事：把《人工智能安全治理框架3.0》里的要求逐条拆成可执行的动词。

我搭建控制项映射表时用的列是这样：

给大家举个具体的例子。框架里有类似“AI系统上线前应进行安全性评估”的要求，翻译到岗位上就是“模型上线审批流程要包含评估环节”，对应动作是“上线申请—模型评估—风险确认—批准发布”。如果企业现在的上线流程里只有功能测试，没有安全性评估，这条就标记为“差距项”，后面第二阶段就要补上。

再比如“对训练数据来源和授权进行管理”，翻译出来就是“数据采集前要登记来源、明确授权范围”，对应岗位动作是“数据入库时校验来源字段、定期抽查授权文件”。这类动作完全可以落到数据管理岗位的月度任务里。

这个环节最容易犯的错，是试图让“框架要求原文”直接当操作手册用。框架原文再细，也是面向整个行业写的，不是面向你企业里的某一个具体角色写的。必须先把要求重新写一遍，用“谁、做什么、多久做一次、做完怎么证明”的句式表达，后续才能落地。

2.3 输出差距清单，顺便把三层治理架构理顺

盘点结束后，要产出两张东西：一张是AI资产总表，一张是控制项差距清单。差距清单里每一项都要标注“现状是什么、目标是什么、差在哪、需要哪个部门参与”。

同时，我会顺手把企业治理架构的层级理一遍，因为后面设岗位时，必须知道岗位挂在哪一层：

• 决策层：负责AI治理的整体方向、资源投入、重大风险决策。
• 管理层：负责组织资产盘点、风险评估、流程建设、考核推进。
• 执行层：负责具体模型评估、数据合规校验、安全监控、应急响应。

很多企业的问题不是没有层级，而是层级之间没有接口。决策层定了方向，管理层不知道怎么拆成任务，执行层做了动作，结果又传不回决策层。90天落地时，在每个层级指定一个“接口人”比岗位名称本身更重要。

3. 第二个30天：把职责写到人，把动作写进流程

3.1 五类关键岗位，按风险高低决定是否独立设置

第二阶段的核心，是把第一阶段的差距清单变成岗位动作。我不建议每个企业都照搬同一套组织架构，但有几类岗位或职能，是大多数场景里都需要的。

第一类是AI治理牵头岗。这个角色不一定要全职，但必须有明确的牵头人。主要职责是统筹资产清单更新、组织风险评估、跟踪问题整改。

第二类是模型安全评估岗。负责模型上线前的安全评估、性能测试和对抗性测试结果分析。技术含量最高，通常由算法工程团队或安全团队的人兼任。

第三类是数据合规管理岗。负责数据来源登记、授权文件审核、数据分类分级、对外提供数据时的合规校验。在数据治理成熟的企业里，这个职能可能已经存在，做好接口对接即可。

第四类是AI应用安全运营岗。负责运行时的监控告警、异常输入输出检测、事件响应。适合挂在现有的安全运营中心下面，不用另起炉灶。

第五类是算法审计岗。负责定期对模型行为进行审计，看是否存在偏差，是否和业务目标一致，决策链路是否可解释。

小团队怎么办？我见过人数精简的团队把五类职能压缩到两个人身上：一个偏技术，负责模型评估和算法审计；一个偏管理，负责数据合规、安全运营协调和治理牵头。压缩的前提是，每类职能对应的动作依然要有明确的交付物，不能因为一个人身兼多职就把动作吃掉。

3.2 岗位职责卡：让一个人10分钟内看懂自己该干什么

岗位职责写得太抽象，是第二阶段最常见的失败方式。我后来习惯用“一页纸岗位职责卡”来解决。

职责卡上要有这么几块：

• 岗位名称：既要写通用名，也要写企业内部叫法。
• 归口上级：这个岗位向谁汇报、和谁协作。
• 核心职责：不超过五条，每条都用“动词+对象+交付物”写。
• 关键指标：3个左右，能量化尽量量化。
• 动作频率：每日、每周、每月、按项目触发。
• 留痕方式：记录在哪张表、哪个工单、哪个系统日志里。
• 应急处置：遇到什么情况，第一通知谁，第二通知谁。

举个具体写法示例：

AI治理牵头岗，核心职责就三条：牵头建立和维护AI资产台账，每月更新一次；组织季度风险评估，输出风险清单和整改计划；向管理层汇报治理进展和重大事件。关键指标定义为“资产台账更新及时率、风险整改按期完成率、重大事件上报及时率”。

我去过一些企业参观，它们的岗位说明书写得很完整，但页数太多，一线员工根本不看。后来我发现，真正起作用的永远是那一页摘要。90天落地的过程里，岗位职责卡不是写给人存档的，是写给人执行时对照的。

3.3 用责任矩阵解决“都负责=都不负责”

岗位设完之后，部门之间的灰色地带就冒出来了。比如“训练数据出问题”这件事，数据合规管理岗说自己是管授权的，模型安全评估岗说自己是管模型质量的，最后谁都不负责数据内容本身。

这个问题我用责任矩阵解决。矩阵的行是动作，列是岗位，格子里填字母：R（Responsible，执行）、A（Accountable，最终责任人）、C（Consulted，咨询）、I（Informed，知会）。

举一个典型动作：一次AI模型上线申请。

矩阵做出来之后，最大的好处是讨论时间大幅减少。每个动作只要有且只有一个A，争议就很快收敛。矩阵也不用做得太细，覆盖框架控制项映射表里标记过的关键动作就行。

4. 配套机制：流程、工具与留痕一起改

4.1 三条核心流程必须重画

岗位动作需要流程承载。90天实施过程中，我会优先改三条流程。

第一条是模型上线审批流程。从“提交申请、数据合规检查、模型安全评估、风险说明、批准发布、上线后复查”串起来。每个环节必须有对应的岗位和审批节点。以前只做功能测试就上线的习惯，这个阶段必须改掉。

第二条是风险事件处置流程。当AI系统出现异常输出、数据泄露、用户投诉、业务中断等事件时，要有统一的“发现—定级—处置—复盘”流程。定级标准可以简单一点，先按影响面分高中低，再逐步细化。

第三条是定期评估流程。包括AI资产台账的定期更新、模型季度的安全评估、数据授权文件的定期核查、日志留存的完整性检查。这一条主要是为了证明工作“持续在跑”，而不是只在项目期跑。

流程改完之后，要配套做一次权限梳理。谁能发起上线申请，谁能审批，谁能查看日志，谁能导出数据，都要跟着岗位职责卡一起定。权限过于分散是很多企业后来出问题的根源。

4.2 工具选型：先有动作，再买工具

一提到落地，很多人第一反应是“上什么软件系统”。我在这个环节通常会把顺序反过来：先把岗位动作和流程确认好，再判断现有工具能不能支撑，最后才考虑采购或自建。

需要看的基础能力有这么几类：

• 资产台账管理：只要能维护一张共享表格，初期就可以满足。
• 流程审批：如果有现成的OA或工单系统，先把流程配上去。
• 日志与审计：模型调用记录、审批记录、操作记录都需要有地方留。
• 模型评估辅助：可能有专门的评估工具，也可能就是脚本加测试集。
• 监控告警：看现有监控平台能不能接到模型服务的日志和指标。

我建议不要一开始就追求大而全的AI安全平台。工具堆得越多，岗位动作的实际负担越重。像有些企业年中的AI治理平台，最后基本没有专人维护，反而是共享表格和定期邮件提醒最能坚持运行。先把简易机制跑起来，等有明确痛点后再迭代工具。

另外，留痕是工具配置里最容易漏的一块。申请单要存，审批意见要存，评估报告要存，模型版本要存，监控异常记录也要存。没有留痕，后面无论做内部审计还是做外部沟通，都会很被动。留痕的颗粒度不用太细，但至少要做到“一件事发生后，能找回当时是谁批准的、依据是什么、结果如何”。

4.3 职责卡、矩阵、流程三者合一

第二阶段结束前，我会把三类文档放在一起对照检查一遍：岗位职责卡说的是“谁做什么”，责任矩阵说的是“一项任务谁是主责谁是配合”，流程说的是“这件事从头到尾怎么流转”。三者如果对不上，说明设计还有问题。

实操时有一个自查技巧：随便抽一个框架控制项，沿着“控制项—岗位主责—流程环节—留痕位置”走一遍，看链路是否完整。走不通的地方就是要回头补的地方。我通常会在第55天左右做一次这样的全链路模拟，把大部分问题都提前暴露掉。

5. 第三个30天：试点运行、考核与复盘

5.1 试点场景怎么选

第三个30天，不追求把所有业务线拉进来，而是选一两个场景做透。选试点时我一般看两个条件：一是对AI依赖度高，出了事故业务影响明显；二是数据敏感度高，能覆盖框架里比较核心的合规要求。

比较合适的试点对象包括：智能客服、文档解析、代码辅助生成、简历筛选、风控决策。这些场景都同时涉及模型评估、数据合规、使用监控和事件响应，适合用来验证岗位职责是否清晰。

试点启动前，要先明确目标。我给试点设的三个硬指标通常是：模型上线前评估覆盖率100%，高风险事件响应时间不超过规定时长，每周监督性检查有完整记录。目标不用多，三条足够。

5.2 考核指标：能证明动作发生，比分数高更重要

岗位落地之后，怎么证明动作真的发生了？靠考核。但考核指标不能定得太复杂，否则大家会把精力花在凑指标上。

常见指标我按几类整理一下：

• 资产台账类：资产清单完整率、台账更新及时率。
• 评估质量类：上线前评估覆盖率、评估报告按期完成率、评估发现的风险整改完成率。
• 运行监控类：监控告警响应时长、高频异常的处理闭环率。
• 事件管理类：事件定级及时率、复盘报告按期完成率、改进措施落地率。
• 培训认证类：岗位人员培训完成率、关键岗位备份覆盖率。

指标定义得越简单越好。比如“上线前评估覆盖率 = 通过评估后上线的模型数 / 当期上线的模型总数”。只要分母分子明确，大家就知道怎么算。

我在考核上踩过一个坑：只看结果指标，比如“全年重大事故数”。这种指标平时根本推动不了动作，等数字变难看时已经太迟了。后来我改成看过程指标，比如“每月高风险事件响应记录是否完整”。过程指标能真实反映岗位有没有在跑。

5.3 复盘机制比考核本身更重要

试点期间一定会出问题。这段时间最重要的事情，是把问题收集回来，形成一个“问题—原因—整改—验证”的闭环。

复盘不要只开会，要有记录。每个问题要写清楚：发生在哪个环节、涉及哪个岗位、责任人是谁、整改动作是什么、什么时候完成。下一周再逐条验证整改是否生效。

90天结束时，我会输出一份“落地运行报告”，内容包括：资产盘点情况、岗位职责卡清单、责任矩阵、流程运行记录、试点考核结果、遗留问题清单。这份报告不只是给管理层看的，也是下一轮迭代的起点。

6. 常见问题与排查技巧实录

6.1 岗位设了，没人认领怎么办

这种情况出现的原因，通常是岗位职责卡写得太模糊。比如“负责AI系统安全”，谁都能说一句“我在负责”，但谁都说不清自己做了哪些动作。

排查方法是把动作细化到可验证的当下：“你这个月做了几次模型安全评估，把评估报告调出来看一下。”一旦考核落到明确的交付物上，岗位是否有人认领会马上暴露。如果确实无人可用，就先把职能合并到现有岗位，再考虑招人或用外部技术支持。

6.2 业务部门配合度低

业务部门最怕的是治理流程变成业务上线路上的绊脚石。如果每次上模型都要多填三张表，别人当然不想配合。

我通常的做法是和业务部门谈一版“最短流程”：只保留“申请、评估、审批、记录”四个关键动作，评估材料尽量复用已有的测试结果，而不是另起炉灶。让业务部门感觉到，这堆流程是在帮他们规避事故，而不是在给他们制造麻烦。

6.3 文档和实际操作两层皮

最典型的场景是：制度文件写了“所有AI系统上线前必须经过模型安全评估”，实际操作里业务部门直接用高权限账号绕过流程，把模型接进了生产环境。这种问题靠补文档解决不了，只能靠权限收口和定期抽查。

我在第二阶段就会把权限收口和抽查机制设计进去。抽查不需要每次都全量检查，随机抽一到两个模型，要求现场调出链路上的审批记录和评估报告。查一次，大家就会把流程当回事。

6.4 小团队没有专职岗位，怎么兼顾

一个人身兼多个岗位职能时，最大的风险是“样样都沾、样样不深”。我的建议是做一个“职能覆盖表”，把岗位职责卡中的每项动作，按负责人填进表里，定期看一眼有没有长期被漏掉的动作。

如果发现某个动作连续两个周期没人做，就要考虑是不是该消减动作，或者把这个动作外包出去。宁可少做几项，也不能让写在纸上的东西长期空转。

7. 最后分享几个落地细节

第一，90天过程中，固定一个“周五复盘”的节奏，雷打不动。每周用半小时过一遍：这周哪些动作发生了、哪些没发生、为什么没发生。不要等项目结束才看数据，那时候已经来不及调整。

第二，岗位职责卡的末端要写上“备份人”。任何一个关键岗位休假或者离职，备份人能立刻顶上，否则整个治理机制就会有空洞。备份人不一定要做全套工作，但至少要知道动作清单和关键入口在哪。

第三，所有文档尽量用表格而不是长篇文字。资产台账、差距清单、责任矩阵、问题跟踪表，都是表格最好用。表格是给执行的人看的，文字是给别人汇报用的，真正跑起来的时候，大家需要的是能快速检索的结构。

我个人试过很多种落地路径，到最后发现，AI安全治理说到底不是技术题，而是管理题。把框架3.0的要求翻译成“谁、什么时间、做什么、怎么做、怎么证明”，再把这条链路固化到岗位和流程里，90天足够让框架真正开始运转。后面要做的，就是每个季度把这套机制拿出来重新跑一遍，跑得越顺，治理就越不像负担。