想象一栋入住两千户的智慧小区:有物业、有业委会、有住户,还有门禁AI、垃圾识别摄像头、外卖机器人。小区越来越智能,但纠纷也越来越多:为什么我的门禁数据被物业拿去推送广告?为什么机器人只在洋房区巡逻?如果只有物业说了算,业主不放心;如果事事都开业主大会,效率又太低。于是,业委会和物业联席会诞生了——它不替物业扫地,也不替住户搬家,只负责一件事:让大家在“智能化”这件事上有一个共同认可的议事规则。企业里的AI伦理委员会,就是这个数字小区的“议事堂”:它不写代码、不做模型,却决定了AI在什么范围内被信任、被使用、被叫停。这篇文章就带你走一遍,怎么在组织里搭起这个议事堂。

岗位关联

掌握AI伦理委员会的组织设计,是AI治理落地最关键的一环;无论你是合规负责人还是AI产品负责人,这门手艺都能让你把“负责任的AI”从口号变成可执行的制度。

目录
  1. 可视化演示
  2. 职责范围界定
  3. 人员构成搭配
  4. 决策流程设计
  5. 业务协同合作
  6. 独立权威保障
  7. 冲突处理机制
  8. 持续运行优化
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示企业AI伦理委员会的组织架构层级与伦理审查决策流程,支持模式切换查看治理体系全貌。

本节配有交互动效(进入视口后自动加载,约 3KB)。

四级治理架构体系 董事会:最高决策权,批准重大AI伦理政策 伦理委员会:跨部门审议,独立审查AI项目 合规团队:执行审查标准,对接法规要求 authority = board × independence × expertise 治理权威性由层级、独立性和专业度共同决定。

职责范围界定

小区议事堂如果什么鸡毛蒜皮都接,就会累死也无法服众。它的院子边界很清楚:只评议智能化公共设施带来的伦理风险,例如门禁数据是不是被滥用、送餐机器人是否让老人出行更困难。AI伦理委员会第一项工作,同样是画边界。不是“所有AI都管”,而是管“可能伤害人或社会的AI使用方式”。常见场景包括算法歧视、隐私泄露、自动化决策误伤、生成式内容失控。梳理出这些场景,才能知道委员会要评估什么。

怎么判断一个场景算不算风险?业界常用两把尺子:发生概率和伤害影响。概率低或影响小,风险就不高;概率高且影响大,就必须重点审议。用风险分数把场景排队,委员会就能把力气花在最需要花的地方。

到了这一步,委员会就可以把业务场景分成“低风险快速通道”“中风险专题评审”“高风险全体审议”三档,并写进章程。就像业委会只在暴雨前检查排水系统并把高风险点位列为重点巡检,其他小事交给物业,边界清楚,才有效率。

Ri=Pi×IiR_i = P_i \times I_i
某个AI场景的风险分,等于它发生问题的概率乘以问题发生后的严重程度,就像判断小区排水系统要不要重点改造,不能只看雨季来不来,还要看积水会不会淹了配电房。
  1. 识别场景变量为每一个AI应用场景建立一个编号 i,它是后续评估的基本单位。
    i=1,2,3,…,ni = 1, 2, 3, \dots, n
  2. 概率 P_i代表这个场景出问题的可能性。取值范围可以设计为 0 到 1,越接近 1 越容易发生。
    0≤Pi≤10 \le P_i \le 1
  3. 影响 I_i代表问题发生后的严重程度。可以采用 1 到 10 分,10 分表示可能造成严重人身伤害或大规模权益受损。
    1≤Ii≤101 \le I_i \le 10
  4. 相乘求风险分把概率和影响乘起来,得到综合风险分。分数越高,优先级越高,委员会投入的审议资源也越多。
    Ri=Pi×IiR_i = P_i \times I_i

人员构成搭配

业委会如果全是物业员工,业主一定不信;如果全是吵得最凶的业主,也不一定懂法律。AI伦理委员会同样需要六种角色:懂业务的、懂技术的、懂法务的、代表用户或公众的、外部独立专家、常设秘书。业务代表说清楚业务想要什么;技术专家判断算法能做到什么;法务确认合规底线;外部专家补上内部盲区;用户代表替受影响的人发声;秘书处负责会议、记录和材料流转。

人员构成还需要考虑能力覆盖度。委员会要避免“豪华但同质”。比如评审一个推荐算法,需要公平性、隐私、产品、法律四类能力;如果现有成员只覆盖两类,覆盖率就是 50%,这个缺口必须靠补充专家或临时外脑来堵上。

人齐之后,还要明确每个席位的到会率和投票权。委员会不是座谈会,而是有明确授权的治理机构;如果连法定人数都凑不齐,再好的配置也会沦为摆设。

C=KcoveredKrequiredC = \frac{K_{\text{covered}}}{K_{\text{required}}}
委员会的能力覆盖度,等于已有能力项除以岗位所需能力项。就像小区议事堂需要会看账、懂物业法、懂工程验收的人,如果没人懂工程,那屋顶维修方案就只能在云里雾里投票。
  1. 确定所需能力 K_required先分析委员会要处理的主要风险类型,列出一张“能力清单”,例如隐私保护、算法公平、产品体验、合同法务。
    KrequiredK_{\text{required}}
  2. 盘点已有能力 K_covered逐席检查现有成员真正具备哪些能力,有些能力可以来自外部顾问。
    KcoveredK_{\text{covered}}
  3. 计算覆盖率用已有能力除以所需能力,得到一个 0 到 1 之间的数值,低于 0.6 就要警惕能力空洞。
    C=KcoveredKrequiredC = \frac{K_{\text{covered}}}{K_{\text{required}}}

决策流程设计

小区里不能门口吵架就决定改造方案;AI伦理委员会也不能让嗓门最大的人说了算。一个完整的决策流程应该包括“申报通道—分级审议—记录留痕—结果反馈”。业务团队要通过统一通道提交AI项目材料,委员会根据风险等级决定是快速通道还是全体审议,每次会议必须留下记录,决议结果要回流给业务方。

具体到一次评审,委员会不能只看一句“风险可控”,而是要把项目拆成几个维度:公平性、隐私保护、透明度、用户影响。每个维度打分,再配上权重,加权求和得到综合分。权重代表企业真正在意什么;伦理事件多发的维度,权重就应该更高。

流程上还要给低风险项目快速通道,给高风险项目全体审议;每次会议必须有记录,裁决结果要反馈给业务团队,并允许对方在指定周期内提出异议。就像小区改造前要有公示、意见收集和投票流程,而不是谁在群里先发火谁赢。

S=∑j=1nwjxj,∑j=1nwj=1S = \sum_{j=1}^{n} w_j x_j, \quad \sum_{j=1}^{n} w_j = 1
综合评审分等于各维度分数乘以权重后的加总,所有权重加起来等于 1。就像小区改造评估中,“安全”权重要大于“美观”权重,否则花园再好看,也挡不住消防通道被堵。
  1. 设定评审维度 x_j把一个AI项目拆成公平性、隐私保护、透明度、用户影响等维度,每个维度单独打分。
    xjx_j
  2. 分配权重 w_j给每个维度设置 0 到 1 之间的权重,它代表这个维度在决策中的重要性。
    wjw_j
  3. 加权加总把每个维度的分数乘以权重后全部加总,得到一个综合分,分数越高代表整体越可接受。
    S=∑j=1nwjxjS = \sum_{j=1}^{n} w_j x_j
  4. 权重归一化所有维度权重之和必须等于 1,这样综合分才能在不同项目之间横向比较。
    ∑j=1nwj=1\sum_{j=1}^{n} w_j = 1

业务协同合作

委员会不能坐在会议室里等业务来敲门。如果业务团队觉得委员会是“审批门卫”,就会想尽办法绕过去;如果委员会是“一起画图纸的邻座专家”,配合度就会高很多。理想状态是:产品提出新功能时,委员会在需求设计阶段就介入,而不是等代码上线后再把项目打回重做。

衡量这种协同是否到位,可以看“早期介入率”。如果大部分应评审项目都在设计阶段邀请委员会参与,说明协作是前置的;如果都是上线后才补材料,那委员会基本形同虚设。

除了早期介入,委员会还要持续做三件事:给业务团队做伦理培训,把抽象原则翻译成产品检查清单;提供随时可用的咨询通道,让业务在拿不准时敢问;和业务一起把“能做、不能做、怎么做”写成规则,而不是单方面封杀。

ER=NearlyNtotalER = \frac{N_{\text{early}}}{N_{\text{total}}}
早期介入率等于“在设计阶段就邀请委员会参与的项目数”除以“所有应评审项目数”。就像小区议事堂不是等漏水了才去业主家登记,而是在新楼栋动工前就参与图纸审查。
  1. 统计应评审项目总数 N_total把周期内所有需要伦理评审的AI项目放进名单。
    NtotalN_{\text{total}}
  2. 统计早期介入项目数 N_early记录哪些项目在需求、方案或数据准备阶段就已经有委员会参与。
    NearlyN_{\text{early}}
  3. 计算介入率两个数相除,得到 0 到 1 的比率,越接近 1 说明委员会在业务中嵌入得越深。
    ER=NearlyNtotalER = \frac{N_{\text{early}}}{N_{\text{total}}}

独立权威保障

议事堂之所以有公信力,不只是因为开会认真,更是因为它不归物业公司管、有自己的经费来源,还能在关键时刻抗住压力。AI伦理委员会也是一样:独立预算、独立汇报线、成员免遭打击报复、最高管理层公开背书,这些都不是形式,而是权威性的实体支柱。

为了保证每次决议不是两三个人拍板,委员会需要设定出席人数的底线。这个底线不能太低,否则小圈子可以绑架全局;也不能高到永远开不成会。业界常见的做法是要求至少三分之二成员到场。

独立不代表不沟通,而是意味着委员的饭碗不能被业务KPI捏着。最理想的位置是:委员会主席直接向CEO或董事会下设的治理委员会汇报,委员的任免有明确章程保护,预算由公司治理项单列,即使某个高风险项目影响了短期业绩,委员会也有底气说“不”。

Mpresent≥23MtotalM_{\text{present}} \ge \frac{2}{3} M_{\text{total}}
实际到场并参与表决的人数必须大于等于全体成员的三分之二。就像业委会要表决动用维修基金,不能只有两三个人在场就说代表全小区,必须让足够多的人到场,结果才站得住。
  1. 明确全体成员数 M_total委员会一共设立多少个正式席位,以此作为分母。
    MtotalM_{\text{total}}
  2. 统计到场人数 M_present每次会议实际到场且有权表决的人数,作为分子。
    MpresentM_{\text{present}}
  3. 三分之二门槛要求到会比例至少达到三分之二,保证决策的代表性。
    23\frac{2}{3}
  4. 判断不等式只有满足“到场人数大于等于门槛人数”,本次会议才具备表决效力。
    Mpresent≥23MtotalM_{\text{present}} \ge \frac{2}{3} M_{\text{total}}

冲突处理机制

业务急着上线,委员会说要暂缓,这种冲突很常见。好的委员会不是把业务压死,而是提供一个有秩序的冲突解决路径:按章程优先级排序、设置上诉通道、透明裁定、必要时外部仲裁。如果冲突只能靠“谁职位高谁说了算”,那委员会就没有存在意义。

当安全目标和增长目标冲突时,可以把两类收益放到同一套计分规则里比较,但伦理安全的权重必须更高。这不是反对增长,而是给失控的增长装上减震器。

如果业务方认为委员会判错了,还可以走上诉通道,由更高级别的审核小组复核;复核过程和结果要尽量透明,避免私下推翻。遇到双方无法达成一致的重大争议,再邀请外部独立专家或第三方机构仲裁,让企业在“快”和“稳”之间有一个可信的裁判。

U=λsUs+λgUg,λs>λgU = \lambda_s U_s + \lambda_g U_g, \quad \lambda_s > \lambda_g
综合效用等于安全收益乘以安全权重,加上业务增长收益乘以增长权重,并且安全权重要大于增长权重。就像小区在暴雨天让外卖机器人暂停配送,不是为了把商家饿死,而是因为人身安全这条底线更重。
  1. 定义安全收益 U_s代表避免事故、保护用户权益、维护企业信任所带来的长期价值。
    UsU_s
  2. 定义业务增长收益 U_g代表收入、用户量、市场份额等短期增长指标。
    UgU_g
  3. 引入权重 λ_s 和 λ_g把一个项目和两种收益放在同一套单位下比较,权重反映企业价值观。
    λs,λg\lambda_s, \lambda_g
  4. 设置安全优先明确要求安全权重大于增长权重,让伦理底线在公式层面拥有优先地位。
    λs>λg\lambda_s > \lambda_g
  5. 计算综合效用加权求和得到 U,冲突各方用同一个公式对话,而不是用职位压人。
    U=λsUs+λgUgU = \lambda_s U_s + \lambda_g U_g

持续运行优化

议事堂不是立完规矩就能一劳永逸。AI技术变化快,去年定的规则今年可能不够用;委员会每年要做一次成熟度体检,看看章程质量、流程执行、组织文化是否还在同一水平线上。任何一个环节塌了,整个治理体系都会空转。

为了把“感觉”变成“指标”,可以给治理体系计算一个成熟度分数。章程再漂亮,执行跟不上,分数上不去;流程再规范,没有文化认同,大家也会绕着走;文化再热闹,没有制度和流程承接,最终只是一阵风。

最后的落点是文化营造。委员会真正成熟的标志,是它偶尔不开会也没关系,因为“负责任的AI”已经变成产品经理写需求时的条件反射、变成工程师注释里主动标注的风险、变成业务负责人拍板前下意识要问的那句话。

M=αC+βP+γL,α+β+γ=1M = \alpha C + \beta P + \gamma L, \quad \alpha + \beta + \gamma = 1
治理成熟度等于章程质量、流程执行、文化氛围三个子分数的加权和,且三个权重加起来等于 1。就像衡量小区治理好不好,不能只看墙上贴了多少公约,还要看公约是不是真被执行,以及住户是不是真的愿意遵守。
  1. 评估章程质量 C检查职责边界、人员构成、决策流程是否清晰,有没有随技术变化及时修订。
    CC
  2. 评估流程执行 P看申报通道是否有人用、留痕是否完整、决议是否被真正执行。
    PP
  3. 评估文化氛围 L看业务团队是否主动求助、管理层是否公开支持、员工是否敢讲伦理疑虑。
    LL
  4. 设置组合权重为三项打分赋予不同重要性,并让所有权重之和为 1。
    α+β+γ=1\alpha + \beta + \gamma = 1
  5. 计算成熟度加权求和得到总分数,作为年度体检和持续改进的基线。
    M=αC+βP+γLM = \alpha C + \beta P + \gamma L

AI 应用场景

智能客服上线前的伦理评审

阶段:AI系统上线前的伦理审查

解决的问题:电商平台的智能客服可能对老年人、方言用户态度冷漠,还会在促销活动中产生歧视性话术。传统做法是上线后看投诉,问题暴露才补救。委员会在需求设计阶段介入,把“用词温度”“拒答策略”“转人工条件”写进评估清单。

具体案例:某零售公司在部署客服机器人前,伦理委员会组织了业务、法务和用户代表进行评审。他们发现机器人对“退款失败”的文案过于生硬,于是要求在话术中增加解释原因和转人工入口,上线后投诉率明显下降。

金融风控模型的冲突仲裁

阶段:AI模型运行中的伦理冲突处理

解决的问题:银行风控模型为了提高坏账拦截率,把某些区域用户的授信额度压得极低。业务部门觉得误伤用户,委员会觉得需要更多数据证明。传统协调只看部门KPI,谁嗓门大谁赢;委员会用安全权重更高的公式来权衡。

具体案例:某消金机构在风控模型上线后收到大量申诉。伦理委员会启动冲突处理流程,先由初审小组复核,再要求业务方提交用户影响评估,最后裁定保留模型但增加人工复核通道,并开放二次申诉接口。

医疗AI数据集使用的流程协同

阶段:AI数据使用授权与跨部门协作

解决的问题:医院与科技公司合作开发肺结节筛查AI,需要脱敏影像数据。传统路径中,临床科室直接给数据,法务事后审核,导致隐私风险。委员会建立“数据使用申报通道”和分级审批,让需求方、数据方、法务在一个流程里协同。

具体案例:某医疗AI公司在申请影像数据时,委员会要求补充数据用途、保留期限、第三方共享范围;联合数据安全团队与法务评审后放行,并将审计日志按月备案。

Python 演示

python51 行
# -*- coding: utf-8 -*-import math  class EthicsCommittee:    def __init__(self, members, safety_weight=0.7):        self.members = members        self.safety_weight = safety_weight        self.review_count = 0     def risk_score(self, probability, impact):        return probability * impact     def decision_level(self, score):        if score < 3:            return "pass"        if score < 6:            return "review"        return "block"     def quorum_needed(self):        return math.ceil(len(self.members) * 2 / 3)     def is_quorum(self, present_count):        return present_count >= self.quorum_needed()     def review_case(self, case):        self.review_count += 1        score = self.risk_score(case["probability"], case["impact"])        level = self.decision_level(score)        quorum_ok = self.is_quorum(case["present_count"])        utility = self.safety_weight * score + (1 - self.safety_weight) * case["business_value"]        return {            "case_id": case["id"],            "risk_score": round(score, 2),            "level": level,            "quorum_ok": quorum_ok,            "utility": round(utility, 2)        }  if __name__ == "__main__":    committee = EthicsCommittee(["legal", "business", "tech", "external", "user"])    case = {        "id": "A001",        "probability": 0.6,        "impact": 8,        "business_value": 5,        "present_count": 4    }    print(committee.review_case(case))
目的:用一个小型伦理委员会类,模拟风险打分、分级决策、法定人数校验和冲突权衡,把正文中的治理公式变成可以直接跑起来的流程。
  1. score = self.risk_score(case["probability"], case["impact"])这是公式 R=P×I 的落地,先算出风险原始分数。
  2. level = self.decision_level(score)根据阈值把分数翻译成放行、复审或拦截。
  3. return math.ceil(len(self.members) * 2 / 3)计算会议有效所需的最小出席人数,呼应三分之二规则。
  4. self.review_count += 1每审一次留痕一次,支撑后续复盘和追责。
  5. utility = self.safety_weight * score + (1 - self.safety_weight) * case["business_value"]用安全权重大于增长权重来量化冲突权衡。

常见误区

误区很多人觉得AI伦理委员会的任务就是拦住高风险项目,让业务少干点,发展慢一点也没关系。于是业务部门视委员会为“审批门卫”,能绕就绕。

正解委员会更像社区议事堂的仪表盘和护栏,不是刹车。它的目标是让“能做的项目”被做对,把风险讲清楚,把失败概率降下来。比如智能客服不是不上线,而是上线前先调整话术和转人工规则;委员会的价值是陪着业务把项目做成,而不是动不动叫停。若把委员会定位成刹车,它一定会失去业务信任,最终连护栏都守不住。

为何常见:多数人看见伦理委员会处理的都是“高风险案例”,自然联想到它总是反对AI落地,忽略了它大量日常工作是优化方案、校准边界和培训赋能。

误区为了显得重视伦理,把法务、技术、产品、公关、工会都塞进委员会,觉得人多就能代表各方,决策自然更正确。

正解委员会的有效性来自“技能互补”和“议事能力”,不是数量。人数太多会让讨论琐碎、责任分散、流程拖沓。更合理的设计是控制核心委员数量(如7-9人),明确每个席位的能力要求,并设置候补和外部专家。就像业委会不需要整栋楼的住户一起开会,而是选出会看报表、懂物业法、有时间跑现场的代表。

为何常见:人们把“民主”等同于“所有人参与”,但治理结构中的代表制恰恰是为了在效率和代表性之间取得平衡。

误区有些委员会为了保证独立,刻意和业务部门保持距离,不参加产品评审会,只在季度例会上看材料。结果拿到一张无法判断对错的PPT,只能凭感觉投票。

正解独立是指汇报线、预算和处置权不受业务KPI控制,不是“老死不相往来”。委员会必须早期介入、和业务开诚布公地讨论,否则信息不对称会让独立性变成武断。就像小区业委会要独立监督物业,但也要定期和物业、业主代表开联席会,否则它连漏水情况都不知道。

为何常见:把“独立”理解为“距离”是最省力的误解,真正难的是在亲密协作中保持不被收买的判断力。

误区公司一纸通知宣布“伦理委员会成立”,然后就不再投入,觉得从此高枕无忧,AI出了问题都能甩给委员会。

正解委员会只是治理框架的“人”的部分,还需要章程、流程、记录、指标、文化等支撑。没有流程的委员会,就像没有议事规则的业委会,开会只会吵架。必须配套:清晰授权、申报通道、决策留痕、定期复盘和持续培训,才能真正让治理体系运转起来。

为何常见:组织变革最容易犯的错误就是“挂牌即完成”,把形式当作能力建设。

面试题

Q1. AI伦理委员会的核心职责是?

单选题 · easy

  • A.替程序员修代码漏洞
  • B.界定风险并护航业务← 正确答案
  • C.替市场部写合规文案
  • D.接管全部算法服务器

答案:B。委员会的核心是界定AI伦理风险边界,然后在这个边界内帮业务把项目做成。修代码、写文案、接管服务器都是其他职能的活,委员会不是执行部门,而是治理机构。

Q2. 委员会权威性最重要的来源是?

单选题 · easy

  • A.委员会的办公人数多
  • B.高管背书和独立直报← 正确答案
  • C.所有成员都来自研发
  • D.把会议室设在最高层

答案:B。权威性来自组织授权,尤其是独立汇报线和最高管理层公开背书。人数多、办公室楼层高只是形式,若委员会要向业务负责人汇报,就很难顶住业务压力做出独立裁决。

Q3. 业务团队提交AI项目评审,第一步通常是?

单选题 · easy

  • A.等出事后再补流程
  • B.通过申报通道报材料← 正确答案
  • C.请老板绕过委员会
  • D.让技术部门写保证书

答案:B。规范的伦理评审要求业务团队走统一申报通道提交项目材料,然后由委员会按风险等级分流。绕过流程或出事再补,恰恰是治理体系最需要堵住的漏洞。

Q4. 以下哪项最能保障委员会独立性?

单选题 · mid

  • A.独立预算和独立汇报线← 正确答案
  • B.让业务负责人兼任主席
  • C.只在突发事故时开会
  • D.在茶水间张贴决策章程

答案:A。独立预算让委员会不受业务资源掣肘,独立汇报线让它不必向被监管对象汇报。让业务负责人兼任主席,等于让球员自己当裁判,独立性会大打折扣。

Q5. 决策记录留痕的主要价值是什么?

单选题 · mid

  • A.帮助复盘和事后追责← 正确答案
  • B.让评审材料显得更厚
  • C.替代技术团队写文档
  • D.减少委员的参会负担

答案:A。留痕是为了让决策过程可追溯、可复盘、可追责,也能让外部监督有据可查。它的目的不是增加工作量,更不是替代技术文档,而是治理透明度的基础。

Q6. 哪种做法最符合“早期介入”的协作理念?

单选题 · mid

  • A.模型上线后开评审会
  • B.需求设计阶段就参与← 正确答案
  • C.舆情危机后开复盘会
  • D.让运维人员代写申请

答案:B。早期介入是在需求设计阶段就邀请委员会参与,这时候调整成本最低。上线后或舆情爆发后再介入,委员会就变成了救火队,而不是共同设计者。

Q7. 委员会面对业务冲突时,合理措施包括哪些?

多选题 · mid

  • A.按章程约定优先级排序← 正确答案
  • B.暂停业务部门的所有群
  • C.提供申诉与上诉通道← 正确答案
  • D.要求业务放弃所有项目

答案:AC。冲突处理要靠“章程优先级 + 申诉通道 + 透明裁定”,而不是封群或一刀切叫停。暂停所有群和放弃所有项目都缺乏程序正义,也不利于长期协作。

Q8. 下列哪些条件能提升委员会决策质量?

多选题 · hard

  • A.成员能力互补且多元← 正确答案
  • B.决策过程透明并留痕← 正确答案
  • C.只向业务线负责人汇报
  • D.引入外部独立专家顾问← 正确答案

答案:ABD。能力互补保证多角度看问题,透明留痕让决策经得起检验,外部专家补充内部盲区。只向业务线汇报会削弱独立性,不利于决策质量。

Q9. 员工申诉与上诉通道的价值体现在哪里?

多选题 · hard

  • A.为错判提供纠偏机会← 正确答案
  • B.让处理过程更可监督← 正确答案
  • C.免除委员会全部责任
  • D.替代业务审批权限

答案:AB。申诉通道让被否定的业务方有一个合法表达渠道,也让委员会必须更认真地对待裁定。它不能免除责任,更不能替代业务审批,只是治理闭环中的纠偏机制。

Q10. 最能体现委员会权威性不被KPI裹挟的是?

单选题 · extreme

  • A.顶着业绩压力坚持风险裁定← 正确答案
  • B.为季度目标跳过伦理评审
  • C.把章程作为临时参考文件
  • D.任命业绩冠军担任委员会主席

答案:A。真正的权威性体现在最糟糕的时候依然能守住底线。顶着业绩压力坚持裁定,说明委员会没有被短期KPI收买;为了业绩跳过评审,恰恰是治理失效的表现。